| 2023-05-17 13:36:39 |
Markus Schade |
description |
[Impact]
* Introduce new EPYC cpu versions: EPYC-v4 and EPYC-Rome-v3.
The only difference vs. older models is an updated cache_info with
the 'complex_indexing' bit unset, since this bit is not currently
defined for AMD and may cause problems should it be used for
something else in the future. Setting this bit will also cause
CPUID validation failures when running SEV-SNP guests.
[Test Plan]
* First of all we'll (and have in advance) run general regression tests
* Qemu shall show to be aware of the new types
# qemu-system-x86_64 -cpu ? | grep EPYC-Rome
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC Processor
x86 EPYC-Rome-v2 AMD EPYC Processor
x86 EPYC-Rome-v3 AMD EPYC Processor
# qemu-system-x86_64 -cpu ?| grep EPYC-v
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
x86 EPYC-v3 AMD EPYC Processor
x86 EPYC-v4 AMD EPYC Processor
* Finally migrations between old->new should be checked to work fine.
[Where problems could occur]
* This kind of "add the new type" usually only a problem in backward-
migratability which isn't supported anyway. Never the less the areas to
look out for is behavior on various AMD EPYC chips. To ensure that old
chips won't change in a breaking way (they might detect new features
now, but not more) and that new Milan chips are now all detected
properly.
----
QEMU added a new versions model for EPYC-Rome and EPYC in
https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg02079.html
This needs the following two patches:
https://github.com/qemu/qemu/commit/cca0a000d06f897411a8af4402e5d0522bbe450b.patch
https://github.com/qemu/qemu/commit/d7c72735f618a7ee27ee109d8b1468193734606a.patch
Please consider adding/backporting these. |
[Impact]
* Introduce new EPYC cpu versions: EPYC-v4 and EPYC-Rome-v3.
The only difference vs. older models is an updated cache_info with
the 'complex_indexing' bit unset, since this bit is not currently
defined for AMD and may cause problems should it be used for
something else in the future. Setting this bit will also cause
CPUID validation failures when running SEV-SNP guests.
[Test Plan]
* First of all we'll (and have in advance) run general regression tests
* Qemu shall show to be aware of the new types
# qemu-system-x86_64 -cpu ? | grep EPYC-Rome
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC Processor
x86 EPYC-Rome-v2 AMD EPYC Processor
x86 EPYC-Rome-v3 AMD EPYC Processor
# qemu-system-x86_64 -cpu ?| grep EPYC-v
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
x86 EPYC-v3 AMD EPYC Processor
x86 EPYC-v4 AMD EPYC Processor
* Finally migrations between old->new should be checked to work fine.
[Where problems could occur]
* There are two areas to look at
a) compat behavior on old systems - e.g. libvirt would now detect IBRS
on such AMD chips and one might wonder about the change.
E.g. compatibility would exist between old-code/new-code/old->new
code; but any action (e.g. suspend resume) from new to old code
might run into trouble (not supported that way but worth to mention
for awareness)
b) Migrations between systems - this should be covered by chip
versioning but still is worth to mention. Versioning will recognize
a formerly started system as v1 and continue to handle it that way.
Only new started guests would become v2 and behave the new and
improved way.
----
QEMU added a new versions model for EPYC-Rome and EPYC in
https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg02079.html
This needs the following two patches:
https://github.com/qemu/qemu/commit/cca0a000d06f897411a8af4402e5d0522bbe450b.patch
https://github.com/qemu/qemu/commit/d7c72735f618a7ee27ee109d8b1468193734606a.patch
Please consider adding/backporting these. |
|
