> -----Original Message----- > From: Daniel Vetter <daniel@xxxxxxxx> > Sent: Tuesday, November 03, 2020 12:43 PM > To: Xiong, Jianxin <jianxin.xiong@xxxxxxxxx> > Cc: Jason Gunthorpe <jgg@xxxxxxxx>; linux-rdma <linux-rdma@xxxxxxxxxxxxxxx>; dri-devel <dri-devel@xxxxxxxxxxxxxxxxxxxxx>; Leon > Romanovsky <leon@xxxxxxxxxx>; Doug Ledford <dledford@xxxxxxxxxx>; Vetter, Daniel <daniel.vetter@xxxxxxxxx>; Christian Koenig > <christian.koenig@xxxxxxx> > Subject: Re: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as user memory region > > On Tue, Nov 3, 2020 at 6:36 PM Xiong, Jianxin <jianxin.xiong@xxxxxxxxx> wrote: > > > > > > > -----Original Message----- > > > From: Daniel Vetter <daniel@xxxxxxxx> > > > Sent: Friday, October 23, 2020 6:45 PM > > > To: Jason Gunthorpe <jgg@xxxxxxxx> > > > Cc: Xiong, Jianxin <jianxin.xiong@xxxxxxxxx>; linux-rdma > > > <linux-rdma@xxxxxxxxxxxxxxx>; dri-devel > > > <dri-devel@xxxxxxxxxxxxxxxxxxxxx>; Leon Romanovsky > > > <leon@xxxxxxxxxx>; Doug Ledford <dledford@xxxxxxxxxx>; Vetter, > > > Daniel <daniel.vetter@xxxxxxxxx>; Christian Koenig > > > <christian.koenig@xxxxxxx> > > > Subject: Re: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as > > > user memory region > > > > > > > > > + > > > > > > +#ifdef CONFIG_DMA_VIRT_OPS > > > > > > + if (device->dma_device->dma_ops == &dma_virt_ops) > > > > > > + return ERR_PTR(-EINVAL); #endif > > > > > > > > > > Maybe I'm confused, but should we have this check in > > > > > dma_buf_attach, or at least in dma_buf_dynamic_attach? The > > > > > p2pdma functions use that too, and I can't imagine how zerocopy > > > > > should work (which is like the entire point of > > > > > dma-buf) when we have dma_virt_ops. > > > > > > > > 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. > > > > > > > > But maybe this is just a 'drivers are using it wrong' if they call > > > > this function and expect struct pages.. > > > > > > > > The check in the p2p stuff was done to avoid this too, but it was > > > > on a different flow. > > > > > > Yeah definitely don't call dma_buf_map_attachment and expect a page > > > back. In practice you'll get a page back fairly often, but I don't think we want to bake that in, maybe we eventually get to non-hacky > dma_addr_t only sgl. > > > > > > What I'm wondering is whether dma_buf_attach shouldn't reject such devices directly, instead of each importer having to do that. > > > > Come back here to see if consensus can be reached on who should do the > > check. My thinking is that it could be over restrictive for > > dma_buf_attach to always reject dma_virt_ops. According to dma-buf > > documentation the back storage would be moved to system area upon > > mapping unless p2p is requested and can be supported by the exporter. The sg_list for system memory would have struct page present. > > So I'm not clear on what this dma_virt_ops stuff is for, but if it's an entirely virtual device with cpu access, then you shouldn't do > dma_buf_map_attachment, and then peek at the struct page in the sgl. This is the key, thanks for pointing that out. I was assuming the importer could use the struct page if it exists. > Instead you need to use dma_buf_vmap/vunmap and dma_buf_begin/end_cpu_access. Otherwise the coherency managed is all potentially > busted. Also note that cpu access from the kernel to dma-buf is a rather niche feature (only some usb device drivers use it), so expect warts. > dma_virt_ops is a set of dma mapping operations that map page/sgl to virtual addresses instead of dma addresses. Drivers that use dma_virt_ops would use the mapping result for cpu access (to emulate DMA) instead of real DMA, and thus the dma mapping returned from dma-buf is not compatible with the expectation of such drivers. If these drivers are not allowed to peek into the struct page of the sgl, they have no way to correctly use the sgl. In this sense I agree that drivers that use dma_virt_ops should not call dma_buf_attach(). They should use dma_buf_vmap() et al to get cpu access. > If this is the case, then I think dma_buf_attach should check for this and reject such imports, since that's an importer bug. So here we go. I will move the check to dma_buf_dynamic_attach (and dma_buf_attach is a wrapper over that). > > If it's otoh something rdma specific, then I guess rdma checking for this is ok. > > As a third option, if it's something about the connectivity between the importing and exporting device, then this should be checked in the > ->attach callback the exporter can provide, like the p2p check. The > idea here is that for device specific remapping units (mostly found ond SoC, and not something like a standard iommu managed by the dma- > api), some of which can even do funny stuff like rotation of 2d images, can be access by some, but not other. And only the exporter is > aware of these restrictions. > > Now I dunno which case this one here is. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
