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: Keir Fraser <keir@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH][SVM] Fix 32bit Windows guest VMs save/restore
From: Wei Huang <wei.huang2@xxxxxxx>
Date: Mon, 31 Jan 2011 15:38:38 -0600
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "james.harper@xxxxxxxxxxxxxxxx" <james.harper@xxxxxxxxxxxxxxxx>
Delivery-date: Mon, 31 Jan 2011 13:40:55 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C96CE488.165C9%keir@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>
References: <C96CE488.165C9%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20101207 Thunderbird/3.1.7
Hi Keir,

My comments inline below.

On 01/31/2011 03:13 PM, Keir Fraser wrote:
On 31/01/2011 18:33, "Wei Huang"<wei.huang2@xxxxxxx>  wrote:

The attached patch fixes the save/restore issue seen with 32bit Windows
guest VMs. The root cause is that current Xen doesn't intercept
SYSENTER-related MSRs for 32bit guest VMs. As a result, the
guest_sysenter_xxx fields contain incorrect values and shouldn't be used
for save/restore. This patch checks the LMA bit of EFER register in the
save/restore code path.

Please apply it to both Xen-4.0 and Xen-unstable trees.

Reported-by: James Harper<james.harper@xxxxxxxxxxxxxxxx>
Signed-off-by: Wei Huang<wei.huang2@xxxxxxx>
Acked-by: Christoph Egger<christoph.egger@xxxxxxx>
Nacked-by: Keir Fraser<keir@xxxxxxx>

This handling of the SYSENTER MSRs is overly complicated. I suggest
reverting a bunch of the original handling of cross-vendor migration as
  * 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. Did you actually mean "* Always intercept the SYSENTER MSRs" here?
  * 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 mailing list

Xen-devel mailing list