Add the following feature bits for EPYC-Milan model and bump the version.
vaes : Vector VAES(ENC|DEC), VAES(ENC|DEC)LAST instruction support
vpclmulqdq : Vector VPCLMULQDQ instruction support
stibp-always-on : Single Thread Indirect Branch Prediction Mode has enhanced performance and may be left Always on
amd-psfd : Predictive Store Forward Disable
no-nested-data-bp : Processor ignores nested data breakpoints
lfence-always-serializing : LFENCE instruction is always serializing
null-sel-clr-base : Null Selector Clears Base. When this bit is set, a null segment load clears the segment base
[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-Milan
x86 EPYC-Milan (alias configured by machine type)
x86 EPYC-Milan-v1 AMD EPYC-Milan Processor
x86 EPYC-Milan-v2 AMD EPYC-Milan Processor
[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.
[Impact]
Add the following feature bits for EPYC-Milan model and bump the version.
performance and may be left Always on nested- data-bp : Processor ignores nested data breakpoints always- serializing : LFENCE instruction is always serializing sel-clr- base : Null Selector Clears Base. When this bit is
set, a null segment load clears the segment base
vaes : Vector VAES(ENC|DEC), VAES(ENC|DEC)LAST instruction support
vpclmulqdq : Vector VPCLMULQDQ instruction support
stibp-always-on : Single Thread Indirect Branch Prediction Mode has enhanced
amd-psfd : Predictive Store Forward Disable
no-
lfence-
null-
[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-Milan
x86 EPYC-Milan (alias configured by machine type)
x86 EPYC-Milan-v1 AMD EPYC-Milan Processor
x86 EPYC-Milan-v2 AMD EPYC-Milan Processor
[Where problems could occur]
* There are two areas to look at new-code/ old->new
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/
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.
[Other Info]
* n/a
---
https:/ /lists. gnu.org/ archive/ html/qemu- devel/2023- 05/msg02082. html
https:/ /github. com/qemu/ qemu/commit/ 27f03be6f59d04b d5673ba1e1628b2 b490f9a9ff. patch
This patch depends on the definitions that were added as part of the EPYC-Milan patch:
amd-psfd, stibp-always-on: /github. com/qemu/ qemu/commit/ bb039a230e6a792 0d71d21fa9afee2 653a678c48. patch 1_EAX: /github. com/qemu/ qemu/commit/ b70eec312b18519 7d639bff6890077 27e596afd1. patch
* https:/
Add feature bits for CPUID_Fn8000002
* https:/