Add EPYC-Genoa model
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
linux (Ubuntu) | Status tracked in Mantic | |||||
Jammy |
Confirmed
|
Undecided
|
Unassigned | |||
Kinetic |
Won't Fix
|
Undecided
|
Unassigned | |||
Lunar |
Confirmed
|
Undecided
|
Unassigned | |||
Mantic |
Confirmed
|
Undecided
|
Unassigned | |||
qemu (Ubuntu) | Status tracked in Mantic | |||||
Jammy |
Triaged
|
Undecided
|
Sergio Durigan Junior | |||
Kinetic |
Won't Fix
|
Undecided
|
Unassigned | |||
Lunar |
Triaged
|
Undecided
|
Sergio Durigan Junior | |||
Mantic |
Triaged
|
Undecided
|
Sergio Durigan Junior |
Bug Description
[Impact]
* 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:/
* In this particular case it is about Support for EPYC Genoa chips
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:/
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.
The lfence-
https:/
https:/
Kernel auto-ibrs et al:
https://<email address hidden>/
kvm: Add support for CPUID_80000021_EAX
* https:/
kvm: Add the NO_NESTED_DATA_BP feature
* https:/
kvm: Move X86_FEATURE_
* https:/
kvm: Add the Null Selector Clears Base feature
* https:/
kvm: Add the SMM_CTL MSR not present feature
https:/
x86/cpu: Support AMD Automatic IBRS
https:/
KVM: Add common feature flag for AMD's PSFD
https:/
Add support for virtual NMIs
https:/
Please consider adding/backporting these.
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in linux (Ubuntu Jammy): | |
status: | Incomplete → New |
Changed in linux (Ubuntu Lunar): | |
status: | Incomplete → New |
Changed in linux (Ubuntu Mantic): | |
status: | Incomplete → New |
Changed in qemu (Ubuntu Kinetic): | |
status: | Triaged → Won't Fix |
assignee: | Sergio Durigan Junior (sergiodj) → nobody |
Changed in linux (Ubuntu): | |
status: | New → Incomplete |
Changed in linux (Ubuntu Jammy): | |
status: | New → Incomplete |
Changed in linux (Ubuntu Lunar): | |
status: | New → Incomplete |
Changed in linux (Ubuntu Jammy): | |
status: | Incomplete → Confirmed |
Changed in linux (Ubuntu Lunar): | |
status: | Incomplete → Confirmed |
Changed in linux (Ubuntu Mantic): | |
status: | Incomplete → Confirmed |
Thanks for the bug report, Markus.
I noticed that bug #1921880 involved a lot of work before Christian was able to actually upload the packages. I will start taking a look at this bug and preparing the backports, hopefully by early next I should have something ready for you to test.