Add EPYC-Milan model

Hi Markus,
thanks for your (two) reports.
I agree that if we can get it backported without wreaking havoc to existing systems and migrations we should do this. I've added a libvirt bug task and will prepare a PPA with preliminary fixes.

I can get access to a Rome system for some tests, but Milan I'm not sure so I might eventually have a few tests for you to do on the PPAs if that is not too much to ask.

Due to the Easter weekend and other in-flight SRUs for qemu/libvirt I can't promise an asap solution, might be after the weekend until the PPAs are ready :-)

Hi Christian,

thanks for picking this up. No rush, we run with our build in the meantime.
I can also do tests for you on a Milan system, no problem.

I will also try to gather the missing tests and submit them to upstream libvirt.

FYI: Since they are closely related (but not a dup) the discussion of
bug 1921754 will mostly take place here as well.

The initial request lists quite some changes already, but there might
be more needed to fully round this up and get it working smoothly.
At least as long as we consider this back to the last LTS being Focal
the following changes are missing as well:

Libvirt
for amd-stibp
1921880 v6.5.0 892b7c70 cpu_map: Add missing x86 features in 0x80000008 CPUID leaf
For npt and others
1921880 v6.5.0 96a39aad cpu_map: Add missing AMD SVM features
For rdpid
1921880 v6.5.0 6ea3bb19 cpu_map: Add missing x86 features in 0x7 CPUID leaf

Qemu:
For STIBP (AMD) and many others
1921880 v5.0.0 143c30d4 i386: Add 2nd Generation AMD EPYC processors
For FSRM
1921880 v5.1.0 5cb287d2 target/i386: add fast short REP MOV support
For svm_addr_chk and others
1921880 v6.5.0 96a39aad cpu_map: Add missing AMD SVM features

I need to document some of my thoughts (for next time this comes up)

Doing this for recent EPYC we should as well consider the recent
intel chips as well. There we'd have Snowridge [1], but being an atom that
isn't the kind of chip that Ubuntu users of KVM (those that crave for the
latest chip features) are after. Being more and end user chip users are typically
ok to either miss a mini-feature benefit or are ok to run the latest Ubuntu
release. Therefore those do exists but are not needed here:

Libvirt
bug tag hash subject
?? v7.0.0 f0a5cf4b cpu_map: Define and enable Snowridge model
?? v7.0.0 13db542c cpu_map: Add support for split-lock-detect CPU feature
?? v7.0.0 e06dd560 cpu_map: Add support for core-capability CPU feature
?? v7.0.0 59a585fd cputestdata: Add test data for Snowridge

[1]: https://ark.intel.com/content/www/us/en/ark/products/codename/87586/snow-ridge.html

Grml - as always this kind of bugs tend to grow until they are unmanageable
and then it eventually seems better to just ask users to upgrade.

BTW Server-Team Backports [1] nowadays which can help in most cases and does
not have the most of the SRU burden as it is an opt-in solution.

[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports

So overall we'd need (in order to apply) to Focal (and less
to later versions):

Libvirt
bug tag hash subject
1921880 v6.5.0 6ea3bb19 cpu_map: Add missing x86 features in 0x7 CPUID leaf
1921880 v6.5.0 892b7c70 cpu_map: Add missing x86 features in 0x80000008 CPUID leaf
1921880 v6.5.0 96a39aad cpu_map: Add missing AMD SVM features
1921880 v7.0.0 8c5c660b cpu_map: Add support for fsrm CPU feature
1921754 v7.2.0 5c17a7ba cpumap: Add support for ibrs CPU feature
1921880 v7.2.0 5ac6ab2f cpumap: Add support for svme-addr-check CPU feature
1921880 v7.2.0 f321a482 cpu_map: Add EPYC-Milan x86 CPU model
1921880 v7.2.0 d3de79db cpu_map: Install x86_EPYC-Milan.xml
1921880 v7.2.0 b5abf9a1 cpu_map: Fix spelling of svme-addr-chk feature

Qemu
bug tag hash subject
1921880 v5.0.0 143c30d4 i386: Add 2nd Generation AMD EPYC processors
1921880 v5.1.0 5cb287d2 target/i386: add fast short REP MOV support
1921880 v6.0.0 5447089c x86/cpu: Populate SVM CPUID feature bits
1921880 v6.0.0 623972ce i386: Add the support for AMD EPYC 3rd generation processors
1921754 v? not-merged https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01020.html

No matter at which exact scope we end up with, since that is:
- clearly a feature
- very new (partially not yet merged upstream)
it is hard to quick-shove this even into Hirsute :-/

Also in the past it was useful to have it in a completed upstream release
to have more developers pick it up and due to that get coverage and issues
reported. That can often identify required follow on fixes.

Therefore on the timing of this I'd go a slightly bit slower. We might end up
on this by merging the new versions early in the cycle into 21.10 and at that
time re-spin the PPA builds we use here (with any later modifications that
might have happened.)

Until then we can already take a step at pre-verification.
The PPA holds builds with the changes as identified backported to Focal (if it
works). Groovy/Hirsute should be simpler than Focal once we eventually do the
full set for real SRUs.

Indeed TBH I'm considering to SRU these changes only to Hirsute (for being much
closer to the upstream changes, more appliciable and threby less churn and
regression potential). That would make it available to Ubuntu users (via 21.04
directly) and for Ubuntu LTS users indirectly via Server-Team-Backports [1]
as well.

I'll look at Focal and Hirsute PPAs based on this next week then.

[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports

Again, thanks for putting so much thought into this. Yes, the Rome-v2 hasn't been merged, yet. But is trivial, so I expect no problems.

As for the Ubuntu integration, targeting this for 21.10 makes sense. By then most things should be in place. In the meantime having a PPA or in the server-backports repo would be great.

Mid-term I think it would still makes sense to get it into focal proper. Icelake is there and it hasn't even launched, yet. AMD is the more attractive platform these days, so having good support is more than just nice to have. But I defer this judgement to the server-team and you.

> Mid-term I think it would still makes sense to get it into focal proper. Icelake is there and
> it hasn't even launched, yet. AMD is the more attractive platform these days, so having good
> support is more than just nice to have. But I defer this judgement to the server-team and you.

I agree, all I'm saying is that if doability or regression risk parts us from the perfect solution this will be a valid fallback and this will never be a "everything is lost" case :-)

I should update this bug as well as I have by accident posted on the other :-/

Report on giving this a first shot for a Focal backport to experiment with it.
The patches are (as expected) not too messy or non-applicable.

Qemu backporting
 143c30d4 already applied due to bug 1882774
 5cb287d2 noise for missing the less used/requested
    353f98c9 avx512-vp2intersect
    b3c7344e tsx-ldtrk
 5447089c applies as-is
 623972ce applies as-is

Libvirt backporting
 6ea3bb19 already applied due to bug 1887490
 892b7c70 already applied due to bug 1887490
 96a39aad already applied due to bug 1887490
 8c5c660b applies as-is
 5c17a7ba applies as-is
 5ac6ab2f applies as-is
 f321a482 some whitespace damage
 d3de79db neededs to be adapted meson->make
 b5abf9a1 sync_qemu_cpu_i386 didn't exist before v6.10

Started building in:
 https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4524

@Markus - if you could test these as time permits that would be great.
Do whatever you usually do with them, but if - in addition - you could check
what happens on live migrations from old to the upgraded package, that would
be awesome.

Testing is done on EPYC 7763 and EPYC 7713 systems

Before: linux 5.4.0-70-generic, libvirt 6.0.0-0ubuntu8.8, qemu 1:4.2-3ubuntu6.14:

# virsh domcapabilities | grep EPYC
      <model fallback='forbid'>EPYC-Rome</model>
      <model usable='yes'>EPYC-Rome</model>
      <model usable='yes'>EPYC-IBPB</model>
      <model usable='yes'>EPYC</model>

After: libvirt 6.0.0-0ubuntu8.9~focalppa1, qemu 1:4.2-3ubuntu6.16~focalppa1

# virsh domcapabilities | grep EPYC
      <model fallback='forbid'>EPYC-Milan</model>
      <model usable='yes'>EPYC-Rome</model>
      <model usable='no'>EPYC-Milan</model>
      <model usable='yes'>EPYC-IBPB</model>
      <model usable='yes'>EPYC</model>

which is expected given that we are missing:

      <feature policy='disable' name='invpcid'/>
      <feature policy='disable' name='pku'/>
      <feature policy='disable' name='fsrm'/>
      <feature policy='disable' name='svme-addr-chk'/>

# qemu-system-x86_64 -cpu ? | grep EPYC
x86 EPYC (alias configured by machine type)
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-Milan (alias configured by machine type)
x86 EPYC-Milan-v1 AMD EPYC-Milan Processor
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
x86 EPYC-Rome-v2 AMD EPYC-Rome Processor
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
x86 EPYC-v3 AMD EPYC Processor

Running a focal instance (5.4.0-70-generic) on the "before" system with the EPYC-Rome type on a Milan CPU results in the following error. This is due to the missing IBRS flag, which is one of the reasons, I'd like to see this backported ;-)

unchecked MSR access error: WRMSR to 0x48 (tried to write 0x0000000000000006) at rIP: 0xffffffff89a73594 (native_write_msr+0x4/0x30)
Call Trace:
 ? __switch_to_xtra+0x1ae/0x5e0
 ? __switch_to_asm+0x34/0x70
 ? __switch_to_asm+0x40/0x70
 ? __switch_to_asm+0x34/0x70
 ? __switch_to_asm+0x40/0x70
 ? __switch_to_asm+0x34/0x70
 __switch_to+0x3b0/0x470
 ? __switch_to_asm+0x40/0x70
 ? __switch_to_asm+0x34/0x70
 __schedule+0x2e3/0x740
 preempt_schedule_common+0x18/0x30
 _cond_resched+0x22/0x30
 stop_one_cpu+0x69/0xa0
 ? sched_ttwu_pending+0xe0/0xe0
 sched_exec+0x92/0xc0
 __do_execve_file.isra.0+0x1fc/0x840
 ? strncpy_from_user+0x4c/0x150
 __x64_sys_execve+0x39/0x50
 do_syscall_64+0x57/0x190
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f31e09ef2fb
Code: 41 89 01 eb da 66 2e 0f 1f 84 00 00 00 00 00 f7 d8 64 41 89 01 eb d6 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 3b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 65 4b 10 00 f7 d8 64 89 01 48
RSP: 002b:00007fff1cfd3b48 EFLAGS: 00000246 ORIG_RAX: 000000000000003b
RAX: ffffffffffffffda RBX: 000055713f000370 RCX: 00007f31e09ef2fb
RDX: 000055713f0d5010 RSI: 000055713f069690 RDI: 000055713f006070
RBP: 00007fff1cfd3d50 R08: 000055713f057cd0 R09: 0000000000000000
R10: 000055713efe9980 R11: 0000000000000246 R...

I finally got (temporary) hold of a EPYC 7713 which should work well for this.

Initial detection is the same on Focal and Hirsute
    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>EPYC-Rome</model>
      <vendor>AMD</vendor>
      <feature policy='require' name='pcid'/>
      <feature policy='require' name='x2apic'/>
      <feature policy='require' name='tsc-deadline'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='erms'/>
      <feature policy='require' name='vaes'/>
      <feature policy='require' name='vpclmulqdq'/>
      <feature policy='require' name='spec-ctrl'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='xsaves'/>
      <feature policy='require' name='cmp_legacy'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='amd-ssbd'/>
      <feature policy='require' name='virt-ssbd'/>
      <feature policy='require' name='rdctl-no'/>
      <feature policy='require' name='skip-l1dfl-vmentry'/>
      <feature policy='require' name='mds-no'/>
      <feature policy='require' name='pschange-mc-no'/>
    </mode>

# virsh domcapabilities | grep EPYC
      <model fallback='forbid'>EPYC-Rome</model>
      <model usable='yes'>EPYC-Rome</model>
      <model usable='yes'>EPYC-IBPB</model>
      <model usable='yes'>EPYC</model>

# qemu-system-x86_64 -cpu ? | grep EPYC
x86 EPYC (alias configured by machine type)
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
x86 EPYC-v3 AMD EPYC Processor

So far all just confirming your reports :-)

I tried all combinations of Focal/Hirsute as Host/Guest
Using Host-passthrough, Host-model and the newest named type available at the time EPYC-Rome.
With EPYC-Rome being just that
  <cpu mode='custom' match='exact' check='partial'>
    <model fallback='forbid'>EPYC-Rome</model>
  </cpu>

I can also confirm that focal works but Hirsute guests trigger the mentioned MSR error:
$ uvt-kvm ssh h-on-f "sudo journalctl" | grep MSR
Apr 15 10:31:01 h-on-h kernel: unchecked MSR access error: WRMSR to 0xda0 (tried to write 0x0000000000000000) at rIP: 0xffffffff9027fa44 (native_write_msr+0x4/0x30)
Apr 15 10:31:01 h-on-h kernel: unchecked MSR access error: RDMSR from 0xda0 at rIP: 0xffffffff9027f968 (native_read_msr+0x8/0x40)

This behavior is the same on Focal&Hirsute.

Note: This does not break/abort the guest, but it is bad still.

Thanks for your awesome testing BTW - it seems all I can do is seconding your findings.
Which is great :-)

Upgrading to the experimental build for Focal

root@f:~# virsh domcapabilities | grep EPYC
      <model fallback='forbid'>EPYC-Milan</model>
      <model usable='yes'>EPYC-Rome</model>
      <model usable='no'>EPYC-Milan</model>
      <model usable='yes'>EPYC-IBPB</model>
      <model usable='yes'>EPYC</model>

    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>EPYC-Milan</model>
      <vendor>AMD</vendor>
      <feature policy='require' name='x2apic'/>
      <feature policy='require' name='tsc-deadline'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='vaes'/>
      <feature policy='require' name='vpclmulqdq'/>
      <feature policy='require' name='spec-ctrl'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='cmp_legacy'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='virt-ssbd'/>
      <feature policy='require' name='rdctl-no'/>
      <feature policy='require' name='skip-l1dfl-vmentry'/>
      <feature policy='require' name='mds-no'/>
      <feature policy='require' name='pschange-mc-no'/>
      <feature policy='disable' name='invpcid'/>
      <feature policy='disable' name='pku'/>
      <feature policy='disable' name='fsrm'/>
      <feature policy='disable' name='svme-addr-chk'/>
    </mode>

x86 EPYC (alias configured by machine type)
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-Milan (alias configured by machine type)
x86 EPYC-Milan-v1 AMD EPYC-Milan Processor
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
x86 EPYC-Rome-v2 AMD EPYC-Rome Processor
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
x86 EPYC-v3 AMD EPYC Processor

I'm glad you have 7713 and 7763 that is great for our joint testing.
I have to state that "my" 7713 have erms and are thereby happy to start
with the EPYC-Milan type.

fsrm I agree, that had to be disabled
  <feature policy='disable' name='fsrm'/>

Full CPU definition
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>EPYC-Milan</model>
    <feature policy='require' name='x2apic'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='disable' name='invpcid'/>
    <feature policy='disable' name='pku'/>
    <feature policy='disable' name='fsrm'/>
    <feature policy='require' name='topoext'/>
    <feature policy='disable' name='svme-addr-chk'/>
  </cpu>

While that is great (new named model, extra named features to specify)
there is a sad point left, for me I still get MSR errors in the guest.

  Apr 15 10:46:08 h-on-f kernel: unchecked MSR access error: WRMSR to 0xda0 (tried to write 0x0000000000000000) at rIP: 0xffffffff9907fa44 (native_write_msr+0x4/0x30)
  Apr 15 10:46:08 h-on-f kernel: unchecked MSR access error: RDMSR from 0xda0 at rIP: 0xffffffff9907f968 (native_read_msr+0x8/0x40)

The same is true for the new EPYC-Rome-v2 type.

If I manually add IBRS like:
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>EPYC-Rome</model>
    <feature policy='require' name='ibrs'/>
  </cpu>
It still trigger the same MSR issue.

But then - just as you said - this is an engineering example.
I even have scary ECC warnings every now and then.
So I'd really be interested for an explicit double check on your 7763 chips.

I haven't went into too much depth on this for this sniff test, but
migrations also didn't trigger issues for me into the new builds and back.

I tried a host-passthrough and a host-model migration, the latter was expanded
to (started on the old host):
    <model fallback='forbid'>EPYC-Rome</model>
    <vendor>AMD</vendor>
    <feature policy='require' name='pcid'/>
    <feature policy='require' name='x2apic'/>
    <feature policy='require' name='tsc-deadline'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='erms'/>
    <feature policy='require' name='vaes'/>
    <feature policy='require' name='vpclmulqdq'/>
    <feature policy='require' name='spec-ctrl'/>
    <feature policy='require' name='stibp'/>
    <feature policy='require' name='arch-capabilities'/>
    <feature policy='require' name='ssbd'/>
    <feature policy='require' name='xsaves'/>
    <feature policy='require' name='cmp_legacy'/>
    <feature policy='require' name='amd-ssbd'/>
    <feature policy='require' name='virt-ssbd'/>
    <feature policy='require' name='rdctl-no'/>
    <feature policy='require' name='skip-l1dfl-vmentry'/>
    <feature policy='require' name='mds-no'/>
    <feature policy='require' name='pschange-mc-no'/>
    <feature policy='require' name='topoext'/>
  </cpu>

No problem due to the new type being around.
Migration forward and back worked fine.

Obviously new types can't be migrated back, but that never was required.

TL;DR
- I was able to confirm Markus test results
- results LGTM (other than a few hickups probably due to my special HW)
- a few questions to Markus (see below)
- With these positive resilts I'd already go on and combine this with
  another SRU to prep merge proposals for F/G/H.
- Once ready and reviewed it will depend on the timing how exactly we
  upload - and then - verify it again

@Markus - Just to be sure on these details let me ask
A)
 - with EPYC-Milan / EPYC-Rome(-v2) types are for you the MSR errors gone on your Chips?
 - Or only when you manually add IBRS and/or other things?
B)
 - since you have multiple EPYC chip types - when the time comes for
   this to become an SRU can I count on you to help test this again
   (in multiple releases)?

C) in https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921754/comments/7
   you said you had these MSR errors on "5.4.0-70 on both host and guest"
   with 5.4.0-71-generic (current). I don't see them. And the fix isn't there
   yet as the kernel bug will only be resolved the next kernel update.
   Therefore - did you really see this with the guest on 5.4 or was this
   a mistake?

I have retested with kernel 5.4.0-72 and qemu 1:4.2-3ubuntu6.15

With 5.4.0-72 on the host and 5.4.0-70 the MSR error (WRMSR to 0x48) is consistently there. After updating the instance to 5.4.0-72 the MSR error is gone without the need for the ibrs flag.
Booting mainline 5.11.14-051114-generic still has the other error (RDMSR from 0xda0).

So right now, I am using our build with the ibrs flag to get rid of the MSR 0x48 error on all distros, even though it's gone with 5.4.0-72 in the guest (and host).

The missing "erms" on my 7713 seems to stem from a buggy BIOS, I will recheck once I have an update from the vendor. The 7763 are on a different platform and the ones we have in production. Those work just fine and don't have any "scary" ECC errors ;-)

I am more than happy to do further testing with/for you.

That should have said:
With 5.4.0-72 on the host and 5.4.0-70 in the guest the MSR error (WRMSR to 0x48) is consistently there.

Awesome thanks for your answers Markus!

I've had a few backport questions (about potential side effects) that I sorted out with Babu (thanks to him as well!).

With that all seems to be in place for another round of PPA updates to [1] combining several changes tat are pre-sniffed SRUs and now build together for all eventually targeted releases.
Those are mostly meant for my own pre-SRU regression testing - no need (but feel free if you want) for anyone else to try these as well.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4525

I have an update regarding the missing "erms". This is apparently a bug in the Milan 1.0.0.1 AGESA, which should be resolved with the next update. Systems with Milan AGESA 1.0.0.0 are not affected.

Hello Markus, or anyone else affected,

Accepted libvirt into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/7.0.0-2ubuntu2 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-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. 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.

Hello Markus, or anyone else affected,

Accepted qemu into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:5.2+dfsg-9ubuntu3 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-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. 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.

Before state as in LP#1921754 (linux 5.11.0-16-generic, qemu 1:5.2+dfsg-9ubuntu2, libvirt 7.0.0-2ubuntu1)

With proposed:

# qemu-system-x86_64 -cpu ? | grep EPYC-Milan
x86 EPYC-Milan (alias configured by machine type)
x86 EPYC-Milan-v1 AMD EPYC-Milan Processor

# virsh domcapabilities
...
    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>EPYC-Milan</model>
      <vendor>AMD</vendor>
      <feature policy='require' name='x2apic'/>
      <feature policy='require' name='tsc-deadline'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='vaes'/>
      <feature policy='require' name='vpclmulqdq'/>
      <feature policy='require' name='spec-ctrl'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='cmp_legacy'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='virt-ssbd'/>
      <feature policy='require' name='rdctl-no'/>
      <feature policy='require' name='skip-l1dfl-vmentry'/>
      <feature policy='require' name='mds-no'/>
      <feature policy='require' name='pschange-mc-no'/>
      <feature policy='disable' name='svme-addr-chk'/>
    </mode>
...

Launching a guest with with EPYC-Milan works:

# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 25
model : 1
model name : AMD EPYC-Milan Processor
stepping : 1
microcode : 0x1000065
cpu MHz : 2445.404
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core invpcid_single ssbd ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves clzero xsaveerptr wbnoinvd arat npt nrip_save umip pku ospke rdpid fsrm
bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips : 4890.80
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

Old
ii libvirt-daemon-system 7.0.0-2ubuntu1 amd64 Libvirt daemon configuration files
ii qemu-system-x86 1:5.2+dfsg-9ubuntu2 amd64 QEMU full system emulation binaries (x86)
New
ii libvirt-daemon-system 7.0.0-2ubuntu2 amd64 Libvirt daemon configuration files
ii qemu-system-x86 1:5.2+dfsg-9ubuntu3 amd64 QEMU full system emulation binaries (x86)

1. regression tests ran and found now new issues triggered by this change
2. qemu types shows Milan
  ubuntu@riccioli:~$ qemu-system-x86_64 -cpu ? | grep EPYC-Milan
  x86 EPYC-Milan (alias configured by machine type)
  x86 EPYC-Milan-v1 AMD EPYC-Milan Processor
3. host-model and host-passthrough guests start fine still
4. Finally migrations between old->new work fine (worked between two LXD containers
   using the different versions) on the Milan HW that I had

As expected in the new builds this is what the CPU got expanded for host-model:
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>EPYC-Milan</model>
    <vendor>AMD</vendor>
    <feature policy='require' name='x2apic'/>
    <feature policy='require' name='tsc-deadline'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='vaes'/>
    <feature policy='require' name='vpclmulqdq'/>
    <feature policy='require' name='spec-ctrl'/>
    <feature policy='require' name='stibp'/>
    <feature policy='require' name='arch-capabilities'/>
    <feature policy='require' name='ssbd'/>
    <feature policy='require' name='cmp_legacy'/>
    <feature policy='require' name='virt-ssbd'/>
    <feature policy='require' name='rdctl-no'/>
    <feature policy='require' name='skip-l1dfl-vmentry'/>
    <feature policy='require' name='mds-no'/>
    <feature policy='require' name='pschange-mc-no'/>
    <feature policy='disable' name='svme-addr-chk'/>
    <feature policy='require' name='topoext'/>
  </cpu>

Thereby confirming Markus report - thanks a lot for your ongoing activity and support Markus!

As per our IRC discussion, I will be releasing those early, without the required SRU aging period. Thanks!

This bug was fixed in the package qemu - 1:5.2+dfsg-9ubuntu3

---------------
qemu (1:5.2+dfsg-9ubuntu3) hirsute; urgency=medium

  * d/p/u/lp-1921754*: add EPYC-Rome-v2 as v1 missed IBRS and thereby fails
    on some HW/Guest combinations e.g. Windows 10 on Threadripper chips
    (LP: #1921754)
  * d/p/u/lp-1921880*: add EPYC-Milan features and named cpu type support
    (LP: #1921880)

 -- Christian Ehrhardt <email address hidden> Wed, 07 Apr 2021 11:58:29 +0200

The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package libvirt - 7.0.0-2ubuntu2

---------------
libvirt (7.0.0-2ubuntu2) hirsute; urgency=medium

  * d/p/u/lp-1921754*: add EPYC-Rome-v2 as v1 missed IBRS and thereby fails
    on some HW/Guest combinations e.g. Windows 10 on Threadripper
    (LP: #1921754)
  * d/p/u/lp-1921880*: add EPYC-Milan features and named cpu type support
    (LP: #1921880)

 -- Christian Ehrhardt <email address hidden> Wed, 07 Apr 2021 13:33:46 +0200

Thanks Lukasz!
Thereby Hirsute completed - now I've uploaded the (more usual SRUs) for Groovy & Focal for review by the SRU Team.

Hello Markus, or anyone else affected,

Accepted qemu into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:5.0-5ubuntu9.8 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-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. 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.

Hello Markus, or anyone else affected,

Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.16 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.

Hello Markus, or anyone else affected,

Accepted libvirt into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/6.6.0-1ubuntu3.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-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. 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.

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

focal: qemu 1:4.2-3ubuntu6.15, libvirt 6.0.0-0ubuntu8.8

# qemu-system-x86_64 -cpu ? | grep EPYC
x86 EPYC (alias configured by machine type)
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
x86 EPYC-v3 AMD EPYC Processor

# virsh domcapabilities
    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>EPYC-Rome</model>
      <vendor>AMD</vendor>
      <feature policy='require' name='pcid'/>
      <feature policy='require' name='x2apic'/>
      <feature policy='require' name='tsc-deadline'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='erms'/>
      <feature policy='require' name='vaes'/>
      <feature policy='require' name='vpclmulqdq'/>
      <feature policy='require' name='spec-ctrl'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='xsaves'/>
      <feature policy='require' name='cmp_legacy'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='amd-ssbd'/>
      <feature policy='require' name='virt-ssbd'/>
      <feature policy='require' name='rdctl-no'/>
      <feature policy='require' name='skip-l1dfl-vmentry'/>
      <feature policy='require' name='mds-no'/>
      <feature policy='require' name='pschange-mc-no'/>
    </mode>

After:

# qemu-system-x86_64 -cpu ? | grep EPYC
x86 EPYC (alias configured by machine type)
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-Milan (alias configured by machine type)
x86 EPYC-Milan-v1 AMD EPYC-Milan Processor
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
x86 EPYC-Rome-v2 AMD EPYC-Rome Processor
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
x86 EPYC-v3 AMD EPYC Processor

    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>EPYC-Milan</model>
      <vendor>AMD</vendor>
      <feature policy='require' name='x2apic'/>
      <feature policy='require' name='tsc-deadline'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='vaes'/>
      <feature policy='require' name='vpclmulqdq'/>
      <feature policy='require' name='spec-ctrl'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='cmp_legacy'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='virt-ssbd'/>
      <feature policy='require' name='rdctl-no'/>
      <feature policy='require' name='skip-l1dfl-vmentry'/>
      <feature policy='require' name='mds-no'/>
      <feature policy='require' name='pschange-mc-no'/>
      <feature policy='disable' name='invpcid'/>
      <feature policy='disable' name='pku'/>
      <feature policy='disable' name='fsrm'/>
      <feature poli...

Thanks Markus.
Also testing groovy here ...

Before:
++-=====================-================-============-=========================================
ii libvirt-daemon-system 6.6.0-1ubuntu3.4 amd64 Libvirt daemon configuration files
ii qemu-system-x86 1:5.0-5ubuntu9.7 amd64 QEMU full system emulation binaries (x86)

$ qemu-system-x86_64 -cpu ? | grep EPYC-Milan
<empty>

After
+++-=====================-================-============-=========================================
ii libvirt-daemon-system 6.6.0-1ubuntu3.5 amd64 Libvirt daemon configuration files
ii qemu-system-x86 1:5.0-5ubuntu9.8 amd64 QEMU full system emulation binaries (x86)

$ qemu-system-x86_64 -cpu ? | grep EPYC-Milan
x86 EPYC-Milan (alias configured by machine type)
x86 EPYC-Milan-v1 AMD EPYC-Milan Processor

libvirt self-identification after the update
    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>EPYC-Milan</model>
      <vendor>AMD</vendor>
      <feature policy='require' name='x2apic'/>
      <feature policy='require' name='tsc-deadline'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='vaes'/>
      <feature policy='require' name='vpclmulqdq'/>
      <feature policy='require' name='spec-ctrl'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='cmp_legacy'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='virt-ssbd'/>
      <feature policy='require' name='rdctl-no'/>
      <feature policy='require' name='skip-l1dfl-vmentry'/>
      <feature policy='require' name='mds-no'/>
      <feature policy='require' name='pschange-mc-no'/>
      <feature policy='disable' name='invpcid'/>
      <feature policy='disable' name='svme-addr-chk'/>
    </mode>

All LGTM in regard to the case.

Regression tests are still running (on proposed this time), I'll mark it overall verified once those completed as well.

The regression tests are good as well with the only hiccups being the known postcopy-after-precopy denial and a known bug in hirsute guest kernels on s390x. Nothing new introduced by the changes as far as I can see.

prep (x86_64) : Pass 20 F/S/N 0/0/0 - RC 0 (10 min 38961 lin)
migrate (x86_64) : Pass 720 F/S/N 36/0/0 - RC 36 (444 min 776248 lin)
cross (x86_64) : Pass 46 F/S/N 0/0/1 - RC 0 (53 min 72466 lin)
misc (x86_64) : Pass 219 F/S/N 0/0/0 - RC 0 (87 min 120975 lin)

prep (s390x) : Pass 20 F/S/N 0/0/0 - RC 0 (10 min 26102 lin)
migrate (s390x) : Pass 718 F/S/N 22/16/0 - RC 22 (501 min 582924 lin)
cross (s390x) : Pass 46 F/S/N 0/0/1 - RC 0 (42 min 66256 lin)
misc (s390x) : Pass 199 F/S/N 2/0/0 - RC 2 (74 min 95916 lin)

This bug was fixed in the package libvirt - 6.6.0-1ubuntu3.5

---------------
libvirt (6.6.0-1ubuntu3.5) groovy; urgency=medium

  * d/p/u/lp-1921754*: add EPYC-Rome-v2 as v1 missed IBRS and thereby fails
    on some HW/Guest combinations e.g. Windows 10 on Threadripper
    (LP: #1921754)
  * d/p/u/lp-1921880*: add EPYC-Milan features and named cpu type support
    (LP: #1921880)

 -- Christian Ehrhardt <email address hidden> Wed, 07 Apr 2021 13:33:46 +0200

This bug was fixed in the package qemu - 1:5.0-5ubuntu9.8

---------------
qemu (1:5.0-5ubuntu9.8) groovy; urgency=medium

  * d/p/u/lp-1921754*: add EPYC-Rome-v2 as v1 missed IBRS and thereby fails
    on some HW/Guest combinations e.g. Windows 10 on Threadripper chips
    (LP: #1921754)
  * d/p/u/lp-1921880*: add EPYC-Milan features and named cpu type support
    (LP: #1921880)

 -- Christian Ehrhardt <email address hidden> Wed, 07 Apr 2021 11:58:29 +0200

This bug was fixed in the package qemu - 1:4.2-3ubuntu6.16

---------------
qemu (1:4.2-3ubuntu6.16) focal; urgency=medium

  * d/p/u/lp-1921754*: add EPYC-Rome-v2 as v1 missed IBRS and thereby fails
    on some HW/Guest combinations e.g. Windows 10 on Threadripper chips
    (LP: #1921754)
  * d/p/u/lp-1921880*: add EPYC-Milan features and named cpu type support
    (LP: #1921880)

 -- Christian Ehrhardt <email address hidden> Wed, 07 Apr 2021 11:58:29 +0200

This bug was fixed in the package libvirt - 6.0.0-0ubuntu8.9

---------------
libvirt (6.0.0-0ubuntu8.9) focal; urgency=medium

  * d/p/u/lp-1921754*: add EPYC-Rome-v2 as v1 missed IBRS and thereby fails
    on some HW/Guest combinations e.g. Windows 10 on Threadripper
    (LP: #1921754)
  * d/p/u/lp-1921880*: add EPYC-Milan features and named cpu type support
    (LP: #1921880)
  * d/p/u/lp-1922907: add ability to parse cpu stepping and thereby correctly
    differentiate skylake and cascadelake chips (LP: #1922907)

 -- Christian Ehrhardt <email address hidden> Wed, 07 Apr 2021 13:33:46 +0200