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

From: Cornelia Huck <[email-masked]>
Date: Tue, 16 May 2023 16:21:22 +0200

On Tue, May 16 2023, Shameerali Kolothum Thodi <[email-masked]> wrote:

>> -----Original Message-----
>> From: Marc Zyngier [mailto:[email-masked]]
>> Sent: 16 May 2023 14:12
>> To: Cornelia Huck <[email-masked]>
>> Cc: Shameerali Kolothum Thodi <[email-masked]>;
>> Jing Zhang <[email-masked]>; KVM <[email-masked]>;
>> KVMARM <[email-masked]>; ARMLinux
>> <[email-masked]>; Oliver Upton <[email-masked]>;
>> Will Deacon <[email-masked]>; Paolo Bonzini <[email-masked]>;
>> James Morse <[email-masked]>; Alexandru Elisei
>> <[email-masked]>; Suzuki K Poulose <[email-masked]>;
>> Fuad Tabba <[email-masked]>; Reiji Watanabe <[email-masked]>;
>> Raghavendra Rao Ananta <[email-masked]>
>> Subject: Re: [PATCH v8 0/6] Support writable CPU ID registers from
>> userspace
>> 
>> On Tue, 16 May 2023 12:55:14 +0100,
>> Cornelia Huck <[email-masked]> 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...

_______________________________________________
linux-arm-kernel mailing list
[email-masked]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel