[PATCH v2 0/6] Enable LKGS instruction

Xin Li posted 6 patches 3 years, 5 months ago
There is a newer version of this series
arch/x86/entry/entry_64.S                | 28 +++++++++---
arch/x86/ia32/ia32_signal.c              |  1 +
arch/x86/include/asm/cpufeatures.h       |  1 +
arch/x86/include/asm/gsseg.h             | 57 ++++++++++++++++++++++++
arch/x86/include/asm/mmu_context.h       |  1 +
arch/x86/include/asm/special_insns.h     | 21 ---------
arch/x86/kernel/paravirt.c               |  1 +
arch/x86/kernel/tls.c                    |  1 +
arch/x86/lib/x86-opcode-map.txt          |  1 +
tools/arch/x86/include/asm/cpufeatures.h |  1 +
tools/arch/x86/lib/x86-opcode-map.txt    |  1 +
11 files changed, 87 insertions(+), 27 deletions(-)
create mode 100644 arch/x86/include/asm/gsseg.h
[PATCH v2 0/6] Enable LKGS instruction
Posted by Xin Li 3 years, 5 months ago
LKGS instruction is introduced with Intel FRED (flexible return and event
delivery) specification https://cdrdv2.intel.com/v1/dl/getContent/678938.

LKGS is independent of FRED, so 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.

Changes since V1:
* place fixup code into code section "__ex_table" instead of the obsoleted
  "fixup" section.
* add a comment that states the LKGS_DI macro will be repalced with "lkgs %di"
  once the binutils support LKGS instruction.

H. Peter Anvin (Intel) (6):
  x86/cpufeature: add cpu feature bit for LKGS
  x86/opcode: add LKGS instruction to x86-opcode-map
  x86/gsseg: make asm_load_gs_index() take an u16
  x86/gsseg: move local_irq_save/restore() into asm_load_gs_index()
  x86/gsseg: move load_gs_index() to its own header file
  x86/gsseg: use the LKGS instruction if available for load_gs_index()

 arch/x86/entry/entry_64.S                | 28 +++++++++---
 arch/x86/ia32/ia32_signal.c              |  1 +
 arch/x86/include/asm/cpufeatures.h       |  1 +
 arch/x86/include/asm/gsseg.h             | 57 ++++++++++++++++++++++++
 arch/x86/include/asm/mmu_context.h       |  1 +
 arch/x86/include/asm/special_insns.h     | 21 ---------
 arch/x86/kernel/paravirt.c               |  1 +
 arch/x86/kernel/tls.c                    |  1 +
 arch/x86/lib/x86-opcode-map.txt          |  1 +
 tools/arch/x86/include/asm/cpufeatures.h |  1 +
 tools/arch/x86/lib/x86-opcode-map.txt    |  1 +
 11 files changed, 87 insertions(+), 27 deletions(-)
 create mode 100644 arch/x86/include/asm/gsseg.h

-- 
2.34.1

Re: [PATCH v2 0/6] Enable LKGS instruction
Posted by H. Peter Anvin 3 years, 5 months ago
On 10/10/22 12:01, Xin Li wrote:
> LKGS instruction is introduced with Intel FRED (flexible return and event
> delivery) specification https://cdrdv2.intel.com/v1/dl/getContent/678938.
> 
> LKGS is independent of FRED, so 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.
> 
> Changes since V1:
> * place fixup code into code section "__ex_table" instead of the obsoleted
>    "fixup" section.
> 

Correction: __ex_table is NOT a code section (scared me there for a 
second...). With the new fixup handling code EX_TYPE_ZERO_REG takes care 
of all the work, and there simply is no need for any fixup code at all 
(the exception fixup is fully data-driven.)

So I would say "use EX_TYPE_ZERO_REG instead of fixup code in the 
obsolete .fixup code section."

	-hpa
RE: [PATCH v2 0/6] Enable LKGS instruction
Posted by Li, Xin3 3 years, 5 months ago
> > * place fixup code into code section "__ex_table" instead of the obsoleted
> >    "fixup" section.
> >
> 
> Correction: __ex_table is NOT a code section (scared me there for a second...).

Right, my bad.

> With the new fixup handling code EX_TYPE_ZERO_REG takes care of all the
> work, and there simply is no need for any fixup code at all (the exception fixup
> is fully data-driven.)
> 
> So I would say "use EX_TYPE_ZERO_REG instead of fixup code in the obsolete
> .fixup code section."
> 
> 	-hpa