From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Stuart Yoder <stuart.yoder-3arQi8VN3Tc@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: SMR masking and PCI
Date: Fri, 28 Oct 2016 18:43:09 +0100 [thread overview]
Message-ID: <20161028174309.GA12946@leverpostej> (raw)
In-Reply-To: <c39b785a-0f18-fc0a-ce08-7ebe3cfaf8c5-5wv7dgnIgG8@public.gmane.org>
Hi,
On Fri, Oct 28, 2016 at 05:16:37PM +0100, Robin Murphy wrote:
> On 27/10/16 18:10, Stuart Yoder wrote:
> > A question about how the SMR masking defined in the arm,smmu binding
> > relates to the PCI iommu-map.
> >
> > The #iommu-cells property defines the number of cells an "IOMMU specifier"
> > takes and 2 is specified to be:
> >
> > SMMUs with stream matching support and complex masters
> > may use a value of 2, where the second cell represents
> > an SMR mask to combine with the ID in the first cell.
> >
> > An iommu-map entry is defined as:
> >
> > (rid-base,iommu,iommu-base,length)
> >
> > What seems to be currently missing in the iommu-map support is
> > the possibility the case where #iommu-cells=<2>.
>
> Indeed. The bindings have so far rather implicitly assumed the case of
> #{msi,iommu}-cells = 1, and the code has followed suit.
The intention was that neither the iommu or msi bindings had such a
requirement, but evidently I did not specify the intended behaviour
thoroughly enough.
I had intended that the offset was added to the final cell of the
iommu-specifier (i.e. that the iommu-specifier was treated as a large
number).
You can handle this case by adding additional entries in the map table,
with a single entry length.
> > In this case iommu-base which is an IOMMU specifier should
> > occupy 2 cells. For example on an ls2085a we would want:
> >
> > iommu-map = <0x0 0x6 0x7 0x3ff 0x1
> > 0x100 0x6 0x8 0x3ff 0x1>;
> >
> > ...to mask our stream IDs to 10 bits.
> >
> > This should work in theory and comply with the bindings, no?
>
> In theory, but now consider:
>
> iommu-map = <0x0 0x6 0x7 0x3ff 0x2>;
>
> faced with ID 1. The input base is 0, the output base is the 2-cell
> value 0x7000003ff, so the final ID value should be 0x700000400, right?
That was the intended behaviour, yes.
> > (Also, I guess that msi-map is not affected by this since it
> > is not related to the IOMMU...but we do have common code
> > handling both maps.)
>
> I'd say it's definitely affected, since #msi-cells can equally be more
> than 1, and encodes an equally opaque value.
Yes.
> It seems pretty reasonable to me that we could extend the binding to
> accommodate #cells > 1 iff length == 1. Mark?
I will try to come up with the wording to make the above explicit, for
both bindings.
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: SMR masking and PCI
Date: Fri, 28 Oct 2016 18:43:09 +0100 [thread overview]
Message-ID: <20161028174309.GA12946@leverpostej> (raw)
In-Reply-To: <c39b785a-0f18-fc0a-ce08-7ebe3cfaf8c5@arm.com>
Hi,
On Fri, Oct 28, 2016 at 05:16:37PM +0100, Robin Murphy wrote:
> On 27/10/16 18:10, Stuart Yoder wrote:
> > A question about how the SMR masking defined in the arm,smmu binding
> > relates to the PCI iommu-map.
> >
> > The #iommu-cells property defines the number of cells an "IOMMU specifier"
> > takes and 2 is specified to be:
> >
> > SMMUs with stream matching support and complex masters
> > may use a value of 2, where the second cell represents
> > an SMR mask to combine with the ID in the first cell.
> >
> > An iommu-map entry is defined as:
> >
> > (rid-base,iommu,iommu-base,length)
> >
> > What seems to be currently missing in the iommu-map support is
> > the possibility the case where #iommu-cells=<2>.
>
> Indeed. The bindings have so far rather implicitly assumed the case of
> #{msi,iommu}-cells = 1, and the code has followed suit.
The intention was that neither the iommu or msi bindings had such a
requirement, but evidently I did not specify the intended behaviour
thoroughly enough.
I had intended that the offset was added to the final cell of the
iommu-specifier (i.e. that the iommu-specifier was treated as a large
number).
You can handle this case by adding additional entries in the map table,
with a single entry length.
> > In this case iommu-base which is an IOMMU specifier should
> > occupy 2 cells. For example on an ls2085a we would want:
> >
> > iommu-map = <0x0 0x6 0x7 0x3ff 0x1
> > 0x100 0x6 0x8 0x3ff 0x1>;
> >
> > ...to mask our stream IDs to 10 bits.
> >
> > This should work in theory and comply with the bindings, no?
>
> In theory, but now consider:
>
> iommu-map = <0x0 0x6 0x7 0x3ff 0x2>;
>
> faced with ID 1. The input base is 0, the output base is the 2-cell
> value 0x7000003ff, so the final ID value should be 0x700000400, right?
That was the intended behaviour, yes.
> > (Also, I guess that msi-map is not affected by this since it
> > is not related to the IOMMU...but we do have common code
> > handling both maps.)
>
> I'd say it's definitely affected, since #msi-cells can equally be more
> than 1, and encodes an equally opaque value.
Yes.
> It seems pretty reasonable to me that we could extend the binding to
> accommodate #cells > 1 iff length == 1. Mark?
I will try to come up with the wording to make the above explicit, for
both bindings.
Thanks,
Mark.
next prev parent reply other threads:[~2016-10-28 17:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-27 17:10 SMR masking and PCI Stuart Yoder
2016-10-27 17:10 ` Stuart Yoder
[not found] ` <VI1PR0401MB26389CC8820C9654337B578E8DAA0-9IDQY6o3qQjcXZ0H4ZLnAo3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2016-10-28 16:16 ` Robin Murphy
2016-10-28 16:16 ` Robin Murphy
[not found] ` <c39b785a-0f18-fc0a-ce08-7ebe3cfaf8c5-5wv7dgnIgG8@public.gmane.org>
2016-10-28 17:12 ` Stuart Yoder
2016-10-28 17:12 ` Stuart Yoder
2016-10-28 17:43 ` Mark Rutland [this message]
2016-10-28 17:43 ` Mark Rutland
2016-10-28 18:38 ` Stuart Yoder
2016-10-28 18:38 ` Stuart Yoder
2016-10-31 15:57 ` Diana Madalina Craciun
2016-10-31 15:57 ` Diana Madalina Craciun
[not found] ` <HE1PR04MB1321DED0E75BD607BB52889EFFAE0-6LN7OEpIatWwb60icsfScs9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2016-10-31 18:36 ` Robin Murphy
2016-10-31 18:36 ` Robin Murphy
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=20161028174309.GA12946@leverpostej \
--to=mark.rutland-5wv7dgnigg8@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
--cc=stuart.yoder-3arQi8VN3Tc@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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.