public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
	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, Suzuki K Poulose <suzuki.poulose@arm.com>
Subject: [RFC PATCH v2 0/4] arm64: realm: Support for probing RSI earlier
Date: Tue,  5 May 2026 16:57:38 +0100	[thread overview]
Message-ID: <20260505155742.623287-1-suzuki.poulose@arm.com> (raw)
In-Reply-To: <20260429103535.266728-1-suzuki.poulose@arm.com>

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.

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.

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

Thoughts ?

Suzuki


Changes since v1:
 (Mainly addressing review comments from AI agent)
[0] https://lore.kernel.org/all/20260429103535.266728-1-suzuki.poulose@arm.com
 - Handle ACPI XSDT table properly for tables greater than a PAGE_SIZE
 - Stricter checking for the PSCI DT node, match the compatible to PSCI 0.2 or v1.0
   and honor the "status" property of the node, to be more closer to the late check

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      | 151 ++++++++++++++++++++++++++++------
 arch/arm64/kernel/rsi.c       |  23 +++++-
 arch/arm64/kernel/setup.c     |  79 ++++++++++++++++++
 drivers/firmware/psci/psci.c  |  49 ++++++++++-
 include/linux/psci.h          |   2 +
 7 files changed, 277 insertions(+), 29 deletions(-)

-- 
2.43.0



  parent reply	other threads:[~2026-05-05 15:58 UTC|newest]

Thread overview: 10+ 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 ` Suzuki K Poulose [this message]
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

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=20260505155742.623287-1-suzuki.poulose@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox