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: <45ED2E63.3070700@vmware.com>
Date:	Tue, 06 Mar 2007 01:03:31 -0800
From:	Zachary Amsden <zach@...are.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Gerd Hoffmann <kraxel@...e.de>,
	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?

Ingo Molnar wrote:
>>> there are already 5 major hypervisors we are going to support (in 
>>> alphabetical order):
>>>
>>>  - KVM
>>>  - lguest
>>>  - Windows
>>>  - VMWare
>>>  - Xen
>>>
>>> the QA matrix is gonna be a _mess_.
>>>       
>> I fail to see how xen-via-vmirom instead of xen-via-paravirt_ops 
>> reduces the QA effort.  You still have 5 Hypervisors you have to test 
>> against.
>>     
>
> yes, just like we have thousands of separate PC boards to support. But 
> as long as the basic ABI is the same, the QA effort on the Linux kernel 
> side is alot more focused. (Distros still have 18446744073709551616 
> total combinations to QA, and have to make an educated guess to reduce 
> that to a more manageable number.)
>   

But hardware PC boards don't do anything as remotely complicate as 
changing the semantics required for correctness in you MMU 
implementation.  There might be some weird MTRR and caching things, 
which are a property of the architecture, and which all modern boards 
have in common.  You don't have completely diverse implementation 
properties like shadow vs direct vs native page tables.  Or hardware 
virtualization vs direct CPL raised execution.  You simply can't test 
this diversity by making an educated guess, because in this case, 
something will always be omitted.  The test matrix has to be raised, and 
if that is a problem, the burden of proper testing shifted onto the 
manufacturers, just as you would with some new PC board or new 
architecture that wanted to be Linux friendly but was radically 
different in some way.

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/