[PATCH v1 11/18] KVM: arm64: expose ID_AA64MMFR3_EL1 to guests

[Mark Brown]

On Thu, Mar 09, 2023 at 04:24:56PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:
> > On Thu, Mar 09, 2023 at 02:52:39PM +0000, Joey Gouly wrote:

> > > Now that KVM context switches the appropriate registers, expose
> > > ID_AA64MMFR3_EL1 to guests to allow them to use the new features.
> > 
> > Should we be adding new vCPU features given that there's new
> > architectural state here?

> What do we gain by that? AFAICT, it only makes the UAPI more complex.
> And to be honest, *any* new feature added to KVM results in new
> architectural state. Are we going to add more and more of these ad
> nauseam? It doesn't scale. All we need to ensure at this stage is that
> you cannot migrate a VM that has seen this to a host that doesn't have
> the feature.

That was a genuine question prompted by how we handle pointer auth -
that seemed to be in a similar situation but has a flag.  With something
like SVE which causes the V registers to be replaced by the Z registers
in the view offered to VMMs it's more obvious.

> And if anything, this sort of selection should be defined by writing
> to the ID_AA64MMFR3_EL1 register from userspace and let the whole
> thing be driven by it. See Jing's current effort at [1].

Yes, I've seen that and it does seem a lot more logical - I was always
confused by why we couldn't do that normally.
-------------- 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/20230309/5517e8da/attachment.sig>