>>> On 3/26/2018 at 09:31 AM, Cole Robinson <crobinso@xxxxxxxxxx> 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 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
