Re: RFC about how to obtain PCIE TPH steer-tag on ARM64 platform

[Wei Huang <wei.huang2@amd.com>]

On Tue, Jan 13, 2026 at 01:07:13PM -0600, Bjorn Helgaas wrote:
> On Mon, Jan 12, 2026 at 11:01:31AM +0800, fengchengwen wrote:
> > Hi all,
> > 
> > We want to enable PCIE TPH feature on ARM64 platform, but we encounter the
> > following problem:
> >
> > 1. The pcie_tph_get_cpu_st() function invokes the ACPI DSM method to
> >    obtain the steer-tag of the CPU. According to the definition of
> >    the DSM method [1], the cpu_uid should be "ACPI processor uid".
> 
> > 2. In the current implementation, the ACPI DSM method is invoked
> >    directly using the logical core number, which works on the x86
> >    platform but does not work on the ARM64 platform because the
> >    logical core ID is not the same as the ACPI processor ID when the
> >    PG exists.
> 
> PG?
> 
> > Because the ARM64 platform generates steer-tag based on the MPIDR
> > information (at least for the Kunpeng platform). Therefore, we have
> > two option:
> >
> > Option-1: convert logic core ID to ACPI process ID: use
> >           get_acpi_id_for_cpu() to get ACPI process ID in
> >           pcie_tph_get_cpu_st() before invoke dsm [2], and BIOS/ACPI
> >           use process ID to get corresponding MPIDR, and then
> >           generate steer-tag from MPIDR.

In my opinion, if this is achievable in your BIOS/ACPI, it is clean vs. Option-2 and preferred.

> >
> > Option-2: convert logic core ID to MPIDR: use cpu_logical_map() to
> >           get MPIDR in pcie_tph_get_cpu_st() before invoke dsm, and
> >           BIOS/ACPI use it to generate steer-tag directly.

This solution requires you to change the ECN and ratify it (as suggested by Bjorn below). The implementation can also be complicated.

> > 
> > Option-1 complies with _DSM ECN, but requires BIOS/ACPI to maintain
> > a mapping table from acpi_process_id to MPIDR.
> >
> > Option 2 does not comply with _DSM ECN (if extension is required).
> > But it is easy to implement and can be extended to the DT system
> > (ACPI is not supported) I think.

If you plan to revamp it, one (wild) idea is that ST retrieval can be extended to support:
  1. ACPI _DSM
  2. DT
  3. Vendor specific

After that, your MPIDR solution can be plugged-in under (3).

> 
> Sounds like this would be of interest to any OS, not just Linux.
> 
> Possibly a topic for the PCI-SIG firmware working group
> (https://members.pcisig.com/wg/Firmware/dashboard) or the ACPI spec
> working group (https://uefi.org/workinggroups)?
> 
> > [1] According to _DSM ECN, the input is defined as: "If the target
> >     is a processor, then this field represents the ACPI Processor
> >     UID of the processor as specified in the MADT. If the target is
> >     a processor container, then this field represents the ACPI
> >     Processor UID of the processor container as specified in the
> >     PPTT"
> >
> > [2] git diff about /drivers/pci/tph.c
> > @@ -289,6 +289,9 @@ int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type,
> > 
> >         rp_acpi_handle = ACPI_HANDLE(rp->bus->bridge);
> > 
> > +#ifdef CONFIG_ARM64
> > +       cpu_uid = get_acpi_id_for_cpu(cpu_uid);
> > +#endif
> >         if (tph_invoke_dsm(rp_acpi_handle, cpu_uid, &info) != AE_OK) {
> >                 *tag = 0;
> >                 return -EINVAL;
> > 
> >