On Fri, Sep 27, 2019 at 8:19 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 27/09/19 16:40, Vitaly Kuznetsov wrote: > > Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > > > >> On 27/09/19 15:53, Vitaly Kuznetsov wrote: > >>> Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > >>> > >>>> Queued, thanks. > >>> > >>> I'm sorry for late feedback but this commit seems to be causing > >>> selftests failures for me, e.g.: > >>> > >>> # ./x86_64/state_test > >>> Testing guest mode: PA-bits:ANY, VA-bits:48, 4K pages > >>> Guest physical address width detected: 46 > >>> ==== Test Assertion Failure ==== > >>> lib/x86_64/processor.c:1089: r == nmsrs > >>> pid=14431 tid=14431 - Argument list too long > >>> 1 0x000000000040a55f: vcpu_save_state at processor.c:1088 (discriminator 3) > >>> 2 0x00000000004010e3: main at state_test.c:171 (discriminator 4) > >>> 3 0x00007f881eb453d4: ?? ??:0 > >>> 4 0x0000000000401287: _start at ??:? > >>> Unexpected result from KVM_GET_MSRS, r: 36 (failed at 194) > >>> > >>> 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. According to the SDM, volume 4, table 2-2, IA-32 Architectural MSRs, 194H is reserved. Sounds like your CPU is mis-architected. :-) > Paolo > > > Oh, btw, this is Intel(R) Xeon(R) CPU E5-2603 v3 > > > > So apparently rdmsr_safe() check in kvm_init_msr_list() is not enough, > > for PMU MSRs we need to do extra. > > >
