RE: [Xen-devel] [patch] Fix 64bit VMX guest crashing SMP x86_64 dom0

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
>Sent: Saturday, February 18, 2006 12:35 AM
>To: Li, Xin B
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] [patch] Fix 64bit VMX guest crashing 
>SMP x86_64 dom0
>
>
>On 17 Feb 2006, at 14:43, Li, Xin B wrote:
>
>> Fix 64bit VMX guest crashing SMP x86_64 dom0.
>> We found creating 64bit VMX guest on SMP x86_64 dom0 will crash the
>> system, and this is introduced when merging with the HVM tree.
>>
>> Signed-off-by: Yunhong Jiang <yunhong.jiang@xxxxxxxxx>
>> Signed-off-by: Xin Li <xin.b.li@xxxxxxxxx>
>
>I've applied a more extensive patch that moves the calls to 
>hvm_load_msrs/hvm_restore_msrs into __context_switch(). Hopefully it 
>isn't broken! :-)  The changeset is 8871.

Yes, it works well :)

>Looking at that area of the code, I wonder whether HVM guests need to 
>be calling save_segments() at all, since segment info is automatically 
>saved into the VMCS on vmexit? Even the hvm_save_segments() call seems 
>unnecessary -- all it does is save the contents of the SHADOW_GS MSR, 
>but you keep a shadow copy of that MSR which you update every time the 
>guest writes to the MSR, so surely that is not necessary? Can you try 
>testing x86_64 with the call to save_segments() made conditional on 
>!HVM_DOMAIN(p)?

For SHADOW_GS MSR, it need to be kept for swapgs, which may change the
SHADOW GS MSR without causing vmexit. So we have to save the SHADOW_GS
MSR  on each context_switch.

Agree with you that HVM domain need not save_segments(), we try it on
x86_64 and it works.
Attached is the patch
        Signed-off-by: Yunhong Jiang <yunhong.jiang@xxxxxxxxx>
        Signed-off-by: Xin Li <xin.b.li@xxxxxxxxx>

Thanks
Yunhong Jiang

>
>  Thanks,
>  Keir
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
>

Attachment: msr.diff
Description: msr.diff

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