----- 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. 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). -Liran > > Paolo
