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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
