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] Fix checked builds of Windows on AMD processors

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Fix checked builds of Windows on AMD processors
From: Steven Smith <steven.smith@xxxxxxxxxx>
Date: Tue, 11 Aug 2009 16:00:51 +0100
Delivery-date: Tue, 11 Aug 2009 08:01:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Checked builds of Windows (2003 at least; I haven't tried anything
else) don't currently work on Xen running on AMD processors, because
they assert that the task priority sub-class in the TPR is correctly
preserved, and Xen doesn't do that.  The attached patch makes it do
so.  This was enough to make a checked build boot on my test box, but
hasn't had any more testing beyond that.

Applies cleanly to 20048:e35a1c004fc2 of xen-unstable.hg.

Checked builds of Windows will, after every modification of the TPR,
read it back again and assert that the value read back matches with
the value written, including the priority sub-class.  Make sure that
we correctly preserve it on vmexit.

As far as I can tell from reading the documentation, the sub-class
doesn't actually do anything, so this should be pretty harmless.

Signed-off-by: Steven Smith <steven.smith@xxxxxxxxxxxxx>

diff -r e35a1c004fc2 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c        Tue Aug 11 07:36:26 2009 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c        Tue Aug 11 15:45:14 2009 +0100
@@ -1307,8 +1307,12 @@ asmlinkage void svm_vmexit_handler(struc
      * SVM's vTPR. It's OK if the guest doesn't touch CR8 (e.g. 32-bit Windows)
      * because we update the vTPR on MMIO writes to the TPR.
+    /* Careful: you need to preserve the low bits of the TPR in order
+     * to make checked builds of Windows work, even though they don't
+     * actually do anything. */
     vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI,
-                   (vmcb->vintr.fields.tpr & 0x0F) << 4);
+                   ((vmcb->vintr.fields.tpr & 0x0F) << 4) |
+                   (vlapic_get_reg(APIC_TASKPRI) & 0x0F));
     exit_reason = vmcb->exitcode;

Attachment: signature.asc
Description: Digital signature

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Fix checked builds of Windows on AMD processors, Steven Smith <=