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-devel] [patch 0/2] Fix rawhide FV booting on VMX

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [patch 0/2] Fix rawhide FV booting on VMX
From: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Date: Tue, 22 May 2007 16:38:12 +0100
Delivery-date: Tue, 22 May 2007 08:36:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi all,

The following two patches --- one to the HV, one to the tools --- allow
current rawhide/FC7 iso images to boot under Xen full virtualisation on

The bug is due to Xen's insanely convoluted way of dealing with 16-bit
code on Intel VMX.  The vmxassist layer needs to be able to respond to
CPU traps properly.  To be able to distinguish between traps being sent
to the vmxassist, and interrupts being delivered to the 16-bit code
being sub-emulated, it remaps the 16-bit guest's IRQs to generate
different interrupt numbers.  This is really really ugly --- whenever
the 16-bit guest performs IO to the (virtual) PIC, vmxassist watches to
see if it's a request to reprogram the PIC interrupt vector; and if so,
rewrites the outb so that the PIC vector is 32 (master PIC) or 40 (slave
PIC). vmxassist then installs 32-bit trap handlers at those offsets in
the IDT, and those handlers bounce the interrupt back into 16-bit mode
at the appropriate vector for the guest (which is *FORCED* to be 8
(master) or 0x70 (slave), the int handlers which the hvmloader rombios
sets up.)

All of this works (barely) while we're in 16-bit mode.  But when the
bootloader transitions into 32-bit mode, vmxassist gracefully steps out
of the way, but the guest's PIC vectors still point to the vmxassist
interrupts (32/40), not the rombios ones (8/0x70).  So if an interrupt
is delivered in this state, it triggers the wrong trap in the guest.

Now, the FC7 iso boot loader has a 32-bit graphical menu module loaded
by syslinux.  That 32-bit code installs interrupt traps to bounce all
received interrupts back down to 16-bit mode.  So it relies heavily on
the PIC vectors set up by 16-bit mode still being valid while in 32-bit

vmxassist can't really fix this on its own.  The only way to reprogram
the guest's virtual PIC is to reinitialise the vPIC, but doing so throws
away all sorts of important vPIC state (some of it recoverable, like the
initialisation modes; some of it not recoverable, such as edge-trigger

So the fix here is to first of all extend the virtual PIC provided by
the hypervisor, supporting a new 2-byte control sequence which lets the
guests change the interrupt vectors _without_ fully reinitialising the
vPIC; and secondly to have vmxassist use that sequence to reset the vPIC
vectors appropriately whenever we transition between 16 and 32-bit mode.

This has been verified to allow rawhide installs to proceed under Xen

Points for discussion:

* Do we need/want vmxassist to fail gracefully if the enhanced vPIC
sequence is not available?
* Is the magic sequence used here (0xff written to ICW1) genuinely
impossible for other guests to use? (see patch 1/2 to follow.)


Xen-devel mailing list