rg/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-vfio-v2
Thanks
Leon Romanovsky (8):
PCI/P2PDMA: Separate the mmap() support from the core logic
PCI/P2PDMA: Simplify bus address mapping API
PCI/P2PDMA: Refactor to separate core P2P functionality from memory
allocation
From: Leon Romanovsky
Move the struct phys_vec definition from block/blk-mq-dma.c to
include/linux/types.h to make it available for use across the kernel.
The phys_vec structure represents a physical address range with a
length, which is used by the new physical address-based DMA mapping
API
From: Leon Romanovsky
Update the pci_p2pdma_bus_addr_map() function to take a direct pointer
to the p2pdma_provider structure instead of the pci_p2pdma_map_state.
This simplifies the API by removing the need for callers to extract
the provider from the state structure.
The change updates all
-by: Vivek Kasireddy
Signed-off-by: Leon Romanovsky
---
drivers/vfio/pci/vfio_pci_core.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index b02dda8c96341..93b6cecfcab49 100644
From: Leon Romanovsky
Add support for exporting PCI device MMIO regions through dma-buf,
enabling safe sharing of non-struct page memory with controlled
lifetime management. This allows RDMA and other subsystems to import
dma-buf FDs and build them into memory regions for PCI P2P operations
On Fri, Sep 12, 2025 at 11:55:29AM -0700, Alex Mastro wrote:
> On Mon, Aug 04, 2025 at 04:00:45PM +0300, Leon Romanovsky wrote:
> > +static void dma_ranges_to_p2p_phys(struct vfio_pci_dma_buf *priv,
> > + struct vfio_device_feature_d
From: Vivek Kasireddy
These helpers are useful for managing additional references taken
on the device from other associated VFIO modules.
Original-patch-by: Jason Gunthorpe
Signed-off-by: Vivek Kasireddy
Signed-off-by: Leon Romanovsky
---
drivers/vfio/vfio_main.c | 2 ++
include/linux
From: Leon Romanovsky
Export the pci_p2pdma_map_type() function to allow external modules
and subsystems to determine the appropriate mapping type for P2PDMA
transfers between a provider and target device.
The function determines whether peer-to-peer DMA transfers can be
done directly through
From: Leon Romanovsky
Refactor the PCI P2PDMA subsystem to separate the core peer-to-peer DMA
functionality from the optional memory allocation layer. This creates a
two-tier architecture:
The core layer provides P2P mapping functionality for physical addresses
based on PCI device MMIO BARs and
From: Leon Romanovsky
Add new kernel config which indicates support for dma-buf export
of MMIO regions, which implementation is provided in next patches.
Signed-off-by: Leon Romanovsky
---
drivers/vfio/pci/Kconfig | 20
1 file changed, 20 insertions(+)
diff --git a
From: Leon Romanovsky
Make sure that all VFIO PCI devices have peer-to-peer capabilities
enables, so we would be able to export their MMIO memory through DMABUF,
Signed-off-by: Leon Romanovsky
---
drivers/vfio/pci/vfio_pci_core.c | 11 +++
include/linux/vfio_pci_core.h| 3 +++
2
From: Leon Romanovsky
Currently the P2PDMA code requires a pgmap and a struct page to
function. The was serving three important purposes:
- DMA API compatibility, where scatterlist required a struct page as
input
- Life cycle management, the percpu_ref is used to prevent UAF during
On Wed, Aug 06, 2025 at 04:02:01PM -0600, Alex Williamson wrote:
> On Mon, 4 Aug 2025 16:00:43 +0300
> Leon Romanovsky wrote:
>
> > From: Leon Romanovsky
> >
> > Make sure that all VFIO PCI devices have peer-to-peer capabilities
> > enables, so we would be
On Wed, Aug 06, 2025 at 02:58:25PM -0600, Alex Williamson wrote:
> On Mon, 4 Aug 2025 16:00:36 +0300
> Leon Romanovsky wrote:
>
> > From: Leon Romanovsky
> >
> > Remove the bus_off field from pci_p2pdma_map_state since it duplicates
> > information already
On Mon, Aug 04, 2025 at 04:00:45PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Add support for exporting PCI device MMIO regions through dma-buf,
> enabling safe sharing of non-struct page memory with controlled
> lifetime management. This allows RDMA and other subsy
On Mon, Aug 04, 2025 at 10:10:32AM -0400, Benjamin LaHaise wrote:
> FYI: this entire patch series was rejected as spam by large numbers of
> linux-mm subscribers using @gmail.com email addresses.
Thanks for the heads-up. Are you aware of any issues from my side?
I'm sending patches with git-send-e
From: Leon Romanovsky
Make sure that all VFIO PCI devices have peer-to-peer capabilities
enables, so we would be able to export their MMIO memory through DMABUF,
Signed-off-by: Leon Romanovsky
---
drivers/vfio/pci/vfio_pci_core.c | 4
include/linux/vfio_pci_core.h| 1 +
2 files
From: Leon Romanovsky
Add support for exporting PCI device MMIO regions through dma-buf,
enabling safe sharing of non-struct page memory with controlled
lifetime management. This allows RDMA and other subsystems to import
dma-buf FDs and build them into memory regions for PCI P2P operations
-by: Vivek Kasireddy
Signed-off-by: Leon Romanovsky
---
drivers/vfio/pci/vfio_pci_core.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index df9a32d3deac9..b1863d84b11aa 100644
From: Leon Romanovsky
Move the struct phys_vec definition from block/blk-mq-dma.c to
include/linux/types.h to make it available for use across the kernel.
The phys_vec structure represents a physical address range with a
length, which is used by the new physical address-based DMA mapping
API
From: Leon Romanovsky
Refactor the PCI P2PDMA subsystem to separate the core peer-to-peer DMA
functionality from the optional memory allocation layer. This creates a
two-tier architecture:
The core layer provides P2P mapping functionality for physical addresses
based on PCI device MMIO BARs and
based on DMA physical API.
---
The WIP branch can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-vfio-v1
Thanks
Leon Romanovsky (8):
PCI/P2PDMA: Remove redundant bus_offset from map state
PCI/P2PDMA: Separate the mmap() su
From: Leon Romanovsky
Remove the bus_off field from pci_p2pdma_map_state since it duplicates
information already available in the pgmap structure. The bus_offset
is only used in one location (pci_p2pdma_bus_addr_map) and is always
identical to pgmap->bus_offset.
Reviewed-by: Christoph Hell
From: Vivek Kasireddy
These helpers are useful for managing additional references taken
on the device from other associated VFIO modules.
Original-patch-by: Jason Gunthorpe
Signed-off-by: Vivek Kasireddy
Signed-off-by: Leon Romanovsky
---
drivers/vfio/vfio_main.c | 2 ++
include/linux
From: Leon Romanovsky
Export the pci_p2pdma_map_type() function to allow external modules
and subsystems to determine the appropriate mapping type for P2PDMA
transfers between a provider and target device.
The function determines whether peer-to-peer DMA transfers can be
done directly through
From: Leon Romanovsky
Currently the P2PDMA code requires a pgmap and a struct page to
function. The was serving three important purposes:
- DMA API compatibility, where scatterlist required a struct page as
input
- Life cycle management, the percpu_ref is used to prevent UAF during
From: Leon Romanovsky
Update the pci_p2pdma_bus_addr_map() function to take a direct pointer
to the p2pdma_provider structure instead of the pci_p2pdma_map_state.
This simplifies the API by removing the need for callers to extract
the provider from the state structure.
The change updates all
On Tue, Jul 29, 2025 at 05:13:51PM -0300, Jason Gunthorpe wrote:
> On Tue, Jul 29, 2025 at 08:44:21PM +0100, Robin Murphy wrote:
>
> > In this case with just one single
> > contiguous mapping, it is clearly objectively worse to have to bounce in and
> > out of the IOMMU layer 3 separate times and
On Tue, Jul 29, 2025 at 02:54:13PM -0600, Logan Gunthorpe wrote:
>
>
> On 2025-07-28 17:11, Jason Gunthorpe wrote:
> >> If the dma mapping for P2P memory doesn't need to create an iommu
> >> mapping then that's fine. But it should be the dma-iommu layer to decide
> >> that.
> >
> > So above, we
On Tue, Jul 29, 2025 at 12:41:00PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 29, 2025 at 11:53:36AM +0300, Leon Romanovsky wrote:
> > > Because the struct page is the only thing that:
> > >
> > > a) dma-mapping works on
> > > b) is the only place we ca
On Tue, Jul 29, 2025 at 09:52:09AM +0200, Christoph Hellwig wrote:
> On Sun, Jul 27, 2025 at 03:51:58PM -0300, Jason Gunthorpe wrote:
> > On Thu, Jul 24, 2025 at 09:59:22AM +0200, Christoph Hellwig wrote:
> > > On Thu, Jul 24, 2025 at 10:55:33AM +0300, Leon Romanovsky wrote:
&
On Tue, Jul 29, 2025 at 09:52:30AM +0200, Christoph Hellwig wrote:
> On Thu, Jul 24, 2025 at 11:13:21AM +0300, Leon Romanovsky wrote:
> > On Thu, Jul 24, 2025 at 10:03:13AM +0200, Christoph Hellwig wrote:
> > > On Wed, Jul 23, 2025 at 04:00:06PM +0300, Leon Romanovsky wrote:
On Mon, Jul 28, 2025 at 02:55:53PM -0600, Alex Williamson wrote:
> On Wed, 23 Jul 2025 16:00:10 +0300
> Leon Romanovsky wrote:
>
> > From: Vivek Kasireddy
> >
> > There is no need to share the main device pointer (struct vfio_device *)
> > with all the featur
On Mon, Jul 28, 2025 at 10:12:31AM -0600, Logan Gunthorpe wrote:
>
>
> On 2025-07-27 13:05, Jason Gunthorpe wrote:
> > On Fri, Jul 25, 2025 at 10:30:46AM -0600, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2025-07-24 02:13, Leon Romanovsky wrote:
>
On Fri, Jul 25, 2025 at 05:34:40AM +, Kasireddy, Vivek wrote:
> Hi Leon,
>
> > Subject: Re: [PATCH 10/10] vfio/pci: Add dma-buf export support for MMIO
> > regions
> >
> > > >
> > > > From: Leon Romanovsky
> > > >
> > >
On Fri, Jul 25, 2025 at 01:12:35PM -0600, Logan Gunthorpe wrote:
>
>
> On 2025-07-25 12:54, Leon Romanovsky wrote:
> >> The solution that would make more sense to me would be for either
> >> dma_iova_try_alloc() or another helper in dma-iommu.c to handle the
> >&
On Fri, Jul 25, 2025 at 10:30:46AM -0600, Logan Gunthorpe wrote:
>
>
> On 2025-07-24 02:13, Leon Romanovsky wrote:
> > On Thu, Jul 24, 2025 at 10:03:13AM +0200, Christoph Hellwig wrote:
> >> On Wed, Jul 23, 2025 at 04:00:06PM +0300, Leon Romanovsky wrote:
>
On Thu, Jul 24, 2025 at 10:03:13AM +0200, Christoph Hellwig wrote:
> On Wed, Jul 23, 2025 at 04:00:06PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > Export the pci_p2pdma_map_type() function to allow external modules
> > and subsystems to determine t
On Thu, Jul 24, 2025 at 09:59:22AM +0200, Christoph Hellwig wrote:
> On Thu, Jul 24, 2025 at 10:55:33AM +0300, Leon Romanovsky wrote:
> > Please, see last patch in the series
> > https://lore.kernel.org/all/aea452cc27ca9e5169f7279d7b524190c39e7260.1753274085.git.leo...@nvidia.com
On Thu, Jul 24, 2025 at 09:51:45AM +0200, Christoph Hellwig wrote:
> On Wed, Jul 23, 2025 at 04:00:03PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > Extract the core P2PDMA provider information (device owner and bus
> > offset) from the d
On Thu, Jul 24, 2025 at 05:13:49AM +, Kasireddy, Vivek wrote:
> Hi Leon,
>
> > Subject: [PATCH 10/10] vfio/pci: Add dma-buf export support for MMIO
> > regions
> >
> > From: Leon Romanovsky
> >
> > Add support for exporting PCI device MMIO regions
-by: Vivek Kasireddy
Signed-off-by: Leon Romanovsky
---
drivers/vfio/pci/vfio_pci_core.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 1e675daab5753..5512d13bb8899 100644
From: Vivek Kasireddy
These helpers are useful for managing additional references taken
on the device from other associated VFIO modules.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Vivek Kasireddy
Signed-off-by: Leon Romanovsky
---
drivers/vfio/vfio_main.c | 2 ++
include/linux/vfio.h
From: Leon Romanovsky
Add support for exporting PCI device MMIO regions through dma-buf,
enabling safe sharing of non-struct page memory with controlled
lifetime management. This allows RDMA and other subsystems to import
dma-buf FDs and build them into memory regions for PCI P2P operations
From: Leon Romanovsky
Make sure that all VFIO PCI devices have peer-to-peer capabilities
enables, so we would be able to export their MMIO memory through DMABUF,
Signed-off-by: Leon Romanovsky
---
drivers/vfio/pci/vfio_pci_core.c | 4
include/linux/vfio_pci_core.h| 1 +
2 files
From: Leon Romanovsky
Move the struct phys_vec definition from block/blk-mq-dma.c to
include/linux/types.h to make it available for use across the kernel.
The phys_vec structure represents a physical address range with a
length, which is used by the new physical address-based DMA mapping
API
From: Leon Romanovsky
Export the pci_p2pdma_map_type() function to allow external modules
and subsystems to determine the appropriate mapping type for P2PDMA
transfers between a provider and target device.
The function determines whether peer-to-peer DMA transfers can be
done directly through
From: Leon Romanovsky
Update the pci_p2pdma_bus_addr_map() function to take a direct pointer
to the p2pdma_provider structure instead of the pci_p2pdma_map_state.
This simplifies the API by removing the need for callers to extract
the provider from the state structure.
The change updates all
From: Leon Romanovsky
Extract the core P2PDMA provider information (device owner and bus
offset) from the dev_pagemap into a dedicated p2pdma_provider structure.
This creates a cleaner separation between the memory management layer and
the P2PDMA functionality.
The new p2pdma_provider structure
From: Leon Romanovsky
Refactor the PCI P2PDMA subsystem to separate the core peer-to-peer DMA
functionality from the optional memory allocation layer. This creates a
two-tier architecture:
The core layer provides P2P mapping functionality for physical addresses
based on PCI device MMIO BARs and
From: Leon Romanovsky
---
Based on blk and DMA patches which will be sent during coming merge window.
---
This series extends the VFIO PCI subsystem to
From: Leon Romanovsky
Remove the bus_off field from pci_p2pdma_map_state since it duplicates
information already available in the pgmap structure. The bus_offset
is only used in one location (pci_p2pdma_bus_addr_map) and is always
identical to pgmap->bus_offset.
Signed-off-by: Jason Guntho
On Wed, Jul 23, 2025 at 01:03:47AM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 21, 2025 at 09:49:04AM +0300, Leon Romanovsky wrote:
> > > In fact, hmm_range_fault doesn't have information about the destination
> > > device that will perform the DMA mapping.
> >
&
On Mon, Jul 21, 2025 at 12:03:51AM +0300, Yonatan Maman wrote:
>
>
> On 20/07/2025 13:30, Leon Romanovsky wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Fri, Jul 18, 2025 at 02:51:07PM +0300, Yonatan Maman wrote:
> > &
On Fri, Jul 18, 2025 at 02:51:07PM +0300, Yonatan Maman wrote:
> From: Yonatan Maman
>
> This patch series aims to enable Peer-to-Peer (P2P) DMA access in
> GPU-centric applications that utilize RDMA and private device pages. This
> enhancement reduces data transfer overhead by allowing the GPU t
On Tue, Mar 04, 2025 at 03:29:42PM +0100, Christian König wrote:
> Am 26.02.25 um 14:38 schrieb Jason Gunthorpe:
> > On Wed, Feb 26, 2025 at 07:55:07AM +, Kasireddy, Vivek wrote:
> >
> >>> Is there any update or ETA for the v3? Are there any ways we can help?
> >> I believe Leon's series is ver
On Wed, Feb 26, 2025 at 09:38:22AM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 26, 2025 at 07:55:07AM +, Kasireddy, Vivek wrote:
>
> > > Is there any update or ETA for the v3? Are there any ways we can help?
>
> > I believe Leon's series is very close to getting merged. Once it
> > lands, thi
On Thu, Jan 09, 2025 at 10:10:01AM +0100, Christian König wrote:
> Am 08.01.25 um 17:22 schrieb Jason Gunthorpe:
> > [SNIP]
> > > > For P2P cases we are going toward (PFN + P2P source information) as
> > > > input to the DMA API. The additional "P2P source information" provides
> > > > a good way f
On Thu, 01 Aug 2024 15:05:09 +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> From Yishai,
>
> Overview
>
> This patch series aims to enable multi-path DMA support, allowing an
> mlx5 RDMA device to issue DMA commands through multiple paths. This
&
shai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/uverbs_std_types_mr.c | 2 +-
drivers/infiniband/hw/bnxt_re/ib_verbs.c | 3 ++-
drivers/infiniband/hw/bnxt_re/ib_verbs.h | 2 +-
drivers/infiniband/hw/efa/efa.h | 2 +-
drivers/infiniband/hw/efa/efa_verbs.c
From: Yishai Hadas
Introduce the 'GET_DATA_DIRECT_SYSFS_PATH' ioctl to return the sysfs
path of the affiliated 'data direct' device for a given device.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx
Yishai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/main.c | 11 +
drivers/infiniband/hw/mlx5/mlx5_ib.h | 8 +
drivers/infiniband/hw/mlx5/mr.c | 304 +++---
drivers/infiniband/hw/mlx5/odp.c | 5 +-
drivers/infi
them to clean up the
resources that were mmaped with its DMA device.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/Makefile | 1 +
drivers/infiniband/hw/mlx5/data_direct.c | 227 +++
drivers/infiniband/hw/mlx5/data_direct.
From: Yishai Hadas
Add support for creating pinned DMABUF umem with a specified DMA device
instead of the DMA device of the given IB device.
This API will be utilized in the upcoming patches of the series when
multiple path DMAs are implemented.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon
patches in the
series, where we aim to delay umem deallocation until the mkey
deregistration. However, we must unmap its pages immediately.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/umem_dmabuf.c | 21 +++--
include/rdma/ib_umem.h
g MR
registrations that request the data direct functionality.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/cmd.c | 21 +++
drivers/infiniband/hw/mlx5/cmd.h | 2 +
drivers/infiniband/hw/mlx5/main.c| 90 ++
From: Yishai Hadas
Add IFC related stuff for data direct.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
---
include/linux/mlx5/mlx5_ifc.h | 51 +++
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/include/linux/mlx5/mlx5_ifc.h b
From: Leon Romanovsky
>From Yishai,
Overview
This patch series aims to enable multi-path DMA support, allowing an
mlx5 RDMA device to issue DMA commands through multiple paths. This
feature is critical for improving performance and reaching line rate
in certain environments wh
On Thu, Jul 18, 2024 at 06:54:17AM +, Omer Shpigelman wrote:
> On 7/17/24 15:33, Leon Romanovsky wrote:
> > On Wed, Jul 17, 2024 at 10:51:03AM +, Omer Shpigelman wrote:
> >> On 7/17/24 10:36, Leon Romanovsky wrote:
> >>> On Wed, Jul 17, 2024 at 07:08:59A
On Wed, Jul 17, 2024 at 10:51:03AM +, Omer Shpigelman wrote:
> On 7/17/24 10:36, Leon Romanovsky wrote:
> > On Wed, Jul 17, 2024 at 07:08:59AM +, Omer Shpigelman wrote:
> >> On 7/16/24 16:40, Jason Gunthorpe wrote:
> >>> On Sun, Jul 14, 2024 at 10:18:12A
On Wed, Jul 17, 2024 at 07:08:59AM +, Omer Shpigelman wrote:
> On 7/16/24 16:40, Jason Gunthorpe wrote:
> > On Sun, Jul 14, 2024 at 10:18:12AM +, Omer Shpigelman wrote:
> >> On 7/12/24 16:08, Jason Gunthorpe wrote:
> >>> [You don't often get email from j...@ziepe.ca. Learn why this is
> >>
On Mon, Jul 01, 2024 at 10:46:48AM +, Omer Shpigelman wrote:
> On 6/30/24 16:29, Leon Romanovsky wrote:
> > On Fri, Jun 28, 2024 at 10:24:32AM +, Omer Shpigelman wrote:
> >> On 6/19/24 13:52, Leon Romanovsky wrote:
> >>> On Wed, Jun 19, 2024 at 09:27:54A
On Fri, Jun 28, 2024 at 10:24:32AM +, Omer Shpigelman wrote:
> On 6/19/24 13:52, Leon Romanovsky wrote:
> > On Wed, Jun 19, 2024 at 09:27:54AM +, Omer Shpigelman wrote:
> >> On 6/18/24 15:58, Leon Romanovsky wrote:
> >>> On Tue, Jun 18, 2024 at 11:08:34A
On Sun, Jun 23, 2024 at 11:53:11PM -0700, Vivek Kasireddy wrote:
> From Jason Gunthorpe:
> "dma-buf has become a way to safely acquire a handle to non-struct page
> memory that can still have lifetime controlled by the exporter. Notably
> RDMA can now import dma-buf FDs and build them into MRs whic
On Sun, Jun 23, 2024 at 05:02:44PM +0200, Andrew Lunn wrote:
> > > If there is no netdev, what is the point of putting it into loopback?
> > > How do you send packets which are to be looped back? How do you
> > > receive them to see if they were actually looped back?
> > >
> > > Andrew
> >
> >
On Mon, Jun 24, 2024 at 08:47:41AM +, Omer Shpigelman wrote:
> On 6/19/24 13:52, Leon Romanovsky wrote:
> > On Wed, Jun 19, 2024 at 09:27:54AM +, Omer Shpigelman wrote:
> >> On 6/18/24 15:58, Leon Romanovsky wrote:
> >>> On Tue, Jun 18, 2024 at 11:08:34A
On Wed, Jun 19, 2024 at 09:27:54AM +, Omer Shpigelman wrote:
> On 6/18/24 15:58, Leon Romanovsky wrote:
> > On Tue, Jun 18, 2024 at 11:08:34AM +, Omer Shpigelman wrote:
> >> On 6/17/24 22:04, Leon Romanovsky wrote:
> >>> [Some people who received this mess
On Tue, Jun 18, 2024 at 11:08:34AM +, Omer Shpigelman wrote:
> On 6/17/24 22:04, Leon Romanovsky wrote:
> > [Some people who received this message don't often get email from
> > l...@kernel.org. Learn why this is important at
> > https://aka.ms/LearnAboutSenderId
On Tue, Jun 18, 2024 at 07:58:55AM +, Omer Shpigelman wrote:
> On 6/18/24 10:08, Leon Romanovsky wrote:
> > On Tue, Jun 18, 2024 at 05:50:15AM +, Omer Shpigelman wrote:
> >> On 6/17/24 16:18, Leon Romanovsky wrote:
> >>> [Some people who received this mess
On Tue, Jun 18, 2024 at 05:50:15AM +, Omer Shpigelman wrote:
> On 6/17/24 16:18, Leon Romanovsky wrote:
> > [Some people who received this message don't often get email from
> > l...@kernel.org. Learn why this is important at
> > https://aka.ms/LearnAboutSenderId
On Mon, Jun 17, 2024 at 05:43:49PM +, Omer Shpigelman wrote:
> On 6/13/24 22:18, Leon Romanovsky wrote:
> > [Some people who received this message don't often get email from
> > l...@kernel.org. Learn why this is important at
> > https://aka.ms/LearnAboutSenderId
On Thu, Jun 13, 2024 at 11:21:57AM +0300, Omer Shpigelman wrote:
> Add a common QP state machine which handles the moving for a QP from one
> state to another including performing necessary checks, draining
> in-flight transactions, invalidating caches and error reporting.
>
> Signed-off-by: Omer
On Mon, Jun 17, 2024 at 08:08:26AM +, Omer Shpigelman wrote:
> On 6/13/24 16:01, Przemek Kitszel wrote:
> > [Some people who received this message don't often get email from
> > przemyslaw.kits...@intel.com. Learn why this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
>
On Thu, Jun 13, 2024 at 11:22:04AM +0300, Omer Shpigelman wrote:
> Add an RDMA driver of Gaudi ASICs family for AI scaling.
> The driver itself is agnostic to the ASIC in action, it operates according
> to the capabilities that were passed on device initialization.
> The device is initialized by th
On Fri, May 03, 2024 at 10:04:16AM -0300, Jason Gunthorpe wrote:
> On Fri, May 03, 2024 at 01:18:35PM +0300, Ilpo Järvinen wrote:
> > On Thu, 15 Feb 2024, Ilpo Järvinen wrote:
> >
> > > Convert open coded RMW accesses for LNKCTL2 to use
> > > pcie_capability_clear_and_set_word() which makes its ea
On Thu, May 02, 2024 at 07:50:36AM +, Kasireddy, Vivek wrote:
> Hi Jason,
<...>
> > I'd rather we stick with the original design. Leon is working on DMA
> > API changes that should address half the issue.
> Ok, I'll keep an eye out for Leon's work.
The code for v1 is here:
https://git.kernel
On Fri, Mar 29, 2024 at 05:00:25PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's series
> to fix drivers/i2c[1], fix the terminology where I had a role to play, now
>
On Wed, Aug 09, 2023 at 06:57:38PM -0700, Mina Almasry wrote:
> Add a netdev_dmabuf_binding struct which represents the
> dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> an rx queue on the netdevice. On the binding, the dma_buf_attach
> & dma_buf_map_attachment will occur.
On Mon, Dec 12, 2022 at 11:53:09AM +0800, Jiapeng Chong wrote:
> The function port_cfg_force_flow_ctrl() is defined in the ksz884x.c file,
> but not called elsewhere, so remove this unused function.
>
> drivers/net/ethernet/micrel/ksz884x.c:2212:20: warning: unused function
> 'port_cfg_force_flow
or debugger access.
>
> Cc: Jason Gunthorpe
> Cc: Leon Romanovsky
> Signed-off-by: David Hildenbrand
> ---
> drivers/infiniband/core/umem.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Thanks,
Tested-by: Leon Romanovsky # Over mlx4 and mlx5.
On Tue, Feb 15, 2022 at 01:21:10PM -0600, Gustavo A. R. Silva wrote:
> On Tue, Feb 15, 2022 at 10:17:40AM -0800, Kees Cook wrote:
> > On Tue, Feb 15, 2022 at 11:47:43AM -0600, Gustavo A. R. Silva wrote:
> > > There is a regular need in the kernel to provide a way to declare
> > > having a dynamical
On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote:
> From: Maor Gottlieb
>
> Changelog:
> v4:
> * Unify sg_free_table_entries with __sg_free_table
> v3: https://lore.kernel.org/lkml/cover.1627551226.git.leo...@nvidia.com/
> * Rewrote to new API suggestion
> * Split for more patches
On Mon, Aug 30, 2021 at 10:31:28AM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 30, 2021 at 11:21:00AM +0300, Leon Romanovsky wrote:
> > On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote:
> > > From: Maor Gottlieb
> > >
> > > Changelog:
> >
entries in the table.
Now all APIs set orig_nents as number of enries with pages.
Fixes: 07da1223ec93 ("lib/scatterlist: Add support in dynamic allocation of SG
table from pages")
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/umem.c | 34 ++
From: Maor Gottlieb
This allows using the normal sg_table APIs and makes all the code
cleaner. Remove sgt, nents and nmapd from ib_umem.
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
---
drivers/infiniband/core/umem.c | 32
: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
drivers/gpu/drm/drm_prime.c | 13 ---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 11 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 14 +++-
drivers/infiniband/core/umem.c | 4 +--
include/linux
From: Leon Romanovsky
Changelog:
v3:
* Rewrote to new API suggestion
* Split for more patches
v2: https://lore.kernel.org/lkml/cover.1626605893.git.leo...@nvidia.com
* Changed implementation of first patch, based on our discussion with
Christoph.
https://lore.kernel.org/lkml/ynwavtt0qmqdx
lib/scatterlist: Add support in dynamic allocation of SG
table from pages")
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
drivers/gpu/drm/drm_prime.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer
-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/umem.c| 28 +++
drivers/infiniband/core/umem_dmabuf.c | 1 -
drivers/infiniband/hw/mlx4/mr.c | 4 ++--
drivers/infiniband/hw/mlx5/mr.c | 3 ++-
drivers/infiniband/sw
From: Leon Romanovsky
Changelog:
v2:
* Changed implementation of first patch, based on our discussion with
Christoph.
https://lore.kernel.org/lkml/ynwavtt0qmqdx...@infradead.org/
v1: https://lore.kernel.org/lkml/cover.1624955710.git.leo...@nvidia.com/
* Fixed sg_page with a _dma_ API in
1 - 100 of 149 matches
Mail list logo
