Date:   Fri, 12 Mar 2021 08:34:33 -0800
From:   kan.liang@...ux.intel.com
To:     peterz@...radead.org, mingo@...nel.org, acme@...hat.com,
        linux-kernel@...r.kernel.org
Cc:     alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
        eranian@...gle.com, namhyung@...nel.org, ak@...ux.intel.com,
        Kan Liang <kan.liang@...ux.intel.com>
Subject: [PATCH 0/5] Uncore PMON discovery mechanism support

From: Kan Liang <kan.liang@...ux.intel.com>

A mechanism of self-describing HW for the uncore PMOM has been
introduced with the latest Intel platforms. By reading through an MMIO
page worth of information, SW can ‘discover’ all the standard uncore
PMON registers.

With the discovery mechanism, Perf can
- Retrieve the generic uncore unit information of all standard uncore
  blocks, e.g., the address of counters, the address of the counter
  control, the counter width, the access type, etc.
  Perf can provide basic uncore support based on this information.
  For a new platform, perf users will get basic uncore support even if
  the platform-specific enabling code is not ready yet.
- Retrieve accurate uncore unit information, e.g., the number of uncore
  boxes. The number of uncore boxes may be different among machines.
  Current perf hard code the max number of the uncore blocks. On some
  machines, perf may create a PMU for an unavailable uncore block.
  Although there is no harm (always return 0 for the unavailable uncore
  block), it may confuse the users. The discovery mechanism can provide
  the accurate number of available uncore boxes on a machine.

But, the discovery mechanism has some limits,
- Rely on BIOS's support. If a BIOS doesn't support the discovery
  mechanism, the uncore driver will exit with -ENODEV. There is nothing
  changed.
- Only provide the generic uncore unit information. The information for
  the advanced features, such as fixed counters, filters, and
  constraints, cannot be retrieved.
- Only support the standard PMON blocks. Non-standard PMON blocks, e.g.,
  free-running counters, are not supported.
- Only provide an ID for an uncore block. No meaningful name is
  provided. The uncore_type_&typeID_&boxID will be used as the name.
- Enabling the PCI and MMIO type of uncore blocks rely on the NUMA support.
  These uncore blocks require the mapping information from a BUS to a
  die. The current discovery table doesn't provide the mapping
  information. The pcibus_to_node() from NUMA is used to retrieve the
  information. If NUMA is not supported, some uncore blocks maybe
  unavailable.

To locate the MMIO page, SW has to find a PCI device with the unique
capability ID 0x23 and retrieve its BAR address.

The spec can be found at Snow Ridge or Ice Lake server's uncore document.
https://cdrdv2.intel.com/v1/dl/getContent/611319

Kan Liang (5):
  perf/x86/intel/uncore: Parse uncore discovery tables
  perf/x86/intel/uncore: Generic support for the MSR type of uncore
    blocks
  perf/x86/intel/uncore: Rename uncore_notifier to
    uncore_pci_sub_notifier
  perf/x86/intel/uncore: Generic support for the PCI type of uncore
    blocks
  perf/x86/intel/uncore: Generic support for the MMIO type of uncore
    blocks

 arch/x86/events/intel/Makefile           |   2 +-
 arch/x86/events/intel/uncore.c           | 184 +++++++--
 arch/x86/events/intel/uncore.h           |  10 +-
 arch/x86/events/intel/uncore_discovery.c | 626 +++++++++++++++++++++++++++++++
 arch/x86/events/intel/uncore_discovery.h | 131 +++++++
 5 files changed, 922 insertions(+), 31 deletions(-)
 create mode 100644 arch/x86/events/intel/uncore_discovery.c
 create mode 100644 arch/x86/events/intel/uncore_discovery.h

-- 
2.7.4

Powered by blists - more mailing lists