Re: [PATCH v3] KVM: arm64: Sanitise ID_AA64MMFR3_EL1.S1P[IO]E

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

On Tue, Oct 20, 2026 at 07:43:06AM +0100, Fuad Tabba wrote:

> On first run, clear S1PIE and S1POE from the VM's ID registers when the
> features they imply are missing, before anything derives state from
> them. The guest and userspace then see neither feature, and the guest's
> accesses to their registers UNDEF.

Updating the ID registers should ensure we don't have any confusion in
the later KVM code due to the standard use of ID register based checks.
I didn't spot any further registers where we have nested checks that
would need similar updates.

> +static bool idreg_deps(struct kvm *kvm, const struct reg_feat_map_desc *r)
> +{
> +	struct resx resx = {};
> +	u64 val;
> +
> +	for (int i = 0; i < r->bit_feat_map_sz; i++) {
> +		if ((r->bit_feat_map[i].flags & CALL_FUNC) &&
> +		    !r->bit_feat_map[i].match(kvm))
> +			resx.res0 |= reg_feat_map_bits(&r->bit_feat_map[i]);
> +	}

It would be nice to have it be more obvious to the VMM and/or it's users
that it messed up, as things stand features it thought it had set will
just silently vanish from the guest - they'd need to know that this is
something that might happen and check after finalization or similar.
That's probably more a documentation/education thing than anything for
the patch.

We might want to support limits other than 0 at some point, but we can
deal with that if it becomes an actual issue and it's likely we would
just decide that the VMM shouldn't be configuring invalid things in the
first place so we don't care about being helpful.

Lorenzo raised all the more detailed code things I had, but either way:

Reviewed-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]