All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Sven Peter <sven@svenpeter.dev>, Will Deacon <will@kernel.org>,
	Joerg Roedel <joro@8bytes.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
	devicetree@vger.kernel.org, Hector Martin <marcan@marcan.st>,
	linux-kernel@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
	Mohamed Mediouni <mohamed.mediouni@caramail.com>,
	Stan Skowronek <stan@corellium.com>,
	linux-arm-kernel@lists.infradead.org,
	Mark Kettenis <mark.kettenis@xs4all.nl>,
	iommu@lists.linux-foundation.org,
	Alexander Graf <graf@amazon.com>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Rob Herring <robh+dt@kernel.org>,
	r.czerwinski@pengutronix.de
Subject: Re: [PATCH v4 0/3] Apple M1 DART IOMMU driver
Date: Wed, 14 Jul 2021 19:19:50 +0100	[thread overview]
Message-ID: <7261df01-34a9-4e53-37cd-ae1aa15b1fb4@arm.com> (raw)
In-Reply-To: <20210627143405.77298-1-sven@svenpeter.dev>

On 2021-06-27 15:34, Sven Peter wrote:
[...]
> In the long term, I'd like to extend the dma-iommu framework itself to
> support iommu pagesizes with a larger granule than the CPU pagesize if that is
> something you agree with.

BTW this isn't something we can fully support in general. IOMMU API 
users may expect this to work:

iommu_map(domain, iova, page_to_phys(p1), PAGE_SIZE, prot);
iommu_map(domain, iova + PAGE_SIZE, page_to_phys(p2), PAGE_SIZE, prot);

Although they do in principle have visibility of pgsize_bitmap, I still 
doubt anyone is really prepared for CPU-page-aligned mappings to fail.
Even at the DMA API level you could hide *some* of it (at the cost of 
effectively only having 1/4 of the usable address space), but there are 
still cases like where v4l2 has a hard requirement that a page-aligned 
scatterlist can be mapped into a contiguous region of DMA addresses.

> This would be important to later support the thunderbolt DARTs since I would be
> very uncomfortable to have these running in (software or hardware) bypass mode.

Funnily enough that's the one case that would be relatively workable, 
since untrusted devices are currently subject to bounce-buffering of the 
entire DMA request, so it doesn't matter so much how the bounce buffer 
itself is mapped. Even with the possible future optimisation of only 
bouncing the non-page-aligned start and end parts of a buffer I think it 
still works (the physical alignment just has to be considered in terms 
of the IOMMU granule).

Robin.

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Sven Peter <sven@svenpeter.dev>, Will Deacon <will@kernel.org>,
	Joerg Roedel <joro@8bytes.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
	r.czerwinski@pengutronix.de, devicetree@vger.kernel.org,
	Marc Zyngier <maz@kernel.org>, Hector Martin <marcan@marcan.st>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	Rob Herring <robh+dt@kernel.org>,
	Alexander Graf <graf@amazon.com>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Mohamed Mediouni <mohamed.mediouni@caramail.com>,
	Mark Kettenis <mark.kettenis@xs4all.nl>,
	linux-arm-kernel@lists.infradead.org,
	Stan Skowronek <stan@corellium.com>
Subject: Re: [PATCH v4 0/3] Apple M1 DART IOMMU driver
Date: Wed, 14 Jul 2021 19:19:50 +0100	[thread overview]
Message-ID: <7261df01-34a9-4e53-37cd-ae1aa15b1fb4@arm.com> (raw)
In-Reply-To: <20210627143405.77298-1-sven@svenpeter.dev>

On 2021-06-27 15:34, Sven Peter wrote:
[...]
> In the long term, I'd like to extend the dma-iommu framework itself to
> support iommu pagesizes with a larger granule than the CPU pagesize if that is
> something you agree with.

BTW this isn't something we can fully support in general. IOMMU API 
users may expect this to work:

iommu_map(domain, iova, page_to_phys(p1), PAGE_SIZE, prot);
iommu_map(domain, iova + PAGE_SIZE, page_to_phys(p2), PAGE_SIZE, prot);

Although they do in principle have visibility of pgsize_bitmap, I still 
doubt anyone is really prepared for CPU-page-aligned mappings to fail.
Even at the DMA API level you could hide *some* of it (at the cost of 
effectively only having 1/4 of the usable address space), but there are 
still cases like where v4l2 has a hard requirement that a page-aligned 
scatterlist can be mapped into a contiguous region of DMA addresses.

> This would be important to later support the thunderbolt DARTs since I would be
> very uncomfortable to have these running in (software or hardware) bypass mode.

Funnily enough that's the one case that would be relatively workable, 
since untrusted devices are currently subject to bounce-buffering of the 
entire DMA request, so it doesn't matter so much how the bounce buffer 
itself is mapped. Even with the possible future optimisation of only 
bouncing the non-page-aligned start and end parts of a buffer I think it 
still works (the physical alignment just has to be considered in terms 
of the IOMMU granule).

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

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Sven Peter <sven@svenpeter.dev>, Will Deacon <will@kernel.org>,
	Joerg Roedel <joro@8bytes.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
	devicetree@vger.kernel.org, Hector Martin <marcan@marcan.st>,
	linux-kernel@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
	Mohamed Mediouni <mohamed.mediouni@caramail.com>,
	Stan Skowronek <stan@corellium.com>,
	linux-arm-kernel@lists.infradead.org,
	Mark Kettenis <mark.kettenis@xs4all.nl>,
	iommu@lists.linux-foundation.org,
	Alexander Graf <graf@amazon.com>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Rob Herring <robh+dt@kernel.org>,
	r.czerwinski@pengutronix.de
Subject: Re: [PATCH v4 0/3] Apple M1 DART IOMMU driver
Date: Wed, 14 Jul 2021 19:19:50 +0100	[thread overview]
Message-ID: <7261df01-34a9-4e53-37cd-ae1aa15b1fb4@arm.com> (raw)
In-Reply-To: <20210627143405.77298-1-sven@svenpeter.dev>

On 2021-06-27 15:34, Sven Peter wrote:
[...]
> In the long term, I'd like to extend the dma-iommu framework itself to
> support iommu pagesizes with a larger granule than the CPU pagesize if that is
> something you agree with.

BTW this isn't something we can fully support in general. IOMMU API 
users may expect this to work:

iommu_map(domain, iova, page_to_phys(p1), PAGE_SIZE, prot);
iommu_map(domain, iova + PAGE_SIZE, page_to_phys(p2), PAGE_SIZE, prot);

Although they do in principle have visibility of pgsize_bitmap, I still 
doubt anyone is really prepared for CPU-page-aligned mappings to fail.
Even at the DMA API level you could hide *some* of it (at the cost of 
effectively only having 1/4 of the usable address space), but there are 
still cases like where v4l2 has a hard requirement that a page-aligned 
scatterlist can be mapped into a contiguous region of DMA addresses.

> This would be important to later support the thunderbolt DARTs since I would be
> very uncomfortable to have these running in (software or hardware) bypass mode.

Funnily enough that's the one case that would be relatively workable, 
since untrusted devices are currently subject to bounce-buffering of the 
entire DMA request, so it doesn't matter so much how the bounce buffer 
itself is mapped. Even with the possible future optimisation of only 
bouncing the non-page-aligned start and end parts of a buffer I think it 
still works (the physical alignment just has to be considered in terms 
of the IOMMU granule).

Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-07-14 18:19 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-27 14:34 [PATCH v4 0/3] Apple M1 DART IOMMU driver Sven Peter
2021-06-27 14:34 ` Sven Peter
2021-06-27 14:34 ` Sven Peter via iommu
2021-06-27 14:34 ` [PATCH v4 1/3] iommu: io-pgtable: add DART pagetable format Sven Peter
2021-06-27 14:34   ` Sven Peter
2021-06-27 14:34   ` Sven Peter via iommu
2021-06-28 10:54   ` Alexander Graf
2021-06-28 10:54     ` Alexander Graf
2021-06-28 10:54     ` Alexander Graf via iommu
2021-06-29  7:37     ` Sven Peter
2021-06-29  7:37       ` Sven Peter
2021-06-29  7:37       ` Sven Peter via iommu
2021-06-29 12:04       ` Alexander Graf
2021-06-29 12:04         ` Alexander Graf
2021-06-29 12:04         ` Alexander Graf via iommu
2021-06-30 13:53   ` Alyssa Rosenzweig
2021-06-30 13:53     ` Alyssa Rosenzweig
2021-06-30 13:53     ` Alyssa Rosenzweig
2021-07-13 19:17   ` Robin Murphy
2021-07-13 19:17     ` Robin Murphy
2021-07-13 19:17     ` Robin Murphy
2021-07-14 17:39     ` Sven Peter
2021-07-14 17:39       ` Sven Peter
2021-07-14 17:39       ` Sven Peter via iommu
2021-06-27 14:34 ` [PATCH v4 2/3] dt-bindings: iommu: add DART iommu bindings Sven Peter
2021-06-27 14:34   ` Sven Peter
2021-06-27 14:34   ` Sven Peter via iommu
2021-06-30 13:54   ` Alyssa Rosenzweig
2021-06-30 13:54     ` Alyssa Rosenzweig
2021-06-30 13:54     ` Alyssa Rosenzweig
2021-06-27 14:34 ` [PATCH v4 3/3] iommu: dart: Add DART iommu driver Sven Peter
2021-06-27 14:34   ` Sven Peter
2021-06-27 14:34   ` Sven Peter via iommu
2021-06-30 13:49   ` Alyssa Rosenzweig
2021-06-30 13:49     ` Alyssa Rosenzweig
2021-06-30 13:49     ` Alyssa Rosenzweig
2021-07-12 11:02     ` Sven Peter
2021-07-12 11:02       ` Sven Peter
2021-07-12 11:02       ` Sven Peter via iommu
2021-07-12 13:53       ` Alyssa Rosenzweig
2021-07-12 13:53         ` Alyssa Rosenzweig
2021-07-12 13:53         ` Alyssa Rosenzweig
2021-07-13 23:23   ` Robin Murphy
2021-07-13 23:23     ` Robin Murphy
2021-07-13 23:23     ` Robin Murphy
2021-07-15 16:41     ` Sven Peter
2021-07-15 16:41       ` Sven Peter
2021-07-15 16:41       ` Sven Peter via iommu
2021-07-19 18:15       ` Robin Murphy
2021-07-19 18:15         ` Robin Murphy
2021-07-19 18:15         ` Robin Murphy
2021-07-25 12:40         ` Sven Peter
2021-07-25 12:40           ` Sven Peter
2021-07-25 12:40           ` Sven Peter via iommu
2021-07-26 13:19           ` Alyssa Rosenzweig
2021-07-26 13:19             ` Alyssa Rosenzweig
2021-07-26 13:19             ` Alyssa Rosenzweig
2021-07-14 18:19 ` Robin Murphy [this message]
2021-07-14 18:19   ` [PATCH v4 0/3] Apple M1 DART IOMMU driver Robin Murphy
2021-07-14 18:19   ` Robin Murphy
2021-07-14 20:51   ` Arnd Bergmann
2021-07-14 20:51     ` Arnd Bergmann
2021-07-14 20:51     ` Arnd Bergmann
2021-07-15  6:52     ` Joerg Roedel
2021-07-15  6:52       ` Joerg Roedel
2021-07-15  6:52       ` Joerg Roedel
2021-07-16  6:24   ` Christoph Hellwig
2021-07-16  6:24     ` Christoph Hellwig
2021-07-16  6:24     ` Christoph Hellwig
2021-07-16 15:32     ` Robin Murphy
2021-07-16 15:32       ` Robin Murphy
2021-07-16 15:32       ` 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=7261df01-34a9-4e53-37cd-ae1aa15b1fb4@arm.com \
    --to=robin.murphy@arm.com \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=arnd@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=graf@amazon.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=mark.kettenis@xs4all.nl \
    --cc=maz@kernel.org \
    --cc=mohamed.mediouni@caramail.com \
    --cc=r.czerwinski@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=stan@corellium.com \
    --cc=sven@svenpeter.dev \
    --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.