From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D6545FF8877 for ; Wed, 29 Apr 2026 10:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=kF1pvvWxpAS9qWmc9Ar/+WVCqIw/byC5ple9Iqn8Gs0=; b=PaDOxa5PGBCPtGjHcWJvXKJMDg h97W01NglfkHH4U2vOezO52MhRyrNlZftDHobFLsIW5DTAj6sPtQumbMJXBwTTmRwiICcArMCOdjf 3rASClHvSLgf6C+TEqH4NOFTJqgiHEaPHlyH85YWwDYfnJhW5h/2HpYCPk6yUV32mluejkF2P+0S2 h833/gY6rtLIXFME4EBc824yKuG3jqIbRRBksc7yOBrivTdDN6Sxg/tdu3qGBOM7npwR8IQFtYo6o Da0PZyz2o43t8SSsXYeNTCAkfZT4H3XSUMWIvec1bFVaV/PLnDLI4G0WFHHIw3gueNafmEw9Q59hT by1kYnOQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wI2H1-00000003Saa-0XkR; Wed, 29 Apr 2026 10:36:07 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wI2Gy-00000003SZ9-05FH for linux-arm-kernel@lists.infradead.org; Wed, 29 Apr 2026 10:36:05 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4ECB82574; Wed, 29 Apr 2026 03:35:55 -0700 (PDT) Received: from ewhatever.cambridge.arm.com (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 363363F763; Wed, 29 Apr 2026 03:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1777458960; bh=7L7s1dLAG/7c75PzP5gneVQA8LYo44stckolmq76ePM=; h=From:To:Cc:Subject:Date:From; b=RwSjkweAHiQe1emy85R7ifOWYU3GW+xcVAouvqb07c1u4wGHWPqik04JePixblR3a zP6NjzJk2yeS8oOro70VWgu87xYA3MZXQAUVDdxko2KWwPIu0Xjlf7eNylQzkDupp/ RE+W41LKfc/OF6l8nD4MwEdnPURKxrsv6RLMxhJg= From: Suzuki K Poulose 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 Subject: [RFC PATCH 0/4] arm64: realm: Support for probing RSI earlier Date: Wed, 29 Apr 2026 11:35:31 +0100 Message-ID: <20260429103535.266728-1-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260429_033604_138211_503B93D8 X-CRM114-Status: GOOD ( 18.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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-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