On Sat, 03 Apr 2021 16:52:13 -0000 Christian Ehrhardt <1915...@bugs.launchpad.net> 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 >