[Bug 1887490] Re: [FFe/SRU] Add/Backport EPYC-v3 and EPYC-Rome CPU model

Hello Markus, or anyone else affected,

Accepted libvirt into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/libvirt/6.0.0-0ubuntu8.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: libvirt (Ubuntu Focal)
Status: Triaged => Fix Committed

** Tags removed: verification-done verification-done-focal
** Tags added: verification-needed verification-needed-focal

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/1887490

Title:
[FFe/SRU] Add/Backport EPYC-v3 and EPYC-Rome CPU model

Status in libvirt package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in qemu package in Ubuntu:
Fix Released
Status in libvirt source package in Focal:
Fix Committed
Status in linux source package in Focal:
Fix Released
Status in qemu source package in Focal:
Fix Released

Bug description:
[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 be careful of the fix done for bug 1892826.
It has to be checked if the linking is fine after the rebuild.
The workload still works in groovy despite 2.32 being present (I'd ahve
expected it doesn't), so we will keep the revert as-is for now.
To be sure 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
Was pointing to glibc, does it still and if so does it work (see
below)?
   - 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.

 * 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)

[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

 * 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.

[Other Info]

 * 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1887490/+subscriptions