[RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[fengchengwen]

Hi all,

I'm writing to propose adding a sysfs interface to expose and configure 
the PCIe TPH
Steering Tag for PCIe devices, which is retrieved inside the kernel.


Background: The TPH Steering Tag is tightly coupled with both a PCIe 
device (identified
by its BDF) and a CPU core. It can only be obtained in kernel mode. To 
allow user-space
applications to fetch and set this value securely and conveniently, we 
need a standard
kernel-to-user interface.


Proposed Solution: Add several sysfs attributes under each PCIe device's 
sysfs directory:
1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt 
or device specific)
2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write 
operations, e.g.:
    Read operation:
      echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
      cat /sys/bus/pci/devices/0000:01:00.0/tph_st
    Write operation:
      echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st


The design strictly follows PCI subsystem sysfs standards and has the 
following key properties:

1. Dynamic Visibility: The sysfs attributes will only be present for 
PCIe devices that
    support TPH Steering Tag. Devices without TPH capability will not 
show these nodes,
    avoiding unnecessary user confusion.

2. Permission Control: The attributes will use 0600 file permissions, 
ensuring only
    privileged root users can read or write them, which satisfies 
security requirements
    for hardware configuration interfaces.

3. Standard Implementation Location: The interface will be implemented in
    drivers/pci/pci-sysfs.c, the canonical location for all PCI device 
sysfs attributes,
    ensuring consistency and maintainability within the PCI subsystem.


Why sysfs instead of alternatives like VFIO-PCI ioctl:

- Universality: sysfs does not require binding the device to a special 
driver such as
   vfio-pci. It is available to any privileged user-space component, 
including system
   utilities, daemons, and monitoring tools.

- Simplicity: Both user-space usage (cat/echo) and kernel implementation are
   straightforward, reducing code complexity and long-term maintenance cost.

- Design Alignment: TPH Steering Tag is a generic PCIe device feature, 
not specific to
   user-space drivers like DPDK or VFIO. Exposing it via sysfs matches 
the kernel's
   standard pattern for hardware capabilities.


I look forward to your comments about this design before submitting the 
final patch.

Best regards,
Chengwen Feng

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[Leon Romanovsky]

On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:
> Hi all,
> 
> I'm writing to propose adding a sysfs interface to expose and configure the
> PCIe TPH
> Steering Tag for PCIe devices, which is retrieved inside the kernel.
> 
> 
> Background: The TPH Steering Tag is tightly coupled with both a PCIe device
> (identified
> by its BDF) and a CPU core. It can only be obtained in kernel mode. To allow
> user-space
> applications to fetch and set this value securely and conveniently, we need
> a standard
> kernel-to-user interface.
> 
> 
> Proposed Solution: Add several sysfs attributes under each PCIe device's
> sysfs directory:
> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
> device specific)
> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
> operations, e.g.:
>    Read operation:
>      echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>      cat /sys/bus/pci/devices/0000:01:00.0/tph_st
>    Write operation:
>      echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st
> 
> 
> The design strictly follows PCI subsystem sysfs standards and has the
> following key properties:
> 
> 1. Dynamic Visibility: The sysfs attributes will only be present for PCIe
> devices that
>    support TPH Steering Tag. Devices without TPH capability will not show
> these nodes,
>    avoiding unnecessary user confusion.
> 
> 2. Permission Control: The attributes will use 0600 file permissions,
> ensuring only
>    privileged root users can read or write them, which satisfies security
> requirements
>    for hardware configuration interfaces.
> 
> 3. Standard Implementation Location: The interface will be implemented in
>    drivers/pci/pci-sysfs.c, the canonical location for all PCI device sysfs
> attributes,
>    ensuring consistency and maintainability within the PCI subsystem.
> 
> 
> Why sysfs instead of alternatives like VFIO-PCI ioctl:
> 
> - Universality: sysfs does not require binding the device to a special
> driver such as
>   vfio-pci. It is available to any privileged user-space component,
> including system
>   utilities, daemons, and monitoring tools.
> 
> - Simplicity: Both user-space usage (cat/echo) and kernel implementation are
>   straightforward, reducing code complexity and long-term maintenance cost.
> 
> - Design Alignment: TPH Steering Tag is a generic PCIe device feature, not
> specific to
>   user-space drivers like DPDK or VFIO. Exposing it via sysfs matches the
> kernel's
>   standard pattern for hardware capabilities.
> 
> 
> I look forward to your comments about this design before submitting the
> final patch.

You need to explain more clearly why this write functionality is useful
and necessary outside the VFIO/RDMA context:
https://lore.kernel.org/all/20260324234615.3731237-1-zhipingz@meta.com/

AFAIK, for non-VFIO TPH callers, kernel has enough knowledge to set
right ST values.

There are several comments regarding the implementation, but those can wait
until the rationale behind the proposal is fully clarified.

Thanks

> 
> Best regards,
> Chengwen Feng
> 

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[fengchengwen]

On 4/13/2026 6:01 PM, Leon Romanovsky wrote:
> On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:
>> Hi all,
>>
>> I'm writing to propose adding a sysfs interface to expose and configure the
>> PCIe TPH
>> Steering Tag for PCIe devices, which is retrieved inside the kernel.
>>
>>
>> Background: The TPH Steering Tag is tightly coupled with both a PCIe device
>> (identified
>> by its BDF) and a CPU core. It can only be obtained in kernel mode. To allow
>> user-space
>> applications to fetch and set this value securely and conveniently, we need
>> a standard
>> kernel-to-user interface.
>>
>>
>> Proposed Solution: Add several sysfs attributes under each PCIe device's
>> sysfs directory:
>> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
>> device specific)
>> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
>> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
>> operations, e.g.:
>>    Read operation:
>>      echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>>      cat /sys/bus/pci/devices/0000:01:00.0/tph_st
>>    Write operation:
>>      echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>>
>>
>> The design strictly follows PCI subsystem sysfs standards and has the
>> following key properties:
>>
>> 1. Dynamic Visibility: The sysfs attributes will only be present for PCIe
>> devices that
>>    support TPH Steering Tag. Devices without TPH capability will not show
>> these nodes,
>>    avoiding unnecessary user confusion.
>>
>> 2. Permission Control: The attributes will use 0600 file permissions,
>> ensuring only
>>    privileged root users can read or write them, which satisfies security
>> requirements
>>    for hardware configuration interfaces.
>>
>> 3. Standard Implementation Location: The interface will be implemented in
>>    drivers/pci/pci-sysfs.c, the canonical location for all PCI device sysfs
>> attributes,
>>    ensuring consistency and maintainability within the PCI subsystem.
>>
>>
>> Why sysfs instead of alternatives like VFIO-PCI ioctl:
>>
>> - Universality: sysfs does not require binding the device to a special
>> driver such as
>>   vfio-pci. It is available to any privileged user-space component,
>> including system
>>   utilities, daemons, and monitoring tools.
>>
>> - Simplicity: Both user-space usage (cat/echo) and kernel implementation are
>>   straightforward, reducing code complexity and long-term maintenance cost.
>>
>> - Design Alignment: TPH Steering Tag is a generic PCIe device feature, not
>> specific to
>>   user-space drivers like DPDK or VFIO. Exposing it via sysfs matches the
>> kernel's
>>   standard pattern for hardware capabilities.
>>
>>
>> I look forward to your comments about this design before submitting the
>> final patch.
> 
> You need to explain more clearly why this write functionality is useful
> and necessary outside the VFIO/RDMA context:
> https://lore.kernel.org/all/20260324234615.3731237-1-zhipingz@meta.com/
> 
> AFAIK, for non-VFIO TPH callers, kernel has enough knowledge to set
> right ST values.
> 
> There are several comments regarding the implementation, but those can wait
> until the rationale behind the proposal is fully clarified.

Thanks for your review and comments.

Let me clarify the rationale behind this user-space sysfs interface:

1. VFIO is just one of the user-space device access frameworks.
   There are many other in-kernel frameworks that expose devices
   to user space, such as UIO, UACCE, etc., which may also require
   TPH Steering Tag support.

2. The kernel can automatically program Steering Tags only when
   the device provides a standard ST table in MSI-X or config space.
   However, many devices implement vendor-specific or platform-specific
   Steering Tag programming methods that cannot be fully handled
   by the generic kernel code.

3. For such devices, user-space applications or framework drivers
   need to retrieve and configure TPH Steering Tags directly.
   A unified sysfs interface allows all user-space frameworks
   (not just VFIO) to use a common, standard way to manage
   TPH Steering Tags, rather than implementing duplicated logic
   in each subsystem.

This interface provides a uniform method for any user-space
device access solution to work with TPH, which is why I believe
it is useful and necessary beyond the VFIO/RDMA case.

Thanks

> 
> Thanks
> 
>>
>> Best regards,
>> Chengwen Feng
>>

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[Leon Romanovsky]

On Mon, Apr 13, 2026 at 08:04:10PM +0800, fengchengwen wrote:
> On 4/13/2026 6:01 PM, Leon Romanovsky wrote:
> > On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:
> >> Hi all,
> >>
> >> I'm writing to propose adding a sysfs interface to expose and configure the
> >> PCIe TPH
> >> Steering Tag for PCIe devices, which is retrieved inside the kernel.
> >>
> >>
> >> Background: The TPH Steering Tag is tightly coupled with both a PCIe device
> >> (identified
> >> by its BDF) and a CPU core. It can only be obtained in kernel mode. To allow
> >> user-space
> >> applications to fetch and set this value securely and conveniently, we need
> >> a standard
> >> kernel-to-user interface.
> >>
> >>
> >> Proposed Solution: Add several sysfs attributes under each PCIe device's
> >> sysfs directory:
> >> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
> >> device specific)
> >> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
> >> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
> >> operations, e.g.:
> >>    Read operation:
> >>      echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>      cat /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>    Write operation:
> >>      echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>
> >>
> >> The design strictly follows PCI subsystem sysfs standards and has the
> >> following key properties:
> >>
> >> 1. Dynamic Visibility: The sysfs attributes will only be present for PCIe
> >> devices that
> >>    support TPH Steering Tag. Devices without TPH capability will not show
> >> these nodes,
> >>    avoiding unnecessary user confusion.
> >>
> >> 2. Permission Control: The attributes will use 0600 file permissions,
> >> ensuring only
> >>    privileged root users can read or write them, which satisfies security
> >> requirements
> >>    for hardware configuration interfaces.
> >>
> >> 3. Standard Implementation Location: The interface will be implemented in
> >>    drivers/pci/pci-sysfs.c, the canonical location for all PCI device sysfs
> >> attributes,
> >>    ensuring consistency and maintainability within the PCI subsystem.
> >>
> >>
> >> Why sysfs instead of alternatives like VFIO-PCI ioctl:
> >>
> >> - Universality: sysfs does not require binding the device to a special
> >> driver such as
> >>   vfio-pci. It is available to any privileged user-space component,
> >> including system
> >>   utilities, daemons, and monitoring tools.
> >>
> >> - Simplicity: Both user-space usage (cat/echo) and kernel implementation are
> >>   straightforward, reducing code complexity and long-term maintenance cost.
> >>
> >> - Design Alignment: TPH Steering Tag is a generic PCIe device feature, not
> >> specific to
> >>   user-space drivers like DPDK or VFIO. Exposing it via sysfs matches the
> >> kernel's
> >>   standard pattern for hardware capabilities.
> >>
> >>
> >> I look forward to your comments about this design before submitting the
> >> final patch.
> > 
> > You need to explain more clearly why this write functionality is useful
> > and necessary outside the VFIO/RDMA context:
> > https://lore.kernel.org/all/20260324234615.3731237-1-zhipingz@meta.com/
> > 
> > AFAIK, for non-VFIO TPH callers, kernel has enough knowledge to set
> > right ST values.
> > 
> > There are several comments regarding the implementation, but those can wait
> > until the rationale behind the proposal is fully clarified.
> 
> Thanks for your review and comments.
> 
> Let me clarify the rationale behind this user-space sysfs interface:
> 
> 1. VFIO is just one of the user-space device access frameworks.
>    There are many other in-kernel frameworks that expose devices
>    to user space, such as UIO, UACCE, etc., which may also require
>    TPH Steering Tag support.
> 
> 2. The kernel can automatically program Steering Tags only when
>    the device provides a standard ST table in MSI-X or config space.
>    However, many devices implement vendor-specific or platform-specific
>    Steering Tag programming methods that cannot be fully handled
>    by the generic kernel code.
> 
> 3. For such devices, user-space applications or framework drivers
>    need to retrieve and configure TPH Steering Tags directly.
>    A unified sysfs interface allows all user-space frameworks
>    (not just VFIO) to use a common, standard way to manage
>    TPH Steering Tags, rather than implementing duplicated logic
>    in each subsystem.
> 
> This interface provides a uniform method for any user-space
> device access solution to work with TPH, which is why I believe
> it is useful and necessary beyond the VFIO/RDMA case.

I understand the rationale for providing a read interface, for example for
debugging, but I do not see any justification for a write interface.

TPH is defined by the PCI specification. If a device intends to support it,
then it should conform to the specification.

Thanks


> 
> Thanks
> 
> > 
> > Thanks
> > 
> >>
> >> Best regards,
> >> Chengwen Feng
> >>
> 
> 

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[fengchengwen]

On 4/14/2026 3:19 AM, Leon Romanovsky wrote:
> On Mon, Apr 13, 2026 at 08:04:10PM +0800, fengchengwen wrote:
>> On 4/13/2026 6:01 PM, Leon Romanovsky wrote:
>>> On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:
>>>> Hi all,
>>>>
>>>> I'm writing to propose adding a sysfs interface to expose and configure the
>>>> PCIe TPH
>>>> Steering Tag for PCIe devices, which is retrieved inside the kernel.
>>>>
>>>>
>>>> Background: The TPH Steering Tag is tightly coupled with both a PCIe device
>>>> (identified
>>>> by its BDF) and a CPU core. It can only be obtained in kernel mode. To allow
>>>> user-space
>>>> applications to fetch and set this value securely and conveniently, we need
>>>> a standard
>>>> kernel-to-user interface.
>>>>
>>>>
>>>> Proposed Solution: Add several sysfs attributes under each PCIe device's
>>>> sysfs directory:
>>>> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
>>>> device specific)
>>>> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
>>>> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
>>>> operations, e.g.:
>>>>    Read operation:
>>>>      echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>>>>      cat /sys/bus/pci/devices/0000:01:00.0/tph_st
>>>>    Write operation:
>>>>      echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>>>>
>>>>
>>>> The design strictly follows PCI subsystem sysfs standards and has the
>>>> following key properties:
>>>>
>>>> 1. Dynamic Visibility: The sysfs attributes will only be present for PCIe
>>>> devices that
>>>>    support TPH Steering Tag. Devices without TPH capability will not show
>>>> these nodes,
>>>>    avoiding unnecessary user confusion.
>>>>
>>>> 2. Permission Control: The attributes will use 0600 file permissions,
>>>> ensuring only
>>>>    privileged root users can read or write them, which satisfies security
>>>> requirements
>>>>    for hardware configuration interfaces.
>>>>
>>>> 3. Standard Implementation Location: The interface will be implemented in
>>>>    drivers/pci/pci-sysfs.c, the canonical location for all PCI device sysfs
>>>> attributes,
>>>>    ensuring consistency and maintainability within the PCI subsystem.
>>>>
>>>>
>>>> Why sysfs instead of alternatives like VFIO-PCI ioctl:
>>>>
>>>> - Universality: sysfs does not require binding the device to a special
>>>> driver such as
>>>>   vfio-pci. It is available to any privileged user-space component,
>>>> including system
>>>>   utilities, daemons, and monitoring tools.
>>>>
>>>> - Simplicity: Both user-space usage (cat/echo) and kernel implementation are
>>>>   straightforward, reducing code complexity and long-term maintenance cost.
>>>>
>>>> - Design Alignment: TPH Steering Tag is a generic PCIe device feature, not
>>>> specific to
>>>>   user-space drivers like DPDK or VFIO. Exposing it via sysfs matches the
>>>> kernel's
>>>>   standard pattern for hardware capabilities.
>>>>
>>>>
>>>> I look forward to your comments about this design before submitting the
>>>> final patch.
>>>
>>> You need to explain more clearly why this write functionality is useful
>>> and necessary outside the VFIO/RDMA context:
>>> https://lore.kernel.org/all/20260324234615.3731237-1-zhipingz@meta.com/
>>>
>>> AFAIK, for non-VFIO TPH callers, kernel has enough knowledge to set
>>> right ST values.
>>>
>>> There are several comments regarding the implementation, but those can wait
>>> until the rationale behind the proposal is fully clarified.
>>
>> Thanks for your review and comments.
>>
>> Let me clarify the rationale behind this user-space sysfs interface:
>>
>> 1. VFIO is just one of the user-space device access frameworks.
>>    There are many other in-kernel frameworks that expose devices
>>    to user space, such as UIO, UACCE, etc., which may also require
>>    TPH Steering Tag support.
>>
>> 2. The kernel can automatically program Steering Tags only when
>>    the device provides a standard ST table in MSI-X or config space.
>>    However, many devices implement vendor-specific or platform-specific
>>    Steering Tag programming methods that cannot be fully handled
>>    by the generic kernel code.
>>
>> 3. For such devices, user-space applications or framework drivers
>>    need to retrieve and configure TPH Steering Tags directly.
>>    A unified sysfs interface allows all user-space frameworks
>>    (not just VFIO) to use a common, standard way to manage
>>    TPH Steering Tags, rather than implementing duplicated logic
>>    in each subsystem.
>>
>> This interface provides a uniform method for any user-space
>> device access solution to work with TPH, which is why I believe
>> it is useful and necessary beyond the VFIO/RDMA case.
> 
> I understand the rationale for providing a read interface, for example for
> debugging, but I do not see any justification for a write interface.

Thank you for the comment!

As I explained, read interface is not only for debugging. It was used to
such device who don't declare ST location in MSI-X or config-space, the following
is Intel X710 NIC device's lspci output (only TPH part):

	Capabilities: [1a0 v1] Transaction Processing Hints
		Device specific mode supported
		No steering table available

So we could not config the ST for device on kernel because it's vendor specific.
But we could configure ST by it's vendor user-space driver, in this case, we
should get ST from kernel to user-space.


As for write interface, which was used to devices whose ST location is known, I
think we could simple it, and only passing <index, cpu>, then kernel query cpu's ST
and set to corresponding index.

> 
> TPH is defined by the PCI specification. If a device intends to support it,
> then it should conform to the specification.

According to the PCI specification 6.17.3 ST Modes of Operation:

  Device Specific Mode: It is recommended for the Function to use a Steering Tag value from an ST Table entry, but it is not required.

  In the Device Specific Mode of operation, the assignment of the Steering Tags to Requests is device specific. The number
  of Steering Tags used by the Function is permitted to be different than the number of interrupt vectors allocated for the
  Function, irrespective of the ST Table location, and Steering Tag values used in Requests are not required to come from
  the architected ST Table.

Thanks

> 
> Thanks
> 
> 
>>
>> Thanks
>>
>>>
>>> Thanks
>>>
>>>>
>>>> Best regards,
>>>> Chengwen Feng
>>>>
>>
>>

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[Leon Romanovsky]

On Tue, Apr 14, 2026 at 09:07:23AM +0800, fengchengwen wrote:
> On 4/14/2026 3:19 AM, Leon Romanovsky wrote:
> > On Mon, Apr 13, 2026 at 08:04:10PM +0800, fengchengwen wrote:
> >> On 4/13/2026 6:01 PM, Leon Romanovsky wrote:
> >>> On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:
> >>>> Hi all,
> >>>>
> >>>> I'm writing to propose adding a sysfs interface to expose and configure the
> >>>> PCIe TPH
> >>>> Steering Tag for PCIe devices, which is retrieved inside the kernel.
> >>>>
> >>>>
> >>>> Background: The TPH Steering Tag is tightly coupled with both a PCIe device
> >>>> (identified
> >>>> by its BDF) and a CPU core. It can only be obtained in kernel mode. To allow
> >>>> user-space
> >>>> applications to fetch and set this value securely and conveniently, we need
> >>>> a standard
> >>>> kernel-to-user interface.
> >>>>
> >>>>
> >>>> Proposed Solution: Add several sysfs attributes under each PCIe device's
> >>>> sysfs directory:
> >>>> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
> >>>> device specific)
> >>>> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
> >>>> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
> >>>> operations, e.g.:
> >>>>    Read operation:
> >>>>      echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>>>      cat /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>>>    Write operation:
> >>>>      echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>>>
> >>>>
> >>>> The design strictly follows PCI subsystem sysfs standards and has the
> >>>> following key properties:
> >>>>
> >>>> 1. Dynamic Visibility: The sysfs attributes will only be present for PCIe
> >>>> devices that
> >>>>    support TPH Steering Tag. Devices without TPH capability will not show
> >>>> these nodes,
> >>>>    avoiding unnecessary user confusion.
> >>>>
> >>>> 2. Permission Control: The attributes will use 0600 file permissions,
> >>>> ensuring only
> >>>>    privileged root users can read or write them, which satisfies security
> >>>> requirements
> >>>>    for hardware configuration interfaces.
> >>>>
> >>>> 3. Standard Implementation Location: The interface will be implemented in
> >>>>    drivers/pci/pci-sysfs.c, the canonical location for all PCI device sysfs
> >>>> attributes,
> >>>>    ensuring consistency and maintainability within the PCI subsystem.
> >>>>
> >>>>
> >>>> Why sysfs instead of alternatives like VFIO-PCI ioctl:
> >>>>
> >>>> - Universality: sysfs does not require binding the device to a special
> >>>> driver such as
> >>>>   vfio-pci. It is available to any privileged user-space component,
> >>>> including system
> >>>>   utilities, daemons, and monitoring tools.
> >>>>
> >>>> - Simplicity: Both user-space usage (cat/echo) and kernel implementation are
> >>>>   straightforward, reducing code complexity and long-term maintenance cost.
> >>>>
> >>>> - Design Alignment: TPH Steering Tag is a generic PCIe device feature, not
> >>>> specific to
> >>>>   user-space drivers like DPDK or VFIO. Exposing it via sysfs matches the
> >>>> kernel's
> >>>>   standard pattern for hardware capabilities.
> >>>>
> >>>>
> >>>> I look forward to your comments about this design before submitting the
> >>>> final patch.
> >>>
> >>> You need to explain more clearly why this write functionality is useful
> >>> and necessary outside the VFIO/RDMA context:
> >>> https://lore.kernel.org/all/20260324234615.3731237-1-zhipingz@meta.com/
> >>>
> >>> AFAIK, for non-VFIO TPH callers, kernel has enough knowledge to set
> >>> right ST values.
> >>>
> >>> There are several comments regarding the implementation, but those can wait
> >>> until the rationale behind the proposal is fully clarified.
> >>
> >> Thanks for your review and comments.
> >>
> >> Let me clarify the rationale behind this user-space sysfs interface:
> >>
> >> 1. VFIO is just one of the user-space device access frameworks.
> >>    There are many other in-kernel frameworks that expose devices
> >>    to user space, such as UIO, UACCE, etc., which may also require
> >>    TPH Steering Tag support.
> >>
> >> 2. The kernel can automatically program Steering Tags only when
> >>    the device provides a standard ST table in MSI-X or config space.
> >>    However, many devices implement vendor-specific or platform-specific
> >>    Steering Tag programming methods that cannot be fully handled
> >>    by the generic kernel code.
> >>
> >> 3. For such devices, user-space applications or framework drivers
> >>    need to retrieve and configure TPH Steering Tags directly.
> >>    A unified sysfs interface allows all user-space frameworks
> >>    (not just VFIO) to use a common, standard way to manage
> >>    TPH Steering Tags, rather than implementing duplicated logic
> >>    in each subsystem.
> >>
> >> This interface provides a uniform method for any user-space
> >> device access solution to work with TPH, which is why I believe
> >> it is useful and necessary beyond the VFIO/RDMA case.
> > 
> > I understand the rationale for providing a read interface, for example for
> > debugging, but I do not see any justification for a write interface.
> 
> Thank you for the comment!
> 
> As I explained, read interface is not only for debugging. It was used to
> such device who don't declare ST location in MSI-X or config-space, the following
> is Intel X710 NIC device's lspci output (only TPH part):
> 
> 	Capabilities: [1a0 v1] Transaction Processing Hints
> 		Device specific mode supported
> 		No steering table available
> 
> So we could not config the ST for device on kernel because it's vendor specific.
> But we could configure ST by it's vendor user-space driver, in this case, we
> should get ST from kernel to user-space.

Vendor-specific, in the context of the PCI specification, does not mean the
kernel cannot configure it. It simply means that the ST values are not
stored in the ST table.

Thanks

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[fengchengwen]

On 4/14/2026 4:57 PM, Leon Romanovsky wrote:
> On Tue, Apr 14, 2026 at 09:07:23AM +0800, fengchengwen wrote:
>> On 4/14/2026 3:19 AM, Leon Romanovsky wrote:
>>> On Mon, Apr 13, 2026 at 08:04:10PM +0800, fengchengwen wrote:
>>>> On 4/13/2026 6:01 PM, Leon Romanovsky wrote:
>>>>> On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I'm writing to propose adding a sysfs interface to expose and configure the
>>>>>> PCIe TPH
>>>>>> Steering Tag for PCIe devices, which is retrieved inside the kernel.
>>>>>>
>>>>>>
>>>>>> Background: The TPH Steering Tag is tightly coupled with both a PCIe device
>>>>>> (identified
>>>>>> by its BDF) and a CPU core. It can only be obtained in kernel mode. To allow
>>>>>> user-space
>>>>>> applications to fetch and set this value securely and conveniently, we need
>>>>>> a standard
>>>>>> kernel-to-user interface.
>>>>>>
>>>>>>
>>>>>> Proposed Solution: Add several sysfs attributes under each PCIe device's
>>>>>> sysfs directory:
>>>>>> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
>>>>>> device specific)
>>>>>> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
>>>>>> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
>>>>>> operations, e.g.:
>>>>>>    Read operation:
>>>>>>      echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>>>>>>      cat /sys/bus/pci/devices/0000:01:00.0/tph_st
>>>>>>    Write operation:
>>>>>>      echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>>>>>>
>>>>>>
>>>>>> The design strictly follows PCI subsystem sysfs standards and has the
>>>>>> following key properties:
>>>>>>
>>>>>> 1. Dynamic Visibility: The sysfs attributes will only be present for PCIe
>>>>>> devices that
>>>>>>    support TPH Steering Tag. Devices without TPH capability will not show
>>>>>> these nodes,
>>>>>>    avoiding unnecessary user confusion.
>>>>>>
>>>>>> 2. Permission Control: The attributes will use 0600 file permissions,
>>>>>> ensuring only
>>>>>>    privileged root users can read or write them, which satisfies security
>>>>>> requirements
>>>>>>    for hardware configuration interfaces.
>>>>>>
>>>>>> 3. Standard Implementation Location: The interface will be implemented in
>>>>>>    drivers/pci/pci-sysfs.c, the canonical location for all PCI device sysfs
>>>>>> attributes,
>>>>>>    ensuring consistency and maintainability within the PCI subsystem.
>>>>>>
>>>>>>
>>>>>> Why sysfs instead of alternatives like VFIO-PCI ioctl:
>>>>>>
>>>>>> - Universality: sysfs does not require binding the device to a special
>>>>>> driver such as
>>>>>>   vfio-pci. It is available to any privileged user-space component,
>>>>>> including system
>>>>>>   utilities, daemons, and monitoring tools.
>>>>>>
>>>>>> - Simplicity: Both user-space usage (cat/echo) and kernel implementation are
>>>>>>   straightforward, reducing code complexity and long-term maintenance cost.
>>>>>>
>>>>>> - Design Alignment: TPH Steering Tag is a generic PCIe device feature, not
>>>>>> specific to
>>>>>>   user-space drivers like DPDK or VFIO. Exposing it via sysfs matches the
>>>>>> kernel's
>>>>>>   standard pattern for hardware capabilities.
>>>>>>
>>>>>>
>>>>>> I look forward to your comments about this design before submitting the
>>>>>> final patch.
>>>>>
>>>>> You need to explain more clearly why this write functionality is useful
>>>>> and necessary outside the VFIO/RDMA context:
>>>>> https://lore.kernel.org/all/20260324234615.3731237-1-zhipingz@meta.com/
>>>>>
>>>>> AFAIK, for non-VFIO TPH callers, kernel has enough knowledge to set
>>>>> right ST values.
>>>>>
>>>>> There are several comments regarding the implementation, but those can wait
>>>>> until the rationale behind the proposal is fully clarified.
>>>>
>>>> Thanks for your review and comments.
>>>>
>>>> Let me clarify the rationale behind this user-space sysfs interface:
>>>>
>>>> 1. VFIO is just one of the user-space device access frameworks.
>>>>    There are many other in-kernel frameworks that expose devices
>>>>    to user space, such as UIO, UACCE, etc., which may also require
>>>>    TPH Steering Tag support.
>>>>
>>>> 2. The kernel can automatically program Steering Tags only when
>>>>    the device provides a standard ST table in MSI-X or config space.
>>>>    However, many devices implement vendor-specific or platform-specific
>>>>    Steering Tag programming methods that cannot be fully handled
>>>>    by the generic kernel code.
>>>>
>>>> 3. For such devices, user-space applications or framework drivers
>>>>    need to retrieve and configure TPH Steering Tags directly.
>>>>    A unified sysfs interface allows all user-space frameworks
>>>>    (not just VFIO) to use a common, standard way to manage
>>>>    TPH Steering Tags, rather than implementing duplicated logic
>>>>    in each subsystem.
>>>>
>>>> This interface provides a uniform method for any user-space
>>>> device access solution to work with TPH, which is why I believe
>>>> it is useful and necessary beyond the VFIO/RDMA case.
>>>
>>> I understand the rationale for providing a read interface, for example for
>>> debugging, but I do not see any justification for a write interface.
>>
>> Thank you for the comment!
>>
>> As I explained, read interface is not only for debugging. It was used to
>> such device who don't declare ST location in MSI-X or config-space, the following
>> is Intel X710 NIC device's lspci output (only TPH part):
>>
>> 	Capabilities: [1a0 v1] Transaction Processing Hints
>> 		Device specific mode supported
>> 		No steering table available
>>
>> So we could not config the ST for device on kernel because it's vendor specific.
>> But we could configure ST by it's vendor user-space driver, in this case, we
>> should get ST from kernel to user-space.
> 
> Vendor-specific, in the context of the PCI specification, does not mean the
> kernel cannot configure it. It simply means that the ST values are not
> stored in the ST table.

Thank you for the clarification!

I agree with your interpretation of "vendor-specific" in PCI spec terms—it
does not prevent the kernel from handling TPH in principle. However, the
real problem is that the kernel has no standardized way to know where or
how to program those vendor-specific ST values.

When a device  reports "No steering table available" and operates in
device-specific mode, the method used to set ST values is entirely
device-specific and not covered by the PCI specification. If the device
is taken over to user-space by UIO framework (e.g. VFIO or IGB_UIO), the
generic kernel cannot infer the proper programming sequence or registers
for each vendor-specific implementation.

In these cases, the configuration must be done by the vendor’s
user-space driver, which is aware of the device’s private programming
model. But such a user-space driver still needs to obtain valid,
platform-provided ST values (from ACPI _DSM), which it cannot do
without a kernel interface.

This is why a read-only interface to retrieve ST values is still
needed: the kernel holds the valid platform tags, while the user-space
driver handles the device-specific programming.

Thanks

> 
> Thanks

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[Leon Romanovsky]

On Tue, Apr 14, 2026 at 05:30:09PM +0800, fengchengwen wrote:
> On 4/14/2026 4:57 PM, Leon Romanovsky wrote:
> > On Tue, Apr 14, 2026 at 09:07:23AM +0800, fengchengwen wrote:
> >> On 4/14/2026 3:19 AM, Leon Romanovsky wrote:
> >>> On Mon, Apr 13, 2026 at 08:04:10PM +0800, fengchengwen wrote:
> >>>> On 4/13/2026 6:01 PM, Leon Romanovsky wrote:
> >>>>> On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I'm writing to propose adding a sysfs interface to expose and configure the
> >>>>>> PCIe TPH
> >>>>>> Steering Tag for PCIe devices, which is retrieved inside the kernel.
> >>>>>>
> >>>>>>
> >>>>>> Background: The TPH Steering Tag is tightly coupled with both a PCIe device
> >>>>>> (identified
> >>>>>> by its BDF) and a CPU core. It can only be obtained in kernel mode. To allow
> >>>>>> user-space
> >>>>>> applications to fetch and set this value securely and conveniently, we need
> >>>>>> a standard
> >>>>>> kernel-to-user interface.
> >>>>>>
> >>>>>>
> >>>>>> Proposed Solution: Add several sysfs attributes under each PCIe device's
> >>>>>> sysfs directory:
> >>>>>> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
> >>>>>> device specific)
> >>>>>> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
> >>>>>> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
> >>>>>> operations, e.g.:
> >>>>>>    Read operation:
> >>>>>>      echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>>>>>      cat /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>>>>>    Write operation:
> >>>>>>      echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>>>>>
> >>>>>>
> >>>>>> The design strictly follows PCI subsystem sysfs standards and has the
> >>>>>> following key properties:
> >>>>>>
> >>>>>> 1. Dynamic Visibility: The sysfs attributes will only be present for PCIe
> >>>>>> devices that
> >>>>>>    support TPH Steering Tag. Devices without TPH capability will not show
> >>>>>> these nodes,
> >>>>>>    avoiding unnecessary user confusion.
> >>>>>>
> >>>>>> 2. Permission Control: The attributes will use 0600 file permissions,
> >>>>>> ensuring only
> >>>>>>    privileged root users can read or write them, which satisfies security
> >>>>>> requirements
> >>>>>>    for hardware configuration interfaces.
> >>>>>>
> >>>>>> 3. Standard Implementation Location: The interface will be implemented in
> >>>>>>    drivers/pci/pci-sysfs.c, the canonical location for all PCI device sysfs
> >>>>>> attributes,
> >>>>>>    ensuring consistency and maintainability within the PCI subsystem.
> >>>>>>
> >>>>>>
> >>>>>> Why sysfs instead of alternatives like VFIO-PCI ioctl:
> >>>>>>
> >>>>>> - Universality: sysfs does not require binding the device to a special
> >>>>>> driver such as
> >>>>>>   vfio-pci. It is available to any privileged user-space component,
> >>>>>> including system
> >>>>>>   utilities, daemons, and monitoring tools.
> >>>>>>
> >>>>>> - Simplicity: Both user-space usage (cat/echo) and kernel implementation are
> >>>>>>   straightforward, reducing code complexity and long-term maintenance cost.
> >>>>>>
> >>>>>> - Design Alignment: TPH Steering Tag is a generic PCIe device feature, not
> >>>>>> specific to
> >>>>>>   user-space drivers like DPDK or VFIO. Exposing it via sysfs matches the
> >>>>>> kernel's
> >>>>>>   standard pattern for hardware capabilities.
> >>>>>>
> >>>>>>
> >>>>>> I look forward to your comments about this design before submitting the
> >>>>>> final patch.
> >>>>>
> >>>>> You need to explain more clearly why this write functionality is useful
> >>>>> and necessary outside the VFIO/RDMA context:
> >>>>> https://lore.kernel.org/all/20260324234615.3731237-1-zhipingz@meta.com/
> >>>>>
> >>>>> AFAIK, for non-VFIO TPH callers, kernel has enough knowledge to set
> >>>>> right ST values.
> >>>>>
> >>>>> There are several comments regarding the implementation, but those can wait
> >>>>> until the rationale behind the proposal is fully clarified.
> >>>>
> >>>> Thanks for your review and comments.
> >>>>
> >>>> Let me clarify the rationale behind this user-space sysfs interface:
> >>>>
> >>>> 1. VFIO is just one of the user-space device access frameworks.
> >>>>    There are many other in-kernel frameworks that expose devices
> >>>>    to user space, such as UIO, UACCE, etc., which may also require
> >>>>    TPH Steering Tag support.
> >>>>
> >>>> 2. The kernel can automatically program Steering Tags only when
> >>>>    the device provides a standard ST table in MSI-X or config space.
> >>>>    However, many devices implement vendor-specific or platform-specific
> >>>>    Steering Tag programming methods that cannot be fully handled
> >>>>    by the generic kernel code.
> >>>>
> >>>> 3. For such devices, user-space applications or framework drivers
> >>>>    need to retrieve and configure TPH Steering Tags directly.
> >>>>    A unified sysfs interface allows all user-space frameworks
> >>>>    (not just VFIO) to use a common, standard way to manage
> >>>>    TPH Steering Tags, rather than implementing duplicated logic
> >>>>    in each subsystem.
> >>>>
> >>>> This interface provides a uniform method for any user-space
> >>>> device access solution to work with TPH, which is why I believe
> >>>> it is useful and necessary beyond the VFIO/RDMA case.
> >>>
> >>> I understand the rationale for providing a read interface, for example for
> >>> debugging, but I do not see any justification for a write interface.
> >>
> >> Thank you for the comment!
> >>
> >> As I explained, read interface is not only for debugging. It was used to
> >> such device who don't declare ST location in MSI-X or config-space, the following
> >> is Intel X710 NIC device's lspci output (only TPH part):
> >>
> >> 	Capabilities: [1a0 v1] Transaction Processing Hints
> >> 		Device specific mode supported
> >> 		No steering table available
> >>
> >> So we could not config the ST for device on kernel because it's vendor specific.
> >> But we could configure ST by it's vendor user-space driver, in this case, we
> >> should get ST from kernel to user-space.
> > 
> > Vendor-specific, in the context of the PCI specification, does not mean the
> > kernel cannot configure it. It simply means that the ST values are not
> > stored in the ST table.
> 
> Thank you for the clarification!
> 
> I agree with your interpretation of "vendor-specific" in PCI spec terms—it
> does not prevent the kernel from handling TPH in principle. However, the
> real problem is that the kernel has no standardized way to know where or
> how to program those vendor-specific ST values.

No one here is opposed to you implementing the appropriate callbacks or
extending the existing in-kernel API to support a device‑specific mode.

> 
> When a device  reports "No steering table available" and operates in
> device-specific mode, the method used to set ST values is entirely
> device-specific and not covered by the PCI specification. If the device
> is taken over to user-space by UIO framework (e.g. VFIO or IGB_UIO), the
> generic kernel cannot infer the proper programming sequence or registers
> for each vendor-specific implementation.
> 
> In these cases, the configuration must be done by the vendor’s
> user-space driver, which is aware of the device’s private programming
> model. But such a user-space driver still needs to obtain valid,
> platform-provided ST values (from ACPI _DSM), which it cannot do
> without a kernel interface.

The objection applies to this point. The PCI device exists in kernel space,
and the kernel is responsible for managing its internal state.

> 
> This is why a read-only interface to retrieve ST values is still
> needed: the kernel holds the valid platform tags, while the user-space
> driver handles the device-specific programming.
> 
> Thanks
> 
> > 
> > Thanks
> 

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[Jason Gunthorpe]

On Tue, Apr 14, 2026 at 10:46:00PM +0800, fengchengwen wrote:
>    We have a real platform requirement:
> 
>      * 1. Devices in TPH Device-Specific Mode with no standard ST table
>      * 2. Steering Tags must be obtained from ACPI _DSM (kernel-only)
>      * 3. Devices are fully managed by userspace drivers (VFIO/UIO)
>      * 4. Userspace must program STs into vendor-specific registers

No, this is nonsenscial too.

If you want to control the steering tags for MMIO BAR memory exposed
by VFIO then the DMABUF mechanism Keith & co has been working on is
the correct approach.

If the VFIO user needs to control steering tags for the device it is
directly controling then it must do that through VFIO ioctls.

Nobody messes around with other devices under the covers of the
operating kernel driver. Stop proposing that.

Jason

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[fengchengwen]

On 4/14/2026 11:11 PM, Jason Gunthorpe wrote:
> On Tue, Apr 14, 2026 at 10:46:00PM +0800, fengchengwen wrote:
>>    We have a real platform requirement:
>>
>>      * 1. Devices in TPH Device-Specific Mode with no standard ST table
>>      * 2. Steering Tags must be obtained from ACPI _DSM (kernel-only)
>>      * 3. Devices are fully managed by userspace drivers (VFIO/UIO)
>>      * 4. Userspace must program STs into vendor-specific registers
> 
> No, this is nonsenscial too.
> 
> If you want to control the steering tags for MMIO BAR memory exposed
> by VFIO then the DMABUF mechanism Keith & co has been working on is
> the correct approach.
> 
> If the VFIO user needs to control steering tags for the device it is
> directly controling then it must do that through VFIO ioctls.
> 
> Nobody messes around with other devices under the covers of the
> operating kernel driver. Stop proposing that.

Understood.

For VFIO-passed devices that are fully under userspace control,
we will implement the TPH Steering Tag query interface
exclusively through VFIO ioctls, not sysfs.

This will allow userspace to query per-CPU Steering Tags
from platform firmware (ACPI _DSM) for the VFIO device,
which is fully under its control.

Thanks

> 
> Jason

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[Jason Gunthorpe]

On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:

> Background: The TPH Steering Tag is tightly coupled with both a PCIe
> device (identified by its BDF) and a CPU core. It can only be
> obtained in kernel mode. To allow user-space applications to fetch
> and set this value securely and conveniently, we need a standard
> kernel-to-user interface.

There is no reason for userspace to have this value outside VFIO.

> Proposed Solution: Add several sysfs attributes under each PCIe device's
> sysfs directory:
> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
> device specific)
> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
> operations, e.g.:
>    Read operation:
>      echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>      cat /sys/bus/pci/devices/0000:01:00.0/tph_st
>    Write operation:
>      echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st

NAK

This is all low level details controled exclusively by the kernel
driver. Allowing userspace to mess it up will break drivers.

There is no justification to give userspace this kind of write access.

Jason

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[fengchengwen]

On 4/13/2026 9:35 PM, Jason Gunthorpe wrote:
> On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:
> 
>> Background: The TPH Steering Tag is tightly coupled with both a PCIe
>> device (identified by its BDF) and a CPU core. It can only be
>> obtained in kernel mode. To allow user-space applications to fetch
>> and set this value securely and conveniently, we need a standard
>> kernel-to-user interface.
> 
> There is no reason for userspace to have this value outside VFIO.
> 
>> Proposed Solution: Add several sysfs attributes under each PCIe device's
>> sysfs directory:
>> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
>> device specific)
>> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
>> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
>> operations, e.g.:
>>    Read operation:
>>      echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>>      cat /sys/bus/pci/devices/0000:01:00.0/tph_st
>>    Write operation:
>>      echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st
> 
> NAK
> 
> This is all low level details controled exclusively by the kernel
> driver. Allowing userspace to mess it up will break drivers.
> 
> There is no justification to give userspace this kind of write access.

Thank you very much for your valuable feedback and candid insights.
I appreciate you raising the important concern about risks of
exposing low-level hardware controls to userspace. To help clarify
the proposal and facilitate constructive discussion, I'd like to
split the topic into two distinct points:

1. Functional Requirement: Userspace Need for ST Management
   Userspace requires access to Steering Tags in two valid scenarios:
   - For devices in TPH Device-Specific Mode with no standard ST table,
     userspace needs to read valid ST values from the kernel, which are
     acquired via ACPI _DSM (a kernel-only operation).
   - For devices using the spec-defined ST location, userspace may
     provide (index, cpu) associations for the kernel to program safely.

2. Implementation: Kernel-Userspace Communication Interface
   The second topic is how to transport ST information securely:
   - Proposed sysfs: universal, works for all frameworks (VFIO, UIO, UACCE)
   - VFIO-private ioctl: limited to VFIO-managed devices

My goal is to provide a secure, generic, non-disruptive interface
that addresses valid userspace needs without impacting kernel
managed devices or introducing stability risks. I welcome your
thoughts on both the requirements and the interface options.

Thank you again for your time and guidance.

> 
> Jason
> 

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[Jason Gunthorpe]

On Tue, Apr 14, 2026 at 09:33:01AM +0800, fengchengwen wrote:

>    - For devices using the spec-defined ST location, userspace may
>      provide (index, cpu) associations for the kernel to program safely.

No, it is not safe.

Jason

Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration

[Jason Gunthorpe]

On Tue, Apr 14, 2026 at 10:40:39PM +0800, fengchengwen wrote:
>    On 2026/4/14 19:57, Jason Gunthorpe wrote:
> 
> On Tue, Apr 14, 2026 at 09:33:01AM +0800, fengchengwen wrote:
> 
> 
>    - For devices using the spec-defined ST location, userspace may
>      provide (index, cpu) associations for the kernel to program safely.
> 
> No, it is not safe.
> 
>    Thank you for your clarification and for emphasizing the security
>    concern.
> 
>    To address this properly and ensure safety, I plan to add a dedicated
>    kernel boot parameter, similar to iommu.passthrough, to control this
>    interface. The behavior would be:

No, that's nonsense. The driver owns the tph table, nothing else is
allowed to manipulate it.

You haven't even sensibly explained why you'd want this.

Jason