On Wed, Jan 28, 2026 at 01:55:31PM -0400, Jason Gunthorpe wrote: > 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? >
This could probably could be made to work. I think it would be an initial pass to figure out the IOVA size then tightly pack. Let me look at this. Probably better too as installing dummy pages is a non-zero cost as I assume dma_iova_link is a radix tree walk. > 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? Scattered dma-addresses is already handled in the copy code, likewise holes so non-issue. > > 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 Yes and make the code simplish. > 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. > Cool, this explains the warning. > This is a possible option to teach things to detect the holes and > ignore them.. Another option — and IMO probably the best one — as it makes potential usages with holes the simplest at the driver level. Let me look at this too. Do you think we need flag somewhere for 'ignore holes' or can I just blindly skip them? Matt > > Jason
