[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B311FF8.7000804@gmail.com>
Date: Tue, 22 Dec 2009 14:37:28 -0500
From: Gregory Haskins <gregory.haskins@...il.com>
To: Avi Kivity <avi@...hat.com>
CC: Ingo Molnar <mingo@...e.hu>, kvm@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
torvalds@...ux-foundation.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
netdev@...r.kernel.org,
"alacrityvm-devel@...ts.sourceforge.net"
<alacrityvm-devel@...ts.sourceforge.net>
Subject: Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/22/09 2:32 PM, Gregory Haskins wrote:
> On 12/22/09 2:25 PM, Avi Kivity wrote:
>>
>> If you're not doing something pretty minor, you're better of waking up a
>> thread (perhaps _sync if you want to keep on the same cpu). With the
>> new user return notifier thingie, that's pretty cheap.
>
> We have exploits that take advantage of IO heuristics. When triggered
> they do more work in vcpu context than normal, which reduces latency
> under certain circumstances. But you definitely do _not_ want to do
> them in-atomic ;)
And I almost forgot: dev->call() is an RPC to the backend device.
Therefore, it must be synchronous, yet we dont want it locked either. I
think that was actually the primary motivation for the change, now that
I think about it.
-Greg
Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)
Powered by blists - more mailing lists