[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070306203712.GC21736@elte.hu>
Date: Tue, 6 Mar 2007 21:37:12 +0100
From: Ingo Molnar <mingo@...e.hu>
To: "Nakajima, Jun" <jun.nakajima@...el.com>
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?
* 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.
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.
Ingo
-
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/
Powered by blists - more mailing lists