Re: [PATCH 0/5] KVM paravirt_ops implementation

Zachary Amsden
2007-06-20T19:35:16Z

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.

>>> 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).

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.

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