[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their interrupt vector reprogrammed
Hi, 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. --Stephen 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; } break; @@ -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; } break; _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |