On Tue, Jun 03, 2014 at 10:21:58AM -0400, Gabriel L. Somlo wrote: > On Tue, Jun 03, 2014 at 11:17:48AM +0200, Paolo Bonzini wrote: > > > > I think it's fine as it is now. :) > > On Mon, Jun 02, 2014 at 09:55:18PM -0400, Gabriel L. Somlo wrote: > > > > W.r.t. monitor/mwait, a guest can do one of the following: > > > > 1. Never check CPUID, and never use monitor/mwait > > - This is great, we don't have to do anything about these > > > > 2. Check CPUID for mwait, use it to idle in preference over hlt > > - Linux, Windows, and Mavericks (10.9) do this > > - we never want to have CPUID say "yes" to these, since > > monitor/mwait support will be clunky in the best case, > > and hlt is overwhelmingly preferable! [*] > > > > 3. Never check CPUID, use monitor/mwait with abandon > > - OS X 10.6 .. 10.8 does this > > - emulating monitor/mwait here allows us to boot the guest > > and use it, and perform sysadmin surgery to force a hlt > > based idle > > > > 4. Check CPUID, panic if unavailable > > - OS X 10.5 did this, IIRC. > > - whether I can do kext surgery and get it to stop checking > > CPUID *in addition to* falling back to hlt-based idle is > > TBD. > > - emulating monitor/mwait allows us to boot this type of > > guest, BUT WE ALSO HAVE TO ADVERTISE IT VIA CPUID !!! > > As it is right now, #4 is not being addressed (and we can't just > advertise mwait via cpuid, or we'd be screwing up #2). Yes, I didn't understand 10.5 did #4. > I also feel a bit weird about the "undocumented feature" aspect > of NOT generating an invalid opcode for something that *should* > be an invalid opcode according to the feature set advertised via > cpuid... > > So if there's a way to make it so we can tell QEMU/KVM to > "--enable-mwait" on a per-guest basis, I think that'd be better > than an always-on "undocumented" behavior... > > But then again, I'm most likely missing something about the big > picture... :) > > Thanks much, > --Gabriel -- 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
