On Wed, Jan 28, 2026 at 09:46:44AM -0800, Matthew Brost wrote: > It is intended to fill holes. The input pages come from the > migrate_vma_* functions, which can return a sparsely populated array of > pages for a region (e.g., it scans a 2M range but only finds several of > the 512 pages eligible for migration). As a result, if (!page) is true > for many entries.
This is migration?? So something is DMA'ing from A -> B - why put holes in the first place? Can you tightly pack the pages in the IOVA? If there is no iommu then the addresses are scattered all over anyhow so it can't be relying on some dma_addr_t relationship? You don't have to fully populate the allocated iova, you can link from A-B and then unlink from A-B even if B is less than the total size requested. The hmm users have the holes because hmm is dynamically adding/removing pages as it runs and it can't do anything to pack the mapping. > > IOVA space? If so, what necessitates those holes? You can have less mapped > > than IOVA and dma_iova_*() API can handle it. > > I was actually going to ask you about this, so I’m glad you brought it > up here. Again, this is a hack to avoid holes — the holes are never > touched by our copy function, but rather skipped, so we just jam in a > dummy address so the entire IOVA range has valid IOMMU pages. I would say what you are doing is trying to optimize unmap by unmapping everything in one shot instead of just the mapped areas, and the WARN_ON is telling you that it isn't allowed to unmap across a hole. > at the moment I’m not sure whether this warning affects actual > functionality or if we could just delete it. It means the iommu page table stopped unmapping when it hit a hole and there is a bunch of left over maps in the page table that shouldn't be there. So yes, it is serious and cannot be deleted. This is a possible option to teach things to detect the holes and ignore them.. Jason
