Thread (1 message) 1 message, 1 author, 2007-06-20

Re: [PATCH 0/5] KVM paravirt_ops implementation

From: Anthony Liguori <hidden>
Date: 2007-06-20 20:22:49
Also in: kvm

Zachary Amsden wrote:
Anthony Liguori wrote:
quoted
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
quoted
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/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help