On Friday, January 03, 2014 08:04:36 PM Gleb Natapov wrote: > On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote: > > Hi All, > > > > Sorry for being late to the party but I just got back from vacation. > > > > There is something deeply wrong here. We should have never gotten to > > intel_pstate_init_cpu(). The VM had to have returned value from the read > > of the max pstate at driver init time and 0 when the CPU was being brought up. > > > > intel_pstate_msrs_not_valid() was added to solve this issue early on > > if I remember correctly it was Josh that reported it then. Is there > > a definative way to detect whether we are running in a VM? > > > Checking for VM is a wrong thing to do here. KVM should behave like it > does not support p-state. > > > Can some one tell me how the nested environment differs in regards to > > reading MSRs? > > > It shouldn't differ, but there may be bug somewhere in nested emulation. > We shouldn't try and hind the bug by doing more checks in Linux but > rather fixing KVM bug that causes Linux to behave incorrectly. Well, fixing the KVM bug is surely welcome. That said, adding checks to ensure that your assumptions are valid is rarely wrong, especially if they are done once per kernel boot. And the kernel only should panic if it cannot continue to run, which isn't the case here. Thanks, Rafael -- 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
