From: "H. Peter Anvin" <hpa@zytor.com>
To: Jan Beulich <JBeulich@suse.com>, mingo@elte.hu, tglx@linutronix.de
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH, RFC] x86-64: properly handle FPU code/data selectors
Date: Wed, 16 Oct 2013 08:39:12 -0700 [thread overview]
Message-ID: <525EB320.2000607@zytor.com> (raw)
In-Reply-To: <525E9BFF02000078000FB74E@nat28.tlf.novell.com>
On 10/16/2013 05:00 AM, Jan Beulich wrote:
> Having had reports of certain Windows versions, when put in some
> special driver verification mode, blue-screening due to the FPU state
> having changed across interrupt handler runs (resulting from a host/
> hypervisor side context switch somewhere in the middle of the guest
> interrupt handler execution) on Xen, and assuming that KVM would suffer
> from the same problem, as well as having also noticed (long ago) that
> 32-bit processes don't behave correctly in this regard when run on a
> 64-bit kernel, this is the resulting attempt to port (and suitably
> extend) the Xen side fix to Linux.
>
> The basic idea here is to either use a priori information on the
> intended state layout (in the case of 32-bit processes) or "sense" the
> proper layout (in the case of KVM guests) by inspecting the already
> saved FPU rip/rdp, and reading their actual values in a second save
> operation.
>
> This second save operation could be another [F]XSAVE, but on all
> systems I measured this on using FNSTENV turned out to be the faster
> alternative.
It is not at all clear to me from the description what the flow is that
causes the problem, whatever the problem is. Perhaps it should be if I
wasn't horribly sleep-deprived, but the description should be clear
enough that one should be able to tell the problem at a glance.
Please describe the flow that causes trouble.
Is this basically a problem with the 32-bit version of FXSAVE versus the
64-bit version?
Furthermore, you define X86_FEATURE_NO_FPU_SEL, but you don't set it
anywhere. At least that bit needs to be factored out into a separate patch.
+ if (config_enabled(CONFIG_IA32_EMULATION) &&
+ test_tsk_thread_flag(tsk, TIF_IA32))
is_ia32_task()?
-hpa
next prev parent reply other threads:[~2013-10-16 15:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-16 12:00 [PATCH, RFC] x86-64: properly handle FPU code/data selectors Jan Beulich
2013-10-16 15:19 ` Linus Torvalds
2013-10-16 15:36 ` Jan Beulich
2013-10-16 15:50 ` Linus Torvalds
2013-10-16 16:13 ` Jan Beulich
2013-10-16 18:43 ` Linus Torvalds
2013-10-17 7:09 ` Jan Beulich
2013-10-17 9:27 ` Gleb Natapov
2013-10-17 9:33 ` Jan Beulich
2013-10-17 9:41 ` Gleb Natapov
2013-10-17 9:51 ` Jan Beulich
2013-10-17 10:23 ` Gleb Natapov
2013-10-17 10:37 ` Jan Beulich
2013-10-17 10:39 ` Gleb Natapov
2013-10-16 15:39 ` H. Peter Anvin [this message]
2013-10-16 16:07 ` Jan Beulich
2013-10-16 17:13 ` H. Peter Anvin
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=525EB320.2000607@zytor.com \
--to=hpa@zytor.com \
--cc=JBeulich@suse.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 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.