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
