Messages in this thread |  | | From | Andy Lutomirski <> | Date | Mon, 3 Oct 2016 20:02:15 -0700 | Subject | Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace |
| |
On Oct 3, 2016 7:11 PM, "Rik van Riel" <riel@redhat.com> wrote: > > 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
Also __get_user, etc. I don't think you want to start playing with TIF_LOAD_FPU there. I think tracking PKRU separately and eagerly loading it with WRPKRU may be the only decent choice here.
> > 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.
|  |