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

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

[Maciej Wieczor-Retman]

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

[PATCH v1 1/2] platform/x86/intel-uncore-freq: Rename instance_id

[Maciej Wieczor-Retman]

From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

The "instance" word has a specific meaning in the TPMI uncore frequency
scaling ecosystem. One TPMI device can have multiple copies of a feature
and each copy is called an instance.

The currently used "instance_id" uncore_data struct field is a
sequentially generated value that's used for appending to uncore
directories inside the /sys/devices/system/cpu/intel_uncore_frequency
directory. It has no relation to the TPMI device feature copy.

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
 .../x86/intel/uncore-frequency/uncore-frequency-common.c    | 6 +++---
 .../x86/intel/uncore-frequency/uncore-frequency-common.h    | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
index 7070c94324e0..71c47aa77d3c 100644
--- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
+++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
@@ -268,7 +268,7 @@ int uncore_freq_add_entry(struct uncore_data *data, int cpu)
 		if (ret < 0)
 			goto uncore_unlock;
 
-		data->instance_id = ret;
+		data->seqname_id = ret;
 		scnprintf(data->name, sizeof(data->name), "uncore%02d", ret);
 	} else {
 		scnprintf(data->name, sizeof(data->name), "package_%02d_die_%02d",
@@ -281,7 +281,7 @@ int uncore_freq_add_entry(struct uncore_data *data, int cpu)
 	ret = create_attr_group(data, data->name);
 	if (ret) {
 		if (data->domain_id != UNCORE_DOMAIN_ID_INVALID)
-			ida_free(&intel_uncore_ida, data->instance_id);
+			ida_free(&intel_uncore_ida, data->seqname_id);
 	} else {
 		data->control_cpu = cpu;
 		data->valid = true;
@@ -301,7 +301,7 @@ void uncore_freq_remove_die_entry(struct uncore_data *data)
 	data->control_cpu = -1;
 	data->valid = false;
 	if (data->domain_id != UNCORE_DOMAIN_ID_INVALID)
-		ida_free(&intel_uncore_ida, data->instance_id);
+		ida_free(&intel_uncore_ida, data->seqname_id);
 
 	mutex_unlock(&uncore_lock);
 }
diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h
index 0abe850ef54e..915506de4ebf 100644
--- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h
+++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h
@@ -35,7 +35,7 @@
  * @die_id:		Die id for this instance
  * @domain_id:		Power domain id for this instance
  * @cluster_id:		cluster id in a domain
- * @instance_id:	Unique instance id to append to directory name
+ * @seqname_id:		Unique id to append to directory name
  * @name:		Sysfs entry name for this instance
  * @agent_type_mask:	Bit mask of all hardware agents for this domain
  * @uncore_attr_group:	Attribute group storage
@@ -71,7 +71,7 @@ struct uncore_data {
 	int die_id;
 	int domain_id;
 	int cluster_id;
-	int instance_id;
+	int seqname_id;
 	char name[32];
 	u16  agent_type_mask;
 
-- 
2.53.0

Re: [PATCH v1 1/2] platform/x86/intel-uncore-freq: Rename instance_id

[Artem Bityutskiy]

On Fri, 2026-03-27 at 15:36 +0000, Maciej Wieczor-Retman wrote:
>   * @die_id:		Die id for this instance
>   * @domain_id:		Power domain id for this instance
>   * @cluster_id:		cluster id in a domain
> - * @instance_id:	Unique instance id to append to directory name
> + * @seqname_id:		Unique id to append to directory name
>   * @name:		Sysfs entry name for this instance
>   * @agent_type_mask:	Bit mask of all hardware agents for this domain
>   * @uncore_attr_group:	Attribute group storage
> @@ -71,7 +71,7 @@ struct uncore_data {
>  	int die_id;
>  	int domain_id;
>  	int cluster_id;
> -	int instance_id;
> +	int seqname_id;
>  	char name[32];
>  	u16  agent_type_mask;

Nitpick: "seqname_id" reads like "sequence name ID" rather than a
sequence number. Consider "seqnum" or "sequence_id" for better clarity.
Just a suggestion based on how the name comes across, but not big deal.

Artem.

Re: [PATCH v1 1/2] platform/x86/intel-uncore-freq: Rename instance_id

[Maciej Wieczor-Retman]

On 2026-03-27 at 19:56:58 +0200, Artem Bityutskiy wrote:
>On Fri, 2026-03-27 at 15:36 +0000, Maciej Wieczor-Retman wrote:
>>   * @die_id:		Die id for this instance
>>   * @domain_id:		Power domain id for this instance
>>   * @cluster_id:		cluster id in a domain
>> - * @instance_id:	Unique instance id to append to directory name
>> + * @seqname_id:		Unique id to append to directory name
>>   * @name:		Sysfs entry name for this instance
>>   * @agent_type_mask:	Bit mask of all hardware agents for this domain
>>   * @uncore_attr_group:	Attribute group storage
>> @@ -71,7 +71,7 @@ struct uncore_data {
>>  	int die_id;
>>  	int domain_id;
>>  	int cluster_id;
>> -	int instance_id;
>> +	int seqname_id;
>>  	char name[32];
>>  	u16  agent_type_mask;
>
>Nitpick: "seqname_id" reads like "sequence name ID" rather than a
>sequence number. Consider "seqnum" or "sequence_id" for better clarity.
>Just a suggestion based on how the name comes across, but not big deal.
>
>Artem.

sequence_id sounds good, I'll go for that. What I was going for was "seq" as in
sequential and "name" as in directory name, but looking at it again it does
seem a bit confusing.

-- 
Kind regards
Maciej Wieczór-Retman

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

[Maciej Wieczor-Retman]

From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

To allow userspace matching between the kernel driver and direct TPMI
register accesses, expose the data required to identify a TPMI uncore
frequency control register set.

Specifically expose the instance ID that's unique in the scope of one
TPMI device. The value was previously available through the domain_id
file exported through sysfs. However on newer systems with multiple
clusters attached to a single instance, domain_id is taking on a unique
value, that's not local to the single TPMI device anymore.

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
 .../uncore-frequency/uncore-frequency-common.c  | 10 ++++++++++
 .../uncore-frequency/uncore-frequency-common.h  |  6 +++++-
 .../uncore-frequency/uncore-frequency-tpmi.c    | 17 ++++++++++++++++-
 3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
index 71c47aa77d3c..52a62cad35de 100644
--- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
+++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
@@ -29,6 +29,13 @@ static ssize_t show_domain_id(struct kobject *kobj, struct kobj_attribute *attr,
 	return sysfs_emit(buf, "%u\n", data->domain_id);
 }
 
+static ssize_t show_instance_id(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
+{
+	struct uncore_data *data = container_of(attr, struct uncore_data, instance_id_kobj_attr);
+
+	return sprintf(buf, "%u\n", data->instance_id);
+}
+
 static ssize_t show_fabric_cluster_id(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
 {
 	struct uncore_data *data = container_of(attr, struct uncore_data, fabric_cluster_id_kobj_attr);
@@ -200,6 +207,9 @@ static int create_attr_group(struct uncore_data *data, char *name)
 	if (data->domain_id != UNCORE_DOMAIN_ID_INVALID) {
 		init_attribute_root_ro(domain_id);
 		data->uncore_attrs[index++] = &data->domain_id_kobj_attr.attr;
+		init_attribute_root_ro(instance_id);
+		data->uncore_attrs[index++] = &data->instance_id_kobj_attr.attr;
+
 		init_attribute_root_ro(fabric_cluster_id);
 		data->uncore_attrs[index++] = &data->fabric_cluster_id_kobj_attr.attr;
 		init_attribute_root_ro(package_id);
diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h
index 915506de4ebf..5e00030fedc5 100644
--- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h
+++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h
@@ -36,6 +36,7 @@
  * @domain_id:		Power domain id for this instance
  * @cluster_id:		cluster id in a domain
  * @seqname_id:		Unique id to append to directory name
+ * @instance_id:	Feature instances for a single PCI device
  * @name:		Sysfs entry name for this instance
  * @agent_type_mask:	Bit mask of all hardware agents for this domain
  * @uncore_attr_group:	Attribute group storage
@@ -56,6 +57,7 @@
  * @elc_floor_freq_khz_kobj_attr: Storage for kobject attribute elc_floor_freq_khz
  * @agent_types_kobj_attr: Storage for kobject attribute agent_type
  * @die_id_kobj_attr:	Attribute storage for die_id information
+ * @instance_id_kobj_attr: Attribute storage for feat_instance value
  * @uncore_attrs:	Attribute storage for group creation
  *
  * This structure is used to encapsulate all data related to uncore sysfs
@@ -72,6 +74,7 @@ struct uncore_data {
 	int domain_id;
 	int cluster_id;
 	int seqname_id;
+	int instance_id;
 	char name[32];
 	u16  agent_type_mask;
 
@@ -90,7 +93,8 @@ struct uncore_data {
 	struct kobj_attribute elc_floor_freq_khz_kobj_attr;
 	struct kobj_attribute agent_types_kobj_attr;
 	struct kobj_attribute die_id_kobj_attr;
-	struct attribute *uncore_attrs[15];
+	struct kobj_attribute instance_id_kobj_attr;
+	struct attribute *uncore_attrs[16];
 };
 
 #define UNCORE_DOMAIN_ID_INVALID	-1
diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c
index 1237d9570886..e74e7d2e26b6 100644
--- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c
+++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c
@@ -385,7 +385,21 @@ static u8 io_die_index_next;
 /* Lock to protect io_die_start, io_die_index_next */
 static DEFINE_MUTEX(domain_lock);
 
-static void set_domain_id(int id,  int num_resources,
+static void set_instance_id(int id, struct tpmi_uncore_cluster_info *cluster_info)
+{
+	/*
+	 * In its base form the domain_id is a per-TPMI device value that lists
+	 * feature instances for that specific TPMI device (instances as named by
+	 * the intel_vsec system). On newer platforms the cdie system comes into
+	 * effect which makes domain_id a unique identifier and there is no more
+	 * correlation between the TPMI device and the domain_id number. The old
+	 * version is still relevant so TPMI device scoped information can be
+	 * matched with the data from the TPMI driver.
+	 */
+	cluster_info->uncore_data.instance_id = id;
+}
+
+static void set_domain_id(int id, int num_resources,
 			  struct oobmsm_plat_info *plat_info,
 			  struct tpmi_uncore_cluster_info *cluster_info)
 {
@@ -686,6 +700,7 @@ static int uncore_probe(struct auxiliary_device *auxdev, const struct auxiliary_
 			set_cdie_id(i, cluster_info, plat_info);
 
 			set_domain_id(i, num_resources, plat_info, cluster_info);
+			set_instance_id(i, cluster_info);
 
 			cluster_info->uncore_root = tpmi_uncore;
 
-- 
2.53.0

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

[Artem Bityutskiy]

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.

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

[Maciej Wieczor-Retman]

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

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

[srinivas pandruvada]

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

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

[Maciej Wieczor-Retman]

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

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

[srinivas pandruvada]

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

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