Mark McLoughlin wrote: > On Wed, 2009-05-27 at 13:40 -0400, Gregory Haskins wrote: > >> Mark McLoughlin wrote: >> >>> On Wed, 2009-05-27 at 15:11 +0300, Avi Kivity wrote: >>> >>> >>> >>>> Multiple cookies on the same address are required by virtio. You can't >>>> mux since the data doesn't go anywhere. >>>> >>>> Virtio can survive by checking all rings on a notify, and we can later >>>> add a mechanism that has a distinct address for each ring, but let's see >>>> if we can cope with multiple cookies. Mark? >>>> >>>> >>> Trying to catch up, but you're talking about replacing virtio-pci >>> QUEUE_NOTIFY handling with iosignalfd ? >>> >>> For a perfect replacement, what you really need is to be able to >>> register multiple cookies per address range, but only have them trigger >>> if the written data matches a provided value. >>> >>> >> Hmm..thats an interesting idea. To date, the "cookie" has really been >> for identifying the proper range selected for deassignment. I never >> thought of using it as an actual trigger value at run-time. >> >> >>> If the data is lost, virtio has no way of knowing which queue is being >>> notified, so we either end up with per-device, rather than per-queue, >>> notifications (probably not too bad for net, at least) or a different >>> notify address per queue (limiting the number of queues per device). >>> >>> >> The addr-per-queue is how I was envisioning it, but the trigger value >> concept hadn't occurred to me. I could make this an option during >> assignment (e.g. "COOKIE" flag means only trigger on writes of the >> provided cookie, otherwise trigger on any write). Sound good? >> > > Ah, I'd been thinking of the trigger data being provided separately to > the cookie. > Yeah, that shouldn't be a problem. Its probably cleaner, too. Perhaps I can simplify things and make the trigger width fixed (say, always 32bit) just so I dont have to support 8,16,32 and 64 variants. > 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? > 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. -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
