From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oupton@kernel.org>,
Zenghui Yu <yuzenghui@huawei.com>,
Christoffer Dall <christoffer.dall@arm.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v3 1/5] KVM: arm64: GICv3: Don't advertise ICH_HCR_EL2.En==1 when no vgic is configured
Date: Mon, 17 Nov 2025 11:28:29 +0000 [thread overview]
Message-ID: <865xb8ucde.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTy93dmoTysS91+jFmey8ei55VWNUf-FsqVz9Ho4W1NWBQ@mail.gmail.com>
On Mon, 17 Nov 2025 10:34:36 +0000,
Fuad Tabba <tabba@google.com> wrote:
>
> Hi Marc,
>
> On Mon, 17 Nov 2025 at 09:15, Marc Zyngier <maz@kernel.org> 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 <broonie@kernel.org>
> > Tested-by: Mark Brown <broonie@kernel.org>
> > 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 <maz@kernel.org>
> > ---
> > 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.
next prev parent reply other threads:[~2025-11-17 11:28 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 9:15 [PATCH v3 0/5] KVM: arm64: Add LR overflow infrastructure (the dregs, the bad and the ugly) Marc Zyngier
2025-11-17 9:15 ` [PATCH v3 1/5] KVM: arm64: GICv3: Don't advertise ICH_HCR_EL2.En==1 when no vgic is configured Marc Zyngier
2025-11-17 10:34 ` Fuad Tabba
2025-11-17 11:28 ` Marc Zyngier [this message]
2025-11-17 11:29 ` Fuad Tabba
2025-11-17 9:15 ` [PATCH v3 2/5] KVM: arm64: GICv3: Completely disable trapping on vcpu exit Marc Zyngier
2025-11-17 10:36 ` Fuad Tabba
2025-11-17 9:15 ` [PATCH v3 3/5] KVM: arm64: GICv3: nv: Resync LRs/VMCR/HCR early for better MI emulation Marc Zyngier
2025-11-17 11:24 ` Fuad Tabba
2025-11-17 11:34 ` Marc Zyngier
2025-11-17 11:37 ` Fuad Tabba
2025-11-17 9:15 ` [PATCH v3 4/5] KVM: arm64: GICv3: Remove vgic_hcr workaround handling leftovers Marc Zyngier
2025-11-17 11:25 ` Fuad Tabba
2025-11-17 9:15 ` [PATCH v3 5/5] KVM: arm64: GICv3: Force exit to sync ICH_HCR_EL2.En Marc Zyngier
2025-11-17 11:35 ` Fuad Tabba
2025-11-17 11:42 ` Marc Zyngier
2025-11-17 11:48 ` Fuad Tabba
2025-11-18 7:16 ` Oliver Upton
2025-11-18 8:54 ` Marc Zyngier
2025-11-17 9:40 ` [PATCH v3 0/5] KVM: arm64: Add LR overflow infrastructure (the dregs, the bad and the ugly) Fuad Tabba
2025-11-17 9:54 ` Marc Zyngier
2025-11-17 10:18 ` Fuad Tabba
2025-11-17 12:54 ` Fuad Tabba
2025-11-18 7:20 ` Oliver Upton
2025-11-18 13:59 ` Fuad Tabba
2025-11-18 19:06 ` Marc Zyngier
2025-11-19 10:37 ` Fuad Tabba
2025-11-18 23:34 ` Oliver Upton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=865xb8ucde.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=christoffer.dall@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oupton@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).