Hi Vivek,
Am 12.02.21 um 09:36 schrieb Kasireddy, Vivek:
Hi Christian,
Hi Vivek,
[Kasireddy, Vivek] What if I do mmap() on the fd followed by mlock()
or mmap() followed by get_user_pages()? If it still fails, would
ioremapping the device memory and poking at the backing storage be an
option? Or, if I bind the passthrough'd GPU device to vfio-pci and tap
into the memory region associated with the device memory, can it be made to work?
get_user_pages() is not allowed on mmaped DMA-bufs in the first place.
Daniel is currently adding code to make sure that this is never ever used.
And, I noticed that for PFNs that do not have valid struct page
associated with it, KVM does a memremap() to access/map them. Is this an option?
No, even for system memory which has a valid struct page touching it when it is part of a
DMA-buf is illegal since the reference count and mapping fields in struct page might be
used for something different.
Keep in mind that struct page is a heavily overloaded structure for different use cases. You
can't just use it for a different use case than what the owner of the page has intended it.
[Kasireddy, Vivek] What is your recommended/acceptable way for doing what I am trying to
do?
I'm not an expert on virtualisation, but Gerd seems to have a couple of
ideas of how to get this working.
In general I think it is pretty much impossible to export stuff from the
guest to the host by DMA-buf.
This is because of the fundamental concept of DMA-buf that the exporter
needs to setup mappings (both CPU page tables as well as stuff like
IOMMU). When the guest exports something it would mean that you give the
guest control over the IOMMU and/or host page tables. And that is not
something you can do as far as I can see.
You can only export stuff the other way around so that the host is
providing the memory and the guest is consuming it. If I understand it
correctly that's exactly what Gerd is suggesting here.
Regards,
Christian.
Thanks,
Vivek
Regards,
Christian.
Thanks,
Vivek
take care,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
