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