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

[Marc Zyngier <maz@kernel.org>]

On Tue, 16 May 2023 15:19:00 +0100,
Cornelia Huck <cohuck@redhat.com> wrote:
> 
> On Tue, May 16 2023, Marc Zyngier <maz@kernel.org> wrote:
> 
> > On Tue, 16 May 2023 12:55:14 +0100,
> > Cornelia Huck <cohuck@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.

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?

Thanks,

	M.

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