From: Like Xu <like.xu.linux@gmail.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Jim Mattson <jmattson@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V5 05/10] KVM: x86/pmu: Disable vPMU if the minimum num of counters isn't met
Date: Mon, 29 May 2023 22:25:22 +0800 [thread overview]
Message-ID: <514b2966-77a6-3b93-f7fe-80e78783ef55@gmail.com> (raw)
In-Reply-To: <ZG6f1GYvtZ/Ndf7H@google.com>
On 25/5/2023 7:37 am, Sean Christopherson wrote:
> On Wed, Apr 19, 2023, Like Xu wrote:
>> Jim, sorry for the late reply.
>>
>> On 11/4/2023 10:58 pm, Jim Mattson wrote:
>>>>>> Jim, does this help you or could you explain more about your confusion ?
>>>>>
>>>>> You say that "fewer than four counters can lead to guest instability
>>>>> as software expects four counters to be available." Your solution is
>>>>> to disable the PMU, which leaves zero counters available. Zero is less
>>>>> than four. Hence, by your claim, disabling the PMU can lead to guest
>>>>> instability. I don't see how this is an improvement over one, two, or
>>>>> three counters.
>
> KVM can't do the right thing regardless. I would rather have KVM explicitly tell
> userspace via that it can't support a vPMU than to carry on with a bogus and
> unexpected setup.
>
>>> Does this actually guarantee that the requisite number of counters are
>>> available and will always be available while the guest is running?
>>
>> Not 100%, the scheduling of physical counters depends on the host perf scheduler.
>
> Or put differently, the same thing that happens on Intel. kvm_pmu_cap.num_counters_gp
> is the number of counters reported by perf when KVM loads, i.e. barring oddities,
> it's the number of counters present in the host. Most importantly, if perf doesn't
> find the expected number of counters, perf will bail and use software only events,
> and then clear all of x86_pmu.
>
> In other words, KVM's new sanity *should* be a nop with respect to current
> behavior. If we're concerned about "unnecessarily" hiding the PMU when there are
> 1-3 counters, I'd be ok with a WARN_ON_ONCE().
>
> Actually, looking more closely, there's unaddressed feedback from v4[*]. Folding
> that in, we can enable the sanity check for both Intel and AMD, though that's a
> bit of a lie since Intel will be '1'. But the code looks pretty!
The below diff looks good to me. Please confirm that the other patches are in
good shape
so that we can iterate on the next version. Thanks.
>
> if (enable_pmu) {
> perf_get_x86_pmu_capability(&kvm_pmu_cap);
>
> /*
> * WARN if perf did NOT disable hardware PMU if the number of
> * architecturally required GP counters aren't present, i.e. if
> * there are a non-zero number of counters, but fewer than what
> * is architecturally required.
> */
> if (!kvm_pmu_cap.num_counters_gp ||
> WARN_ON_ONCE(kvm_pmu_cap.num_counters_gp < pmu_ops->MIN_NR_GP_COUNTERS))
> enable_pmu = false;
> else if (is_intel && !kvm_pmu_cap.version)
> enable_pmu = false;
> }
>
> if (!enable_pmu) {
> memset(&kvm_pmu_cap, 0, sizeof(kvm_pmu_cap));
> return;
> }
>
> [*] https://lore.kernel.org/all/ZC9ijgZBaz6p1ecw@google.com
next prev parent reply other threads:[~2023-05-29 14:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 10:50 [PATCH V5 00/10] KVM: x86: Add AMD Guest PerfMonV2 PMU support Like Xu
2023-04-10 10:50 ` [PATCH V5 01/10] KVM: x86/pmu: Expose reprogram_counters() in pmu.h Like Xu
2023-04-10 10:50 ` [PATCH V5 02/10] KVM: x86/pmu: Return #GP if user sets the GLOBAL_STATUS reserved bits Like Xu
2023-04-10 10:50 ` [PATCH V5 03/10] KVM: x86/pmu: Make part of the Intel v2 PMU MSRs handling x86 generic Like Xu
2023-04-10 10:50 ` [PATCH V5 04/10] KVM: x86: Explicitly zero cpuid "0xa" leaf when PMU is disabled Like Xu
2023-04-10 10:50 ` [PATCH V5 05/10] KVM: x86/pmu: Disable vPMU if the minimum num of counters isn't met Like Xu
2023-04-11 5:36 ` Jim Mattson
2023-04-11 6:17 ` Like Xu
2023-04-11 12:58 ` Jim Mattson
2023-04-11 13:17 ` Like Xu
2023-04-11 14:58 ` Jim Mattson
2023-04-19 9:34 ` Like Xu
2023-05-24 23:37 ` Sean Christopherson
2023-05-29 14:25 ` Like Xu [this message]
2023-04-10 10:50 ` [PATCH V5 06/10] KVM: x86/pmu: Forget PERFCTR_CORE if the min " Like Xu
2023-04-10 10:50 ` [PATCH V5 07/10] KVM: x86/pmu: Constrain the num of guest counters with kvm_pmu_cap Like Xu
2023-04-10 10:50 ` [PATCH V5 08/10] KVM: x86/cpuid: Add a KVM-only leaf to redirect AMD PerfMonV2 flag Like Xu
2023-04-10 10:50 ` [PATCH V5 09/10] KVM: x86/svm/pmu: Add AMD PerfMonV2 support Like Xu
2023-04-10 10:50 ` [PATCH V5 10/10] KVM: x86/cpuid: Add AMD CPUID ExtPerfMonAndDbg leaf 0x80000022 Like Xu
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=514b2966-77a6-3b93-f7fe-80e78783ef55@gmail.com \
--to=like.xu.linux@gmail.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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