linux/arch
Borislav Petkov (AMD) 0d3db1f14a x86/alternatives, kvm: Fix a couple of CALLs without a frame pointer
objtool complains:

  arch/x86/kvm/kvm.o: warning: objtool: .altinstr_replacement+0xc5: call without frame pointer save/setup
  vmlinux.o: warning: objtool: .altinstr_replacement+0x2eb: call without frame pointer save/setup

Make sure %rSP is an output operand to the respective asm() statements.

The test_cc() hunk and ALT_OUTPUT_SP() courtesy of peterz. Also from him
add some helpful debugging info to the documentation.

Now on to the explanations:

tl;dr: The alternatives macros are pretty fragile.

If I do ALT_OUTPUT_SP(output) in order to be able to package in a %rsp
reference for objtool so that a stack frame gets properly generated, the
inline asm input operand with positional argument 0 in clear_page():

	"0" (page)

gets "renumbered" due to the added

	: "+r" (current_stack_pointer), "=D" (page)

and then gcc says:

  ./arch/x86/include/asm/page_64.h:53:9: error: inconsistent operand constraints in an ‘asm’

The fix is to use an explicit "D" constraint which points to a singleton
register class (gcc terminology) which ends up doing what is expected
here: the page pointer - input and output - should be in the same %rdi
register.

Other register classes have more than one register in them - example:
"r" and "=r" or "A":

  ‘A’
	The ‘a’ and ‘d’ registers.  This class is used for
	instructions that return double word results in the ‘ax:dx’
	register pair.  Single word values will be allocated either in
	‘ax’ or ‘dx’.

so using "D" and "=D" just works in this particular case.

And yes, one would say, sure, why don't you do "+D" but then:

  : "+r" (current_stack_pointer), "+D" (page)
  : [old] "i" (clear_page_orig), [new1] "i" (clear_page_rep), [new2] "i" (clear_page_erms),
  : "cc", "memory", "rax", "rcx")

now find the Waldo^Wcomma which throws a wrench into all this.

Because that silly macro has an "input..." consume-all last macro arg
and in it, one is supposed to supply input *and* clobbers, leading to
silly syntax snafus.

Yap, they need to be cleaned up, one fine day...

Closes: https://lore.kernel.org/oe-kbuild-all/202406141648.jO9qNGLa-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Sean Christopherson <seanjc@google.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20240625112056.GDZnqoGDXgYuWBDUwu@fat_crate.local
2024-07-01 12:41:11 +02:00
..
alpha mseal: wire up mseal syscall 2024-05-23 19:40:26 -07:00
arc bpf-for-netdev 2024-05-27 16:26:30 -07:00
arm mseal: wire up mseal syscall 2024-05-23 19:40:26 -07:00
arm64 14 hotfixes, 6 of which are cc:stable. 2024-06-07 17:01:10 -07:00
csky The usual shower of singleton fixes and minor series all over MM, 2024-05-19 09:21:03 -07:00
hexagon hexagon: vmlinux.lds.S: handle attributes section 2024-03-26 11:07:23 -07:00
loongarch LoongArch: Fix GMAC's phy-mode definitions in dts 2024-06-03 15:45:53 +08:00
m68k mseal: wire up mseal syscall 2024-05-23 19:40:26 -07:00
microblaze mseal: wire up mseal syscall 2024-05-23 19:40:26 -07:00
mips mseal: wire up mseal syscall 2024-05-23 19:40:26 -07:00
nios2 Kbuild updates for v6.10 2024-05-18 12:39:20 -07:00
openrisc openrisc: Move FPU state out of pt_regs 2024-04-15 15:20:39 +01:00
parisc mseal: wire up mseal syscall 2024-05-23 19:40:26 -07:00
powerpc powerpc: Limit ARCH_HAS_KERNEL_FPU_SUPPORT to PPC64 2024-05-30 22:57:27 +10:00
riscv RISC-V Fixes for 6.10-rc3 2024-06-07 14:47:38 -07:00
s390 s390/crash: Do not use VM info if os_info does not have it 2024-06-05 17:03:24 +02:00
sh mseal: wire up mseal syscall 2024-05-23 19:40:26 -07:00
sparc Jeff Xu's implementation of the mseal() syscall. 2024-05-24 12:47:28 -07:00
um This pull request contains the following changes for UML: 2024-05-25 13:17:48 -07:00
x86 x86/alternatives, kvm: Fix a couple of CALLs without a frame pointer 2024-07-01 12:41:11 +02:00
xtensa mseal: wire up mseal syscall 2024-05-23 19:40:26 -07:00
.gitignore
Kconfig arch: add ARCH_HAS_KERNEL_FPU_SUPPORT 2024-05-19 14:36:17 -07:00