[PATCH v2 0/3] iommu/vt-d: Ensure atomicity in context and PASID entry updates

Lu Baolu posted 3 patches 2 weeks, 4 days ago
drivers/iommu/intel/iommu.h  |  21 +++-
drivers/iommu/intel/pasid.h  |  28 +++---
drivers/iommu/intel/iommu.c  |  33 +++---
drivers/iommu/intel/nested.c |   9 +-
drivers/iommu/intel/pasid.c  | 190 +----------------------------------
5 files changed, 58 insertions(+), 223 deletions(-)
[PATCH v2 0/3] iommu/vt-d: Ensure atomicity in context and PASID entry updates
Posted by Lu Baolu 2 weeks, 4 days ago
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 following the translation table
entry ownership handshake protocal recommended by the VT-d specification.

[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/

Change log:

v2:
 - Considering that these fixes should be backported deep into old
   versions, and the previous solution relies heavily on the x86_64
   cmpxchg16b instruction, which is not friendly to backport as it might
   cause regressions on early hardware or configurations, we use the
   simple dma_wmb() approach in this version.
 - Jason proposed the entry-sync framework
   (https://lore.kernel.org/linux-iommu/20260113150542.GF812923@nvidia.com/)
   which consolidates the details of how to update a translation table
   entry in common code shared by the individual drivers, so that the
   IOMMU driver could be designed without considering the hitless or
   non-hitless replace.
 - To make life easier, I decided to split all the work into multiple
   series. The first, as it is, covers fixing the real problems in a
   backport-friendly way, and the next series covers entry-sync for
   PASID table entry updates.

v1: https://lore.kernel.org/linux-iommu/20260113030052.977366-1-baolu.lu@linux.intel.com/

Lu Baolu (3):
  iommu/vt-d: Clear Present bit before tearing down PASID entry
  iommu/vt-d: Clear Present bit before tearing down context entry
  iommu/vt-d: Fix race condition during PASID entry replacement

 drivers/iommu/intel/iommu.h  |  21 +++-
 drivers/iommu/intel/pasid.h  |  28 +++---
 drivers/iommu/intel/iommu.c  |  33 +++---
 drivers/iommu/intel/nested.c |   9 +-
 drivers/iommu/intel/pasid.c  | 190 +----------------------------------
 5 files changed, 58 insertions(+), 223 deletions(-)

-- 
2.43.0

Re: [PATCH v2 0/3] iommu/vt-d: Ensure atomicity in context and PASID entry updates
Posted by Jason Gunthorpe 2 weeks, 3 days ago
On Tue, Jan 20, 2026 at 02:18:11PM +0800, Lu Baolu wrote:
> 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 following the translation table
> entry ownership handshake protocal recommended by the VT-d specification.

This seems like a reasonable first series

Thanks,
Jason