From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH RFC v2 3/3] documentation/iommu: Add description of Hisilicon SMMU private binding
Date: Tue, 17 Jun 2014 10:33:26 +0100 [thread overview]
Message-ID: <20140617093326.GC13020@arm.com> (raw)
In-Reply-To: <539FF33C.7020007@huawei.com>
On Tue, Jun 17, 2014 at 08:50:20AM +0100, leizhen wrote:
> On 2014/6/17 0:39, Will Deacon wrote:
> > On Thu, Jun 12, 2014 at 06:08:12AM +0100, Zhen Lei wrote:
> >> This patch adds a description of private properties for the Hisilicon
> >> System MMU architecture.
> >>
> >> Signed-off-by: Zhen Lei <thunder.leizhen@huawei•com>
> >> ---
> >> Documentation/devicetree/bindings/iommu/arm,smmu.txt | 16 ++++++++++++++++
> >> 1 file changed, 16 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >> index f284b99..75b1351 100644
> >> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >> @@ -15,6 +15,7 @@ conditions.
> >> "arm,smmu-v2"
> >> "arm,mmu-400"
> >> "arm,mmu-500"
> >> + "hisilicon,smmu-v1"
> >>
> >> depending on the particular implementation and/or the
> >> version of the architecture implemented.
> >> @@ -54,6 +55,21 @@ conditions.
> >> aliases of secure registers have to be used during
> >> SMMU configuration.
> >>
> >> +** Hisilicon SMMU private properties:
> >> +
> >> +- smmu-force-memtype : A list of StreamIDs which not translate address but
> >> + translate attributes. The StreamIDs list here can not be
> >> + used for map(translation) mode again.
> >> + StreamID first, then the type list below:
> >> + 1, cahceable, WBRAWA, Normal outer and inner write-back
> >> + 2, non-cacheable, Normal outer and inner non-cacheable
> >> + 3, device, nGnRE
> >> + others, bypass
> >> +
> >> +- smmu-bypass-vmid : Specify which context bank is used for bypass mode.
> >> + If omit, vmid=255 is default. If bypass and map mode can
> >> + share a same S2CR, config vmid=0.
> >
> > These don't feel like they belong in the device-tree to me. Is the list of
> > StreamIDs described in smmu-force-memtype a property of the hardware
> > configuration, or a software policy to allow you to generate cacheable
> > traffic for particular masters?
> >
> > Will
> >
> > .
> >
> OK, I will put these description into a sperate file, hisilicon,smmu.txt
> and mark a reference to arm,smmu.txt
No, don't do that. Delete the properties instead. I'm not a device-tree
expert, but these don't feel like things we should be describing there at
all.
> The latter case. Some masters driver want use cacheable(WB) attribute to access
> memory, but the masters can not bring cacheable attribute. So, can not use
> bypass(or transaction) mode. In fact, the master driver can use iommu_map to
> create map and specify IOMMU_CACHE. But maybe the driver does not want to
> map, if the memory access is very dynamically, frequently map and unmap will
> decrease performance.
You seem to be highlighting a perceived deficiency in the IOMMU API which
you're attempting to work-around with new device-tree properties. Instead,
why not propose an extension to the IOMMU API in Linux?
> Actually, I think smmu-force-memtype maybe suitable for arm-smmu too. But now,
> if nobody declear need it, I will just implement it in hisi-smmu.c
I don't want to see hisi-smmu.c at all. You need to make your driver fit
into the code we already have.
Do you have a specification available describing the hardware you have
created?
> A big issue should be discussed now. When a master use bypass mode to access
> memory, this means it can access all non-secure memory. So, if a master can
> be operated in user mode, that means a user process can access any kernel
> memory. In ARM smmu-v2 specification, SMMU_S2CRn.PRIVCFG is used for determine
> output priviledge attribute. But if use bypass mode and output attribute is
> Unprivileged, specification have no mention about where to decide memory access
> is permitted or not. Do you think is a spec design bug or Implemention
> defined, or find some description anywhere.
There are various overrides for the privilege controls but, as Varun said,
you should be using VFIO for userspace device access.
Will
next prev parent reply other threads:[~2014-06-17 9:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-12 5:08 [PATCH RFC v2 0/3] Add support for Hisilicon SMMU architecture Zhen Lei
2014-06-12 5:08 ` [PATCH RFC v2 1/3] iommu/arm: Adjust code to facilitate support arm smmu variants Zhen Lei
2014-06-12 5:08 ` [PATCH RFC v2 2/3] iommu/hisilicon: Add support for Hisilicon Ltd. System MMU architecture Zhen Lei
2014-06-12 5:08 ` [PATCH RFC v2 3/3] documentation/iommu: Add description of Hisilicon SMMU private binding Zhen Lei
2014-06-16 16:39 ` Will Deacon
2014-06-17 7:50 ` leizhen
2014-06-17 9:11 ` Varun Sethi
2014-06-17 9:33 ` Will Deacon [this message]
2014-06-18 1:28 ` leizhen
2014-06-18 12:03 ` Varun Sethi
2014-06-18 12:34 ` leizhen
2014-06-18 13:32 ` Will Deacon
2014-06-19 1:58 ` leizhen
2014-06-16 16:37 ` [PATCH RFC v2 0/3] Add support for Hisilicon SMMU architecture Will Deacon
2014-06-17 6:32 ` leizhen
2014-06-17 9:27 ` 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=20140617093326.GC13020@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