All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Olav Haugan <ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: "linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v3 1/1] iommu-api: Add map_sg/unmap_sg functions
Date: Mon, 28 Jul 2014 20:11:12 +0100	[thread overview]
Message-ID: <20140728191111.GW15536@arm.com> (raw)
In-Reply-To: <1406572731-6216-2-git-send-email-ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

Hi Olav,

On Mon, Jul 28, 2014 at 07:38:51PM +0100, Olav Haugan wrote:
> Mapping and unmapping are more often than not in the critical path.
> map_sg and unmap_sg allows IOMMU driver implementations to optimize
> the process of mapping and unmapping buffers into the IOMMU page tables.
> 
> Instead of mapping a buffer one page at a time and requiring potentially
> expensive TLB operations for each page, this function allows the driver
> to map all pages in one go and defer TLB maintenance until after all
> pages have been mapped.
> 
> Additionally, the mapping operation would be faster in general since
> clients does not have to keep calling map API over and over again for
> each physically contiguous chunk of memory that needs to be mapped to a
> virtually contiguous region.
> 
> Signed-off-by: Olav Haugan <ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
>  drivers/iommu/iommu.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/iommu.h | 28 ++++++++++++++++++++++++++++
>  2 files changed, 76 insertions(+)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 1698360..cd65511 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1088,6 +1088,54 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t size)
>  }
>  EXPORT_SYMBOL_GPL(iommu_unmap);
>  
> +int iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
> +			struct scatterlist *sg, unsigned int nents,
> +			int prot, unsigned long flags)
> +{
> +	int ret = 0;
> +	unsigned long offset = 0;
> +
> +	BUG_ON(iova & (~PAGE_MASK));
> +
> +	if (unlikely(domain->ops->map_sg == NULL)) {
> +		unsigned int i;
> +		struct scatterlist *s;
> +
> +		for_each_sg(sg, s, nents, i) {
> +			phys_addr_t phys = page_to_phys(sg_page(s));
> +			u32 page_len = PAGE_ALIGN(s->offset + s->length);

Hmm, this is a pretty horrible place where CPU page size (from the sg list)
meets the IOMMU and I think we need to do something better to avoid spurious
failures. In other words, the sg list should be iterated in such a way that
we always pass a multiple of a supported iommu page size to iommu_map.

All the code using PAGE_MASK and PAGE_ALIGN needn't match what is supported
by the IOMMU hardware.

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/1] iommu-api: Add map_sg/unmap_sg functions
Date: Mon, 28 Jul 2014 20:11:12 +0100	[thread overview]
Message-ID: <20140728191111.GW15536@arm.com> (raw)
In-Reply-To: <1406572731-6216-2-git-send-email-ohaugan@codeaurora.org>

Hi Olav,

On Mon, Jul 28, 2014 at 07:38:51PM +0100, Olav Haugan wrote:
> Mapping and unmapping are more often than not in the critical path.
> map_sg and unmap_sg allows IOMMU driver implementations to optimize
> the process of mapping and unmapping buffers into the IOMMU page tables.
> 
> Instead of mapping a buffer one page at a time and requiring potentially
> expensive TLB operations for each page, this function allows the driver
> to map all pages in one go and defer TLB maintenance until after all
> pages have been mapped.
> 
> Additionally, the mapping operation would be faster in general since
> clients does not have to keep calling map API over and over again for
> each physically contiguous chunk of memory that needs to be mapped to a
> virtually contiguous region.
> 
> Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
> ---
>  drivers/iommu/iommu.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/iommu.h | 28 ++++++++++++++++++++++++++++
>  2 files changed, 76 insertions(+)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 1698360..cd65511 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1088,6 +1088,54 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t size)
>  }
>  EXPORT_SYMBOL_GPL(iommu_unmap);
>  
> +int iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
> +			struct scatterlist *sg, unsigned int nents,
> +			int prot, unsigned long flags)
> +{
> +	int ret = 0;
> +	unsigned long offset = 0;
> +
> +	BUG_ON(iova & (~PAGE_MASK));
> +
> +	if (unlikely(domain->ops->map_sg == NULL)) {
> +		unsigned int i;
> +		struct scatterlist *s;
> +
> +		for_each_sg(sg, s, nents, i) {
> +			phys_addr_t phys = page_to_phys(sg_page(s));
> +			u32 page_len = PAGE_ALIGN(s->offset + s->length);

Hmm, this is a pretty horrible place where CPU page size (from the sg list)
meets the IOMMU and I think we need to do something better to avoid spurious
failures. In other words, the sg list should be iterated in such a way that
we always pass a multiple of a supported iommu page size to iommu_map.

All the code using PAGE_MASK and PAGE_ALIGN needn't match what is supported
by the IOMMU hardware.

Will

  parent reply	other threads:[~2014-07-28 19:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-28 18:38 [PATCH v3 0/1] Add iommu map_sg/unmap_sg calls Olav Haugan
2014-07-28 18:38 ` Olav Haugan
2014-07-28 18:38 ` [PATCH v3 1/1] iommu-api: Add map_sg/unmap_sg functions Olav Haugan
2014-07-28 18:38   ` Olav Haugan
     [not found]   ` <1406572731-6216-2-git-send-email-ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-07-28 19:11     ` Will Deacon [this message]
2014-07-28 19:11       ` Will Deacon
     [not found]       ` <20140728191111.GW15536-5wv7dgnIgG8@public.gmane.org>
2014-07-29  0:50         ` Olav Haugan
2014-07-29  0:50           ` Olav Haugan
     [not found]           ` <53D6EFC0.1060308-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-07-29  9:25             ` Will Deacon
2014-07-29  9:25               ` Will Deacon
     [not found]               ` <20140729092547.GB9245-5wv7dgnIgG8@public.gmane.org>
2014-07-29 17:21                 ` Olav Haugan
2014-07-29 17:21                   ` Olav Haugan
2014-07-30  9:45                   ` Will Deacon
2014-07-30  9:45                     ` Will Deacon

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=20140728191111.GW15536@arm.com \
    --to=will.deacon-5wv7dgnigg8@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.