[PATCH 2/2] iommu/arm-smmu: add support for access-protected mappings

[Will Deacon]

On Wed, Sep 17, 2014 at 09:16:09PM +0100, Mitchel Humpherys wrote:
> ARM SMMUs support memory access control via some bits in the translation
> table descriptor memory attributes. Currently we assume all translations
> are "unprivileged". Add support for privileged mappings, controlled by
> the IOMMU_PRIV prot flag.
> 
> Also sneak in a whitespace change for consistency with nearby code.
> 
> Signed-off-by: Mitchel Humpherys <mitchelh at codeaurora.org>
> ---
>  drivers/iommu/arm-smmu.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index ca18d6d42a..93999ec22c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1256,10 +1256,11 @@ static int arm_smmu_alloc_init_pte(struct arm_smmu_device *smmu, pmd_t *pmd,
>  	}
>  
>  	if (stage == 1) {
> -		pteval |= ARM_SMMU_PTE_AP_UNPRIV | ARM_SMMU_PTE_nG;
> +		pteval |= ARM_SMMU_PTE_nG;
> +		if (!(prot & IOMMU_PRIV))
> +			pteval |= ARM_SMMU_PTE_AP_UNPRIV;

I think this actually makes more sense if we invert the logic, i.e. have
IOMMU_USER as a flag which sets the UNPRIV bit in the pte.

I don't have the spec to hand, but I guess you can't enforce this at
stage-2? If so, do we also need a new IOMMU capability so people don't try
to use this for stage-2 only SMMUs?

Will