On Tue, 2007-08-14 at 00:44 -0700, Dor Laor wrote: > Can you provide performance figures? What’s the tcp/udp between guest & host?
None yet :( Its pretty much "pseudo code that compiles" at this point. ;) I still have to work out several issues before I can even begin testing. Interrupt management jumps out at me as one of those issues. The one saving grace is that I originally developed the ioq.[ch] code in userspace with a mutex/condvar based ioqmgr. So in general I know the queuing code works. But once I started really coding to the kernel it became difficult to maintain the test harness so I cut it out and abandoned it. > I saw that you use kvm_vcpu_send_interrupt in a comment. Did you actually > inject irqs? Not yet, just a place holder for the real implementation. Now you know why I was interested in the lapic project tho ;) > Through the kernel or userspace? The thing obviously would prefer an in-kernel injection path, but I think I might need to talk to you soon about getting the userspace path working in the interim until the lapic3 branch is merged. > > 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. By all means, point me to the area you think I can contribute here. One of the the things I was thinking of as I looked at the two was that perhaps the code in IOQ could be used to *implement* virtio. Even if people don't like having the iterator methods exposed directly to end-users (e.g. drivers), the stuff I did to generalize the queuing and to abstract the VMM platform away might be useful. > - 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. This wasn't on purpose per se. I will definitely take a look at that. On that topic, I really see the queuing code as independent from the pvbus code. Did you like any of the directions I took things there, or am I off in the weeds? > - IMO the ring code lacks lots of memory barrier calls (actually my original > implementation > partially suffered from that too ... Totally agree. Its on my plate. I think at the very least I need them in the ioq_signal() code. But there are probably other places too, like before the ownership bit is changed (e.g. desc->sown). > 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. I am looking forward to your patches! -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
