On Tue, May 16 2023, Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx> wrote: >> -----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 Thanks for the link. > >> 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. Oh, I see that the MIDR fun had already been mentioned in a reply to the first version of that patchset; this needs to be addressed for the general case, I guess...
