This is a follow-up from recent discussions in the iommu community
mailing list [1] [2] regarding potential race conditions in table 
entry updates.

The Intel VT-d hardware fetches translation table entries (context
entries and PASID entries) in 128-bit (16-byte) chunks. Currently, the
Linux driver often updates these entries using multiple 64-bit writes.
This creates a race condition where the IOMMU hardware may fetch a
"torn" entry — a mixture of old and new data — during a CPU update. This
can lead to unpredictable hardware behavior, spurious faults, or system
instability.

This addresses these atomicity issues by implementing 128-bit atomic
updates where possible and following the VT-d specification's ownership
handshake protocol for larger structures.

[1] https://lore.kernel.org/linux-iommu/20251227175728.4358-1-dmaluka@chromium.org/
[2] https://lore.kernel.org/linux-iommu/20260107201800.2486137-1-skhawaja@google.com/

Lu Baolu (3):
  iommu/vt-d: Use 128-bit atomic updates for context entries
  iommu/vt-d: Clear Present bit before tearing down PASID entry
  iommu/vt-d: Rework hitless PASID entry replacement

 drivers/iommu/intel/Kconfig |  2 +-
 drivers/iommu/intel/iommu.h | 22 ++++++++--
 drivers/iommu/intel/pasid.h | 38 ++++++++++++++++-
 drivers/iommu/intel/iommu.c | 30 ++++++-------
 drivers/iommu/intel/pasid.c | 84 ++++++++++++++++++++++++++++++-------
 5 files changed, 140 insertions(+), 36 deletions(-)

-- 
2.43.0