Re: [PATCH v1 0/2] platform/x86/intel-uncore-freq: Expose instance ID in the sysfs

[srinivas pandruvada <srinivas.pandruvada@linux.intel.com>]

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.
"