Re: [PATCH 0/5] KVM paravirt_ops implementation

[Zachary Amsden <zach-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>]

Jeremy Fitzhardinge wrote:
> Well, I was suggesting we could print the banner later rather than
> forcing an earlier init.
>
> The important part is that you set your pv_ops before patching occurs,
> since that will bake the function calls into the rest of the kernel, and
> it will ignore any further changes to the paravirt_ops structure.
>
> I think Zach was originally thinking of initializing VMI much later
> (even as a module load), but the subtleties of inveigling its way into
> the kernel at that late stage got too complex.
>   

Definition: software-reliant paravirtualization is a guest-involved 
virtualization technique in which non-virtualizable operations are 
substituted in software with virtualized operations, thus making 
redirection of instruction flow necessary for correct operation.

For software-reliant paravirtualization, it is difficult to atomically 
switch from natural instructions to simulated para-instructions on the 
fly; you would need stop_machine_run that also holds off NMIs (so as to 
keep IF flag state intact across a window where non-virtualizable IRET 
instruction is not yet patched), and you would need to re-patch the 
kernel and modules dynamically.  Another problem is unloading the 
module, which requires restoring the smashed native paravirt-ops - some 
of which may have been patched, some not.  It is possible to do this 
from a module, just obtuse, and for 32-bit, not really worth the effort 
IMHO.

Definition: software-advisory paravirtualization is a guest-involved 
virtualization technique in which only advisory state is communicated to 
the hypervisor, thus making redirection of instruction flow at any 
particular point optional for more efficient virtualization (and 
non-virtualizability is eliminated by some other mechanism).

For software-advisory paravirtualization, it is totally possible to just 
switch over to new pv-ops at any time, and there need be no atomicity.  
This would make a paravirt-ops module rather easy to write; it simply 
needs to run some init code on each CPU and the patch paravirt-ops at 
leisure.

Now it is quite likely at least one developer is going to be assuming 
hardware virtualization capabilities for 64-bit paravirt, thus making an 
advisory method with module loading (and unloading) a more practical 
option than dissecting the 64-bit startup sequence.  In that case, 
perhaps having a paravirt_register function which would check to make 
sure no conflicting paravirt-ops have already been installed, printing 
the banner on success would be the most logical.  The 
paravirt_unregister function can then simply restore the native 
paravirt-ops.

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.

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/