From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2 4/4] iommu/arm-smmu-v3: Support 52-bit virtual address
Date: Mon, 26 Feb 2018 18:05:09 +0000 [thread overview]
Message-ID: <20180226180508.GE26147@arm.com> (raw)
In-Reply-To: <15d196d9a8e160c5df0e0340e23a432482389f9f.1512038236.git.robin.murphy@arm.com>
On Thu, Dec 14, 2017 at 04:58:53PM +0000, Robin Murphy wrote:
> Stage 1 input addresses are effectively 64-bit in SMMUv3 anyway, so
> really all that's involved is letting io-pgtable know the appropriate
> upper bound for T0SZ.
>
> Tested-by: Nate Watterson <nwatters@codeaurora•org>
> Signed-off-by: Robin Murphy <robin.murphy@arm•com>
> ---
>
> v2: No change
>
> drivers/iommu/arm-smmu-v3.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index c9c4e6132e27..7059a0805bd1 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -102,6 +102,7 @@
> #define IDR5_OAS_44_BIT (4 << IDR5_OAS_SHIFT)
> #define IDR5_OAS_48_BIT (5 << IDR5_OAS_SHIFT)
> #define IDR5_OAS_52_BIT (6 << IDR5_OAS_SHIFT)
> +#define IDR5_VAX (1 << 10)
I think this is actually a two-bit field, so we should check the whole
thing.
>
> #define ARM_SMMU_CR0 0x20
> #define CR0_CMDQEN (1 << 3)
> @@ -604,6 +605,7 @@ struct arm_smmu_device {
> #define ARM_SMMU_FEAT_STALLS (1 << 11)
> #define ARM_SMMU_FEAT_HYP (1 << 12)
> #define ARM_SMMU_FEAT_STALL_FORCE (1 << 13)
> +#define ARM_SMMU_FEAT_VAX (1 << 14)
> u32 features;
>
> #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
> @@ -1656,6 +1658,8 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain)
> switch (smmu_domain->stage) {
> case ARM_SMMU_DOMAIN_S1:
> ias = VA_BITS;
> + if (VA_BITS > 48 && !(smmu->features & ARM_SMMU_FEAT_VAX))
nit, but I'd rather the if condition was checking ias instead of VA_BITS.
> + ias = 48;
> oas = smmu->ias;
Should we also be sanitising the oas here if the SMMU doesn't support 64k
pages? It looks like the ias/oas sanitisation isn't cleanly split between
the pgtable code and the SMMU driver.
Will
next prev parent reply other threads:[~2018-02-26 18:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-14 16:58 [PATCH v2 0/4] SMMU 52-bit address support Robin Murphy
2017-12-14 16:58 ` [PATCH v2 1/4] iommu/arm-smmu-v3: Clean up address masking Robin Murphy
2018-02-26 18:04 ` Will Deacon
2018-02-27 13:28 ` Robin Murphy
2018-03-06 16:02 ` Will Deacon
2017-12-14 16:58 ` [PATCH v2 2/4] iommu/io-pgtable-arm: Support 52-bit physical address Robin Murphy
2018-02-26 18:05 ` Will Deacon
2018-02-27 13:49 ` Robin Murphy
2018-03-06 17:54 ` Will Deacon
2017-12-14 16:58 ` [PATCH v2 3/4] iommu/arm-smmu-v3: " Robin Murphy
2018-02-26 18:05 ` Will Deacon
2017-12-14 16:58 ` [PATCH v2 4/4] iommu/arm-smmu-v3: Support 52-bit virtual address Robin Murphy
2018-02-26 18:05 ` Will Deacon [this message]
2018-02-27 13:57 ` Robin Murphy
2018-02-26 18:04 ` [PATCH v2 0/4] SMMU 52-bit address support Will Deacon
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=20180226180508.GE26147@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox