On Fri, 2019-09-27 at 17:46 +0200, Vitaly Kuznetsov wrote: > > > > > > Is this something known already or should I investigate? > > > > > > > > > > No, I didn't know about it, it works here. > > > > > > > > > > > > > Ok, this is a bit weird :-) '194' is 'MSR_ARCH_PERFMON_EVENTSEL0 + > > > > 14'. In intel_pmu_refresh() nr_arch_gp_counters is set to '8', however, > > > > rdmsr_safe() for this MSR passes in kvm_init_msr_list() (but it fails > > > > for 0x18e..0x193!) so it stay in the list. get_gp_pmc(), however, checks > > > > it against nr_arch_gp_counters and returns a failure. > > > > > > Huh, 194h apparently is a "FLEX_RATIO" MSR. I agree that PMU MSRs need > > > to be checked against CPUID before allowing them. > > > > My vote would be to programmatically generate the MSRs using CPUID and the > > base MSR, as opposed to dumping them into the list and cross-referencing > > them against CPUID. E.g. there should also be some form of check that the > > architectural PMUs are even supported. > > Yes. The problem appears to be that msrs_to_save[] and emulated_msrs[] > are global and for the MSRs in question we check > kvm_find_cpuid_entry(vcpu, 0xa, ) to find out how many of them are > available so this can be different for different VMs (and even vCPUs :-) > However, > > "KVM_GET_MSR_INDEX_LIST returns the guest msrs that are supported. The list > varies by kvm version and host processor, but does not change otherwise." > Indeed, "KVM_GET_MSR_INDEX_LIST" returns the guest msrs that KVM supports and they are free from different guest configuration since they're initialized when kvm module is loaded. Even though some MSRs are not exposed to guest by clear their related cpuid bits, they are still saved/restored by QEMU in the same fashion. I wonder should we change "KVM_GET_MSR_INDEX_LIST" per VM? > So it seems that PMU MSRs just can't be there. Revert? >
