On 11/27/2017 09:46 PM, Michael S. Tsirkin wrote:
> On Sat, Nov 25, 2017 at 02:09:31PM +0100, Jan H. Schönherr wrote:
>> Allowing a guest to execute MWAIT without interception enables a guest
>> to put a (physical) CPU into a power saving state, where it takes
>> longer to return from than what may be desired by the host.
>>
>> Don't give a guest that power over a host by default. (Especially,
>> since nothing prevents a guest from using MWAIT even when it is not
>> advertised via CPUID.)
>>
>> This restores the behavior from before Linux 4.12 commit 668fffa3f838
>> ("kvm: better MWAIT emulation for guests") but keeps the option to
>> enable MWAIT in guest for individual VMs.
>
> As others pointed out, an interrupt will wake up the host CPU anyway.
>
> Given that, what's the actual motivation here?
The CPU will wake up, but it will take time depending which C-state the
guest requested and achieved to enter.
Since Linux 4.11 and 4.14 the menu and ladder cpuidle governors, respectively,
allow setting a per CPU wakeup latency requirement -- see, eg, commit c523c68da211
("cpuidle: ladder: Add per CPU PM QoS resume latency support"). Allowing a guest
to execute MWAIT without moderation will bypass that functionality.
Thus, while MWAIT-in-guest is a great thing to have when there are dedicated
CPUs, it is less so, when the CPUs still have to do other activities.
Regards
Jan
