| 2023-05-17 14:03:34 |
Markus Schade |
bug |
|
|
added bug |
| 2023-05-17 14:03:58 |
Markus Schade |
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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
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). |
[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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
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 jammy kernel 5.15.0-72). |
|
| 2023-05-17 14:04:29 |
Markus Schade |
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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
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 jammy kernel 5.15.0-72). |
[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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
Please consider adding/backporting these. |
|
| 2023-05-17 15:04:22 |
Markus Schade |
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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
Please consider adding/backporting these. |
[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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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.
The lfence-always-serializing, amd-psfd, no-nested-data-bp, null-sel-clr-base are part of the Milan-v2 patch set
https://github.com/qemu/qemu/commit/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
Kernel auto-ibrs:
https://www.spinics.net/lists/kernel/msg4646861.html
Please consider adding/backporting these. |
|
| 2023-05-18 19:32:58 |
Sergio Durigan Junior |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-05-18 19:32:58 |
Sergio Durigan Junior |
bug task added |
|
qemu (Ubuntu Jammy) |
|
| 2023-05-18 19:32:58 |
Sergio Durigan Junior |
nominated for series |
|
Ubuntu Kinetic |
|
| 2023-05-18 19:32:58 |
Sergio Durigan Junior |
bug task added |
|
qemu (Ubuntu Kinetic) |
|
| 2023-05-18 19:32:58 |
Sergio Durigan Junior |
nominated for series |
|
Ubuntu Mantic |
|
| 2023-05-18 19:32:58 |
Sergio Durigan Junior |
bug task added |
|
qemu (Ubuntu Mantic) |
|
| 2023-05-18 19:32:58 |
Sergio Durigan Junior |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-05-18 19:32:58 |
Sergio Durigan Junior |
bug task added |
|
qemu (Ubuntu Lunar) |
|
| 2023-05-18 19:33:05 |
Sergio Durigan Junior |
qemu (Ubuntu Jammy): status |
New |
Triaged |
|
| 2023-05-18 19:33:07 |
Sergio Durigan Junior |
qemu (Ubuntu Kinetic): status |
New |
Triaged |
|
| 2023-05-18 19:33:09 |
Sergio Durigan Junior |
qemu (Ubuntu Lunar): status |
New |
Triaged |
|
| 2023-05-18 19:33:11 |
Sergio Durigan Junior |
qemu (Ubuntu Mantic): status |
New |
Triaged |
|
| 2023-05-18 19:33:18 |
Sergio Durigan Junior |
bug |
|
|
added subscriber Sergio Durigan Junior |
| 2023-05-18 19:34:52 |
Sergio Durigan Junior |
qemu (Ubuntu Jammy): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2023-05-18 19:34:54 |
Sergio Durigan Junior |
qemu (Ubuntu Kinetic): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2023-05-18 19:34:55 |
Sergio Durigan Junior |
qemu (Ubuntu Lunar): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2023-05-18 19:34:57 |
Sergio Durigan Junior |
qemu (Ubuntu Mantic): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2023-05-19 05:07:19 |
Markus Schade |
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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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.
The lfence-always-serializing, amd-psfd, no-nested-data-bp, null-sel-clr-base are part of the Milan-v2 patch set
https://github.com/qemu/qemu/commit/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
Kernel auto-ibrs:
https://www.spinics.net/lists/kernel/msg4646861.html
Please consider adding/backporting these. |
[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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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.
The lfence-always-serializing, amd-psfd, no-nested-data-bp, null-sel-clr-base are part of the Milan-v2 patch set
https://github.com/qemu/qemu/commit/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
Kernel auto-ibrs:
https://lkml.kernel.org/lkml/20230124163319.2277355-1-kim.phillips@amd.com/
Please consider adding/backporting these. |
|
| 2023-05-19 05:21:55 |
Markus Schade |
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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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.
The lfence-always-serializing, amd-psfd, no-nested-data-bp, null-sel-clr-base are part of the Milan-v2 patch set
https://github.com/qemu/qemu/commit/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
Kernel auto-ibrs:
https://lkml.kernel.org/lkml/20230124163319.2277355-1-kim.phillips@amd.com/
Please consider adding/backporting these. |
[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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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.
The lfence-always-serializing, amd-psfd, no-nested-data-bp, null-sel-clr-base are part of the Milan-v2 patch set
https://github.com/qemu/qemu/commit/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
Kernel auto-ibrs et al:
https://lkml.kernel.org/lkml/20230124163319.2277355-1-kim.phillips@amd.com/
kvm: Add support for CPUID_80000021_EAX
* https://github.com/torvalds/linux/commit/8415a74852d7c24795007ee9862d25feb519007c.patch
kvm: Add the NO_NESTED_DATA_BP feature
* https://github.com/torvalds/linux/commit/a9dc9ec5a1fafc3d2fe7a7b594eefaeaccf89a6b.patch
kvm: Move X86_FEATURE_LFENCE_RDTSC to its native leaf
* https://github.com/torvalds/linux/commit/84168ae786f8a15a7eb0f79d34f20b8d261ce2f5.patch
kvm: Add the Null Selector Clears Base feature
* https://github.com/torvalds/linux/commit/5b909d4ae59aedc711b7a432da021be0e82c95a0.patch
kvm: Add the SMM_CTL MSR not present feature
https://github.com/torvalds/linux/commit/faabfcb194a8d0686396e3fff6a5b42911f65191.patch
x86/cpu: Support AMD Automatic IBRS
https://github.com/torvalds/linux/commit/e7862eda309ecfccc36bb5558d937ed3ace07f3f.patch
And probably this one as well:
KVM: Add common feature flag for AMD's PSFD
https://github.com/torvalds/linux/commit/3d8f61bf8bcd69bcd397276d53aa18f7ca8347f9.patch
Please consider adding/backporting these. |
|
| 2023-05-19 05:25:50 |
Markus Schade |
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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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.
The lfence-always-serializing, amd-psfd, no-nested-data-bp, null-sel-clr-base are part of the Milan-v2 patch set
https://github.com/qemu/qemu/commit/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
Kernel auto-ibrs et al:
https://lkml.kernel.org/lkml/20230124163319.2277355-1-kim.phillips@amd.com/
kvm: Add support for CPUID_80000021_EAX
* https://github.com/torvalds/linux/commit/8415a74852d7c24795007ee9862d25feb519007c.patch
kvm: Add the NO_NESTED_DATA_BP feature
* https://github.com/torvalds/linux/commit/a9dc9ec5a1fafc3d2fe7a7b594eefaeaccf89a6b.patch
kvm: Move X86_FEATURE_LFENCE_RDTSC to its native leaf
* https://github.com/torvalds/linux/commit/84168ae786f8a15a7eb0f79d34f20b8d261ce2f5.patch
kvm: Add the Null Selector Clears Base feature
* https://github.com/torvalds/linux/commit/5b909d4ae59aedc711b7a432da021be0e82c95a0.patch
kvm: Add the SMM_CTL MSR not present feature
https://github.com/torvalds/linux/commit/faabfcb194a8d0686396e3fff6a5b42911f65191.patch
x86/cpu: Support AMD Automatic IBRS
https://github.com/torvalds/linux/commit/e7862eda309ecfccc36bb5558d937ed3ace07f3f.patch
And probably this one as well:
KVM: Add common feature flag for AMD's PSFD
https://github.com/torvalds/linux/commit/3d8f61bf8bcd69bcd397276d53aa18f7ca8347f9.patch
Please consider adding/backporting these. |
[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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
* In this particular case it is about Support for EPYC Genoa chips
https://en.wikipedia.org/wiki/Epyc#Fourth_generation_Epyc_(Genoa)
[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.
The lfence-always-serializing, amd-psfd, no-nested-data-bp, null-sel-clr-base are part of the Milan-v2 patch set
https://github.com/qemu/qemu/commit/62a798d4bc2c3e767d94670776c77a7df274d7c5.patch
https://github.com/qemu/qemu/commit/166b1741884dd4fd7090b753cd7333868457a29b.patch
Kernel auto-ibrs et al:
https://lkml.kernel.org/lkml/20230124163319.2277355-1-kim.phillips@amd.com/
kvm: Add support for CPUID_80000021_EAX
* https://github.com/torvalds/linux/commit/8415a74852d7c24795007ee9862d25feb519007c.patch
kvm: Add the NO_NESTED_DATA_BP feature
* https://github.com/torvalds/linux/commit/a9dc9ec5a1fafc3d2fe7a7b594eefaeaccf89a6b.patch
kvm: Move X86_FEATURE_LFENCE_RDTSC to its native leaf
* https://github.com/torvalds/linux/commit/84168ae786f8a15a7eb0f79d34f20b8d261ce2f5.patch
kvm: Add the Null Selector Clears Base feature
* https://github.com/torvalds/linux/commit/5b909d4ae59aedc711b7a432da021be0e82c95a0.patch
kvm: Add the SMM_CTL MSR not present feature
https://github.com/torvalds/linux/commit/faabfcb194a8d0686396e3fff6a5b42911f65191.patch
x86/cpu: Support AMD Automatic IBRS
https://github.com/torvalds/linux/commit/e7862eda309ecfccc36bb5558d937ed3ace07f3f.patch
KVM: Add common feature flag for AMD's PSFD
https://github.com/torvalds/linux/commit/3d8f61bf8bcd69bcd397276d53aa18f7ca8347f9.patch
Add support for virtual NMIs
https://github.com/torvalds/linux/commit/4a5fd419952e49ef870e9259d815718062871cc1.patch
Please consider adding/backporting these. |
|
| 2023-07-17 23:15:57 |
Sergio Durigan Junior |
bug task added |
|
linux (Ubuntu) |
|
| 2023-08-10 18:02:31 |
Utkarsh Gupta |
linux (Ubuntu Kinetic): status |
New |
Won't Fix |
|
| 2023-08-22 15:32:29 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2023-08-22 15:32:30 |
Ubuntu Kernel Bot |
linux (Ubuntu Jammy): status |
New |
Incomplete |
|
| 2023-08-22 15:32:32 |
Ubuntu Kernel Bot |
linux (Ubuntu Lunar): status |
New |
Incomplete |
|
| 2023-09-02 04:01:35 |
Sergio Durigan Junior |
linux (Ubuntu Jammy): status |
Incomplete |
New |
|
| 2023-09-02 04:01:44 |
Sergio Durigan Junior |
linux (Ubuntu Lunar): status |
Incomplete |
New |
|
| 2023-09-02 04:01:50 |
Sergio Durigan Junior |
linux (Ubuntu Mantic): status |
Incomplete |
New |
|
| 2023-09-02 04:01:58 |
Sergio Durigan Junior |
qemu (Ubuntu Kinetic): status |
Triaged |
Won't Fix |
|
| 2023-09-02 04:02:06 |
Sergio Durigan Junior |
qemu (Ubuntu Kinetic): assignee |
Sergio Durigan Junior (sergiodj) |
|
|
| 2023-09-02 04:30:14 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2023-09-02 04:30:15 |
Ubuntu Kernel Bot |
linux (Ubuntu Jammy): status |
New |
Incomplete |
|
| 2023-09-02 04:30:17 |
Ubuntu Kernel Bot |
linux (Ubuntu Lunar): status |
New |
Incomplete |
|
| 2023-09-02 04:37:16 |
Sergio Durigan Junior |
linux (Ubuntu Jammy): status |
Incomplete |
Confirmed |
|
| 2023-09-02 04:37:22 |
Sergio Durigan Junior |
linux (Ubuntu Lunar): status |
Incomplete |
Confirmed |
|
| 2023-09-02 04:37:33 |
Sergio Durigan Junior |
linux (Ubuntu Mantic): status |
Incomplete |
Confirmed |
|
| 2024-01-25 20:39:35 |
Brian Murray |
linux (Ubuntu Lunar): status |
Confirmed |
Won't Fix |
|
