From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Alexandre Derumier <aderumier@odiso.com>
Subject: Re: [pve-devel] [PATCH v4 qemu-server 1/1] cpuconfig: add new x86-64-vX models
Date: Tue, 6 Jun 2023 14:09:37 +0200 [thread overview]
Message-ID: <ae82ddba-d4da-9dd1-aad1-9ddb05a6721e@proxmox.com> (raw)
In-Reply-To: <20230602100551.2224246-2-aderumier@odiso.com>
Am 02.06.23 um 12:05 schrieb Alexandre Derumier:
> https://lists.gnu.org/archive/html/qemu-devel/2021-06/msg01592.html
> "
> 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 https://gitlab.com/x86-psABIs/x86-64-ABI/ 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 ;)
> int main()
> {
> __asm__ __volatile__
> (
> "xgetbv"
> );
> return 0;
> }
I also found
https://gist.github.com/rindeal/81198b1cf8f55c356743
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 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.
> 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;+f16c;+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.
>
> 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;+f16c;+fma;+abm;+movbe;+avx512f;+avx512bw;+avx512cd;+avx512dq;+avx512vl
>
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 12:10 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 [this message]
2023-06-06 13:36 ` DERUMIER, Alexandre
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=ae82ddba-d4da-9dd1-aad1-9ddb05a6721e@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=aderumier@odiso.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal