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] [PATCH][SVM] Fix 32bit Windows guest VMs save/restore

To: Wei Huang <wei.huang2@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH][SVM] Fix 32bit Windows guest VMs save/restore
From: Keir Fraser <keir@xxxxxxx>
Date: Tue, 01 Feb 2011 07:14:07 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "james.harper@xxxxxxxxxxxxxxxx" <james.harper@xxxxxxxxxxxxxxxx>
Delivery-date: Mon, 31 Jan 2011 22:15:10 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:user-agent:date:subject:from:to:cc :message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=AJnwKxxblkCoGFCF0oMvlw6B+92PZZAWLeSwLo8RYVo=; b=JQVnklNwgz9eVmmjlTJV5y1pyYTWgrTDLZMOEwbl3Lw/nhTsXwn/yK4w2pDRobriBj VCnmyZCHUIL0MfiUsPFYvSHR5FtNM/LUCAI+cTjq2Xi+uNgTqgYZ3zfvBqZFJgbSl6Yb SVTqFklnz/j2a6B24yf2M81u+VY+Z47KgzJVk=
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=FTKsUkZSvGzcJ0U5XHT7QxE2+vqmuQTtAVVK+sRbl2GAdgiJSr50F0M3YVonPAE65F O1iUWjws25XCwjPL+EkcKKzFS/7c8u19fbVedEe2JsB0j1x0JOs8MLexYM/kKgBcrnRs 5BkJ9fHA0Fz0v+C4FTbXzwISkhAoIuA3heauc=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D472BDE.8040101@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcvB1zt3sLkxz/Pa2kOotUXCfF8pUw==
Thread-topic: [Xen-devel] [PATCH][SVM] Fix 32bit Windows guest VMs save/restore
User-agent: Microsoft-Entourage/
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.


> 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