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

[Maciej Wieczor-Retman]

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