iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Hellstrom via iommu <iommu@lists.linux-foundation.org>
To: "hch@lst.de" <hch@lst.de>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>
Cc: "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 2/2] dma-mapping: force unencryped devices are always addressing limited
Date: Fri, 6 Dec 2019 14:10:59 +0000	[thread overview]
Message-ID: <c98d594b465d3d8228743bc54017b8c456695219.camel@vmware.com> (raw)
In-Reply-To: <20191204130339.22804-3-hch@lst.de>

Hi, Christoph.


On Wed, 2019-12-04 at 14:03 +0100, Christoph Hellwig wrote:
> Devices that are forced to DMA through swiotlb need to be treated as
> if
> they are addressing limited.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  include/linux/dma-direct.h | 1 +
>  kernel/dma/direct.c        | 8 ++++++--
>  kernel/dma/mapping.c       | 3 +++
>  3 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
> index 24b8684aa21d..83aac21434c6 100644
> --- a/include/linux/dma-direct.h
> +++ b/include/linux/dma-direct.h
> @@ -85,4 +85,5 @@ int dma_direct_mmap(struct device *dev, struct
> vm_area_struct *vma,
>  		void *cpu_addr, dma_addr_t dma_addr, size_t size,
>  		unsigned long attrs);
>  int dma_direct_supported(struct device *dev, u64 mask);
> +bool dma_direct_addressing_limited(struct device *dev);
>  #endif /* _LINUX_DMA_DIRECT_H */
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 6af7ae83c4ad..450f3abe5cb5 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -497,11 +497,15 @@ int dma_direct_supported(struct device *dev,
> u64 mask)
>  	return mask >= __phys_to_dma(dev, min_mask);
>  }
>  
> +bool dma_direct_addressing_limited(struct device *dev)
> +{
> +	return force_dma_unencrypted(dev) || swiotlb_force ==
> SWIOTLB_FORCE;
> +}
> +
>  size_t dma_direct_max_mapping_size(struct device *dev)
>  {
>  	/* If SWIOTLB is active, use its maximum mapping size */
> -	if (is_swiotlb_active() &&
> -	    (dma_addressing_limited(dev) || swiotlb_force ==
> SWIOTLB_FORCE))
> +	if (is_swiotlb_active() && dma_addressing_limited(dev))
>  		return swiotlb_max_mapping_size(dev);
>  	return SIZE_MAX;
>  }
> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> index 1dbe6d725962..ebc60633d89a 100644
> --- a/kernel/dma/mapping.c
> +++ b/kernel/dma/mapping.c
> @@ -416,6 +416,9 @@ EXPORT_SYMBOL_GPL(dma_get_merge_boundary);
>   */
>  bool dma_addressing_limited(struct device *dev)
>  {
> +	if (dma_is_direct(get_dma_ops(dev)) &&
> +	    dma_direct_addressing_limited(dev))
> +		return true;

This works fine for vmwgfx, for which the below expression is always 0.
But it looks like the only current user of dma_addressing_limited
outside of the dma code, radeon, actually wants only the below
expression to force GFP_DMA32 page allocations when the devices have
limited dma address space. Perhaps Christian can elaborate on that.

So in the end it looks like we have two different use cases. One to
force coherent memory (vmwgfx, possibly other grahpics drivers) or
reduced queue depth (vmw_pvscsi) when we have bounce-buffering.

The other one is to force GFP_DMA32 page allocation when the device
dma-addressing is limited. Perhaps this mode can be replaced by using
dma_coherent memory and stripped that functionality from TTM?

>  	return min_not_zero(dma_get_mask(dev), dev->bus_dma_limit) <
>  			    dma_get_required_mask(dev);
>  }


Thanks,
Thomas

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2019-12-06 14:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 13:03 make dma_addressing_limited work for memory encryption setups v2 Christoph Hellwig
2019-12-04 13:03 ` [PATCH 1/2] dma-mapping: move dma_addressing_limited out of line Christoph Hellwig
2019-12-04 13:03 ` [PATCH 2/2] dma-mapping: force unencryped devices are always addressing limited Christoph Hellwig
2019-12-06 14:10   ` Thomas Hellstrom via iommu [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-11-27 14:40 make dma_addressing_limited work for memory encryption setups Christoph Hellwig
2019-11-27 14:40 ` [PATCH 2/2] dma-mapping: force unencryped devices are always addressing limited Christoph Hellwig
2019-11-27 18:22   ` Thomas Hellstrom via iommu
2019-11-28  7:51     ` hch
2019-11-28  8:02       ` Thomas Hellstrom via iommu
2019-11-28 15:36         ` hch

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=c98d594b465d3d8228743bc54017b8c456695219.camel@vmware.com \
    --to=iommu@lists.linux-foundation.org \
    --cc=christian.koenig@amd.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=thellstrom@vmware.com \
    --cc=thomas.lendacky@amd.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;
as well as URLs for NNTP newsgroup(s).