[PATCH V2 0/5] Uncore PMON discovery mechanism support

kan.liang
2021-03-17T18:06:33Z

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 3497 bytes --]

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

Changes since V1:
- Use the generic rbtree functions, rb_add() and rb_find(). (Patch 1)
- Add a module parameter, uncore_no_discover. If users don't want the
discovery feature, they can set uncore_no_discover=true. (Patch 1)

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 | 188 ++++++++--
arch/x86/events/intel/uncore.h | 10 +-
arch/x86/events/intel/uncore_discovery.c | 622 +++++++++++++++++++++++++++++++
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