All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: joro@8bytes.org, iommu@lists.linux.dev, will@kernel.org,
	digetx@gmail.com, thierry.reding@gmail.com,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH 4/4] iommu: Clean up force_aperture confusion
Date: Mon, 15 May 2023 10:15:17 -0300	[thread overview]
Message-ID: <ZGIwZZCcUV2lalIq@nvidia.com> (raw)
In-Reply-To: <ed26ed3213bf07ab4977211702dc0898680524cd.1684154219.git.robin.murphy@arm.com>

On Mon, May 15, 2023 at 01:49:32PM +0100, Robin Murphy wrote:
> It was never entirely clear whether the force_aperture flag was supposed
> to be a hardware capability or a software policy. So far things seem to
> have leant towards the latter, given that the only drivers not setting
> the flag are ones where the aperture is seemingly a whole virtual
> address space such that accesses outside it wouldn't be possible, and
> the one driver which definitely can't enforce it in hardware *does*
> still set the flag.
> 
> On reflection, though, it makes little sense for drivers to dictate
> usage policy to callers, and the interpretation that a driver setting
> the flag might also translate addresses outside the given aperture but
> has for some reason chosen not to is not actually a useful one. It seems
> a lot more logical to treat the aperture as the absolute limit of what
> can be translated, and the flag to indicate what would happen if a
> device did try to access an address outside the aperture, i.e. whether
> the access would fault or pass through untranslated. As such, reframe
> the flag consistent with a hardware capability in the hope of clearing
> up the misconception.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  drivers/iommu/dma-iommu.c    | 19 +++++++------------
>  drivers/iommu/mtk_iommu_v1.c |  4 ++++
>  drivers/iommu/sprd-iommu.c   |  1 +
>  drivers/iommu/tegra-gart.c   |  2 +-
>  4 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 7a9f0b0bddbd..4693b021d54f 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -548,24 +548,19 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>  	if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
>  		return -EINVAL;
>  
> +	/*
> +	 * If the IOMMU only offers a non-isolated GART-style translation
> +	 * aperture, just let the device use dma-direct.
> +	 */

So we add code to dma-iommu.c for a driver that never enables
dma-iommu.c and uses def_default_domain to prevent it from ever being
used anyhow? :(

> +	if (!domain->geometry.force_aperture)
> +		return -EINVAL;

We need more checks than just this, the 'blocking domain is an empty
unmanaged' thing needs it, there is a check in virtio-iommu that looks
wonky and the name doesn't really convay what it does
anymore.. "partial_translation" or something would be better.

I still prefer deleting tegra-gart and deleting force_aperture
completely.

Jason

  reply	other threads:[~2023-05-15 13:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15 12:49 [PATCH 0/4] iommu: tegra-gart cleanups Robin Murphy
2023-05-15 12:49 ` [PATCH 1/4] iommu/tegra-gart: Add default identity domain support Robin Murphy
2023-05-15 12:49 ` [PATCH 2/4] iommu/tegra-gart: Improve " Robin Murphy
2023-05-15 12:49 ` [PATCH 3/4] iommu/tegra-gart: Generalise " Robin Murphy
2023-05-15 12:49 ` [PATCH 4/4] iommu: Clean up force_aperture confusion Robin Murphy
2023-05-15 13:15   ` Jason Gunthorpe [this message]
2023-05-16  9:53 ` [PATCH 0/4] iommu: tegra-gart cleanups Nicolas Chauvet
2023-05-16 11:45   ` Robin Murphy
2023-05-16 12:16     ` Nicolas Chauvet
2023-05-16 12:31       ` Robin Murphy
2023-05-16 15:15         ` Nicolas Chauvet
2023-05-17 10:54           ` 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=ZGIwZZCcUV2lalIq@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=digetx@gmail.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=thierry.reding@gmail.com \
    --cc=will@kernel.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.