[RFC PATCH 0/4] arm64: realm: Support for probing RSI earlier

Suzuki K Poulose
2026-04-29T10:36:21Z

The Realm Guest linux support is broken without rodata=full (fortunately default
for arm64), as we detect the RSI support after we have created the Linear map
with Block/Contiguous mappings. If the boot CPU doesn't support BBML2_NOABORT
(there are CPUs out there with FEAT_RME and no - useable - BBML2_NOABORT)
we are then not able to split the page tables down to PTE level if the system
as such doesn't support BBML2.

See the following link for the discussion.

https://lore.kernel.org/all/20260330161705.3349825-2-ryan.roberts@arm.com/

The available options are :
1. Start with PTE level mappings at paging_init() and then "FOLD" the page tables
to Block/Cont mappings after we have the full picture available. Looking at the
future (with BBML3), this might mean "additional work" for most of the systems
at boot. But not bad as splitting them ?
2. Hold the secondary CPUs in busy loop with MMU disabled and split the mappings
by the boot CPU with MMU off (if Boot CPU can't support BBML2). This is tricky
with the page allocations required to add the page-tables.
3. Move the detection of Realm support earlier to make a better decision for
paging_init(), with an added bonus of earlycon support for Realms without
the user having to work out the "top bit" for the Realm.

This series is an attempt to implement (3) (without the earlycon support). We try
to probe the PSCI conduit early from the DT/ACPI. DT is not flattened at this time.

ACPI table is not mapped in full, so we have to map one table at a time and walk
from the Root of the table (RSDP) through to XSDT and find the FADT table from
the array of table pointers there. Minimal verification is performed on the
tables (e.g., revision checks, standard FADT sanity checks). Checksum is not
verified, but should be possible to do for the parts we consume.

With arm64, during the normal boot, we could fallback to using DT if the ACPI
tables are not useable. So, during the early probe, we try to follow the similar
logic and probe the conduit from both DT and ACPI where available. If both of
them contain a conduit, we only proceed if they match. Otherwise, we skip the
early probe and do things the normal way. (Any sane system shouldn't have such
a mismatch, but..)

Once we probe the PSCI conduit, PSCI is probed, along with the presence of SMCCC.
With that in place, we try to probe the RSI support after the early probe and
advertise the Realm World. If the early probe wasn't successful, we fall back
to the late mode, where we could end up with (on a possibly rare broken firmware).

NOTE: This is an early RFC attempt to moving the PSCI detection earlier. The other
option(s) that may be worth exploring are:

1. On systems with EFI, parse this from EFI Stub and pass the data back in the
DT Stub, under chosen node. e.g., "linux,uefi-arm-psci-conduit".
Challenge: EFI stub doesn't seem to be ACPI aware. We could make that change,
we only need a few table walks.
2. Have EFI firmware provide this information (with my limited knowledge on the
area, this looks like too much work, and bending the standards)
3. Append arm64 boot protocol to have this information passed to the kernel.
(Firmware provided) - (Steven's idea)
4. Any other options ?

This series is also available here :

git@git.gitlab.arm.com:linux-arm/linux-cca.git cca-guest/early-rsi-detection/rfc-v1

Thoughts ?

Suzuki

Suzuki K Poulose (4):
arm64: acpi: Refactor FADT table verification
psci: Add support for Early detection and init
arm64: psci: Move detection and SMCCC probe earlier
arm64: realm: Move RSI detection earlier

arch/arm64/include/asm/acpi.h | 1 +
arch/arm64/include/asm/rsi.h | 1 +
arch/arm64/kernel/acpi.c | 136 +++++++++++++++++++++++++++-------
arch/arm64/kernel/rsi.c | 23 +++++-
arch/arm64/kernel/setup.c | 69 +++++++++++++++++
drivers/firmware/psci/psci.c | 49 +++++++++++-
include/linux/psci.h | 2 +
7 files changed, 252 insertions(+), 29 deletions(-)

--
2.43.0