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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Jun 03, 2026 at 12:53:08PM -0600, Alex Williamson wrote:
> On Tue, 2 Jun 2026 21:45:24 -0300
> Jason Gunthorpe <jgg@ziepe.ca> wrote:
> 
> > On Wed, Jun 03, 2026 at 08:34:53AM +0800, fengchengwen wrote:
> > 
> > > This translation helper is required to handle varied TPH configurations,
> > > including cases where ST entries live inside device private registers
> > > instead of MSI-X or TPH capability space.  
> > 
> > I thought we agreed vfio had to block that feature in config space due
> > to security concerns? That's what enable_unsafe_tph is about, right?
> 
> Steering tags can effectively live in one of three places.  The
> architected locations are the TPH capability itself and the MSI-X
> table, where support is mutually exclusive.  However the device can
> support either of these and still enable DS mode, thus essentially
> a third location.
> 
> None of these are particularly more or less unsafe than another.  It's
> inadvisable for drivers to write to the MSI-X vector table, versus
> using the SET_IRQS uAPI, but it's not prevented anymore via mmap. 

We'd have to go back to preventing it..

> We don't provide direct write access to the TPH capability, but
> backdoors to config space are not uncommon.  

I think we can discount this, if a device exposes TPH through config
then it should keep it secure.

> I'm actually still wrestling with the question whether any of this is
> really unsafe beyond the scope of ownership of the device at all.

Well there is certainly some kind of DOS argument for calling it
unsafe, and we don't actually know what effects the TPH value even
has.

I'd be much more worried about some "smart" accelerator device doing
something impactful based on TPH than insecure config space for
example.

> > I agree in general that the presence of enable_unsafe_tph VFIO has to
> > report the per-device steering tags to userspace so it can program the
> > device specific registers, nothing else can do this.
> 
> What's the scope of "nothing else" here?  The raw ST value for a CPU is
> derived from an ACPI _DSM associated to a root port.  So if the scope
> is that the kernel needs to provide that translation, I agree, but
> where in the kernel it's provided may still require some thought.

The APIs accept a PCI device:

int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type,
			unsigned int cpu, u16 *tag)


IIRC the ACPI allows it to vary based on the source. Nothing else
could provide the PCI device owned by VFIO to these functions..

> We also need to consider how this incorporates Zhiping's series, where
> TPH values can be associated to a dmabuf.  Would userspace get access
> to those raw TPH values to program the initiator?  It must for DS
> support.  Therefore the interface became one of the user handling raw
> ST values and the CPU ID to ST translation became this ill-fitting
> sidecar.

Arguably yes, likely iommufd would need an API to return the ST of the
dmabuf when it maps it.

Jason