On Mon, Jan 06, 2014 at 09:18:44AM -0800, Dirk Brandewie wrote: > On 01/03/2014 02:06 PM, Paolo Bonzini wrote: > >Il 03/01/2014 21:00, Dirk Brandewie ha scritto: > >>+ case MSR_IA32_MPERF: > >>+ case MSR_IA32_APERF: > > > OK I will spin the patch to only add MSR_PLATFORM_INFO. > > >These should never be accessed. A KVM VM will always have > >CPUID[06H].ECX = 0, and the Intel manual says that the MSRs are only > >present if CPUID returns that value with bit 0 set. > > > >I think the actual bug is that intel_pstate_init does not check the > >feature bits in CPUID (either manually or via x86_match_cpu). > > I will add the feature check. > > What are the differences between the first and the nested KVM's? There shouldn't be any. There is a bug in nested emulation probably. > At load time intel_pstate checks that APERF and MPERF are incrementing > and that PLATFORM_INFO has some value. Somehow these checks pass > in the nested environment and we fall over when the CPU is being added > by cpufreq. > KVM does not emulate either of those and inject #GP if one is accessed. Linux catches those #GPs and fixs up rdmsr to return zero. It would be interesting to see ftrace for nested kvm run. -- Gleb. -- 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
