Anthony Liguori wrote: >>>> >>>>> + case VIRTIO_PCI_QUEUE_NOTIFY: >>>>> + if (val < VIRTIO_PCI_QUEUE_MAX) >>>>> + virtio_ring_kick(vdev, &vdev->vq[val]); >>>>> + break; >>>>> >>>> >>>> I see you're not using hypercalls for this, presumably for >>>> compatibility >>>> with -no-kvm. >>> >>> More than just that. By stick to PIO, we are compatible with just >>> about any VMM. For instance, we get Xen support for free. If we >>> used hypercalls, even if we agreed on a way to determine which >>> number to use and how to make those calls, it would still be >>> difficult to implement in something like Xen. >>> >> >> But pio through the config space basically means you're committed to >> handling it in qemu. We want a more flexible mechanism. > > There's no reason that the PIO operations couldn't be handled in the > kernel. You'll already need some level of cooperation in userspace > unless you plan on implementing the PCI bus in kernel space too. It's > easy enough in the pci_map function in QEMU to just notify the kernel > that it should listen on a particular PIO range.
With my new understanding of what this is all about, I suggest each virtqueue having an ID filled in by the host. This ID is globally unique, and is used as an argument for kick. It would map into a Xen domain id + event channel number, a number to be written into a pio port for kvm-lite or non-hypercall kvm, the argument for a kick hypercall on kvm, or whatever. This is independent of virtio-pci, which is good. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
