From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Nate Watterson <nwatters-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] iommu/arm-smmu-v3: avoid over allocating for l2 stream tables
Date: Tue, 20 Dec 2016 10:22:09 +0000 [thread overview]
Message-ID: <20161220102209.GC10132@arm.com> (raw)
In-Reply-To: <1482179200-4264-1-git-send-email-nwatters-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Hi Nate,
On Mon, Dec 19, 2016 at 03:26:40PM -0500, Nate Watterson wrote:
> Currently, all l2 stream tables are being allocated with space for
> (1<<split) stes without regard to the number of sid bits the smmu
> physically supports. To avoid allocating memory for inaccessible
> stes, this patch limits the span of an l2 table to be no larger
> than the sid size of the smmu to which it belongs.
>
> Signed-off-by: Nate Watterson <nwatters-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
I can't help but think you'd be better off using a linear stream table
in this scenario. If we hack the feature check for
ARM_SMMU_FEAT_2_LVL_STRTAB so that it doesn't report support for 2 level
tables if the number of sids is less than that covered by a single l2
entry, would that solve your problem?
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] iommu/arm-smmu-v3: avoid over allocating for l2 stream tables
Date: Tue, 20 Dec 2016 10:22:09 +0000 [thread overview]
Message-ID: <20161220102209.GC10132@arm.com> (raw)
In-Reply-To: <1482179200-4264-1-git-send-email-nwatters@codeaurora.org>
Hi Nate,
On Mon, Dec 19, 2016 at 03:26:40PM -0500, Nate Watterson wrote:
> Currently, all l2 stream tables are being allocated with space for
> (1<<split) stes without regard to the number of sid bits the smmu
> physically supports. To avoid allocating memory for inaccessible
> stes, this patch limits the span of an l2 table to be no larger
> than the sid size of the smmu to which it belongs.
>
> Signed-off-by: Nate Watterson <nwatters@codeaurora.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
I can't help but think you'd be better off using a linear stream table
in this scenario. If we hack the feature check for
ARM_SMMU_FEAT_2_LVL_STRTAB so that it doesn't report support for 2 level
tables if the number of sids is less than that covered by a single l2
entry, would that solve your problem?
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Nate Watterson <nwatters@codeaurora.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>,
linux-arm-kernel@lists.infradead.org,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/arm-smmu-v3: avoid over allocating for l2 stream tables
Date: Tue, 20 Dec 2016 10:22:09 +0000 [thread overview]
Message-ID: <20161220102209.GC10132@arm.com> (raw)
In-Reply-To: <1482179200-4264-1-git-send-email-nwatters@codeaurora.org>
Hi Nate,
On Mon, Dec 19, 2016 at 03:26:40PM -0500, Nate Watterson wrote:
> Currently, all l2 stream tables are being allocated with space for
> (1<<split) stes without regard to the number of sid bits the smmu
> physically supports. To avoid allocating memory for inaccessible
> stes, this patch limits the span of an l2 table to be no larger
> than the sid size of the smmu to which it belongs.
>
> Signed-off-by: Nate Watterson <nwatters@codeaurora.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
I can't help but think you'd be better off using a linear stream table
in this scenario. If we hack the feature check for
ARM_SMMU_FEAT_2_LVL_STRTAB so that it doesn't report support for 2 level
tables if the number of sids is less than that covered by a single l2
entry, would that solve your problem?
Will
next prev parent reply other threads:[~2016-12-20 10:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-19 20:26 [PATCH] iommu/arm-smmu-v3: avoid over allocating for l2 stream tables Nate Watterson
2016-12-19 20:26 ` Nate Watterson
2016-12-19 20:26 ` Nate Watterson
[not found] ` <1482179200-4264-1-git-send-email-nwatters-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-12-20 10:22 ` Will Deacon [this message]
2016-12-20 10:22 ` Will Deacon
2016-12-20 10:22 ` Will Deacon
[not found] ` <20161220102209.GC10132-5wv7dgnIgG8@public.gmane.org>
2017-01-10 19:47 ` [PATCH] iommu/arm-smmu-v3: limit use of 2-level " Nate Watterson
2017-01-10 19:47 ` Nate Watterson
2017-01-10 19:47 ` Nate Watterson
[not found] ` <1484077633-18376-1-git-send-email-nwatters-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-01-12 17:20 ` Will Deacon
2017-01-12 17:20 ` Will Deacon
2017-01-12 17:20 ` 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=20161220102209.GC10132@arm.com \
--to=will.deacon-5wv7dgnigg8@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=nwatters-sgV2jX0FEOL9JmXXK+q4OQ@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.