>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
As always you keep developing KVM features ahead of the group :) Well, you got passed a little bit by virtio, but we can share code and ideas from both implementations. Can you provide performance figures? What’s the tcp/udp between guest & host? Are you using HVM guests or PV (kernel) guests? From my experience HVM has bug overhead since they must go through irq ack with the current userspace pic/apic. I saw that you use kvm_vcpu_send_interrupt in a comment. Did you actually inject irqs? Through the kernel or userspace? Also I have some general comments: - I like the approach of a general shared memory queue (one can call it dma descriptor data structure or whatever). Rusty has a similar dma descriptor code that can be generealized easily too. - Regarding the virtual bus, I didn't see any use of standard Linux APIs such as 'bus_register' or 'driver_register'. Take a look at lguest_bus.c, it is very nice piece of code. Since both lguest and KVM needs one, it will be good idea to generalize it. Actually I remember there were some patches for that case that were not merged. - IMO the ring code lacks lots of memory barrier calls (actually my original implementation partially suffered from that too ... Since Rusty has taken care for that in his virtio implementation I think we should base our KVM PV devices over it. I just started porting virtio to KVM and expect to see the first packets coming in today. I'll send initial patches when it be in better shape next week. Nevertheless, any ideas/code are welcomed. Now I'll take a better look in the code. Thanks for the code, Dor. ------------------------------------------------------------------------- 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
