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

[David Woodhouse]

On Thu, 2026-04-09 at 16:45 +0100, Marc Zyngier wrote:
> On Thu, 09 Apr 2026 15:51:59 +0100, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> > On Thu, 2026-04-09 at 14:36 +0100, Marc Zyngier wrote:
> 
> > > We have never guaranteed host downgrade. It almost never works.
> >
> > Huh? Host downgrade absolutely *does* work; KVM on Arm isn't a toy.
> > We'd never be able to ship a new kernel if we didn't know we could roll
> > it *back* if we needed to.
> 
> You have clearly been lucky so far, because I'd never such claim.

It's not luck. We do a *lot* of testing, both within the guest checking
that what it sees is identical between old and new environments, and
repeated live upgrade/downgrade cycles between versions as well as
migration back and forth, and hibernate/resume from one to the other.

> > 
> > I *know* that you know perfectly well that we actively test host
> > downgrades prior to every rollout of a new kernel. So I'm a little
> > confused about what you're trying to say here, Marc.
> 
> I said exactly this: we make no effort to ensure that a guest started
> on a version of the kernel can be migrated to an older version -- the
> state space might be different.

You said "it almost never works". If that were the case, then I would
suggest that KVM on arm64 would be entirely unsuitable as a production
platform for virtual hosting. But thankfully it isn't my experience at
all.

Sure, we've occasionally found breakage, such as this commit and the
vGIC 'IMP_REV_1' thing being discussed in a separate thread, but those
are the exceptions rather than the norm.

(And yes, we need to do better than just reverting the offending
commits when we find them, and fix the issues properly upstream. Which
is what I'm doing now, belatedly).

> > 
> > Now that the values are writable, but userspace can't easily see *what*
> > they would have been in the previous kernel. So having the capability
> > to ask KVM to set them to those values seems like it might be useful.
> 
> Well, it's only a patch away.

Indeed so. When I asked what I was missing, I was *kind* of hoping
someone would tell me I'm wrong and that I can get the original values
from userspace either through sysfs or some other means, but in the
absence of that:
https://lore.kernel.org/lkml/7fb7b823c68e04321eb532a5b8ae21a818d4926d.camel@xxxxxxxxxxxxx/

(Lore is being insanely slow today but it *will* be there, and the
marc.info first alternative it offers does already have the message).

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