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.
Steven.
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;
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home