Zachary Amsden wrote:
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.
I don't agree that having paravirt_ops within a normal module is all
that useful. By the time modules can be loaded, the kernel has
completely booted. There should only be a handful of paravirt_ops
implementations and they aren't large so I don't think there's a big
size savings either.
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.
I'm not familiar with the particular problem here, but I don't think
that driver modules should be checking to see what paravirt_ops is
active. Each VMM has it's own discovery mechanism (KVM and Xen are both
based on CPUID) so that seems like a much better method to use.
Regards,
Anthony Liguori
Zach
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
