[virt-tools-list] [PATCH] [RFC] CPU model capabilities vs domcapabilities

[Cole Robinson]

On 03/23/2018 04:35 PM, Charles Arnold wrote:
> The issue is when the host has been updated with microcode for Spectre
> but qemu has _not_ been updated. In this scenario (as an example),
> 'virsh capabilities' shows the host cpu model as IvyBridge-IBRS, which is
> correct. However, 'virsh domcapabilities' shows IvyBridge as the host-model
> and does not show any of the '-IBRS' flavors available under the custom model,
> which is also correct since the qemu does not have Spectre patches.
> 
> Be default, virt-manager uses 'custom' for the cpu mode XML. For example,
> 
>   <cpu mode="custom" match="exact">
>     <model>IvyBridge-IBRS</model>
>   </cpu>
> 
> Starting an installation in the above scenario will fail because qemu
> doesn't understand '-IBRS' but will be okay using the domcapabilities
> model which does not contain '-IBRS'.
> 
> The patch below pulls the cpu model from domcapabilites instead of
> capabilities. Not sure this is the right way to go so please chime in on
> how you think this problem could be solved.
> 

Thanks for the report. I think taking the cpu model name from
domcapabilities mode='host-model' XML is problematic, because there have
been times in the past that the straight host-model name won't actually
work either unless all the <feature> bits are included as well. For
example there are machines with say model=Broadwell, but have CPU flags
disabled that are typically associated with Broadwell, so the only
working config is the entire host-model block which will disable
features as needed.

I think the fix in this case should be to validate that the capabilities
cpu is present in domcapabilities, and if not, log a message and don't
set any CPU value. That should fix the bug.

An improvement here is to switch to host-model when libvirt is new
enough to show host-model data in domcapabilities, but that's more
invasive and can come later

Thanks,
Cole