** Description changed:
+ [Impact]
+
+ * CPU definitions are added to libvirt as these CPUs are known
+ and added to qemu for execution.
+ And due to that over time some are considered missing in
+ former releases.
+
+ * To really benefit from the new features of these chips
+ they have to be known, therefore new type additions done by
+ upstream should be backported if they generally apply and do
+ not depend on SRU-critical changes.
+
+ * This backports three upstream fixes that just add definitions
+ (no control flow changes)
+
+ [Test Case]
+
+ * Check if it has an EPYC-Rome entry in
+ /usr/share/libvirt/cpu_map/index.xml and the file included
+ there exists.
+
+ * Define a guest like:
+ <cpu mode='custom' match='exact' check='partial'>
+ <model fallback='forbid'>EPYC-Rome</model>
+ </cpu>
+ You can only "really" start this on a system with the
+ matching HW. But even on others it will change from:
+ error: internal error: Unknown CPU model EPYC-Rome
+ to being unable to start for some features missing.
+
+ * libvirt probes a system if a named cpu can be used, after the
+ fix this should include EPYC-Rome
+ $ virsh domcapabilities | grep EPYC
+ <model usable='no'>EPYC-IBPB</model>
+ <model usable='no'>EPYC</model>
+
+ [Regression Potential]
+
+ * Usually these type additions are safe unless they add control flow
+ changes (e.g. to handle yet unknown types of registers or such) but
+ that isn't the case here.
+ A regression if any is to be expected on systems that are close to the
+ newly added type(s). Those will after the update be detected as such
+ if e.g. host-model is used. If then running on a mixed cluster of
+ updated/non-updated systems migrations will only work if the target is
+ updated as well.
+
+ [Other Info]
+
+ * This is the first build since glibc 2.32 arrived in groovy, hence we
+ need to revert the revert done for bug 1892826. It has to be checked
+ if the linking is fine afterwards. That adds two tests that shall be
+ done.
+ - check the linking to point to libtirpc instead of glibc
+ $ eu-readelf -a /usr/lib/libvirt/libvirt_lxc | grep xdr_uint64 | grep
GLOBAL
+ - run the autopkgtest cases as the LXC tests would trigger an issue if
+ there is one
+
+
+ ----
+
## Qemu SRU ##
[Impact]
- * CPU definitions are added to qemu as these CPUs are known.
- And due to that over time are missing in former releases.
+ * CPU definitions are added to qemu as these CPUs are known.
+ And due to that over time are missing in former releases.
- * To really benefit from the new features of these chips
- they have to be known, therefore new type additions done by
- upstream should be backported if they generally apply and do
- not depend on SRU-critical changes.
+ * To really benefit from the new features of these chips
+ they have to be known, therefore new type additions done by
+ upstream should be backported if they generally apply and do
+ not depend on SRU-critical changes.
- * This backports two upstream fixes that just add definitions (no
- control flow changes)
+ * This backports two upstream fixes that just add definitions (no
+ control flow changes)
[Test Case]
- * Probe qemu for the known CPU types (works on all HW)
- $ qemu-system-x86_64 -cpu ? | grep EPYC
- Focal without fix:
- x86 EPYC (alias configured by machine type)
- x86 EPYC-IBPB (alias of EPYC-v2)
- x86 EPYC-v1 AMD EPYC Processor
- x86 EPYC-v2 AMD EPYC Processor (with IBPB)
- Focal with fix also adds:
- x86 EPYC-Rome (alias configured by machine type)
- x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
- x86 EPYC-v3 AMD EPYC Processor
+ * Probe qemu for the known CPU types (works on all HW)
+ $ qemu-system-x86_64 -cpu ? | grep EPYC
+ Focal without fix:
+ x86 EPYC (alias configured by machine type)
+ x86 EPYC-IBPB (alias of EPYC-v2)
+ x86 EPYC-v1 AMD EPYC Processor
+ x86 EPYC-v2 AMD EPYC Processor (with IBPB)
+ Focal with fix also adds:
+ x86 EPYC-Rome (alias configured by machine type)
+ x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
+ x86 EPYC-v3 AMD EPYC Processor
- * Given such HW is available start a KVM guest using those new types
- Since we don't have libvirt support (yet) do so directly in qemu
- commandline like (bootloader is enough)
- $ qemu-system-x86_64 -cpu EPYC-Rome -machine pc-q35-focal,accel=kvm
-nographic
- $ qemu-system-x86_64 -cpu EPYC-v3 -machine pc-q35-focal,accel=kvm
-nographic
+ * Given such HW is available start a KVM guest using those new types
+ Since we don't have libvirt support (yet) do so directly in qemu
+ commandline like (bootloader is enough)
+ $ qemu-system-x86_64 -cpu EPYC-Rome -machine pc-q35-focal,accel=kvm
-nographic
+ $ qemu-system-x86_64 -cpu EPYC-v3 -machine pc-q35-focal,accel=kvm
-nographic
[Regression Potential]
- * This adds new CPU types to the list of known CPUs defining their name
- and features. Generally the changes are contained to those new types
- and only active when selected - and usually only selectable on such new
- machines. Therefore not a lot should change for other users.
- One thing thou, if a user selected an unversioned type (which in this
- case only can be "EPYC") by default it will pick the latest subversion
- that applies. In this case the behavior will change and pick EPYC-v3
- after the fix. But this is the whole purpose of versioned (stay as is)
- and unversioned (move with updates) CPU types - so that should be ok.
- The EPYC-Rome type didn't exist in Focal before, so it can't "change"
- for users.
-
+ * This adds new CPU types to the list of known CPUs defining their name
+ and features. Generally the changes are contained to those new types
+ and only active when selected - and usually only selectable on such new
+ machines. Therefore not a lot should change for other users.
+ One thing thou, if a user selected an unversioned type (which in this
+ case only can be "EPYC") by default it will pick the latest subversion
+ that applies. In this case the behavior will change and pick EPYC-v3
+ after the fix. But this is the whole purpose of versioned (stay as is)
+ and unversioned (move with updates) CPU types - so that should be ok.
+ The EPYC-Rome type didn't exist in Focal before, so it can't "change"
+ for users.
[Other Info]
-
- * Depends on the new kernel 5.4.0-49 or later (Currently in
- focal-proposed)
+
+ * Depends on the new kernel 5.4.0-49 or later (Currently in
+ focal-proposed)
---
Qemu in focal has already support for most (except amd-stibp) flags of
this model.
Please backport the following patches:
https://github.com/qemu/qemu/commit/a16e8dbc043720abcb37fc7dca313e720b4e0f0c
https://github.com/qemu/qemu/commit/143c30d4d346831a09e59e9af45afdca0331e819
** Summary changed:
- Add/Backport EPYC-v3 and EPYC-Rome CPU model
+ [FFe/SRU] Add/Backport EPYC-v3 and EPYC-Rome CPU model
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1887490
Title:
[FFe/SRU] Add/Backport EPYC-v3 and EPYC-Rome CPU model
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1887490/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
