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

[Cornelia Huck]

On Tue, May 16 2023, Marc Zyngier <maz at kernel.org> wrote:

> On Tue, 16 May 2023 15:19:00 +0100,
> Cornelia Huck <cohuck at redhat.com> wrote:
>> 
>> On Tue, May 16 2023, Marc Zyngier <maz at kernel.org> wrote:
>> 
>> > On Tue, 16 May 2023 12:55:14 +0100,
>> > Cornelia Huck <cohuck at redhat.com> wrote:
>> >> 
>> >> 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.
>> 
>> Certainly; the important part is that we can keep the guest ABI
>> stable... which parts match to a "CPU model" in the way other
>> architectures use it is an interesting question. It almost certainly
>> will look different from e.g. s390, where we only have to deal with a
>> single manufacturer.
>> 
>> I'm wondering whether we'll end up building frankenmonster CPUs.
>
> We already do. KVM hides a bunch of things we don't want the guest to
> see, either because we don't support the feature, or that we want to
> present it with a different shape (cache topology, for example), and
> these combination don't really exist in any physical implementation.
>
> Which is why I don't really buy the "CPU model" concept as defined by
> x86 and s390. We already are in a vastly different place.

Yes, I agree that the "named cpu models" approach probably won't work on
Arm (especially if you add other accelerators into the mix -- cpu 'foo'
with tcg is unlikely to be 100% identical to cpu 'foo' with KVM.) OTOH,
"these two cpus are not that different from each other, so we support
migration between them with a least common denominator feature/behaviour
set" seems more reasonable.

>
> The way I see it, you get a bunch of architectural features that can
> be enabled/disabled depending on the underlying HW, hypervisor's
> capabilities and userspace input. On top of that, there is a layer of
> paint that tells you what is the overall implementation you could be
> running on (that's what MIDR+REVIDR+AIDR tell you) so that you can
> apply some unspeakable, uarch-specific hacks that keep the machine
> going (got to love these CPU errata).
>
>> Another interesting aspect is how KVM ends up influencing what the guest
>> sees on the CPU level, as in the case where we migrate across matching
>> CPUs, but with a different software level. I think we want userspace to
>> control that to some extent, but I'm not sure if this fully matches the
>> CPU model context.
>
> I'm not sure I get the "different software level" part. Do you mean
> VMM revisions?

Yes. Basically, two (for migration purposes) identical machines with
different kernel/QEMU versions, but using the same QEMU compat
machine. Migrate from old to new, get more regs: works. Migrate from
new to old, get less regs: boom. Expectation would be for this to
work, and handling it from machine compat code seems very awkward.