Subject: RE: [RFC, PATCH 5/24] i386 Vmi code patching
Date: Wed, 22 Mar 2006 18:41:06 -0500
MIME-Version: 1.0
To: arai@vmware.com, zach@vmware.com
Cc: xen-devel@lists.xensource.com, wim.coekaerts@oracle.com, chrisw@osdl.org,
       chrisl@vmware.com, jbeulich@novell.com, chrisw@sous-sol.org,
       virtualization@lists.osdl.org, torvalds@osdl.org, anne@vmware.com,
       jreddy@vmware.com, kmacy@fsmware.com, ksrinivasan@novell.com,
       leendert@watson.ibm.com, linux-kernel@vger.kernel.org
From: Volkmar Uhlig <vuhlig@us.ibm.com>
Message-ID: <OF6C9205F6.79606CB4-ON05257139.0080D734@us.ibm.com>
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2128
Lines: 44

> -----Original Message-----
> From: arai@vmware.com
> Sent: Wednesday, March 22, 2006 5:34 PM
>
> > The idea of in-tree ROM code doesn't make sense.  The entire point
> > of this layer of code is that it is modular, and specific to the
> > hypervisor, not the kernel.  Once you lift the shroud and combine
> > the two layers, you have lost all of the benefit that it was
> > supposed to provide.
> 
> To elaborate a bit more, the "ROM" layer is "published" by 
> the hypervisor.  This layer of abstraction will let you take 
> a VMI-compiled kernel and run it efficiently on any 
> hypervisor that exports a VMI interface - even one that you 
> didn't know about (or didn't exist) when you compiled your kernel.
> 
> [...]
> 
> Going forward, having the ROM layer published by the 
> hypervisor gives the hypervisor more flexibility than having 
> the code statically compiled into the kernel.  Consider when 
> hardware virtualization becomes more prevalent.  Perhaps 
> there are places where today hypercalls make sense, but with 
> hardware virtualization, you'd rather have the hardware just 
> take care of it.  CPUID is the only example I can come up 
> with at the moment, but there are certainly others.  VMI lets 
> the hypervisor decide that it doesn't actually need to 
> replace the CPUID instruction with a hypercall.  The 
> important factor here is that only the hypervisor, not the 
> kernel, knows about these performance tradeoffs.  

Very obvious other candidates are the shadowed system state registers
(cli, sti, CRx) provided by VT and the shadow page-table support as
defined by Pacifica.  In particular since these features are dependent on
the specific processor revision a hard-coded binary interface doesn't do
any good.  The ROM pretty much resembles Linux' system call interface as
provided today optimizing for the specific HW architecture.

- Volkmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/