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] AMD crash on restore. bug in MTRR restore.4.0.2-rc2-pre

>>> On 27.01.11 at 04:49, "James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:
> By saving the sysenter msrs in my PV drivers before the suspend
> hypercall and restoring them after, save/restore now works fine.
> Does nobody else see a save/restore failure on AMD as a blocker to
> 4.0.2? It it something particular to my exact AMD CPU and OS (Windows
> 2008 x32)?

The 32-bit-ness of your Windows may matter: Looking at
xen/arch/hvm/svm/svm.c, I cannot see how
v->arch.hvm_svm.guest_sysenter_* would ever get set
in this case (given that the intercept for the respective MSRs
gets disabled in svm_update_guest_efer()), yet
svm_vmcb_save() reads this field unconditionally, whereas I
would think v->arch.hvm_svm.vmcb->sysenter_* should be
read/written in that case.

That code seems to go back to c/s 19856, fixing a boot
problem introduced in c/s 19648, which is the one that
removed the reads of the VMCB fields. Christoph?


>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
>> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of James Harper
>> Sent: Thursday, 27 January 2011 13:32
>> To: xen-devel@xxxxxxxxxxxxxxxxxxx 
>> Cc: Tim Deegan
>> Subject: RE: [Xen-devel] AMD crash on restore. bug in MTRR
> restore.4.0.2-rc2-
>> pre
>> Additionally, WinDbg tells me that MSR's 175, and 176 are wiped out by
>> save/restore:
>> immediately before suspend
>> kd> rdmsr 174
>> msr[174] = 00000000`00000008
>> kd> rdmsr 175
>> msr[175] = 00000000`8039e000
>> kd> rdmsr 176
>> msr[176] = 00000000`816a4950
>> immediately after restore
>> kd> rdmsr 174
>> msr[174] = 00000000`00000000
>> kd> rdmsr 175
>> msr[175] = 00000000`00000000
>> kd> rdmsr 176
>> msr[176] = 00000000`00000000
>> although you're never too sure with WinDbg...
>> James

Xen-devel mailing list