Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp189098rwl; Thu, 6 Apr 2023 17:15:28 -0700 (PDT) X-Google-Smtp-Source: AKy350Z94fOEi/7jjtUY6fvLcyUPoaK5lRNz8h/80g8qzJTBrhiLP+pKicks1TXa/igJ37AO3/vV X-Received: by 2002:a05:6402:2051:b0:4fb:999:e04c with SMTP id bc17-20020a056402205100b004fb0999e04cmr1078235edb.38.1680826527826; Thu, 06 Apr 2023 17:15:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680826527; cv=none; d=google.com; s=arc-20160816; b=LrDWurEMenmRVNUJx0yJCYSru+9e59Havdm38YABUvX6ELdvPcqd1ET4d7z2tLzhth zcXJGcl4BSWEgc75Vg96sZmG7hf/WbGl+2v6YuMPQ6ExDrjQ0PjqIYoKFL8j7cQV1HlD q/Z+dPUGa3gYeI2EewFjWODnt0UqNl4hPCixyEMD0YTILu3S3iAOUqaRObqbcKklODdn 8/9iFuzwe8tfdiiFTPWiicFLAyipCwuYhyCcGwyT+QCOjHUfHrCtqCdsl9ax2SidiYZW QvZ0tMG0lovsl4XpDDgIzaARZnMj0aW5+xACchoOmSd+/NrTb0CKYSb9o7mYEG6KDpp8 FWmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=Ino5YyBq/GfM+fUdSOf2HFa4ZsDYuj7dqoyVWykvLN0=; b=LvKI4VP3npNR70QGG/Me3xEYV2j+pXvI/QOtbEt5irsDzzPFovLptaN0dE0/eO5inT 0RJ1hFZ9Ke50GLDYsuDHZ3B0MdY9vFuG569dGQRzw8aXBnrCIyxlpcXWH9VZ2KGnXBsx URYJCl0+GnfFOkTcehMIvSEn/dirouL5yooQ5DfOdHGTZoQs6KzAId/d/IKgBSechiwo aGniFUKsiaFy9B3cYcQbHsUPAJIeXooa85IoL+PiZwFS0p0mPy3cJtwlA09WMcuF0ynz 8bEssi1gGVSun9GhSANpPWz4ClLj8bhaSzN+TfoCa6LsEmIaaT5aBxK20ZO3Xz8qR49W zrVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=n4LTyjMa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n12-20020aa7db4c000000b004acbf5579casi2060569edt.472.2023.04.06.17.15.02; Thu, 06 Apr 2023 17:15:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=n4LTyjMa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237261AbjDGAHJ (ORCPT + 99 others); Thu, 6 Apr 2023 20:07:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236825AbjDGAHD (ORCPT ); Thu, 6 Apr 2023 20:07:03 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BCBF786B8 for ; Thu, 6 Apr 2023 17:06:57 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id u11-20020a170902e80b00b001a043e84bdfso23822805plg.23 for ; Thu, 06 Apr 2023 17:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680826017; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Ino5YyBq/GfM+fUdSOf2HFa4ZsDYuj7dqoyVWykvLN0=; b=n4LTyjMaGSYct8qR2/uFWsF8lJ2I/NsaOf1QPwunNmd1BJpFI5usfASmHnbIJTW70u DNOtoCY8+V5kn7qgLAQ9T3tKSLTQ0OiVjgUaouc8G64Hx5SBuZx4Zr8KaaZmdwfP9+ei tCrM1yfRD5tf9a7rLw1O9HAi41/k/Cdi7ITb7UwrvCDV5EJDG4A+Fk3izlynYI8PraH1 Bo1lgo0LtDDyC8I+UHvwLNGubfFMbZBJIi9nmiBpzw17ee4buvvUGRDilUQy/SX2Bh0S h1EOkiHUc/NK8XPF3wJ/nP8KNSHpPdAsgidyq5YIN7bY4STMHMzy7BG+79nkHstr9tHb v1hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680826017; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Ino5YyBq/GfM+fUdSOf2HFa4ZsDYuj7dqoyVWykvLN0=; b=ODS/RhKHAGnnZyMBy0PFH9NGrLMaMLv8aXLyrUxC2kJIUbvp/UK+Kss05pxGkaP3fV p2n1Z/WP4W5aqs1TBFTHDWcXk6JM7A5Neg18MuGfECqd2TQlVFSOAu7o5IZhgLCrLi0b CLF5BfRQa8fOg/eoqVnaXvaN6JzJd/OmO0NMTXqFRO+BpQNS2i5hXZOVgLtGeyDLtu9F KUlgV/PJHr7ydLtM0JSr5bkvbscH75L0RPGTh7uUrdsqBeysokb5CLf1+28C/rJ1QZU9 BNdlYhfS1DDjjZE+6EefLfRFhaWj5KomSHe9i/afnwZU2zd8O3GHtuNla1J7CZMkp2mh 82AA== X-Gm-Message-State: AAQBX9fUSSt2MRoVVih1AlVd9O3ebbbSH4FZy/8czBm+aWBJOve7osv3 MkftMsvPaZUD/IVwr+q9AuQFveadEIE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:bf0c:b0:1a0:52f1:8ea7 with SMTP id bi12-20020a170902bf0c00b001a052f18ea7mr299235plb.12.1680826017296; Thu, 06 Apr 2023 17:06:57 -0700 (PDT) Date: Thu, 6 Apr 2023 17:06:55 -0700 In-Reply-To: <20230214050757.9623-9-likexu@tencent.com> Mime-Version: 1.0 References: <20230214050757.9623-1-likexu@tencent.com> <20230214050757.9623-9-likexu@tencent.com> Message-ID: Subject: Re: [PATCH v4 08/12] KVM: x86/pmu: Disable vPMU if the minimum num of counters isn't met From: Sean Christopherson To: Like Xu Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-7.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 14, 2023, Like Xu wrote: > From: Like Xu > > For compatibility with old software, KVM/AMD should never report less > than four counters if vPMU is supported. Explain _why_. Anchor what "should" be done in hardware specifications and architecture. > Thus KVM should sanity check the number of counters enumerated by perf and > explicitly disable vPMU support if the min isn't met. E.g. if KVM needs 4 > counters and perf says there are 3, then something is wrong and enumerating 4 > to the guest is only going to cause more troubles. Again, state what the patch actually does, not what KVM "should do". E.g. Disable PMU support when running on AMD and perf reports fewer than four general purpose counters. All AMD PMUs must define at least four counters due to AMD's legacy architecture hardcoding the number of counters without providing a way to enumerate the number of counters to software, e.g. from AMD's APM. The legacy architecture defines four performance counters Virtualizing fewer than four counters can lead to guest instability as software expects four counters to be available. > Suggested-by: Sean Christopherson > Signed-off-by: Like Xu > --- > arch/x86/kvm/pmu.h | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h > index d1cc02c8da88..46db5404894e 100644 > --- a/arch/x86/kvm/pmu.h > +++ b/arch/x86/kvm/pmu.h > @@ -170,6 +170,12 @@ static inline void kvm_init_pmu_capability(const struct kvm_pmu_ops *pmu_ops) > if ((is_intel && !kvm_pmu_cap.version) || !kvm_pmu_cap.num_counters_gp) > enable_pmu = false; > > + /* > + * For AMD, disable vPMU if the minimum number of counters isn't met. > + */ Doesn't need to be a multiple line comment. This comment is also useless. It's quite clear from the code that PMU support is being disabled when there aren't enough counters, what's missing is _why_. > + if (!is_intel && kvm_pmu_cap.num_counters_gp < AMD64_NUM_COUNTERS) > + enable_pmu = false; > + > if (!enable_pmu) { > memset(&kvm_pmu_cap, 0, sizeof(kvm_pmu_cap)); > return; > -- > 2.39.1 >