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 08:42:32 -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:
> i think you are missing my point.
>
> paravirt_ops is a Linux-internal abstraction that tries to make our life 
> easier but it has no relevance whatsoever to an external hypervisor - be 
> that Xen, VMWare/ESX or Windows/Longhorn.
>   

Of course it has relevance.  Linux is an important guest system, and not
supporting it would be a major problem.  I already have a list of things
which need to be done to Xen to make it work better with current kernels
- none of them mandatory, but nice to have.

> 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

That's assuming all the parties involved are approaching the process
with goodwill.  If someone wanted to effectively stall the kernel's
development (at least in terms of useful kernels that people can keep
shipping and deploying), then all they have to do is drag their heels on
this "VMI" interface process.  All this heavyweight process is very
enterprisy, but it doesn't help Linux at all.

And given that the idea of multiple implementations of a complex ABI
like this will actually conform to a spec and/or each other is pretty
much pie-in-the-sky, the kernel will still have to deal with all the
quirks of multiple implementations anyway.

    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/