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

[Suzuki K Poulose <suzuki.poulose@arm.com>]

On 08/05/2026 12:05, Lorenzo Pieralisi wrote:
> 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

Oh! I misread the FACS as FADT :facepalm:

Thank you for correcting me.

> 
> 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).

I will continue to explore this too.

Much appreciated

Cheers
Suzuki


> 
> 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
>>>>
>>