linux-kernel - Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

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: <4B311ECB.6040205@gmail.com>
Date:	Tue, 22 Dec 2009 14:32:27 -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:25 PM, Avi Kivity wrote:
> On 12/22/2009 09:15 PM, Gregory Haskins wrote:
>> On 12/22/09 1:53 PM, Avi Kivity wrote:
>>   
>>> I asked why the irqfd/ioeventfd mechanisms are insufficient, and you
>>> did not reply.
>>>
>>>      
>> BTW: the ioeventfd issue just fell through the cracks, so sorry about
>> that.  Note that I have no specific issue with irqfd ever since the
>> lockless IRQ injection code was added.
>>
>> ioeventfd turned out to be suboptimal for me in the fast path for two
>> reasons:
>>
>> 1) the underlying eventfd is called in atomic context.  I had posted
>> patches to Davide to address that limitation, but I believe he rejected
>> them on the grounds that they are only relevant to KVM.
>>    
> 
> 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 ;)

> 
>> 2) it cannot retain the data field passed in the PIO.  I wanted to have
>> one vector that could tell me what value was written, and this cannot be
>> expressed in ioeventfd.
>>
>>    
> 
> It would be easier to add data logging support to ioeventfd, if it was
> needed that badly.

"Better design"? perhaps.  "More easily"?  no.  Besides, Davide has
already expressed dissatisfaction with the KVM-isms creeping into
eventfd, so its not likely to ever be accepted regardless of your own
disposition.

xinterface, as it turns out, is a great KVM interface for me and easy to
extend, all without conflicting with the changes in upstream.  The old
way was via the kvm ioctl interface, but that sucked as the ABI was
always moving.  Where is the problem?  ioeventfd still works fine as it is.

Kind Regards,
-Greg



Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)