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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 6 Mar 2007 11:26:59 +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:

> > cleanliness and performance: KVM doesnt need any artificial 
> > indirection.
> 
> Xen doesn't need it either.
> 
> > 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. 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.

> > well, the VMI patches got into Linux with the claim that it's also 
> > useful for Xen. So that claim was ... not actually true?
> 
> As mentioned there was a proof-of-concept VMI ROM done by vmware.  As 
> far I know it translated the VMI ROM interface calls into xen 
> hypercalls somehow, Zach probably has more details.
> 
> 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.

really, one of my jobs as a maintainer is to keep crap out of Linux (we 
are capable of adding enough crap ourselves ;-). Having multiple, 
overlapping, technologically redundant ABIs between /software/, embedded 
into the heart of the kernel (paravirt ops nonwithstanding), for 
perpetuity, is one such type of crap. It is in fact the kind of crap i'm 
/most/ worried about, because it sticks forever.

	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/