Activity log for bug #2019971

Date Who What changed Old value New value Message
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