linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: "Jens Axboe" <axboe@kernel.dk>, "Jason Gunthorpe" <jgg@ziepe.ca>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	"Christoph Hellwig" <hch@lst.de>,
	"Sagi Grimberg" <sagi@grimberg.me>,
	"Keith Busch" <kbusch@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Logan Gunthorpe" <logang@deltatee.com>,
	"Yishai Hadas" <yishaih@nvidia.com>,
	"Shameer Kolothum" <shameerali.kolothum.thodi@huawei.com>,
	"Kevin Tian" <kevin.tian@intel.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-rdma@vger.kernel.org,
	iommu@lists.linux.dev, linux-nvme@lists.infradead.org,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 02/18] dma-mapping: move the PCI P2PDMA mapping helpers to pci-p2pdma.h
Date: Tue, 29 Oct 2024 10:11:04 -0500	[thread overview]
Message-ID: <20241029151104.GA1156518@bhelgaas> (raw)
In-Reply-To: <27698e7cc55f6ca5371c3d86c50fd3afce9afddd.1730037276.git.leon@kernel.org>

On Sun, Oct 27, 2024 at 04:21:02PM +0200, Leon Romanovsky wrote:
> From: Christoph Hellwig <hch@lst.de>
> 
> To support the upcoming non-scatterlist mapping helpers, we need to go
> back to have them called outside of the DMA API.  Thus move them out of
> dma-map-ops.h, which is only for DMA API implementations to pci-p2pdma.h,
> which is for driver use.
> 
> Note that the core helper is still not exported as the mapping is
> expected to be done only by very highlevel subsystem code at least for
> now.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> ---
>  drivers/iommu/dma-iommu.c   |  1 +
>  include/linux/dma-map-ops.h | 84 -------------------------------------
>  include/linux/pci-p2pdma.h  | 84 +++++++++++++++++++++++++++++++++++++
>  kernel/dma/direct.c         |  1 +
>  4 files changed, 86 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 6e50023c8112..c422e36c0d66 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -26,6 +26,7 @@
>  #include <linux/mutex.h>
>  #include <linux/of_iommu.h>
>  #include <linux/pci.h>
> +#include <linux/pci-p2pdma.h>
>  #include <linux/scatterlist.h>
>  #include <linux/spinlock.h>
>  #include <linux/swiotlb.h>
> diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
> index 49edcbda19d1..6ee626e50708 100644
> --- a/include/linux/dma-map-ops.h
> +++ b/include/linux/dma-map-ops.h
> @@ -435,88 +435,4 @@ static inline void debug_dma_dump_mappings(struct device *dev)
>  
>  extern const struct dma_map_ops dma_dummy_ops;
>  
> -enum pci_p2pdma_map_type {
> -	/*
> -	 * PCI_P2PDMA_MAP_UNKNOWN: Used internally for indicating the mapping
> -	 * type hasn't been calculated yet. Functions that return this enum
> -	 * never return this value.
> -	 */
> -	PCI_P2PDMA_MAP_UNKNOWN = 0,
> -
> -	/*
> -	 * Not a PCI P2PDMA transfer.
> -	 */
> -	PCI_P2PDMA_MAP_NONE,
> -
> -	/*
> -	 * PCI_P2PDMA_MAP_NOT_SUPPORTED: Indicates the transaction will
> -	 * traverse the host bridge and the host bridge is not in the
> -	 * allowlist. DMA Mapping routines should return an error when
> -	 * this is returned.
> -	 */
> -	PCI_P2PDMA_MAP_NOT_SUPPORTED,
> -
> -	/*
> -	 * PCI_P2PDMA_BUS_ADDR: Indicates that two devices can talk to
> -	 * each other directly through a PCI switch and the transaction will
> -	 * not traverse the host bridge. Such a mapping should program
> -	 * the DMA engine with PCI bus addresses.
> -	 */
> -	PCI_P2PDMA_MAP_BUS_ADDR,
> -
> -	/*
> -	 * PCI_P2PDMA_MAP_THRU_HOST_BRIDGE: Indicates two devices can talk
> -	 * to each other, but the transaction traverses a host bridge on the
> -	 * allowlist. In this case, a normal mapping either with CPU physical
> -	 * addresses (in the case of dma-direct) or IOVA addresses (in the
> -	 * case of IOMMUs) should be used to program the DMA engine.
> -	 */
> -	PCI_P2PDMA_MAP_THRU_HOST_BRIDGE,
> -};
> -
> -struct pci_p2pdma_map_state {
> -	struct dev_pagemap *pgmap;
> -	enum pci_p2pdma_map_type map;
> -	u64 bus_off;
> -};
> -
> -/* helper for pci_p2pdma_state(), do not use directly */
> -void __pci_p2pdma_update_state(struct pci_p2pdma_map_state *state,
> -		struct device *dev, struct page *page);
> -
> -/**
> - * pci_p2pdma_state - check the P2P transfer state of a page
> - * @state: 	P2P state structure
> - * @dev:	device to transfer to/from
> - * @page:	page to map
> - *
> - * Check if @page is a PCI P2PDMA page, and if yes of what kind.  Returns the
> - * map type, and updates @state with all information needed for a P2P transfer.
> - */
> -static inline enum pci_p2pdma_map_type
> -pci_p2pdma_state(struct pci_p2pdma_map_state *state, struct device *dev,
> -		struct page *page)
> -{
> -	if (IS_ENABLED(CONFIG_PCI_P2PDMA) && is_pci_p2pdma_page(page)) {
> -		if (state->pgmap != page->pgmap)
> -			__pci_p2pdma_update_state(state, dev, page);
> -		return state->map;
> -	}
> -	return PCI_P2PDMA_MAP_NONE;
> -}
> -
> -/**
> - * pci_p2pdma_bus_addr_map - map a PCI_P2PDMA_MAP_BUS_ADDR P2P transfer
> - * @state: 	P2P state structure
> - * @paddr:	physical address to map
> - *
> - * Map a physically contigous PCI_P2PDMA_MAP_BUS_ADDR transfer.
> - */
> -static inline dma_addr_t
> -pci_p2pdma_bus_addr_map(struct pci_p2pdma_map_state *state, phys_addr_t paddr)
> -{
> -	WARN_ON_ONCE(state->map != PCI_P2PDMA_MAP_BUS_ADDR);
> -	return paddr + state->bus_off;
> -}
> -
>  #endif /* _LINUX_DMA_MAP_OPS_H */
> diff --git a/include/linux/pci-p2pdma.h b/include/linux/pci-p2pdma.h
> index 2c07aa6b7665..66b71f60a811 100644
> --- a/include/linux/pci-p2pdma.h
> +++ b/include/linux/pci-p2pdma.h
> @@ -104,4 +104,88 @@ static inline struct pci_dev *pci_p2pmem_find(struct device *client)
>  	return pci_p2pmem_find_many(&client, 1);
>  }
>  
> +enum pci_p2pdma_map_type {
> +	/*
> +	 * PCI_P2PDMA_MAP_UNKNOWN: Used internally for indicating the mapping
> +	 * type hasn't been calculated yet. Functions that return this enum
> +	 * never return this value.
> +	 */
> +	PCI_P2PDMA_MAP_UNKNOWN = 0,
> +
> +	/*
> +	 * Not a PCI P2PDMA transfer.
> +	 */
> +	PCI_P2PDMA_MAP_NONE,
> +
> +	/*
> +	 * PCI_P2PDMA_MAP_NOT_SUPPORTED: Indicates the transaction will
> +	 * traverse the host bridge and the host bridge is not in the
> +	 * allowlist. DMA Mapping routines should return an error when
> +	 * this is returned.
> +	 */
> +	PCI_P2PDMA_MAP_NOT_SUPPORTED,
> +
> +	/*
> +	 * PCI_P2PDMA_BUS_ADDR: Indicates that two devices can talk to
> +	 * each other directly through a PCI switch and the transaction will
> +	 * not traverse the host bridge. Such a mapping should program
> +	 * the DMA engine with PCI bus addresses.
> +	 */
> +	PCI_P2PDMA_MAP_BUS_ADDR,
> +
> +	/*
> +	 * PCI_P2PDMA_MAP_THRU_HOST_BRIDGE: Indicates two devices can talk
> +	 * to each other, but the transaction traverses a host bridge on the
> +	 * allowlist. In this case, a normal mapping either with CPU physical
> +	 * addresses (in the case of dma-direct) or IOVA addresses (in the
> +	 * case of IOMMUs) should be used to program the DMA engine.
> +	 */
> +	PCI_P2PDMA_MAP_THRU_HOST_BRIDGE,
> +};
> +
> +struct pci_p2pdma_map_state {
> +	struct dev_pagemap *pgmap;
> +	enum pci_p2pdma_map_type map;
> +	u64 bus_off;
> +};
> +
> +/* helper for pci_p2pdma_state(), do not use directly */
> +void __pci_p2pdma_update_state(struct pci_p2pdma_map_state *state,
> +		struct device *dev, struct page *page);
> +
> +/**
> + * pci_p2pdma_state - check the P2P transfer state of a page
> + * @state: 	P2P state structure
> + * @dev:	device to transfer to/from
> + * @page:	page to map
> + *
> + * Check if @page is a PCI P2PDMA page, and if yes of what kind.  Returns the
> + * map type, and updates @state with all information needed for a P2P transfer.
> + */
> +static inline enum pci_p2pdma_map_type
> +pci_p2pdma_state(struct pci_p2pdma_map_state *state, struct device *dev,
> +		struct page *page)
> +{
> +	if (IS_ENABLED(CONFIG_PCI_P2PDMA) && is_pci_p2pdma_page(page)) {
> +		if (state->pgmap != page->pgmap)
> +			__pci_p2pdma_update_state(state, dev, page);
> +		return state->map;
> +	}
> +	return PCI_P2PDMA_MAP_NONE;
> +}
> +
> +/**
> + * pci_p2pdma_bus_addr_map - map a PCI_P2PDMA_MAP_BUS_ADDR P2P transfer
> + * @state: 	P2P state structure
> + * @paddr:	physical address to map
> + *
> + * Map a physically contigous PCI_P2PDMA_MAP_BUS_ADDR transfer.
> + */
> +static inline dma_addr_t
> +pci_p2pdma_bus_addr_map(struct pci_p2pdma_map_state *state, phys_addr_t paddr)
> +{
> +	WARN_ON_ONCE(state->map != PCI_P2PDMA_MAP_BUS_ADDR);
> +	return paddr + state->bus_off;
> +}
> +
>  #endif /* _LINUX_PCI_P2P_H */
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index a793400161c2..47e124561fff 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -13,6 +13,7 @@
>  #include <linux/vmalloc.h>
>  #include <linux/set_memory.h>
>  #include <linux/slab.h>
> +#include <linux/pci-p2pdma.h>
>  #include "direct.h"
>  
>  /*
> -- 
> 2.46.2
> 


  parent reply	other threads:[~2024-10-29 15:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-27 14:21 [PATCH 00/18] Provide a new two step DMA mapping API Leon Romanovsky
2024-10-27 14:21 ` [PATCH 01/18] PCI/P2PDMA: refactor the p2pdma mapping helpers Leon Romanovsky
2024-10-28 18:10   ` Logan Gunthorpe
2024-10-28 20:59   ` Bjorn Helgaas
2024-10-29 16:48     ` Leon Romanovsky
2024-10-27 14:21 ` [PATCH 02/18] dma-mapping: move the PCI P2PDMA mapping helpers to pci-p2pdma.h Leon Romanovsky
2024-10-28 18:11   ` Logan Gunthorpe
2024-10-29 15:11   ` Bjorn Helgaas [this message]
2024-10-27 14:21 ` [PATCH 03/18] iommu: generalize the batched sync after map interface Leon Romanovsky
2024-10-27 14:21 ` [PATCH 04/18] dma-mapping: Add check if IOVA can be used Leon Romanovsky
2024-10-27 14:21 ` [PATCH 05/18] dma: Provide an interface to allow allocate IOVA Leon Romanovsky
2024-10-28  1:24   ` Baolu Lu
2024-10-28  6:37     ` Leon Romanovsky
2024-10-29  7:46       ` Christoph Hellwig
2024-10-28  4:24   ` Srinivasulu Thanneeru
2024-10-28  6:46     ` Leon Romanovsky
2024-10-27 14:21 ` [PATCH 06/18] iommu/dma: Factor out a iommu_dma_map_swiotlb helper Leon Romanovsky
2024-10-27 14:21 ` [PATCH 07/18] dma-mapping: Implement link/unlink ranges API Leon Romanovsky
2024-10-28  2:00   ` Baolu Lu
2024-10-28  6:22     ` Leon Romanovsky
2024-10-28 18:31       ` Leon Romanovsky
2024-10-27 14:21 ` [PATCH 08/18] dma-mapping: add a dma_need_unmap helper Leon Romanovsky
2024-10-27 14:21 ` [PATCH 09/18] docs: core-api: document the IOVA-based API Leon Romanovsky
2024-10-28 18:12   ` Logan Gunthorpe
2024-10-28 18:28     ` Leon Romanovsky
2024-10-27 14:21 ` [PATCH 10/18] mm/hmm: let users to tag specific PFN with DMA mapped bit Leon Romanovsky
2024-10-27 14:21 ` [PATCH 11/18] mm/hmm: provide generic DMA managing logic Leon Romanovsky
2024-10-27 14:21 ` [PATCH 12/18] RDMA/umem: Store ODP access mask information in PFN Leon Romanovsky
2024-10-27 14:21 ` [PATCH 13/18] RDMA/core: Convert UMEM ODP DMA mapping to caching IOVA and page linkage Leon Romanovsky
2024-10-27 14:21 ` [PATCH 14/18] RDMA/umem: Separate implicit ODP initialization from explicit ODP Leon Romanovsky
2024-10-27 14:21 ` [PATCH 15/18] vfio/mlx5: Explicitly use number of pages instead of allocated length Leon Romanovsky
2024-10-27 14:21 ` [PATCH 16/18] vfio/mlx5: Rewrite create mkey flow to allow better code reuse Leon Romanovsky
2024-10-27 14:21 ` [PATCH 17/18] vfio/mlx5: Explicitly store page list Leon Romanovsky
2024-10-27 14:21 ` [PATCH 18/18] vfio/mlx5: Convert vfio to use DMA link API Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241029151104.GA1156518@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=joro@8bytes.org \
    --cc=kbusch@kernel.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=m.szyprowski@samsung.com \
    --cc=robin.murphy@arm.com \
    --cc=sagi@grimberg.me \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=will@kernel.org \
    --cc=yishaih@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox