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 ... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
