Applying with these fixes on my side:
- "grows to 6" -> "grows up to 6"
- the second paragraph split in two: when the table grows, and what a
faulting read and write do, as a "- " list
On Tue, 10 Nov 2026 17:45:29 +0100, Denis V. Lunev wrote:
> The v1 table starts with 3 levels and grows to 6 on the first IOVA
> dma-iommu takes from the top of the 64-bit space, once the 32-bit space
> runs out.
The table stops at amd_iommu_hpt_level. On parts whose EFR[HATS] allows
only 4 or 5 levels it never reaches 6, and the race is the same there.
> - write_seqcount_end(&pgtable->seqcount);
> -
> amd_iommu_update_and_flush_device_table(domain);
> + write_seqcount_end(&pgtable->seqcount);
- Please send a separate backport of upstream 1e75a8255f11c ("iommu/amd:
Wait for completion instead of returning early in
iommu_completion_wait()"). I created a task for that:
https://virtuozzo.atlassian.net/browse/VSTOR-154424
This fix relies on domain_flush_complete() having waited for the DTE
invalidation before write_seqcount_end(). In vz10
iommu_completion_wait() still tests need_sync without iommu->lock.
If another CPU queues a completion wait on the same IOMMU right after
our invalidation, it clears need_sync. Our wait then returns before the
IOMMU has run the invalidation, and a mapper can hand out a 64-bit IOVA
while the old DTE is still cached.
The window is much smaller than the one this patch closes, but it opens
under the same heavy DMA load. The stable trees have the fix, vz10 does
not yet. It needs a small adaptation, cmd_sem_val is still an atomic64_t
here.
--
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
