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 1/2] HV: allow HVM virtual PICs to have their interru

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [patch 1/2] HV: allow HVM virtual PICs to have their interrupt vector reprogrammed
From: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Date: Tue, 22 May 2007 16:42:33 +0100
Delivery-date: Tue, 22 May 2007 08:40:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1179848292.8438.40.camel@xxxxxxxxxxxxxxxxxxxxx>
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: <1179848292.8438.40.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

> 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

And this is the patch for that.  The new control sequence is:

Write 0xff to ICW1: this is an otherwise unused value, since it has bit
4 set (ie. it's an initialisation register write), and yet bits 5--7 are
also set (only valid for MCS-80 mode, which the Xen vPIC doesn't emulate
at all.)  This sets the PIC to expect ICW2 to follow, just as ICW1
usually does, except that it does not reset the PIC internal state.

Write the new vector to ICW2: completes the initialisation sequence.
This the same as a normal ICW2 write, except that it does not expect to
be followed by the usual ICW3/ICW4 writes.

Note that the flag used to indicate this "special" ICW1 write is shared
between the two vPICs (master and slave), so it is not legal for the
guest to write 0xff to both master/slave ICW1 before following up with
the ICW2 writes.  But since the only software that will use this is the
modified vmxassist, that's OK.


--- xen-3.1.0-rc7-7041b52471c3/xen/arch/x86/hvm/vpic.c.~1~      2007-05-03 
17:49:31.000000000 +0100
+++ xen-3.1.0-rc7-7041b52471c3/xen/arch/x86/hvm/vpic.c  2007-05-22 
14:25:05.000000000 +0100
@@ -178,13 +178,23 @@ static void vpic_ioport_write(struct hvm
     int priority, cmd, irq;
     uint8_t mask;
+    static int custom_revector_flag = 0;
     addr &= 1;
     if ( addr == 0 )
-        if ( val & 0x10 )
+       if ( val == 0xff ) {
+           /* Extension to the PIC: lets us rewrite the icw2 vector
+            * without fully reinitialising the PIC, used by vmxassist
+            * to preserve icw2 vector translations across transitions
+            * into and back out of 32-bit mode.
+            */
+           vpic->init_state = 1;
+           custom_revector_flag = 1;
+       }
+        else if ( val & 0x10 )
             /* ICW1 */
             /* Clear edge-sensing logic. */
@@ -268,6 +278,10 @@ static void vpic_ioport_write(struct hvm
             /* ICW2 */
             vpic->irq_base = val & 0xf8;
+           if (custom_revector_flag) {
+               custom_revector_flag = 0;
+               vpic->init_state = 0;
+           }
             if ( !(vpic->init_state & 8) )
                 break; /* CASCADE mode: wait for write to ICW3. */
             /* SNGL mode: fall through (no ICW3). */
Xen-devel mailing list