This patch series represents the state of my current work w.r.t. PV and KVM. It is still a work in progress and so far has only been compile tested (though earlier versions had a test harness that ironed many bugs out). I submit it now as an RFC on the directions I am taking and to solicit feedback. Note that it is based on Dor's PV branch, not kvm.git master.
As a brief synopsis, the series implements the following: *) A generic shared-memory based IO subsystem called "IOQ". This is an iterator based interface, with an asymmetric allocation scheme conducive to virtualization constraints. Its designed to allow for "zero copy" (yeah, I know its not really ;) type buffer passing between host and guest, including deferred pointer reaping. It also allows for bi-directional NAPI which can mitigate both guest interrupts as well as host-hypercalls on active queues. *) A generic paravirtual-bus abstraction (called PVBUS) for discovery/configuration of PV devices. This allows backend driver writers to simply plug into the system without mucking with ACPI, Bochs, PCI, and other legacy related items. It also allows guest drivers to dynamically find, query, and connect to backend devices in a hypervisor and system neutral way. This is helpful, for instance, for s390 that from what I understand doesn't have PCI. *) An example PV network driver called "IOQNET". Note that the guest side of this driver is VMM independent since it sits on top of the IOQ/PVBUS interfaces. I started this work a while back before I knew about Rusty's VirtIO proposals. I had recently contemplated distilling the original interface into an implementation of virtio, but there was some key differences in approach taken. Rather than just throw those differences away, I figured I would submit it "as is" to foster discussion. I would ideally like to see a convergence between IOQ and VirtIO with Rusty's blessing. So Rusty: If you see anything that I did that looks interesting to you, I would like to work with you on bringing some of those ideas into a VirtIO implementation for KVM. I would like to thank all of you out there who guided me along the way. In particular, Hollis, Anthony, Dor and Rusty were most helpful in helping me to understand how to go about building something like this. -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
