[PATCH] KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT

[PATCH] KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT

[Gustavo Romero]

Currently, kvm_vcpu_load_fgt() returns early when the CPU lacks FEAT_FGT,
so the per-vCPU ICH_HFGRTR_EL2, ICH_HFGWTR_EL2 and ICH_HFGITR_EL2 values
are never computed and stay 0, meaning any access to several GICv5
registers will trap, like an access to ICC_PPI_PRIORITYR0_EL1.

On the other hand, __activate_traps_ich_hfgxtr() is gated only on the
GICv5 CPU interface and writes them on every guest entry, which is
correct.

Returning early when the CPU lacks FEAT_FGT and leaving the GICv5 traps
enabled can lead to a KVM "Unsupported guest access at" error when a
GICv5 register access by the guest traps to KVM, because the register
has no emulation handler.

A real machine with no FEAT_FGT and with GICv5 support enabled is
unlikely to exist, but such a setup can happen on some simulators, like
FVP with the following flags:

-C cluster0.has_arm_v8-5=1
-C bp.is_gicv5_used=1

Hence, because the ICH trap registers are part of FEAT_GCIE, not part of
FEAT_FGT, compute them before the FGT check, making this computation
independent of FEAT_FGT.

Fixes: 9d6d9514c08f ("KVM: arm64: gic-v5: Support GICv5 FGTs & FGUs")
Signed-off-by: Gustavo Romero <gromero@redhat.com>
---
 arch/arm64/kvm/config.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
index 1053676551af..8a526704af59 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;
 
@@ -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);
-	}
 }
-- 
2.47.3

Re: [PATCH] KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT

[sashiko-bot]

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

Re: [PATCH] KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT

[Gustavo Romero]

Hi robot,

On Tue, Oct 20, 2026 at 10:53:22AM +0000, sashiko-bot@kernel.org wrote:
> 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?

I guess you're right but it was already addressed by Fuad's patch:

https://lore.kernel.org/all/20260929090031.3829185-2-fuad.tabba@linux.dev/

that is already in the mainline:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4bdd2b3a708c1feb701cb8b62feb8ad2fd77bb07

Maybe you're looking at some branch that doesn't have this fix?


Cheers,
Gustavo
 
> 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
> 

Re: [PATCH] KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT

[Sascha Bischoff]

Hi Gustavo,

On 20/10/2026 11:41, Gustavo Romero wrote:
> Currently, kvm_vcpu_load_fgt() returns early when the CPU lacks FEAT_FGT,
> so the per-vCPU ICH_HFGRTR_EL2, ICH_HFGWTR_EL2 and ICH_HFGITR_EL2 values
> are never computed and stay 0, meaning any access to several GICv5
> registers will trap, like an access to ICC_PPI_PRIORITYR0_EL1.

This is never a valid configuration for GICv5 on a system that has EL2, 
i.e., one that supports KVM.

* FEAT_GCIE (GICv5) is optional from v9.3.
* FEAT_FGT is mandatory from v8.6, if an implementation has EL2 or EL3.
* v9.1 must be v8.6 compliant.
* If we are running KVM, we must have EL2.

There's no way to legally have GICv5 without also having support for 
FEAT_FGT.

FWIW, Marc caught me making the same mistake:

https://lore.kernel.org/all/86o6o3oehl.wl-maz@kernel.org/

> 
> On the other hand, __activate_traps_ich_hfgxtr() is gated only on the
> GICv5 CPU interface and writes them on every guest entry, which is
> correct.
> 
> Returning early when the CPU lacks FEAT_FGT and leaving the GICv5 traps
> enabled can lead to a KVM "Unsupported guest access at" error when a
> GICv5 register access by the guest traps to KVM, because the register
> has no emulation handler.
> 
> A real machine with no FEAT_FGT and with GICv5 support enabled is
> unlikely to exist

Given the above, very unlikely. I hope... :)

> , but such a setup can happen on some simulators, like
> FVP with the following flags:
> 
> -C cluster0.has_arm_v8-5=1
> -C bp.is_gicv5_used=1

Even if the simulator allows it, it isn't a valid configuration. You 
want v9.3 or greater here. Moreover, we shouldn't be writing code to 
support architecturally invalid configurations.

Thanks,
Sascha

> 
> Hence, because the ICH trap registers are part of FEAT_GCIE, not part of
> FEAT_FGT, compute them before the FGT check, making this computation
> independent of FEAT_FGT.
> 
> Fixes: 9d6d9514c08f ("KVM: arm64: gic-v5: Support GICv5 FGTs & FGUs")
> Signed-off-by: Gustavo Romero <gromero@redhat.com>
> ---
>   arch/arm64/kvm/config.c | 12 ++++++------
>   1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
> index 1053676551af..8a526704af59 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;
>   
> @@ -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);
> -	}
>   }

Re: [PATCH] KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT

[Gustavo Romero]

Hi Sascha,

On Tue, Oct 20, 2026 at 01:45:43PM +0100, Sascha Bischoff wrote:
> Hi Gustavo,
> 
> On 20/10/2026 11:41, Gustavo Romero wrote:
> > Currently, kvm_vcpu_load_fgt() returns early when the CPU lacks FEAT_FGT,
> > so the per-vCPU ICH_HFGRTR_EL2, ICH_HFGWTR_EL2 and ICH_HFGITR_EL2 values
> > are never computed and stay 0, meaning any access to several GICv5
> > registers will trap, like an access to ICC_PPI_PRIORITYR0_EL1.
> 
> This is never a valid configuration for GICv5 on a system that has EL2,
> i.e., one that supports KVM.
> 
> * FEAT_GCIE (GICv5) is optional from v9.3.
> * FEAT_FGT is mandatory from v8.6, if an implementation has EL2 or EL3.
> * v9.1 must be v8.6 compliant.
> * If we are running KVM, we must have EL2.
> 
> There's no way to legally have GICv5 without also having support for
> FEAT_FGT.
> 
> FWIW, Marc caught me making the same mistake:
> 
> https://lore.kernel.org/all/86o6o3oehl.wl-maz@kernel.org/

oh, so you've been there already :)

Thanks a lot for pointing me to that discussion.


> > 
> > On the other hand, __activate_traps_ich_hfgxtr() is gated only on the
> > GICv5 CPU interface and writes them on every guest entry, which is
> > correct.
> > 
> > Returning early when the CPU lacks FEAT_FGT and leaving the GICv5 traps
> > enabled can lead to a KVM "Unsupported guest access at" error when a
> > GICv5 register access by the guest traps to KVM, because the register
> > has no emulation handler.
> > 
> > A real machine with no FEAT_FGT and with GICv5 support enabled is
> > unlikely to exist
> 
> Given the above, very unlikely. I hope... :)
> 
> > , but such a setup can happen on some simulators, like
> > FVP with the following flags:
> > 
> > -C cluster0.has_arm_v8-5=1
> > -C bp.is_gicv5_used=1
> 
> Even if the simulator allows it, it isn't a valid configuration. You want
> v9.3 or greater here. Moreover, we shouldn't be writing code to support
> architecturally invalid configurations.

Yeah, I agree.

Now I also see the code has the assumption that FEAT_GCIE always imply FEAT_FGT,
but FEAT_FGT does not imply FEAT_GCIE, so indeed these two features are, in that
sense, not totally independent.

BTW, the output in the thread you pointed out:

	(FEAT_GCIE ==> v9Ap3)
	(FEAT_FGT ==> v8Ap5)
	(v9Ap3 ==> (v9Ap2 && v8Ap8))

seems some form of processed AARCHMRS. Are you folks using any script to digest
it?


Cheers,
Gustavo

> Thanks,
> Sascha
> 
> > 
> > Hence, because the ICH trap registers are part of FEAT_GCIE, not part of
> > FEAT_FGT, compute them before the FGT check, making this computation
> > independent of FEAT_FGT.
> > 
> > Fixes: 9d6d9514c08f ("KVM: arm64: gic-v5: Support GICv5 FGTs & FGUs")
> > Signed-off-by: Gustavo Romero <gromero@redhat.com>
> > ---
> >   arch/arm64/kvm/config.c | 12 ++++++------
> >   1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
> > index 1053676551af..8a526704af59 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;
> > @@ -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);
> > -	}
> >   }
> 

Re: [PATCH] KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT

[Marc Zyngier]

On Tue, 20 Oct 2026 15:03:24 +0100,
Gustavo Romero <gromero@redhat.com> wrote:
> 
> BTW, the output in the thread you pointed out:
> 
> 	(FEAT_GCIE ==> v9Ap3)
> 	(FEAT_FGT ==> v8Ap5)
> 	(v9Ap3 ==> (v9Ap2 && v8Ap8))
> 
> seems some form of processed AARCHMRS. Are you folks using any script to digest
> it?

See the tooling branch in [1]. You can point the scripts at any of the
commits to pick the version of the JSON you want.

	M.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/maz/AARCHMRS

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH] KVM: arm64: Decouple computation of the GICv5 trap registers from FEAT_FGT

[Gustavo Romero]

On Tue, Oct 20, 2026 at 03:15:43PM +0100, Marc Zyngier wrote:
> On Tue, 20 Oct 2026 15:03:24 +0100,
> Gustavo Romero <gromero@redhat.com> wrote:
> > 
> > BTW, the output in the thread you pointed out:
> > 
> > 	(FEAT_GCIE ==> v9Ap3)
> > 	(FEAT_FGT ==> v8Ap5)
> > 	(v9Ap3 ==> (v9Ap2 && v8Ap8))
> > 
> > seems some form of processed AARCHMRS. Are you folks using any script to digest
> > it?
> 
> See the tooling branch in [1]. You can point the scripts at any of the
> commits to pick the version of the JSON you want.

Thanks, Marc!


Cheers,
Gustavo

> 	M.
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/maz/AARCHMRS
> 
> -- 
> Without deviation from the norm, progress is not possible.
>