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

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

Hi,

On Fri, 2007-05-25 at 10:35 +0100, Keir Fraser wrote:

> Would it be possible to hack this PIC transition code into
> vmx_world_{save,restore}? This would restrict the changes to code that will
> obviously be killed off when vmxassist is removed, and might perhaps be
> simpler and faster than making the changes via specialised pokes of the PIC
> device from vmxassist itself?

This turned out to be trivial to do.  I was just stalled for a while in
testing it since it uncovered another regression --- Xen FV seems to
have problem with the latest dynticks patches from FC7 kernels. 

The new patch is much simpler; at the same time it's uglier in that it's
an (even more) gross layering violation.  

vmxassist does the rewriting of the guests vPIC vectors, so the HV
*cannot* have any idea what vectors the guest actually intended to write
when we go back to 32-bit mode.  However, vmxassist already hard-codes
the vectors in several places: the 16-bit irq_bases are hard-coded to
0x08 and 0x70 in the trap bouncing code, and those bounce traps are
hard-coded to live at 0x20 and 0x28.  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.

--Stephen


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