From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99D95CA5A; Tue, 25 Nov 2025 13:48:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764078487; cv=none; b=aolUfaoUbnOLR/7+of2hRjp2sdy/2XoJXmySTWMe9hLkpl7x3fHO6O1vuh2A7RQJ+P5WnancpjBfFtHFPTa8uKqKIUC+fVMGdE7vDTT+ockTLmJPqnJyAjIJ53BYn3AIVBGocIOD8DrnrY6SHoGU++YHOa0HA5bZZ0GkvCq+MCA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764078487; c=relaxed/simple; bh=v1vD+BGAe1IfybLjeiZYe5naHAG4W/wc0Z6DAqSf8Tw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=BA+usgR9B4KSwIWLiHkh6feAeWQw3yvaE+fowjkPOxdBubwlvQTBmkDNY35GN8hjT+Ug2jTXensW5BidKKwsqqBLRUfs7lVAZLbLQNqs5jA7Ke/sesQN+JVHVMkJOSN9/xAsU3S+yizDAZlU1uVYkWQjh7VD8/9N+ry0RFys1/Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kFEOUjxn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kFEOUjxn" 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) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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.