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

[Lorenzo Pieralisi <lpieralisi@kernel.org>]

On Fri, May 08, 2026 at 09:28:32AM +0100, Suzuki K Poulose wrote:
> Hi Lorenzo,
> 
> 
> On 08/05/2026 09:09, Lorenzo Pieralisi wrote:
> > On Wed, Apr 29, 2026 at 11:35:31AM +0100, Suzuki K Poulose wrote:
> > > 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.
> > 
> > Nit: you mean unflattened here.
> 
> Yep, thats right.
> 
> > 
> > > 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.
> > 
> > I went back to tracing acpi_boot_table_init() (joy :)) and it does what you
> 
> Welcome back ;-)
> 
> > describe here above (it has been a while since I touched that code) relying on
> > early_memremap() mappings (as you re-do in this series) before acpi_permanent_mmap
> > is set in acpi_early_init() (that happens later in the boot process).
> > 
> > I am sure there are caveats in moving acpi_boot_table_init() before
> > paging_init() but I thought I'd mention it in case (3) is what we are
> > pursuing (I am most definitely in favour of alternatives if there are
> > any).
> 
> I believe we might have issues with acpi_table_upgrade(), which would
> need access to initramfs for any tables. We may not have the initramfs
> mapped by then ? Anyways, FADT cannot be upgraded from the initramfs,

I think it can:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/tables.c?h=v7.1-rc2#n407

Obviously this is a debugging/bootstrapping tool but hey, here we go.

> so if we can work out a way to do the necessary may be something
> worth checking.

I don't think we can init the tables before enabling the upgrade (which
requires reading from initrd).

I will try to think a bit more to see whether we can reuse some code
(again - if that's what we eventually want to do).

Lorenzo

> > 
> > > 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.
> > 
> > What would we gain compared to (3) above ?
> 
> EFI stub has 1x1 map for the areas and we don't have to do the map/unmap
> dancein the kernel and potentially end up crashing ourselves.
> 
> Suzuki
> 
> > 
> > Thanks,
> > Lorenzo
> > 
> > > 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
> > > 
>