From: fengchengwen <fengchengwen@huawei.com>
To: Alex Williamson <alex@shazbot.org>
Cc: <helgaas@kernel.org>, <wathsala.vithanage@arm.com>,
<wei.huang2@amd.com>, <zhipingz@meta.com>,
<wangzhou1@hisilicon.com>, <wangyushan12@huawei.com>,
<liuyonglong@huawei.com>, <kvm@vger.kernel.org>,
<linux-pci@vger.kernel.org>, Jason Gunthorpe <jgg@ziepe.ca>
Subject: Re: [PATCH v17 08/12] PCI/TPH: Add sysfs binary file to export CPU to steering-tag mapping
Date: Tue, 23 Jun 2026 17:56:51 +0800 [thread overview]
Message-ID: <9105ceef-5e27-4e3c-8903-d46aef52a2bd@huawei.com> (raw)
In-Reply-To: <20260616105754.784be22d@shazbot.org>
Hi Alex,
On 6/17/2026 12:57 AM, Alex Williamson wrote:
> On Tue, 16 Jun 2026 11:42:24 -0300
> Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
>> On Tue, Jun 16, 2026 at 06:46:17PM +0800, Chengwen Feng wrote:
>>> Add per-device sysfs binary attribute tph_cpu_st to expose ACPI DSM CPU
>>> to steering-tag data to userspace, resolving the concern that VFIO should
>>> not host CPU-to-ST translation interfaces.
>>>
>>> Follow PCI standard binattr framework: dynamic visible group, fixed-size
>>> 8-byte packed uapi entry, aligned offset read, root-only 0400 permission.
>>> Refactor duplicate ACPI DSM logic into shared tph_get_cpu_st_info helper.
>>>
>>> ABI: /sys/bus/pci/devices/<BDF>/tph_cpu_st
>>
>> I'm sorry, I really dislike this :(
>>
>> Structured binary sysfs attributes are pretty much against the rules,
>> I think using sysfs at all for this interface is a bad idea.
>>
>> IMHO the VFIO version was much better.
>
> There are some deficiencies in this implementation:
>
> - The ABI needs to be documented in
> Documentation/ABI/testing/sysfs-bus-pci
>
> - The attribute is at the wrong place, all endpoints would just
> replicate the root port values. Place it at the root port.
>
> - Corollary, is_visible should key on whether we have CPU to ST
> mappings (_DSM) and the root port is a TPH completer (DevCap2), not
> the TPH capabilities of an endpoint - a userspace driver can already
> discover the endpoint TPH requester support.
>
> - The 8-byte aligned read requirement should be removed, perform a
> sub-8-byte read from the slot offset. !cpu_possible() should be
> filled with zeros. This allows userspace to dump the entire bin
> file or read only a set of fields.
>
> - Probably cleaner to zero-initialize the buffer rather than memset()
> and (redundant) reserved = 0.
I’ve sent v18-resend of the PCI TPH sysfs patchset with all prior review
comments fully addressed.
I remain open to both discussed implementation options. This v18-resend
implements the sysfs binary blob approach on Root Ports as you previously
suggested.
Please kindly review v18-resend and share your thoughts.
Thanks
>
> IMO, this implementation in sysfs more so proves that vfio is the wrong
> place for the interface. vfio has a use case to consume STs, but it
> doesn't produce them or own any of the mechanism by which they're
> generated. This proposal, with the above improvements, provides
> effectively an ioctl-like interface when using a properly offset and
> sized pread().
>
> The weak point is whether this bin attribute, exposing an array of
> structures, fits within the socially acceptable norms of sysfs. There
> is some precedent for this, for example cc_settings_bin in infiniband,
> but these might also be considered legacy. So I don't know if this
> sort of usage is a grey area that fits social norms or if it's promoting
> legacy use cases that we don't want to repeat. Thanks,
>
> Alex
next prev parent reply other threads:[~2026-06-23 9:56 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 10:46 [PATCH v17 00/12] vfio/pci: Add PCIe TPH support Chengwen Feng
2026-06-16 10:46 ` [PATCH v17 01/12] PCI/TPH: Fix pcie_tph_get_st_table_loc() field extraction Chengwen Feng
2026-06-16 11:00 ` sashiko-bot
2026-06-16 10:46 ` [PATCH v17 02/12] PCI/TPH: Fix tph_enabled concurrent update race by bitfield packing Chengwen Feng
2026-06-16 10:55 ` sashiko-bot
2026-06-16 10:46 ` [PATCH v17 03/12] PCI/TPH: Cache TPH requester capability at probe time Chengwen Feng
2026-06-16 10:55 ` sashiko-bot
2026-06-16 10:46 ` [PATCH v17 04/12] PCI/TPH: Refactor pcie_enable_tph & add explicit requester variant Chengwen Feng
2026-06-16 10:53 ` sashiko-bot
2026-06-16 10:46 ` [PATCH v17 05/12] PCI/TPH: Refactor pcie_tph_get_cpu_st & add explicit variant Chengwen Feng
2026-06-16 10:53 ` sashiko-bot
2026-06-16 10:46 ` [PATCH v17 06/12] PCI/TPH: Expose the enabled TPH requester type Chengwen Feng
2026-06-16 10:51 ` sashiko-bot
2026-06-16 10:46 ` [PATCH v17 07/12] PCI/TPH: Add pcie_tph_supported() helper to check TPH capability attributes Chengwen Feng
2026-06-16 10:52 ` sashiko-bot
2026-06-16 10:46 ` [PATCH v17 08/12] PCI/TPH: Add sysfs binary file to export CPU to steering-tag mapping Chengwen Feng
2026-06-16 11:00 ` sashiko-bot
2026-06-16 14:42 ` Jason Gunthorpe
2026-06-16 16:57 ` Alex Williamson
2026-06-16 17:27 ` Jason Gunthorpe
2026-06-17 1:18 ` fengchengwen
2026-06-17 1:30 ` Alex Williamson
2026-06-17 2:33 ` fengchengwen
2026-06-17 3:01 ` Alex Williamson
2026-06-17 3:41 ` fengchengwen
2026-06-17 3:53 ` Krzysztof Wilczyński
2026-06-17 6:04 ` fengchengwen
2026-06-23 9:56 ` fengchengwen [this message]
2026-06-26 15:22 ` Alex Williamson
2026-06-28 11:58 ` fengchengwen
2026-06-29 15:43 ` Alex Williamson
2026-06-16 10:46 ` [PATCH v17 09/12] vfio/pci: Hide TPH capability when TPH is unsupported Chengwen Feng
2026-06-16 10:56 ` sashiko-bot
2026-06-16 10:46 ` [PATCH v17 10/12] vfio/pci: Add TPH_ENABLE feature skeleton and unsafe module parameter Chengwen Feng
2026-06-16 10:55 ` sashiko-bot
2026-06-16 10:46 ` [PATCH v17 11/12] vfio/pci: Add TPH_ST_CONFIG for PCIe TPH ST configuration Chengwen Feng
2026-06-16 11:05 ` sashiko-bot
2026-06-16 10:46 ` [PATCH v17 12/12] vfio/pci: Virtualize PCIe TPH capability registers Chengwen Feng
2026-06-16 11:03 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9105ceef-5e27-4e3c-8903-d46aef52a2bd@huawei.com \
--to=fengchengwen@huawei.com \
--cc=alex@shazbot.org \
--cc=helgaas@kernel.org \
--cc=jgg@ziepe.ca \
--cc=kvm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liuyonglong@huawei.com \
--cc=wangyushan12@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=wathsala.vithanage@arm.com \
--cc=wei.huang2@amd.com \
--cc=zhipingz@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox