From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752626AbcJDCr7 (ORCPT ); Mon, 3 Oct 2016 22:47:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50034 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751662AbcJDCr6 (ORCPT ); Mon, 3 Oct 2016 22:47:58 -0400 Message-ID: <1475549273.21644.51.camel@redhat.com> Subject: Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace From: Rik van Riel To: Andy Lutomirski Cc: Dave Hansen , "linux-kernel@vger.kernel.org" , X86 ML , Thomas Gleixner , Paolo Bonzini , Ingo Molnar , Andrew Lutomirski , "H. Peter Anvin" , Borislav Petkov Date: Mon, 03 Oct 2016 22:47:53 -0400 In-Reply-To: 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> <1475544579.21644.37.camel@redhat.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-U0HM/X1j2PVm/EhEv8Q6" Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 04 Oct 2016 02:47:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-U0HM/X1j2PVm/EhEv8Q6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-10-03 at 19:09 -0700, Andy Lutomirski wrote: > > Having two separate status booleans for "registers valid" > > and "memory valid" may make more sense. >=20 > I have no problem with the concept of "owner_ctx", and I think it's a > perfectly reasonable data structure.=C2=A0=C2=A0My problem with it is tha= t it's > subtle and knowledge of it is spread all over the place.=C2=A0=C2=A0Just = going > with "registers valid" in a variable won't work, I think, because > there's nowhere to put it.=C2=A0=C2=A0We need to be able to delete a stru= ct fpu > while that struct fpu might have a valid copy in a different cpu's > registers. >=20 > Anyway, feel free to tell me that I'm making this too difficult :) How about we rename=C2=A0fpu_want_lazy_restore to fpu_registers_valid()? =C2=A0Problem solved :) Then we can rename=C2=A0__cpu_disable_lazy_restore to fpu_invalidate_registers(), and call that before we modify any in-memory FPU state. > > We can get rid of fpu.counter, since nobody uses it > > any more. >=20 > We should definitely do this. >=20 > Maybe getting in some cleanups first (my lazy fpu deletion, > fpu.counter removal, etc) first is the way to go. Sounds good. =C2=A0I will keep my patch 1/4 as part of the cleanup series, and will not move on to the harder stuff until after the cleanups. Any other stuff I should clean up while we're there? > > > > >=C2=A0 > > You are right, read_pkru() and write_pkru() can only deal with > > the pkru state being present in registers. Is this because of an > > assumption in the code, or because of a hardware requirement? read_pkru and write_pkru would be candidates for using fpu_registers_valid, and potentially a fpu_make_registers_valid, which restores the contents of the fpu registers from memory, if fpu_registers_valid is not true. Likewise, we can have an fpu_make_memory_valid to ensure the in kernel memory copy of the FPU registers is valid, potentially a _read and _write version that do exactly what the pstate code wants today. Would that make sense as an API? --=20 All Rights Reversed. --=-U0HM/X1j2PVm/EhEv8Q6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJX8xhaAAoJEM553pKExN6DObYH/3d+QiUhQhT4t6NTASlXuW/7 4a4OQSn6Dgt3qpbfHtTxT+xa+5W2tYT5dIGQ+vu8XpdW9+b4cGfIV1IkQM9JGNL2 Egz5OrnlBFDy+gAdNT0/L5whYmdcsFSqdALJGUpLTogA5YOkVjsK04E+8Vl7LgNz NdFAUXgc4pKjZX6ZjEQZRYUMOFFA9vLOb+lEZxQGkH0weVYHqBCmLWnYaQ83CGbY gdCuzLeJYGqKNTBldUivXtd1O/jbXyP4qtA2lC6pt8urqmGkdGXBifRKv9OlDTOh +UbDUfdwSxMYH+Wqik+G4SZDbPLEkS2EXV207X2OlJZDM6LTOkG53mODL23Phlg= =2szt -----END PGP SIGNATURE----- --=-U0HM/X1j2PVm/EhEv8Q6--