On Wed, Jun 04, 2014 at 03:33:38PM -0400, Gabriel L. Somlo wrote: > On Wed, Jun 04, 2014 at 10:08:12PM +0300, Michael S. Tsirkin wrote: > > On Wed, Jun 04, 2014 at 06:34:04PM +0200, Paolo Bonzini wrote: > > > Il 04/06/2014 16:44, Alexander Graf ha scritto: > > > > > > > > > > > >>Obviously, if you really like the current behavior better you can > > > >>always reject whatever patch I'll come up with, but I'd like to at > > > >>least try and see what it would look like :) > > > > > > > >I think it's perfectly fine to leave mwait always implemented as NOP - > > > >it's valid behavior. > > > > > > > >As for the CPUID exposure, that should be a pure QEMU thing. If > > > >overriding CPUID bits the kernel mask tells us doesn't work today, we > > > >should just make it possible :). > > > > > > That should be the purpose of KVM_GET_EMULATED_CPUID, so MWAIT could be > > > added in __do_cpuid_ent_emulated. However, the corresponding QEMU patches > > > were never included. Borislav, can you refresh them? > > > > > > Paolo > > > > I don't understand why would we want mwait bit set in CPUID. > > The only reason we want the nop is because of broken guests which > > don't check CPUID. > > E.g., OS X 10.5 *does* check CPUID, and panics if it doesn't find it. > It needs the MONITOR cpuid flag to be on, *and* the actual > instructions to work. Aha. I didn't realize this. I thought it used mwait without checking CPUID. > HOWEVER: I really do NOT want us to bend over backwards to support it, > I think having 10.6 and up working is good enough. Besides, there are > other problems we'd run into with 10.5 if we got the mwait situation > taken care of, so even more reason to leave well enough alone. > > Thanks, > --Gabriel > > PS. Thanks again for everyone's patience while I wrapped my head > around the fine details :) It's up to you of course. If some guests refuse to run without the CPUID bit, then of course an option to set it might be useful. Sorry about misunderstanding and making noise. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
