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
-------------------------------------------------------------------------
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
