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

[Cornelia Huck]

On Mon, May 13 2024, Oliver Upton <oliver.upton at linux.dev> wrote:

[apologies for the late reply]

> 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.

Yeah, we're probably fine for the time being, but something to keep in
mind, I guess.

>
>> >
>> > 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

Might make sense to spell that out?

>From 1d952c816d3192a4c2f3d95339aa96d86d3d0406 Mon Sep 17 00:00:00 2001
From: Cornelia Huck <cohuck at redhat.com>
Date: Wed, 22 May 2024 12:01:24 +0200
Subject: [PATCH] KVM: arm64: provide hint about vCPU feature stability

Give userspace some advice on how to achieve a stable feature set.

Signed-off-by: Cornelia Huck <cohuck at redhat.com>
---
 Documentation/virt/kvm/arm/vcpu-features.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/virt/kvm/arm/vcpu-features.rst b/Documentation/virt/kvm/arm/vcpu-features.rst
index f7cc6d8d8b74..01973bf8815d 100644
--- a/Documentation/virt/kvm/arm/vcpu-features.rst
+++ b/Documentation/virt/kvm/arm/vcpu-features.rst
@@ -40,6 +40,10 @@ outlined by the architecture in DDI0487J.a D19.1.3 'Principles of the ID
 scheme for fields in ID register'. KVM does not allow ID register values that
 exceed the capabilities of the system.
 
+As KVM will enable new features by default, userspace that wants to provide a
+stable feature set regardless of the kernel version is advised to supply a
+complete set of values for all of the ID registers.
+
 .. warning::
    It is **strongly recommended** that userspace modify the ID register values
    before accessing the rest of the vCPU's CPU register state. KVM may use the

>
>> >
>> > 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.

Yes, that would make the most sense (explicit opt-out from userspace),
the advice from above would still apply.