linux-kernel - Re: [RFC PATCH 1/3] kvm: keep track of which task is running a KVM vcpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4CFB8842.4010003@redhat.com>
Date:	Sun, 05 Dec 2010 14:40:34 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Rik van Riel <riel@...hat.com>
CC:	Chris Wright <chrisw@...s-sol.org>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>,
	Anthony Liguori <aliguori@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH 1/3] kvm: keep track of which task is running a KVM
 vcpu

On 12/03/2010 04:50 PM, Rik van Riel wrote:
> On 12/02/2010 08:18 PM, Chris Wright wrote:
>> * Rik van Riel (riel@...hat.com) wrote:
>>> Keep track of which task is running a KVM vcpu.  This helps us
>>> figure out later what task to wake up if we want to boost a
>>> vcpu that got preempted.
>>>
>>> Unfortunately there are no guarantees that the same task
>>> always keeps the same vcpu, so we can only track the task
>>> across a single "run" of the vcpu.
>>
>> So shouldn't it confine to KVM_RUN?  The other vcpu_load callers aren't
>> always a vcpu in a useful runnable state.
>
> Yeah, probably.  If you want I can move the setting of
> vcpu->task to kvm_vcpu_ioctl.
>

No need, it's not like something bad will happen.

What I'd really like to see is a soft binding between a vcpu and its 
thread, so directed yield works even if we're in qemu while we were 
scheduled out.  In fact it's not an unlikely pattern:

   spin_lock(&lock)
   ...
   writel(some_port_handled_by_qemu)
   ...
   spin_unlock(&lock)

but that can wait.

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/