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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
