[PATCH v6 18/28] KVM: arm64: Support SME priority registers

[Mark Brown]

On Sun, Jun 29, 2025 at 10:32:23AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -495,6 +495,7 @@ enum vcpu_sysreg {
> >  	SVCR,
> >  	FPMR,
> >  	SMIDR_EL1,	/* Streaming Mode Identification Register */
> > +	SMPRI_EL1,	/* Streaming Mode Priority Register */

> What is the point of making the sysreg file larger for the sole
> purpose of returning a value that is firmly always 0? Can't that be
> synthesised on the fly whenever needed?

This was patterned of what you'd done with SVCR, I'd formed the
impression that the idea was that for registers that really exist like
this one it was more robust and less code to set them up in the sysreg
file and have everything look standard than do custom handling.  That
case was a bit different as the arch FP code needs a variable to point
at, I'll remove this and synthesise instead.

> > +	EL2_REG_FILTERED(SMPRIMAP_EL2, trap_raz_wi, reset_val, 0,
> > +			 sme_el2_visibility),

> Wut??? You clearly said it yourself: this register "has no specific
> traps available". If you end-up here from a guest access, this is a
> bug. So this "trap_raz_wi" makes no sense.

I see, so the callback should be NULL?  Access to the register will get
trapped as part of the general trapping of EL2 access by a NV hypervisor
so it wasn't clear to me that that we shouldn't have the handling.

> I also cannot see where this register is properly configured to be
> fully RES0, as it should.

Me either now that you point it out, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250703/3a00b7e0/attachment.sig>