[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvTdKmSxkCtBRkL+qP7aaw19amHKBKzNG+z+SuSNo54RBKbyQ@mail.gmail.com>
Date: Tue, 31 Aug 2021 18:44:28 -0400
From: Len Brown <lenb@...nel.org>
To: Thiago Macieira <thiago.macieira@...el.com>
Cc: Dave Hansen <dave.hansen@...el.com>,
Borislav Petkov <bp@...en8.de>,
"Chang S. Bae" <chang.seok.bae@...el.com>,
Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
"Brown, Len" <len.brown@...el.com>,
"Liu, Jing2" <jing2.liu@...el.com>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 12/26] x86/fpu/xstate: Use feature disable (XFD) to
protect dynamic user state
On Tue, Aug 31, 2021 at 6:39 PM Thiago Macieira
<thiago.macieira@...el.com> wrote:
>
> On Tuesday, 31 August 2021 15:15:55 PDT Len Brown wrote:
> > Indeed, I believe that there is universal agreement that a synchronous
> > return code
> > from a system call is a far superior programming model than decoding
> > the location of a failure in a system call. (no, the IP isn't random -- it
> > is always the 1st instruction in that thread to touch a TMM register).
>
> That instruction is actually likely going to be a memory load, probably an
> LDTILECFG.
There is no fault on LDTILECONFIG, it will occur on the load tile data.
But yes, still a memory load (with a TMM destination)
Len Brown, Intel Open Source Technology Center
Powered by blists - more mailing lists