Re: Xen & VMI?

Ingo Molnar
2007-03-06T11:59:57Z

* Gerd Hoffmann <kraxel@suse.de> wrote:

> > || Also, lguest and KVM is Linux-internal, so there's a natural
> > || match between the guest and the host APIs.
> >
> > It's a basic kernel maintainance issue: lguest/KVM and Linux host
> > and guest will co-evolve foward in a natural way as they are in
> > essence Linux-internal technologies. They /will/ harmonize.
>
> Yes for lguest, that is a linux-only ground for play and research and
> that will most likely not change in near future.

i actually disagree here: lguest is growing up and will inevitably have
to spend a small amount of its attention on the world beyond the
playground too - even if Rusty doesnt want that =B-) That will happen
de-facto the first time a distro ships an lguest-capable kernel, so it's
unavoidable.

> It is complete bullshit for kvm. You can run almost anything as guest
> in kvm, and I certainly wouldn't be surprised if we see other
> operating systems start using the kvm paravirt interface.

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

> > There is no such guarantee with Xen/VMWare/etc. (which are
> > distinctly separate technologies) - so any ABIs towards them could
> > become (and are already becoming) a drag and distraction.
>
> We'll certainly need some stable ABI for kvm too, so you can mix
> kernel versions on host and guest. I really can't see why do you
> think kvm is special in any way [...]

lguest/KVM is fundamentally special because its future evolution is
naturally aligned with that of Linux. 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. 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.

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.

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

Ingo