Re: Xen & VMI?

[Gerd Hoffmann]

Ingo Molnar wrote:
>>> IMO the GPL-ed ROM portion of VMI was a bad idea to begin with.
>> So why do you want xen use vmi then?
> 
> due to the other argument i listed:
> 
> || 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.

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.

> 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 (except that it is your favorite toy at the moment).

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

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@xxxxxxx>
-
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/