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.
>> 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.
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
