linux-kernel - Re: [KVM PATCH v4 3/3] kvm: add iosignalfd support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4A1E7FA0.8060300@novell.com>
Date:	Thu, 28 May 2009 08:12:16 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Mark McLoughlin <markmc@...hat.com>
CC:	Gregory Haskins <gregory.haskins@...il.com>,
	Avi Kivity <avi@...hat.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Davide Libenzi <davidel@...ilserver.org>, mtosatti@...hat.com
Subject: Re: [KVM PATCH v4 3/3] kvm: add iosignalfd support

Mark McLoughlin wrote:
> On Wed, 2009-05-27 at 16:45 -0400, Gregory Haskins wrote:
>   
>> Mark McLoughlin wrote:
>>     
>>> The virtio ABI is fixed, so we couldn't e.g. have the guest use a cookie
>>> to identify a queue - it's just going to continue using a per-device
>>> queue number. 
>>>       
>> Actually, I was originally thinking this would be exposed as a virtio
>> FEATURE bit anyway, so there were no backwards-compat constraints.  That
>> said, we can possibly make it work in a backwards compat way, too. 
>> IIRC, today virtio does a PIO cycle to a specific register with the
>> queue-id when it wants to signal guest->host, right?  What is the width
>> of the write?
>>     
>
> It's a 16-bit write.
>
> /* A 16-bit r/w queue notifier */
> #define VIRTIO_PCI_QUEUE_NOTIFY         16
>   

(Thanks)

>   
>>> So, if the cookie was also the trigger, we'd need an
>>> eventfd per device.
>>>   
>>>       
>> I'm having trouble parsing this one.  The cookie namespace is controlled
>> by the userspace component that owns the corresponding IO address, so
>> there's no reason you can't make "queue-id = 0" use cookie = 0, or
>> whatever.  That said, I still think a separation of the cookie and
>> trigger as suggested above is a good idea, so its probably moot to
>> discuss this point further.
>>     
>
> Ah, my mistake - I thought the cookie was returned to userspace when the
> eventfd was signalled, but no ... userspace only gets an event counter
> value and the cookie is used during de-assignment to distinguish between
> iosignalfds.
>
> Okay, so suppose you do assign multiple times at a given address -
> you're presumably going to use a different eventfd for each assignment?
> If so, can't we match using both the address and eventfd at
> de-assignment and drop the cookie from the interface altogether?
>   

This is closer to how the original series worked, but Avi asked for a
data-match token and thus the cookie was born.  I think the rationale is
that we can't predict whether the same eventfd will be registered more
than once, and thus we need a way to further qualify it.  However, to
your point, I cannot think of a valid use case for having the same fd
registered to the same address more than once, so perhaps your fd/addr
tuple is sufficient and we can drop the cookie (or, really, rename it to
"trigger" ;)

Avi?

Regards,
-Greg


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