From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 52DFF3D47A1; Sun, 13 Sep 2026 10:00:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789293630; cv=none; b=YgGGkZrzjeX6wE/TSm60mVPEUBOdm+gusnbyN5PkUTalxxRFPtHXRmefVciWAn1F+n6PzMbhl4XxRErrDr/+1pEu6aXBVsQiE9DlVAAJ40lvIBJXeUPisJMqqhRy+8MMiU5sTN5aifnv+ktqDhkRmM5QaiIf5G9DR9i+B8hUU+Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789293630; c=relaxed/simple; bh=9iHFkTGe08yADbf2MXnHpT84LIP8xl+f6E9L6ji2wWg=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=tF80U9DMxyGtV4cTyvRFkBdAdA/MteshCEnZk5adCw9uQaUdRNCLPnBDXQT4j2rbDAosAA1PyBSNJ8qRuVkdfOp3Kx0ZH/JHm35+8hcMNHsgIBlALNlI3Lku00a70hRxLjn+5s80qc1v1YWBX+3ZGaPAKGasYlqDHSHwmV3q45E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Uc6NE47J; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Uc6NE47J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E47681F000FF; Sun, 13 Sep 2026 10:00:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789293628; bh=yUhB/Xmeg30XhsREq6iJc4tei3Cw+4oVMaJgqTQh/Fc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Uc6NE47JoD/TgSICJzC9SdlxuYriLqEXrEj0yirkshjjUGO6AHRmOAQjrGSAmHuQs OW1o6PG5y9h2o+0vr708O/w9wlf+IYDBHfH0+me2FHMjD5AdpIVzuGI2NsPsfslrC0 riPzzTtYiGDNn8ml/Q6kbT9ApTq92plRWS73gaNWOyt83mO2Yi5l3BVoEZ03ilITWF NHUfCiUsMdsPzoQOo3rUdrHiRsgeNK0qPMjgTTVIKNi8S8YSqvpVAEph9NQAs7k/Vv Sm4OPvzPQxllggLz4EKAPOVzRuKxZtOPxmZxHaPunPtYl0HZEOYq9Ix7BbYvTheHQQ M/lqZ1qsO1E4A== 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 1x5h0c-00000008GHI-39tq; Sun, 13 Sep 2026 10:00:26 +0000 Date: Sun, 13 Sep 2026 11:00:26 +0100 Message-ID: <868q5579ol.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Oliver Upton , Catalin Marinas , Will Deacon , James Morse , Ben Horgan , Xi Ruoyao , Mark Rutland , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Steffen Eiden , Gavin Shan , Yuan Yao , Fuad Tabba , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] KVM: arm64: Trap guest MPAM accesses whenever MPAM is implemented In-Reply-To: <20260911104715.307500-1-fuad.tabba@linux.dev> References: <20260911104715.307500-1-fuad.tabba@linux.dev> 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: linux-kernel@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: fuad.tabba@linux.dev, oupton@kernel.org, catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, ben.horgan@arm.com, xry111@xry111.site, mark.rutland@arm.com, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, seiden@linux.ibm.com, gshan@redhat.com, yaoyuan@linux.alibaba.com, tabba@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.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 Fri, 11 Sep 2026 11:47:15 +0100, Fuad Tabba wrote: > > finalise_el2_state() clears the EL2 MPAM traps whenever the ID > registers advertise MPAM, while KVM sets them only under ARM64_MPAM, > which also requires MPAMEN. Without EL3 nothing sets that enable, so a > guest reaches the MPAM registers while ID_AA64PFR0_EL1.MPAM reads 0 > for it. > > Gate on what finalise_el2_state() tests instead: this CPU's ID > registers with the arm64.nompam override applied, and its > MPAMIDR_EL1.HAS_HCR before writing MPAMHCR_EL2, which is UNDEFINED > without it. MPAMEN isn't a term in any MPAM accessor, so the traps > take effect without it. > > Fixes: 31ff96c38ea3 ("KVM: arm64: Fix missing traps of guest accesses to the MPAM registers") > Signed-off-by: Fuad Tabba > --- > > Notes: > Changes since v2: > - A per-CPU flag in kvm_host_data, set at KVM's CPU init from the ID > registers with the override applied, instead of a third cpucap > (Will). The probe checks presence only, since MPAM3_EL3.TRAPLOWER > can't be read at EL2. > - The MPAMHCR_EL2 branch reads this CPU's MPAMIDR_EL1 rather than the > sanitised ARM64_MPAM_HCR, which would otherwise have been the one > system-wide test left in a per-CPU function. > - Fixes: names the KVM commit that left this case open, rather than > the head.S commit that cleared the traps. > - Yuan's Reviewed-by dropped, since the mechanism changed. > > v2: https://lore.kernel.org/all/20260908145651.2828597-1-fuad.tabba@linux.dev/ > v1: https://lore.kernel.org/all/20260903160819.831518-1-fuad.tabba@linux.dev/ > > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/arm.c | 7 +++++++ > arch/arm64/kvm/hyp/include/hyp/switch.h | 13 ++++++++----- > 3 files changed, 16 insertions(+), 5 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index 27fe0cd5b2d7a..98ca2d9b9e18d 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -755,6 +755,7 @@ struct kvm_host_data { > #define KVM_HOST_DATA_FLAG_VCPU_IN_HYP_CONTEXT 4 > #define KVM_HOST_DATA_FLAG_L1_VNCR_MAPPED 5 > #define KVM_HOST_DATA_FLAG_HAS_BRBE 6 > +#define KVM_HOST_DATA_FLAG_HAS_MPAM 7 > unsigned long flags; > > struct kvm_cpu_context host_ctxt; > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 8b080804bc90b..fde75a63cf045 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -2281,9 +2281,16 @@ static void cpu_set_hyp_vector(void) > > static void cpu_hyp_init_context(void) > { > + u64 pfr0 = __read_sysreg_by_encoding(SYS_ID_AA64PFR0_EL1); > + u64 pfr1 = __read_sysreg_by_encoding(SYS_ID_AA64PFR1_EL1); > + Why not directly read_sysreg(id_aa64pfr0_el1) and co? __read_sysreg_by_encoding() is useful when the encoding comes from a variable, but it looks odd in the case of a literal sysreg. > kvm_init_host_cpu_context(host_data_ptr(host_ctxt)); > kvm_init_host_debug_data(); > > + /* The traps take effect without MPAMEN, which ARM64_MPAM requires. */ > + if (id_aa64pfr0_mpam(pfr0) || id_aa64pfr1_mpamfrac(pfr1)) > + host_data_set_flag(HAS_MPAM); > + > if (!is_kernel_in_hyp_mode()) > cpu_init_hyp_mode(); > } > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h > index 1ce7130e25490..2cb611e2bd69b 100644 > --- a/arch/arm64/kvm/hyp/include/hyp/switch.h > +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h > @@ -298,14 +298,17 @@ static inline void __activate_traps_mpam(struct kvm_vcpu *vcpu) > u64 clr = MPAM2_EL2_EnMPAMSM; > u64 set = MPAM2_EL2_TRAPMPAM0EL1 | MPAM2_EL2_TRAPMPAM1EL1; > > - if (!system_supports_mpam()) > + if (!host_data_test_flag(HAS_MPAM)) > return; > > /* trap guest access to MPAMIDR_EL1 */ > - if (system_supports_mpam_hcr()) { > + if (read_sysreg_s(SYS_MPAMIDR_EL1) & MPAMIDR_EL1_HAS_HCR) { This is going to suck under NV. The host hypervisor is of course going to set MPAMHCR_EL2.TRAP_MPAMIDR_EL1, and we're in for a recursive trap on the hottest possible path in KVM. Which is silly as the actual write to MPAMHCR_EL2 is free (it lands in NVMem[]). This really should be replaced by a flag called HAS_MPAM_HCR, just like you have HAS_MPAM. Thanks, M. -- Without deviation from the norm, progress is not possible.