iommu/dma: SATA RMRR reservation omission in shared group on HP Gen8

iommu/dma: SATA RMRR reservation omission in shared group on HP Gen8

[Renato Machelett]

Hello,

I am hitting a recurring DMA PTE collision issue on an HP ProLiant DL320e Gen8 v2 (Xeon E3-1230 v3, Intel C222 Lynx Point PCH, BIOS P80 tested with both 03/28/2014 and 04/04/2019) on Ubuntu 24.04 with 6.8.0-146-generic. In Ubuntu's 6.8.0-147-generic source, drivers/iommu/dma-iommu.c is byte-identical.

On Ubuntu Launchpad, bug 2160616 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160616) reported the same 0xf1f7e collisions on HP Gen8 hardware and was marked as a duplicate of bug 2158934 (the PCIe ACS quirk regression reverted in 6.8.0-136.136). However, 6.8.0-146 already contains that ACS revert and still reproduces these collisions with intel_iommu=on, because on the Intel C222 PCH 00:1f.0 (LPC bridge, 8086:8c4e) and 00:1f.2 (AHCI SATA controller, 8086:8c02) are multifunction siblings without ACS hardware and share IOMMU group 8:

  pci 0000:00:1f.0: Adding to iommu group 8
  pci 0000:00:1f.2: Adding to iommu group 8

The ProLiant DMAR table defines 23 pages of RMRR (0xf1f7e000-0xf1f94fff) scoped to 00:1f.2 (SATA), but not to 00:1f.0 (LPC).

My source analysis points to drivers/iommu/dma-iommu.c (matching the Oct 2024 thread at https://lists.openwall.net/linux-kernel/2024/10/24/1195):
1. During bus probing (bus_iommu_probe -> iommu_setup_default_domain, drivers/iommu/iommu.c:2014, :3150), iommu_create_device_direct_mappings() installs 00:1f.2's 23 identity PTEs (0xf1f7e003..0xf1f94003) into group 8's hardware IOMMU page table.
2. When bus_iommu_probe() finalizes group 8 in member order (00:1f.0 first, 00:1f.2 second), iommu_dma_init_domain() (drivers/iommu/dma-iommu.c:701-727) initializes iovad->start_pfn and calls iova_reserve_iommu_regions() for 00:1f.0 (which has no RMRRs), then takes the already-initialized iovad->start_pfn early return (lines 701-713) for 00:1f.2 without reserving 00:1f.2's RMRRs in the IOVA allocator.
3. Because iommu_dma_alloc_iova() prefers allocations below 4 GiB (pci_32bit_workaround), ordinary ahci disk I/O can allocate these unreserved vPFNs (0xf1f7e..0xf1f94):

  DMAR: ERROR: DMA PTE for vPFN 0xf1f7e already set (to f1f7e003 not 11f04e003)
  WARNING: CPU: 3 PID: 2210 at drivers/iommu/intel/iommu.c:2227 __domain_mapping+0x2b5/0x320
  Call Trace:
   <TASK>
   intel_iommu_map_pages+0xe1/0x140
   __iommu_map+0x121/0x280
   iommu_map_sg+0xbf/0x1f0
   iommu_dma_map_sg+0x463/0x4f0
   __dma_map_sg_attrs+0x35/0xd0
   dma_map_sg_attrs+0xe/0x30
   ata_qc_issue+0x131/0x320

4. In __domain_mapping() (drivers/iommu/intel/iommu.c:2218), cmpxchg64_local(&pte->val, 0ULL, pteval) sees the pre-existing RMRR identity PTE (0xf1f7e003) and logs the warning, but does not fail the mapping, leaving the identity translation in place. A subsequent DMA transfer could therefore access the RMRR page instead of the intended RAM buffer (I also observed cached ext4 inode checksum errors on this host, though I have not proven the completed DMA link directly). Subsequent DMA unmapping in dma_pte_clear_level() (drivers/iommu/intel/iommu.c:1097) calls dma_clear_pte(), clearing the covered identity PTE so repeated allocations at that vPFN need not produce another warning.

Separately, when testing Ubuntu Noble HWE 7.0.0-38-generic on the same host, drivers/iommu/dma-iommu.c still has the same initialized-domain early return before per-device reservation, and I also observed immediate VT-d faults during boot ("DMAR: [DMA Write NO_PASID] Request device [00:1f.2] fault addr 0xf4c00000 [fault reason 0x0c] non-zero reserved fields in PTE", CAP=0xd2008c20660462, ECAP=0xf010da) followed by ATA Emask 0x40 (AC_ERR_SYSTEM) failures. This kernel uses drivers/iommu/generic_pt/fmt/vtdss.h, whose permission handling in vtdss_pt_iommu_set_prot() differs from the legacy implementation (no longer OR'ing bit 0 on IOMMU_WRITE), though I have not established which specific PTE field caused the 0x0c fault.

I am currently running with intel_iommu=off as a workaround. Is there an existing fix or backport for this shared-group reservation omission?

Thank you!
Renato

Re: iommu/dma: SATA RMRR reservation omission in shared group on HP Gen8

[Baolu Lu]

On 10/18/2026 9:50 AM, Renato Machelett wrote:
> Hello,
> 
> I am hitting a recurring DMA PTE collision issue on an HP ProLiant DL320e Gen8 v2 (Xeon E3-1230 v3, Intel C222 Lynx Point PCH, BIOS P80 tested with both 03/28/2014 and 04/04/2019) on Ubuntu 24.04 with 6.8.0-146-generic. In Ubuntu's 6.8.0-147-generic source, drivers/iommu/dma-iommu.c is byte-identical.
> 
> On Ubuntu Launchpad, bug 2160616 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160616) reported the same 0xf1f7e collisions on HP Gen8 hardware and was marked as a duplicate of bug 2158934 (the PCIe ACS quirk regression reverted in 6.8.0-136.136). However, 6.8.0-146 already contains that ACS revert and still reproduces these collisions with intel_iommu=on, because on the Intel C222 PCH 00:1f.0 (LPC bridge, 8086:8c4e) and 00:1f.2 (AHCI SATA controller, 8086:8c02) are multifunction siblings without ACS hardware and share IOMMU group 8:
> 
>    pci 0000:00:1f.0: Adding to iommu group 8
>    pci 0000:00:1f.2: Adding to iommu group 8
> 
> The ProLiant DMAR table defines 23 pages of RMRR (0xf1f7e000-0xf1f94fff) scoped to 00:1f.2 (SATA), but not to 00:1f.0 (LPC).
> 
> My source analysis points to drivers/iommu/dma-iommu.c (matching the Oct 2024 thread at https://lists.openwall.net/linux-kernel/2024/10/24/1195):
> 1. During bus probing (bus_iommu_probe -> iommu_setup_default_domain, drivers/iommu/iommu.c:2014, :3150), iommu_create_device_direct_mappings() installs 00:1f.2's 23 identity PTEs (0xf1f7e003..0xf1f94003) into group 8's hardware IOMMU page table.
> 2. When bus_iommu_probe() finalizes group 8 in member order (00:1f.0 first, 00:1f.2 second), iommu_dma_init_domain() (drivers/iommu/dma-iommu.c:701-727) initializes iovad->start_pfn and calls iova_reserve_iommu_regions() for 00:1f.0 (which has no RMRRs), then takes the already-initialized iovad->start_pfn early return (lines 701-713) for 00:1f.2 without reserving 00:1f.2's RMRRs in the IOVA allocator.
> 3. Because iommu_dma_alloc_iova() prefers allocations below 4 GiB (pci_32bit_workaround), ordinary ahci disk I/O can allocate these unreserved vPFNs (0xf1f7e..0xf1f94):
> 
>    DMAR: ERROR: DMA PTE for vPFN 0xf1f7e already set (to f1f7e003 not 11f04e003)
>    WARNING: CPU: 3 PID: 2210 at drivers/iommu/intel/iommu.c:2227 __domain_mapping+0x2b5/0x320
>    Call Trace:
>     <TASK>
>     intel_iommu_map_pages+0xe1/0x140
>     __iommu_map+0x121/0x280
>     iommu_map_sg+0xbf/0x1f0
>     iommu_dma_map_sg+0x463/0x4f0
>     __dma_map_sg_attrs+0x35/0xd0
>     dma_map_sg_attrs+0xe/0x30
>     ata_qc_issue+0x131/0x320
> 
> 4. In __domain_mapping() (drivers/iommu/intel/iommu.c:2218), cmpxchg64_local(&pte->val, 0ULL, pteval) sees the pre-existing RMRR identity PTE (0xf1f7e003) and logs the warning, but does not fail the mapping, leaving the identity translation in place. A subsequent DMA transfer could therefore access the RMRR page instead of the intended RAM buffer (I also observed cached ext4 inode checksum errors on this host, though I have not proven the completed DMA link directly). Subsequent DMA unmapping in dma_pte_clear_level() (drivers/iommu/intel/iommu.c:1097) calls dma_clear_pte(), clearing the covered identity PTE so repeated allocations at that vPFN need not produce another warning.
> 
> Separately, when testing Ubuntu Noble HWE 7.0.0-38-generic on the same host, drivers/iommu/dma-iommu.c still has the same initialized-domain early return before per-device reservation, and I also observed immediate VT-d faults during boot ("DMAR: [DMA Write NO_PASID] Request device [00:1f.2] fault addr 0xf4c00000 [fault reason 0x0c] non-zero reserved fields in PTE", CAP=0xd2008c20660462, ECAP=0xf010da) followed by ATA Emask 0x40 (AC_ERR_SYSTEM) failures. This kernel uses drivers/iommu/generic_pt/fmt/vtdss.h, whose permission handling in vtdss_pt_iommu_set_prot() differs from the legacy implementation (no longer OR'ing bit 0 on IOMMU_WRITE), though I have not established which specific PTE field caused the 0x0c fault.
> 
> I am currently running with intel_iommu=off as a workaround. Is there an existing fix or backport for this shared-group reservation omission?

Thank you for the report. This issue still appears to exist in the
latest upstream kernel:

static int iommu_dma_init_domain(struct iommu_domain *domain, struct 
device *dev)
{
...
         /* start_pfn is always nonzero for an already-initialised domain */
         if (iovad->start_pfn) {
                 if (1UL << order != iovad->granule ||
                     base_pfn != iovad->start_pfn) {
                         pr_warn("Incompatible range for DMA domain\n");
                         return -EFAULT;
                 }

                 return 0;
         }
...
}

The early return is still there. Have you tried reserving the second
device's RMRR in the IOVA allocator as well? Something like:

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 68ee57800fef..e9b39009f109 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -704,7 +704,7 @@ static int iommu_dma_init_domain(struct iommu_domain 
*domain, struct device *dev
                         return -EFAULT;
                 }

-               return 0;
+               return iova_reserve_iommu_regions(dev, domain);
         }

         init_iova_domain(iovad, 1UL << order, base_pfn);

This would at least confirm your analysis.

Thanks,
baolu

RE: iommu/dma: SATA RMRR reservation omission in shared group on HP Gen8

[Renato Machelett]

On 10/19/2026, Baolu Lu wrote:
> The early return is still there. Have you tried reserving the second
> device's RMRR in the IOVA allocator as well? Something like:
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 68ee57800fef..e9b39009f109 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -704,7 +704,7 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, struct device *dev
>                          return -EFAULT;
>                  }
>
> -               return 0;
> +               return iova_reserve_iommu_regions(dev, domain);
>          }
>
>          init_iova_domain(iovad, 1UL << order, base_pfn);
>
> This would at least confirm your analysis.

Hi Baolu,

I have not tested a patched kernel because this is a production server.

In the October 2024 thread, Jerry Snitselaar proposed the equivalent
change, and Robin Murphy pointed out why calling
iova_reserve_iommu_regions() in the already-initialized branch is unsafe
as a general fix (https://lkml.iu.edu/2411.1/00575.html):

> It's also possible for the second device to get here after the first
> device has already started using the domain, so at that point it's no
> longer safe to use reserve_iova() due to how it merges overlapping and
> adjacent rbtree nodes, which could really screw things up once there
> are normal allocations in the tree as well.

Best regards,
Renato