From: Wei Huang <wei.huang2@amd.com>
To: Keir Fraser <keir@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH][SVM] Fix 32bit Windows guest VMs save/restore
Date: Tue, 1 Feb 2011 00:25:51 -0600 [thread overview]
Message-ID: <1296541551.2172.13.camel@weilaptop> (raw)
In-Reply-To: <C96D633F.16615%keir@xen.org>
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?
Thanks,
-Wei
On Tue, 2011-02-01 at 00:14 -0600, Keir Fraser wrote:
> On 31/01/2011 22:38, "Wei Huang" <wei.huang2@amd.com> 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@lists.xensource.com
> >>> http://lists.xensource.com/xen-devel
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >>
> >
> >
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
next prev parent reply other threads:[~2011-02-01 6:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-31 17:33 [PATCH][SVM] Fix 32bit Windows guest VMs save/restore Wei Huang
2011-01-31 21:13 ` Keir Fraser
2011-01-31 21:17 ` Keir Fraser
2011-01-31 21:43 ` Wei Huang
2011-01-31 21:38 ` Wei Huang
2011-02-01 6:14 ` Keir Fraser
2011-02-01 6:25 ` Wei Huang [this message]
2011-02-01 8:14 ` Keir Fraser
2011-02-01 21:06 ` Wei Huang
2011-02-01 22:35 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1296541551.2172.13.camel@weilaptop \
--to=wei.huang2@amd.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.