Message ID | 20231104000239.367005-5-seanjc@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:8f47:0:b0:403:3b70:6f57 with SMTP id j7csp1379411vqu; Fri, 3 Nov 2023 17:03:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGXIpCPm6jH+ob/U3aOCRFZDhr10SaWApyu+tBQ/N3m6AeVEaUMtDkyYo70YCEQ40O0GlEI X-Received: by 2002:a17:90b:38c5:b0:27d:2ce9:d6d5 with SMTP id nn5-20020a17090b38c500b0027d2ce9d6d5mr5752467pjb.12.1699056196637; Fri, 03 Nov 2023 17:03:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1699056196; cv=none; d=google.com; s=arc-20160816; b=Oo357iOSUjgj7oSonOnJDjWD/y68XWRbeIWRkRmWhF9IOuJv6QHJAONxLAk80/7Y3m n8UqQsT3XGFGNK3zc4nINNjelNKhE3LlLsfp3x8kEzjbB18Aypw8H3WpCmNjkPev2omF W6lyzJ6BtaHFEuPk2GaSnpwkR8pCNQsrY8D3nl9FSCzuII0wTx74e92klsj+yrdF+gy+ ZapzdmGDdGC7TdiTIvhrOLSDGegNPaXPZhcSIapkgSU6HWGbins1+c5gIDV7Se7JSHBX GizxzRBq4B9P9Yq/vq9SXcKmOo/qah78w6hpfu8WZMXElpcGrubyuMs0WK2knFd0LAM9 /MhQ== 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:reply-to:dkim-signature; bh=qddZI5QlDYzkDDGMWXMNXP2vKdkDVMrPtOHGx6AbiEs=; fh=z/UQYx9FUD9Bz9JyYrmi2ijAScp29gktKr8lejSUuXU=; b=lg4Z9bXrBoGA0VlJN5dFxDeHGkEpIinoo4c5eXSsL6Dye9tow4ITNJmcf6REymrif/ +ye/0itC76xPZIPfI+fx0SkhAglqsUyoV8Rxe8y3oiZqkBUzQMT3G6hr30GjtEqZHueN sMoYu7pwDgmeZhihajg2vxTqqf6ZyOucux45tQMQAA5C2gm8BQrUO/45m0TA7H7q86R9 0oZr7Wz+flV6qLFKxO/DwPscPg9gxRbDSg8m5wRkWk4dio+C+XnAsbMIc5Ef6hi08Xt/ uXmLQ+1LqkPqDpN+seujvlLAJWWAORLWCtBKGfPwF6kna9zaAuU7MXIwViRrcSIBG0c4 h0Zw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=byDXblP4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id lr3-20020a17090b4b8300b002806cdeecc6si2923971pjb.35.2023.11.03.17.03.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Nov 2023 17:03:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=byDXblP4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id DB165819BB5B; Fri, 3 Nov 2023 17:03:10 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231558AbjKDADC (ORCPT <rfc822;heyuhang3455@gmail.com> + 35 others); Fri, 3 Nov 2023 20:03:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231183AbjKDACv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 3 Nov 2023 20:02:51 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D44F2D49 for <linux-kernel@vger.kernel.org>; Fri, 3 Nov 2023 17:02:48 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id d9443c01a7336-1cc281f1214so20509305ad.2 for <linux-kernel@vger.kernel.org>; Fri, 03 Nov 2023 17:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699056168; x=1699660968; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=qddZI5QlDYzkDDGMWXMNXP2vKdkDVMrPtOHGx6AbiEs=; b=byDXblP4cNIdEpE/d9r52ueFTlhR93MmVW7ZYBxtIjeNwlSRrs/pWCiS6ZL0gXgZeC 3+WyIjyee77RjBGJ5ws1LLp5hjyUWc15DqrMbDOIa4RL04oCeUauUZy1Q3JdHzRVInca jSlOJoygzuKi1+49VvB9fCCGjAKag1Y36mOSJqkz7njdd7U2P870wDCklI6pbd4KUjDN gFTc7XvR5AhSJGEqIPzn/qrGpbl/ViKg+AQ2RGpQgApggXo//rtIm5UZQ+V3tX1RG0Hy rldEN/EWdeJIMPtt2dUvZk86tjo8RNfqauEYpbm+yNS9l/Hdhsq3bz2MAcI6RM4MleIw g8Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699056168; x=1699660968; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qddZI5QlDYzkDDGMWXMNXP2vKdkDVMrPtOHGx6AbiEs=; b=RtGM5sfw2i49Y8OSFUHl2qTa4vgFXI2g9D1L8F0Ywq0qd7FfTEhaT0wetvi1LqTTMF XI8koKhxYo/f9oqYm372v4c32vWRYXhGJFQILFR4txtMzHvlnuFJ2LsK7VppQQloLEnG 4HCKWGeTUaUvp3VyiAPyjLGQHKd1HIDRRHM7c8+H5P2tHVw+dG2zqUxXUY7KBDcfCBjb dgJ1IvIjSnGkfwb+NS3eQKwN7nLrq74Ji8YLcwOKIrdJS82z6EWTDemzYaZuXd/3ndpe kQqyT/YXiMqw3dsdGUJXn6JeQu+ONwuAKAyduGYze09ty3lN/41M58s1rM5keQCyLKp+ iLSw== X-Gm-Message-State: AOJu0Yxso9NSV1l4lQwB4nQaypVfvZlTHQO1B2Vk9MZYjnjjPpPg5El/ 6PpkS5dWJjqFBDDW/BH3GnYjbOJnG0k= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:ab84:b0:1c9:b045:5a8b with SMTP id f4-20020a170902ab8400b001c9b0455a8bmr372275plr.6.1699056168312; Fri, 03 Nov 2023 17:02:48 -0700 (PDT) Reply-To: Sean Christopherson <seanjc@google.com> Date: Fri, 3 Nov 2023 17:02:22 -0700 In-Reply-To: <20231104000239.367005-1-seanjc@google.com> Mime-Version: 1.0 References: <20231104000239.367005-1-seanjc@google.com> X-Mailer: git-send-email 2.42.0.869.gea05f2083d-goog Message-ID: <20231104000239.367005-5-seanjc@google.com> Subject: [PATCH v6 04/20] KVM: x86/pmu: Always treat Fixed counters as available when supported From: Sean Christopherson <seanjc@google.com> To: Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Kan Liang <kan.liang@linux.intel.com>, Dapeng Mi <dapeng1.mi@linux.intel.com>, Jinrong Liang <cloudliang@tencent.com>, Like Xu <likexu@tencent.com>, Jim Mattson <jmattson@google.com>, Aaron Lewis <aaronlewis@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, 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 agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Fri, 03 Nov 2023 17:03:10 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781589550609478750 X-GMAIL-MSGID: 1781589550609478750 |
Series |
KVM: x86/pmu: selftests: Fixes and new tests
|
|
Commit Message
Sean Christopherson
Nov. 4, 2023, 12:02 a.m. UTC
Now that KVM hides fixed counters that can't be virtualized, treat fixed
counters as available when they are supported, i.e. don't silently ignore
an enabled fixed counter just because guest CPUID says the associated
general purpose architectural event is unavailable.
KVM originally treated fixed counters as always available, but that got
changed as part of a fix to avoid confusing REF_CPU_CYCLES, which does NOT
map to an architectural event, with the actual architectural event used
associated with bit 7, TOPDOWN_SLOTS.
The commit justified the change with:
If the event is marked as unavailable in the Intel guest CPUID
0AH.EBX leaf, we need to avoid any perf_event creation, whether
it's a gp or fixed counter.
but that justification doesn't mesh with reality. The Intel SDM uses
"architectural events" to refer to both general purpose events (the ones
with the reverse polarity mask in CPUID.0xA.EBX) and the events for fixed
counters, e.g. the SDM makes statements like:
Each of the fixed-function PMC can count only one architectural
performance event.
but the fact that fixed counter 2 (TSC reference cycles) doesn't have an
associated general purpose architectural makes trying to apply the mask
from CPUID.0xA.EBX impossible. Furthermore, the SDM never explicitly
says that an architectural events that's marked unavailable in EBX affects
the fixed counters.
Note, at the time of the change, KVM didn't enforce hardware support, i.e.
didn't prevent userspace from enumerating support in guest CPUID.0xA.EBX
for architectural events that aren't supported in hardware. I.e. silently
dropping the fixed counter didn't somehow protection against counting the
wrong event, it just enforced guest CPUID.
Arguably, userspace is creating a bogus vCPU model by advertising a fixed
counter but saying the associated general purpose architectural event is
unavailable. But regardless of the validity of the vCPU model, letting
the guest enable a fixed counter and then not actually having it count
anything is completely nonsensical. I.e. even if all of the above is
wrong and it's illegal for a fixed counter to exist when the architectural
event is unavailable, silently doing nothing is still the wrong behavior
and KVM should instead disallow enabling the fixed counter in the first
place.
Fixes: a21864486f7e ("KVM: x86/pmu: Fix available_event_types check for REF_CPU_CYCLES event")
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/vmx/pmu_intel.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
Comments
On Fri, Nov 3, 2023 at 5:02 PM Sean Christopherson <seanjc@google.com> wrote: > > Now that KVM hides fixed counters that can't be virtualized, treat fixed > counters as available when they are supported, i.e. don't silently ignore > an enabled fixed counter just because guest CPUID says the associated > general purpose architectural event is unavailable. > > KVM originally treated fixed counters as always available, but that got > changed as part of a fix to avoid confusing REF_CPU_CYCLES, which does NOT > map to an architectural event, with the actual architectural event used > associated with bit 7, TOPDOWN_SLOTS. > > The commit justified the change with: > > If the event is marked as unavailable in the Intel guest CPUID > 0AH.EBX leaf, we need to avoid any perf_event creation, whether > it's a gp or fixed counter. > > but that justification doesn't mesh with reality. The Intel SDM uses > "architectural events" to refer to both general purpose events (the ones > with the reverse polarity mask in CPUID.0xA.EBX) and the events for fixed > counters, e.g. the SDM makes statements like: > > Each of the fixed-function PMC can count only one architectural > performance event. > > but the fact that fixed counter 2 (TSC reference cycles) doesn't have an > associated general purpose architectural makes trying to apply the mask > from CPUID.0xA.EBX impossible. Furthermore, the SDM never explicitly > says that an architectural events that's marked unavailable in EBX affects > the fixed counters. > > Note, at the time of the change, KVM didn't enforce hardware support, i.e. > didn't prevent userspace from enumerating support in guest CPUID.0xA.EBX > for architectural events that aren't supported in hardware. I.e. silently > dropping the fixed counter didn't somehow protection against counting the > wrong event, it just enforced guest CPUID. > > Arguably, userspace is creating a bogus vCPU model by advertising a fixed > counter but saying the associated general purpose architectural event is > unavailable. But regardless of the validity of the vCPU model, letting > the guest enable a fixed counter and then not actually having it count > anything is completely nonsensical. I.e. even if all of the above is > wrong and it's illegal for a fixed counter to exist when the architectural > event is unavailable, silently doing nothing is still the wrong behavior > and KVM should instead disallow enabling the fixed counter in the first > place. > > Fixes: a21864486f7e ("KVM: x86/pmu: Fix available_event_types check for REF_CPU_CYCLES event") > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/kvm/vmx/pmu_intel.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c > index 8d545f84dc4a..b239e7dbdc9b 100644 > --- a/arch/x86/kvm/vmx/pmu_intel.c > +++ b/arch/x86/kvm/vmx/pmu_intel.c > @@ -147,11 +147,24 @@ static bool intel_hw_event_available(struct kvm_pmc *pmc) As discussed (https://lore.kernel.org/kvm/ZUU12-TUR_1cj47u@google.com/), this function should go away. > u8 unit_mask = (pmc->eventsel & ARCH_PERFMON_EVENTSEL_UMASK) >> 8; > int i; > > + /* > + * Fixed counters are always available if KVM reaches this point. If a > + * fixed counter is unsupported in hardware or guest CPUID, KVM doesn't > + * allow the counter's corresponding MSR to be written. KVM does use > + * architectural events to program fixed counters, as the interface to > + * perf doesn't allow requesting a specific fixed counter, e.g. perf > + * may (sadly) back a guest fixed PMC with a general purposed counter. > + * But if _hardware_ doesn't support the associated event, KVM simply > + * doesn't enumerate support for the fixed counter. > + */ > + if (pmc_is_fixed(pmc)) > + return true; > + > BUILD_BUG_ON(ARRAY_SIZE(intel_arch_events) != NR_INTEL_ARCH_EVENTS); > > /* > * Disallow events reported as unavailable in guest CPUID. Note, this > - * doesn't apply to pseudo-architectural events. > + * doesn't apply to pseudo-architectural events (see above). > */ > for (i = 0; i < NR_REAL_INTEL_ARCH_EVENTS; i++) { > if (intel_arch_events[i].eventsel != event_select || > -- > 2.42.0.869.gea05f2083d-goog >
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c index 8d545f84dc4a..b239e7dbdc9b 100644 --- a/arch/x86/kvm/vmx/pmu_intel.c +++ b/arch/x86/kvm/vmx/pmu_intel.c @@ -147,11 +147,24 @@ static bool intel_hw_event_available(struct kvm_pmc *pmc) u8 unit_mask = (pmc->eventsel & ARCH_PERFMON_EVENTSEL_UMASK) >> 8; int i; + /* + * Fixed counters are always available if KVM reaches this point. If a + * fixed counter is unsupported in hardware or guest CPUID, KVM doesn't + * allow the counter's corresponding MSR to be written. KVM does use + * architectural events to program fixed counters, as the interface to + * perf doesn't allow requesting a specific fixed counter, e.g. perf + * may (sadly) back a guest fixed PMC with a general purposed counter. + * But if _hardware_ doesn't support the associated event, KVM simply + * doesn't enumerate support for the fixed counter. + */ + if (pmc_is_fixed(pmc)) + return true; + BUILD_BUG_ON(ARRAY_SIZE(intel_arch_events) != NR_INTEL_ARCH_EVENTS); /* * Disallow events reported as unavailable in guest CPUID. Note, this - * doesn't apply to pseudo-architectural events. + * doesn't apply to pseudo-architectural events (see above). */ for (i = 0; i < NR_REAL_INTEL_ARCH_EVENTS; i++) { if (intel_arch_events[i].eventsel != event_select ||