* To avoid bugs with newer Hardware and to allow users/admins to control
the KVM guests correctly we usually try to backport major CPU-
detect/control features back to at least the last LTS (currently jammy)
In SRU Terms this is under the second entry in https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* First of all we'll (and have in advance) run general regression tests
* Second you'd want to run this with host-model and host-passthrough on
Rome / Milan chips to ensure no case is now falling in to a totally
dysfunctional state
* Qemu shall show to be aware of the new types
# qemu-system-x86_64 -cpu ? | grep EPYC-Genoa
x86 EPYC-Genoa (alias configured by machine type)
x86 EPYC-Genoa-v1 AMD EPYC-Genoa 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 s a problem in backward-
migratebility 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.
[Other Info]
* This is not the first time new AMD chips need to add their definitions,
for example bug 1921880 was similar
Of course there are a number of kernel commits, some/most listed in the qemu commit, that would need to be backported to enable all features. But even without them, this already works for the most part (tested on focal kernel 5.4.0-70).
[Impact]
* To avoid bugs with newer Hardware and to allow users/admins to control /wiki.ubuntu. com/StableRelea seUpdates# Other_safe_ cases
the KVM guests correctly we usually try to backport major CPU-
detect/control features back to at least the last LTS (currently jammy)
In SRU Terms this is under the second entry in
https:/
* In this particular case it is about Support for EPYC Genoa chips /en.wikipedia. org/wiki/ Epyc#Fourth_ generation_ Epyc_(Genoa)
https:/
[Test Plan]
* First of all we'll (and have in advance) run general regression tests
* Second you'd want to run this with host-model and host-passthrough on
Rome / Milan chips to ensure no case is now falling in to a totally
dysfunctional state
* Qemu shall show to be aware of the new types
# qemu-system-x86_64 -cpu ? | grep EPYC-Genoa
x86 EPYC-Genoa (alias configured by machine type)
x86 EPYC-Genoa-v1 AMD EPYC-Genoa 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 s a problem in backward-
migratebility 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.
[Other Info]
* This is not the first time new AMD chips need to add their definitions,
for example bug 1921880 was similar
----
QEMU added a separate model for EPYC-Genoa in
https:/ /lists. gnu.org/ archive/ html/qemu- devel/2023- 05/msg02087. html
On the qemu side most bits are already present as far back as jammy. The only things missing are the vnmi and auto-ibrs flag.
https:/ /github. com/qemu/ qemu/commit/ 62a798d4bc2c3e7 67d94670776c77a 7df274d7c5. patch /github. com/qemu/ qemu/commit/ 166b1741884dd4f d7090b753cd7333 868457a29b. patch
https:/
Please consider adding/backporting these.
Of course there are a number of kernel commits, some/most listed in the qemu commit, that would need to be backported to enable all features. But even without them, this already works for the most part (tested on focal kernel 5.4.0-70).