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

[Suzuki K Poulose]

On 28/05/2026 17:06, Catalin Marinas wrote:
> Hi Suzuki,
>
> On Tue, May 05, 2026 at 04:57:38PM +0100, Suzuki K Poulose wrote:
> > This is an updated series, addressing the review comments from AI agent on
> > the version 1 [0] of the series, (some of which were documented as short comings).
> > See below for the changes.
> >
> > 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@xxxxxxx/
> >
> > 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.
>
> Looking at the patches, I'm no longer sure it's worth justifying the
> complexity. 

Yep, it is not simple with ACPI.

> Trying to recall the previous thread - does it only matter
> if BBML2_NOABORT is not supported and the kernel boots with rodata=off?

Correct.

> I guess we can ignore big.LITTLE configurations for now since the
> deployment of CCA doesn't target mobile yet.

True.

> Could we instead add a more informative message in arm64_rsi_init() if
> !force_pte_mappings() && !cpu_supports_bbml2_noabort() (before
> is_realm_world() becomes true)? Well, it may not print anything if the
> early console is not set up yet.

That is true, but with some expertise you may be able to enable earlycon
and may be we could get some new mechanism for "earlycon"  for Realms.

The other way to look at is:

When the system doesn't support BBML2 Abort:

Creating block/Cont mappings to start with and then splitting it to PTE
is quite difficult as we :
1. Need to allocate pages for leaf level tables
2. Hold the other CPUs in tight loop

Instead, creating the block/CONT levels from a fully "page level"
mappings are easier, as we can:

1. Can easily fold the tables to Block mapping with reclaiming the leaf 
level pagetables.

2. Avoid the secondary CPUs dance, as they all support BBML2_NOABORT.

This shouldn't be that bad as the opposite ?

I understand there are concerns on the boot time. May be we could add
a kernel command line to force block mappings and slowly deprecate it ?

Suzuki

>