On 11/17/2017 5:44 AM, Borislav Petkov wrote:
On Thu, Nov 16, 2017 at 12:00:11PM -0600, Natarajan, Janakarajan wrote:
Ah my apologies. So when the pmu is initialized the cpuid entries
aren't available then.
So let's see:
... kvm_arch_vcpu_create() ->
svm_create_vcpu() ->
kvm_vcpu_init() ->
kvm_arch_vcpu_init() ->
<--- HERE
kvm_pmu_init()
But at HERE in kvm_arch_vcpu_init() right before kvm_pmu_init() we do already query
cpuid:
vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
cpuid_query_maxphyaddr first checks for for the 0x80000008 cpuid entry,
and if it can't find it
returns a default value of 36.
When invoked in the kvm_arch_vcpu_init(), the default is being returned.
The vcpu->arch.maxphyaddr
is later updated in the kvm_update_cpuid(), which in my case was setting
the maxphyaddr to 40.
I believe the cpuid entry is not available when invoked in the init call
and a default value is
being used as a placeholder until the entries are updated by qemu.
so it's not like we don't know about cpuid leafs at that point. Which
would mean that the code can be made to set the CPU family earlier,
before kvm_pmu_init() runs so that you have the proper CPU family and
thus have this thing properly designed.
Maybe Paolo and Radim have a better suggestion here...
