Linux KVM/arm64 development list
 help / color / mirror / Atom feed
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

  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