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 4C0C7271A9A; Tue, 4 Nov 2025 09:04:18 +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=1762247058; cv=none; b=rpYF5r3x9rquFIeB28peLGbIcjGPoxwYT8FSvQUbfdWYlM+WAKmT4jm3vzrD8nrJGw4T/zXJFfKVQFgGQpErOM4kxx5Bra0AMCWaI41KZvWuwz3JBa4533e222aqiG4BVgXQq5EbcdhszDLXsPaO4LXYhncVzcWVn9qXKLULbyM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762247058; c=relaxed/simple; bh=z10J5XPxAwVH3Vw4dBwDiXFrC7TpRWkdOo9+Yz5+U3s=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=moZ7ksgkESmM48HpAzkif13XuCbsegSmTJFlU7gmIR6VkgoAOq5nUSPZuEHj58ApbGtIeqmsmmy/YlyrzYkKWdlXM4wclmtwFTcd0b3eKyWJVCOKMsm+7EvKNiqcGzuZyeIzHEN2O93IHduNs/5I6U+75O+WiE6Fx5x3AO/KR1k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CmOWGoyB; 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="CmOWGoyB" 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) 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: 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 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.