[Xen-devel] [patch 0/2] Fix rawhide FV booting on VMX

["Stephen C. Tweedie" <sct@xxxxxxxxxx>]

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
VMX.

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
mode.

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
latches.)

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
FV.  

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.)

--Stephen



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