In order to perform an indirect branch to kvm_host_psci_cpu_entry()
on a BTI-aware system, we first branch to a 'BTI j' landing pad,
and from there branch again to the target.
While this works, this is really not required:
- BLR works with 'BTI c' and 'PACIASP' as the landing pad
- Even if LR gets clobbered by BLR, we are going to restore the
host's registers, so it is pointless to try and avoid touching
LR
Given the above, drop the veneer and directly call into C code.
If we were to come back from it, we'd directly enter the error
handler.
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260321212419.2803972-3-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
ret
SYM_CODE_END(__kvm_hyp_host_forward_smc)
-
-/*
- * kvm_host_psci_cpu_entry is called through br instruction, which requires
- * bti j instruction as compilers (gcc and llvm) doesn't insert bti j for external
- * functions, but bti c instead.
- */
-SYM_CODE_START(kvm_host_psci_cpu_entry)
- bti j
- b __kvm_host_psci_cpu_entry
-SYM_CODE_END(kvm_host_psci_cpu_entry)
mov x0, x28
bl ___kvm_hyp_init // Clobbers x0..x2
- /* Leave idmap. */
+ /* Leave idmap -- using BLR is OK, LR is restored from host context */
mov x0, x29
- ldr x1, =kvm_host_psci_cpu_entry
- br x1
+ ldr x1, =__kvm_host_psci_cpu_entry
+ blr x1
- // The core booted in EL1. KVM cannot be initialized on it.
+ // The core booted in EL1, or the C code unexpectedly returned.
+ // Either way, KVM cannot be initialized on it.
1: wfe
wfi
b 1b