[PATCH v3 8/9] KVM: arm64: pkvm: Report optional ID register traps with a 0x18 syndrome

Marc Zyngier maz at kernel.org
Thu Dec 4 04:06:04 PST 2025


On Thu, 04 Dec 2025 10:51:19 +0000,
Ben Horgan <ben.horgan at arm.com> wrote:
> 
> Hi Marc,
> 
> On 12/4/25 09:48, Marc Zyngier wrote:
> > With FEAT_IDST, unimplemented system registers in the feature ID space
> > must be reported using EC=0x18 at the closest handling EL, rather than
> > with an UNDEF.
> > 
> > Most of these system registers are always implemented thanks to their
> > dependency on FEAT_AA64, except for a set of (currently) three registers:
> > GMID_EL1 (depending on MTE2), CCSIDR2_EL1 (depending on FEAT_CCIDX),
> > and SMIDR_EL1 (depending on SME).
> > 
> > For these three registers, report their trap as EC=0x18 if they
> > end-up trapping into KVM and that FEAT_IDST is implemented in the guest.
> > Otherwise, just make them UNDEF.
> > 
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > ---
> >  arch/arm64/kvm/hyp/nvhe/sys_regs.c | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > index 876b36d3d4788..efc36645f4b5a 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > @@ -347,6 +347,18 @@ static bool pvm_gic_read_sre(struct kvm_vcpu *vcpu,
> >  	return true;
> >  }
> >  
> > +static bool pvm_idst_access(struct kvm_vcpu *vcpu,
> > +			    struct sys_reg_params *p,
> > +			    const struct sys_reg_desc *r)
> > +{
> > +	if (kvm_has_feat_enum(vcpu->kvm, ID_AA64MMFR2_EL1, IDS, NI))
> > +		inject_undef64(vcpu);
> > +	else
> > +		inject_sync64(vcpu, kvm_vcpu_get_esr(vcpu));
> > +
> > +	return false;
> > +}
> > +
> 
> Just wondering, why is the pkvm version register specific? You changed
> the non-pkvm from register specific to generic.

Because pKVM relies on a full enumeration of the registers as a design
principle, and refrains from having wide-casting nets as a catch-all.

That's to ensure that there is a "surprise trap" always results in an
UNDEF. Different model from the rest of KVM.

Thanks,

	M.

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



More information about the linux-arm-kernel mailing list