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
