All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Andrew Lutomirski <luto@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@suse.de>
Subject: Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace
Date: Mon, 03 Oct 2016 22:11:17 -0400	[thread overview]
Message-ID: <1475547077.21644.45.camel@redhat.com> (raw)
In-Reply-To: <CALCETrX_A71XYJxSxprd_ujHFUK_M7UfmCXeNnP1iGx17CSu8A@mail.gmail.com>

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

On Mon, 2016-10-03 at 14:36 -0700, Andy Lutomirski wrote:
> 
> Anything else that tries to read task xstate from memory, i.e. MPX
> and
> PKRU.  (Although if we switch to eager-switched PKRU, then PKRU stops
> mattering for this purpose.)
> 
> Actually, I don't see any way your patches can be compatible with
> PKRU
> without switching to eager-switched PKRU.

There is one case where the in-register PKRU state matters:
- user space accesses to memory

There are several cases where the in-memory PKRU state would
suffice:
- get_user_pages(_fast) to the local task (could also use registers)
- setting VMA/PTE permission bits (could also use registers)

There is one case where only in-memory PKRU state works, where
PKRU is currently simply ignored:
- get_user_pages to another task's memory

Dave, are there major obstacles to making read_pkru and write_pkru
work with in-memory state?

Would it be better for read/write_pkru to force the FPU state
to get loaded into registers, under the assumption that if things
like get_user_pages_fast happens, we will likely switch back to
userspace soon, anyway?

Would that assumption be wrong with KVM? :)

-- 
All Rights Reversed.

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

  parent reply	other threads:[~2016-10-04  2:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-01 20:31 [PATCH RFC 0/5] x86,fpu: make FPU context switching much lazier riel
2016-10-01 20:31 ` [PATCH RFC 1/5] x86,fpu: split prev/next task fpu state handling riel
2016-10-01 23:26   ` Andy Lutomirski
2016-10-02  0:02     ` Rik van Riel
2016-10-01 20:31 ` [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace riel
2016-10-01 23:44   ` Andy Lutomirski
2016-10-02  0:08     ` Rik van Riel
2016-10-03 20:54       ` Andy Lutomirski
2016-10-03 21:21         ` Rik van Riel
2016-10-03 21:36           ` Andy Lutomirski
2016-10-04  1:29             ` Rik van Riel
2016-10-04  2:09               ` Andy Lutomirski
2016-10-04  2:47                 ` Rik van Riel
2016-10-04  3:02                   ` Andy Lutomirski
2016-10-04  6:35                 ` Ingo Molnar
2016-10-04 12:48                   ` Rik van Riel
2016-10-04  2:11             ` Rik van Riel [this message]
2016-10-04  3:02               ` Andy Lutomirski
2016-10-02  0:42     ` Rik van Riel
2016-10-03 16:23       ` Dave Hansen
2016-10-01 20:31 ` [PATCH RFC 3/5] x86,fpu: add kernel fpu argument to __kernel_fpu_begin riel
2016-10-01 20:31 ` [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded riel
2016-10-03 20:04   ` Dave Hansen
2016-10-03 20:22     ` Rik van Riel
2016-10-03 20:49       ` Dave Hansen
2016-10-03 21:02         ` Rik van Riel
2016-10-01 20:31 ` [PATCH RFC 5/5] x86,fpu: kinda sorta fix up signal path 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=1475547077.21644.45.camel@redhat.com \
    --to=riel@redhat.com \
    --cc=bp@suse.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    --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.