WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching

To: Chuck Ebbert <76306.1226@xxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching
From: Zachary Amsden <zach@xxxxxxxxxx>
Date: Mon, 27 Mar 2006 17:48:54 -0800
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization <virtualization@xxxxxxxxxxxxxx>
Delivery-date: Tue, 28 Mar 2006 01:52:24 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200603271955_MC3-1-BBB1-E3F1@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200603271955_MC3-1-BBB1-E3F1@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (X11/20051201)
Chuck Ebbert wrote:
In-Reply-To: <200603222115.46926.ak@xxxxxxx>

On Wed, 22 Mar 2006 21:15:44 +0100, Andi Kleen wrote:

On Monday 13 March 2006 19:02, Zachary Amsden wrote:
The VMI ROM detection and code patching mechanism is illustrated in
setup.c.  There ROM is a binary block published by the hypervisor, and
and there are certainly implications of this.  ROMs certainly have a
history of being proprietary, very differently licensed pieces of
software, and mostly under non-free licenses.  Before jumping to the
conclusion that this is a bad thing, let us consider more carefully
why hiding the interface layer to the hypervisor is actually a good
thing.
How about you fix all these issues you describe here first and then submit it again?

The disassembly stuff indeed doesn't look like something
that belongs in the kernel.

I think they put the disassembler in there as a joke. ;)

It's not necessary for fixing up the call site, anyway. Something like
this should work, assuming there is always a call in every vmi
translation.

Very good observation. The code you illustrate is roughly what the patch mechanism used to do. The disassembly serves one purpose, which is incomplete in our current implementation. It provides live register information and constant propagation that can be used by an inliner in the VMI layer to inline hypervisor calls. This information gets encoded naturally in the push sequence before the call instruction.

But considering it is currently incomplete, and most of the benefit can be had be special casing just 4 VMI calls to allow selective inlining, it does seem like a lot of complexity for little payoff. I really don't like special casing, but in this scenario, it does seem to make sense. And of the 4 VMI calls, only one (SetInterruptMask) takes an input, and it takes that input in a fixed register.

Based on suggestions from Anthony Liguori and others, we are going to drop this extra complexity - we can get to hypervisor inlining later. Right now having the simplest and cleanest interface is more important. Actually, adding the required padding for inlining is quite easy:

#define FILL(n) ".fill " #n "-1,1,0x66; nop"

static inline void local_irq_restore(const unsigned long flags)
{
       vmi_wrap_call(
               SetInterruptMask, "pushl %0; popfl"  FILL(6),
               VMI_NO_OUTPUT,
               1, VMI_IREG1 (flags),
               XCONC("cc", "memory"));
}

Now you have 8 bytes to overwrite, which is sufficient for byte arithmetic operations to a memory address, plus a segment override. This seems like a much simpler solution than run-time disassembly.

-                               /*
-                                * Don't printk - it may acquire spinlocks with
-                                * partially completed VMI translations, causing
-                                * nuclear meltdown of the core.
-                                */
-                               BUG();
-                               return;
-               }
-       }

This part was a joke  ;)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>