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. >> Leon, it would be great if You could also prepare an incremental patch >> adding map_phys callback to the dma_maps_ops, so the individual >> arch-specific dma-mapping providers can be then converted (or simplified >> in many cases) too. > Sure, will do. Thanks! Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
