From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "fenghua.yu@intel.com" <fenghua.yu@intel.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
"will@kernel.org" <will@kernel.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"zhangfei.gao@linaro.org" <zhangfei.gao@linaro.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>
Subject: RE: [PATCH v10 10/13] iommu/arm-smmu-v3: Check for SVA features
Date: Mon, 21 Sep 2020 08:59:39 +0000 [thread overview]
Message-ID: <753bcd76c21c4ea98ef1d4e492db01f4@huawei.com> (raw)
In-Reply-To: <20200918101852.582559-11-jean-philippe@linaro.org>
Hi Jean,
> -----Original Message-----
> From: iommu [mailto:iommu-bounces@lists.linux-foundation.org] On Behalf Of
> Jean-Philippe Brucker
> Sent: 18 September 2020 11:19
> To: iommu@lists.linux-foundation.org; linux-arm-kernel@lists.infradead.org;
> linux-mm@kvack.org
> Cc: fenghua.yu@intel.com; Jean-Philippe Brucker <jean-philippe@linaro.org>;
> catalin.marinas@arm.com; Suzuki K Poulose <suzuki.poulose@arm.com>;
> robin.murphy@arm.com; zhangfei.gao@linaro.org; will@kernel.org
> Subject: [PATCH v10 10/13] iommu/arm-smmu-v3: Check for SVA features
>
> Aggregate all sanity-checks for sharing CPU page tables with the SMMU
> under a single ARM_SMMU_FEAT_SVA bit. For PCIe SVA, users also need to
> check FEAT_ATS and FEAT_PRI. For platform SVA, they will have to check
> FEAT_STALLS.
>
> Introduce ARM_SMMU_FEAT_BTM (Broadcast TLB Maintenance), but don't
> enable it at the moment. Since the entire VMID space is shared with the
> CPU, enabling DVM (by clearing SMMU_CR2.PTM) could result in
> over-invalidation and affect performance of stage-2 mappings.
>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> v10:
> * Check that 52-bit VA is supported on the SMMU side if vabits_actual
> requires it.
> * Check arm64_kernel_unmapped_at_el0() instead of
> CONFIG_UNMAP_KERNEL_AT_EL0
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 10 +++++
> .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 45
> +++++++++++++++++++
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 ++
> 3 files changed, 58 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index 90c08f156b43..7b14b48a26c7 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -602,6 +602,8 @@ struct arm_smmu_device {
> #define ARM_SMMU_FEAT_STALL_FORCE (1 << 13)
> #define ARM_SMMU_FEAT_VAX (1 << 14)
> #define ARM_SMMU_FEAT_RANGE_INV (1 << 15)
> +#define ARM_SMMU_FEAT_BTM (1 << 16)
> +#define ARM_SMMU_FEAT_SVA (1 << 17)
> u32 features;
>
> #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
> @@ -683,4 +685,12 @@ int arm_smmu_write_ctx_desc(struct
> arm_smmu_domain *smmu_domain, int ssid,
> void arm_smmu_tlb_inv_asid(struct arm_smmu_device *smmu, u16 asid);
> bool arm_smmu_free_asid(struct arm_smmu_ctx_desc *cd);
>
> +#ifdef CONFIG_ARM_SMMU_V3_SVA
> +bool arm_smmu_sva_supported(struct arm_smmu_device *smmu);
> +#else /* CONFIG_ARM_SMMU_V3_SVA */
> +static inline bool arm_smmu_sva_supported(struct arm_smmu_device
> *smmu)
> +{
> + return false;
> +}
> +#endif /* CONFIG_ARM_SMMU_V3_SVA */
> #endif /* _ARM_SMMU_V3_H */
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> index ef3fcfa72187..cb94c0924196 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> @@ -152,3 +152,48 @@ static void arm_smmu_free_shared_cd(struct
> arm_smmu_ctx_desc *cd)
> kfree(cd);
> }
> }
> +
> +bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
> +{
> + unsigned long reg, fld;
> + unsigned long oas;
> + unsigned long asid_bits;
> + u32 feat_mask = ARM_SMMU_FEAT_BTM |
> ARM_SMMU_FEAT_COHERENCY;
Why is BTM mandated for SVA? I couldn't find this requirement in SMMU spec
(Sorry if I missed it or this got discussed earlier). But if performance is the only concern here,
is it better just to allow it with a warning rather than limiting SMMUs without BTM?
Thanks,
Shameer
> +
> + if (vabits_actual == 52)
> + feat_mask |= ARM_SMMU_FEAT_VAX;
> +
> + if ((smmu->features & feat_mask) != feat_mask)
> + return false;
> +
> + if (!(smmu->pgsize_bitmap & PAGE_SIZE))
> + return false;
> +
> + /*
> + * Get the smallest PA size of all CPUs (sanitized by cpufeature). We're
> + * not even pretending to support AArch32 here. Abort if the MMU
> outputs
> + * addresses larger than what we support.
> + */
> + reg = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
> + fld = cpuid_feature_extract_unsigned_field(reg,
> ID_AA64MMFR0_PARANGE_SHIFT);
> + oas = id_aa64mmfr0_parange_to_phys_shift(fld);
> + if (smmu->oas < oas)
> + return false;
> +
> + /* We can support bigger ASIDs than the CPU, but not smaller */
> + fld = cpuid_feature_extract_unsigned_field(reg,
> ID_AA64MMFR0_ASID_SHIFT);
> + asid_bits = fld ? 16 : 8;
> + if (smmu->asid_bits < asid_bits)
> + return false;
> +
> + /*
> + * See max_pinned_asids in arch/arm64/mm/context.c. The following is
> + * generally the maximum number of bindable processes.
> + */
> + if (arm64_kernel_unmapped_at_el0())
> + asid_bits--;
> + dev_dbg(smmu->dev, "%d shared contexts\n", (1 << asid_bits) -
> + num_possible_cpus() - 2);
> +
> + return true;
> +}
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e99ebdd4c841..44c57bcfe112 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -3257,6 +3257,9 @@ static int arm_smmu_device_hw_probe(struct
> arm_smmu_device *smmu)
>
> smmu->ias = max(smmu->ias, smmu->oas);
>
> + if (arm_smmu_sva_supported(smmu))
> + smmu->features |= ARM_SMMU_FEAT_SVA;
> +
> dev_info(smmu->dev, "ias %lu-bit, oas %lu-bit (features 0x%08x)\n",
> smmu->ias, smmu->oas, smmu->features);
> return 0;
> --
> 2.28.0
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "fenghua.yu@intel.com" <fenghua.yu@intel.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
"will@kernel.org" <will@kernel.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"zhangfei.gao@linaro.org" <zhangfei.gao@linaro.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>
Subject: RE: [PATCH v10 10/13] iommu/arm-smmu-v3: Check for SVA features
Date: Mon, 21 Sep 2020 08:59:39 +0000 [thread overview]
Message-ID: <753bcd76c21c4ea98ef1d4e492db01f4@huawei.com> (raw)
In-Reply-To: <20200918101852.582559-11-jean-philippe@linaro.org>
Hi Jean,
> -----Original Message-----
> From: iommu [mailto:iommu-bounces@lists.linux-foundation.org] On Behalf Of
> Jean-Philippe Brucker
> Sent: 18 September 2020 11:19
> To: iommu@lists.linux-foundation.org; linux-arm-kernel@lists.infradead.org;
> linux-mm@kvack.org
> Cc: fenghua.yu@intel.com; Jean-Philippe Brucker <jean-philippe@linaro.org>;
> catalin.marinas@arm.com; Suzuki K Poulose <suzuki.poulose@arm.com>;
> robin.murphy@arm.com; zhangfei.gao@linaro.org; will@kernel.org
> Subject: [PATCH v10 10/13] iommu/arm-smmu-v3: Check for SVA features
>
> Aggregate all sanity-checks for sharing CPU page tables with the SMMU
> under a single ARM_SMMU_FEAT_SVA bit. For PCIe SVA, users also need to
> check FEAT_ATS and FEAT_PRI. For platform SVA, they will have to check
> FEAT_STALLS.
>
> Introduce ARM_SMMU_FEAT_BTM (Broadcast TLB Maintenance), but don't
> enable it at the moment. Since the entire VMID space is shared with the
> CPU, enabling DVM (by clearing SMMU_CR2.PTM) could result in
> over-invalidation and affect performance of stage-2 mappings.
>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> v10:
> * Check that 52-bit VA is supported on the SMMU side if vabits_actual
> requires it.
> * Check arm64_kernel_unmapped_at_el0() instead of
> CONFIG_UNMAP_KERNEL_AT_EL0
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 10 +++++
> .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 45
> +++++++++++++++++++
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 ++
> 3 files changed, 58 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index 90c08f156b43..7b14b48a26c7 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -602,6 +602,8 @@ struct arm_smmu_device {
> #define ARM_SMMU_FEAT_STALL_FORCE (1 << 13)
> #define ARM_SMMU_FEAT_VAX (1 << 14)
> #define ARM_SMMU_FEAT_RANGE_INV (1 << 15)
> +#define ARM_SMMU_FEAT_BTM (1 << 16)
> +#define ARM_SMMU_FEAT_SVA (1 << 17)
> u32 features;
>
> #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
> @@ -683,4 +685,12 @@ int arm_smmu_write_ctx_desc(struct
> arm_smmu_domain *smmu_domain, int ssid,
> void arm_smmu_tlb_inv_asid(struct arm_smmu_device *smmu, u16 asid);
> bool arm_smmu_free_asid(struct arm_smmu_ctx_desc *cd);
>
> +#ifdef CONFIG_ARM_SMMU_V3_SVA
> +bool arm_smmu_sva_supported(struct arm_smmu_device *smmu);
> +#else /* CONFIG_ARM_SMMU_V3_SVA */
> +static inline bool arm_smmu_sva_supported(struct arm_smmu_device
> *smmu)
> +{
> + return false;
> +}
> +#endif /* CONFIG_ARM_SMMU_V3_SVA */
> #endif /* _ARM_SMMU_V3_H */
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> index ef3fcfa72187..cb94c0924196 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> @@ -152,3 +152,48 @@ static void arm_smmu_free_shared_cd(struct
> arm_smmu_ctx_desc *cd)
> kfree(cd);
> }
> }
> +
> +bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
> +{
> + unsigned long reg, fld;
> + unsigned long oas;
> + unsigned long asid_bits;
> + u32 feat_mask = ARM_SMMU_FEAT_BTM |
> ARM_SMMU_FEAT_COHERENCY;
Why is BTM mandated for SVA? I couldn't find this requirement in SMMU spec
(Sorry if I missed it or this got discussed earlier). But if performance is the only concern here,
is it better just to allow it with a warning rather than limiting SMMUs without BTM?
Thanks,
Shameer
> +
> + if (vabits_actual == 52)
> + feat_mask |= ARM_SMMU_FEAT_VAX;
> +
> + if ((smmu->features & feat_mask) != feat_mask)
> + return false;
> +
> + if (!(smmu->pgsize_bitmap & PAGE_SIZE))
> + return false;
> +
> + /*
> + * Get the smallest PA size of all CPUs (sanitized by cpufeature). We're
> + * not even pretending to support AArch32 here. Abort if the MMU
> outputs
> + * addresses larger than what we support.
> + */
> + reg = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
> + fld = cpuid_feature_extract_unsigned_field(reg,
> ID_AA64MMFR0_PARANGE_SHIFT);
> + oas = id_aa64mmfr0_parange_to_phys_shift(fld);
> + if (smmu->oas < oas)
> + return false;
> +
> + /* We can support bigger ASIDs than the CPU, but not smaller */
> + fld = cpuid_feature_extract_unsigned_field(reg,
> ID_AA64MMFR0_ASID_SHIFT);
> + asid_bits = fld ? 16 : 8;
> + if (smmu->asid_bits < asid_bits)
> + return false;
> +
> + /*
> + * See max_pinned_asids in arch/arm64/mm/context.c. The following is
> + * generally the maximum number of bindable processes.
> + */
> + if (arm64_kernel_unmapped_at_el0())
> + asid_bits--;
> + dev_dbg(smmu->dev, "%d shared contexts\n", (1 << asid_bits) -
> + num_possible_cpus() - 2);
> +
> + return true;
> +}
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e99ebdd4c841..44c57bcfe112 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -3257,6 +3257,9 @@ static int arm_smmu_device_hw_probe(struct
> arm_smmu_device *smmu)
>
> smmu->ias = max(smmu->ias, smmu->oas);
>
> + if (arm_smmu_sva_supported(smmu))
> + smmu->features |= ARM_SMMU_FEAT_SVA;
> +
> dev_info(smmu->dev, "ias %lu-bit, oas %lu-bit (features 0x%08x)\n",
> smmu->ias, smmu->oas, smmu->features);
> return 0;
> --
> 2.28.0
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "fenghua.yu@intel.com" <fenghua.yu@intel.com>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"zhangfei.gao@linaro.org" <zhangfei.gao@linaro.org>,
"will@kernel.org" <will@kernel.org>
Subject: RE: [PATCH v10 10/13] iommu/arm-smmu-v3: Check for SVA features
Date: Mon, 21 Sep 2020 08:59:39 +0000 [thread overview]
Message-ID: <753bcd76c21c4ea98ef1d4e492db01f4@huawei.com> (raw)
In-Reply-To: <20200918101852.582559-11-jean-philippe@linaro.org>
Hi Jean,
> -----Original Message-----
> From: iommu [mailto:iommu-bounces@lists.linux-foundation.org] On Behalf Of
> Jean-Philippe Brucker
> Sent: 18 September 2020 11:19
> To: iommu@lists.linux-foundation.org; linux-arm-kernel@lists.infradead.org;
> linux-mm@kvack.org
> Cc: fenghua.yu@intel.com; Jean-Philippe Brucker <jean-philippe@linaro.org>;
> catalin.marinas@arm.com; Suzuki K Poulose <suzuki.poulose@arm.com>;
> robin.murphy@arm.com; zhangfei.gao@linaro.org; will@kernel.org
> Subject: [PATCH v10 10/13] iommu/arm-smmu-v3: Check for SVA features
>
> Aggregate all sanity-checks for sharing CPU page tables with the SMMU
> under a single ARM_SMMU_FEAT_SVA bit. For PCIe SVA, users also need to
> check FEAT_ATS and FEAT_PRI. For platform SVA, they will have to check
> FEAT_STALLS.
>
> Introduce ARM_SMMU_FEAT_BTM (Broadcast TLB Maintenance), but don't
> enable it at the moment. Since the entire VMID space is shared with the
> CPU, enabling DVM (by clearing SMMU_CR2.PTM) could result in
> over-invalidation and affect performance of stage-2 mappings.
>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> v10:
> * Check that 52-bit VA is supported on the SMMU side if vabits_actual
> requires it.
> * Check arm64_kernel_unmapped_at_el0() instead of
> CONFIG_UNMAP_KERNEL_AT_EL0
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 10 +++++
> .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 45
> +++++++++++++++++++
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 ++
> 3 files changed, 58 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index 90c08f156b43..7b14b48a26c7 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -602,6 +602,8 @@ struct arm_smmu_device {
> #define ARM_SMMU_FEAT_STALL_FORCE (1 << 13)
> #define ARM_SMMU_FEAT_VAX (1 << 14)
> #define ARM_SMMU_FEAT_RANGE_INV (1 << 15)
> +#define ARM_SMMU_FEAT_BTM (1 << 16)
> +#define ARM_SMMU_FEAT_SVA (1 << 17)
> u32 features;
>
> #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
> @@ -683,4 +685,12 @@ int arm_smmu_write_ctx_desc(struct
> arm_smmu_domain *smmu_domain, int ssid,
> void arm_smmu_tlb_inv_asid(struct arm_smmu_device *smmu, u16 asid);
> bool arm_smmu_free_asid(struct arm_smmu_ctx_desc *cd);
>
> +#ifdef CONFIG_ARM_SMMU_V3_SVA
> +bool arm_smmu_sva_supported(struct arm_smmu_device *smmu);
> +#else /* CONFIG_ARM_SMMU_V3_SVA */
> +static inline bool arm_smmu_sva_supported(struct arm_smmu_device
> *smmu)
> +{
> + return false;
> +}
> +#endif /* CONFIG_ARM_SMMU_V3_SVA */
> #endif /* _ARM_SMMU_V3_H */
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> index ef3fcfa72187..cb94c0924196 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> @@ -152,3 +152,48 @@ static void arm_smmu_free_shared_cd(struct
> arm_smmu_ctx_desc *cd)
> kfree(cd);
> }
> }
> +
> +bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
> +{
> + unsigned long reg, fld;
> + unsigned long oas;
> + unsigned long asid_bits;
> + u32 feat_mask = ARM_SMMU_FEAT_BTM |
> ARM_SMMU_FEAT_COHERENCY;
Why is BTM mandated for SVA? I couldn't find this requirement in SMMU spec
(Sorry if I missed it or this got discussed earlier). But if performance is the only concern here,
is it better just to allow it with a warning rather than limiting SMMUs without BTM?
Thanks,
Shameer
> +
> + if (vabits_actual == 52)
> + feat_mask |= ARM_SMMU_FEAT_VAX;
> +
> + if ((smmu->features & feat_mask) != feat_mask)
> + return false;
> +
> + if (!(smmu->pgsize_bitmap & PAGE_SIZE))
> + return false;
> +
> + /*
> + * Get the smallest PA size of all CPUs (sanitized by cpufeature). We're
> + * not even pretending to support AArch32 here. Abort if the MMU
> outputs
> + * addresses larger than what we support.
> + */
> + reg = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
> + fld = cpuid_feature_extract_unsigned_field(reg,
> ID_AA64MMFR0_PARANGE_SHIFT);
> + oas = id_aa64mmfr0_parange_to_phys_shift(fld);
> + if (smmu->oas < oas)
> + return false;
> +
> + /* We can support bigger ASIDs than the CPU, but not smaller */
> + fld = cpuid_feature_extract_unsigned_field(reg,
> ID_AA64MMFR0_ASID_SHIFT);
> + asid_bits = fld ? 16 : 8;
> + if (smmu->asid_bits < asid_bits)
> + return false;
> +
> + /*
> + * See max_pinned_asids in arch/arm64/mm/context.c. The following is
> + * generally the maximum number of bindable processes.
> + */
> + if (arm64_kernel_unmapped_at_el0())
> + asid_bits--;
> + dev_dbg(smmu->dev, "%d shared contexts\n", (1 << asid_bits) -
> + num_possible_cpus() - 2);
> +
> + return true;
> +}
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e99ebdd4c841..44c57bcfe112 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -3257,6 +3257,9 @@ static int arm_smmu_device_hw_probe(struct
> arm_smmu_device *smmu)
>
> smmu->ias = max(smmu->ias, smmu->oas);
>
> + if (arm_smmu_sva_supported(smmu))
> + smmu->features |= ARM_SMMU_FEAT_SVA;
> +
> dev_info(smmu->dev, "ias %lu-bit, oas %lu-bit (features 0x%08x)\n",
> smmu->ias, smmu->oas, smmu->features);
> return 0;
> --
> 2.28.0
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-09-21 8:59 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 10:18 [PATCH v10 00/13] iommu: Shared Virtual Addressing for SMMUv3 (PT sharing part) Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` [PATCH v10 01/13] mm: Define pasid in mm Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-28 22:22 ` Will Deacon
2020-09-28 22:22 ` Will Deacon
2020-09-28 22:22 ` Will Deacon
2020-09-28 22:43 ` Fenghua Yu
2020-09-28 22:43 ` Fenghua Yu
2020-09-28 22:43 ` Fenghua Yu
2020-09-30 9:13 ` Jean-Philippe Brucker
2020-09-30 9:13 ` Jean-Philippe Brucker
2020-09-30 9:13 ` Jean-Philippe Brucker
2020-09-18 10:18 ` [PATCH v10 02/13] iommu/ioasid: Add ioasid references Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` [PATCH v10 03/13] iommu/sva: Add PASID helpers Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` [PATCH v10 04/13] arm64: mm: Pin down ASIDs for sharing mm with devices Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` [PATCH v10 05/13] iommu/io-pgtable-arm: Move some definitions to a header Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` [PATCH v10 06/13] arm64: cpufeature: Export symbol read_sanitised_ftr_reg() Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` [PATCH v10 07/13] iommu/arm-smmu-v3: Move definitions to a header Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` [PATCH v10 08/13] iommu/arm-smmu-v3: Share process page tables Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` [PATCH v10 09/13] iommu/arm-smmu-v3: Seize private ASID Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 13:07 ` Jonathan Cameron
2020-09-18 13:07 ` Jonathan Cameron
2020-09-18 13:07 ` Jonathan Cameron
2020-09-18 10:18 ` [PATCH v10 10/13] iommu/arm-smmu-v3: Check for SVA features Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-21 8:59 ` Shameerali Kolothum Thodi [this message]
2020-09-21 8:59 ` Shameerali Kolothum Thodi
2020-09-21 8:59 ` Shameerali Kolothum Thodi
2020-09-24 10:13 ` Jean-Philippe Brucker
2020-09-24 10:13 ` Jean-Philippe Brucker
2020-09-24 10:13 ` Jean-Philippe Brucker
2020-09-24 11:13 ` Shameerali Kolothum Thodi
2020-09-24 11:13 ` Shameerali Kolothum Thodi
2020-09-24 11:13 ` Shameerali Kolothum Thodi
2020-12-09 19:49 ` Krishna Reddy
2020-12-09 19:49 ` Krishna Reddy
2020-12-09 19:49 ` Krishna Reddy
2020-12-09 20:07 ` Will Deacon
2020-12-09 20:07 ` Will Deacon
2020-12-09 20:07 ` Will Deacon
2020-12-09 20:38 ` Krishna Reddy
2020-12-09 20:38 ` Krishna Reddy
2020-12-09 20:38 ` Krishna Reddy
2020-12-14 9:32 ` Jean-Philippe Brucker
2020-12-14 9:32 ` Jean-Philippe Brucker
2020-12-14 9:32 ` Jean-Philippe Brucker
2020-12-14 23:23 ` Krishna Reddy
2020-12-14 23:23 ` Krishna Reddy
2020-12-14 23:23 ` Krishna Reddy
2020-09-18 10:18 ` [PATCH v10 11/13] iommu/arm-smmu-v3: Add SVA device feature Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-12-15 1:09 ` Krishna Reddy
2020-12-15 1:09 ` Krishna Reddy
2020-12-15 1:09 ` Krishna Reddy
2021-01-06 10:09 ` Jean-Philippe Brucker
2021-01-06 10:09 ` Jean-Philippe Brucker
2021-01-06 10:09 ` Jean-Philippe Brucker
2021-01-06 17:23 ` Krishna Reddy
2021-01-06 17:23 ` Krishna Reddy
2021-01-06 17:23 ` Krishna Reddy
2020-09-18 10:18 ` [PATCH v10 12/13] iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind() Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-11-24 23:58 ` Jason Gunthorpe
2020-11-24 23:58 ` Jason Gunthorpe
2020-11-24 23:58 ` Jason Gunthorpe
2020-11-25 9:27 ` Jean-Philippe Brucker
2020-11-25 9:27 ` Jean-Philippe Brucker
2020-11-25 9:27 ` Jean-Philippe Brucker
2020-11-26 0:37 ` Jason Gunthorpe
2020-11-26 0:37 ` Jason Gunthorpe
2020-11-26 0:37 ` Jason Gunthorpe
2020-09-18 10:18 ` [PATCH v10 13/13] iommu/arm-smmu-v3: Hook up ATC invalidation to mm ops Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 10:18 ` Jean-Philippe Brucker
2020-09-18 13:15 ` [PATCH v10 00/13] iommu: Shared Virtual Addressing for SMMUv3 (PT sharing part) Jonathan Cameron
2020-09-18 13:15 ` Jonathan Cameron
2020-09-18 13:15 ` Jonathan Cameron
2020-09-28 16:47 ` Jean-Philippe Brucker
2020-09-28 16:47 ` Jean-Philippe Brucker
2020-09-28 16:47 ` Jean-Philippe Brucker
2020-09-28 17:23 ` Will Deacon
2020-09-28 17:23 ` Will Deacon
2020-09-28 17:23 ` Will Deacon
2020-09-28 22:39 ` Will Deacon
2020-09-28 22:39 ` Will Deacon
2020-09-28 22:39 ` Will Deacon
2020-09-30 9:12 ` Jean-Philippe Brucker
2020-09-30 9:12 ` Jean-Philippe Brucker
2020-09-30 9:12 ` Jean-Philippe Brucker
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=753bcd76c21c4ea98ef1d4e492db01f4@huawei.com \
--to=shameerali.kolothum.thodi@huawei.com \
--cc=catalin.marinas@arm.com \
--cc=fenghua.yu@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=robin.murphy@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=zhangfei.gao@linaro.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.