linux-kernel - Re: Xen & VMI?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070306115937.GA25313@elte.hu>
Date:	Tue, 6 Mar 2007 12:59:37 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Gerd Hoffmann <kraxel@...e.de>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	virtualization <virtualization@...ts.osdl.org>,
	Jan Beulich <jbeulich@...ell.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Xen & VMI?

* Gerd Hoffmann <kraxel@...e.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/