Re: [PATCH v14 0/8] vfio/pci: Add PCIe TPH support

[Alex Williamson <alex@shazbot.org>]

On Thu, 28 May 2026 20:46:41 +0800
Chengwen Feng <fengchengwen@huawei.com> wrote:

> This patchset enables userspace control over PCIe TPH steering tags,
> motivated by the following considerations:
> 
> 1. Why userspace needs the capability to control steering tags:
>    When PCIe devices are fully owned by userspace workloads such as DPDK
>    and SPDK, only userspace has full knowledge of core binding policies
>    and traffic distribution strategies. Without this series, userspace
>    cannot enable TPH or configure steering tags, leaving built-in PCIe
>    performance optimizations unused in high-throughput polling I/O
>    scenarios.
> 
> 2. Why this interface must be implemented in VFIO:
>    VFIO is the standard, secure community solution for granting full
>    PCIe device ownership to userspace. Existing kernel TPH interfaces
>    are designed purely for in-kernel drivers. For user-owned devices,
>    VFIO provides the only isolated and correct path to expose per-device
>    TPH management.
> 
> TPH supports both IV and DS modes. Since both modes could introduces
> cross-VM isolation risks such as untrusted guests programming arbitrary
> steering tags to impact other domains:
> 1. If ST location in MSI-X table, untrusted guests may program the
>    MSI-X table.
> 2. If ST don't locate in MSI-X or CAP, untrusted guests may program the
>    device-specific register.
> So a new module parameter `enable_unsafe_tph` is added. It defaults to
> off, and blocks all unsafe TPH operations when disabled.
> 
> Based on earlier RFC work by Wathsala Vithanage
> 
> ---
> v14:
> - Return PCI_TPH_LOC_NONE when !CONFIG_PCIE_TPH accord Alex's comment
> - Fix Sashiko comments:
>   - Clear ST shadow state across user session
>   - Fix out-of-bounds byte masking in vfio_pci_tph_config_read
> v13:
> - Fix Alex's comments:
>   - Add virtualize of TPH request type
>   - Adopt two feature


 - Patch 2/ sets tph_cap to zero if TPH cannot be enabled, but this is
   never propagated to vfio-pci to drop the TPH capability from the
   capability chain.

 - Patch 3/ exposing the enum to callers is a bit ugly, maybe we should
   retain pci_enable_tph() as the "auto" wrapper, resulting in no
   change to existing users, and add _ext and _std wrappers.

 - Patch 4/ same, multiple wrappers keeps the "auto" api cleaner.  Also
   note that auto is broken before TPH is enabled when tph_req_type is
   zero.

 - Patch 6/:
   - mutex_init/destroy belong in vfio_pci_core_init_dev/release_dev()
   - Re-order to avoid forward declarations.
   - vfio_check_feature() does not require declaring PROBE as a
     supported op.
   - pcie_tph_set_st_entry() can write to MMIO space without testing
     for or enabling device memory or power state.
   - tph_init allocates shadow table regardless of opt-in for tph
     support.
   - Redundant tests for count/index in feature function.
   - Duplicate memcpy/kfree in feature function.

 - Patch 7/:
   - Unclear why it's vfio-pci's responsibility to provide this
     translation interface.
   - PROBE is unnecessary for vfio_check_feature().
   - Array size conversion is strange.

 - Patch 8/:
   - default config read handles emulated bits.  Clear the bit if
     necessary in vconfig, use p_setd() to mark PCI_TPH_CAP_EXT_TPH
     virtualized, read-only.
   - Follow examples like vfio_pm_config_write, vfio_vpd_config_write,
     vfio_exp_config_write, etc.  Set the virtualized and writable
     bits, perform default config write, evaluate if anything was
     enabled, effect the change in hardware via kernel APIs.
   - pcie_disable_tph() happens after the restore state is recorded.
   - TPH capability becomes read/write, an ABI change to the user, with
     only a host-based opt-in.  Seems like the userspace driver also
     needs to opt-in to the ABI change.
   - Memory enable not assured for pcie_tph_set_st_entry().
   - Sashiko notes there are existing hazards in the tph_enabled
     storage unit relative to multiple bitfields that can be updated
     concurrently.  The problem is worse with this exposed through
     vfio-pci.

Thanks,
Alex