.../uncore-frequency/uncore-frequency-common.c | 16 +++++++++++++--- .../uncore-frequency/uncore-frequency-common.h | 8 ++++++-- .../uncore-frequency/uncore-frequency-tpmi.c | 17 ++++++++++++++++- 3 files changed, 35 insertions(+), 6 deletions(-)
In TPMI devices, an instance is a feature copy that's local to the TPMI device. It has its own control and header registers and it is tied to a die that is a unit of uncore control. Uncore Frequency Scaling (UFS) is a special feature in the sense that it can have instances further split into clusters if there is more than one per-die. On older systems the domain_id value exported in sysfs matches the instance value, as in it is unique in the single TPMI device scope. But on newer systems that can have multiple clusters on a single die, the intel-uncore-freq driver behaves differently and the domain_id is a globally unique value - unique on all TPMI devices. Therefore it's difficult to match a specific instance to a set of UFS registers for example visible through /sys/kernel/debug/tpmi directories. Separately exporting the instance value that's local to a TPMI device and not globally unique can help restore the now lost value association. Maciej Wieczor-Retman (2): platform/x86/intel-uncore-freq: Rename instance_id platform/x86/intel-uncore-freq: Expose instance ID in the sysfs .../uncore-frequency/uncore-frequency-common.c | 16 +++++++++++++--- .../uncore-frequency/uncore-frequency-common.h | 8 ++++++-- .../uncore-frequency/uncore-frequency-tpmi.c | 17 ++++++++++++++++- 3 files changed, 35 insertions(+), 6 deletions(-) -- 2.53.0
On Fri, 2026-03-27 at 15:36 +0000, Maciej Wieczor-Retman wrote: > on newer systems that can have multiple clusters on a single die, the > intel-uncore-freq driver behaves differently and the domain_id is a > globally unique value - unique on all TPMI devices. Therefore it's > difficult to match a specific instance to a set of UFS registers for > example visible through /sys/kernel/debug/tpmi directories. Although, I'd say that the key point isn't that "domain_id is globally unique" (though this is true), but that it's a synthetic value generated by the driver rather than representing an actual HW instance ID. Artem.
On 2026-03-27 at 19:51:54 +0200, Artem Bityutskiy wrote: >On Fri, 2026-03-27 at 15:36 +0000, Maciej Wieczor-Retman wrote: >> on newer systems that can have multiple clusters on a single die, the >> intel-uncore-freq driver behaves differently and the domain_id is a >> globally unique value - unique on all TPMI devices. Therefore it's >> difficult to match a specific instance to a set of UFS registers for >> example visible through /sys/kernel/debug/tpmi directories. > >Although, I'd say that the key point isn't that "domain_id is globally >unique" (though this is true), but that it's a synthetic value >generated by the driver rather than representing an actual HW instance >ID. > >Artem. Right, that's worth emphasizing. I'll try to rephrase it when updating the patches. -- Kind regards Maciej Wieczór-Retman
On Fri, 2026-03-27 at 21:03 +0000, Maciej Wieczor-Retman wrote: > On 2026-03-27 at 19:51:54 +0200, Artem Bityutskiy wrote: > > On Fri, 2026-03-27 at 15:36 +0000, Maciej Wieczor-Retman wrote: > > > on newer systems that can have multiple clusters on a single die, > > > the > > > intel-uncore-freq driver behaves differently and the domain_id is > > > a > > > globally unique value - unique on all TPMI devices. Therefore > > > it's > > > difficult to match a specific instance to a set of UFS registers > > > for > > > example visible through /sys/kernel/debug/tpmi directories. > > > > Although, I'd say that the key point isn't that "domain_id is > > globally > > unique" (though this is true), but that it's a synthetic value > > generated by the driver rather than representing an actual HW > > instance > > ID. > > > > Artem. > > Right, that's worth emphasizing. I'll try to rephrase it when > updating the > patches. I think the purpose is not clear. Also need to update the documentation. Let me write one tomorrow. Thanks, Srinivas
On 2026-03-29 at 12:30:59 -0700, srinivas pandruvada wrote: >On Fri, 2026-03-27 at 21:03 +0000, Maciej Wieczor-Retman wrote: >> On 2026-03-27 at 19:51:54 +0200, Artem Bityutskiy wrote: >> > On Fri, 2026-03-27 at 15:36 +0000, Maciej Wieczor-Retman wrote: >> > > on newer systems that can have multiple clusters on a single die, >> > > the >> > > intel-uncore-freq driver behaves differently and the domain_id is >> > > a >> > > globally unique value - unique on all TPMI devices. Therefore >> > > it's >> > > difficult to match a specific instance to a set of UFS registers >> > > for >> > > example visible through /sys/kernel/debug/tpmi directories. >> > >> > Although, I'd say that the key point isn't that "domain_id is >> > globally >> > unique" (though this is true), but that it's a synthetic value >> > generated by the driver rather than representing an actual HW >> > instance >> > ID. >> > >> > Artem. >> >> Right, that's worth emphasizing. I'll try to rephrase it when >> updating the >> patches. > >I think the purpose is not clear. Also need to update the >documentation. >Let me write one tomorrow. > >Thanks, >Srinivas Would it help if the purpose was stated as: "this domain_id value is not attached to a HW instance ID anymore" and then I could show the debug tpmi device mem_dump contents and how it diverges with the domain_id - hence why the instance_id needs to be exported? -- Kind regards Maciej Wieczór-Retman
On Mon, 2026-03-30 at 08:11 +0000, Maciej Wieczor-Retman wrote: > On 2026-03-29 at 12:30:59 -0700, srinivas pandruvada wrote: > > On Fri, 2026-03-27 at 21:03 +0000, Maciej Wieczor-Retman wrote: > > > On 2026-03-27 at 19:51:54 +0200, Artem Bityutskiy wrote: > > > > On Fri, 2026-03-27 at 15:36 +0000, Maciej Wieczor-Retman wrote: > > > > > on newer systems that can have multiple clusters on a single > > > > > die, > > > > > the > > > > > intel-uncore-freq driver behaves differently and the > > > > > domain_id is > > > > > a > > > > > globally unique value - unique on all TPMI devices. Therefore > > > > > it's > > > > > difficult to match a specific instance to a set of UFS > > > > > registers > > > > > for > > > > > example visible through /sys/kernel/debug/tpmi directories. > > > > > > > > Although, I'd say that the key point isn't that "domain_id is > > > > globally > > > > unique" (though this is true), but that it's a synthetic value > > > > generated by the driver rather than representing an actual HW > > > > instance > > > > ID. > > > > > > > > Artem. > > > > > > Right, that's worth emphasizing. I'll try to rephrase it when > > > updating the > > > patches. > > > > I think the purpose is not clear. Also need to update the > > documentation. > > Let me write one tomorrow. > > > > Thanks, > > Srinivas > > Would it help if the purpose was stated as: > "this domain_id value is not attached to a HW instance ID > anymore" > and then I could show the debug tpmi device mem_dump contents and how > it > diverges with the domain_id - hence why the instance_id needs to be > exported? But why you need to have such information? I tried to explain. We should add to uncore documentation in some form. Hope this helps. " This change introduces unique identification for MMIO blocks in TPMI devices, enabling userspace tools like "pepc" (https://github.com/intel/pepc) to provide additional controls through direct MMIO access. "pepc" directly read/write MMIO from user space when possible. While this was straightforward for non-partitioned systems, partitioned systems require additional steps to map MMIO blocks. Background TPMI MMIO Organization TPMI defines MMIO maps organized into blocks for each device, where: - Each block belongs to a different power domain - Each power domain is exposed in sysfs via a domain_id attribute - Power domain scope is per-die (either IO dies or compute dies) - Compute die blocks are ordered before IO die blocks in MMIO space Domain ID Mapping For compute dies, the mapping is architectural with CPUID leaf or via MSR 0x54: - Compute die IDs directly correspond to CPU die IDs - CPU die ID can be obtained from MSR 0x54 or recent CPUID leaves - Example: domain_id = 1 applies to all CPUs with die ID 1 For IO dies, the relationship is generation/platform specific and requires special user space if any control are desired. This is generally not recommended to assume any specific IO organization. But uncore sysfs provides attribute to know die types, if required. Single Partition Example (Granite Rapids) One TPMI device per package with MMIO blocks ordered as: - Compute die 0 (domain_id = 0) - Compute die 1 (domain_id = 1) - IO die 0 (domain_id = 2) - IO die 1 (domain_id = 3) Userspace tools can directly index MMIO space using domain_id, and tools can correlate CPU die IDs with domain_id. Partitioned System Layout With partitioned systems, multiple TPMI devices exist per package: -Partition 0: Compute die 0 Compute die 1 IO die 0 IO die 1 Partition 1: Compute die 0 Compute die 1 IO die 0 IO die 1 CPUs are still enumerated package-wide, so die IDs remain unique per package. So for example a CPU with die ID 3 can map to the first instance in partition 1. The partition ID is non architectural and there is no CPUID leaf or MSR to map CPU to partition number. To maintain a consistent interface without exposing non-architectural partitioning: domain_id remains logically consistent (domain_id = 3 controls CPU die ID 3). Driver internally organizes domain_id. This allows existing user space to continue to use domain_id to map CPU die IDs. IO domains receive logical domain IDs after all compute domain IDs as it has no architectural meaning. But direct MMIO indexing via domain_id is no longer possible. This patchset introduces "instance_id" as a physical index into MMIO blocks: - Single partition systems: instance_id equals domain_id - Partitioned systems: instance_id provides the actual MMIO block index enabling tools like pepc to perform direct MMIO access once it knows partition. "
On 2026-03-30 at 10:10:06 -0700, srinivas pandruvada wrote: >On Mon, 2026-03-30 at 08:11 +0000, Maciej Wieczor-Retman wrote: >> On 2026-03-29 at 12:30:59 -0700, srinivas pandruvada wrote: >> > On Fri, 2026-03-27 at 21:03 +0000, Maciej Wieczor-Retman wrote: >> > > On 2026-03-27 at 19:51:54 +0200, Artem Bityutskiy wrote: >> > > > On Fri, 2026-03-27 at 15:36 +0000, Maciej Wieczor-Retman wrote: >> > > > > on newer systems that can have multiple clusters on a single >> > > > > die, >> > > > > the >> > > > > intel-uncore-freq driver behaves differently and the >> > > > > domain_id is >> > > > > a >> > > > > globally unique value - unique on all TPMI devices. Therefore >> > > > > it's >> > > > > difficult to match a specific instance to a set of UFS >> > > > > registers >> > > > > for >> > > > > example visible through /sys/kernel/debug/tpmi directories. >> > > > >> > > > Although, I'd say that the key point isn't that "domain_id is >> > > > globally >> > > > unique" (though this is true), but that it's a synthetic value >> > > > generated by the driver rather than representing an actual HW >> > > > instance >> > > > ID. >> > > > >> > > > Artem. >> > > >> > > Right, that's worth emphasizing. I'll try to rephrase it when >> > > updating the >> > > patches. >> > >> > I think the purpose is not clear. Also need to update the >> > documentation. >> > Let me write one tomorrow. >> > >> > Thanks, >> > Srinivas >> >> Would it help if the purpose was stated as: >> "this domain_id value is not attached to a HW instance ID >> anymore" >> and then I could show the debug tpmi device mem_dump contents and how >> it >> diverges with the domain_id - hence why the instance_id needs to be >> exported? > >But why you need to have such information? > >I tried to explain. We should add to uncore documentation in some form. >Hope this helps. Thanks for more background information! I'll redact it into cover letter/patch messages and a documentation entry. > >" >This change introduces unique identification for MMIO blocks in TPMI >devices, enabling userspace tools like "pepc" >(https://github.com/intel/pepc) to provide additional controls through >direct MMIO access. "pepc" directly read/write MMIO from user space >when possible. > >While this was straightforward for non-partitioned systems, partitioned >systems require additional steps to map MMIO blocks. > >Background > >TPMI MMIO Organization >TPMI defines MMIO maps organized into blocks for each device, where: >- Each block belongs to a different power domain >- Each power domain is exposed in sysfs via a domain_id attribute >- Power domain scope is per-die (either IO dies or compute dies) >- Compute die blocks are ordered before IO die blocks in MMIO space > >Domain ID Mapping >For compute dies, the mapping is architectural with CPUID leaf or via >MSR 0x54: >- Compute die IDs directly correspond to CPU die IDs >- CPU die ID can be obtained from MSR 0x54 or recent CPUID leaves >- Example: domain_id = 1 applies to all CPUs with die ID 1 > >For IO dies, the relationship is generation/platform specific and >requires special user space if any control are desired. This is >generally not recommended to assume any specific IO organization. >But uncore sysfs provides attribute to know die types, if >required. > >Single Partition Example (Granite Rapids) > >One TPMI device per package with MMIO blocks ordered as: >- Compute die 0 (domain_id = 0) >- Compute die 1 (domain_id = 1) >- IO die 0 (domain_id = 2) >- IO die 1 (domain_id = 3) > >Userspace tools can directly index MMIO space using domain_id, and >tools can correlate CPU die IDs with domain_id. > >Partitioned System Layout >With partitioned systems, multiple TPMI devices exist per package: >-Partition 0: > Compute die 0 > Compute die 1 > IO die 0 > IO die 1 > >Partition 1: > Compute die 0 > Compute die 1 > IO die 0 > IO die 1 > >CPUs are still enumerated package-wide, so die IDs remain unique per >package. >So for example a CPU with die ID 3 can map to the first instance in >partition 1. > >The partition ID is non architectural and there is no CPUID leaf or MSR >to map CPU to partition number. > >To maintain a consistent interface without exposing non-architectural >partitioning: >domain_id remains logically consistent (domain_id = 3 controls CPU die >ID 3). >Driver internally organizes domain_id. This allows existing user space >to continue to use domain_id to map CPU die IDs. > >IO domains receive logical domain IDs after all compute domain IDs as >it has no architectural meaning. >But direct MMIO indexing via domain_id is no longer possible. > >This patchset introduces "instance_id" as a physical index into MMIO >blocks: >- Single partition systems: instance_id equals domain_id >- Partitioned systems: instance_id provides the actual MMIO block index >enabling tools like pepc to perform direct MMIO access once it knows >partition. >"
© 2016 - 2026 Red Hat, Inc.