Arnd Bergmann wrote: > On Tuesday 18 August 2009, Gregory Haskins wrote: >> Avi Kivity wrote: >>> On 08/17/2009 10:33 PM, Gregory Haskins wrote: >>> >>> One point of contention is that this is all managementy stuff and should >>> be kept out of the host kernel. Exposing shared memory, interrupts, and >>> guest hypercalls can all be easily done from userspace (as virtio >>> demonstrates). True, some devices need kernel acceleration, but that's >>> no reason to put everything into the host kernel. >> See my last reply to Anthony. My two points here are that: >> >> a) having it in-kernel makes it a complete subsystem, which perhaps has >> diminished value in kvm, but adds value in most other places that we are >> looking to use vbus. >> >> b) the in-kernel code is being overstated as "complex". We are not >> talking about your typical virt thing, like an emulated ICH/PCI chipset. >> Its really a simple list of devices with a handful of attributes. They >> are managed using established linux interfaces, like sysfs/configfs. > > IMHO the complexity of the code is not so much of a problem. What I > see as a problem is the complexity a kernel/user space interface that > manages a the devices with global state. > > One of the greatest features of Michaels vhost driver is that all > the state is associated with open file descriptors that either exist > already or belong to the vhost_net misc device. When a process dies, > all the file descriptors get closed and the whole state is cleaned > up implicitly. > > AFAICT, you can't do that with the vbus host model. It should work the same. When a driver opens a vbus device, it calls "interface->connect()" and gets back a "connection" object. The connection->release() method is invoked when the driver "goes away", which would include the scenario you present. This gives the device-model the opportunity to cleanup in the same way. > >>> What performance oriented items have been left unaddressed? >> Well, the interrupt model to name one. > > The performance aspects of your interrupt model are independent > of the vbus proxy, or at least they should be. Let's assume for > now that your event notification mechanism gives significant > performance improvements (which we can't measure independently > right now). I don't see a reason why we could not get the > same performance out of a paravirtual interrupt controller > that uses the same method, and it would be straightforward > to implement one and use that together with all the existing > emulated PCI devices and virtio devices including vhost_net. Agreed. I proposed this before and Avi rejected the idea. -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
