# VFIO group 26: bounded source-level lifecycle

This case freezes **Linux v3.6** and the topology in its `Documentation/vfio.txt` example: group 26 contains PCI bridge `0000:00:1e.0` and functions `0000:06:0d.0` and `.1`. The document says transactions from the two functions are indistinguishable to the IOMMU behind that bridge. The example is documentary testimony, **not** a newly observed host or measured device transfer.

The analytical path assumes an Intel VT-d IOMMU selected by the platform, the type1 VFIO backend, both functions satisfying group viability, a single group and container, and successful API calls. It does not assume a specific interrupt mode, function-reset capability, ATS state, peer route, or verified physical quiescence. These conditions are recorded rather than silently supplied.

`vfio-group26-trace-v5.csv` follows the documented topology, group construction and viability, IOMMU activation, device open, DMA mapping, IRQ branch, explicit unmap, final close, group detach, Intel invalidation path, and backend release. Each row separates observed code from the permitted inference and the unresolved condition. The anchor blob ID identifies one primary file in the tagged locator; multi-file rows list every additional file and line range in that locator. All files were checked against the official v3.6 Git tag.

Three source-level findings narrow G05 without classifying it:

1. The PCI final-close path attempts `pci_reset_function` but ignores its return. The PCI helper can return a negative value when a single-function reset is unsupported. The opening path checks reset support, but this case has no actual result for the example device.
2. Intel group detach clears device context and requests global context and IOTLB invalidation. The queued path can wait for completion, subject to queue success and capability-dependent drains. This is a more specific release path than the proposal documents gave, but no host trace confirms it.
3. The inspected explicit `VFIO_IOMMU_UNMAP_DMA` path reaches Intel `intel_iommu_unmap`, which clears PTEs and comments that a TLB flush should follow. The inspected call chain has no visible invalidation before returning. This is an **evidence gap for per-unmap completion**, not a demonstrated exploit or proof that stale DMA occurred.

The documentation example itself uses `VFIO_X86_IOMMU` and `vfio_iommu_x86_*` names, while the same tag's public header defines `VFIO_TYPE1_IOMMU` and `vfio_iommu_type1_*`. It is therefore not treated as executable code. The chronology and ownership model remain informative.

**Decision:** the broad G05 guarantee—safe reassignment of the group to a different owner after DMA, interrupts, reset, peer paths, and in-flight work—is **not classifiable** from this record. A narrower source-level claim is supported: Linux v3.6 contains explicit cleanup and Intel detach/invalidation paths for the documented group-shaped case. The observed code alone cannot prove that every old-owner effect ended on a particular platform.