Re: Xen & VMI?

[Anthony Liguori]

Nakajima, Jun wrote:
> Anthony Liguori wrote:
>   
> > Ingo Molnar wrote:
> >     
> > > * Gerd Hoffmann <kraxel@xxxxxxx> wrote:
> > >
> > >       
> > > > > > So in the end you would still have two different hypervisor ABI's,
> > > > > > the VMI ROM just hides that.
> > > > > >             
> > > > > oh, but that way i have cleverly pushed the problem out of Linux
> > > > > and into the VMI-ROM's domain ;) Which is all i care about.
> > > > >           
> > > > Fine, so lets move kvm paravirtualitzation into vmi too (proof of
> > > > concept code by Anthony Liguori exists) and kill one more item on
> > > > the (linux) QA test matrix?  (just following your arguments, not
> > > > that I'm confident it would actually help reducing QA effort).
> > > >         
> > > yes - although obviously a KVM Linux guest does not need such an
> > > interface - but it's a nice proof of concept to integrate other guest
> > > OSs into KVM.
> > >       
> > I disagree that a KVM Linux guest does not benefit from VMI.  Right
> > now, your KVM paravirt interface only covers CR3 target caching and
> > apic enhancements (neither of which I believe have made it into
> > 2.6.21). Inevitably, things like MMU batching will be added.
> >     
>
> I think a KVM Linux would benefit more from paravirt ops, rather than
> VMI. 

Functionally speaking, the only difference between using VMI and 
paravirt_ops is that with VMI you redirect the paravirt_ops to a ROM 
area.  This has the following effects:

1) you cannot call back into Linux from the op implementation
2) you can change the implementation of the op w/o rebuilding the kernel

1 & 2 are trade-offs.  For everything that KVM can do wrt 
paravirtualization, there really isn't a need for #1 at the moment.  Xen 
is much more challenging to do with VMI as there are a lot of instances 
where #1 is quite useful.  I think you pretty much have to target 
paravirt_ops for Xen.

> The higher-level interface such as the one in Xen, espeically for
> I/O, interrupt controllers, timer, SMP, etc. actually simplifies the
> implementation of the VMM,

Right, but those higher-level interfaces can certainly be implemented 
within the context of a VMI rom.  For instance, VMI already defines a 
paravirtual timer.  In the case of interrupt control, it just provides 
hooks for APIC reads/writes with the assumption (presumably) that the 
ROM will implement APIC emulation and bridge to whatever the hypervisor 
abstraction is.

>  and improve performance of the guest. Even
> for MMU, direct page tables, for example, would work better for
> hardware-based virtualization because the processor can use the native
> page tables. 
>   

Direct paging is a whole other can of worms.  Fortunately, EPT and NPT 
will eliminate the need to worry about this in the future for things 
like KVM/HVM :-)

Regards,

Anthony Liguori

> > Using paravirt_ops, this is going to require new kernels for the
> >   guests. Every new paravirtualization feature will require a new
> >   guest kernel. With VMI, one can add these features to any 2.6.21+
> > guest by just modifying the ROM (assuming a newer host).  Some
> > features will require new VMI entry points but quite a lot will fall
> > under the current entry points.
> >
> > Of all the hypervisors, KVM is the easiest to use VMI with.  QEMU
> > already supports option ROM loading and Zach just made some changes to
> > allow a native ROM to be implemented very easily.
> >
> > If we're going to use VMI for anything other than VMware, it seems to
> > be that KVM should be what we use it for.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> >     
> > > 	Ingo
> > >       
>
> Jun
> ---
> Intel Open Source Technology Center
>
>   

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/