dma-buf sg mangling

[Christian König]

Am 10.05.24 um 18:34 schrieb Zack Rusin:
> Hey,
>
> so this is a bit of a silly problem but I'd still like to solve it
> properly. The tldr is that virtualized drivers abuse
> drm_driver::gem_prime_import_sg_table (at least vmwgfx and xen do,
> virtgpu and xen punt on it) because there doesn't seem to be a
> universally supported way of converting the sg_table back to a list of
> pages without some form of gart to do it.

Well the whole point is that you should never touch the pages in the 
sg_table in the first place.

The long term plan is actually to completely remove the pages from that 
interface.

> drm_prime_sg_to_page_array is deprecated (for all the right reasons on
> actual hardware) but in our cooky virtualized world we don't have
> gart's so what are we supposed to do with the dma_addr_t from the
> imported sg_table? What makes it worse (and definitely breaks xen) is
> that with CONFIG_DMABUF_DEBUG the sg page_link is mangled via
> mangle_sg_table so drm_prime_sg_to_page_array won't even work.

XEN and KVM were actually adjusted to not touch the struct pages any more.

I'm not sure if that work is already upstream or not but I had to 
explain it over and over again why their approach doesn't work.

> The reason why I'm saying it's a bit of a silly problem is that afaik
> currently it only affects IGT testing with vgem (because the rest of
> external gem objects will be from the virtualized gpu itself which is
> different). But do you have any ideas on what we'd like to do with
> this long term? i.e. we have a virtualized gpus without iommu, we have
> sg_table with some memory and we'd like to import it. Do we just
> assume that the sg_table on those configs will always reference cpu
> accessible memory (i.e. if it's external it only comes through
> drm_gem_shmem_object) and just do some horrific abomination like:
> for (i = 0; i < bo->ttm->num_pages; ++i) {
>      phys_addr_t pa = dma_to_phys(vmw->drm.dev, bo->ttm->dma_address[i]);
>      pages[i] = pfn_to_page(PHYS_PFN(pa));
> }
> or add a "i know this is cpu accessible, please demangle" flag to
> drm_prime_sg_to_page_array or try to have some kind of more permanent
> solution?

Well there is no solution for that. Accessing the underlying struct page 
through the sg_table is illegal in the first place.

So the question is not how to access the struct page, but rather why do 
you want to do this?

Regards,
Christian.

>
> z