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

[Marc Zyngier <maz@kernel.org>]

On Thu, 09 Apr 2026 13:25:24 +0100,
David Woodhouse <dwmw2@infradead.org> wrote:
> 
> 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?

By reading them at the source?

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

We have never guaranteed host downgrade. It almost never works.

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

And you can provide these values.

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

I don't think a capability buys you anything. You want to expose
something to the guest? Make it so. You are in the favourable
situation to completely own the HW and the VMM.

The stuff we are allowing the VMM to change are not directly relevant
to the guest anyway (set/way per cache levels...), and were only
actively breaking things.

> Am I missing something?

That you had over 3 years to voice your concern, and did nothing?

	M.

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