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

[Jason Gunthorpe <jgg@ziepe.ca>]

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?

> Prior discussion with Jason (
> ref: https://lore.kernel.org/all/20260414151125.GF2577880@ziepe.ca/)
> indicated VFIO-PCI is the correct component for per-device TPH
> implementation.

> > The host-only opt-in issue above also doesn't appear to be addressed or
> > rebutted.
> 
> enable_unsafe_tph host opt-in already fully gates all new TPH ABI:
> TPH cap + feature ioctl are completely hidden from userspace when off,
> no userspace opt-in needed.

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.

But I don't really get what is going on with all the new uAPI
proposed.

I don't understand what VFIO_DEVICE_FEATURE_TPH_ST_CONFIG is supposed
to be for, userspace should not be able to directly program registers
that are kernel controled. In this case it is 'safe' and it should be
only programmed by specifying abstract information like TPH_CPU_ST
does.

I'm also wondering why it needs a shadow entry, that doesn't seem
normal for config space tables..

Jason