All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.