[Xen-changelog] [xen-unstable] x86 svm: Fix checked builds of Windows running on AMD SVM

[Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User Keir Fraser <keir.fraser@xxxxxxxxxx>
# Date 1250082361 -3600
# Node ID f1dbddb69cc67078ec6e65302a56a9145dbea74b
# Parent  e35a1c004fc22ba4a38e0ea53c272f89b0256c51
x86 svm: Fix checked builds of Windows running on AMD SVM

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>
---
 xen/arch/x86/hvm/svm/svm.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletion(-)

diff -r e35a1c004fc2 -r f1dbddb69cc6 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        Wed Aug 12 14:06:01 2009 +0100
@@ -1306,9 +1306,12 @@ asmlinkage void svm_vmexit_handler(struc
      * Before doing anything else, we need to sync up the VLAPIC's TPR with
      * 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.
+     * NB. We need to preserve the low bits of the TPR 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;
 

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog