1. Patchew
  2. QEMU
  3. [PATCH RFC 0/4] target/i386/cpu: introduce new CPU models for x86-64 ABI levels
  4. View patch

[PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels

Daniel P. Berrangé posted 4 patches 5 years ago
There is a newer version of this series
[PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by Daniel P. Berrangé 5 years ago 
It is useful to know which CPUs satisfy each x86-64 ABI
compatibility level, when dealing with guest OS that require
something newer than the baseline ABI.

These ABI levels are defined in:

  https://gitlab.com/x86-psABIs/x86-64-ABI/

and supported by GCC, CLang, GLibC and more.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 MAINTAINERS                        |   2 +-
 docs/system/cpu-models-x86-abi.csv | 121 +++++++++++++++++++++++++++++
 docs/system/cpu-models-x86.rst.inc |  18 +++++
 3 files changed, 140 insertions(+), 1 deletion(-)
 create mode 100644 docs/system/cpu-models-x86-abi.csv

diff --git a/MAINTAINERS b/MAINTAINERS
index fbb228ef2b..bb8d60c458 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -344,7 +344,7 @@ F: tests/tcg/i386/
 F: tests/tcg/x86_64/
 F: hw/i386/
 F: disas/i386.c
-F: docs/system/cpu-models-x86.rst.inc
+F: docs/system/cpu-models-x86*
 T: git https://gitlab.com/ehabkost/qemu.git x86-next
 
 Xtensa TCG CPUs
diff --git a/docs/system/cpu-models-x86-abi.csv b/docs/system/cpu-models-x86-abi.csv
new file mode 100644
index 0000000000..4565e6a535
--- /dev/null
+++ b/docs/system/cpu-models-x86-abi.csv
@@ -0,0 +1,121 @@
+Model,baseline,v2,v3,v4
+486,,,,
+486-v1,,,,
+Broadwell,✅,✅,✅,
+Broadwell-IBRS,✅,✅,✅,
+Broadwell-noTSX,✅,✅,✅,
+Broadwell-noTSX-IBRS,✅,✅,✅,
+Broadwell-v1,✅,✅,✅,
+Broadwell-v2,✅,✅,✅,
+Broadwell-v3,✅,✅,✅,
+Broadwell-v4,✅,✅,✅,
+Cascadelake-Server,✅,✅,✅,✅
+Cascadelake-Server-noTSX,✅,✅,✅,✅
+Cascadelake-Server-v1,✅,✅,✅,✅
+Cascadelake-Server-v2,✅,✅,✅,✅
+Cascadelake-Server-v3,✅,✅,✅,✅
+Cascadelake-Server-v4,✅,✅,✅,✅
+Conroe,✅,,,
+Conroe-v1,✅,,,
+Cooperlake,✅,✅,✅,✅
+Cooperlake-v1,✅,✅,✅,✅
+Denverton,✅,✅,,
+Denverton-v1,✅,✅,,
+Denverton-v2,✅,✅,,
+Dhyana,✅,✅,✅,
+Dhyana-v1,✅,✅,✅,
+EPYC,✅,✅,✅,
+EPYC-IBPB,✅,✅,✅,
+EPYC-Rome,✅,✅,✅,
+EPYC-Rome-v1,✅,✅,✅,
+EPYC-v1,✅,✅,✅,
+EPYC-v2,✅,✅,✅,
+EPYC-v3,✅,✅,✅,
+Haswell,✅,✅,✅,
+Haswell-IBRS,✅,✅,✅,
+Haswell-noTSX,✅,✅,✅,
+Haswell-noTSX-IBRS,✅,✅,✅,
+Haswell-v1,✅,✅,✅,
+Haswell-v2,✅,✅,✅,
+Haswell-v3,✅,✅,✅,
+Haswell-v4,✅,✅,✅,
+Icelake-Client,✅,✅,✅,
+Icelake-Client-noTSX,✅,✅,✅,
+Icelake-Client-v1,✅,✅,✅,
+Icelake-Client-v2,✅,✅,✅,
+Icelake-Server,✅,✅,✅,✅
+Icelake-Server-noTSX,✅,✅,✅,✅
+Icelake-Server-v1,✅,✅,✅,✅
+Icelake-Server-v2,✅,✅,✅,✅
+Icelake-Server-v3,✅,✅,✅,✅
+Icelake-Server-v4,✅,✅,✅,✅
+IvyBridge,✅,✅,,
+IvyBridge-IBRS,✅,✅,,
+IvyBridge-v1,✅,✅,,
+IvyBridge-v2,✅,✅,,
+KnightsMill,✅,✅,✅,
+KnightsMill-v1,✅,✅,✅,
+Nehalem,✅,✅,,
+Nehalem-IBRS,✅,✅,,
+Nehalem-v1,✅,✅,,
+Nehalem-v2,✅,✅,,
+Opteron_G1,✅,,,
+Opteron_G1-v1,✅,,,
+Opteron_G2,✅,,,
+Opteron_G2-v1,✅,,,
+Opteron_G3,✅,,,
+Opteron_G3-v1,✅,,,
+Opteron_G4,✅,✅,,
+Opteron_G4-v1,✅,✅,,
+Opteron_G5,✅,✅,,
+Opteron_G5-v1,✅,✅,,
+Penryn,✅,,,
+Penryn-v1,✅,,,
+SandyBridge,✅,✅,,
+SandyBridge-IBRS,✅,✅,,
+SandyBridge-v1,✅,✅,,
+SandyBridge-v2,✅,✅,,
+Skylake-Client,✅,✅,✅,
+Skylake-Client-IBRS,✅,✅,✅,
+Skylake-Client-noTSX-IBRS,✅,✅,✅,
+Skylake-Client-v1,✅,✅,✅,
+Skylake-Client-v2,✅,✅,✅,
+Skylake-Client-v3,✅,✅,✅,
+Skylake-Server,✅,✅,✅,✅
+Skylake-Server-IBRS,✅,✅,✅,✅
+Skylake-Server-noTSX-IBRS,✅,✅,✅,✅
+Skylake-Server-v1,✅,✅,✅,✅
+Skylake-Server-v2,✅,✅,✅,✅
+Skylake-Server-v3,✅,✅,✅,✅
+Skylake-Server-v4,✅,✅,✅,✅
+Snowridge,✅,✅,,
+Snowridge-v1,✅,✅,,
+Snowridge-v2,✅,✅,,
+Westmere,✅,✅,,
+Westmere-IBRS,✅,✅,,
+Westmere-v1,✅,✅,,
+Westmere-v2,✅,✅,,
+athlon,,,,
+athlon-v1,,,,
+core2duo,✅,,,
+core2duo-v1,✅,,,
+coreduo,,,,
+coreduo-v1,,,,
+kvm32,,,,
+kvm32-v1,,,,
+kvm64,✅,,,
+kvm64-v1,✅,,,
+n270,,,,
+n270-v1,,,,
+pentium,,,,
+pentium-v1,,,,
+pentium2,,,,
+pentium2-v1,,,,
+pentium3,,,,
+pentium3-v1,,,,
+phenom,✅,,,
+phenom-v1,✅,,,
+qemu32,,,,
+qemu32-v1,,,,
+qemu64,✅,,,
+qemu64-v1,✅,,,
diff --git a/docs/system/cpu-models-x86.rst.inc b/docs/system/cpu-models-x86.rst.inc
index 9a2327828e..b964b29c78 100644
--- a/docs/system/cpu-models-x86.rst.inc
+++ b/docs/system/cpu-models-x86.rst.inc
@@ -39,6 +39,24 @@ CPU, as they would with "Host passthrough", but gives much of the
 benefit of passthrough, while making live migration safe.
 
 
+ABI compatibility levels for CPU models
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The x86_64 architecture has a number of `ABI compatibility levels`_
+defined. Traditionally most operating systems and toolchains would
+only target the original baseline ABI. It is expected that in
+future OS and toolchains are likely to target newer ABIs. The
+following table illustrates which ABI compatibility levels can be
+satisfied by the QEMU CPU models
+
+.. _ABI compatibility levels: https://gitlab.com/x86-psABIs/x86-64-ABI/
+
+.. csv-table:: x86-64 ABI compatibility levels
+   :file: cpu-models-x86-abi.csv
+   :widths: 40,15,15,15,15
+   :header-rows: 1
+
+
 Preferred CPU models for Intel x86 hosts
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-- 
2.29.2
Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by Eduardo Habkost 5 years ago 
On Mon, Feb 01, 2021 at 03:36:03PM +0000, Daniel P. Berrangé wrote:
> It is useful to know which CPUs satisfy each x86-64 ABI
> compatibility level, when dealing with guest OS that require
> something newer than the baseline ABI.
> 
> These ABI levels are defined in:
> 
>   https://gitlab.com/x86-psABIs/x86-64-ABI/
> 
> and supported by GCC, CLang, GLibC and more.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
[...]
> diff --git a/docs/system/cpu-models-x86-abi.csv b/docs/system/cpu-models-x86-abi.csv
> new file mode 100644
> index 0000000000..4565e6a535
> --- /dev/null
> +++ b/docs/system/cpu-models-x86-abi.csv
> @@ -0,0 +1,121 @@
> +Model,baseline,v2,v3,v4
> +486,,,,
> +486-v1,,,,
> +Broadwell,✅,✅,✅,
> +Broadwell-IBRS,✅,✅,✅,
> +Broadwell-noTSX,✅,✅,✅,
> +Broadwell-noTSX-IBRS,✅,✅,✅,
> +Broadwell-v1,✅,✅,✅,
> +Broadwell-v2,✅,✅,✅,
> +Broadwell-v3,✅,✅,✅,
> +Broadwell-v4,✅,✅,✅,

Unversioned names like "Broadwell" are machine-type-dependent
aliases.  I don't think they should be present in the table.

Models with suffixes like -IBRS, -noTSX, etc. are also aliases to
specific versions.  Maybe they could appear in the table for
completeness, but I'm not sure.

-- 
Eduardo
Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by Daniel P. Berrangé 5 years ago 
On Mon, Feb 01, 2021 at 01:28:51PM -0500, Eduardo Habkost wrote:
> On Mon, Feb 01, 2021 at 03:36:03PM +0000, Daniel P. Berrangé wrote:
> > It is useful to know which CPUs satisfy each x86-64 ABI
> > compatibility level, when dealing with guest OS that require
> > something newer than the baseline ABI.
> > 
> > These ABI levels are defined in:
> > 
> >   https://gitlab.com/x86-psABIs/x86-64-ABI/
> > 
> > and supported by GCC, CLang, GLibC and more.
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> [...]
> > diff --git a/docs/system/cpu-models-x86-abi.csv b/docs/system/cpu-models-x86-abi.csv
> > new file mode 100644
> > index 0000000000..4565e6a535
> > --- /dev/null
> > +++ b/docs/system/cpu-models-x86-abi.csv
> > @@ -0,0 +1,121 @@
> > +Model,baseline,v2,v3,v4
> > +486,,,,
> > +486-v1,,,,
> > +Broadwell,✅,✅,✅,
> > +Broadwell-IBRS,✅,✅,✅,
> > +Broadwell-noTSX,✅,✅,✅,
> > +Broadwell-noTSX-IBRS,✅,✅,✅,
> > +Broadwell-v1,✅,✅,✅,
> > +Broadwell-v2,✅,✅,✅,
> > +Broadwell-v3,✅,✅,✅,
> > +Broadwell-v4,✅,✅,✅,
> 
> Unversioned names like "Broadwell" are machine-type-dependent
> aliases.  I don't think they should be present in the table.
> 
> Models with suffixes like -IBRS, -noTSX, etc. are also aliases to
> specific versions.  Maybe they could appear in the table for
> completeness, but I'm not sure.

I guess just skip the CPUs with "alias-of" reported is easiest


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by David Edmondson 5 years ago 
On Monday, 2021-02-01 at 15:36:03 GMT, Daniel P. Berrangé wrote:

> It is useful to know which CPUs satisfy each x86-64 ABI
> compatibility level, when dealing with guest OS that require
> something newer than the baseline ABI.
>
> These ABI levels are defined in:
>
>   https://gitlab.com/x86-psABIs/x86-64-ABI/
>
> and supported by GCC, CLang, GLibC and more.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  MAINTAINERS                        |   2 +-
>  docs/system/cpu-models-x86-abi.csv | 121 +++++++++++++++++++++++++++++
>  docs/system/cpu-models-x86.rst.inc |  18 +++++
>  3 files changed, 140 insertions(+), 1 deletion(-)
>  create mode 100644 docs/system/cpu-models-x86-abi.csv
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fbb228ef2b..bb8d60c458 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -344,7 +344,7 @@ F: tests/tcg/i386/
>  F: tests/tcg/x86_64/
>  F: hw/i386/
>  F: disas/i386.c
> -F: docs/system/cpu-models-x86.rst.inc
> +F: docs/system/cpu-models-x86*
>  T: git https://gitlab.com/ehabkost/qemu.git x86-next
>  
>  Xtensa TCG CPUs
> diff --git a/docs/system/cpu-models-x86-abi.csv b/docs/system/cpu-models-x86-abi.csv
> new file mode 100644
> index 0000000000..4565e6a535
> --- /dev/null
> +++ b/docs/system/cpu-models-x86-abi.csv
> @@ -0,0 +1,121 @@
> +Model,baseline,v2,v3,v4
> +486,,,,
> +486-v1,,,,
> +Broadwell,✅,✅,✅,
> +Broadwell-IBRS,✅,✅,✅,
> +Broadwell-noTSX,✅,✅,✅,
> +Broadwell-noTSX-IBRS,✅,✅,✅,

Would it be useful to add an explicit negative mark (✘) in the slots
where the CPU does not satisfy the requirement? It makes reading the
table a little easier (my opinion, of course).

> +Broadwell-v1,✅,✅,✅,
> +Broadwell-v2,✅,✅,✅,
> +Broadwell-v3,✅,✅,✅,
> +Broadwell-v4,✅,✅,✅,
> +Cascadelake-Server,✅,✅,✅,✅
> +Cascadelake-Server-noTSX,✅,✅,✅,✅
> +Cascadelake-Server-v1,✅,✅,✅,✅
> +Cascadelake-Server-v2,✅,✅,✅,✅
> +Cascadelake-Server-v3,✅,✅,✅,✅
> +Cascadelake-Server-v4,✅,✅,✅,✅
> +Conroe,✅,,,
> +Conroe-v1,✅,,,
> +Cooperlake,✅,✅,✅,✅
> +Cooperlake-v1,✅,✅,✅,✅
> +Denverton,✅,✅,,
> +Denverton-v1,✅,✅,,
> +Denverton-v2,✅,✅,,
> +Dhyana,✅,✅,✅,
> +Dhyana-v1,✅,✅,✅,
> +EPYC,✅,✅,✅,
> +EPYC-IBPB,✅,✅,✅,
> +EPYC-Rome,✅,✅,✅,
> +EPYC-Rome-v1,✅,✅,✅,
> +EPYC-v1,✅,✅,✅,
> +EPYC-v2,✅,✅,✅,
> +EPYC-v3,✅,✅,✅,
> +Haswell,✅,✅,✅,
> +Haswell-IBRS,✅,✅,✅,
> +Haswell-noTSX,✅,✅,✅,
> +Haswell-noTSX-IBRS,✅,✅,✅,
> +Haswell-v1,✅,✅,✅,
> +Haswell-v2,✅,✅,✅,
> +Haswell-v3,✅,✅,✅,
> +Haswell-v4,✅,✅,✅,
> +Icelake-Client,✅,✅,✅,
> +Icelake-Client-noTSX,✅,✅,✅,
> +Icelake-Client-v1,✅,✅,✅,
> +Icelake-Client-v2,✅,✅,✅,
> +Icelake-Server,✅,✅,✅,✅
> +Icelake-Server-noTSX,✅,✅,✅,✅
> +Icelake-Server-v1,✅,✅,✅,✅
> +Icelake-Server-v2,✅,✅,✅,✅
> +Icelake-Server-v3,✅,✅,✅,✅
> +Icelake-Server-v4,✅,✅,✅,✅
> +IvyBridge,✅,✅,,
> +IvyBridge-IBRS,✅,✅,,
> +IvyBridge-v1,✅,✅,,
> +IvyBridge-v2,✅,✅,,
> +KnightsMill,✅,✅,✅,
> +KnightsMill-v1,✅,✅,✅,
> +Nehalem,✅,✅,,
> +Nehalem-IBRS,✅,✅,,
> +Nehalem-v1,✅,✅,,
> +Nehalem-v2,✅,✅,,
> +Opteron_G1,✅,,,
> +Opteron_G1-v1,✅,,,
> +Opteron_G2,✅,,,
> +Opteron_G2-v1,✅,,,
> +Opteron_G3,✅,,,
> +Opteron_G3-v1,✅,,,
> +Opteron_G4,✅,✅,,
> +Opteron_G4-v1,✅,✅,,
> +Opteron_G5,✅,✅,,
> +Opteron_G5-v1,✅,✅,,
> +Penryn,✅,,,
> +Penryn-v1,✅,,,
> +SandyBridge,✅,✅,,
> +SandyBridge-IBRS,✅,✅,,
> +SandyBridge-v1,✅,✅,,
> +SandyBridge-v2,✅,✅,,
> +Skylake-Client,✅,✅,✅,
> +Skylake-Client-IBRS,✅,✅,✅,
> +Skylake-Client-noTSX-IBRS,✅,✅,✅,
> +Skylake-Client-v1,✅,✅,✅,
> +Skylake-Client-v2,✅,✅,✅,
> +Skylake-Client-v3,✅,✅,✅,
> +Skylake-Server,✅,✅,✅,✅
> +Skylake-Server-IBRS,✅,✅,✅,✅
> +Skylake-Server-noTSX-IBRS,✅,✅,✅,✅
> +Skylake-Server-v1,✅,✅,✅,✅
> +Skylake-Server-v2,✅,✅,✅,✅
> +Skylake-Server-v3,✅,✅,✅,✅
> +Skylake-Server-v4,✅,✅,✅,✅
> +Snowridge,✅,✅,,
> +Snowridge-v1,✅,✅,,
> +Snowridge-v2,✅,✅,,
> +Westmere,✅,✅,,
> +Westmere-IBRS,✅,✅,,
> +Westmere-v1,✅,✅,,
> +Westmere-v2,✅,✅,,
> +athlon,,,,
> +athlon-v1,,,,
> +core2duo,✅,,,
> +core2duo-v1,✅,,,
> +coreduo,,,,
> +coreduo-v1,,,,
> +kvm32,,,,
> +kvm32-v1,,,,
> +kvm64,✅,,,
> +kvm64-v1,✅,,,
> +n270,,,,
> +n270-v1,,,,
> +pentium,,,,
> +pentium-v1,,,,
> +pentium2,,,,
> +pentium2-v1,,,,
> +pentium3,,,,
> +pentium3-v1,,,,
> +phenom,✅,,,
> +phenom-v1,✅,,,
> +qemu32,,,,
> +qemu32-v1,,,,
> +qemu64,✅,,,
> +qemu64-v1,✅,,,
> diff --git a/docs/system/cpu-models-x86.rst.inc b/docs/system/cpu-models-x86.rst.inc
> index 9a2327828e..b964b29c78 100644
> --- a/docs/system/cpu-models-x86.rst.inc
> +++ b/docs/system/cpu-models-x86.rst.inc
> @@ -39,6 +39,24 @@ CPU, as they would with "Host passthrough", but gives much of the
>  benefit of passthrough, while making live migration safe.
>  
>  
> +ABI compatibility levels for CPU models
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The x86_64 architecture has a number of `ABI compatibility levels`_
> +defined. Traditionally most operating systems and toolchains would
> +only target the original baseline ABI. It is expected that in
> +future OS and toolchains are likely to target newer ABIs. The
> +following table illustrates which ABI compatibility levels can be
> +satisfied by the QEMU CPU models

Missing full stop (or colon?).

> +
> +.. _ABI compatibility levels: https://gitlab.com/x86-psABIs/x86-64-ABI/
> +
> +.. csv-table:: x86-64 ABI compatibility levels
> +   :file: cpu-models-x86-abi.csv
> +   :widths: 40,15,15,15,15
> +   :header-rows: 1
> +
> +
>  Preferred CPU models for Intel x86 hosts
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  
> -- 
> 2.29.2

dme.
-- 
All of us, we're going out tonight. We're gonna walk all over your cars.
Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by Daniel P. Berrangé 5 years ago 
On Tue, Feb 02, 2021 at 09:41:15AM +0000, David Edmondson wrote:
> On Monday, 2021-02-01 at 15:36:03 GMT, Daniel P. Berrangé wrote:
> 
> > It is useful to know which CPUs satisfy each x86-64 ABI
> > compatibility level, when dealing with guest OS that require
> > something newer than the baseline ABI.
> >
> > These ABI levels are defined in:
> >
> >   https://gitlab.com/x86-psABIs/x86-64-ABI/
> >
> > and supported by GCC, CLang, GLibC and more.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >  MAINTAINERS                        |   2 +-
> >  docs/system/cpu-models-x86-abi.csv | 121 +++++++++++++++++++++++++++++
> >  docs/system/cpu-models-x86.rst.inc |  18 +++++
> >  3 files changed, 140 insertions(+), 1 deletion(-)
> >  create mode 100644 docs/system/cpu-models-x86-abi.csv
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index fbb228ef2b..bb8d60c458 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -344,7 +344,7 @@ F: tests/tcg/i386/
> >  F: tests/tcg/x86_64/
> >  F: hw/i386/
> >  F: disas/i386.c
> > -F: docs/system/cpu-models-x86.rst.inc
> > +F: docs/system/cpu-models-x86*
> >  T: git https://gitlab.com/ehabkost/qemu.git x86-next
> >  
> >  Xtensa TCG CPUs
> > diff --git a/docs/system/cpu-models-x86-abi.csv b/docs/system/cpu-models-x86-abi.csv
> > new file mode 100644
> > index 0000000000..4565e6a535
> > --- /dev/null
> > +++ b/docs/system/cpu-models-x86-abi.csv
> > @@ -0,0 +1,121 @@
> > +Model,baseline,v2,v3,v4
> > +486,,,,
> > +486-v1,,,,
> > +Broadwell,✅,✅,✅,
> > +Broadwell-IBRS,✅,✅,✅,
> > +Broadwell-noTSX,✅,✅,✅,
> > +Broadwell-noTSX-IBRS,✅,✅,✅,
> 
> Would it be useful to add an explicit negative mark (✘) in the slots
> where the CPU does not satisfy the requirement? It makes reading the
> table a little easier (my opinion, of course).

I felt it was clearer to only show the positive case. Since the
ABI levels are additive, you can count the ticks at a glance to see
the ABI level achieved. Also this CSV file isn't really meant to
be seen by users directly. It is just data input that gets rendered
into an HTML table that looks like this:

  https://berrange.gitlab.io/-/qemu/-/jobs/1001700036/artifacts/public/system/target-i386.html#recommendations-for-kvm-cpu-model-configuration-on-x86-hosts

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by David Edmondson 5 years ago 
On Tuesday, 2021-02-02 at 12:23:42 GMT, Daniel P. Berrangé wrote:

> On Tue, Feb 02, 2021 at 09:41:15AM +0000, David Edmondson wrote:
>> On Monday, 2021-02-01 at 15:36:03 GMT, Daniel P. Berrangé wrote:
>> 
>> > It is useful to know which CPUs satisfy each x86-64 ABI
>> > compatibility level, when dealing with guest OS that require
>> > something newer than the baseline ABI.
>> >
>> > These ABI levels are defined in:
>> >
>> >   https://gitlab.com/x86-psABIs/x86-64-ABI/
>> >
>> > and supported by GCC, CLang, GLibC and more.
>> >
>> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
>> > ---
>> >  MAINTAINERS                        |   2 +-
>> >  docs/system/cpu-models-x86-abi.csv | 121 +++++++++++++++++++++++++++++
>> >  docs/system/cpu-models-x86.rst.inc |  18 +++++
>> >  3 files changed, 140 insertions(+), 1 deletion(-)
>> >  create mode 100644 docs/system/cpu-models-x86-abi.csv
>> >
>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> > index fbb228ef2b..bb8d60c458 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -344,7 +344,7 @@ F: tests/tcg/i386/
>> >  F: tests/tcg/x86_64/
>> >  F: hw/i386/
>> >  F: disas/i386.c
>> > -F: docs/system/cpu-models-x86.rst.inc
>> > +F: docs/system/cpu-models-x86*
>> >  T: git https://gitlab.com/ehabkost/qemu.git x86-next
>> >  
>> >  Xtensa TCG CPUs
>> > diff --git a/docs/system/cpu-models-x86-abi.csv b/docs/system/cpu-models-x86-abi.csv
>> > new file mode 100644
>> > index 0000000000..4565e6a535
>> > --- /dev/null
>> > +++ b/docs/system/cpu-models-x86-abi.csv
>> > @@ -0,0 +1,121 @@
>> > +Model,baseline,v2,v3,v4
>> > +486,,,,
>> > +486-v1,,,,
>> > +Broadwell,✅,✅,✅,
>> > +Broadwell-IBRS,✅,✅,✅,
>> > +Broadwell-noTSX,✅,✅,✅,
>> > +Broadwell-noTSX-IBRS,✅,✅,✅,
>> 
>> Would it be useful to add an explicit negative mark (✘) in the slots
>> where the CPU does not satisfy the requirement? It makes reading the
>> table a little easier (my opinion, of course).
>
> I felt it was clearer to only show the positive case. Since the
> ABI levels are additive, you can count the ticks at a glance to see
> the ABI level achieved. Also this CSV file isn't really meant to
> be seen by users directly. It is just data input that gets rendered
> into an HTML table that looks like this:
>
>   https://berrange.gitlab.io/-/qemu/-/jobs/1001700036/artifacts/public/system/target-i386.html#recommendations-for-kvm-cpu-model-configuration-on-x86-hosts

Fine with me.

dme.
-- 
Another lonely day, no one here but me-o.
Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by Peter Maydell 5 years ago 
On Mon, 1 Feb 2021 at 15:39, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> It is useful to know which CPUs satisfy each x86-64 ABI
> compatibility level, when dealing with guest OS that require
> something newer than the baseline ABI.
>
> These ABI levels are defined in:
>
>   https://gitlab.com/x86-psABIs/x86-64-ABI/
>
> and supported by GCC, CLang, GLibC and more.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> +ABI compatibility levels for CPU models
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The x86_64 architecture has a number of `ABI compatibility levels`_
> +defined. Traditionally most operating systems and toolchains would
> +only target the original baseline ABI. It is expected that in
> +future OS and toolchains are likely to target newer ABIs. The
> +following table illustrates which ABI compatibility levels can be
> +satisfied by the QEMU CPU models
> +
> +.. _ABI compatibility levels: https://gitlab.com/x86-psABIs/x86-64-ABI/
> +
> +.. csv-table:: x86-64 ABI compatibility levels
> +   :file: cpu-models-x86-abi.csv
> +   :widths: 40,15,15,15,15
> +   :header-rows: 1

Apart from the QEMU/KVM specific CPU models, why is this something
we should be documenting rather than, say, the people specifying
what the ABI compatiblity levels are ?

thanks
-- PMM
Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by Daniel P. Berrangé 5 years ago 
On Mon, Feb 01, 2021 at 04:53:03PM +0000, Peter Maydell wrote:
> On Mon, 1 Feb 2021 at 15:39, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > It is useful to know which CPUs satisfy each x86-64 ABI
> > compatibility level, when dealing with guest OS that require
> > something newer than the baseline ABI.
> >
> > These ABI levels are defined in:
> >
> >   https://gitlab.com/x86-psABIs/x86-64-ABI/
> >
> > and supported by GCC, CLang, GLibC and more.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > +ABI compatibility levels for CPU models
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The x86_64 architecture has a number of `ABI compatibility levels`_
> > +defined. Traditionally most operating systems and toolchains would
> > +only target the original baseline ABI. It is expected that in
> > +future OS and toolchains are likely to target newer ABIs. The
> > +following table illustrates which ABI compatibility levels can be
> > +satisfied by the QEMU CPU models
> > +
> > +.. _ABI compatibility levels: https://gitlab.com/x86-psABIs/x86-64-ABI/
> > +
> > +.. csv-table:: x86-64 ABI compatibility levels
> > +   :file: cpu-models-x86-abi.csv
> > +   :widths: 40,15,15,15,15
> > +   :header-rows: 1
> 
> Apart from the QEMU/KVM specific CPU models, why is this something
> we should be documenting rather than, say, the people specifying
> what the ABI compatiblity levels are ?

QEMU's named CPU models are not a perfect match for features in the
real world silicon. So even if someone has a Skylake Server CPU with
feature X, this doesn't mean QEMU's definition of the Skylake-Server
CPU model is guaranteed to have feature X.  So we want to document
the compatibility of the exact CPU models that QEMU has defined.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by Florian Weimer 5 years ago 
* Peter Maydell:

> Apart from the QEMU/KVM specific CPU models, why is this something
> we should be documenting rather than, say, the people specifying
> what the ABI compatiblity levels are ?

The psABI only cares about userspace, and the specification there
deliberately excludes CPU features used in cryptography blocks, and
features that seem unstable and likely to be disabled in firmware or
future microcode updates.  This seemed a good trade-off for the psABI
because in userspace, run-time detection is still available, to access
additional CPU features not available as part of the target x86-64 level
at build time.

This doesn't really work for virtualization, which also has to decide
what to do with CPU features not relevant to userspace.  And a decision
to exclude features is final in the sense that guests cannot use the
feature at all because run-time detection shows it is as unavailable.

This is why a 1:1 copy of the userspace levels to virtualized machine
models is not possible, I think.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by Florian Weimer 5 years ago 
* Daniel P. Berrangé:

> and supported by GCC, CLang, GLibC and more.

Clang and glibc are the official spellings, I think.

> diff --git a/docs/system/cpu-models-x86-abi.csv b/docs/system/cpu-models-x86-abi.csv
> new file mode 100644
> index 0000000000..4565e6a535
> --- /dev/null
> +++ b/docs/system/cpu-models-x86-abi.csv

> +Icelake-Client,✅,✅,✅,
> +Icelake-Client-noTSX,✅,✅,✅,
> +Icelake-Client-v1,✅,✅,✅,
> +Icelake-Client-v2,✅,✅,✅,

Icelake Client supports x86-64-v4 according to Intel ARK and a quick
test on a reference system.  Have you defined it differently in QEMU?

> +KnightsMill,✅,✅,✅,
> +KnightsMill-v1,✅,✅,✅,

This one is correct.  Even though Knights Mill supports AVX-512, it does
not cover the variants that are considered definitive for x86-64-v4.

> +Skylake-Server,✅,✅,✅,✅
> +Skylake-Server-IBRS,✅,✅,✅,✅
> +Skylake-Server-noTSX-IBRS,✅,✅,✅,✅
> +Skylake-Server-v1,✅,✅,✅,✅
> +Skylake-Server-v2,✅,✅,✅,✅
> +Skylake-Server-v3,✅,✅,✅,✅
> +Skylake-Server-v4,✅,✅,✅,✅

This one is a little bit odd.  Skylake Xeons which are not Xeon Scalable
Processors exist, and they do not support x86-64-v4.  Is this again a
matter of different naming in QEMU?

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels
Posted by Daniel P. Berrangé 5 years ago 
On Mon, Feb 01, 2021 at 05:33:53PM +0100, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
> > and supported by GCC, CLang, GLibC and more.
> 
> Clang and glibc are the official spellings, I think.

Ok.

> > diff --git a/docs/system/cpu-models-x86-abi.csv b/docs/system/cpu-models-x86-abi.csv
> > new file mode 100644
> > index 0000000000..4565e6a535
> > --- /dev/null
> > +++ b/docs/system/cpu-models-x86-abi.csv
> 
> > +Icelake-Client,✅,✅,✅,
> > +Icelake-Client-noTSX,✅,✅,✅,
> > +Icelake-Client-v1,✅,✅,✅,
> > +Icelake-Client-v2,✅,✅,✅,
> 
> Icelake Client supports x86-64-v4 according to Intel ARK and a quick
> test on a reference system.  Have you defined it differently in QEMU?

QEMU's Icelake-Client CPU models appear to be missing most of the AVX-512
CPUIDs bits:

  https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/cpu.c#L3291

Compared to Icelake-Server which does have them:

  https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/cpu.c#L3409

I don't know why it is specified this way in QEMU. It could easily
be a bug in QEMU's definitions. Alternatively there might be a subset
of Icelake-Client SKUs which genuinely do lack these features, and
this influenced the decision to omit them from QEMU models.


> > +KnightsMill,✅,✅,✅,
> > +KnightsMill-v1,✅,✅,✅,
> 
> This one is correct.  Even though Knights Mill supports AVX-512, it does
> not cover the variants that are considered definitive for x86-64-v4.
> 
> > +Skylake-Server,✅,✅,✅,✅
> > +Skylake-Server-IBRS,✅,✅,✅,✅
> > +Skylake-Server-noTSX-IBRS,✅,✅,✅,✅
> > +Skylake-Server-v1,✅,✅,✅,✅
> > +Skylake-Server-v2,✅,✅,✅,✅
> > +Skylake-Server-v3,✅,✅,✅,✅
> > +Skylake-Server-v4,✅,✅,✅,✅
> 
> This one is a little bit odd.  Skylake Xeons which are not Xeon Scalable
> Processors exist, and they do not support x86-64-v4.  Is this again a
> matter of different naming in QEMU?

Most likely this is just a case of the QEMU Skylake-Server model being
written in terms of the most common SKUs, and ignoring the inconvenience
of certain SKUs lacking the features.


In general there are waaaay too many different variants of Intel CPUs for
QEMU to provide a named model to cope with every scenario. So the QEMU
models are always an approximation of what exists in the silicon.

If there are places where we've made bad mistake, we do now have the
ability to do CPU versioning. So in theory we could introduce a new
Skylake-Server-v5 which removes the AVX512 stuff if there's a genuine
problem with some variants of silicon not supporting it. Alternatively
people with such hosts can just use an older named model like
Skylake-Client.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.