Re: [PATCH 0/5] KVM paravirt_ops implementation

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

Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
>> Anthony Liguori wrote:
>>  
>>> 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.


>>>> 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/