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

[Fuad Tabba]

On Tue, 4 Nov 2025 at 17:22, Marc Zyngier <maz at kernel.org> wrote:
>
> 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.

Right... I was thinking of protected VMs, but much of that code isn't
yet upstream. I'll start working on handling these traps similar to
the FGU handling, so it's ready when we start upstreaming the rest of
pKVM (soon I hope).

Cheers,
/fuad


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