All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Lutomirski <luto@kernel.org>,
	dave.hansen@intel.linux.com, Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH RFC 3/3] x86/fpu: defer FPU state load until return to userspace
Date: Mon, 17 Oct 2016 20:06:06 -0400	[thread overview]
Message-ID: <1476749166.23685.8.camel@redhat.com> (raw)
In-Reply-To: <CALCETrXeV4w3Y74a=uA_mzNraDHj+ZEUJ4rM+j3k3R573YKV2g@mail.gmail.com>

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

On Mon, 2016-10-17 at 13:58 -0700, Andy Lutomirski wrote:
> On Mon, Oct 17, 2016 at 1:09 PM,  <riel@redhat.com> wrote:
> > 
> > From: Rik van Riel <riel@redhat.com>
> > 
> > Defer loading of FPU state until return to userspace. This gives
> > the kernel the potential to skip loading FPU state for tasks that
> > stay in kernel mode, or for tasks that end up with repeated
> > invocations of kernel_fpu_begin.

> >  #define CREATE_TRACE_POINTS
> >  #include <trace/events/syscalls.h>
> > @@ -189,6 +190,14 @@ __visible inline void
> > prepare_exit_to_usermode(struct pt_regs *regs)
> >         if (unlikely(cached_flags & EXIT_TO_USERMODE_LOOP_FLAGS))
> >                 exit_to_usermode_loop(regs, cached_flags);
> > 
> > +       /* Reload ti->flags; we may have rescheduled above. */
> > +       cached_flags = READ_ONCE(ti->flags);
> 
> Stick this bit in the "if" above, please.

Will do.

> But I still don't see how this can work correctly with PKRU.

OK, Andy and I talked on IRC, and we have some ideas on how
to fix & improve this series:

1) pin/unpin_fpregs_active to prevent leaking of other
   users' fpregs contents to userspace (patch 1)
2) eagerly switch PKRU state (only), at task switch time,
   if the incoming task has different protection keys from
   the outgoing task (somewhat unlikely), just like the
   KVM vcpu entry & exit code is already doing
3) remove stts from the KVM VMX code (Andy may get
   to this before me)
4) enhance __kernel_fpu_begin() to take an fpu argument,
   and let the caller (really just kvm_load_guest_fpu)
   know whether that fpu state is still present in the
   registers, allowing it to skip __copy_kernel_to_fpregs

-- 
All Rights Reversed.

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

  reply	other threads:[~2016-10-18  0:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 20:09 [PATCH RFC 0/3] x86/fpu: defer FPU state loading until return to userspace riel
2016-10-17 20:09 ` [PATCH RFC 1/3] fpu/x86: add make_fpregs_active(_newstate) helper functions riel
2016-10-17 20:57   ` Andy Lutomirski
2016-10-17 23:04     ` Yu-cheng Yu
2016-10-17 23:30       ` Andy Lutomirski
2016-10-17 23:45         ` Yu-cheng Yu
2016-10-18  1:23           ` Andy Lutomirski
2016-10-17 20:09 ` [PATCH RFC 2/3] x86/fpu: prepare misc FPU state handling code for lazy FPU loading riel
2016-10-17 20:09 ` [PATCH RFC 3/3] x86/fpu: defer FPU state load until return to userspace riel
2016-10-17 20:58   ` Andy Lutomirski
2016-10-18  0:06     ` Rik van Riel [this message]
2016-10-18  7:58 ` [PATCH RFC 0/3] x86/fpu: defer FPU state loading " Ingo Molnar

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=1476749166.23685.8.camel@redhat.com \
    --to=riel@redhat.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.linux.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --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.