From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E58DDC4332F for ; Tue, 7 Nov 2023 17:39:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234043AbjKGRjz (ORCPT ); Tue, 7 Nov 2023 12:39:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343785AbjKGR1Y (ORCPT ); Tue, 7 Nov 2023 12:27:24 -0500 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A559111F for ; Tue, 7 Nov 2023 09:27:22 -0800 (PST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5afa86b8d66so80313587b3.3 for ; Tue, 07 Nov 2023 09:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699378042; x=1699982842; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=Qa2wFXn+fN/9MOzm2p0htr7TnYIvjcbd3WdjaN07M/k=; b=SApOfQWYC9LmzzbP04Sz03KN1j6GWowzoqVDrR+eoszpBD1+TxUbsDYAGtwPxXkqyk NqCQ6sGrOYtCKxKtZAzeLOGpotn0YcpE8m92mC+H24JuUAsB2/MEdFzowPNLz90XlGqx keSEhAKp/PG9GixQhyllTirYiuYEQyVNJhFjzz94Y8ap4TejoMErlXnHvq1UlS/sexBv A026cfYfXu1SvfH/0fNJziIahS07Dwpup/3cdwzl5lzxU+EDImxf4H1zW8vWtteL0STB 5q6wH0wof9W6FhaXdj3/IgHerOtS5l1Wu23VmqMSWGifaRf51QvCmiuVGhOL+EOYE+i5 Y8Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699378042; x=1699982842; h=content-transfer-encoding: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=Qa2wFXn+fN/9MOzm2p0htr7TnYIvjcbd3WdjaN07M/k=; b=KcDWXVm48dMb5p4AwX3sWWHUfb1YZesxQShZcNd6ouydgbt/fDCLzX9BEAE92D3WSn oGFYyWgtyNHRQINVVgRldn6ImPeziKjtdOmQf6dhQi/aXYYShporoOt2OPGXlCTeICdw mxB4SL1S6RX+zOnSFbG/m/FqnNARgJVt525HtLSZ5pj5Ew3TcZrhRIy6Q0ucok4V1Gpk 0kNSxDdBLSqTY7wQg6KS5H0YqcnKU7p4lxlYs8iUI9KzN3VtTMYZtfJ8J3Ee+iJ98QAv LYCW3MAoEncWNgfgXASW/4sD6jlAsaz4VCZpMTpyuxDJ3iIrrgpaR4hV/+dl+r4blQrR JQkQ== X-Gm-Message-State: AOJu0YzHMeZ3laVWFYpMFw7CpPRM+qs6vF2ydcA2bIsxXosomjYGLEwH zntBmafhw+p0ZzY/vkhEQ51qE+NFqPU= X-Google-Smtp-Source: AGHT+IEfx2xJRyHlzos0vemGZEAAO4aiy00M2pBqcV8b4prgzhoMSWSgigaGYOWEUbs4hq72Zazg1t3nACs= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a0d:d88e:0:b0:5a8:33ab:d545 with SMTP id a136-20020a0dd88e000000b005a833abd545mr290916ywe.2.1699378041829; Tue, 07 Nov 2023 09:27:21 -0800 (PST) Date: Tue, 7 Nov 2023 09:27:20 -0800 In-Reply-To: <2c804098-af2b-4f1d-a39f-eb42f58635d7@linux.intel.com> Mime-Version: 1.0 References: <20231104000239.367005-1-seanjc@google.com> <20231104000239.367005-4-seanjc@google.com> <2c804098-af2b-4f1d-a39f-eb42f58635d7@linux.intel.com> Message-ID: Subject: Re: [PATCH v6 03/20] KVM: x86/pmu: Don't enumerate arch events KVM doesn't support From: Sean Christopherson To: Dapeng Mi Cc: Jim Mattson , Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Kan Liang , Jinrong Liang , Like Xu , Aaron Lewis Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 07, 2023, Dapeng Mi wrote: >=20 > On 11/4/2023 8:41 PM, Jim Mattson wrote: > > On Fri, Nov 3, 2023 at 5:02=E2=80=AFPM Sean Christopherson wrote: > > > Don't advertise support to userspace for architectural events that KV= M > > > doesn't support, i.e. for "real" events that aren't listed in > > > intel_pmu_architectural_events. On current hardware, this effectivel= y > > > means "don't advertise support for Top Down Slots". > > NR_REAL_INTEL_ARCH_EVENTS is only used in intel_hw_event_available(). > > As discussed (https://lore.kernel.org/kvm/ZUU12-TUR_1cj47u@google.com/)= , > > intel_hw_event_available() should go away. > >=20 > > Aside from mapping fixed counters to event selector and unit mask > > (fixed_pmc_events[]), KVM has no reason to know when a new > > architectural event is defined. >=20 >=20 > Since intel_hw_event_available() would be removed, it looks the enum > intel_pmu_architectural_events and intel_arch_events[] array become usele= ss. > We can directly simply modify current fixed_pmc_events[] array and use it= to > store fixed counter events code and umask. Yep, I came to the same conclusion. This is what I ended up with yesterday= : /* * Map fixed counter events to architectural general purpose event encoding= s. * Perf doesn't provide APIs to allow KVM to directly program a fixed count= er, * and so KVM instead programs the architectural event to effectively reque= st * the fixed counter. Perf isn't guaranteed to use a fixed counter and may * instead program the encoding into a general purpose counter, e.g. if a * different perf_event is already utilizing the requested counter, but the= end * result is the same (ignoring the fact that using a general purpose count= er * will likely exacerbate counter contention). * * Note, reference cycles is counted using a perf-defined "psuedo-encoding"= , * there is no architectural general purpose encoding for reference TSC cyc= les. */ static u64 intel_get_fixed_pmc_eventsel(int index) { const struct { u8 eventsel; u8 unit_mask; } fixed_pmc_events[] =3D { [0] =3D { 0xc0, 0x00 }, /* Instruction Retired / PERF_COUNT= _HW_INSTRUCTIONS. */ [1] =3D { 0x3c, 0x00 }, /* CPU Cycles/ PERF_COUNT_HW_CPU_CY= CLES. */ [2] =3D { 0x00, 0x03 }, /* Reference TSC Cycles / PERF_COUN= T_HW_REF_CPU_CYCLES*/ }; BUILD_BUG_ON(ARRAY_SIZE(fixed_pmc_events) !=3D KVM_PMC_MAX_FIXED); return (fixed_pmc_events[index].unit_mask << 8) | fixed_pmc_events[index].eventsel; } ... static void intel_pmu_init(struct kvm_vcpu *vcpu) { int i; struct kvm_pmu *pmu =3D vcpu_to_pmu(vcpu); struct lbr_desc *lbr_desc =3D vcpu_to_lbr_desc(vcpu); for (i =3D 0; i < KVM_INTEL_PMC_MAX_GENERIC; i++) { pmu->gp_counters[i].type =3D KVM_PMC_GP; pmu->gp_counters[i].vcpu =3D vcpu; pmu->gp_counters[i].idx =3D i; pmu->gp_counters[i].current_config =3D 0; } for (i =3D 0; i < KVM_PMC_MAX_FIXED; i++) { pmu->fixed_counters[i].type =3D KVM_PMC_FIXED; pmu->fixed_counters[i].vcpu =3D vcpu; pmu->fixed_counters[i].idx =3D i + INTEL_PMC_IDX_FIXED; pmu->fixed_counters[i].current_config =3D 0; pmu->fixed_counters[i].eventsel =3D intel_get_fixed_pmc_eve= ntsel(i); } lbr_desc->records.nr =3D 0; lbr_desc->event =3D NULL; lbr_desc->msr_passthrough =3D false; }