All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] iommu/dma: Stop getting dma_32bit_pfn wrong
Date: Tue, 15 Nov 2016 12:49:09 +0100	[thread overview]
Message-ID: <20161115114909.GC24857@8bytes.org> (raw)
In-Reply-To: <f9c96106e6253f7033be8dd975392f0edb12e603.1478889045.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>

On Fri, Nov 11, 2016 at 06:30:45PM +0000, Robin Murphy wrote:
> iommu_dma_init_domain() was originally written under the misconception
> that dma_32bit_pfn represented some sort of size limit for IOVA domains.
> Since the truth is almost the exact opposite of that, rework the logic
> and comments to reflect its real purpose of optimising lookups when
> allocating from a subset of the available space.
> 
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
>  drivers/iommu/dma-iommu.c | 23 ++++++++++++++++++-----
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab8667e6f2..ae045a14b530 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -139,6 +139,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>  {
>  	struct iova_domain *iovad = cookie_iovad(domain);
>  	unsigned long order, base_pfn, end_pfn;
> +	bool pci = dev && dev_is_pci(dev);
>  
>  	if (!iovad)
>  		return -ENODEV;
> @@ -161,19 +162,31 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>  		end_pfn = min_t(unsigned long, end_pfn,
>  				domain->geometry.aperture_end >> order);
>  	}
> +	/*
> +	 * PCI devices may have larger DMA masks, but still prefer allocating
> +	 * within a 32-bit mask to avoid DAC addressing. Such limitations don't
> +	 * apply to the typical platform device, so for those we may as well
> +	 * leave the cache limit at the top of the range they're likely to use.
> +	 */
> +	if (pci)
> +		end_pfn = min_t(unsigned long, end_pfn,
> +				DMA_BIT_MASK(32) >> order);

Question, does it actually hurt platform devices to follow the same
allocation strategy as pci devices? I mean, does it hurt enough to
special-case the code here?



	Joerg

WARNING: multiple messages have this Message-ID (diff)
From: joro@8bytes.org (Joerg Roedel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] iommu/dma: Stop getting dma_32bit_pfn wrong
Date: Tue, 15 Nov 2016 12:49:09 +0100	[thread overview]
Message-ID: <20161115114909.GC24857@8bytes.org> (raw)
In-Reply-To: <f9c96106e6253f7033be8dd975392f0edb12e603.1478889045.git.robin.murphy@arm.com>

On Fri, Nov 11, 2016 at 06:30:45PM +0000, Robin Murphy wrote:
> iommu_dma_init_domain() was originally written under the misconception
> that dma_32bit_pfn represented some sort of size limit for IOVA domains.
> Since the truth is almost the exact opposite of that, rework the logic
> and comments to reflect its real purpose of optimising lookups when
> allocating from a subset of the available space.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  drivers/iommu/dma-iommu.c | 23 ++++++++++++++++++-----
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab8667e6f2..ae045a14b530 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -139,6 +139,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>  {
>  	struct iova_domain *iovad = cookie_iovad(domain);
>  	unsigned long order, base_pfn, end_pfn;
> +	bool pci = dev && dev_is_pci(dev);
>  
>  	if (!iovad)
>  		return -ENODEV;
> @@ -161,19 +162,31 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>  		end_pfn = min_t(unsigned long, end_pfn,
>  				domain->geometry.aperture_end >> order);
>  	}
> +	/*
> +	 * PCI devices may have larger DMA masks, but still prefer allocating
> +	 * within a 32-bit mask to avoid DAC addressing. Such limitations don't
> +	 * apply to the typical platform device, so for those we may as well
> +	 * leave the cache limit at the top of the range they're likely to use.
> +	 */
> +	if (pci)
> +		end_pfn = min_t(unsigned long, end_pfn,
> +				DMA_BIT_MASK(32) >> order);

Question, does it actually hurt platform devices to follow the same
allocation strategy as pci devices? I mean, does it hurt enough to
special-case the code here?



	Joerg

  parent reply	other threads:[~2016-11-15 11:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-11 18:30 [PATCH] iommu/dma: Stop getting dma_32bit_pfn wrong Robin Murphy
2016-11-11 18:30 ` Robin Murphy
     [not found] ` <f9c96106e6253f7033be8dd975392f0edb12e603.1478889045.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2016-11-15 11:49   ` Joerg Roedel [this message]
2016-11-15 11:49     ` Joerg Roedel
     [not found]     ` <20161115114909.GC24857-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2016-11-15 16:22       ` Robin Murphy
2016-11-15 16:22         ` Robin Murphy

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=20161115114909.GC24857@8bytes.org \
    --to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=robin.murphy-5wv7dgnIgG8@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.