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 40B88D0E6E3 for ; Tue, 25 Nov 2025 13:48:17 +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-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3BoF/X28BOoyaiqzRhaHYZ/mygqMWgMGsiQEFaOHpKw=; b=zL8miTktaSg/O1PMAWIus8xaif 5jNQdkdA5DtgCR/Jfn3vPuU39YDeDH3Z/BvZ0dCLU+o0CkpJ2DfmqKijrjUJnL/wndSNDXRgQ7AR8 1IFwNwLk/x2+6IZakxuRvGYhw/oXLbZXuIr3uqdVmIY0Gv+UXMRQjnMV0aBIF9naFdRCktgpCFCPC rHWXyI8vK4m/DUe/DouYT5umD1wlNXt0ztzWkmtI8T7yKAtFFhg/HYiTTshsuS5fB1Yp9RbLU6KTy Vc4mXpH2hIt5QSy0UUAT74kwygRoUshGb8SNzEHcLQAb0rHxVathXIz/KQDHxhgpBt8GEaWMskxa/ IW1HM4Gw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vNtOt-0000000DN4G-0rpF; Tue, 25 Nov 2025 13:48:11 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vNtOr-0000000DN3u-0H4N for linux-arm-kernel@lists.infradead.org; Tue, 25 Nov 2025 13:48:10 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 8FA3C43699; Tue, 25 Nov 2025 13:48:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67227C116B1; Tue, 25 Nov 2025 13:48:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764078487; bh=v1vD+BGAe1IfybLjeiZYe5naHAG4W/wc0Z6DAqSf8Tw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kFEOUjxncfJmOGX/axqEJ0fQ3xOlt2OKe2bWcrqMJOmJeHoPcUSToOaJq3Pi7jMi1 d+T27+5hJLqJKFtwntWGjlUJlOesEI1GhO08eLcfwBeNlU3PPw/qSp18W6+Jhb0lJU UV+aYflCUMYPez+kXuAfcSKcGU1YgbO+hHUH4vv+j3zMqVQ+/SaXeOrwUJoApE0lA2 Xk4MjhATfwn6mPrQSvoTzb0y3eXcJ/fb9Dvq20T2AEl6ZIJoVtDFMqbeH9kDL0h35b wfe1SPv5Bj9pRNZ7RExLiRRVt7aIOcRourBP8wuZ/QG9AgLzwWFHqCxOqSmhV0XQ42 tKviKm5VWq3Xg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vNtOn-00000008AYp-0HiX; Tue, 25 Nov 2025 13:48:05 +0000 Date: Tue, 25 Nov 2025 13:48:04 +0000 Message-ID: <86h5uiql4b.wl-maz@kernel.org> From: Marc Zyngier To: Suzuki K Poulose Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Joey Gouly , Oliver Upton , Zenghui Yu , Christoffer Dall , Fuad Tabba , Mark Brown Subject: Re: [PATCH v4 06/49] KVM: arm64: GICv3: Detect and work around the lack of ICV_DIR_EL1 trapping In-Reply-To: <5df713d4-8b79-4456-8fd1-707ca89a61b6@arm.com> References: <20251120172540.2267180-1-maz@kernel.org> <20251120172540.2267180-7-maz@kernel.org> <5df713d4-8b79-4456-8fd1-707ca89a61b6@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: suzuki.poulose@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, joey.gouly@arm.com, oupton@kernel.org, yuzenghui@huawei.com, christoffer.dall@arm.com, tabba@google.com, broonie@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251125_054809_142054_A4F5F4BA X-CRM114-Status: GOOD ( 34.22 ) 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 On Tue, 25 Nov 2025 11:26:10 +0000, Suzuki K Poulose wrote: > > On 20/11/2025 17:24, Marc Zyngier wrote: > > A long time ago, an unsuspecting architect forgot to add a trap > > bit for ICV_DIR_EL1 in ICH_HCR_EL2. Which was unfortunate, but > > what's a bit of spec between friends? Thankfully, this was fixed > > in a later revision, and ARM "deprecates" the lack of trapping > > ability. > > > > Unfortuantely, a few (billion) CPUs went out with that defect, > > anything ARMv8.0 from ARM, give or take. And on these CPUs, > > you can't trap DIR on its own, full stop. > > > > As the next best thing, we can trap everything in the common group, > > which is a tad expensive, but hey ho, that's what you get. You can > > otherwise recycle the HW in the neaby bin. > > > > Tested-by: Fuad Tabba > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/virt.h | 7 ++++- > > arch/arm64/kernel/cpufeature.c | 52 ++++++++++++++++++++++++++++++++++ > > arch/arm64/kernel/hyp-stub.S | 5 ++++ > > arch/arm64/kvm/vgic/vgic-v3.c | 3 ++ > > arch/arm64/tools/cpucaps | 1 + > > 5 files changed, 67 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h > > index aa280f356b96a..8eb63d3294974 100644 > > --- a/arch/arm64/include/asm/virt.h > > +++ b/arch/arm64/include/asm/virt.h > > @@ -40,8 +40,13 @@ > > */ > > #define HVC_FINALISE_EL2 3 > > +/* > > + * HVC_GET_ICH_VTR_EL2 - Retrieve the ICH_VTR_EL2 value > > + */ > > +#define HVC_GET_ICH_VTR_EL2 4 > > + > > /* Max number of HYP stub hypercalls */ > > -#define HVC_STUB_HCALL_NR 4 > > +#define HVC_STUB_HCALL_NR 5 > > /* Error returned when an invalid stub number is passed into x0 > > */ > > #define HVC_STUB_ERR 0xbadca11 > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > > index 5ed401ff79e3e..5de51cb1b8fe2 100644 > > --- a/arch/arm64/kernel/cpufeature.c > > +++ b/arch/arm64/kernel/cpufeature.c > > @@ -2303,6 +2303,49 @@ static bool has_gic_prio_relaxed_sync(const struct arm64_cpu_capabilities *entry > > } > > #endif > > +static bool can_trap_icv_dir_el1(const struct > > arm64_cpu_capabilities *entry, > > + int scope) > > +{ > > + static const struct midr_range has_vgic_v3[] = { > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M1_ICESTORM), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M1_FIRESTORM), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M1_ICESTORM_PRO), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M1_FIRESTORM_PRO), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M1_ICESTORM_MAX), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M1_FIRESTORM_MAX), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M2_BLIZZARD), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M2_AVALANCHE), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M2_BLIZZARD_PRO), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M2_AVALANCHE_PRO), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M2_BLIZZARD_MAX), > > + MIDR_ALL_VERSIONS(MIDR_APPLE_M2_AVALANCHE_MAX), > > + {}, > > + }; > > + struct arm_smccc_res res = {}; > > + > > + BUILD_BUG_ON(ARM64_HAS_ICH_HCR_EL2_TDIR <= ARM64_HAS_GICV3_CPUIF); > > + BUILD_BUG_ON(ARM64_HAS_ICH_HCR_EL2_TDIR <= ARM64_HAS_GICV5_LEGACY); > > + if (!cpus_have_cap(ARM64_HAS_GICV3_CPUIF) && > > + !is_midr_in_range_list(has_vgic_v3)) > > + return false; > > + > > + if (!is_hyp_mode_available()) > > + return false; > > + > > + if (cpus_have_cap(ARM64_HAS_GICV5_LEGACY)) > > + return true; > > + > > + if (is_kernel_in_hyp_mode()) > > + res.a1 = read_sysreg_s(SYS_ICH_VTR_EL2); > > + else > > + arm_smccc_1_1_hvc(HVC_GET_ICH_VTR_EL2, &res); > > We are reading the register on the current CPU and this capability, > being a SYSTEM_FEATURE, relies on the "probing CPU". If there CPUs > with differing values (which I don't think is practical, but hey, > never say..). This is would better be a > ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE, which would run through all > boot CPUs and would set the capability when it matches. While I agree that SYSTEM_FEATURE is most probably the wrong thing, I can't help but notice that - ARM64_HAS_GICV3_CPUIF, - ARM64_HAS_GIC_PRIO_MASKING - ARM64_HAS_GIC_PRIO_RELAXED_SYNC are all ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE. On the other ARM64_HAS_GICV5_LEGACY is ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE. Given that ARM64_HAS_ICH_HCR_EL2_TDIR is dependent on both ARM64_HAS_GICV3_CPUIF and ARM64_HAS_GICV5_LEGACY, shouldn't these two (and their dependencies) be aligned to have the same behaviour? Thanks, M. -- Without deviation from the norm, progress is not possible.