Re: [PATCH v8 0/6] Support writable CPU ID registers from userspace

On Tue, 16 May 2023 17:31:29 +0100,
Oliver Upton [off-list ref] wrote:

On Tue, May 16, 2023 at 02:11:30PM +0100, Marc Zyngier wrote:

quoted

On Tue, 16 May 2023 12:55:14 +0100,
Cornelia Huck [off-list ref] wrote:

quoted

Do you have more concrete ideas for QEMU CPU models already? Asking
because I wanted to talk about this at KVM Forum, so collecting what
others would like to do seems like a good idea :)

I'm not being asked, but I'll share my thoughts anyway! ;-)

I don't think CPU models are necessarily the most important thing.
Specially when you look at the diversity of the ecosystem (and even
the same CPU can be configured in different ways at integration
time). Case in point, Neoverse N1 which can have its I/D caches made
coherent or not. And the guest really wants to know which one it is
(you can only lie in one direction).

But being able to control the feature set exposed to the guest from
userspace is a huge benefit in terms of migration.

Now, this is only half of the problem (and we're back to the CPU
model): most of these CPUs have various degrees of brokenness. Most of
the workarounds have to be implemented by the guest, and are keyed on
the MIDR values. So somehow, you need to be able to expose *all* the
possible MIDR values that a guest can observe in its lifetime.

I have a vague prototype for that that I'd need to dust off and
finish, because that's also needed for this very silly construct
called big-little...

And the third half of the problem is all of the other IP bits that get
strung together into an SOC :) Errata that live beyond the CPU can
become guest-visible (interconnect for example) and that becomes a bit
difficult to express to the guest OS. So, beyond something like a
big-little VM where the rest of the IP should be shared, I'm a bit
fearful of migrating a VM cross-system.

Indeed. But there isn't much we can do about that, and it should be
clear to anyone who's remotely involved in this crap that migration to
different systems is risky business.

But hey, userspace is in the drivers seat and it can do as it pleases.

Exactly. We just need to give it enough of the proverbial rope...

Hopefully we wouldn't need a KVM-specific PV interface for MIDR
enumeration. Perhaps the errata management spec could be expanded to
describe a set of CPU implementations and associated errata...

Hence finally making it clear the big-little is a large scale,
industry wide erratum? Sign me up! :D

More seriously, I'd expect this to be an ARM spec. But it wouldn't
hurt having a prototype that serves as a draft for the spec. Better
doing that than leaving it to... someone else.

Thanks,

	M.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel