Re: [PATCH v2 6/8] KVM: arm64: Add sys_reg_descs for remaining MTE CMO instructions

[Oliver Upton <oupton@kernel.org>]

On Fri, Nov 06, 2026 at 06:45:39PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue to consider:
> - [Low] KVM: arm64: possible missing MTE_CMO_INSN entries for DC GVA and
>   DC GZVA
> --
> 
> commit c80fdbddf913183cac8f63dfc60ce6f48445eafa
> Author: Oliver Upton <oupton@kernel.org>
> 
> KVM: arm64: Add sys_reg_descs for remaining MTE CMO instructions
> 
> This commit adds MTE_CMO_INSN descriptors with mte_visibility to
> sys_insn_descs[] for MTE cache maintenance instructions trapped by
> HCR_EL2.TPCP so that they inject an UNDEFINED exception when MTE is not
> enabled for the VM.
> 
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index b456354713443..7f7a197a9ad6b 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> [ ... ]
> > @@ -4394,6 +4403,15 @@ static struct sys_reg_desc sys_insn_descs[] = {
> >  	SYS_INSN(TLBI_VALE1NXS, handle_tlbi_el1),
> >  	SYS_INSN(TLBI_VAALE1NXS, handle_tlbi_el1),
> >  
> > +	MTE_CMO_INSN(DC_CGVAC, bad_cmo_trap),
> > +	MTE_CMO_INSN(DC_CGDVAC, bad_cmo_trap),
> > +	MTE_CMO_INSN(DC_CGVAP, bad_cmo_trap),
> > +	MTE_CMO_INSN(DC_CGDVAP, bad_cmo_trap),
> > +	MTE_CMO_INSN(DC_CGVADP, bad_cmo_trap),
> > +	MTE_CMO_INSN(DC_CGDVADP, bad_cmo_trap),
> > +	MTE_CMO_INSN(DC_CIGVAC, bad_cmo_trap),
> > +	MTE_CMO_INSN(DC_CIGDVAC, bad_cmo_trap),
> 
> [Severity: Low]
> This question rests on an architecture detail that could not be confirmed
> from the kernel source: can SYS_DC_GVA and SYS_DC_GZVA trap to EL2 via
> HCR_EL2.TDZ or HFGITR_EL2.DCZVA when MTE is not enabled for the VM?
> 
> If so, encoding_to_cgt[] maps both instructions to CGT_HCR_TDZ and
> encoding_to_fgt[] maps them to HFGITR_EL2.DCZVA, which is marked NEVER_FGU
> in config.c because the trap bit is shared with SYS_DC_ZVA.  Without
> MTE_CMO_INSN entries for SYS_DC_GVA and SYS_DC_GZVA in sys_insn_descs[],
> triage_sysreg_trap() has neither an FGU bit nor a visibility() callback to
> filter them, and will forward traps from a nested guest to L1 when L1 sets
> HCR_EL2.TDZ or HFGITR_EL2.DCZVA instead of injecting an UNDEFINED
> exception.

Urgh, I'm starting to get the sense that we should pursue a generalized
solution. This relies on adding a subtle detail to KVM's trap behavior
when what we're trying to do already has a direct description in the
architecture...

Thanks,
Oliver