On 09/01/2018 09:52, Liran Alon wrote: > > ----- pbonzini@xxxxxxxxxx wrote: > >> On 09/01/2018 09:43, Liran Alon wrote: >>> I'm not sure I 100% agree with this. >>> There should be a way for the userspace agent to disable these >> CPUIDs if wanted. >>> You don't want to lose the ability to expose a mimic of a real >> physical CPU-model of core2duo that >>> doesn't have these CPUIDs. A good solution can be that these >> features will be exposed by default to guests >>> if available on hardware but can still be explicitly not-exposed if >> userspace agent wishes so. >>> The only weird side-effect of this is that live-migration between >> different physical hosts running with >>> exact same QEMU cmdline will result in different CPUID values >> exposed to guest. >> >> In turn, this will cause guests to fail horribly when migrated from >> patched to unpatched hosts (#GP on the first access to >> MSR_IA32_SPEC_CTRL). Shortcuts simply don't work when you take >> migration into account. > > That's true but this will also happen when explicitly exposing new CPUIDs via QEMU cmdline. > The live-migration controller should not attempt to migrate a VM that runs with these CPUIDs to a host > which cannot support them. Indeed libvirt does such a check, and QEMU does it too if you use "-cpu ...,enforce". But if KVM or even QEMU[1] adds flags behind the user's back, the controller cannot even _know_ that the VM cannot be migrated to an unpatched host. Paolo [1] as in this patch: https://lists.nongnu.org/archive/html/qemu-devel/2018-01/txtfadLGhMEF6.txt > But I agree with you, as at least when it is explicit, this scenario can also be checked in QEMU. > (QEMU can check if explicit CPUID flags to expose doesn't match host capabilities).
