Claude review: vfio: add dma-buf get_tph callback and DMA_BUF_TPH feature

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**dma-buf callback design (include/linux/dma-buf.h)**

The `get_tph` callback API is clean. The documentation clearly specifies that 8-bit and 16-bit ST are distinct namespaces. One observation:

```c
int (*get_tph)(struct dma_buf *dmabuf, u16 *steering_tag, u8 *ph,
	       u8 st_width);
```

The `steering_tag` output is `u16 *` but for `st_width == 8` the caller only expects an 8-bit value. This is fine since the VFIO implementation stores `u8 steering_tag` and will only write the low byte, but it means the implementation must be careful. Looking at the actual implementation:

```c
case 8:
	if (!(flags & VFIO_DMA_BUF_TPH_ST))
		return -EOPNOTSUPP;
	*steering_tag = priv->steering_tag;
	break;
case 16:
	if (!(flags & VFIO_DMA_BUF_TPH_ST_EXT))
		return -EOPNOTSUPP;
	*steering_tag = priv->steering_tag_ext;
	break;
```

This correctly returns the right-width value via the `u16` pointer. Good.

**Write-once semantics and memory ordering (vfio_pci_dmabuf.c)**

The release/acquire pair is correctly used:

```c
/* Writer: */
priv->steering_tag = set_tph.steering_tag;
priv->steering_tag_ext = set_tph.steering_tag_ext;
priv->ph = set_tph.ph;
smp_store_release(&priv->tph_flags, set_tph.flags);

/* Reader: */
flags = smp_load_acquire(&priv->tph_flags);
```

The write-once enforcement via `READ_ONCE(priv->tph_flags)` check returning `-EBUSY` under `memory_lock` is correct.

**READ_ONCE/WRITE_ONCE on priv->vdev**

The conversion of plain accesses to `READ_ONCE`/`WRITE_ONCE` for `priv->vdev` is a reasonable annotation improvement, but there's a subtlety: in `vfio_pci_dma_buf_release`, the code does:

```c
struct vfio_pci_core_device *vdev = READ_ONCE(priv->vdev);
if (vdev) {
	down_write(&vdev->memory_lock);
```

The original code didn't use `READ_ONCE` here either, and this path races with `vfio_pci_dma_buf_cleanup` which does `WRITE_ONCE(priv->vdev, NULL)` under `dma_resv_lock`. The `READ_ONCE` prevents compiler tearing/re-reading but doesn't add synchronization. The existing `kref` protects against double-cleanup, so this is still correct — just worth noting that `READ_ONCE`/`WRITE_ONCE` here are documentation of the existing design rather than a fix.

**uAPI struct (include/uapi/linux/vfio.h)**

```c
struct vfio_device_feature_dma_buf_tph {
	__s32	dmabuf_fd;
	__u32	flags;
	__u8	steering_tag;
	__u8	ph;
	__u16	steering_tag_ext;
};
```

This is 12 bytes total with natural alignment (no holes). Feature number 13 is correctly the next available. The struct has no padding or reserved fields — that's fine for a write-only SET-only feature, but if GET support were ever desired, there'd be no room for extension. Given the write-once semantics, this seems intentional.

**Minor**: The `revoked` field changed from `u8 revoked : 1` to `bool revoked`. This is a clean-up unrelated to TPH — consider splitting it out or at least mentioning it in the commit message.

---
Generated by Claude Code Patch Reviewer