lkml.org 
[lkml]   [2009]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
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

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2009-08-19 07:39    [W:0.278 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site