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

[Marc Zyngier]

On Thu, 09 Mar 2023 17:04:20 +0000,
Mark Brown <broonie at kernel.org> wrote:
> 
> 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.

Because we made the mistake initially and nobody cared enough to fix
it until now? The KVM UAPI is a never ending train wreck...

	M.

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