Re: [PATCH 23/26] treewide: Rename dma_buf_attach() to dma_buf_sgt_attach()

["Christian König" <christian.koenig@amd.com>]

On 10/27/26 03:15, Karl Mehltretter wrote:
> On Mon, Oct 26, 2026 at 04:36:14PM +0100, Alistair Popple wrote:
> 
> Testing the series on a Jetson Nano exposed this path. A 3 MiB system-heap
> buffer was imported into Tegra DRM and scanned out over HDMI. With
> CONFIG_DMABUF_DEBUG=y the PRIME import succeeded, but scanout immediately
> produced display SMMU faults starting at 0x300000.
> 
> Tracing the fault led here:
> 
>> @@ -475,7 +475,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device *drm,
>>  	 * domain, map it first to the DRM device to get an sgt.
>>  	 */
>>  	if (tegra->domain) {
>> -		attach = dma_buf_attach(buf, drm->dev);
>> +		attach = dma_buf_sgt_attach(buf, drm->dev);
> 
> tegra_bo_import() passes the attachment SGT to iommu_map_sgtable(), which
> uses sg_phys() and sg->length. The SGT mapping contract only guarantees the
> DMA address and length fields. The debug wrapper clears the page-side fields,
> so iommu_map_sgtable() maps zero bytes. 
> 
> Tegra only treats negative returns as errors and keeps the reserved
> IOVA, which scanout then faults on.
> 
> This page-side use predates the series, so the fault is not itself a v2
> regression. Is dma_buf_sgt_attach() valid for this call site, or does Tegra
> need a page/physical mapping type first?

Sharing page/physical to be used with the IOMMU functions through DMA-buf is an absolutely hard NAK from my side.

We still need to figure out how to do this between KVM, IOMMUFD and virtio so that it is limited to only those three.

Regards,
Christian.

> 
> Karl