Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

From: Alexander Graf
Date: Tue Apr 04 2017 - 09:15:56 EST


On 04/04/2017 03:13 PM, Radim KrÄmÃÅ wrote:
2017-04-04 14:51+0200, Alexander Graf:
On 04/04/2017 02:39 PM, Radim KrÄmÃÅ wrote:
2017-04-03 12:04+0200, Alexander Graf:
So coming back to the original patch, is there anything that should keep us
from exposing MWAIT straight into the guest at all times?
Just minor issues:
* OS X on Core 2 fails for unknown reason if we disable the instruction
trapping, which is an argument against doing it by default
So for that we should try and see if changing the exposed CPUID MWAIT leaf
helps. Currently we return 0/0 which is pretty bogus and might be the reason
OSX fails.
We have tried to pass host's CPUID MWAIT leaf and it still failed:
https://www.spinics.net/lists/kvm/msg146686.html

I wouldn't mind breaking that particular combination of OS X and
hardware, but I'm worried to do it because we don't understand why it
broke, so there could be more ...

* idling guests would consume host CPU, which is a significant change
in behavior and shouldn't be done without userspace's involvement
That's the same as today, as idling guests with MWAIT would also today end
up in a NOP emulated loop.

Please bear in mind that I do not advocate to expose the MWAIT CPUID flag.
This is only for the instruction trap.
Ah, makes sense.

I think the best compromise is to add a capability for the MWAIT VM-exit
controls and let userspace expose MWAIT if it wishes to.
Will send a patch.
Please see my patch to force enable CPUID bits ;).
Nice. MWAIT could also use setting of arbitrary values for its leaf,
but a generic interface for that would probably look clunky on the
command line ...


I think we should have an interface similar to smbios for that eventually. Something where you can explicitly set arbitrary CPUID leaf information using leaf specific syntax. There are more leafs where it would make sense - cache topology for example.


Alex