From: Catalin Marinas <catalin.marinas@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, will@kernel.org, ardb@kernel.org,
lpieralisi@kernel.org, mark.rutland@arm.com,
steven.price@arm.com, aneesh.kumar@kernel.org,
sudeep.holla@arm.com, robh@kernel.org, maz@kernel.org
Subject: Re: [RFC PATCH v2 0/4] arm64: realm: Support for probing RSI earlier
Date: Thu, 28 May 2026 17:06:39 +0100 [thread overview]
Message-ID: <ahhoD3HbKMo_vP8K@arm.com> (raw)
In-Reply-To: <20260505155742.623287-1-suzuki.poulose@arm.com>
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@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.
Looking at the patches, I'm no longer sure it's worth justifying the
complexity. Trying to recall the previous thread - does it only matter
if BBML2_NOABORT is not supported and the kernel boots with rodata=off?
I guess we can ignore big.LITTLE configurations for now since the
deployment of CCA doesn't target mobile yet.
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.
--
Catalin
next prev parent reply other threads:[~2026-05-28 16:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 10:35 [RFC PATCH 0/4] arm64: realm: Support for probing RSI earlier Suzuki K Poulose
2026-04-29 10:35 ` [RFC PATCH 1/4] arm64: acpi: Refactor FADT table verification Suzuki K Poulose
2026-04-29 10:35 ` [RFC PATCH 2/4] psci: Add support for Early detection and init Suzuki K Poulose
2026-04-29 10:35 ` [RFC PATCH 3/4] arm64: psci: Move detection and SMCCC probe earlier Suzuki K Poulose
2026-04-29 10:35 ` [RFC PATCH 4/4] arm64: realm: Move RSI detection earlier Suzuki K Poulose
2026-05-05 15:57 ` [RFC PATCH v2 0/4] arm64: realm: Support for probing RSI earlier Suzuki K Poulose
2026-05-05 15:57 ` [RFC PATCH v2 1/4] arm64: acpi: Refactor FADT table verification Suzuki K Poulose
2026-05-05 15:57 ` [RFC PATCH v2 2/4] psci: Add support for Early detection and init Suzuki K Poulose
2026-05-05 15:57 ` [RFC PATCH v2 3/4] arm64: psci: Move detection and SMCCC probe earlier Suzuki K Poulose
2026-05-05 15:57 ` [RFC PATCH v2 4/4] arm64: realm: Move RSI detection earlier Suzuki K Poulose
2026-05-28 16:06 ` Catalin Marinas [this message]
2026-05-29 12:27 ` [RFC PATCH v2 0/4] arm64: realm: Support for probing RSI earlier Suzuki K Poulose
2026-05-08 8:09 ` [RFC PATCH " Lorenzo Pieralisi
2026-05-08 8:28 ` Suzuki K Poulose
2026-05-08 11:05 ` Lorenzo Pieralisi
2026-05-13 10:17 ` Suzuki K Poulose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ahhoD3HbKMo_vP8K@arm.com \
--to=catalin.marinas@arm.com \
--cc=aneesh.kumar@kernel.org \
--cc=ardb@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=robh@kernel.org \
--cc=steven.price@arm.com \
--cc=sudeep.holla@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.