> -----Original Message----- > From: Christoph Hellwig <h...@infradead.org> > Sent: Tuesday, October 27, 2020 1:08 AM > To: Jason Gunthorpe <j...@ziepe.ca> > Cc: Christoph Hellwig <h...@infradead.org>; Daniel Vetter <dan...@ffwll.ch>; > Xiong, Jianxin <jianxin.xi...@intel.com>; linux- > r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Leon Romanovsky > <l...@kernel.org>; Doug Ledford <dledf...@redhat.com>; > Vetter, Daniel <daniel.vet...@intel.com>; Christian Koenig > <christian.koe...@amd.com> > Subject: Re: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as user > memory region > > On Mon, Oct 26, 2020 at 09:26:37AM -0300, Jason Gunthorpe wrote: > > On Sat, Oct 24, 2020 at 08:48:07AM +0100, Christoph Hellwig wrote: > > > On Fri, Oct 23, 2020 at 03:20:05PM -0300, Jason Gunthorpe wrote: > > > > The problem is we have RDMA drivers that assume SGL's have a valid > > > > struct page, and these hacky/wrong P2P sgls that DMABUF creates > > > > cannot be passed into those drivers. > > > > > > RDMA drivers do not assume scatterlist have a valid struct page, > > > scatterlists are defined to have a valid struct page. Any > > > scatterlist without a struct page is completely buggy. > > > > It is not just having the struct page, it needs to be a CPU accessible > > one for memcpy/etc. They aren't correct with the > > MEMORY_DEVICE_PCI_P2PDMA SGLs either. > > Exactly.
In the function ib_umem_dmabuf_sgt_slice() (part of this patch) we could generate a dma address array instead of filling the scatterlist 'umem->sg_head'. The array would be handled similar to 'umem_odp->dma_list'. With such change, the RDMA drivers wouldn't see incorrectly formed scatterlist. The check for dma_virt_ops here wouldn't be needed either. Would such proposal address the concern here? -Jianxin _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
