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
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
