Re: [PATCH] drm/ttm: use dma_alloc_pages for the page pool

From: "Christian König" <christian.koenig@amd.com>
To: Christoph Hellwig <hch@lst.de>
Cc: amd-gfx@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>,
	Roland Scheidegger <sroland@vmware.com>,
	dri-devel@lists.freedesktop.org,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	virtualization@lists.linux-foundation.org,
	iommu@lists.linux-foundation.org, Huang Rui <ray.huang@amd.com>,
	VMware Graphics <linux-graphics-maintainer@vmware.com>,
	Ben Skeggs <bskeggs@redhat.com>, Daniel Vetter <daniel@ffwll.ch>,
	nouveau@lists.freedesktop.org,
	Alex Deucher <alexander.deucher@amd.com>,
	Dave Airlie <airlied@redhat.com>,
	spice-devel@lists.freedesktop.org, Zack Rusin <zackr@vmware.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PATCH] drm/ttm: use dma_alloc_pages for the page pool
Date: Tue, 11 May 2021 10:57:17 +0200	[thread overview]
Message-ID: <2af7d79c-4a9c-1b35-2a5a-c86e3a8df8d0@amd.com> (raw)
In-Reply-To: <20210511085011.GA14477@lst.de>

Am 11.05.21 um 10:50 schrieb Christoph Hellwig:
> On Tue, May 11, 2021 at 09:35:20AM +0200, Christian König wrote:
>> We certainly going to need the drm_need_swiotlb() for userptr support
>> (unless we add some approach for drivers to opt out of swiotlb).
> swiotlb use is driven by three things:
>
>   1) addressing limitations of the device
>   2) addressing limitations of the interconnect
>   3) virtualiztion modes that require it
>
> not sure how the driver could opt out.  What is the problem with userptr
> support?

userptr grabs the pages for a certain virtual memory address, map them 
in the IOMMU and then expect the device to have coherent access to it.

When SWIOTLB is in place we need to fail that gracefully, try to not 
expose the functionality or even don't load the driver in the first place.

>> Then while I really want to get rid of GFP_DMA32 as well I'm not 100% sure
>> if we can handle this without the flag.
> Note that this is still using GFP_DMA32 underneath where required,
> just in a layer that can decide that ѕensibly.

Completely agree, I'm just not sure if every driver gets its coherent 
mask right under every condition.

Might be a good idea to double check the coherent mask in nouveau/radeon 
when they want to use GFP_DMA32.

>> And last we need something better to store the DMA address and order than
>> allocating a separate memory object for each page.
> Yeah.  If you use __GFP_COMP for the allocations we can find the order
> from the page itself, which might be useful.  For 64-bit platforms
> the dma address could be store in page->private, or depending on how
> the page gets used the dma_addr field in struct page that overloads
> the lru field and is used by the networking page pool could be used.

Yes, I've considered that as well. But I do need the list_head and dma 
address at the same time.

> Maybe we could even have a common page pool between net and drm, but
> I don't want to go there myself, not being an expert on either subsystem.

I had the same thought and also the same concerns, can't judge what the 
net code is doing with this.

Regards,
Christian.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu