2017-04-04 14:51+0200, Alexander Graf:
On 04/04/2017 02:39 PM, Radim KrÄmÃÅ wrote:We have tried to pass host's CPUID MWAIT leaf and it still failed:
2017-04-03 12:04+0200, Alexander Graf:So for that we should try and see if changing the exposed CPUID MWAIT leaf
So coming back to the original patch, is there anything that should keep usJust minor issues:
from exposing MWAIT straight into the guest at all times?
* OS X on Core 2 fails for unknown reason if we disable the instruction
trapping, which is an argument against doing it by default
helps. Currently we return 0/0 which is pretty bogus and might be the reason
OSX fails.
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 ...
Ah, makes sense.* idling guests would consume host CPU, which is a significant changeThat's the same as today, as idling guests with MWAIT would also today end
in behavior and shouldn't be done without userspace's involvement
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.
Nice. MWAIT could also use setting of arbitrary values for its leaf,I think the best compromise is to add a capability for the MWAIT VM-exitPlease see my patch to force enable CPUID bits ;).
controls and let userspace expose MWAIT if it wishes to.
Will send a patch.
but a generic interface for that would probably look clunky on the
command line ...