Re: [PATCH v3 28/33] drm/xe: Use IOVA-based DMA mapping for eligible tt BOs

[Matthew Auld <matthew.auld@intel.com>]

On 11/07/2026 03:56, Matthew Brost wrote:
> Add support for mapping a ttm_tt's pages using the IOVA-based DMA API
> (dma_iova_try_alloc()/link()/sync()/unlink()/free()) as an alternative
> to the scatter-gather list. An IOVA mapping is a single contiguous DMA
> range, which is cheaper to walk and program than an sg list.
> 
> Whether the IOVA API can be used depends on the IOMMU mode, so the
> decision is made once per tt at xe_ttm_tt_create() time and recorded in
> struct xe_ttm_tt::use_iova. To keep the scope limited, only device BOs
> that are not GGTT-mapped are eligible: dma-buf imports manage their own
> mapping and GGTT bindings are programmed directly from the sg list.
> dma_iova_try_alloc() may still fail, in which case the tt transparently
> falls back to the sg list, which remains the default.
> 
> The IOVA reservation is allocated at tt creation and freed at tt
> destroy. xe_tt_map_iova() links the tt pages (coalescing physically
> contiguous runs) and syncs the IOTLB; xe_tt_unmap_iova() unlinks them
> but keeps the reservation so the tt can be remapped without
> re-allocating IOVA space. xe_tt_map()/xe_tt_unmap() dispatch between the
> IOVA and sg backends, and xe_bo_dma_unmap_pinned() learns about the IOVA
> case.
> 
> Consumers that walked the sg list via xe_res_first_sg(xe_bo_sg()) now go
> through the new xe_res_first_tt() helper, which initializes either an
> IOVA cursor (xe_res_first_iova()) or an sg cursor depending on the tt's
> mapping mode.
> 
> Cc: Carlos Santa <carlos.santa@intel.com>
> Cc: Ryan Neph <ryanneph@google.com>
> Cc: Christian Koenig <christian.koenig@amd.com>
> Cc: Huang Rui <ray.huang@amd.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Assisted-by: GitHub_Copilot:claude-opus-4.8
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>


<snip>

>   static void xe_ttm_tt_destroy(struct ttm_device *ttm_dev, struct ttm_tt *tt)
>   {
> +	struct xe_ttm_tt *xe_tt = container_of(tt, struct xe_ttm_tt, ttm);
> +
> +	/*
> +	 * Release the IOVA reservation made in xe_ttm_tt_create(). The pages
> +	 * must already have been unlinked by xe_tt_unmap().
> +	 */
> +	if (xe_tt->use_iova) {
> +		struct xe_device *xe = ttm_to_xe_device(ttm_dev);
> +
> +		xe_assert(xe, !xe_tt->iova_linked);
> +		dma_iova_free(xe->drm.dev, &xe_tt->iova);

Do we know if this is allowed? I think there is 
xe_bo_pci_dev_remove_all() which requires that evict_all will correctly 
tear down iommu mappings on stuff like pci unplug and I don't think 
tt_destroy is called in that flow? Does having the iova here cause 
issues? Also, for VRAM flow I think there is a tt_create() via pipeline 
gutting which will now create a new iova?

Aside from that, maybe we can land 27/28 as standalone?