On Wed, 2007-08-15 at 00:13 -0400, Gregory Haskins wrote: > On Wed, 2007-08-15 at 06:58 +0300, Avi Kivity wrote:
> > 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). I think I misspoke when I said this (it was up way to late for coherent thought ;) While what you said is true (virtio = API, IOQ = API+ABI) note that I believe both can be considered hypervisor agnostic. (That was a primary design goal of mine). All the hypervisor would need to do is write an ioq_mgr layer. Xen for instance, could use either hypercalls/interrupts directly like I do for the KVM implementation. Or it could use XenBus as a signaling transport. I am only bringing this up as a correction to my statement, not to try to sway someone in some kind of IOQ vs VirtIO debate. :) Regards, -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
