Re: [PATCH 0/5] KVM paravirt_ops implementation

[Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>]

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/