Comment 32 for bug 1915063

On Sat, 03 Apr 2021 16:52:13 -0000
Christian Ehrhardt  <email address hidden> wrote:

> That is awesome David,
> qemu64 is like a very low common denominator with only very basic CPU features.
> While "copy host" means "enable all you can".

Also it's worth to try setting real CPU topology for if EPYC cpu model is used.
i.e. use -smp with options that resemble a real EPYC cpu
(for number of core complexes is configured with 'dies' option in QEMU)

> We can surely work with that a bit, but until I get access to the same
> HW I need you to do it.
>
>
> If you run in a console `$virsh domcapabilities` it will spew some XML at you. One of the sections will be for "host-model". In my case that looks like
>
> <mode name='host-model' supported='yes'>
> <model fallback='forbid'>Skylake-Client-IBRS</model>
> <vendor>Intel</vendor>
> <feature policy='require' name='ss'/>
> <feature policy='require' name='vmx'/>
> <feature policy='require' name='hypervisor'/>
> ...
> </mode>
>
>
> That means a names CPU type (the one that is closest to what you have) and some feature additionally enabled/disabled.
>
> If you could please post the full output you have, that can be useful.
> >From there you could go two steps.
> 1. as you see in my example it will list some cpu features on top of the named type.
> If you remove them one by one you might be able to identify the single-cpu featute
> that breaks in your case.
> 2. The named CPU that you have also has a representation, it can be found in
> /usr/share/libvirt/cpu_map...
> That ill list all the CPU features that make up the named type.
> If #1 wasn't sufficient, you can now add those to your guest definition one by one in disabled
> state, example
> <feature policy='disable' name='ss'/>
>
> A description of the underlying mechanism is here
> https://libvirt.org/formatdomain.html#cpu-model-and-topology
>