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: <45EE24FA.7090002@vmware.com>
Date:	Tue, 06 Mar 2007 18:35:38 -0800
From:	Zachary Amsden <zach@...are.com>
To:	Chris Wright <chrisw@...s-sol.org>, Ingo Molnar <mingo@...e.hu>
CC:	Gerd Hoffmann <kraxel@...e.de>,
	virtualization <virtualization@...ts.osdl.org>,
	Jan Beulich <jbeulich@...ell.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Roland McGrath <roland@...hat.com>
Subject: Re: Xen & VMI?

Chris Wright wrote:
> I agree that changing the interface to the low-level platform is tricky
> and less isolated.  But how does the VMI protect you from those changes?
> It simply doesn't, the changes are still necessary.  And the inflexibility
> means the tough corner cases swept under the VMI rug are more difficult
> to debug, get right, etc...
>   

I actually disagree here.  Yes, it will change over time.  VMI was 
designed to be extensible and flexible - you can omit implementation for 
any calls you don't require, and with consensus, you can add new flags, 
fields, and calls where you need them.  But VMI as it stands today is 
simply not sufficient to support the hypervisors which are here now.  
There are gaps, particularly with SMP support, which require significant 
changes to either the hypervisors, the kernel, or the VMI itself.  There 
are many reasons these gaps still exist, but most prominently, the big 
reason is that nobody wanted to use a single ABI to interface to the 
hypervisor a year ago when we first proposed the VMI interface as a 
virtualization solution for Linux.  In the end, I see no reason the 
technical issues can't be solved, but the larger questions about the 
future evolution of the interface and also some largely non-technical 
points, valid or not, have stalled the growth which we originally desired.

At this point, the question of whether to pursue a common ABI is no 
longer a technical issue, it's no longer a management or evolutionary 
issue at all.  It's a pragmatic issue about getting code that works into 
Linux today.  It's about working together using what we have as a base, 
which is paravirt-ops, to get working code to users.  We can always 
evolve the code in tree if we find a workable cross-vendor ABI that 
solves everyone's problems.  But that is neither here nor there, because 
it isn't here today.

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