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 05CAA22F389; Mon, 17 Nov 2025 11:28:32 +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=1763378913; cv=none; b=cRTbe8ly6KUPJBC1ChBZ2Xd1N90qPVNBlrMCILTZe+38orUJnuhcZBsvmS5xJUIhBpk0ueV/+VUTh/FjeJJKfdmtPWTWJNkTCKw4okvdNqg3pTdPWLad/aVqBvqrzq2KUR2s135dMYO+U4AFJs4R4oFpKn7PHHI9R2LxpTLpf7I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763378913; c=relaxed/simple; bh=hdkCa9GLlXOFEKazFI6YIXZl54t/xf43XIXxQ2WHmsQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=HM1OVo5DOZj+E6vvkTmZtZhpJ9Mp+rBVwaIwFc/H04pEr12yqSahHjIZA66T9mMZqBqjcJoGo+REQ9je29rzVFXOS+KYdYcdLgY80F7wAFl/p1S6BQ+J6Ak7mDE3e9y/llXKIfuKNlQ/IBCEPw/gN3H5WEP6fDigoB0FLWMnfaQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=olpCmwZH; 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="olpCmwZH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 796A8C19425; Mon, 17 Nov 2025 11:28:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763378912; bh=hdkCa9GLlXOFEKazFI6YIXZl54t/xf43XIXxQ2WHmsQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=olpCmwZHh7kRdwZ4Jdn8CAsbf0cuwdmdL6osbk/mw3mfqndJ+zZDdknmVGSVqubdD lYAsqjPAqieDGa2khqIcc5/el0L6nPbI/fyek2jo2fvr9Ue/QHLHx2PY81ufUuZJq/ Le/IKSaRLwhqzbWtJv7qTLjfEhkFgGjrVCvKUrbpFmvgzx69s2IXY3JaXmgpqzwReh 1300KU9uFOY7KElD+QRCawUPhrAHT5Rnl+76TpPcDx5fJdlwzzXdLLxddY9t5xl3va e0CoValZiyzMpnDVJ250cNF3QMWajt320UsXZU5y3+e7MXYRHR2fg4muElg5CqRyeP hUylNU+7PdAaA== 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 1vKxPK-00000005ndG-0LVa; Mon, 17 Nov 2025 11:28:30 +0000 Date: Mon, 17 Nov 2025 11:28:29 +0000 Message-ID: <865xb8ucde.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba 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 , Mark Brown Subject: Re: [PATCH v3 1/5] KVM: arm64: GICv3: Don't advertise ICH_HCR_EL2.En==1 when no vgic is configured In-Reply-To: References: <20251117091527.1119213-1-maz@kernel.org> <20251117091527.1119213-2-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: tabba@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.com, christoffer.dall@arm.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 Mon, 17 Nov 2025 10:34:36 +0000, Fuad Tabba wrote: > > Hi Marc, > > On Mon, 17 Nov 2025 at 09:15, Marc Zyngier wrote: > > > > Configuring GICv3 to deal with the lack of GIC in the guest relies > > on not setting ICH_HCR_EL2.En in the shadow register, as this is > > an indication of the fact that we want to trap all system registers > > to report an UNDEF in the guest. > > > > Make sure we leave vgic_hcr untouched in this case. > > > > Reported-by: Mark Brown > > Tested-by: Mark Brown > > Closes: https://lore.kernel.org/r/72e1e8b5-e397-4dc5-9cd6-a32b6af3d739@sirena.org.uk > > Fixes: 877324a1b5415 ("KVM: arm64: Revamp vgic maintenance interrupt configuration") > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/vgic/vgic-v3.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c > > index 598621b14a30d..1d6dd1b545bdd 100644 > > --- a/arch/arm64/kvm/vgic/vgic-v3.c > > +++ b/arch/arm64/kvm/vgic/vgic-v3.c > > @@ -26,6 +26,9 @@ void vgic_v3_configure_hcr(struct kvm_vcpu *vcpu, > > { > > struct vgic_v3_cpu_if *cpuif = &vcpu->arch.vgic_cpu.vgic_v3; > > > > + if (!irqchip_in_kernel(vcpu->kvm)) > > + return; > > + > > Bear with me, since I'm not too familiar with this code. This is the > only function that initializes cpuif->vgic_hcr. Should we be > explicitly setting it to 0, or warn if ICH_HCR_EL2_En is set? It must be zero by construction, as the vcpu structure (which this is part of) is always zeroed at allocation time, and the only way to populate this field to have created an irqchip and start populating the shadow structure, right after this test. If we start doubting the state of bits of the vcpu structure that should never be written to because of some particular configuration, then we should address this globally, not piecemeal. Thanks, M. -- Without deviation from the norm, progress is not possible.