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


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

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their interrupt vector reprogrammed
From: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Date: Thu, 31 May 2007 21:35:35 +0100
Cc: Stephen Tweedie <sct@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 31 May 2007 13:33:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C27C6C7C.F7F9%keir@xxxxxxxxxxxxx>
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
References: <C27C6C7C.F7F9%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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.


--- 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;
@@ -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;
Xen-devel mailing list