[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8Afy2J0io8F510i@hirez.programming.kicks-ass.net>
Date: Thu, 12 Jan 2023 15:57:15 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Xin Li <xin3.li@...el.com>, linux-kernel@...r.kernel.org,
x86@...nel.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, hpa@...or.com, brgerst@...il.com,
chang.seok.bae@...el.com, jgross@...e.com
Subject: Re: [PATCH v6 0/5] x86: Enable LKGS instruction
On Thu, Jan 12, 2023 at 01:13:20PM +0100, Ingo Molnar wrote:
>
> * Xin Li <xin3.li@...el.com> wrote:
>
> > LKGS instruction is introduced with Intel FRED (flexible return and event
> > delivery) specification. As LKGS is independent of FRED, we enable it as
> > a standalone CPU feature.
> >
> > LKGS behaves like the MOV to GS instruction except that it loads the base
> > address into the IA32_KERNEL_GS_BASE MSR instead of the GS segment’s
> > descriptor cache, which is exactly what Linux kernel does to load user
> > level GS base. Thus, with LKGS, there is no need to SWAPGS away from the
> > kernel GS base.
>
> Ok, this looks good to me.
>
> I've applied the first 4 patches to tip:x86/cpu, as the instruction exists
> in a public document and these patches are fine stand-alone as well, such
> as the factoring out of load_gs_index() methods from a high-use low level
> header into a new header file.
>
> Planning to apply the final, LKGS enabler patch as well, unless there's any
> objections from others?
Nah, I think that thing's bike-shedded to near death. Let's just do it.
Powered by blists - more mailing lists