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

[Cornelia Huck]

On Tue, May 16 2023, Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com> wrote:

>> -----Original Message-----
>> From: Marc Zyngier [mailto:maz at kernel.org]
>> Sent: 16 May 2023 14:12
>> To: Cornelia Huck <cohuck at redhat.com>
>> Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>;
>> Jing Zhang <jingzhangos at google.com>; KVM <kvm at vger.kernel.org>;
>> KVMARM <kvmarm at lists.linux.dev>; ARMLinux
>> <linux-arm-kernel at lists.infradead.org>; Oliver Upton <oupton at google.com>;
>> Will Deacon <will at kernel.org>; Paolo Bonzini <pbonzini at redhat.com>;
>> James Morse <james.morse at arm.com>; Alexandru Elisei
>> <alexandru.elisei at arm.com>; Suzuki K Poulose <suzuki.poulose at arm.com>;
>> Fuad Tabba <tabba at google.com>; Reiji Watanabe <reijiw at google.com>;
>> Raghavendra Rao Ananta <rananta at google.com>
>> 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 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.
>
> 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...