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/
Home Products Support Community News


Re: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their int

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their interrupt vector reprogrammed
From: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Date: Thu, 31 May 2007 21:41:02 +0100
Cc: Stephen Tweedie <sct@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 31 May 2007 13:39:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1180643735.6497.25.camel@xxxxxxxxxxxxxxxxxxxxx>
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>
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
References: <C27C6C7C.F7F9%keir@xxxxxxxxxxxxx> <1180643735.6497.25.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Thu, 2007-05-31 at 21:35 +0100, Stephen C. Tweedie wrote:

> If we are willing to extend that
> hard-coding into the hypervisor (but JUST the existing vmxassist-
> specific portion, not the general vPIC code), then the patch reduces to
> just a few lines, as below.

Reposted, this time complete with commit header and signed-off-by.

Fix boot loader hangs with syslinux's 32-bit vesamenu module.

Syslinux can load 32-bit UI code for menu handling.  But the core of
syslinux is still 16-bit.  When it jumps to this 32-bit code, it
installs a set of 32-bit interrupt trap handlers which just bounce the
interrupts back to 16-bit mode.

But this plays badly with vmxassist.  When running 16-bit boot loader
code, vmxassist installs its own trap handlers which bounce vPIC
interrupts back down to 16-bit mode.  The trap handlers live at int0x20
to 0x2f, so when the 16-bit code tries to reprogram the vPIC, vm86
rewrites the outb()s on the fly to set the irq_base vectors accordingly.

So when syslinux enters 32-bit mode, the vPIC has still been programmed
to point to vmxassist's bounce traps, even though vmxassist is no longer
active once the guest is running 32-bit code.  So the wrong interrupts
get delivered to the guest.

Fix this by restoring the rombios vPIC irq_base vectors when we leave
vmxassist mode, and returning the vmxassist traps when we reenter it.
These irq base values are hard-coded in this patch, but they are already
hard-coded in vmxassist so any boot code that relies on changing them
will already fail.

Signed-off-by: Stephen Tweedie <sct@xxxxxxxxxx>

--- xen/arch/x86/hvm/vmx/vmx.c.~2~      2007-05-03 17:49:31.000000000 +0100
+++ xen/arch/x86/hvm/vmx/vmx.c  2007-05-31 20:48:58.000000000 +0100
@@ -1914,6 +1914,20 @@ static int vmx_assist(struct vcpu *v, in
             if ( vmx_world_restore(v, &c) != 0 )
                 goto error;
             v->arch.hvm_vmx.vmxassist_enabled = 1;
+            /* 
+             * The 32-bit vmxassist vm86.c support code is hard-coded to
+             * expect vPIC interrupts to arrive at interrupt traps 0x20
+             * and 0x28.  It bounces these to 16-bit boot code offset
+             * from traps 0x08 and 0x70.  But when the guest transitions
+             * to true native 32-bit mode, vmxassist steps out of the
+             * way and no such bouncing occurs; so we need to rewrite
+             * the vPIC irq base to point direcetly to 0x08/0x70 (see
+             * code just below).  So on re-entering 16-bit mode, we need
+             * to reset the vPICs to go back to the 0x20/0x28 bounce
+             * traps.
+             */
+            v->domain->arch.hvm_domain.vpic[0].irq_base = 0x20;
+            v->domain->arch.hvm_domain.vpic[1].irq_base = 0x28;
             return 1;
@@ -1932,6 +1946,11 @@ static int vmx_assist(struct vcpu *v, in
             if ( vmx_world_restore(v, &c) != 0 )
                 goto error;
             v->arch.hvm_vmx.vmxassist_enabled = 0;
+            /* See comment above about vmxassist 16/32-bit vPIC
+             * behaviour.  The irq_base values are hard-coded into
+             * vmxassist vm86.c. */
+            v->domain->arch.hvm_domain.vpic[0].irq_base = 0x08;
+            v->domain->arch.hvm_domain.vpic[1].irq_base = 0x70;
             return 1;
Xen-devel mailing list