drivers/dma-buf/dma-buf-mapping.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-)
From: David Hu <xuehaohu@google.com> This series address two related issues in scatter-gather mapping, specifically for the MMIO based dma-buf mapping. The fixes ensure sgt mapping is correct, and proper for large MMIO regions. Patch 1 fixes a silent integer overflow for mapping length exceeding 4G (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for phys vec to sgt) https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ Patch 2 Splits sgl by largest page aligned chunk (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ Changes in v8: - Combined the two patches into one unified series to avoid merge conflicts. - Collected Reviewed-by tag from Leon Romanovsky for Patch 2. David Hu (2): dma-buf: Fix silent overflow for phys vec to sgt dma-buf: Split sgl by largest page-aligned chunk drivers/dma-buf/dma-buf-mapping.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-) -- 2.55.0.897.gb25b4bd76c-goog
On 9/1/26 19:08, David Hu wrote: > From: David Hu <xuehaohu@google.com> > > This series address two related issues in scatter-gather mapping, > specifically for the MMIO based dma-buf mapping. The fixes ensure > sgt mapping is correct, and proper for large MMIO regions. > > Patch 1 fixes a silent integer overflow for mapping length exceeding 4G > (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for > phys vec to sgt) > https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ > > Patch 2 Splits sgl by largest page aligned chunk > (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) > https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. I'm going to push those fixes to drm-misc-next now, but when there are more issues like that will mark the code as abandoned and not maintained. Regards, Christian. > > Changes in v8: > - Combined the two patches into one unified series to avoid merge > conflicts. > - Collected Reviewed-by tag from Leon Romanovsky for Patch 2. > > David Hu (2): > dma-buf: Fix silent overflow for phys vec to sgt > dma-buf: Split sgl by largest page-aligned chunk > > drivers/dma-buf/dma-buf-mapping.c | 31 +++++++++++++++++++++---------- > 1 file changed, 21 insertions(+), 10 deletions(-) > > -- > 2.55.0.897.gb25b4bd76c-goog >
On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote: > On 9/1/26 19:08, David Hu wrote: > > From: David Hu <xuehaohu@google.com> > > > > This series address two related issues in scatter-gather mapping, > > specifically for the MMIO based dma-buf mapping. The fixes ensure > > sgt mapping is correct, and proper for large MMIO regions. > > > > Patch 1 fixes a silent integer overflow for mapping length exceeding 4G > > (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for > > phys vec to sgt) > > https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ > > > > Patch 2 Splits sgl by largest page aligned chunk > > (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) > > https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ > > *sigh* such issues are exactly the reason why I didn't wanted the > *dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. So you'd rather have these tricky bugs in every driver using dmabuf? The scatterlist construction in most of the DRM drivers is not in good shape. They should be converting to call these APIs so they can do it properly. > I'm going to push those fixes to drm-misc-next now, but when there > are more issues like that will mark the code as abandoned and not > maintained. Code that is getting bugs fix is not abandoned, please be reasonable. Jason
On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote: > On 9/1/26 19:08, David Hu wrote: > > From: David Hu <xuehaohu@google.com> > > > > This series address two related issues in scatter-gather mapping, > > specifically for the MMIO based dma-buf mapping. The fixes ensure > > sgt mapping is correct, and proper for large MMIO regions. > > > > Patch 1 fixes a silent integer overflow for mapping length exceeding 4G > > (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for > > phys vec to sgt) > > https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ > > > > Patch 2 Splits sgl by largest page aligned chunk > > (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) > > https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ > > *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. And this is why so many in the kernel community want to get rid of SG lists. It would be great if DMA-BUF could also eliminate the need to convert to an SGL, like Jason proposed. The DMA layer no longer needs SGL. These bugs belong to the DMA-BUF layer, which is the one that depends on it. Thanks
On 9/2/26 09:39, Leon Romanovsky wrote: > On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote: >> On 9/1/26 19:08, David Hu wrote: >>> From: David Hu <xuehaohu@google.com> >>> >>> This series address two related issues in scatter-gather mapping, >>> specifically for the MMIO based dma-buf mapping. The fixes ensure >>> sgt mapping is correct, and proper for large MMIO regions. >>> >>> Patch 1 fixes a silent integer overflow for mapping length exceeding 4G >>> (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for >>> phys vec to sgt) >>> https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ >>> >>> Patch 2 Splits sgl by largest page aligned chunk >>> (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) >>> https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ >> >> *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. > > And this is why so many in the kernel community want to get rid of SG > lists. It would be great if DMA-BUF could also eliminate the need to > convert to an SGL, like Jason proposed. > > The DMA layer no longer needs SGL. These bugs belong to the DMA-BUF layer, > which is the one that depends on it. I'm all fine using an array/xarray of dma_addr_t in DMA-buf, just phys_vec is a clear no-go. Regards, Christian. > > Thanks
On Wed, Sep 02, 2026 at 09:56:06AM +0200, Christian König wrote: > On 9/2/26 09:39, Leon Romanovsky wrote: > > On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote: > >> On 9/1/26 19:08, David Hu wrote: > >>> From: David Hu <xuehaohu@google.com> > >>> > >>> This series address two related issues in scatter-gather mapping, > >>> specifically for the MMIO based dma-buf mapping. The fixes ensure > >>> sgt mapping is correct, and proper for large MMIO regions. > >>> > >>> Patch 1 fixes a silent integer overflow for mapping length exceeding 4G > >>> (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for > >>> phys vec to sgt) > >>> https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ > >>> > >>> Patch 2 Splits sgl by largest page aligned chunk > >>> (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) > >>> https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ > >> > >> *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. > > > > And this is why so many in the kernel community want to get rid of SG > > lists. It would be great if DMA-BUF could also eliminate the need to > > convert to an SGL, like Jason proposed. > > > > The DMA layer no longer needs SGL. These bugs belong to the DMA-BUF layer, > > which is the one that depends on it. > > I'm all fine using an array/xarray of dma_addr_t in DMA-buf, just phys_vec is a clear no-go. You are proposing the same thing as an SGL, just in a different format. It does not address the issue that dma_addr_t is expected to hold a DMA address, while that is not always the case. For example, in the P2P case, the addresses are not DMA addresses. Jason's proposal: https://lore.kernel.org/all/0-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@nvidia.com/ Thanks > > Regards, > Christian. > > > > > Thanks > >
On 9/2/26 10:32, Leon Romanovsky wrote: > On Wed, Sep 02, 2026 at 09:56:06AM +0200, Christian König wrote: >> On 9/2/26 09:39, Leon Romanovsky wrote: >>> On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote: >>>> On 9/1/26 19:08, David Hu wrote: >>>>> From: David Hu <xuehaohu@google.com> >>>>> >>>>> This series address two related issues in scatter-gather mapping, >>>>> specifically for the MMIO based dma-buf mapping. The fixes ensure >>>>> sgt mapping is correct, and proper for large MMIO regions. >>>>> >>>>> Patch 1 fixes a silent integer overflow for mapping length exceeding 4G >>>>> (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for >>>>> phys vec to sgt) >>>>> https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ >>>>> >>>>> Patch 2 Splits sgl by largest page aligned chunk >>>>> (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) >>>>> https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ >>>> >>>> *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. >>> >>> And this is why so many in the kernel community want to get rid of SG >>> lists. It would be great if DMA-BUF could also eliminate the need to >>> convert to an SGL, like Jason proposed. >>> >>> The DMA layer no longer needs SGL. These bugs belong to the DMA-BUF layer, >>> which is the one that depends on it. >> >> I'm all fine using an array/xarray of dma_addr_t in DMA-buf, just phys_vec is a clear no-go. > > You are proposing the same thing as an SGL, just in a different format. Yes, because that is the right thing todo as far as I can see. > It does not address the issue that dma_addr_t is expected to hold a DMA > address, while that is not always the case. For example, in the P2P case, > the addresses are not DMA addresses. Yes they are. They must be DMA addresses because that is the only thing the importer needs to do it's DMA. It can be that those are DMA addresses on private interconnects between devices, but it should *never* be a phys_addr_t because that is limited to the address space the CPU can see. > Jason's proposal: > https://lore.kernel.org/all/0-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@nvidia.com/ Yeah, I have commented quite a bit on that. Regards, Christian. > > Thanks > >> >> Regards, >> Christian. >> >>> >>> Thanks >> >>
On Wed, Sep 02, 2026 at 10:44:59AM +0200, Christian König wrote: > On 9/2/26 10:32, Leon Romanovsky wrote: > > On Wed, Sep 02, 2026 at 09:56:06AM +0200, Christian König wrote: > >> On 9/2/26 09:39, Leon Romanovsky wrote: > >>> On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote: > >>>> On 9/1/26 19:08, David Hu wrote: > >>>>> From: David Hu <xuehaohu@google.com> > >>>>> > >>>>> This series address two related issues in scatter-gather mapping, > >>>>> specifically for the MMIO based dma-buf mapping. The fixes ensure > >>>>> sgt mapping is correct, and proper for large MMIO regions. > >>>>> > >>>>> Patch 1 fixes a silent integer overflow for mapping length exceeding 4G > >>>>> (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for > >>>>> phys vec to sgt) > >>>>> https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ > >>>>> > >>>>> Patch 2 Splits sgl by largest page aligned chunk > >>>>> (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) > >>>>> https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ > >>>> > >>>> *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. > >>> > >>> And this is why so many in the kernel community want to get rid of SG > >>> lists. It would be great if DMA-BUF could also eliminate the need to > >>> convert to an SGL, like Jason proposed. > >>> > >>> The DMA layer no longer needs SGL. These bugs belong to the DMA-BUF layer, > >>> which is the one that depends on it. > >> > >> I'm all fine using an array/xarray of dma_addr_t in DMA-buf, just phys_vec is a clear no-go. > > > > You are proposing the same thing as an SGL, just in a different format. > > Yes, because that is the right thing todo as far as I can see. > > > It does not address the issue that dma_addr_t is expected to hold a DMA > > address, while that is not always the case. For example, in the P2P case, > > the addresses are not DMA addresses. > > Yes they are. They must be DMA addresses because that is the only thing the importer needs to do it's DMA. They can perform DMA, but that still does not make them suitable for the dma_addr_t type. For the PCI_P2PDMA_MAP_BUS_ADDR flow, these addresses follow completely different rules: they are not unmapped, require no cache synchronization, are valid only for peer access, and require separate error handling. All of this information is lost if only the dma_addr_t is stored. > > It can be that those are DMA addresses on private interconnects between devices, but it should *never* be a phys_addr_t because that is limited to the address space the CPU can see. > > > Jason's proposal: > > https://lore.kernel.org/all/0-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@nvidia.com/ > > Yeah, I have commented quite a bit on that. Right, I posted it for reference. Thanks > > Regards, > Christian. > > > > > Thanks > > > >> > >> Regards, > >> Christian. > >> > >>> > >>> Thanks > >> > >> > >
On 9/2/26 11:53, Leon Romanovsky wrote: > On Wed, Sep 02, 2026 at 10:44:59AM +0200, Christian König wrote: >> On 9/2/26 10:32, Leon Romanovsky wrote: >>> On Wed, Sep 02, 2026 at 09:56:06AM +0200, Christian König wrote: >>>> On 9/2/26 09:39, Leon Romanovsky wrote: >>>>> On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote: >>>>>> On 9/1/26 19:08, David Hu wrote: >>>>>>> From: David Hu <xuehaohu@google.com> >>>>>>> >>>>>>> This series address two related issues in scatter-gather mapping, >>>>>>> specifically for the MMIO based dma-buf mapping. The fixes ensure >>>>>>> sgt mapping is correct, and proper for large MMIO regions. >>>>>>> >>>>>>> Patch 1 fixes a silent integer overflow for mapping length exceeding 4G >>>>>>> (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for >>>>>>> phys vec to sgt) >>>>>>> https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ >>>>>>> >>>>>>> Patch 2 Splits sgl by largest page aligned chunk >>>>>>> (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) >>>>>>> https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ >>>>>> >>>>>> *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. >>>>> >>>>> And this is why so many in the kernel community want to get rid of SG >>>>> lists. It would be great if DMA-BUF could also eliminate the need to >>>>> convert to an SGL, like Jason proposed. >>>>> >>>>> The DMA layer no longer needs SGL. These bugs belong to the DMA-BUF layer, >>>>> which is the one that depends on it. >>>> >>>> I'm all fine using an array/xarray of dma_addr_t in DMA-buf, just phys_vec is a clear no-go. >>> >>> You are proposing the same thing as an SGL, just in a different format. >> >> Yes, because that is the right thing todo as far as I can see. >> >>> It does not address the issue that dma_addr_t is expected to hold a DMA >>> address, while that is not always the case. For example, in the P2P case, >>> the addresses are not DMA addresses. >> >> Yes they are. They must be DMA addresses because that is the only thing the importer needs to do it's DMA. > > They can perform DMA, but that still does not make them suitable for the > dma_addr_t type. For the PCI_P2PDMA_MAP_BUS_ADDR flow, these addresses > follow completely different rules: they are not unmapped, require no cache > synchronization, are valid only for peer access, and require separate error > handling. The PCI_P2PDMA_MAP_BUS_ADDR is not supported by DMA-buf and as far as I can see is a complete dead end. > All of this information is lost if only the dma_addr_t is stored. Yes and that is fully intentional. DMA-buf handles that cleanly on the buffer object level and not like PCI_P2PDMA_MAP_BUS_ADDR as a completely broken design on a per address/page basis. Technical background is that the PCI_P2PDMA_MAP_BUS_ADDR approach can only be handled by a very very small subset of HW. Regards, Christian. > >> >> It can be that those are DMA addresses on private interconnects between devices, but it should *never* be a phys_addr_t because that is limited to the address space the CPU can see. >> >>> Jason's proposal: >>> https://lore.kernel.org/all/0-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@nvidia.com/ >> >> Yeah, I have commented quite a bit on that. > > Right, I posted it for reference. > > Thanks > >> >> Regards, >> Christian. >> >>> >>> Thanks >>> >>>> >>>> Regards, >>>> Christian. >>>> >>>>> >>>>> Thanks >>>> >>>> >> >>
On Wed, Sep 02, 2026 at 12:00:25PM +0200, Christian König wrote: > On 9/2/26 11:53, Leon Romanovsky wrote: > > On Wed, Sep 02, 2026 at 10:44:59AM +0200, Christian König wrote: > >> On 9/2/26 10:32, Leon Romanovsky wrote: > >>> On Wed, Sep 02, 2026 at 09:56:06AM +0200, Christian König wrote: > >>>> On 9/2/26 09:39, Leon Romanovsky wrote: > >>>>> On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote: > >>>>>> On 9/1/26 19:08, David Hu wrote: > >>>>>>> From: David Hu <xuehaohu@google.com> > >>>>>>> > >>>>>>> This series address two related issues in scatter-gather mapping, > >>>>>>> specifically for the MMIO based dma-buf mapping. The fixes ensure > >>>>>>> sgt mapping is correct, and proper for large MMIO regions. > >>>>>>> > >>>>>>> Patch 1 fixes a silent integer overflow for mapping length exceeding 4G > >>>>>>> (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for > >>>>>>> phys vec to sgt) > >>>>>>> https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ > >>>>>>> > >>>>>>> Patch 2 Splits sgl by largest page aligned chunk > >>>>>>> (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) > >>>>>>> https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ > >>>>>> > >>>>>> *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. > >>>>> > >>>>> And this is why so many in the kernel community want to get rid of SG > >>>>> lists. It would be great if DMA-BUF could also eliminate the need to > >>>>> convert to an SGL, like Jason proposed. > >>>>> > >>>>> The DMA layer no longer needs SGL. These bugs belong to the DMA-BUF layer, > >>>>> which is the one that depends on it. > >>>> > >>>> I'm all fine using an array/xarray of dma_addr_t in DMA-buf, just phys_vec is a clear no-go. > >>> > >>> You are proposing the same thing as an SGL, just in a different format. > >> > >> Yes, because that is the right thing todo as far as I can see. > >> > >>> It does not address the issue that dma_addr_t is expected to hold a DMA > >>> address, while that is not always the case. For example, in the P2P case, > >>> the addresses are not DMA addresses. > >> > >> Yes they are. They must be DMA addresses because that is the only thing the importer needs to do it's DMA. > > > > They can perform DMA, but that still does not make them suitable for the > > dma_addr_t type. For the PCI_P2PDMA_MAP_BUS_ADDR flow, these addresses > > follow completely different rules: they are not unmapped, require no cache > > synchronization, are valid only for peer access, and require separate error > > handling. > > The PCI_P2PDMA_MAP_BUS_ADDR is not supported by DMA-buf and as far as I can see is a complete dead end. > > > All of this information is lost if only the dma_addr_t is stored. > > Yes and that is fully intentional. > > DMA-buf handles that cleanly on the buffer object level and not like PCI_P2PDMA_MAP_BUS_ADDR as a completely broken design on a per address/page basis. > > Technical background is that the PCI_P2PDMA_MAP_BUS_ADDR approach can only be handled by a very very small subset of HW. > With the rise of accelerators, the P2PDMA_MAP_BUS_ADDR is going to be increasingly more common where accelerators directly transfer data to NICs, storage devices, other accelerators etc. With VFIO gaining a DMABUF exporter the use has already spread to RDMA & NVMe devices (w/ SPDK). In fact, we found these bugs while trying to map large BAR regions for RDMA. Thus, it would be great if we could find alignment here. AFAICT, I foresee the use of dmabufs to only increase for PCI_P2PDMA_MAP_BUS_ADDR. IIRC when the network stack moved to net_iovs to support dmabufs, the SGL became a primary concern and partly the reason why we have "unreadable" skbs for memory we can indeed access if mapped correctly. Thanks, Praan
On Wed, Sep 02, 2026 at 12:00:25PM +0200, Christian König wrote: > On 9/2/26 11:53, Leon Romanovsky wrote: > > On Wed, Sep 02, 2026 at 10:44:59AM +0200, Christian König wrote: > >> On 9/2/26 10:32, Leon Romanovsky wrote: > >>> On Wed, Sep 02, 2026 at 09:56:06AM +0200, Christian König wrote: > >>>> On 9/2/26 09:39, Leon Romanovsky wrote: > >>>>> On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote: > >>>>>> On 9/1/26 19:08, David Hu wrote: > >>>>>>> From: David Hu <xuehaohu@google.com> > >>>>>>> > >>>>>>> This series address two related issues in scatter-gather mapping, > >>>>>>> specifically for the MMIO based dma-buf mapping. The fixes ensure > >>>>>>> sgt mapping is correct, and proper for large MMIO regions. > >>>>>>> > >>>>>>> Patch 1 fixes a silent integer overflow for mapping length exceeding 4G > >>>>>>> (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for > >>>>>>> phys vec to sgt) > >>>>>>> https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/ > >>>>>>> > >>>>>>> Patch 2 Splits sgl by largest page aligned chunk > >>>>>>> (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk) > >>>>>>> https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/ > >>>>>> > >>>>>> *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here. > >>>>> > >>>>> And this is why so many in the kernel community want to get rid of SG > >>>>> lists. It would be great if DMA-BUF could also eliminate the need to > >>>>> convert to an SGL, like Jason proposed. > >>>>> > >>>>> The DMA layer no longer needs SGL. These bugs belong to the DMA-BUF layer, > >>>>> which is the one that depends on it. > >>>> > >>>> I'm all fine using an array/xarray of dma_addr_t in DMA-buf, just phys_vec is a clear no-go. > >>> > >>> You are proposing the same thing as an SGL, just in a different format. > >> > >> Yes, because that is the right thing todo as far as I can see. > >> > >>> It does not address the issue that dma_addr_t is expected to hold a DMA > >>> address, while that is not always the case. For example, in the P2P case, > >>> the addresses are not DMA addresses. > >> > >> Yes they are. They must be DMA addresses because that is the only thing the importer needs to do it's DMA. > > > > They can perform DMA, but that still does not make them suitable for the > > dma_addr_t type. For the PCI_P2PDMA_MAP_BUS_ADDR flow, these addresses > > follow completely different rules: they are not unmapped, require no cache > > synchronization, are valid only for peer access, and require separate error > > handling. > > The PCI_P2PDMA_MAP_BUS_ADDR is not supported by DMA-buf and as far as I can see is a complete dead end. Maybe you mean DRM, but VFIO works perfectly with PCI_P2PDMA_MAP_BUS_ADDR flow in DMA-buf. What am I missing? Thanks
On 9/2/26 12:59, Leon Romanovsky wrote: ... >> The PCI_P2PDMA_MAP_BUS_ADDR is not supported by DMA-buf and as far as I can see is a complete dead end. > > Maybe you mean DRM, but VFIO works perfectly with PCI_P2PDMA_MAP_BUS_ADDR flow in DMA-buf. > What am I missing? Well not quite. The approach PCI_P2PDMA_MAP_BUS_ADDR takes is fundamentally tied to only map a physical CPU address into a PCI address and doesn't take into account that in a lot of configurations the CPU can't access all resources. So when VFIO uses PCI_P2PDMA_MAP_BUS_ADDR it only works for a small subset of the use cases DMA-buf supports, but yeah as always in DMA-buf pretty much everything is optional. Regards, Christian. > > Thanks
On Wed, Sep 02, 2026 at 03:34:18PM +0200, Christian König wrote: > On 9/2/26 12:59, Leon Romanovsky wrote: > ... > >> The PCI_P2PDMA_MAP_BUS_ADDR is not supported by DMA-buf and as > >> far as I can see is a complete dead end. > > > > Maybe you mean DRM, but VFIO works perfectly with > > PCI_P2PDMA_MAP_BUS_ADDR flow in DMA-buf. What am I missing? > > Well not quite. > > The approach PCI_P2PDMA_MAP_BUS_ADDR takes is fundamentally tied to > only map a physical CPU address into a PCI address and doesn't take > into account that in a lot of configurations the CPU can't access > all resources. It is called PCI P2P. If the flow only uses PCI devices it should always work because it relies on PCI spec things that happen outside the CPU. It does not try to solve the general embedded problem of arbitary communication between blocks inside a SOC, scale up networks, and so on. So, yes, it does not solve every problem DMA buf faces, but no it is not a "Dead end" as it 100% solves PCI to PCI communication which is still a very common use case. DMA buf users that are exporting from a PCI device, over PCI MMIO should be using this API. It is the only way to do PCI to PCI communication correctly in the kernel. Jason
© 2016 - 2026 Red Hat, Inc.