On Thu, May 24, 2018 at 11:46 AM, Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote: > 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. Yes, to abet violations of Apple's EULA. Shame on you! > 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. More precisely, MONITOR is not supported by KVM *in its default configuration*. > 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? It is, but at the very least, the documentation needs to be updated to reflect the new reality. This doesn't regress old userspace code, because the old userspace code would not know about KVM_X86_DISABLE_EXITS_MWAIT.
