On Monday, January 06, 2014 12:20:32 PM Paolo Bonzini wrote: > Il 04/01/2014 22:38, Rafael J. Wysocki ha scritto: > > On Saturday, January 04, 2014 07:48:13 PM Gleb Natapov wrote: > >> On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote: > >>> Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto: > >>>> Well, it's just a sanity check and it makes the problem go away for the reporter. > >>>> > >>>>>> Your patch is welcome but perhaps it should have a WARN_ON too. > >>>> It has been pulled in already, so the WARN_ON() can only be added via a separate > >>>> patch now. Would you like to prepare that patch? > >>> > >>> Yes, I'll add it together with the CPUID check. I'll send the patch so > >>> that it can get into 3.14. > >>> > >> CPUID check, while correct, will sweep the problem under the rug. Current > >> Linux logic should detect non working pstate in KVM. We should look into > >> why this is not happening for nested. > > > > I agree. It's better not to use CPUID for that in my opinion. > > Among hypervisors, RHEL5's Xen is probably one of the oldest in actual > use with new hardware and new kernels, and the CPUID bit has been fixed > in 2011. Older versions wouldn't run new kernels due to other CPUID > bits not being cleared properly in VMs. > > Is there real hardware that has the CPUID bit set and non-working > pstate? If there's no such real hardware, CPUID is what the SDM says > you should use to detect presence of the APERF/MPERF msrs. OK > Having extra safety checks is fine on top of what the SDM says, but IMO > they should be WARN_ONs. Otherwise you are sweeping bugs under the rug > just as much. As I said I'm not against adding WARN_ON()s there. :-) Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
