From: Robin Murphy <robin.murphy@arm.com> To: Hanna Hawa <hannah@marvell.com>, catalin.marinas@arm.com, will.deacon@arm.com, corbet@lwn.net, joro@8bytes.org, robh+dt@kernel.org, gregory.clement@bootlin.com, mark.rutland@arm.com, jason@lakedaemon.net, andrew@lunn.ch, sebastian.hesselbarth@gmail.com Cc: linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, devicetree@vger.kernel.org, thomas.petazzoni@bootlin.com, nadavh@marvell.com, omrii@marvell.com, nd@arm.com Subject: Re: [PATCH 2/4] iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum #582743 Date: Thu, 18 Oct 2018 17:08:40 +0100 [thread overview] Message-ID: <38360fdf-8bc0-9fea-870f-fdb8b6103248@arm.com> (raw) In-Reply-To: <2e4f2b02-4b02-877d-1f51-c617170398a6@marvell.com> On 16/10/18 09:25, Hanna Hawa wrote: > Hi Robin, > > > On 10/15/2018 04:00 PM, Robin Murphy wrote: >> Hi Hanna, >> >> On 15/10/18 13:00, hannah@marvell.com wrote: >>> From: Hanna Hawa <hannah@marvell.com> >>> >>> Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit >>> to ARM SMMUv2 registers. >>> This patch split the writeq/readq to two accesses of writel/readl. >>> >>> Note that separate writes/reads to 2 is not problem regards to >>> atomicity, >>> because the driver use the readq/writeq while initialize the SMMU, >>> report >>> for SMMU fault, and use spinlock in one case (iova_to_phys). >> >> In general, this doesn't work. Here's what the SMMU spec says about >> SMMU_CBn_TLBIVA, but others are similar: >> >> "If SMMU_CBA2Rn.VA64 is one, then AArch64 format is selected. The >> programmer should use 64 bit accesses to this register. If 32-bit >> accesses are used then writes to the top 32 bits are ignored and writes >> to the lower 32 bits are zero extended." >> >> If your interconnect won't let 64-bit transactions through, then you >> can't use AArch64 format at stage 1 at all, since there's no way to >> invalidate entries with the correct ASID, and you'll have to restrict >> stage 2 formats to at most 44-bit IOVAs in order for TLBIIPAS2{L} not to >> invalidate the wrong thing. > Thanks for your suggestion. > > To restrict the IOVAs i need to add another work-around to the driver to > limit the va_size, is that acceptable? Yeah, constraining AArch64 stage 2 to 44 bits should just be a case of adjusting smmu->ipa_size at probe time, but you'd still need to add the writel()-based TLBI path to take advantage of it. How big is the physical memory map on these SoCs? If everything fits into 40 bits then I think you could get away with simply hiding the SMMU_IDR2.PTFSv8 fields to sidestep the AArch64 formats altogether, and everything else should fall out in the wash. Otherwise, you'll have to just disable stage 1 support in addition to the stage 2 workaround as above. > What the different in the driver between AARCH32_L & AARCH32_S? AARCH32_L is the 3-level LPAE format, which gives you 32-bit input/40-bit output at stage 1 and 40-bit input/40-bit output at stage 2. AARCH32_S is the legacy 2-level short-descriptor format which only supports stage 1 and is limited to 32-bit output addresses - MMU-500 does support it, but you probably want to avoid it if possible ;) Robin.
WARNING: multiple messages have this Message-ID (diff)
From: robin.murphy@arm.com (Robin Murphy) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 2/4] iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum #582743 Date: Thu, 18 Oct 2018 17:08:40 +0100 [thread overview] Message-ID: <38360fdf-8bc0-9fea-870f-fdb8b6103248@arm.com> (raw) In-Reply-To: <2e4f2b02-4b02-877d-1f51-c617170398a6@marvell.com> On 16/10/18 09:25, Hanna Hawa wrote: > Hi Robin, > > > On 10/15/2018 04:00 PM, Robin Murphy wrote: >> Hi Hanna, >> >> On 15/10/18 13:00, hannah at marvell.com wrote: >>> From: Hanna Hawa <hannah@marvell.com> >>> >>> Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit >>> to ARM SMMUv2 registers. >>> This patch split the writeq/readq to two accesses of writel/readl. >>> >>> Note that separate writes/reads to 2 is not problem regards to >>> atomicity, >>> because the driver use the readq/writeq while initialize the SMMU, >>> report >>> for SMMU fault, and use spinlock in one case (iova_to_phys). >> >> In general, this doesn't work. Here's what the SMMU spec says about >> SMMU_CBn_TLBIVA, but others are similar: >> >> "If SMMU_CBA2Rn.VA64 is one, then AArch64 format is selected. The >> programmer should use 64 bit accesses to this register. If 32-bit >> accesses are used then writes to the top 32 bits are ignored and writes >> to the lower 32 bits are zero extended." >> >> If your interconnect won't let 64-bit transactions through, then you >> can't use AArch64 format at stage 1 at all, since there's no way to >> invalidate entries with the correct ASID, and you'll have to restrict >> stage 2 formats to at most 44-bit IOVAs in order for TLBIIPAS2{L} not to >> invalidate the wrong thing. > Thanks for your suggestion. > > To restrict the IOVAs i need to add another work-around to the driver to > limit the va_size, is that acceptable? Yeah, constraining AArch64 stage 2 to 44 bits should just be a case of adjusting smmu->ipa_size at probe time, but you'd still need to add the writel()-based TLBI path to take advantage of it. How big is the physical memory map on these SoCs? If everything fits into 40 bits then I think you could get away with simply hiding the SMMU_IDR2.PTFSv8 fields to sidestep the AArch64 formats altogether, and everything else should fall out in the wash. Otherwise, you'll have to just disable stage 1 support in addition to the stage 2 workaround as above. > What the different in the driver between AARCH32_L & AARCH32_S? AARCH32_L is the 3-level LPAE format, which gives you 32-bit input/40-bit output at stage 1 and 40-bit input/40-bit output at stage 2. AARCH32_S is the legacy 2-level short-descriptor format which only supports stage 1 and is limited to 32-bit output addresses - MMU-500 does support it, but you probably want to avoid it if possible ;) Robin.
next prev parent reply other threads:[~2018-10-18 16:08 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-15 12:00 [PATCH 0/4] Add system mmu support for Armada-806 hannah 2018-10-15 12:00 ` hannah at marvell.com 2018-10-15 12:00 ` hannah 2018-10-15 12:00 ` [PATCH 1/4] iommu/arm-smmu: introduce wrapper for writeq/readq hannah 2018-10-15 12:00 ` hannah at marvell.com 2018-10-15 12:00 ` hannah 2018-10-15 12:00 ` [PATCH 2/4] iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum #582743 hannah 2018-10-15 12:00 ` hannah at marvell.com 2018-10-15 12:00 ` hannah 2018-10-15 13:00 ` Robin Murphy 2018-10-15 13:00 ` Robin Murphy 2018-10-15 13:00 ` Robin Murphy 2018-10-16 8:25 ` Hanna Hawa 2018-10-16 8:25 ` Hanna Hawa 2018-10-16 8:25 ` Hanna Hawa 2018-10-18 16:08 ` Robin Murphy [this message] 2018-10-18 16:08 ` Robin Murphy 2018-10-15 12:00 ` [PATCH 3/4] dt-bindings: iommu/arm,smmu: add compatible string for Marvell hannah 2018-10-15 12:00 ` [PATCH 3/4] dt-bindings: iommu/arm, smmu: " hannah at marvell.com 2018-10-15 12:00 ` hannah 2018-10-15 13:11 ` Robin Murphy 2018-10-15 13:11 ` Robin Murphy 2018-10-18 20:48 ` Rob Herring 2018-10-18 20:48 ` Rob Herring 2018-10-18 20:48 ` Rob Herring 2018-10-15 12:00 ` [PATCH 4/4] arm64: dts: marvell: add smmu node for Armada-AP806 hannah 2018-10-15 12:00 ` hannah at marvell.com 2018-10-15 12:00 ` hannah
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=38360fdf-8bc0-9fea-870f-fdb8b6103248@arm.com \ --to=robin.murphy@arm.com \ --cc=andrew@lunn.ch \ --cc=catalin.marinas@arm.com \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=gregory.clement@bootlin.com \ --cc=hannah@marvell.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jason@lakedaemon.net \ --cc=joro@8bytes.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=nadavh@marvell.com \ --cc=nd@arm.com \ --cc=omrii@marvell.com \ --cc=robh+dt@kernel.org \ --cc=sebastian.hesselbarth@gmail.com \ --cc=thomas.petazzoni@bootlin.com \ --cc=will.deacon@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: linkBe 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.