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 <[email protected]> > --- > 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 _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
