Linux kernel (drivers/iommu/intel): VT-d switched from set-and-check to clear-and-reset when programming device-table

Impact

VT-d switched from set-and-check to clear-and-reset when programming device-table context entries on domain attach. For PCI functions that share a requester ID through a PCIe-to-PCI bridge, attaching one function blows away the context entry the sibling is using, so devices in the same IOMMU group end up with a wrong or absent translation and start taking DMA faults. Attaching a device to a tenant's domain therefore disturbs the translation state of every other function aliased to it - the shared entry is the boundary, and the attach path stops treating it as shared.

Who can reach it

Triggered by domain attach on Intel VT-d hosts whenever devices are PCI-aliased behind a PCIe-to-PCI bridge - exactly the case where those functions must be passed through as one IOMMU group. Reached through the normal VFIO/iommufd attach a tenant's VMM performs when claiming a device, so a tenant's start/stop cycle drives it; no host root required. Conditional on Intel VT-d and on the node actually having aliased functions (upstream reproduced it with an Apple SPI controller, but the pattern is generic to bridge-aliased devices).

What to do

No fixed release is listed in this record; apply the linked stable commits or run a current stable/LTS kernel on Intel passthrough nodes. Interim: avoid assigning devices that live in an aliased IOMMU group behind a PCIe-to-PCI bridge, and audit dmesg for DMAR PTE-read faults on nodes where a tenant attach coincides with another device going quiet.

References