On Thu, Dec 12, 2024 at 11:04:30AM +0100, Eric Auger wrote: Hi Eric,
> On 12/12/24 10:36, Cornelia Huck wrote: > > On Thu, Dec 12 2024, Daniel P. Berrangé <berra...@redhat.com> wrote: [...] > >> Consider you mgmt app wants to set a CPU model that's common across > >> heterogeneous hardware. They don't neccessarily want/need to be > >> able to live migrate between heterogeneous CPUs, but for simplicity > >> of configuration desire to set a single named CPU across all guests, > >> irrespective of what host hey are launched on. The ARM spec baseline > >> named models would give you that config simplicity. > > If we use architecture extensions (i.e. Armv8.x/9.x) as baseline, I'm > > seeing some drawbacks: > > - a lot of work before we can address some specific use cases > > - old models can get new optional features > > - a specific cpu might have a huge set of optional features on top of > > the baseline model > > > > Using a reference core such as Neoverse-V2 probably makes more sense > > (easier to get started, less feature diff?) It would still make a good > > starting point for a simple config. > > > Actually from a dev point of view I am not sure it changes much to have > either ARM spec rev baseline or CPU ref core named model. > > One remark is that if you look at > https://developer.arm.com/documentation/109697/2024_09?lang=en > you will see there are quite a lot of spec revisions and quite a few of > them are actually meaningful in the light of currently avaiable and > relevant HW we want to address. What I would like to avoid is to be > obliged to look at all of them in a generic manner while we just want to > address few cpu ref models. > > Also starting from the ARM spec rev baseline the end-user may need to > add more feature opt-ins to be close to a specific cpu model. So I > foresee extra complexity for the end-user. (Assuming I'm parsing your last para right; correct me if not.) Isn't a user wanting to add extra CPU flags (on top of a baseline) a "normal behaviour" and not "extra complexity"? Besides coming close to a specific CPU model, there's the additional important use-case of CPU flags that provide security mitigation. Consider this: Say, there's a serious security issue in a released ARM CPU. As part of the fix, two new CPU flags need to be exposed to the guest OS, call them "secflag1" and "secflag2". Here, the user is configuring a baseline model + two extra CPU flags, not to get close to some other CPU model but to mitigate itself against a serious security flaw. An example that comes to mind is the infamous "speculative store bypass" (SSB) vulnerability and how QEMU addressed it[1][2] in x86. I'm sure, as you know, it also affects ARM[3]. [1] https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04796.html — i386: define the 'ssbd' CPUID feature bit (CVE-2018-3639) [2] https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04797.html — i386: Define the Virt SSBD MSR and handling of it (CVE-2018-3639) [3] https://developer.arm.com/documentation/ddi0601/2024-06/AArch64-Registers/SSBS--Speculative-Store-Bypass-Safe -- /kashyap
