Re: [PATCH 0/5] KVM paravirt_ops implementation

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

Zachary Amsden wrote:
> Anthony Liguori wrote:
>> But what's the value in having it not in the kernel?  Let's take Xen 
>> and lhype out of the picture because it clearly has to be there for 
>> them.  You have a little less in the kernel now but then your kernel 
>> boots more slowly.  There's already a noticable difference in 
>> boot-time with the KVM paravirt_ops implementation.  I imagine there 
>> is for VMI too.
>
> If it isn't compiled in the core kernel, then a distro need not do 
> anything special to distribute VMI or KVM support - other than compile 
> support for paravirt-ops.  Then the paravirt-ops module can be 
> installed along with the guest tools and drivers, but need not be on 
> install media.

Typically, distros do not support third-party modules so that's not a 
very useful property.  Further, that just encourages out-of-kernel 
modules and worst yet, binary modules.

In fact, the whole install "guest tools" is fundamentally broken in this 
respect.  Guest tools always end up installing closed source drivers.  
Plus, these things aren't available during distro installation typically 
so you end up with a sucky user experience.

> Basically, it just makes it easier on distributors and allows any old 
> kernel with paravirt-ops module support to run on any modern, new 
> hypervisor - that might not have even existed at the time the distro 
> was created.

Yeah, I'm not buying it.  Is it really that much easier to backport a 
module than it is to just roll out a new kernel for an older distro?

BTW, isn't this the whole point of the VMI ROM? :-)

Regards,

Anthony Liguori

>>
>> In the case of KVM, the paravirt_ops implementation is orthogonal to 
>> paravirt device drivers.  A PV device driver can happily exist even 
>> if the paravirt_ops backend isn't activated.  This is assuming that 
>> hypercalls aren't used btw.  If hypercalls are desirable to use, then 
>> the paravirt_ops backend would have to EXPORT_GPL the hypercall 
>> interface.  I imagine returning a specific errno would suffice.
>
> I'm mostly in agreement on that - although making dual hypercall / I/O 
> emulated drivers is a bit more work.
>
> Zach
>
>


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/