Description of problem: Host CPU does not provide required features: monitor Version-Release number of selected component (if applicable): rhel8 host: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 12 On-line CPU(s) list: 0-11 Thread(s) per core: 2 Core(s) per socket: 6 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 23 Model: 8 Model name: AMD Ryzen 5 2600 Six-Core Processor Stepping: 2 CPU MHz: 3763.435 CPU max MHz: 3400.0000 CPU min MHz: 1550.0000 BogoMIPS: 6786.24 Virtualization: AMD-V L1d cache: 32K L1i cache: 64K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 0-11 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 constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca nested rhv 4.3.7: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 12 On-line CPU(s) list: 0-11 Thread(s) per core: 1 Core(s) per socket: 12 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 23 Model: 8 Model name: AMD Ryzen 5 2600 Six-Core Processor Stepping: 2 CPU MHz: 3393.620 BogoMIPS: 6787.24 Virtualization: AMD-V Hypervisor vendor: KVM Virtualization type: full L1d cache: 64K L1i cache: 64K L2 cache: 512K L3 cache: 16384K NUMA node0 CPU(s): 0-11 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 art rep_good nopl extd_apicid eagerfpu pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw perfctr_core retpoline_amd ssbd ibpb vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 virt_ssbd arat npt nrip_save How reproducible: in customer site on AMD Ryzen 5 2600 Six-Core Processor Steps to Reproduce: 1. install rhel 8 host and enable nested virtualization 2. deploy rhv (manager + host) 3. try to start vm on the rhv Actual results: vm fails with the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor Expected results: vm will start Additional info:
Libvirt debug logs and information of installed components such as libvirt or virt module in general would be appreciated. Thanks.
Hi Marian From the version.txt, there is no libvirt version info. From the libvirtd.log, I can see the following info: 2020-02-06 15:29:22.218+0000: 6006: info : libvirt version: 4.5.0, package: 23.el7_7.3 (CentOS BuildSystem <http://bugs.centos.org>, 2019-12-02-17:45:06, x86-02.bsys.centos.org) It seems the libvirt version showed in logs belong to RHEL-7.*. So can you show more info about the libvirt/virt module info? I will try to reproduce if I have more info about the env. Thank you.
The bug description talks about RHEL-8, while the logs show RHEL-7.7. Since you're talking about nested virtualization, I guess the setup is as follows (it really should have been part of the bug description): - host with RHEL-8 (no idea which version though) installed - first level VM with RHEL-7.7 - starting a second level VM inside the RHEL-7.7 VM fails If all this is correct, we need the following additional data to be able to investigate the issue: From the RHEL-8 host: - exact version of libvirt and qemu-kvm packages - output of "virsh capabilities" command - output of "virsh domcapabilities" command - XML definition of the shutoff first level VM (virsh dumpxml --inactive $VM) - XML definition of the running first level VM (virsh dumpxml $VM) - /var/log/libvirt/qemu/$VM.log corresponding to the first level VM From the first level VM with RHEL-7.7: - output of "virsh capabilities" command - output of "virsh domcapabilities" command Thanks.
Extracting the data requested by comment 5 from provided attachments: RHEL-8 host package versions: - libvirt-4.5.0-35.2.module_el8.1.0+266+ba744077.rpm - qemu-kvm-2.12.0-88.module_el8.1.0+266+ba744077.2.rpm virsh capabilities on RHEL-8 host: <cpu> <arch>x86_64</arch> <model>EPYC-IBPB</model> <vendor>AMD</vendor> <microcode version='134251021'/> <topology sockets='1' cores='6' threads='2'/> <feature name='ht'/> <feature name='osxsave'/> <feature name='xsaves'/> <feature name='cmp_legacy'/> <feature name='extapic'/> <feature name='skinit'/> <feature name='wdt'/> <feature name='tce'/> <feature name='topoext'/> <feature name='perfctr_core'/> <feature name='perfctr_nb'/> <feature name='invtsc'/> <pages unit='KiB' size='4'/> <pages unit='KiB' size='2048'/> <pages unit='KiB' size='1048576'/> </cpu> virsh domcapabilities on RHEL-8 host: <mode name='host-model' supported='yes'> <model fallback='forbid'>EPYC-IBPB</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='arch-capabilities'/> <feature policy='require' name='cmp_legacy'/> <feature policy='require' name='perfctr_core'/> <feature policy='require' name='invtsc'/> <feature policy='require' name='virt-ssbd'/> <feature policy='require' name='skip-l1dfl-vmentry'/> <feature policy='disable' name='monitor'/> </mode> CPU definition from the XML of the first level VM: <cpu mode='host-passthrough' check='partial'> <topology sockets='1' cores='6' threads='2'/> </cpu> virsh capabilities from the first level VM: <cpu> <arch>x86_64</arch> <model>Opteron_G2</model> <vendor>AMD</vendor> <microcode version='16777317'/> <topology sockets='1' cores='12' threads='1'/> <feature name='vme'/> <feature name='ht'/> <feature name='pclmuldq'/> <feature name='ssse3'/> <feature name='fma'/> <feature name='sse4.1'/> <feature name='sse4.2'/> <feature name='x2apic'/> <feature name='movbe'/> <feature name='popcnt'/> <feature name='tsc-deadline'/> <feature name='aes'/> <feature name='xsave'/> <feature name='osxsave'/> <feature name='avx'/> <feature name='f16c'/> <feature name='rdrand'/> <feature name='hypervisor'/> <feature name='arat'/> <feature name='fsgsbase'/> <feature name='tsc_adjust'/> <feature name='bmi1'/> <feature name='avx2'/> <feature name='smep'/> <feature name='bmi2'/> <feature name='rdseed'/> <feature name='adx'/> <feature name='smap'/> <feature name='clflushopt'/> <feature name='sha-ni'/> <feature name='arch-facilities'/> <feature name='xsaveopt'/> <feature name='xsavec'/> <feature name='xgetbv1'/> <feature name='mmxext'/> <feature name='fxsr_opt'/> <feature name='pdpe1gb'/> <feature name='cmp_legacy'/> <feature name='cr8legacy'/> <feature name='abm'/> <feature name='sse4a'/> <feature name='misalignsse'/> <feature name='3dnowprefetch'/> <feature name='osvw'/> <feature name='perfctr_core'/> <feature name='ibpb'/> <feature name='virt-ssbd'/> <pages unit='KiB' size='4'/> <pages unit='KiB' size='2048'/> <pages unit='KiB' size='1048576'/> </cpu> virsh domcapabilities from the first level VM: <mode name='host-model' supported='yes'> <model fallback='forbid'>EPYC-IBPB</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='cmp_legacy'/> <feature policy='require' name='virt-ssbd'/> <feature policy='disable' name='monitor'/> <feature policy='disable' name='svm'/> </mode> From the provided data we can see that while the host CPU supports the "monitor" feature, QEMU is not enabling it for the first level VM. The virsh domcapabilities snippet from RHEL-8 host shows what features will be enabled/disabled with either host-model or host-passthrough and "monitor" is disabled there. The output of virsh capabilities from inside the first level VM confirms "monitor" is not supported by the virtual CPU. It's one of the reasons the CPU is described as Opteron_G2 rather than EPYC. Thus running a second level VM with <cpu match="exact"> <model>EPYC</model> <feature name="ibpb" policy="require" /> <feature name="virt-ssbd" policy="require" /> <topology cores="1" sockets="16" threads="1" /> </cpu> fails. Possible workarounds are adding <feature name="monitor" policy="disable"/> or changing <cpu match="exact"> to <cpu match="exact" check="none"/> in the XML for the second level VM. Anyway, I'm passing this to QEMU folks for checking whether "monitor" is expected to be filtered out from a VM started with -cpu host.
I have the same problem, which effectively prevents me from testing oVirt on an EPYC machine (no, it is not an option to configure the "bare metal" as an oVirt host, the oVirt host must run as L1-VM in my setup). Searching around I came to this page (https://wiki.qemu.org/Features/CPUModels) which states that "the 'monitor' feature was never supported by KVM, but it is included in many CPU models". It seems that the monitor feature is deliberately filtered out to keep ABI backward compatibility. This reference has also been mentioned in a previous report (https://bugzilla.redhat.com/show_bug.cgi?id=1685656). I have found no way to undo the filtering, e.g. forcing the feature in the libvirt cpu configuration for the L1 oVirt host does not work. So while one way to solve this might be to somehow prevent qemu from filtering the monitor feature (obviously not easy to do), another way might be to simply not require this feature in VM configurations generated by oVirt. After all, I can start the L2 VMs configured on my L1 oVirt-host manually using virsh after editing the cpu section. So it seems that the monitor feature is not really required to run the L2 VMs. For e.g. educational purposes it would be great to be able to run one or more oVirt host as L1 VMs on EPYC hardware. It seems a pity that this fails simply because of this unsupported flag.
Not exposing the monitor flag by default on host passthrough mode is intentional. The reason for this is not ABI compatibility. Short explanation is that it would make all VCPUs use 100% of the host CPUs. Long explanation is at the following commits: commit 6f131f13e68d648a8e4f083c667ab1acd88ce4cd Author: Michael S. Tsirkin <mst> Date: Fri Jun 22 22:22:05 2018 +0300 kvm: support -overcommit cpu-pm=on|off With this flag, kvm allows guest to control host CPU power state. This increases latency for other processes using same host CPU in an unpredictable way, but if decreases idle entry/exit times for the running VCPU, so to use it QEMU needs a hint about whether host CPU is overcommitted, hence the flag name. Follow-up patches will expose this capability to guest (using mwait leaf). Based on a patch by Wanpeng Li <kernellwp> . Signed-off-by: Michael S. Tsirkin <mst> Message-Id: <20180622192148.178309-2-mst> Signed-off-by: Paolo Bonzini <pbonzini> commit 2266d44311321a833d569cd4deb46cca6021d0e7 Author: Michael S. Tsirkin <mst> Date: Fri Jun 22 22:22:05 2018 +0300 i386/cpu: make -cpu host support monitor/mwait When guest CPU PM is enabled, and with -cpu host, expose the host CPU MWAIT leaf in the CPUID so guest can make good PM decisions. Note: the result is 100% CPU utilization reported by host as host no longer knows that the CPU is halted. Signed-off-by: Michael S. Tsirkin <mst> Reviewed-by: Eduardo Habkost <ehabkost> Message-Id: <20180622192148.178309-3-mst> Signed-off-by: Paolo Bonzini <pbonzini>
I believe the actual problem with oVirt has no relation to "-cpu host", so if we want to pursue a solution to the problems in oVirt, the summary of this BZ needs to be fixed (or another BZ needs to be opened).
(In reply to Jiri Denemark from comment #9) > Anyway, I'm passing this to QEMU folks for checking whether "monitor" is > expected to be filtered out from a VM started with -cpu host. Short answer: yes, it is expected to be filtered out, and libvirt's cpu_map.xml is not expected to include 'monitor' on any of the CPU models.
(In reply to Eduardo Habkost from comment #14) > Short answer: yes, it is expected to be filtered out, and libvirt's > cpu_map.xml is not expected to include 'monitor' on any of the CPU models. I don't know if this was the intended approach, but after removing "<feature name='monitor'/>" from /usr/share/libvirt/cpu_map/x86_EPYC-IBPB.xml the installation of the hosted engine finally went through. Thanks!
Michael, I just tested your solution on a Ryzen 7 2700 machine in a nested virtualization (running VirtualBox under Windows 10). The Hosted engine went through, but when it comes to the stage to move the machine to NFS and rebuilt the Hosted Engine, it fails and aborts the deployment.
Jirko, what's the status of this bug? Is there any blocker? We have another instance of the problem, I can reproduce it, https://bugzilla.redhat.com/show_bug.cgi?id=1689362#c27, and our QE can reproduce it too. Both L0 and L1 hosts are el8 with Advanced Virt. I believe it's easily reproducible but tell me if you need more info.
(In reply to Hetz Ben Hamo from comment #22) > Michael, I just tested your solution on a Ryzen 7 2700 machine in a nested > virtualization (running VirtualBox under Windows 10). The Hosted engine went > through, but when it comes to the stage to move the machine to NFS and > rebuilt the Hosted Engine, it fails and aborts the deployment. I doubt that the problem that you have encountered is related to this bug. If your problem occurs *after* the installation of the hosted engine goes through successfully, you should open a new bug report.The problem discussed here prevents the successful installation of the hosted engine. It is hard to imagine that it has an impact once the hosted engine is running. (I've used glusterfs as storage for the hosted engine. But this shouldn't make a difference with respect to the problem with the monitor flag.)
I don't install a hosted engine. What's summarized in https://bugzilla.redhat.com/show_bug.cgi?id=1689362#c27 is what happens when I try to run a VM inside an oVirt VM. The same error and problem as discussed here.
(In reply to Milan Zamazal from comment #25) > I don't install a hosted engine. What's summarized in > https://bugzilla.redhat.com/show_bug.cgi?id=1689362#c27 is what happens when > I try to run a VM inside an oVirt VM. The same error and problem as > discussed here. This fits. Doesn't matter if you try to run the hosted engine or any other VM. It's just that you usually choose oVirt as your base system (either on the hardware or as VM) when you want the VMs hosted by oVirt to be managed by the hosted engine. So the first nested VM that fails will usually be the hosted engine. While "debugging" this, I created the nested VMs using virsh, of course.
(In reply to Milan Zamazal from comment #23) > Jirko, what's the status of this bug? Is there any blocker? Well, the main blocker is finding the right solution as we can't just simply remove "monitor" from the existing AMD models. I have an idea how we could solve this, but I still need to think about it more to make sure it wouldn't break anything.
(In reply to Michael Lipp from comment #16) > (In reply to Eduardo Habkost from comment #14) > > Short answer: yes, it is expected to be filtered out, and libvirt's > > cpu_map.xml is not expected to include 'monitor' on any of the CPU models. > > I don't know if this was the intended approach, but after removing "<feature > name='monitor'/>" from /usr/share/libvirt/cpu_map/x86_EPYC-IBPB.xml the > installation of the hosted engine finally went through. Thanks! It's worked for me, my CPU is: AMD Ryzen 7 1700X Eight-Core Processor The enviroment is: libvirt-6.6.0-2.fc33.x86_64 I have fedora 33 and into it I have centos8(ovirt44), after delete the feature the into libvirt VM(centos8) start correctly the nested VM (debian-10). Thanks a lot for the workarround.
Hi Marian, This seems to be a common issue with a workaround, iirc. Can you please KCS it?
Just to make it clear in this BZ (I said that already in another bug, but forgot to copy it here): removing "monitor" feature from any file in /usr/share/libvirt/cpu_map is not a good general workaround. It is going to work temporarily on a single host, but things will break when a domain using the modified CPU model is migrated to another host or even when you upgrade libvirt while such domain is running. The correct workaround is modifying domain XML and disabling the monitor feature there. For example: <cpu mode='custom' match='exact'> <model fallback='forbid'>EPYC</model> <feature name="monitor" policy="disable"/> </cpu>
Understood. Small question: is it possible that the team would add it as an option to the GUI of creating/modifying a VM please?
(In reply to Hetz Ben Hamo from comment #31) > Understood. > > Small question: is it possible that the team would add it as an option to > the GUI of creating/modifying a VM please? Affects the automatic hosted engine installation as well.
(In reply to Hetz Ben Hamo from comment #31) > Small question: is it possible that the team would add it as an option to > the GUI of creating/modifying a VM please? Libvirt has no GUI so this really depends on what a particular GUI you're using supports. If you're talking about virt-manager, I think the goal there was to avoid adding ways of tunning for every possible knobs and instead introduce let the advanced users directly change the appropriate parts of domain XML. Anyway, I'm not a developer (or even a regular user) of any GUI built on top of libvirt, but I suspect adding a feature to easily configure a libvirt workaround is hardly justifiable. After all it's libvirt that's broken and should be fixed. I returned back to my idea I mentioned in comment 27 after letting it settle down a bit and I still thing I should be able to fix this without breaking anything. I'm starting to work on the fix.
Patches sent upstream for review: https://www.redhat.com/archives/libvir-list/2020-November/msg01222.html
Tested on AMD Ryzen 9 3900X CPU and a virtual RHVH 4.4.2 with cpu mode='host-passthrough'. The nested HostedEngine VM fails to deploy with "Host CPU does not provide required features: monitor". Removing the "monitor" flag from the files /usr/share/libvirt/cpu_map/x86_EPYC*xml in RHVH, makes the deploy to succeed.
Can we get this backported to 8.3.0.1?
(In reply to Sandro Bonazzola from comment #36) > Can we get this backported to 8.3.0.1? Do you mean RHEL-AV 8.3.1 or a z-stream batch update 1 of RHEL-AV 8.3.0?
(In reply to Jiri Denemark from comment #37) > (In reply to Sandro Bonazzola from comment #36) > > Can we get this backported to 8.3.0.1? > > Do you mean RHEL-AV 8.3.1 or a z-stream batch update 1 of RHEL-AV 8.3.0? batch update 1 of RHEL-AV 8.3.0 but if not possible 8.3.1 would be better than 8.4.0.
Reproduce the bug on libvirt-libs-6.6.0-8.module+el8.3.1+8648+130818f2.x86_64 with the steps on comment 9: 1. check the cpu info on host: [host] # virsh capabilities <capabilities> <host> <uuid>36383738-3231-4336-5538-34323252384a</uuid> <cpu> <arch>x86_64</arch> <model>EPYC-IBPB</model> <vendor>AMD</vendor> ... [host] # virsh capabilities | grep monitor # (not outputs) [host]# virsh domcapabilities ... <mode name='host-model' supported='yes'> <model fallback='forbid'>EPYC-IBPB</model> <vendor>AMD</vendor> ... <feature policy='require' name='pschange-mc-no'/> <feature policy='disable' name='monitor'/> </mode> ... 2. start L1 guest with cpu model as host-passthrough: [host] # virsh dumpxml rhel --inactive | grep cpu <cpu mode='host-passthrough' check='partial' migratable='on'/> 3. check the cpu info on L1 guest, the guest cpu is recognized as Opteron_G2 as 'mointor' is not supported by qemu: [L1 guest] # virsh capabilities <capabilities> <host> <uuid>2fd12140-ed5a-4fe6-96e5-7cfd8861056e</uuid> <cpu> <arch>x86_64</arch> <model>Opteron_G2</model> <vendor>AMD</vendor> <microcode version='134222416'/> <topology sockets='1' dies='1' cores='1' threads='1'/> <feature name='vme'/> <feature name='pclmuldq'/> <feature name='ssse3'/> ... [L1 guest]# virsh domcapabilities <mode name='host-model' supported='yes'> <model fallback='forbid'>EPYC-IBPB</model> <vendor>AMD</vendor> <feature policy='require' name='x2apic'/> ... <feature policy='disable' name='monitor'/> <feature policy='disable' name='svm'/> </mode> <mode name='custom' supported='yes'> <model usable='yes'>qemu64</model> <model usable='yes'>qemu32</model> ... <model usable='no'>EPYC-Rome</model> <model usable='yes'>EPYC-IBPB</model> <model usable='yes'>EPYC</model> <model usable='yes'>Dhyana</model> ... 4. start L2 guest with cpu as: [L1 guest] # virsh dumpxml rh ... <cpu mode='custom' match='exact' check='partial'> <model fallback='allow'>EPYC</model> <feature policy='require' name='ibpb'/> <feature policy='require' name='virt-ssbd'/> </cpu> [L1 guest] # virsh start rh error: Failed to start domain rh error: the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor Update the libvirt to latest libvirt-6.6.0-10.module+el8.3.1+9163+37dc0a58.x86_64 1. check cpu info on the host: # virsh capabilities <capabilities> <host> <uuid>36383738-3231-4336-5538-34323252384a</uuid> <cpu> <arch>x86_64</arch> <model>EPYC-IBPB</model> <vendor>AMD</vendor> <microcode version='134222416'/> <counter name='tsc' frequency='2096062000'/> <topology sockets='1' dies='1' cores='2' threads='2'/> <feature name='ht'/> ***** <feature name='monitor'/> **** <feature name='osxsave'/> <feature name='xsaves'/> <feature name='cmp_legacy'/> <feature name='extapic'/> <feature name='skinit'/> <feature name='wdt'/> <feature name='tce'/> <feature name='topoext'/> <feature name='perfctr_core'/> <feature name='perfctr_nb'/> <feature name='invtsc'/> <feature name='clzero'/> <feature name='xsaveerptr'/> <feature name='npt'/> <feature name='lbrv'/> <feature name='svm-lock'/> <feature name='nrip-save'/> <feature name='tsc-scale'/> <feature name='vmcb-clean'/> <feature name='flushbyasid'/> <feature name='decodeassists'/> <feature name='pause-filter'/> <feature name='pfthreshold'/> <pages unit='KiB' size='4'/> <pages unit='KiB' size='2048'/> <pages unit='KiB' size='1048576'/> </cpu> # virsh domcapabilities <mode name='host-model' supported='yes'> <model fallback='forbid'>EPYC-IBPB</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='arch-capabilities'/> <feature policy='require' name='xsaves'/> <feature policy='require' name='cmp_legacy'/> <feature policy='require' name='perfctr_core'/> <feature policy='require' name='invtsc'/> <feature policy='require' name='clzero'/> <feature policy='require' name='xsaveerptr'/> <feature policy='require' name='virt-ssbd'/> <feature policy='require' name='npt'/> <feature policy='require' name='nrip-save'/> <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='monitor'/> </mode> 2. start the L1 guest with cpu as host-passthrough and check the cpu info, the cpu model is "EPYC-IBPB" # virsh capabilities <capabilities> <host> <uuid>2fd12140-ed5a-4fe6-96e5-7cfd8861056e</uuid> <cpu> <arch>x86_64</arch> <model>EPYC-IBPB</model> <vendor>AMD</vendor> <microcode version='134222416'/> <topology sockets='1' dies='1' cores='1' threads='1'/> <feature name='x2apic'/> <feature name='tsc-deadline'/> <feature name='osxsave'/> <feature name='hypervisor'/> <feature name='tsc_adjust'/> <feature name='arch-capabilities'/> <feature name='xsaves'/> <feature name='cmp_legacy'/> <feature name='perfctr_core'/> <feature name='clzero'/> <feature name='xsaveerptr'/> <feature name='virt-ssbd'/> <feature name='npt'/> <feature name='nrip-save'/> <feature name='rdctl-no'/> <feature name='skip-l1dfl-vmentry'/> <feature name='mds-no'/> <feature name='pschange-mc-no'/> <pages unit='KiB' size='4'/> <pages unit='KiB' size='2048'/> <pages unit='KiB' size='1048576'/> </cpu> 3. start the L2 guest with cpu as EPYC, guest can start successfully: # virsh start rh Domain rh started # virsh dumpxml rh <cpu mode='custom' match='exact' check='full'> <model fallback='forbid'>EPYC</model> <feature policy='require' name='ibpb'/> <feature policy='require' name='virt-ssbd'/> <feature policy='disable' name='monitor'/> <feature policy='require' name='x2apic'/> <feature policy='require' name='hypervisor'/> <feature policy='disable' name='svm'/> <feature policy='require' name='topoext'/> </cpu> All the result is as expected.
set it as verified as comment 44
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (virt:8.3 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:0639