> -----Original Message----- > From: Marc Zyngier [mailto:maz@xxxxxxxxxx] > Sent: 16 May 2023 14:12 > To: Cornelia Huck <cohuck@xxxxxxxxxx> > Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx>; > Jing Zhang <jingzhangos@xxxxxxxxxx>; KVM <kvm@xxxxxxxxxxxxxxx>; > KVMARM <kvmarm@xxxxxxxxxxxxxxx>; ARMLinux > <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>; Oliver Upton <oupton@xxxxxxxxxx>; > Will Deacon <will@xxxxxxxxxx>; Paolo Bonzini <pbonzini@xxxxxxxxxx>; > James Morse <james.morse@xxxxxxx>; Alexandru Elisei > <alexandru.elisei@xxxxxxx>; Suzuki K Poulose <suzuki.poulose@xxxxxxx>; > Fuad Tabba <tabba@xxxxxxxxxx>; Reiji Watanabe <reijiw@xxxxxxxxxx>; > Raghavendra Rao Ananta <rananta@xxxxxxxxxx> > Subject: Re: [PATCH v8 0/6] Support writable CPU ID registers from > userspace > > 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. Yes, this is what we also need and was thinking of adding a named CPU with common min feature set exposed to Guest. There were some previous attempts to add the basic support in Qemu here, https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg00087.html > 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. Ok. This will be a problem and I am not sure this has an impact on our platforms or not. Thanks, Shameer > 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... > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible.
