On Fri, Dec 10, 2021 at 09:26:56AM -0400, Jason Gunthorpe wrote: > On Fri, Dec 10, 2021 at 01:47:37PM +0100, Christian König wrote: > > Am 10.12.21 um 13:42 schrieb Jason Gunthorpe: > > > On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote: > > > > Hi Jason, > > > > Thank you for replying. > > > > > > > > 2021年12月8日(水) 2:14 Jason Gunthorpe <jgg@xxxxxxxx>: > > > > > On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: > > > > > > Hi maintainers, > > > > > > > > > > > > Could you please review this patch series? > > > > > Why is it RFC? > > > > > > > > > > I'm confused why this is useful? > > > > > > > > > > This can't do copy from MMIO memory, so it shouldn't be compatible > > > > > with things like Gaudi - does something prevent this? > > > > I think if an export of the dma-buf supports vmap, CPU is able to access the > > > > mmio memory. > > > > > > > > Is it wrong? If this is wrong, there is no advantages this changes.. > > > I don't know what the dmabuf folks did, but yes, it is wrong. > > > > > > IOMEM must be touched using only special accessors, some platforms > > > crash if you don't do this. Even x86 will crash if you touch it with > > > something like an XMM optimized memcpy. > > > > > > Christian? If the vmap succeeds what rules must the caller use to > > > access the memory? > > > > See dma-buf-map.h and especially struct dma_buf_map. > > > > MMIO memory is perfectly supported here and actually the most common case. > > Okay that looks sane, but this rxe RFC seems to ignore this > completely. It stuffs the vaddr directly into a umem which goes to all > manner of places in the driver. > > ?? dma_buf_map is fairly new and we haven't rolled it out consistently yet. In the past 10 years we simply yolo'd this :-) Just an explanation, not an excuse for new code to not use dma_buf_map consistently now that we fixed this mistake. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
