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


[Xen-changelog] [xen-unstable] Fix boot loader hangs with syslinux's 32-

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-unstable] Fix boot loader hangs with syslinux's 32-bit vesamenu module.
From: Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 11 Jun 2007 02:22:11 -0700
Delivery-date: Mon, 11 Jun 2007 02:23:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User kfraser@xxxxxxxxxxxxxxxxxxxxx
# Date 1180967531 -3600
# Node ID 5710c94e65394daadafd7a6780450e01a26bf32d
# Parent  d0dc12484bf2e1a7397e6ea4bcfeb6ef118494ac
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
int 0x20 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

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 |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+)

diff -r d0dc12484bf2 -r 5710c94e6539 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c        Mon Jun 04 15:21:12 2007 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c        Mon Jun 04 15:32:11 2007 +0100
@@ -2002,6 +2002,19 @@ 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-0x27
+             * and 0x28-0x2f.  It bounces these to 16-bit boot code traps
+             * 0x08-0x0f and 0x70-0x77.  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 directly 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;
@@ -2020,6 +2033,12 @@ 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-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-unstable] Fix boot loader hangs with syslinux's 32-bit vesamenu module., Xen patchbot-unstable <=