Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752174AbcJDDCi (ORCPT ); Mon, 3 Oct 2016 23:02:38 -0400 Received: from mail-vk0-f42.google.com ([209.85.213.42]:34493 "EHLO mail-vk0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751469AbcJDDCh (ORCPT ); Mon, 3 Oct 2016 23:02:37 -0400 MIME-Version: 1.0 In-Reply-To: <1475547077.21644.45.camel@redhat.com> References: <1475353895-22175-1-git-send-email-riel@redhat.com> <1475353895-22175-3-git-send-email-riel@redhat.com> <1475366900.21644.8.camel@redhat.com> <1475529679.4622.27.camel@redhat.com> <1475547077.21644.45.camel@redhat.com> From: Andy Lutomirski Date: Mon, 3 Oct 2016 20:02:15 -0700 Message-ID: Subject: Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace To: Rik van Riel Cc: Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Dave Hansen , X86 ML , Borislav Petkov , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1500 Lines: 43 On Oct 3, 2016 7:11 PM, "Rik van Riel" 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.