From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH 2/2] iommu/arm-smmu: add support for access-protected mappings Date: Fri, 19 Sep 2014 23:05:36 +0100 Message-ID: <20140919220535.GM20773@arm.com> References: <1410984969-2340-1-git-send-email-mitchelh@codeaurora.org> <1410984969-2340-3-git-send-email-mitchelh@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1410984969-2340-3-git-send-email-mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Mitchel Humpherys Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Joerg Roedel , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: iommu@lists.linux-foundation.org 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 > --- > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Fri, 19 Sep 2014 23:05:36 +0100 Subject: [PATCH 2/2] iommu/arm-smmu: add support for access-protected mappings In-Reply-To: <1410984969-2340-3-git-send-email-mitchelh@codeaurora.org> References: <1410984969-2340-1-git-send-email-mitchelh@codeaurora.org> <1410984969-2340-3-git-send-email-mitchelh@codeaurora.org> Message-ID: <20140919220535.GM20773@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > --- > 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