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".
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
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'/>
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".
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'> 'forbid' >Skylake- Client- IBRS</model> vendor> Intel</ vendor>
<model fallback=
<
<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. share/libvirt/ cpu_map. ..
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/
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/formatdomai n.html# cpu-model- and-topology