Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
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.
It doesn't seem terribly valuable to me either. But Zach is talking
about something very similar to the kvm case, where you have a fully
virtualized environment (with hardware support), but then you load a
module containing paravirtualized helpers at some late stage which makes
things more efficient but isn't required for functional correctness.
Yes, the value isn't the space savings - it's the ability to include
paravirtualized driver support for Xen, KVM, VMI, lhype - which need not
be compiled in, but can now be modules in a ramdisk. The goal is
minimal effort for a single bootable image which works across native and
all virtualization environments.
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.
I think he's referring to the xen/kvm/vmi paravirt implementation as a
"driver" here. I think.
I don't know of any "if (xxx_running)" tests at present.
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).
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.
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..).
Zach
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
