All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: Sven Peter <sven@svenpeter.dev>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>,
	Rob Herring <robh@kernel.org>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Hector Martin <marcan@marcan.st>, Marc Zyngier <maz@kernel.org>,
	Mohamed Mediouni <mohamed.mediouni@caramail.com>,
	Stan Skowronek <stan@corellium.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>
Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver
Date: Fri, 26 Mar 2021 17:38:24 +0100	[thread overview]
Message-ID: <CAK8P3a2b7k6JkxecW=yu-NF+fkNCxJ3Ja36nQ7LK8hsuO=4=sw@mail.gmail.com> (raw)
In-Reply-To: <9f06872d-f0ec-43c3-9b53-d144337100b3@www.fastmail.com>

On Fri, Mar 26, 2021 at 5:10 PM Sven Peter <sven@svenpeter.dev> wrote:
> On Fri, Mar 26, 2021, at 16:59, Mark Kettenis wrote:
> > Some of the DARTs provide a bypass facility.  That code make using the
> > standard "dma-ranges" property tricky.  That property would need to
> > contain the bypass address range.  But that would mean that if the
> > DART driver needs to look at that property to figure out the address
> > range that supports translation it will need to be able to distinguish
> > between the translatable address range and the bypass address range.
>
> Do we understand if and why we even need to bypass certain streams?

My guess is that this is a performance optimization.

There are generally three reasons to want an iommu in the first place:
 - Pass a device down to a guest or user process without giving
   access to all of memory
 - Avoid problems with limitations in the device, typically when it
only supports
   32-bit bus addressing, but the installed memory is larger than 4GB
 - Protect kernel memory from broken drivers

If you care about none of the above, but you do care about data transfer
speed, you are better off just leaving the IOMMU in bypass mode.
I don't think we have to support it if the IOMMU works reliably, but it's
something that users might want.

        Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Sven Peter <sven@svenpeter.dev>
Cc: Rob Herring <robh@kernel.org>, DTML <devicetree@vger.kernel.org>,
	Will Deacon <will@kernel.org>, Hector Martin <marcan@marcan.st>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Marc Zyngier <maz@kernel.org>,
	Mohamed Mediouni <mohamed.mediouni@caramail.com>,
	Stan Skowronek <stan@corellium.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Mark Kettenis <mark.kettenis@xs4all.nl>
Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver
Date: Fri, 26 Mar 2021 17:38:24 +0100	[thread overview]
Message-ID: <CAK8P3a2b7k6JkxecW=yu-NF+fkNCxJ3Ja36nQ7LK8hsuO=4=sw@mail.gmail.com> (raw)
In-Reply-To: <9f06872d-f0ec-43c3-9b53-d144337100b3@www.fastmail.com>

On Fri, Mar 26, 2021 at 5:10 PM Sven Peter <sven@svenpeter.dev> wrote:
> On Fri, Mar 26, 2021, at 16:59, Mark Kettenis wrote:
> > Some of the DARTs provide a bypass facility.  That code make using the
> > standard "dma-ranges" property tricky.  That property would need to
> > contain the bypass address range.  But that would mean that if the
> > DART driver needs to look at that property to figure out the address
> > range that supports translation it will need to be able to distinguish
> > between the translatable address range and the bypass address range.
>
> Do we understand if and why we even need to bypass certain streams?

My guess is that this is a performance optimization.

There are generally three reasons to want an iommu in the first place:
 - Pass a device down to a guest or user process without giving
   access to all of memory
 - Avoid problems with limitations in the device, typically when it
only supports
   32-bit bus addressing, but the installed memory is larger than 4GB
 - Protect kernel memory from broken drivers

If you care about none of the above, but you do care about data transfer
speed, you are better off just leaving the IOMMU in bypass mode.
I don't think we have to support it if the IOMMU works reliably, but it's
something that users might want.

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

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Sven Peter <sven@svenpeter.dev>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>,
	Rob Herring <robh@kernel.org>,
	 "open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>,  Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Hector Martin <marcan@marcan.st>,  Marc Zyngier <maz@kernel.org>,
	Mohamed Mediouni <mohamed.mediouni@caramail.com>,
	Stan Skowronek <stan@corellium.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>
Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver
Date: Fri, 26 Mar 2021 17:38:24 +0100	[thread overview]
Message-ID: <CAK8P3a2b7k6JkxecW=yu-NF+fkNCxJ3Ja36nQ7LK8hsuO=4=sw@mail.gmail.com> (raw)
In-Reply-To: <9f06872d-f0ec-43c3-9b53-d144337100b3@www.fastmail.com>

On Fri, Mar 26, 2021 at 5:10 PM Sven Peter <sven@svenpeter.dev> wrote:
> On Fri, Mar 26, 2021, at 16:59, Mark Kettenis wrote:
> > Some of the DARTs provide a bypass facility.  That code make using the
> > standard "dma-ranges" property tricky.  That property would need to
> > contain the bypass address range.  But that would mean that if the
> > DART driver needs to look at that property to figure out the address
> > range that supports translation it will need to be able to distinguish
> > between the translatable address range and the bypass address range.
>
> Do we understand if and why we even need to bypass certain streams?

My guess is that this is a performance optimization.

There are generally three reasons to want an iommu in the first place:
 - Pass a device down to a guest or user process without giving
   access to all of memory
 - Avoid problems with limitations in the device, typically when it
only supports
   32-bit bus addressing, but the installed memory is larger than 4GB
 - Protect kernel memory from broken drivers

If you care about none of the above, but you do care about data transfer
speed, you are better off just leaving the IOMMU in bypass mode.
I don't think we have to support it if the IOMMU works reliably, but it's
something that users might want.

        Arnd

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

  reply	other threads:[~2021-03-26 16:39 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-20 15:19 [PATCH 0/3] Apple M1 DART IOMMU driver Sven Peter
2021-03-20 15:19 ` Sven Peter
2021-03-20 15:19 ` Sven Peter via iommu
2021-03-20 15:19 ` [PATCH 1/3] iommu: io-pgtable: add DART pagetable format Sven Peter
2021-03-20 15:19   ` Sven Peter
2021-03-20 15:19   ` Sven Peter via iommu
2021-03-24 16:37   ` Robin Murphy
2021-03-24 16:37     ` Robin Murphy
2021-03-24 16:37     ` Robin Murphy
2021-03-25 20:47     ` Sven Peter
2021-03-25 20:47       ` Sven Peter
2021-03-25 20:47       ` Sven Peter via iommu
2021-03-20 15:20 ` [PATCH 2/3] dt-bindings: iommu: add DART iommu bindings Sven Peter
2021-03-20 15:20   ` Sven Peter
2021-03-20 15:20   ` Sven Peter via iommu
2021-03-22  0:15   ` Rob Herring
2021-03-22  0:15     ` Rob Herring
2021-03-22  0:15     ` Rob Herring
2021-03-22 18:16     ` Sven Peter
2021-03-22 18:16       ` Sven Peter
2021-03-22 18:16       ` Sven Peter via iommu
2021-03-21 16:00 ` [PATCH 0/3] Apple M1 DART IOMMU driver Mark Kettenis
2021-03-21 16:00   ` Mark Kettenis
2021-03-21 16:00   ` Mark Kettenis
2021-03-21 17:22   ` Sven Peter via iommu
2021-03-21 18:35     ` Mark Kettenis
2021-03-21 18:35       ` Mark Kettenis
2021-03-21 18:35       ` Mark Kettenis
2021-03-22 22:17       ` Sven Peter
2021-03-22 22:17         ` Sven Peter
2021-03-22 22:17         ` Sven Peter via iommu
2021-03-23 20:00         ` Mark Kettenis
2021-03-23 20:00           ` Mark Kettenis
2021-03-23 20:00           ` Mark Kettenis
2021-03-23 21:03           ` Sven Peter
2021-03-23 21:03             ` Sven Peter
2021-03-23 21:03             ` Sven Peter via iommu
2021-03-21 17:28   ` Sven Peter
2021-03-21 17:28     ` Sven Peter
2021-03-21 17:28     ` Sven Peter via iommu
2021-03-23 20:53   ` Rob Herring
2021-03-23 20:53     ` Rob Herring
2021-03-23 20:53     ` Rob Herring
2021-03-23 22:33     ` Mark Kettenis
2021-03-23 22:33       ` Mark Kettenis
2021-03-23 22:33       ` Mark Kettenis
2021-03-25  7:53     ` Sven Peter
2021-03-25  7:53       ` Sven Peter
2021-03-25  7:53       ` Sven Peter via iommu
2021-03-25 11:50       ` Robin Murphy
2021-03-25 11:50         ` Robin Murphy
2021-03-25 11:50         ` Robin Murphy
2021-03-25 20:49         ` Sven Peter
2021-03-25 20:49           ` Sven Peter
2021-03-25 20:49           ` Sven Peter via iommu
2021-03-27 15:33         ` Sven Peter
2021-03-27 15:33           ` Sven Peter
2021-03-27 15:33           ` Sven Peter via iommu
2021-03-25 21:41       ` Arnd Bergmann
2021-03-25 21:41         ` Arnd Bergmann
2021-03-25 21:41         ` Arnd Bergmann
2021-03-26 15:59         ` Mark Kettenis
2021-03-26 15:59           ` Mark Kettenis
2021-03-26 15:59           ` Mark Kettenis
2021-03-26 16:09           ` Arnd Bergmann
2021-03-26 16:09             ` Arnd Bergmann
2021-03-26 16:09             ` Arnd Bergmann
2021-03-26 16:10           ` Sven Peter
2021-03-26 16:10             ` Sven Peter
2021-03-26 16:10             ` Sven Peter via iommu
2021-03-26 16:38             ` Arnd Bergmann [this message]
2021-03-26 16:38               ` Arnd Bergmann
2021-03-26 16:38               ` Arnd Bergmann
2021-03-26 17:06               ` Sven Peter
2021-03-26 17:06                 ` Sven Peter
2021-03-26 17:06                 ` Sven Peter via iommu
2021-03-26 17:26               ` Mark Kettenis
2021-03-26 17:26                 ` Mark Kettenis
2021-03-26 17:26                 ` Mark Kettenis
2021-03-26 17:34                 ` Robin Murphy
2021-03-26 17:34                   ` Robin Murphy
2021-03-26 17:34                   ` Robin Murphy
2021-03-26 17:51                   ` Sven Peter
2021-03-26 17:51                     ` Sven Peter
2021-03-26 17:51                     ` Sven Peter via iommu
2021-03-26 19:59                     ` Arnd Bergmann
2021-03-26 19:59                       ` Arnd Bergmann
2021-03-26 19:59                       ` Arnd Bergmann
2021-03-26 21:16                       ` Mark Kettenis
2021-03-26 21:16                         ` Mark Kettenis
2021-03-26 21:16                         ` Mark Kettenis
2021-03-27 15:30                       ` Sven Peter
2021-03-27 15:30                         ` Sven Peter
2021-03-27 15:30                         ` Sven Peter via iommu
2021-03-26 20:03                 ` Arnd Bergmann
2021-03-26 20:03                   ` Arnd Bergmann
2021-03-26 20:03                   ` Arnd Bergmann
2021-03-26 21:13                   ` Mark Kettenis
2021-03-26 21:13                     ` Mark Kettenis
2021-03-26 21:13                     ` Mark Kettenis
2021-03-24 15:29 ` Robin Murphy
2021-03-24 15:29   ` Robin Murphy
2021-03-24 15:29   ` Robin Murphy
2021-03-25  7:58   ` Sven Peter
2021-03-25  7:58     ` Sven Peter
2021-03-25  7:58     ` Sven Peter via iommu

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='CAK8P3a2b7k6JkxecW=yu-NF+fkNCxJ3Ja36nQ7LK8hsuO=4=sw@mail.gmail.com' \
    --to=arnd@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --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=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --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.