All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Dave Hansen <dave.hansen@linux.intel.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Andrew Lutomirski <luto@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>
Subject: Re: Lazy FPU restoration / moving kernel_fpu_end() to context switch
Date: Fri, 15 Jun 2018 16:56:58 -0400	[thread overview]
Message-ID: <1529096218.7898.158.camel@surriel.com> (raw)
In-Reply-To: <7e415c4d-415b-0ff6-5488-1681e522d2dc@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

On Fri, 2018-06-15 at 13:42 -0700, Dave Hansen wrote:
> On 06/15/2018 01:33 PM, Jason A. Donenfeld wrote:
> > On Fri, Jun 15, 2018 at 8:32 PM Andy Lutomirski <luto@kernel.org>
> > wrote:
> > > quite in the form you imagined.  The idea that we've tossed
> > > around is
> > > to restore FPU state on return to user mode.  Roughly, we'd
> > > introduce
> > > a new thread flag TIF_FPU_UNLOADED (name TBD).
> > > prepare_exit_to_usermode() would notice this flag, copy the
> > > fpstate to
> > > fpregs, and clear the flag.  (Or maybe exit_to_usermode_loop() --
> > > No
> > > one has quite thought it through, but I think it should be
> > > outside the
> > > loop.)  We'd update all the FPU accessors to understand the flag.
> > 
> > Yes! This is exactly what I was thinking. Then those calls to
> > begin()
> > and end() could be placed as close to the actual FPU usage as
> > possible.
> 
> Andy, what was the specific concern about PKRU?  That we might do:
> 
> 	kernel_fpu_begin(); <- Saves the first time
> 	something()
> 	kernel_fpu_end(); <- Does not XRSTOR
> 
> 	copy_from_user(); <- Sees old PKRU, does the wrong thing
> 
> 	prepare_exit_to_usermode(); <- Does the XRSTOR
> 	// only now does PKRU have the right value
> 	SYSRET/IRET
> 
> ?
> 
> Does that *matter* unless something() modified PKRU?  We could just
> make
> the rule that nobody is supposed to mess with it and that it's not
> covered by kernel_fpu_begin/end() semantics.  We could even
> theoretically enforce that in a debug environment if we watch its
> value.

KVM needs to change out guest and host PKRU values
when switching between guest and host mode, but
since f775b13eedee ("x86,kvm: move qemu/guest FPU 
switching out to vcpu_run") that no longer happens
under kernel_fpu_begin/end so we don't need to care
about that :)

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2018-06-15 20:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15 13:11 Lazy FPU restoration / moving kernel_fpu_end() to context switch Jason A. Donenfeld
2018-06-15 16:25 ` Thomas Gleixner
2018-06-15 18:33   ` Brian Gerst
2018-06-15 19:34   ` Peter Zijlstra
2018-06-15 20:30     ` Jason A. Donenfeld
2018-06-18  9:44       ` Peter Zijlstra
2018-06-18 15:25         ` Jason A. Donenfeld
2018-06-15 18:31 ` Andy Lutomirski
2018-06-15 18:40   ` Rik van Riel
2018-06-15 18:41   ` Dave Hansen
2018-06-15 18:49     ` Andy Lutomirski
2018-06-15 18:48   ` Dave Hansen
2018-06-15 18:53     ` Andy Lutomirski
2018-06-15 20:27       ` Jason A. Donenfeld
2018-06-15 20:48         ` Jason A. Donenfeld
2018-06-19 11:43       ` David Laight
2018-06-19 13:08         ` Thomas Gleixner
2018-06-15 20:33   ` Jason A. Donenfeld
2018-06-15 20:42     ` Dave Hansen
2018-06-15 20:52       ` Andy Lutomirski
2018-06-15 20:56       ` Rik van Riel [this message]
2018-07-11 16:28     ` Sebastian Andrzej Siewior
2018-07-11 20:10       ` Rik van Riel

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=1529096218.7898.158.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=Jason@zx2c4.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=x86@kernel.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.