Re: Xen & VMI?

[Jeremy Fitzhardinge <jeremy@goop.org>]

Ingo Molnar wrote:
> legacy support has to be ensured, but it does not hugely matter in terms 
> of the designing our future. What matters is that once we change some 
> fundamental aspect of Linux, we can adopt lguest/KVM immediately. With 
> 'external' hypervisors there is no such compulsory forward motion, and 
> my fear is that by giving them ABI interfaces to the innards of the 
> Linux guest they will just stick with those ABIs - and worse, drag Linux 
> along with them. (because distros will be forced by the legacy 
> assumptions to carry those ABIs along.)
>   

So what's your argument here?  That if Xen/ESX/whatever are evolved
separately from Linux, then they should be tied together behind one ABI,
so that even if one could support a new Linux feature it can't move
until everyone else implementing the ABI too?  How does that help anyone?

The big practical difficulty is that there are no examples of an ABI
with multiple implementations all being sufficiently cross-compatible
that a user of that ABI can actually rely on it working consistently
(and certainly not to the extent that it actually reduces the test
matrix size).  There are masses of subtle details that are hard to get
right, and making sure that multiple implementations get all this right
is apparently impossible (otherwise ACPI would be a dream to work with...).

> lguest/KVM is fundamentally special because its future evolution is 
> naturally aligned with that of Linux.

lguest is special, because it is purely kernel-internal (and because
Rusty wrote it, of course).  kvm is not, and I don't see why you think
it is.  In its simplest form its a thin layer which exposes hardware
virtualization to usermode, which happens to be qemu at the moment.  Its
evolving some bells and whistles, but at heart it's being developed by a
company with just as much commercial interest and backing as Xen and
VMI, and it has the scope to be just as cross-platform.

>  Sure, legacies will have to be 
> taken care of (just like Linux supports old system-calls and even old 
> driver APIs in some circumstances), but there is no danger of KVM 
> staying in legacy land forever.

Sure there is.  It needs the usermode part to keep sync; that's easy if
its qemu, but you're stuck if its a proprietary usermode implementing
that end of the kvm equation.

>  With Xen and VMWare i see no guarantee 
> at all that Linux wont be hindered by their legacies (or by any plain 
> diverging approaches) forever.
>   

Well, if the kernel goes one way and Xen doesn't follow, then that
pretty severely restricts Xen's usefulness - there's a pretty strong
incentive for Xen to keep supporting Linux.  And besides, Xen is all
GPL, so anyone who's sufficiently motivated can do this work.

> so for example, if we change some fundamental thing that can be 
> implemented via the legacy ABI but only slowly, that's not a problem 
> because new-lguest/new-KVM will use the new approach, so there's a 
> straightforward technology-based migratory path out of the legacy. But 
> if Xen or VMWare were to stick with that legacy ABI forever (for 
> whatever reason), we couldnt solve that situation on the Linux side at 
> all, via technological measures.
>   

Well, that's the reason for minimizing Linux's exposure to any ABI. 
Clearly the interface to a hypervisor has to be *some* ABI.  But it
doesn't help anyone if there's an extra uber-ABI which is a superset of
all the underlying hypervisor ABIs; that's just a big rigid, brittle mess.

The whole point of pv_ops is to allow the hypervisors interfaces to
evolve at their own pace without having to constrain the core kernel's
development

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

Well, if there were any other guests that used VMI that might be
useful.  You'd get further using the Xen ABI.


    J