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, 6 Mar 2007 13:35:51 -0800
From:	"Nakajima, Jun" <jun.nakajima@...el.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Anthony Liguori" <anthony@...emonkey.ws>,
	"virtualization" <virtualization@...ts.osdl.org>,
	"Roland McGrath" <roland@...hat.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Jan Beulich" <jbeulich@...ell.com>, <linux-kernel@...r.kernel.org>
Subject: RE: Xen & VMI?

Ingo Molnar wrote:
> * Nakajima, Jun <jun.nakajima@...el.com> wrote:
> 
>> I think a KVM Linux would benefit more from paravirt ops, rather than
>> VMI. The higher-level interface such as the one in Xen, espeically
>> for I/O, interrupt controllers, timer, SMP, etc. actually simplifies
>> the implementation of the VMM, and improve performance of the guest.
>> Even for MMU, direct page tables, for example, would work better for
>> hardware-based virtualization because the processor can use the
>> native page tables.
> 
> maybe we are talking past each other because i dont really disagree
> with that: i mentioned it right at beginning that higher-level APIs
> would have to be added to VMI. What i'd like to avoid is the ABI
> duplication for the lowlevel stuff /and/ for the highlevel stuff.
> Since VMI is mostly about lowlevel stuff right now it's obvious that
> it would have to grow more highlevel ops. Doing an IO driver via IO
> emulation is obviously pretty ... low-tech.
>

I agree with you.
 
> maybe i shouldnt call it 'VMI' but 'the paravirt ABI'. I dont mind if
> it's the Xen ABI or the VMWare ABI or a mesh of the two - everyone can
> map their own internals to that /one/ ABI.

To me it should be handled as 'paravirt devices', 'paravirt chipset',
etc. If we use the standard H/W detection mechanism (such as CPUID, I/O
port, etc.) used by the native kernel, we should be able to extend the
kernel cleanly (or just add device drivers). And the key here is to
define the behavior of such pseudo (or fake) H/W as we do for actual
H/W. Then 'the paravirt ABI' is the set of (high-level) operations for
such fake H/W devices.

> 
> 	Ingo

Jun
---
Intel Open Source Technology Center
-
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/