Re: [PATCH 0/5] KVM paravirt_ops implementation

Jeremy Fitzhardinge
2007-06-20T19:47:18Z

Zachary Amsden wrote:
> 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).

paravirt_ops-style paravirtualization and paravirt device drivers are
more or less completely orthogonal. An unmodified OS running under hvm
Xen can still have paravirt drivers which can detect the presence of
Xenbus and do all the appropriate things. It would presumably be a
matter of loading xenbus.ko, which would probe for the presence of the
Xen device infrastructure, and that in turn would start pulling in the
appropriate paravirt drivers. The state (or existence) of struct
paravirt_ops is immaterial.

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

No, I think not. Normal bus/device probing should be able to deal with it.

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

To a large extent that already exists in the device model.

J