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 08F90CCF9E3 for ; Tue, 4 Nov 2025 09:04:27 +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=IwEMqVRyW+DM9x4io5wXKO1giayzNI8wOXqTlEhm7NM=; b=tvib2/AWAcyufRaYswwcqvQrXR l0MaOwHhbCSUEOK4YowzrscNi8aI3hvTERCCwRScwYpFbNe1mct7vVA66Lu8gca6NfH6sr8aydjl5 HJNW7ZvL846UX+S2FRRToFrjvh8MC+VfdPQ9S2ULimsT0RGicYEWi5kXA0DvseIfrfGbGsWFIad+0 IpU3v53eGbSX/+M7Sp3YynqSjhRlDRSptXMka4fSdo5YCfVnT53DKoosnA+WJNRamNB5hNmcoK+8k J0fNmD1cu9BwYSO7PVBjLMFWibVPskKiyj3lz165t1wx4fn+muamFJfIg79/BmSmEM4jlbSyy+Pr9 tBumAG6w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vGCxh-0000000BVL7-00HL; Tue, 04 Nov 2025 09:04:21 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vGCxe-0000000BVKQ-1rY9 for linux-arm-kernel@lists.infradead.org; Tue, 04 Nov 2025 09:04:19 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 12D0E43F1D; Tue, 4 Nov 2025 09:04:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3CD0C4CEF7; Tue, 4 Nov 2025 09:04:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762247057; bh=z10J5XPxAwVH3Vw4dBwDiXFrC7TpRWkdOo9+Yz5+U3s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CmOWGoyBs6fv7yEP1oOt+ocymgiht9JSc073prHK7Y1Vd2sHCpXOKfLRTGtm0pzUL VAsQIugWwVZkiD46IS4Le+SzHft6GDpinZc8Z64WFMsRhkc4hCGMC82WcwW1yEPfpN nagGB2wvclRW1ZZiKKp6/YPrmqWXmoRy2XyvmVbpNgjgXpTMbyTeJn8nW6fi3cPHFH Jeb0FTmohhbn2bnvkWtSL1kKuGDQjjFsbRPaYYig9/ao/wTuLtiN2ofk6+et3CphnP xrHYXnb8y5SukMy+mjYWoF3065PLs1Xi6YlnZ4PEHk0w0jzGai+3XAhGLYndAZR1v3 r4GLYo8dhq1QA== 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 1vGCxb-00000002E8l-25h3; Tue, 04 Nov 2025 09:04:15 +0000 Date: Tue, 04 Nov 2025 09:04:15 +0000 Message-ID: <86ikfquq28.wl-maz@kernel.org> From: Marc Zyngier To: Yao Yuan Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Christoffer Dall , Volodymyr Babchuk Subject: Re: [PATCH 05/33] KVM: arm64: GICv3: Detect and work around the lack of ICV_DIR_EL1 trapping In-Reply-To: References: <20251103165517.2960148-1-maz@kernel.org> <20251103165517.2960148-6-maz@kernel.org> 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: yaoyuan@linux.alibaba.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, christoffer.dall@arm.com, Volodymyr_Babchuk@epam.com 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-20251104_010418_522234_4A8F4EC6 X-CRM114-Status: GOOD ( 29.78 ) 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, 04 Nov 2025 08:50:26 +0000, Yao Yuan wrote: > > On Mon, Nov 03, 2025 at 04:54:49PM +0800, 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. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/virt.h | 7 ++++++- > > arch/arm64/kernel/cpufeature.c | 34 ++++++++++++++++++++++++++++++++++ > > arch/arm64/kernel/hyp-stub.S | 5 +++++ > > arch/arm64/kvm/vgic/vgic-v3.c | 3 +++ > > arch/arm64/tools/cpucaps | 1 + > > 5 files changed, 49 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..44103ad98805d 100644 > > --- a/arch/arm64/kernel/cpufeature.c > > +++ b/arch/arm64/kernel/cpufeature.c > > @@ -2303,6 +2303,31 @@ 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) > > +{ > > + struct arm_smccc_res res = {}; > > + > > + BUILD_BUG_ON(ARM64_HAS_ICH_HCR_EL2_TDS <= ARM64_HAS_GICV3_CPUIF); > > + BUILD_BUG_ON(ARM64_HAS_ICH_HCR_EL2_TDS <= ARM64_HAS_GICV5_LEGACY); > > + if (!cpus_have_cap(ARM64_HAS_GICV3_CPUIF) || > > + !cpus_have_cap(ARM64_HAS_GICV3_CPUIF)) > > Duplicated checking ? Yup, cut'n'paste, and lack of GICv5 testing... This should really look like the hack below, since GICv5 legacy feature is guaranteed to have TDIR: diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 44103ad98805d..3f2d4b033966d 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -2310,13 +2310,15 @@ static bool can_trap_icv_dir_el1(const struct arm64_cpu_capabilities *entry, BUILD_BUG_ON(ARM64_HAS_ICH_HCR_EL2_TDS <= ARM64_HAS_GICV3_CPUIF); BUILD_BUG_ON(ARM64_HAS_ICH_HCR_EL2_TDS <= ARM64_HAS_GICV5_LEGACY); - if (!cpus_have_cap(ARM64_HAS_GICV3_CPUIF) || - !cpus_have_cap(ARM64_HAS_GICV3_CPUIF)) + if (!cpus_have_cap(ARM64_HAS_GICV3_CPUIF)) 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 Thanks for the heads-up! M. -- Without deviation from the norm, progress is not possible.