Thread (1 message) 1 message, 1 author, 2007-06-20

Re: [PATCH 0/5] KVM paravirt_ops implementation

From: Jeremy Fitzhardinge <hidden>
Date: 2007-06-20 19:47:18
Also in: kvm

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

-------------------------------------------------------------------------
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/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help