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. 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. So, if the cookie was also the trigger, we'd need an eventfd per device. And if this was a device where the guest writes similar values to multiple addresses, you'd need an eventfd per address. Cheers, Mark. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
