From: sashiko-bot@kernel.org
To: "Gustavo Romero" <gromero@redhat.com>, kvmarm@lists.linux.dev
Cc: "Oliver Upton" <oupton@kernel.org>, "Marc Zyngier" <maz@kernel.org>
Subject: Re: [PATCH] KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT
Date: Tue, 20 Oct 2026 10:53:22 +0000 [thread overview]
Message-ID: <sashiko-outbox-178860@kernel.org> (raw)
In-Reply-To: <20261020104138.2641586-1-gromero@redhat.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] KVM: arm64: populate_nv_trap_config() skips GICv5 FGTs when FEAT_FGT is absent
--
commit 78d2daa299df3d77e7dfa794f19cd0a1eee7919c
Author: Gustavo Romero <gromero@redhat.com>
KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT
This commit moves the computation of ICH_HFGRTR_EL2, ICH_HFGWTR_EL2, and
ICH_HFGITR_EL2 in kvm_vcpu_load_fgt() ahead of the ARM64_HAS_FGT check so
that GICv5 trap register values are computed whenever ARM64_HAS_GICV5_CPUIF
is present, even if the CPU lacks FEAT_FGT.
> diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
> index e93919cadf860..0833453efe4bb 100644
> --- a/arch/arm64/kvm/config.c
> +++ b/arch/arm64/kvm/config.c
> @@ -1744,6 +1744,12 @@ static void __compute_ich_hfgwtr(struct kvm_vcpu *vcpu)
>
> void kvm_vcpu_load_fgt(struct kvm_vcpu *vcpu)
> {
> + if (cpus_have_final_cap(ARM64_HAS_GICV5_CPUIF)) {
> + __compute_ich_hfgrtr(vcpu);
> + __compute_ich_hfgwtr(vcpu);
> + __compute_fgt(vcpu, ICH_HFGITR_EL2);
> + }
> +
> if (!cpus_have_final_cap(ARM64_HAS_FGT))
> return;
[Severity: High]
Does populate_nv_trap_config() in arch/arm64/kvm/emulate-nested.c also need
to be updated to store the ICH_HFGRTR_GROUP and ICH_HFGITR_GROUP entries into
sr_forward_xa when ARM64_HAS_GICV5_CPUIF is present but ARM64_HAS_FGT is
absent?
Currently, populate_nv_trap_config() skips storing any entry into
sr_forward_xa when ARM64_HAS_FGT is not supported:
arch/arm64/kvm/emulate-nested.c:populate_nv_trap_config() {
...
for_each_encoding_in(enc, fgt->encoding, fgt->end) {
...
if (!cpus_have_final_cap(ARM64_HAS_FGT))
continue;
prev = xa_store(&sr_forward_xa, enc,
xa_mk_value(tc.val), GFP_KERNEL);
...
}
}
Because of that, on a system with ARM64_HAS_GICV5_CPUIF and !ARM64_HAS_FGT,
the GICv5 entries in sr_forward_xa are left with tc.fgt == __NO_FGT_GROUP__
(populated only with tc.sri by populate_sysreg_config() for registers in
sys_reg_descs[], or left at 0 for all other GICv5 registers and instructions).
When a guest running without FEAT_GCIE (for example, a GICv3 guest in
compatibility mode, or a VM where ID_AA64PFR2_EL1.GCIE was cleared) executes
a GICv5 system register or instruction access, kvm_vcpu_load_fgt() has
cleared the trap bits in ICH_HFGRTR_EL2, ICH_HFGWTR_EL2, and ICH_HFGITR_EL2
from kvm->arch.fgu[], so the access traps to kvm_handle_sys_reg() ->
triage_sysreg_trap():
arch/arm64/kvm/emulate-nested.c:triage_sysreg_trap() {
...
if (tc.fgt != __NO_FGT_GROUP__ &&
(vcpu->kvm->arch.fgu[tc.fgt] & BIT(tc.bit))) {
kvm_inject_undefined(vcpu);
return true;
}
...
}
With tc.fgt == __NO_FGT_GROUP__, this FGU check is bypassed instead of
injecting an UNDEF:
- A guest read of SYS_ICC_PPI_ENABLER0_EL1 or SYS_ICC_PPI_ENABLER1_EL1
dispatches to access_gicv5_ppi_enabler() in arch/arm64/kvm/sys_regs.c with
!p->is_write, triggering WARN_ON_ONCE(!p->is_write).
- A guest write to SYS_ICC_PPI_ENABLER0_EL1 dispatches to
access_gicv5_ppi_enabler() and writes to
vcpu->arch.vgic_cpu.vgic_v5.vgic_ppi_enabler, which shares a union with
vgic_v3 in struct vgic_cpu.
- Guest reads of SYS_ICC_IDR0_EL1 or SYS_ICC_IAFFIDR_EL1 execute
access_gicv5_idr0() or access_gicv5_iaffid() instead of injecting UNDEF.
- Guest accesses to other GICv5 registers or instructions fall through to the
local label with !tc.sri and log "Unsupported guest access at:" on the host
before injecting UNDEF.
>
> @@ -1761,10 +1767,4 @@ void kvm_vcpu_load_fgt(struct kvm_vcpu *vcpu)
> __compute_fgt(vcpu, HDFGRTR2_EL2);
> __compute_fgt(vcpu, HDFGWTR2_EL2);
> }
> -
> - if (cpus_have_final_cap(ARM64_HAS_GICV5_CPUIF)) {
> - __compute_ich_hfgrtr(vcpu);
> - __compute_ich_hfgwtr(vcpu);
> - __compute_fgt(vcpu, ICH_HFGITR_EL2);
> - }
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261020104138.2641586-1-gromero@redhat.com?part=1
next prev parent reply other threads:[~2026-10-20 10:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 10:41 [PATCH] KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT Gustavo Romero
2026-10-20 10:53 ` sashiko-bot [this message]
2026-10-20 12:33 ` Gustavo Romero
2026-10-20 12:45 ` Sascha Bischoff
2026-10-20 14:03 ` Gustavo Romero
2026-10-20 14:15 ` Marc Zyngier
2026-10-20 14:32 ` Gustavo Romero
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=sashiko-outbox-178860@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=gromero@redhat.com \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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