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

From: Suzuki K Poulose

Date: Thu Jun 11 2026 - 10:51:44 EST


On 11/06/2026 12:14, Catalin Marinas wrote:
On Fri, May 29, 2026 at 01:27:01PM +0100, Suzuki K Poulose wrote:
On 28/05/2026 17:06, Catalin Marinas wrote:
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.
[...]
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

Agree, that's not easily possible at runtime.

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 don't think it solves our problem. Aren't we concerned with the
rodata=off && !BBML2_NOABORT && is_realm_world() case? I don't think
your second point stands.

Currently we have:

rodata=full && BBML2_NOABORT => block mappings irrespective of realms

rodata=off && BBML2_NOABORT => block mappings first, can be split later
if is_realm_world()

rodata=off && !BBML2_NOABORT => block mappings first, serious problem if
is_realm_world()

It's the last case we need to fix. Starting with page mappings does
avoid the in-realm failure but the !is_realm_world() case folding to
block mappings still requires proper BBM.

I see, the case I was missing is : !is_realm_world() and !BBML2_NO_ABORT
and we want Block mapping if rodata=off. Yes, in this case we need the secondaries on hold, with proper BBM on the boot CPU too. Again, it is
easier to "collapsing the tables to Block" than the reverse.

Suzuki