Re: [RFC PATCH v3 04/11] drm/pagemap: Use dma-map IOVA alloc, link, and sync API for DRM pagemap

[Matthew Brost <matthew.brost@intel.com>]

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