[PATCH v1 2/8] KVM: arm64: Trap access to ALLINT if FEAT_NMI not supported by the guest

Marc Zyngier maz at kernel.org
Tue Nov 4 09:22:34 PST 2025


On Tue, 04 Nov 2025 15:30:34 +0000,
Fuad Tabba <tabba at google.com> wrote:
> 
> Hi Marc,
> 
> On Tue, 4 Nov 2025 at 15:15, Marc Zyngier <maz at kernel.org> wrote:
> >
> > On Tue, 04 Nov 2025 12:59:00 +0000,
> > Fuad Tabba <tabba at google.com> wrote:
> > >
> > > Access to ALLINT is part of FEAT_NMI. If a guest does not support this
> > > feature, any access to this register must be trapped to the hypervisor
> > > (EL2).
> > >
> > > KVM didn't configure this trap, potentially allowing a guest to toggle
> > > all interrupt mask when it doesn't support FEAT_NMI. Fix this by
> > > checking if the guest has FEAT_NMI support.
> > >
> > > Signed-off-by: Fuad Tabba <tabba at google.com>
> > > ---
> > >  arch/arm64/include/asm/kvm_emulate.h | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> > > index 0f8311263edf..3fc62808c548 100644
> > > --- a/arch/arm64/include/asm/kvm_emulate.h
> > > +++ b/arch/arm64/include/asm/kvm_emulate.h
> > > @@ -688,6 +688,9 @@ static inline void vcpu_set_hcrx(struct kvm_vcpu *vcpu)
> > >               else
> > >                       vcpu->arch.hcrx_el2 |= HCRX_EL2_MCE2;
> > >
> > > +             if (!kvm_has_feat(kvm, ID_AA64PFR1_EL1, NMI, IMP))
> > > +                     vcpu->arch.hcrx_el2 |= HCRX_EL2_TALLINT;
> > > +
> > >               if (kvm_has_tcr2(kvm))
> > >                       vcpu->arch.hcrx_el2 |= HCRX_EL2_TCR2En;
> > >
> >
> > I think this is moving in the wrong direction. We have for quite some
> > time now tried to automatically derive these behaviours from the guest
> > config, as we do for FGUs.
> >
> > I would like to see a similar behaviour being introduced for non-FGT
> > bits so that we don't have to worry about these things anymore.
> 
> I agree that we should make this more like FGT, but since that will
> likely require a bit more time (and probably a couple of respins),
> should we fix the HCRX traps as they are now?

I don't think this is fixing anything. Where does the trap go? There
is no triaging, no handling. At the very least, this needs to be
defined.

Thanks,

	M.

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



More information about the linux-arm-kernel mailing list