[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH][SVM] Fix 32bit Windows guest VMs save/restore


  • To: <wei.huang2@xxxxxxx>
  • From: Keir Fraser <keir@xxxxxxx>
  • Date: Tue, 01 Feb 2011 09:14:49 +0100
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 01 Feb 2011 00:17:42 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=xSXedcqsDutmDFjHuAD45uhGZOw0dIMPKuU7JDI9TpVbgdgsIXhTdbKU/Hgs88j7e/ mei1sONXxjEO339zJL2T7cPH0qmUzwyfFKSi4uKrez87OwjgopVEnIXbKfXkRHqXJm0g q6dHJhMVmoaqBBzhj6T6BGOifi/2IvtTPOMh4=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcvB6BgIpzOidV8i4EK1UsVo1nWZBA==
  • Thread-topic: [Xen-devel] [PATCH][SVM] Fix 32bit Windows guest VMs save/restore

On 01/02/2011 07:25, "Wei Huang" <wei.huang2@xxxxxxx> wrote:

> But there is another issue: upper 32bit of sysenter MSRs in VMCB save
> area will be truncated with VMSARE/VMEXIT (see comments in vmcb.h).
> Could we use these VMCB fields as a storage for 64bit MSRs?

Is that a bug? Seems unfortunate and unnecessary.

Well, in that case I would suggest to *always* intercept the MSRs, keep the
vcpu-structure fields, and in svm_msr_write_intercept(MSR_IA32_SYSENTER_*)
update vcpu structure *and* do svm_sync_vmcb(); update vmcb; svm_vmload().

This keeps the canonical version of the msrs always in the vcpu structure,
with a (possibly 32-bit truncated) copy in the vmcb. The truncation is safe
since the MSRs will only directly be used in guest mode by legacy-mode
execution of SYSENTER.

How's that?

 -- Keir

> Thanks,
> -Wei
> 
> On Tue, 2011-02-01 at 00:14 -0600, Keir Fraser wrote:
>> On 31/01/2011 22:38, "Wei Huang" <wei.huang2@xxxxxxx> wrote:
>> 
>>>> This handling of the SYSENTER MSRs is overly complicated. I suggest
>>>> reverting a bunch of the original handling of cross-vendor migration as
>>>> follows:
>>>>   * Never intercept the SYSENTER MSRs.
>>> The reason for Christoph to create this patch is AMD doesn't support
>>> SYSENTER in long mode.
>> 
>> Yes.
>> 
>>> If we don't intercept MSRs under long mode, we
>>> will get stuck with #UD after migration from Intel platform.
>> 
>> It's the SYSENTER instruction that causes the UD, right, not the WRMSR
>> writes to the SYSENTER MSRs? Then my described approach will work -- the
>> SYSENTER instruction will be handled by Xen's x86_emulate(), calling out to
>> svm_msr_read_intercept() to grab the SYSENTER MSR values (from the VMCB, as
>> I described). In fact x86_emulate() handles WRMSR too, so even if WRMSR
>> caused UD we'd still handle it.
>> 
>>> Did you 
>>> actually mean "* Always intercept the SYSENTER MSRs" here?
>> 
>> No, I think my approach works as I described it.
>> 
>>  -- Keir
>> 
>>>>   * Remove the vcpu->arch.hvm_svm.guest_sysenter_* fields.
>>>>   * Always hvm save/restore from/to the values in the vmcb.
>>>>   * Modify svm_msr_read_intercept(MSR_IA32_SYSENTER_*) to svm_sync_vmcb()
>>>> and
>>>> then read the sysenter msr value from vmcb
>>>>   * Modify svm_msr_write_intercept(MSR_IA32_SYSENTER_*) to svm_sync_vmcb(),
>>>> then modify the sysenter msr in the vmcb, and then svm_vmload().
>>>> 
>>>> Result is that we get rid of some redundant fields from the vcpu structure
>>>> and have one canonical place we always keep the sysenter msr values, in the
>>>> vmcb. The extra cost in the msr read/write functions is totally
>>>> inconsequential, and only used after guest migration from an Intel CPU
>>>> anyway. Hardly something to optimise for.
>>>> 
>>>>   -- Keir
>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>> http://lists.xensource.com/xen-devel
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>> http://lists.xensource.com/xen-devel
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>> 
> 
> 
> 



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.