Re: [PATCH] KVM: arm64: Add KVM_CAP_ARM_NATIVE_CACHE_CONFIG vcpu capability

[David Woodhouse]

On Thu, 2026-04-09 at 19:12 +0100, Marc Zyngier wrote:
> 
> That only means you are doing a pretty bad job at supporting
> guests. And yes, this is an issue for anything that expects to see
> something meaningful in CCSIDR[]. The fact that none of your guests
> hit that problem only means you're lacking coverage.

I think we just have a different idea of what it means to do a good job
of supporting guests. For me, the most important thing is never to
randomly change stuff underneath a running guest, even if it's a "bug
fix".

Even fixing an egregious and obvious bug, like fixing the reported
serial port type from the legacy 16550 to ACPI_DBG2_16550_WITH_GAS
turned out to break FreeBSD, to pick just one recent example.

Guest operating systems will often work with the environment they
actually *had* already, regardless of the actual specifications or
common sense. We don't have the luxury of just changing things
underneath them and then saying "haha, well that should never have
worked so screw you".

Moving to the fixed model is obviously the plan, but it has to be done
carefully and starting with new launches and new instance types and a
rollback plan, not just randomly inflicted as an unexpected side-effect
of a kernel upgrade.

> From what I can read, anything from Neoverse V1 is affected.
> 
> > 
> > This isn't about introducing *new* behaviour; it's about allowing the
> > existing established behaviour to be maintained so that we can have a
> > *managed* transition to the new model (for new launches) rather than an
> > unconditional uncontrolled change as the kernel gets upgraded.
> 
> Then fully implement "show me the cache hierarchy", read it out, and
> write it back with whatever level of brokenness you intend to inflict
> on your guests.

Again, *compatibility* is the point here, not brokenness.

> But I'm not reintroducing this particular bug.

Fair enough. It's not like the x86 zoo; there are only a certain number
of existing CPUs that I care about, that I need to enumerate. I can
just hard-code the values for all of those in the VMM — the kernel does
let me override the errantly-changed defaults, as the commit message
said.

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