[pve-devel] [PATCH v4 qemu-server 1/1] cpuconfig: add new x86-64-vX models

[DERUMIER, Alexandre]

Le mardi 06 juin 2023 à 14:09 +0200, Fiona Ebner a écrit :
> Am 02.06.23 um 12:05 schrieb Alexandre Derumier:
> > 
> > "
> > In 2020, AMD, Intel, Red Hat, and SUSE worked together to define
> > three microarchitecture levels on top of the historical x86-64
> > baseline:
> > 
> >   * x86-64:    original x86_64 baseline instruction set
> >   * x86-64-v2: vector instructions up to Streaming SIMD
> >                Extensions 4.2 (SSE4.2)  and Supplemental
> >                Streaming SIMD Extensions 3 (SSSE3), the
> >                POPCNT instruction, and CMPXCHG16B
> >   * x86-64-v3: vector instructions up to AVX2, MOVBE,
> >                and additional bit-manipulation instructions.
> >   * x86-64-v4: vector instructions from some of the
> >                AVX-512 variants.
> > "
> 
> Can we also link to  because
> table 3.1 in the PDF contains a bit more precise information?
> 
> I used the following to test for some instructions, but feel free to
> tell me something better ;)
> 
I'm a pretty poor C developper, but that's seem right!
(To be honest, I didn't have even thinked to test instructions one by
one  )

> > int main()
> > {
> >     __asm__ __volatile__
> >     (
> >         "xgetbv"
> >     );
> >     return 0;
> > }
> 
> 
> I also found
> and after adding #include <stdbool.h> to the cpuid-dump2.c it seemed
> to
> work.
> 
> > 
> > This patch add new builtin model derivated from qemu64 model,
> > to be compatible between intel/amd.
> > 
> > x86-64-v1 : I'm skipping it, as it's basicaly qemu64|kvm64 -vme,-
> > cx16 for compat Opteron_G1 from 2004
> >             so will use it as qemu64|kvm64 is higher are not
> > working on opteron_g1 anyway
> > 
> > x86-64-v2 : Derived from qemu, +popcnt;+pni;+sse4.1;+sse4.2;+ssse3
> > 
> > min intel: Nehalem
> > min amd : Opteron_G3
> > 
> > x86-64-v2-AES : Derived from qemu,
> > +aes;+popcnt;+pni;+sse4.1;+sse4.2;+ssse3
> 
> Could you describe how you chose/tested the flags?

from the qemu doc generator
https://github.com/qemu/qemu/commit/4e2f5f3a9db06e87a73eb60a7cc9754fc13596ee


+# Mandatory CPUID features for each microarch ABI level
> +levels = [
> +    [ # x86-64 baseline
> +        "cmov",
> +        "cx8",
> +        "fpu",
> +        "fxsr",
> +        "mmx",
> +        "syscall",
> +        "sse",
> +        "sse2",
> +    ],
> +    [ # x86-64-v2
> +        "cx16",
> +        "lahf-lm",
> +        "popcnt",
> +        "pni",
> +        "sse4.1",
> +        "sse4.2",
> +        "ssse3",
> +    ],
> +    [ # x86-64-v3
> +        "avx",
> +        "avx2",
> +        "bmi1",
> +        "bmi2",
> +        "f16c",
> +        "fma",
> +        "abm",
> +        "movbe",
> +    ],
> +    [ # x86-64-v4
> +        "avx512f",
> +        "avx512bw",
> +        "avx512cd",
> +        "avx512dq",
> +        "avx512vl",
> +    ],
> +]
> 
> From the table in the PDF, most flags are clear (with pni apparently
> being SSE3). There are also CMPXCHG16B and LAHF-SAHF CPU
> features/instructions, but they are already part of qemu64 AFAICT. At
> least the example instructions cmpxchg16b (needs an operand) and lahf
> seem to work with my little test program and the cpuid-dump2 program
> also outputs -mcx16 -msahf indicating support.

yes, cx16 && lahf are already included in qemu64. (I have used qemu64
as it's more recent,and qemu don't recommend to use kvm64)


> 
> > min intel: Westmere
> > min amd : Opteron_G3
> > 
> > x86-64-v3 : Derived from qemu64
> > +aes;+popcnt;+pni;+sse4.1;+sse4.2;+ssse3;+avx;+avx2;+bmi1;+bmi2;+f1
> > 6c;+fma;+abm;+movbe
> 
> Again comparing with the table in the PDF all flags are clear (with
> abm
> adding the LZCNT feature/instruction).
> 
> But isn't the OSXSAVE feature missing? At least if I try with my
> little
> test program above I get "illegal hardware instruction" for xgetbv
> (that
> is the example instruction for the OSXSAVE CPU Feature mentioned in
> the
> PDF) and the has_osxsave variable in the cpuid-dump2 program is also
> false.

AFAIK, it's has been removed from qemu some years ago. (and I don't see
reference in other qemu models)

https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195
https://listman.redhat.com/archives/libvir-list/2019-May/msg00274.html
> 
> > 
> > min intel: Haswell
> > min amd : EPYC_v1
> > 
> > x86-64-v4 : Derived from qemu64
> > +aes;+popcnt;+pni;+sse4.1;+sse4.2;+ssse3;+avx;+avx2;+bmi1;+bmi2;+f1
> > 6c;+fma;+abm;+movbe;+avx512f;+avx512bw;+avx512cd;+avx512dq;+avx512v
> > l
> > 
> 
> Those match up exactly with the table in the PDF, so should be fine
> (except the OSXSAVE feature will also be missing as v4 extends v3).
> 
> > min intel: Skylake
> > min amd : EPYC_v4
> > 
> 
> (...)
> 
> > @@ -302,6 +321,17 @@ sub get_cpu_models {
> >         };
> >      }
> >  
> > +    for my $model (keys %{$builtin_models}) {
> > +       my $reported_model = $builtin_models->{$model}->{'reported-
> > model'};
> > +       $reported_model //= $cpu_fmt->{'reported-model'}-
> > >{default};
> 
> Nit: we could just avoid this and similar fallbacks in the rest of
> the
> patch, because we know that 'reported-model' is set for the built-in
> models. But it's not a big deal and in a language like Perl we don't
> have compile-time checks for it, so I'm fine with either way. If you
> drop these fallbacks, please add a comment above $builtin_models
> stating
> that 'reported-model' has to be set.
>