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

[Charles Arnold]

>>> On 3/26/2018 at 09:31 AM, Cole Robinson <crobinso at redhat.com> wrote: 
> 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 for the review and suggestions!

Follow up patch coming soon.

- Charles