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 C0ABB3E3DB1; Tue, 3 Mar 2026 16:02:39 +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=1772553759; cv=none; b=SEkfMIP4yF4yDPJ3hnKFSr0PMfj0HMIWcpxECE7g4PwIx6DuMvvEW+0D7nkcOKv9FqPV+1VSSLH/OaihmaQGFxsf8PvVNRgNq7i698nBQZgURZ/lJOplJ5Pejzk5ynaUcPiu8zwkHhqUP3S3mxvpbm8HQlDas/mu4AYNMnFlRkg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772553759; c=relaxed/simple; bh=9GTxoPFm60nrBf/Iq0cAmUqQnqTieulX7wXH71jwZSI=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=X7nYnTgc45DwtJyUYhC2fJyKQl/QHlJOIQbZAZlRFmXiiK3X5jVMd8YtPwyIPxtYEwkSOafLHi5xk8Ck1sHD56xSCipZ7R6tVXVAXLXdcUACwOOVb8GCiD8x/oVpEuJemDO8v4hcUn4HUmCYjdvhAmE3d6agrkfgb/gVEfq8oss= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AnTRyR/q; 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="AnTRyR/q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99EAFC116C6; Tue, 3 Mar 2026 16:02:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772553759; bh=9GTxoPFm60nrBf/Iq0cAmUqQnqTieulX7wXH71jwZSI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AnTRyR/quwr3kHVi1iQrT4FoxLDBThUmIJRsNcJH4vKLpYlxzY+XYJB9BQcr22+d4 1PNJZRkeE+o/N+AlPawrGz3RY9KXOBLIDEx8AH4X/G2JIWhj8xhNrKroHY8tCSbj/L +6d9BzuvAQjh3sIYZDDcKAzQI1fPh8xK+In7aIiIMn/oIxY2TmeHQTzByPFiMjqOYE moP+eT899HVESHWPOTnZ1Qn43jmEq13zxTdL2hRE8LKgiIIDLw0ESiGGg+7FU0ADmK tJXq06s5qA5GUV5w3Kk/BoiPcuaIQZWkdTUIVGII2NIbomV1YtG/KYkPVKRRu7DgH5 cMVYc2u28FH8g== 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 1vxSCj-0000000FhU2-19fZ; Tue, 03 Mar 2026 16:02:37 +0000 Date: Tue, 03 Mar 2026 16:02:36 +0000 Message-ID: <868qc89a03.wl-maz@kernel.org> From: Marc Zyngier To: Sascha Bischoff Cc: "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "kvm@vger.kernel.org" , nd , "oliver.upton@linux.dev" , Joey Gouly , Suzuki Poulose , "yuzenghui@huawei.com" , "peter.maydell@linaro.org" , "lpieralisi@kernel.org" , Timothy Hayes , "jonathan.cameron@huawei.com" Subject: Re: [PATCH v5 12/36] KVM: arm64: gic-v5: Add emulation for ICC_IAFFIDR_EL1 accesses In-Reply-To: <20260226155515.1164292-13-sascha.bischoff@arm.com> References: <20260226155515.1164292-1-sascha.bischoff@arm.com> <20260226155515.1164292-13-sascha.bischoff@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: Sascha.Bischoff@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, nd@arm.com, oliver.upton@linux.dev, Joey.Gouly@arm.com, Suzuki.Poulose@arm.com, yuzenghui@huawei.com, peter.maydell@linaro.org, lpieralisi@kernel.org, Timothy.Hayes@arm.com, jonathan.cameron@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 26 Feb 2026 15:58:31 +0000, Sascha Bischoff wrote: > > GICv5 doesn't provide an ICV_IAFFIDR_EL1 or ICH_IAFFIDR_EL2 for > providing the IAFFID to the guest. A guest access to the > ICC_IAFFIDR_EL1 must therefore be trapped and emulated to avoid the > guest accessing the host's ICC_IAFFIDR_EL1. > > The virtual IAFFID is provided to the guest when it reads > ICC_IAFFIDR_EL1 (which always traps back to the hypervisor). Writes are > rightly ignored. KVM treats the GICv5 VPEID, the virtual IAFFID, and > the vcpu_id as the same, and so the vcpu_id is returned. > > The trapping for the ICC_IAFFIDR_EL1 is always enabled when in a guest > context. > > Co-authored-by: Timothy Hayes > Signed-off-by: Timothy Hayes > Signed-off-by: Sascha Bischoff > --- > arch/arm64/kvm/config.c | 10 +++++++++- > arch/arm64/kvm/sys_regs.c | 19 +++++++++++++++++++ > arch/arm64/kvm/vgic/vgic.h | 5 +++++ > 3 files changed, 33 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c > index e4ec1bda8dfcb..bac5f49fdbdef 100644 > --- a/arch/arm64/kvm/config.c > +++ b/arch/arm64/kvm/config.c > @@ -1684,6 +1684,14 @@ static void __compute_hdfgwtr(struct kvm_vcpu *vcpu) > *vcpu_fgt(vcpu, HDFGWTR_EL2) |= HDFGWTR_EL2_MDSCR_EL1; > } > > +static void __compute_ich_hfgrtr(struct kvm_vcpu *vcpu) > +{ > + __compute_fgt(vcpu, ICH_HFGRTR_EL2); > + > + /* ICC_IAFFIDR_EL1 *always* needs to be trapped when running a guest */ > + *vcpu_fgt(vcpu, ICH_HFGRTR_EL2) &= ~ICH_HFGRTR_EL2_ICC_IAFFIDR_EL1; > +} > + > void kvm_vcpu_load_fgt(struct kvm_vcpu *vcpu) > { > if (!cpus_have_final_cap(ARM64_HAS_FGT)) > @@ -1705,7 +1713,7 @@ void kvm_vcpu_load_fgt(struct kvm_vcpu *vcpu) > } > > if (cpus_have_final_cap(ARM64_HAS_GICV5_CPUIF)) { > - __compute_fgt(vcpu, ICH_HFGRTR_EL2); > + __compute_ich_hfgrtr(vcpu); > __compute_fgt(vcpu, ICH_HFGWTR_EL2); > __compute_fgt(vcpu, ICH_HFGITR_EL2); > } > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index b8b86f5e1adc1..384824e875603 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -681,6 +681,24 @@ static bool access_gic_dir(struct kvm_vcpu *vcpu, > return true; > } > > +static bool access_gicv5_iaffid(struct kvm_vcpu *vcpu, struct sys_reg_params *p, > + const struct sys_reg_desc *r) > +{ > + if (!kvm_has_gicv5(vcpu->kvm)) > + return undef_access(vcpu, p, r); Do we really need this? If the guest doesn't have FEAT_GCIE, then we should have an FGU bit set for any FGT bit that control a GCIE register, and that register should UNDEF at the point of triaging the trap, and never reach this handler. If it doesn't, we have bigger problems, and we should address them. Thanks, M. -- Without deviation from the norm, progress is not possible.