[PATCH RFC] KVM: arm64: allow ID_MMFR4_EL1 to be writable

[Oliver Upton]

On Fri, May 10, 2024 at 05:11:09PM +0200, Cornelia Huck wrote:
> On Wed, May 08 2024, Oliver Upton <oliver.upton at linux.dev> wrote:
> > I'm willing to wager that the set of users who want to migrate state
> > from kernel N -> (N - 1) know the exact CPU definition they want to
> > expose to the guest, and in that case should be using a static set of
> > feature register values matching their intent.
> 
> I think the trouble starts when we introduce additional ranges of
> registers that can be controled via that interface -- old userspace will
> be able to figure out that there are more ranges available than what it
> is aware of, but will have no idea how to handle those additional ranges
> to get into a defined state (what is the actual range, for example?)

Even though the UAPI was designed around supporting multiple ranges, I
do not see this being an issue for quite some time. We already fully
describe the Feature ID register range from the architecture.

> >
> > Beyond the CPU architecture, KVM presents hypercall features to the VM
> > which userspace can _opt-out_ of on a per-feature basis using the
> > feature bitmap registers described in [2]. Like the feature ID
> > registers, we've preallocated a range of indices to be used for
> > hypercall bitmaps. So if an unexpected bitmap register appears on a new
> > kernel, userspace should write 0 to it to prevent new features from
> > silently creeping in.
> 
> Hm, the doc says: "The features for the registers that are untouched,
> probably because userspace isn’t aware of them, will be exposed as is to
> the guest." Seems to indicate that it is not too hard to get this wrong :)

Sure, but keep in mind the full range of possible Feature ID registers is
already known to userspace. Many of these register encodings are reserved,
RAZ to allow for future expansion of the architecture [*]. New registers
will come from one of these RAZ encodings.

If userspace wants to assert complete control over the CPU feature set
exposed to the VM it should use a pre-baked value for every register in
the range Op0=3, Op1=0, CRn=0, CRm={1-8}, Op2={0-8}.

[*] DDI0487J.a Table D18-2

> >
> > The canonical reason for this behavior, though, is that KVM/arm64
> > defaults to the maximum-possible feature set as discussed above.
> 
> /me contemplating "reverse" features, but too tired to think this
> through on a Friday afternoon.
> 

Reverse as in a negative / removed feature?

These tend to appear as negative ID register fields, to imply that the
feature set is less than what's provided for with a value of 0x0. KVM
probably couldn't start deprecating features in the default ID register
values but userspace could probe for features it can opt-out of using
the writable mask + trying to write -1 to a field.

DDI0487J.a D19.1.3 covers this.

-- 
Thanks,
Oliver