Messages in this thread | | | Subject | Re: [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support | From | Christian König <> | Date | Fri, 10 Dec 2021 14:28:50 +0100 |
| |
Am 10.12.21 um 14:26 schrieb Jason Gunthorpe: > 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@ziepe.ca>: >>>>> 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. > > ??
Well, yes that can go boom pretty quickly.
Not sure what they want to use this for.
Christian.
> > Jason
| |