all lists on lists.proxmox.com
 help / color / mirror / Atom feed
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.
> 


  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 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