On Mon, Mar 27, 2017 at 06:10:43PM +0200, Alexander Graf wrote: > > > On 27/03/2017 17:46, Eduardo Habkost wrote: > > On Mon, Mar 27, 2017 at 04:26:50PM +0200, Alexander Graf wrote: > > > KVM allows trap and emulate (read: NOP) of the MONITOR and MWAIT > > > instructions. There is work undergoing to enable actual execution > > > of these inside of KVM, but nobody really wants to expose the feature > > > to the guest by default, as it would eat up all of the host CPU. > > > > Isn't this something that should be reported using > > KVM_GET_EMULATED_CPUID? (QEMU still doesn't know how to use > > KVM_GET_EMULATED_CPUID, however.) > > Depends how you look at it. In KVM land there are basically 3 ways to deal > with MONITOR/MWAIT: > > 1) #VMEXIT on every execution, treat them as NOP > 2) let the guest natively execute them (looks like a busy loop for the > host, but saves power) > 3) be smart in KVM about it, add actual emulation and adaptively allow for > native mwait execution or emulated mwait which means we can run inside host > context Which case is going to be enabled when using your patch? Don't you want to make that configurable? This looks like configuration that can't be easily represented using the GET_SUPPORTED_CPUID/KVM_SET_CPUID abstraction, as the ability to enable the feature can't be represented by a single bit. We already have a few cases where we make kvm_arch_get_supported_cpuid() look at something other than just GET_SUPPORTED_CPUID return values (most cases are related to in-kernel irqchip). We can change kvm_arch_get_supported_cpuid() to look at other flags (like one that would configure mwait behavior), and decide to report CPUID_EXT_MONITOR on those cases. Would something like the following make sense? * Having a "mwait=(none|nop|native|smart)" option, to choose mwait behavior * Making kvm_arch_get_supported_cpuid() return CPUID_EXT_MONITOR as supported only if the "mwait" option is not "none". Then: * "-cpu ...,monitor=on" would fail, because mwait=none would be the default * "-cpu ...,mwait=none,monitor=on" would fail * "-cpu ...,mwait=(nop|native|smart)" would fail if host KVM doesn't report the corresponding mwait behavior as supported * "-cpu ...,mwait=(nop|native|smart),monitor=on" would work * "-cpu ...,mwait=(nop|native|smart)" would also work, and probably should enable CPUID_EXT_MONITOR flag by default We could still implement "monitor=force" for debugging, but I think we need something safer than "just ignore what KVM is telling us" for production. -- Eduardo
