2018-05-24 11:18-0700, Jim Mattson: > > I think it would be better to say that the userspace should enable > > MONITOR in CPUID when using KVM_X86_DISABLE_EXITS_MWAIT. > > The problem with that approach is that it breaks the documented API > for KVM_GET_SUPPORTED_CPUID. Specifically, "This ioctl returns x86 > cpuid features which are supported by both the hardware > and kvm." If, for example, we use KVM_GET_SUPPORTED_CPUID to determine > whether or not a target host can support a live migration, then it > becomes impossible to migrate a guest that uses > KVM_X86_DISABLE_EXITS_MWAIT. The original nop-MWAIT implementation is so bad that we didn't say that MONITOR is supported by KVM, we just had to implement those intercepts as NOP instead of #UD becase of a buggy OS X guest. The nop MWAIT implementation is the default and userspace cannot change it before a query to KVM_GET_SUPPORTED_CPUID, so I think we can still say that MONITOR is not supported by KVM. A guest that enables KVM_X86_DISABLE_EXITS_MWAIT could ignore the MONITOR flag when checking its CPUID against target host's KVM_GET_SUPPORTED_CPUID. The migration check should already take non-CPUID KVM capabilities into account, so the real check would just be elsewhere. > Perhaps, like Intel, we have painted ourselves into a corner, and now > we need KVM_GET_TRUE_SUPPORTED_CPUID? I'd rather regress -cpu host, but isn't this soluble with capability checking?
