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

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

Patch Review

**uAPI structure looks correct.** `struct vfio_device_feature_dma_buf_tph` is 16 bytes with proper alignment and 3 reserved bytes for future use:

```c
struct vfio_device_feature_dma_buf_tph {
	__s32	dmabuf_fd;        /* 0-3 */
	__u32	flags;            /* 4-7 */
	__u16	steering_tag;     /* 8-9 */
	__u16	steering_tag_ext; /* 10-11 */
	__u8	ph;               /* 12 */
	__u8	reserved[3];      /* 13-15 */
};
```

**Feature number 13 is next available**, following `VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 = 12` in the current tree.

**Input validation is thorough** — reserved fields, unknown flag bits, ph range:

```c
if (set_tph.reserved[0] || set_tph.reserved[1] || set_tph.reserved[2])
	return -EINVAL;
if (set_tph.flags & ~(VFIO_DMA_BUF_TPH_ST | VFIO_DMA_BUF_TPH_ST_EXT))
	return -EINVAL;
if (!set_tph.flags)
	return -EINVAL;
if (set_tph.ph & ~0x3)
	return -EINVAL;
```

**The memory ordering is correct.** Writers populate the value fields first, then publish with `smp_store_release()` on `tph_flags`; readers do `smp_load_acquire()` before reading the values. This is a well-established producer-consumer pattern.

**Issue: No revocation check when setting TPH.** In `vfio_pci_core_feature_dma_buf_tph`, the code acquires `memory_lock` and validates `priv->vdev == vdev`, but does not check `priv->revoked`. Setting TPH on a revoked dma-buf is arguably harmless (the get_tph callback would still work, but the buffer can't be mapped), but it seems like a bug to accept a SET ioctl that produces a state that can never be consumed. Consider adding:

```c
if (priv->vdev != vdev) {
	ret = -EINVAL;
	goto out_unlock;
}
+if (priv->revoked) {
+	ret = -ENODEV;
+	goto out_unlock;
+}
```

Note: accessing `priv->revoked` under `memory_lock` while it's written under `dma_resv_lock` is a data race unless `revoked` transitions monotonically and you treat the check as advisory. Since `revoked` is now a `bool` (not a bitfield), a plain load is fine on architectures where bool stores are atomic, but you might want `READ_ONCE(priv->revoked)` for correctness under KCSAN.

**Issue: No way to unset TPH.** The validation rejects `!set_tph.flags`, so once TPH is set, it cannot be cleared. This may be fine for the current use case, but it's worth documenting as a deliberate choice in the uAPI comment. If a future caller needs to re-set with different values, the current code does support that (subsequent SETs overwrite), but clearing back to "no TPH" is impossible.

**Minor: dma-buf core API change.** Adding `get_tph` to `struct dma_buf_ops` in `include/linux/dma-buf.h` changes the dma-buf framework's interface. This is optional (documented as such), but will need acks from the dma-buf maintainers (Christian König / Sumit Semwal). The comment block is well-written.

**The bitfield-to-bool conversion for `revoked` is correct** — it prevents the compiler from merging a read-modify-write on the bitfield byte across two different locks.

---
Generated by Claude Code Patch Reviewer