From: David Vrabel <david.vrabel@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCHv1 3/5] x86/fpu: Add a per-domain field to set the width of FIP/FDP
Date: Fri, 19 Feb 2016 16:38:39 +0000 [thread overview]
Message-ID: <56C7450F.4060909@citrix.com> (raw)
In-Reply-To: <56C73830.3060103@citrix.com>
On 19/02/16 15:43, David Vrabel wrote:
> On 19/02/16 15:14, Jan Beulich wrote:
>>
>> Iirc the issue was with a 64-bit XSAVE having got the selector
>> values stuck in via FNSTENV (forcing word size to 4), and a
>> subsequent XSAVEOPT not further touching the fields
>> (because no change to the FPU state had occurred), leading
>> to (without the code you're deleting) the word size for the
>> restore wrongly getting set to 8, and the selector values then
>> lost. I cannot see how this situation would be handled with
>> this patch in place.
>
> Er, yes. You're right. Sorry.
Would this function be less confusing with something like this?
The resulting code is a lot smaller too (by 163 bytes) and has fewer branches.
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -263,41 +263,24 @@ void xsave(struct vcpu *v, uint64_t mask)
if ( word_size <= 0 || !is_pv_32bit_vcpu(v) )
{
- typeof(ptr->fpu_sse.fip.sel) fcs = ptr->fpu_sse.fip.sel;
- typeof(ptr->fpu_sse.fdp.sel) fds = ptr->fpu_sse.fdp.sel;
+ uint64_t bad_fip;
- if ( cpu_has_xsaveopt || cpu_has_xsaves )
- {
- /*
- * XSAVEOPT/XSAVES may not write the FPU portion even when the
- * respective mask bit is set. For the check further down to work
- * we hence need to put the save image back into the state that
- * it was in right after the previous XSAVEOPT.
- */
- if ( word_size > 0 &&
- (ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] == 4 ||
- ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] == 2) )
- {
- ptr->fpu_sse.fip.sel = 0;
- ptr->fpu_sse.fdp.sel = 0;
- }
- }
+ /*
+ * FIP/FDP may not be written in some cases (e.g., if
+ * XSAVEOPT/XSAVES is used, or on AMD CPUs if an exception
+ * isn't pending).
+ *
+ * To tell if the hardware writes these fields, make the FIP
+ * field non-canonical by flipping the top bit.
+ */
+ bad_fip = ptr->fpu_sse.fip.addr ^= 1 << 63;
XSAVE("0x48,");
- if ( !(mask & ptr->xsave_hdr.xstate_bv & XSTATE_FP) ||
- /*
- * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
- * is pending.
- */
- (!(ptr->fpu_sse.fsw & 0x0080) &&
- boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+ /* FIP/FDP not updated? Restore the old value. */
+ if ( ptr->fpu_sse.fip.addr == bad_fip )
{
- if ( (cpu_has_xsaveopt || cpu_has_xsaves) && word_size > 0 )
- {
- ptr->fpu_sse.fip.sel = fcs;
- ptr->fpu_sse.fdp.sel = fds;
- }
+ ptr->fpu_sse.fip.addr ^= 1 << 63;
return;
}
next prev parent reply other threads:[~2016-02-19 16:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-18 18:52 [RFC PATCH 0/5] x86: workaround inability to fully restore FPU state David Vrabel
2016-02-18 18:52 ` [PATCHv1 1/5] domctl: Add op to get/set generic numeric parameters David Vrabel
2016-02-18 19:02 ` Andrew Cooper
2016-02-19 13:59 ` Jan Beulich
2016-02-18 18:52 ` [PATCHv1 2/5] tools/libxc: add xc_domain_get_param() and xc_domain_set_param() David Vrabel
2016-02-18 19:03 ` Andrew Cooper
2016-02-18 18:52 ` [PATCHv1 3/5] x86/fpu: Add a per-domain field to set the width of FIP/FDP David Vrabel
2016-02-18 19:13 ` Andrew Cooper
2016-02-19 10:03 ` David Vrabel
2016-02-19 14:08 ` Jan Beulich
2016-02-19 14:16 ` David Vrabel
2016-02-19 14:36 ` Jan Beulich
2016-02-19 14:49 ` David Vrabel
2016-02-19 15:14 ` Jan Beulich
2016-02-19 15:43 ` David Vrabel
2016-02-19 16:38 ` David Vrabel [this message]
2016-02-19 17:20 ` Jan Beulich
2016-02-18 18:52 ` [PATCHv1 4/5] x86/viridian: set x87 FIP width to 4 for Windows guests David Vrabel
2016-02-18 19:19 ` Andrew Cooper
2016-02-19 14:11 ` Jan Beulich
2016-02-18 18:52 ` [PATCHv1 5/5] x86/domctl: Add XEN_DOMCTL_PARAM_ARCH_X86_FIP_WIDTH parameter David Vrabel
2016-02-19 10:05 ` David Vrabel
2016-02-19 14:13 ` Jan Beulich
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=56C7450F.4060909@citrix.com \
--to=david.vrabel@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).