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]

Date:	Tue, 06 Mar 2007 10:04:35 -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:
> * Jeremy Fitzhardinge <jeremy@...p.org> wrote:
>
>   
>>> My suggestion would be for Linux to make only a /single/ external 
>>> ABI promise: VMI. (and we can extend it with higher-level paravirt 
>>> ops, etc.)
>>>       
>> "VMI" is not a promise, it's just three letters.  It doesn't even mean 
>> the same thing now as it did 12 months ago.  Turning "VMI" from three 
>> letters into anything remotely like a promise is a huge amount of work 
>> which requires:
>>
>>    1. someone actually sit down and fully document what all those
>>       entrypoints are going to do
>>    2. everyone to implement them
>>    3. someone to test that all the implementations conform to the
>>       document (bearing in mind that if anyone is going to go to all
>>       this effort, they're going to use this with non-Linux guests)
>>    4. and repeat all that every subsequent update
>>     
>
> There's no process needed. The only thing needed is to treat the Linux 
> implementation as the reference design, documentation and specification. 
>   
What Linux implementation?  Linux as a client of this interface?  So
everyone implements as much of the ABI as needed to get Linux to boot?

We have an excellent example of how well that model works.  Thousands of
BIOS implementations all implementing just enough of the various BIOS
interfaces to get Windows to boot.  And then all fall over as soon as
you try to be non-Windows, or even a later version of Windows.  It's the
path to being absolutely inundated with legacy crap.

You're arguing that we should have a single hypervisor ABI in order to,
among other things, reduce the test matrix, and yet the ABI is entirely
defined by testing to see how well a given implementation runs some
random version of Linux.  And if Linux wants to use that interface in a
different way, everyone is supposed to magically keep up.

And all this is supposed to be managed by multiple disparate independent
out-of-tree implementations?

Yep, I want a pony too.

> Treat it as we treat the Linux system calls. We promise not to change 
> them.

OK.  How does that help with "not hindering Linux's development"?

    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/