On Tue, Jul 08, 2025 at 01:45:20PM +0200, Marek Szyprowski wrote: > On 08.07.2025 13:00, Leon Romanovsky wrote: > > On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote: > >> On 30.06.2025 15:38, Christoph Hellwig wrote: > >>> On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote: > >>>>> Thanks for this rework! I assume that the next step is to add map_phys > >>>>> callback also to the dma_map_ops and teach various dma-mapping providers > >>>>> to use it to avoid more phys-to-page-to-phys conversions. > >>>> Probably Christoph will say yes, however I personally don't see any > >>>> benefit in this. Maybe I wrong here, but all existing .map_page() > >>>> implementation platforms don't support p2p anyway. They won't benefit > >>>> from this such conversion. > >>> I think that conversion should eventually happen, and rather sooner than > >>> later. > >> Agreed. > >> > >> Applied patches 1-7 to my dma-mapping-next branch. Let me know if one > >> needs a stable branch with it. > > Thanks a lot, I don't think that stable branch is needed. Realistically > > speaking, my VFIO DMA work won't be merged this cycle, We are in -rc5, > > it is complete rewrite from RFC version and touches pci-p2p code (to > > remove dependency on struct page) in addition to VFIO, so it will take > > time. > > > > Regarding, last patch (hmm), it will be great if you can take it. > > We didn't touch anything in hmm.c this cycle and have no plans to send PR. > > It can safely go through your tree. > > Okay, then I would like to get an explicit ack from Jérôme for this.
Jerome is not active in HMM world for a long time already. HMM tree is managed by us (RDMA) https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=hmm ➜ kernel git:(m/dmabuf-vfio) git log --merges mm/hmm.c ... Pull HMM updates from Jason Gunthorpe: ... https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=58ba80c4740212c29a1cf9b48f588e60a7612209 +hmm git git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git#hmm We just never bothered to reflect current situation in MAINTAINERS file. Thanks
