On Wed, 2007-08-15 at 06:58 +0300, Avi Kivity wrote: > > > Yes. virtio adapts the driver interface to an API can drive a shared > memory queue more easily, while you actually provide the queue protocol > (and ABI).
If I understand what you are saying, it actually jives with something that struck me as a potentially win-win a while back when I first heard about virtio. That is: you can actually implement virtio with ioq. I am not sure if that idea has any merit or not, especially given the news that virtio for KVM is almost done....but I thought I would mention it. > > virtio seems to have more modest goals: > > - make it easier to write guest/host (or guest/guest) transports, but > not actually provide them > - limited to guest only (and Linux only) > - no discovery/hotplug (yet?) As an aside, the version of the pvbus that I am working on right now (v3?) adds hotplug capability. I assume that there is some merit to me continuing the work at least on the discovery/hotplug front then? > > since it wants to be hypervisor agnostic, it cannot specify an ABI (as > some already have ABIs, for example Xen). I see, and that is a good point. By only being an API, virtio can work over XenBus or any other ABI it wants. IOQ is an API *and* an ABI. While this doesnt preclude it from ever working on Xen, it does imply that you would need to add the IOQ ABI to the Xen infrastructure if you wanted to use it (at least, if you wanted to use it directly instead of doing some kind of funky queue-in-queue with IOQ on XenBus..yuk). -Greg ------------------------------------------------------------------------- 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
