From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Jim Mattson <jmattson@google.com>,
Sean Christopherson <sean.j.christopherson@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm list <kvm@vger.kernel.org>,
Eric Hankland <ehankland@google.com>,
Peter Shier <pshier@google.com>,
Krish Sadhukhan <krish.sadhukhan@oracle.com>
Subject: Re: [PATCH] kvm: x86: Add Intel PMU MSRs to msrs_to_save[]
Date: Fri, 27 Sep 2019 17:46:58 +0200 [thread overview]
Message-ID: <87a7ap68st.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20190927152608.GC25513@linux.intel.com>
Sean Christopherson <sean.j.christopherson@intel.com> writes:
> On Fri, Sep 27, 2019 at 05:19:25PM +0200, Paolo Bonzini wrote:
>> On 27/09/19 16:40, Vitaly Kuznetsov wrote:
>> > Paolo Bonzini <pbonzini@redhat.com> writes:
>> >
>> >> On 27/09/19 15:53, Vitaly Kuznetsov wrote:
>> >>> Paolo Bonzini <pbonzini@redhat.com> 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)
>
> That "failed at %x" print line should really be updated to make it clear
> that it's printing hex...
>
Yea, I also wasn't sure and had to look in the code. Will send a patch
if no one beats me to it.
>> >>> 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."
So it seems that PMU MSRs just can't be there. Revert?
--
Vitaly
next prev parent reply other threads:[~2019-09-27 15:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 18:20 [PATCH] kvm: x86: Add Intel PMU MSRs to msrs_to_save[] Jim Mattson
2019-09-06 16:48 ` Jim Mattson
[not found] ` <8907173e-9f27-6769-09fc-0b82c22d6352@oracle.com>
2019-09-06 20:30 ` Jim Mattson
2019-09-06 20:43 ` Krish Sadhukhan
2019-09-06 21:08 ` Jim Mattson
2019-09-16 20:43 ` Jim Mattson
2019-09-17 12:39 ` Paolo Bonzini
2019-09-27 13:53 ` Vitaly Kuznetsov
2019-09-27 14:00 ` Paolo Bonzini
2019-09-27 14:40 ` Vitaly Kuznetsov
2019-09-27 15:19 ` Paolo Bonzini
2019-09-27 15:26 ` Sean Christopherson
2019-09-27 15:46 ` Vitaly Kuznetsov [this message]
2019-09-27 15:55 ` Jim Mattson
2019-09-27 15:59 ` Jim Mattson
2019-09-27 16:01 ` Paolo Bonzini
2019-09-27 15:58 ` Xiaoyao Li
2019-09-27 16:06 ` Paolo Bonzini
2019-09-27 16:10 ` Jim Mattson
2019-09-27 16:32 ` Paolo Bonzini
2019-09-27 17:14 ` Sean Christopherson
2019-09-27 17:19 ` Paolo Bonzini
2019-09-27 17:23 ` Sean Christopherson
2019-09-27 17:30 ` Jim Mattson
2019-09-27 17:35 ` Sean Christopherson
2019-09-27 19:03 ` Jim Mattson
2019-09-27 17:22 ` Jim Mattson
2019-09-27 17:34 ` Sean Christopherson
2019-09-27 17:26 ` Jim Mattson
2019-09-27 16:06 ` Jim Mattson
2019-09-27 17:36 ` Jim Mattson
2019-09-27 17:45 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a7ap68st.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=ehankland@google.com \
--cc=jmattson@google.com \
--cc=krish.sadhukhan@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=pshier@google.com \
--cc=sean.j.christopherson@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox