From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>,
"aderumier@odiso.com" <aderumier@odiso.com>,
"f.ebner@proxmox.com" <f.ebner@proxmox.com>
Subject: Re: [pve-devel] [PATCH v4 qemu-server 1/1] cpuconfig: add new x86-64-vX models
Date: Tue, 6 Jun 2023 13:36:07 +0000 [thread overview]
Message-ID: <c73ce1cfea3d4b1507868547d74cec437a22856d.camel@groupe-cyllene.com> (raw)
In-Reply-To: <ae82ddba-d4da-9dd1-aad1-9ddb05a6721e@proxmox.com>
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.
>
next prev parent reply other threads:[~2023-06-06 13:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 10:05 [pve-devel] [PATCH-SERIES v4 qemu-server/manager] add and set x86-64-v2-AES as default model for new vms Alexandre Derumier
2023-06-02 10:05 ` [pve-devel] [PATCH v4 qemu-server 1/1] cpuconfig: add new x86-64-vX models Alexandre Derumier
2023-06-06 12:09 ` Fiona Ebner
2023-06-06 13:36 ` DERUMIER, Alexandre [this message]
2023-06-07 8:31 ` Fiona Ebner
2023-06-07 10:57 ` DERUMIER, Alexandre
2023-06-07 11:25 ` DERUMIER, Alexandre
2023-06-07 11:48 ` Fiona Ebner
2023-06-07 14:11 ` DERUMIER, Alexandre
2023-06-07 15:29 ` DERUMIER, Alexandre
2023-06-02 10:05 ` [pve-devel] [PATCH v2 pve-manager 1/1] qemu: processor : set x86-64-v2-AES as default cputype for create wizard Alexandre Derumier
2023-06-06 12:47 ` Fiona Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c73ce1cfea3d4b1507868547d74cec437a22856d.camel@groupe-cyllene.com \
--to=alexandre.derumier@groupe-cyllene.com \
--cc=aderumier@odiso.com \
--cc=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox