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: <45ED2F53.2040101@goop.org>
Date:	Tue, 06 Mar 2007 01:07:31 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Zachary Amsden <zach@...are.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	virtualization <virtualization@...ts.osdl.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>, Andi Kleen <ak@...e.de>,
	linux-kernel@...r.kernel.org, Jan Beulich <jbeulich@...ell.com>
Subject: Re: Xen & VMI?

Ingo Molnar wrote:
> btw., while we have everyone on the phone and talking ;) Technologically 
> it would save us a whole lot of trouble in Linux if 'external' 
> hypervisors could standardize around a single ABI - such as VMI. Is 
> there any deep reason why Xen couldnt use VMI to talk to Linux? I 
> suspect a range of VMI vectors could be set aside for Xen's dom0 (and 
> other) APIs that have no current VMI equivalent - if there's broad 
> agreement on the current 60+ base VMI vectors that center around basic 
> x86 CPU capabilities - which make up the largest portion of our 
> paravirtualization complexity. Pipe dream?

Well, we went around this about six months ago, and decided the best way
forward is the current paravirt_ops approach. 

The Xen and VMI interfaces are quite different, and have different
design goals.  VMI is fairly low-level, and is approximately a software
implementation of VT/SVM with a couple of extra bits, whereas the Xen
interface is intended to be higher level, with the expectation that the
guest cooperates more with its virtualization.  They have similarities
by necessity, but they have some fairly basic differences.

You could come up with some shim layer which makes the two interfaces
appear similar, and you could spell the name of that shim "VMI".  Or you
could call it "paravirt_ops", which is the name we chose.  And you could
implement the interface to that layer as a binary ABI, or you could make
it a normal source-level Linux kernel interface, which is what we chose
to do.

Either way, its still one of native hardware, VMI/ESX, Xen or something
else under the interface layer, and you need to test for each case
regardless of what the interface looks like.

    J
-
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/