Re: [PATCH v7 7/7] KVM: arm64: Normalize cache configuration

[David Woodhouse]

On Thu, 12 Jan 2023 at 11:38:52 +0900, Akihiko Odaki wrote:
> Before this change, the cache configuration of the physical CPU was
> exposed to vcpus. This is problematic because the cache configuration a
> vcpu sees varies when it migrates between vcpus with different cache
> configurations.
> 
> Fabricate cache configuration from the sanitized value, which holds the
> CTR_EL0 value the userspace sees regardless of which physical CPU it
> resides on.
> 
> CLIDR_EL1 and CCSIDR_EL1 are now writable from the userspace so that
> the VMM can restore the values saved with the old kernel.

(commit 7af0c2534f4c5)

How does the VMM set the values that the old kernel would have set?

Let's say we're deploying a kernel with this change for the first time,
and we need to ensure that we provide a consistent environment to
guests, which can be live migrated back to an older host.

So for new launches, we need to provide the values that the old kernel
*would* have provided to the guest. A new launch isn't a migration;
there are no "values saved with the old kernel".

Userspace can't read the CLIDR_EL1 and CCSIDR_EL1 registers directly,
and AFAICT not everything we need to reconstitute them is in sysfs. How
is this supposed to work?

Shouldn't this change have been made as a capability that the VMM can
explicitly opt in or out of? Environments that don't do cross-CPU
migration absolutely don't care about, and actively don't *want*, the
sanitisation that this commit inflicted on us, surely?

Am I missing something?

Attachment: smime.p7s
Description: S/MIME cryptographic signature