All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anders Roxell <anders.roxell@linaro.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: sudeep.holla@arm.com,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	liviu.dudau@arm.com,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-stable <stable@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sasha Levin <sashal@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	lkft-triage@lists.linaro.org,
	Linux Kernel Functional Testing <lkft@linaro.org>
Subject: Re: [PATCH 2/2] arm64: dts: juno: Enable more SMMUs
Date: Fri, 30 Jul 2021 16:57:28 +0200	[thread overview]
Message-ID: <CADYN=9KV6u5ZTRWwpyNQt-FtnT3Fn0P6chQwodxOSg67_Qs7yg@mail.gmail.com> (raw)
In-Reply-To: <8b358507-dbdf-b05b-c1da-2ec9903a2912@arm.com>

On Fri, 30 Jul 2021 at 16:44, Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-07-30 15:34, Anders Roxell wrote:
> > On 2021-07-30 13:17, Robin Murphy wrote:
> >> On 2021-07-30 12:35, Anders Roxell wrote:
> >>> From: Robin Murphy <robin.murphy@arm.com>
> >>>
> >>>> Now that PCI inbound window restrictions are handled generically between
> >>>> the of_pci resource parsing and the IOMMU layer, and described in the
> >>>> Juno DT, we can finally enable the PCIe SMMU without the risk of DMA
> >>>> mappings inadvertently allocating unusable addresses.
> >>>>
> >>>> Similarly, the relevant support for IOMMU mappings for peripheral
> >>>> transfers has been hooked up in the pl330 driver for ages, so we can
> >>>> happily enable the DMA SMMU without that breaking anything either.
> >>>>
> >>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >>>
> >>> When we build a kernel with 64k page size and run the ltp syscalls we
> >>> sporadically see a kernel crash while doing a mkfs on a connected SATA
> >>> drive.  This is happening every third test run on any juno-r2 device in
> >>> the lab with the same kernel image (stable-rc 5.13.y, mainline and next)
> >>> with gcc-11.
> >>
> >> Hmm, I guess 64K pages might make a difference in that we'll chew through
> >> IOVA space a lot faster with small mappings...
> >>
> >> I'll have to try to reproduce this locally, since the interesting thing
> >> would be knowing what DMA address it was trying to use that went wrong, but
> >> IOMMU tracepoints and/or dma-debug are going to generate an crazy amount of
> >> data to sift through and try to correlate - having done it before it's not
> >> something I'd readily ask someone else to do for me :)
> >>
> >> On a hunch, though, does it make any difference if you remove the first
> >> entry from the PCIe "dma-ranges" (the 0x2c1c0000 one)?
> >
> > I did this change, and run the job 7 times and could not reproduce the
> > issue.
>
> Thanks! And hold that thought; if it works then I suspect it probably is
> the best fix, but I'll double-check and write it up properly next week.

Thank you Robin.

Cheers,
Anders

>
> Cheers,
> Robin.
>
> > diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> > index 8e7a66943b01..d3148730e951 100644
> > --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> > +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> > @@ -545,8 +545,7 @@ pcie_ctlr: pcie@40000000 {
> >                           <0x02000000 0x00 0x50000000 0x00 0x50000000 0x0 0x08000000>,
> >                           <0x42000000 0x40 0x00000000 0x40 0x00000000 0x1 0x00000000>;
> >                  /* Standard AXI Translation entries as programmed by EDK2 */
> > -               dma-ranges = <0x02000000 0x0 0x2c1c0000 0x0 0x2c1c0000 0x0 0x00040000>,
> > -                            <0x02000000 0x0 0x80000000 0x0 0x80000000 0x0 0x80000000>,
> > +               dma-ranges = <0x02000000 0x0 0x80000000 0x0 0x80000000 0x0 0x80000000>,
> >                               <0x43000000 0x8 0x00000000 0x8 0x00000000 0x2 0x00000000>;
> >                  #interrupt-cells = <1>;
> >                  interrupt-map-mask = <0 0 0 7>;
> >
> >
> > Cheers,
> > Anders
> >

WARNING: multiple messages have this Message-ID (diff)
From: Anders Roxell <anders.roxell@linaro.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: sudeep.holla@arm.com,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	liviu.dudau@arm.com,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 linux-stable <stable@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sasha Levin <sashal@kernel.org>,  Arnd Bergmann <arnd@arndb.de>,
	lkft-triage@lists.linaro.org,
	 Linux Kernel Functional Testing <lkft@linaro.org>
Subject: Re: [PATCH 2/2] arm64: dts: juno: Enable more SMMUs
Date: Fri, 30 Jul 2021 16:57:28 +0200	[thread overview]
Message-ID: <CADYN=9KV6u5ZTRWwpyNQt-FtnT3Fn0P6chQwodxOSg67_Qs7yg@mail.gmail.com> (raw)
In-Reply-To: <8b358507-dbdf-b05b-c1da-2ec9903a2912@arm.com>

On Fri, 30 Jul 2021 at 16:44, Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-07-30 15:34, Anders Roxell wrote:
> > On 2021-07-30 13:17, Robin Murphy wrote:
> >> On 2021-07-30 12:35, Anders Roxell wrote:
> >>> From: Robin Murphy <robin.murphy@arm.com>
> >>>
> >>>> Now that PCI inbound window restrictions are handled generically between
> >>>> the of_pci resource parsing and the IOMMU layer, and described in the
> >>>> Juno DT, we can finally enable the PCIe SMMU without the risk of DMA
> >>>> mappings inadvertently allocating unusable addresses.
> >>>>
> >>>> Similarly, the relevant support for IOMMU mappings for peripheral
> >>>> transfers has been hooked up in the pl330 driver for ages, so we can
> >>>> happily enable the DMA SMMU without that breaking anything either.
> >>>>
> >>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >>>
> >>> When we build a kernel with 64k page size and run the ltp syscalls we
> >>> sporadically see a kernel crash while doing a mkfs on a connected SATA
> >>> drive.  This is happening every third test run on any juno-r2 device in
> >>> the lab with the same kernel image (stable-rc 5.13.y, mainline and next)
> >>> with gcc-11.
> >>
> >> Hmm, I guess 64K pages might make a difference in that we'll chew through
> >> IOVA space a lot faster with small mappings...
> >>
> >> I'll have to try to reproduce this locally, since the interesting thing
> >> would be knowing what DMA address it was trying to use that went wrong, but
> >> IOMMU tracepoints and/or dma-debug are going to generate an crazy amount of
> >> data to sift through and try to correlate - having done it before it's not
> >> something I'd readily ask someone else to do for me :)
> >>
> >> On a hunch, though, does it make any difference if you remove the first
> >> entry from the PCIe "dma-ranges" (the 0x2c1c0000 one)?
> >
> > I did this change, and run the job 7 times and could not reproduce the
> > issue.
>
> Thanks! And hold that thought; if it works then I suspect it probably is
> the best fix, but I'll double-check and write it up properly next week.

Thank you Robin.

Cheers,
Anders

>
> Cheers,
> Robin.
>
> > diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> > index 8e7a66943b01..d3148730e951 100644
> > --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> > +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> > @@ -545,8 +545,7 @@ pcie_ctlr: pcie@40000000 {
> >                           <0x02000000 0x00 0x50000000 0x00 0x50000000 0x0 0x08000000>,
> >                           <0x42000000 0x40 0x00000000 0x40 0x00000000 0x1 0x00000000>;
> >                  /* Standard AXI Translation entries as programmed by EDK2 */
> > -               dma-ranges = <0x02000000 0x0 0x2c1c0000 0x0 0x2c1c0000 0x0 0x00040000>,
> > -                            <0x02000000 0x0 0x80000000 0x0 0x80000000 0x0 0x80000000>,
> > +               dma-ranges = <0x02000000 0x0 0x80000000 0x0 0x80000000 0x0 0x80000000>,
> >                               <0x43000000 0x8 0x00000000 0x8 0x00000000 0x2 0x00000000>;
> >                  #interrupt-cells = <1>;
> >                  interrupt-map-mask = <0 0 0 7>;
> >
> >
> > Cheers,
> > Anders
> >

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

  reply	other threads:[~2021-07-30 15:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05 17:33 [PATCH 1/2] arm64: dts: juno: Describe PCI dma-ranges Robin Murphy
2021-03-05 17:33 ` [PATCH 2/2] arm64: dts: juno: Enable more SMMUs Robin Murphy
2021-07-30 12:17   ` Robin Murphy
2021-07-30 12:17     ` Robin Murphy
2021-07-30 14:34     ` Anders Roxell
2021-07-30 14:34       ` Anders Roxell
2021-07-30 14:44       ` Robin Murphy
2021-07-30 14:44         ` Robin Murphy
2021-07-30 14:57         ` Anders Roxell [this message]
2021-07-30 14:57           ` Anders Roxell
2021-09-14  9:46         ` Anders Roxell
2021-09-14  9:46           ` Anders Roxell
2022-02-14 14:06           ` Naresh Kamboju
2022-02-14 14:06             ` Naresh Kamboju
2022-02-14 14:13             ` Sudeep Holla
2022-02-14 14:13               ` Sudeep Holla
2022-02-14 15:11               ` Naresh Kamboju
2022-02-14 15:11                 ` Naresh Kamboju
2022-02-16 11:32                 ` Naresh Kamboju
2022-02-16 11:32                   ` Naresh Kamboju
2022-02-16 14:31                   ` Sudeep Holla
2022-02-16 14:31                     ` Sudeep Holla
2021-03-09 12:01 ` [PATCH 1/2] arm64: dts: juno: Describe PCI dma-ranges Sudeep Holla
2021-03-23  9:30 ` Sudeep Holla
2021-03-23  9:30   ` Sudeep Holla

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='CADYN=9KV6u5ZTRWwpyNQt-FtnT3Fn0P6chQwodxOSg67_Qs7yg@mail.gmail.com' \
    --to=anders.roxell@linaro.org \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=lkft-triage@lists.linaro.org \
    --cc=lkft@linaro.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=sudeep.holla@arm.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 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.