Re: [PATCH 0/5] KVM paravirt_ops implementation

Zachary Amsden wrote:

Jeremy Fitzhardinge wrote:

quoted

Anthony Liguori wrote:
 

quoted

I don't agree that having paravirt_ops within a normal module is all
that useful.  By the time modules can be loaded, the kernel has
completely booted.  There should only be a handful of paravirt_ops
implementations and they aren't large so I don't think there's a big
size savings either.
    

It doesn't seem terribly valuable to me either.  But Zach is talking
about something very similar to the kvm case, where you have a fully
virtualized environment (with hardware support), but then you load a
module containing paravirtualized helpers at some late stage which makes
things more efficient but isn't required for functional correctness.
  

Yes, the value isn't the space savings - it's the ability to include 
paravirtualized driver support for Xen, KVM, VMI, lhype - which need 
not be compiled in, but can now be modules in a ramdisk.  The goal is 
minimal effort for a single bootable image which works across native 
and all virtualization environments.

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.

quoted

quoted

quoted

More importantly, now device drivers for virtual devices would have a
way to inquire into which set of paravirt-ops was loaded by having an
official registered interface rather than an ad-hoc (if xxx_running
== 1) mess, and now the paravirt driver modules are nicely decoupled
from the boot-strap code and can be loaded dynamically.
      

I'm not familiar with the particular problem here, but I don't think
that driver modules should be checking to see what paravirt_ops is
active.  Each VMM has it's own discovery mechanism (KVM and Xen are
both based on CPUID) so that seems like a much better method to use.
    

I think he's referring to the xen/kvm/vmi paravirt implementation as a
"driver" here.  I think.

I don't know of any "if (xxx_running)" tests at present.
  

For a VMM which supports both full emulation and para-virtualization, 
testing CPUID leaves is not sufficient to determine applicability of a 
paravirt device driver.  This only indicates the presence of the 
functionality, not the fact that the functionality has been 
activated.  For 32-bit Xen, this might be an already assumed fact - 
but for VMI, KVM, and HV assisted Xen, which do support guests running 
without paravirt, you need a way to test whether the particular family 
of paravirt has been activated - for device drivers which assume 
paravirt semantics might well require this activation to work, or need 
to behave differently in an unactivated environment (emulate 
hypercalls with port I/O, for example).

Presumably, this is the job of PV device discovery, not of 
paravirt_ops.  For instance, with Xen, this is the existence of XenBus.  
For KVM, it will probably be a psuedo-device on the PCI bus.

Thus, all the paravirt drivers as modules would need to test if 
(xen_running) or (vmi_enabled) or (kvm_active), and then all these 
symbols need to be exported, and now you have an ad-hoc activation 
detection system for each brand of paravirt.

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.

Regards,

Anthony Liguori

Better to have a standard interface, IMHO, where a paravirt-ops 
"parent" module gets registered and activated, and then well defined 
symbols to query that activation.  You also have module dependencies 
between the parent and child which are nicely modeled with the module 
system (xenbus dependes on xen, vmitimer depends on vmi, etc..).

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/