iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode

In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode

Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation

request when device is disconnected") relies on

pci_dev_is_disconnected() to skip ATS invalidation for

safely-removed devices, but it does not cover link-down caused

by faults, which can still hard-lock the system.

For example, if a VM fails to connect to the PCIe device,

"virsh destroy" is executed to release resources and isolate

the fault, but a hard-lockup occurs while releasing the group fd.

Call Trace:

qi_submit_sync

qi_flush_dev_iotlb

intel_pasid_tear_down_entry

device_block_translation

blocking_domain_attach_dev

__iommu_attach_device

__iommu_device_set_domain

__iommu_group_set_domain_internal

iommu_detach_group

vfio_iommu_type1_detach_group

vfio_group_detach_container

vfio_group_fops_release

__fput

Although pci_device_is_present() is slower than

pci_dev_is_disconnected(), it still takes only ~70 µs on a

ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed

and width increase.

Besides, devtlb_invalidation_with_pasid() is called only in the

paths below, which are far less frequent than memory map/unmap.

1. mm-struct release

2. {attach,release}_dev

3. set/remove PASID

4. dirty-tracking setup

The gain in system stability far outweighs the negligible cost

of using pci_device_is_present() instead of pci_dev_is_disconnected()

to decide when to skip ATS invalidation, especially under GDR

high-load conditions.