All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sven Peter" <sven@svenpeter.dev>
To: "Arnd Bergmann" <arnd@kernel.org>
Cc: "Robin Murphy" <robin.murphy@arm.com>,
	"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>,
	"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: Sat, 27 Mar 2021 16:30:41 +0100	[thread overview]
Message-ID: <c62dd4c1-2680-4eab-a2d7-fff390f3f11a@www.fastmail.com> (raw)
In-Reply-To: <CAK8P3a1+BOmT39k=OqFU+LtgfW=SDCp5W69YW58sVGf66mSppw@mail.gmail.com>



On Fri, Mar 26, 2021, at 20:59, Arnd Bergmann wrote:
> On Fri, Mar 26, 2021 at 6:51 PM Sven Peter <sven@svenpeter.dev> wrote:
> >   dart-sio: 0021c000 fbde4000 (at least their Secure Enclave/TPM co-processor)
> 
> Same here:
>     dart-sio {
>        vm-base = <0x0>;
>        vm-size = <0xfc000000>;
>        pio-vm-base = <0xfd000000>;
>       pio-vm-size = <0x2000000>;
>       pio-granularity = <0x1000000>;
>    }
> 
> There are clearly two distinct ranges that split up the 4GB space again,
> with a small hole of 16MB (==pio-granularity) at the end of each range.
> 
> The "pio" name might indicate that this is a range of addresses that
> can be programmed to point at I/O registers in another device, rather
> than pointing to RAM.
> 
>            Arnd
>

Very interesting observation!

Mark and I have discussed this a little bit further on IRC. Mark also successfully
used the PCIe DARTs with a DMA window outside of the one specified by vm-base/vm-size
in the ADT.

I believe that the (pio-)vm-base/size properties merely specify the ranges their
allocator uses and do not describe actual hardware limitations. Mark also suggested
that they might reserve memory at the beginning to find bugs similar to how one
might not allow to map memory at 0x0.

I have also done a few more experiments and figured out that if I put the IOMMU
into bypass mode (which doesn't seem to work for all IOMMUs/master combinations
which is why I'll leave it out of this series for now until I figure out more
details) I *can* use the full address space. I think the limitation
is therefore imposed by the translation hardware inside the IOMMU and not by
the bus/the interconnect.

If that's correct I think the right place to enforce this is to just limit
the aperture inside the DART driver to a 32bit address space whenever address
translation is enabled.


Thanks,

Sven


WARNING: multiple messages have this Message-ID (diff)
From: Sven Peter via iommu <iommu@lists.linux-foundation.org>
To: "Arnd Bergmann" <arnd@kernel.org>
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: Sat, 27 Mar 2021 16:30:41 +0100	[thread overview]
Message-ID: <c62dd4c1-2680-4eab-a2d7-fff390f3f11a@www.fastmail.com> (raw)
In-Reply-To: <CAK8P3a1+BOmT39k=OqFU+LtgfW=SDCp5W69YW58sVGf66mSppw@mail.gmail.com>



On Fri, Mar 26, 2021, at 20:59, Arnd Bergmann wrote:
> On Fri, Mar 26, 2021 at 6:51 PM Sven Peter <sven@svenpeter.dev> wrote:
> >   dart-sio: 0021c000 fbde4000 (at least their Secure Enclave/TPM co-processor)
> 
> Same here:
>     dart-sio {
>        vm-base = <0x0>;
>        vm-size = <0xfc000000>;
>        pio-vm-base = <0xfd000000>;
>       pio-vm-size = <0x2000000>;
>       pio-granularity = <0x1000000>;
>    }
> 
> There are clearly two distinct ranges that split up the 4GB space again,
> with a small hole of 16MB (==pio-granularity) at the end of each range.
> 
> The "pio" name might indicate that this is a range of addresses that
> can be programmed to point at I/O registers in another device, rather
> than pointing to RAM.
> 
>            Arnd
>

Very interesting observation!

Mark and I have discussed this a little bit further on IRC. Mark also successfully
used the PCIe DARTs with a DMA window outside of the one specified by vm-base/vm-size
in the ADT.

I believe that the (pio-)vm-base/size properties merely specify the ranges their
allocator uses and do not describe actual hardware limitations. Mark also suggested
that they might reserve memory at the beginning to find bugs similar to how one
might not allow to map memory at 0x0.

I have also done a few more experiments and figured out that if I put the IOMMU
into bypass mode (which doesn't seem to work for all IOMMUs/master combinations
which is why I'll leave it out of this series for now until I figure out more
details) I *can* use the full address space. I think the limitation
is therefore imposed by the translation hardware inside the IOMMU and not by
the bus/the interconnect.

If that's correct I think the right place to enforce this is to just limit
the aperture inside the DART driver to a 32bit address space whenever address
translation is enabled.


Thanks,

Sven

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

WARNING: multiple messages have this Message-ID (diff)
From: "Sven Peter" <sven@svenpeter.dev>
To: "Arnd Bergmann" <arnd@kernel.org>
Cc: "Robin Murphy" <robin.murphy@arm.com>,
	"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>,
	"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: Sat, 27 Mar 2021 16:30:41 +0100	[thread overview]
Message-ID: <c62dd4c1-2680-4eab-a2d7-fff390f3f11a@www.fastmail.com> (raw)
In-Reply-To: <CAK8P3a1+BOmT39k=OqFU+LtgfW=SDCp5W69YW58sVGf66mSppw@mail.gmail.com>



On Fri, Mar 26, 2021, at 20:59, Arnd Bergmann wrote:
> On Fri, Mar 26, 2021 at 6:51 PM Sven Peter <sven@svenpeter.dev> wrote:
> >   dart-sio: 0021c000 fbde4000 (at least their Secure Enclave/TPM co-processor)
> 
> Same here:
>     dart-sio {
>        vm-base = <0x0>;
>        vm-size = <0xfc000000>;
>        pio-vm-base = <0xfd000000>;
>       pio-vm-size = <0x2000000>;
>       pio-granularity = <0x1000000>;
>    }
> 
> There are clearly two distinct ranges that split up the 4GB space again,
> with a small hole of 16MB (==pio-granularity) at the end of each range.
> 
> The "pio" name might indicate that this is a range of addresses that
> can be programmed to point at I/O registers in another device, rather
> than pointing to RAM.
> 
>            Arnd
>

Very interesting observation!

Mark and I have discussed this a little bit further on IRC. Mark also successfully
used the PCIe DARTs with a DMA window outside of the one specified by vm-base/vm-size
in the ADT.

I believe that the (pio-)vm-base/size properties merely specify the ranges their
allocator uses and do not describe actual hardware limitations. Mark also suggested
that they might reserve memory at the beginning to find bugs similar to how one
might not allow to map memory at 0x0.

I have also done a few more experiments and figured out that if I put the IOMMU
into bypass mode (which doesn't seem to work for all IOMMUs/master combinations
which is why I'll leave it out of this series for now until I figure out more
details) I *can* use the full address space. I think the limitation
is therefore imposed by the translation hardware inside the IOMMU and not by
the bus/the interconnect.

If that's correct I think the right place to enforce this is to just limit
the aperture inside the DART driver to a 32bit address space whenever address
translation is enabled.


Thanks,

Sven


_______________________________________________
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-03-27 15:31 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
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 [this message]
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=c62dd4c1-2680-4eab-a2d7-fff390f3f11a@www.fastmail.com \
    --to=sven@svenpeter.dev \
    --cc=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=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.