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.
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
