[PATCH 0/5] arm64: Survival kit for SCR_EL3.HCE==0 conditions

[Marc Zyngier]

Anyone vaguely familiar with the ARMv8 architecture would quickly
understand that entering the kernel at EL2 without enabling the HVC
instruction is... living dangerously. But as it turns out [0], there
is a whole range of (*cough*) "high quality" (*cough*) Broadcom
systems out there configured exactly like that.

If you are speechless, I'm right with you.

These machines have stopped being able to boot an upstream kernel
since 5.12, where we changed the way we switch from nVHE to VHE, as
this relies on the HVC instruction being usable... It is also worth
noting that these systems have never been able to use KVM. Or kexec.

This small series addresses the issue by detecting an UNDEFing HVC in
a fairly controlled environment, and in this case pretend that we have
booted at EL1. It also documents the requirement for SCR_EL3.HCE to be
set to *1* if the kernel is entered at EL2. Turns out that we really
have to state the obvious.

This has been tested on a FVP model with a hacked-up boot-wrapper.

Note that I really don't think any of this is -stable material, except
maybe for the documentation. It isn't 5.14 material either. Best case,
this is 5.15, or maybe even later. If ever.

	M. (drink required)

[0] https://lore.kernel.org/r/53f3a2d2-22f8-edee-2507-d41a4090dad7@xxxxxxxxx

Marc Zyngier (5):
  arm64: Directly expand __init_el2_nvhe_prepare_eret where needed
  arm64: Handle UNDEF in the EL2 stub vectors
  arm64: Detect disabled HVC early
  arm64: Warn on booting at EL2 with HVC disabled
  arm64: Document the requirement for SCR_EL3.HCE

 Documentation/arm64/booting.rst    |  5 +++++
 arch/arm64/include/asm/el2_setup.h |  6 ------
 arch/arm64/include/asm/virt.h      | 10 +++++++++
 arch/arm64/kernel/head.S           | 34 ++++++++++++++++++++++++++++++
 arch/arm64/kernel/hyp-stub.S       | 19 ++++++++++++++++-
 arch/arm64/kernel/smp.c            |  3 +++
 6 files changed, 70 insertions(+), 7 deletions(-)

-- 
2.30.2