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

[Gregory Haskins]

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

Attachment: signature.asc
Description: OpenPGP digital signature