All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org
Cc: will.deacon-5wv7dgnIgG8@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Geethasowjanya.Akula-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org
Subject: Re: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
Date: Fri, 5 Feb 2016 20:15:32 +0000	[thread overview]
Message-ID: <20160205201532.GA10389@leverpostej> (raw)
In-Reply-To: <20160205200142.GA8647@leverpostej>

On Fri, Feb 05, 2016 at 08:02:09PM +0000, Mark Rutland wrote:
> On Fri, Feb 05, 2016 at 10:47:07AM -0800, tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org wrote:
> > From: Tirumalesh Chalamarla <tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> > 
> > An issue exists whereby the Linux kernel requires that ASIDs are a
> > unique namespace per SMMU.  
> 
> The SMMU architecture requires this, and Linux relies on hardware
> following the architecture.
> 
> Please describe the problem correctly. i.e. that the hardware
> erroneously shares TLBs between SMMU instances.
> 
> > That ASID-local choice conflicts with the
> > CN88xx SMMU, where only shared ASID namespaces are supported;
> > specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
> > and SMMU3. CN88xx SMMU also requires global VMIDs.
> > 
> > This patch tries to address these issuee by supplying asid and vmid
> > transformations from devicetree.
> > 
> > Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> > Signed-off-by: Tirumalesh Chalamarla <tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> > ---
> >  .../devicetree/bindings/iommu/arm,smmu.txt         | 16 ++++++
> >  drivers/iommu/arm-smmu.c                           | 59 ++++++++++++++++++----
> >  2 files changed, 65 insertions(+), 10 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > index 7180745..eef06d0 100644
> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > @@ -55,6 +55,22 @@ conditions.
> >                    aliases of secure registers have to be used during
> >                    SMMU configuration.
> >  
> > +- thunderx,smmu-asid-transform	: Enable proper handling for buggy
> > +		  implementations that require special transformations
> > +		  for smmu asid. if this property exists asid-transform
> > +		  property must be present.
> > +
> > +- thunderx,smmu-vmid-transform	: Enable proper handling for buggy
> > +		  implementations that require special transformations
> > +		  for smmu vmid. if this property exists vmid-transform
> > +		  property must be present.
> > +
> > +- asid-transform 	: Transform mask that needs to be applied to asid.
> > +			This property has to be specified as '/bits/ 8' value.
> > +
> > +- vmid-transform 	: Transform mask that needs to be applied to vmid.
> > +			This property has to be specified as '/bits/ 8' value.
> 
> Don't bother with /bits/ 8. It saves no space in the DTB and only adds
> to confusion. Use a full cell, and of_property_read_u32, and validate
> that the value is in range.
> 
> Having two properties for each seems redundant. The presence of a mask
> should be sufficient to make it clear that the use of the mask is
> required.
> 
> These properties aren't sufficiently described. How is the mask
> "applied", and what is it applied to? What constraints does it impose
> on the OS's selection of ASIDs/VMIDs?
> 
> From the looks of the patch, it's ANDed into the value Linux has
> selected, so it sounds like an OS must avoid using any bits set in any
> mask on any SMMU instance. That sounds very difficult to ensure in
> general, and very fragile.

A much better approach would be to have something like:

valid-asid-range : two u32 cells describing the minimum and maximum
                   ASIDs that may be used on this SMMU instance. The OS
		   must allocate ASIDs in the interval [minimum,
		   maximum].

That way the OS can prevent itself from allocating conflicting ASIDs,
which is not possible with a single base value as you have with your
asid-transform property.

Mark.

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
Date: Fri, 5 Feb 2016 20:15:32 +0000	[thread overview]
Message-ID: <20160205201532.GA10389@leverpostej> (raw)
In-Reply-To: <20160205200142.GA8647@leverpostej>

On Fri, Feb 05, 2016 at 08:02:09PM +0000, Mark Rutland wrote:
> On Fri, Feb 05, 2016 at 10:47:07AM -0800, tchalamarla at caviumnetworks.com wrote:
> > From: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
> > 
> > An issue exists whereby the Linux kernel requires that ASIDs are a
> > unique namespace per SMMU.  
> 
> The SMMU architecture requires this, and Linux relies on hardware
> following the architecture.
> 
> Please describe the problem correctly. i.e. that the hardware
> erroneously shares TLBs between SMMU instances.
> 
> > That ASID-local choice conflicts with the
> > CN88xx SMMU, where only shared ASID namespaces are supported;
> > specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
> > and SMMU3. CN88xx SMMU also requires global VMIDs.
> > 
> > This patch tries to address these issuee by supplying asid and vmid
> > transformations from devicetree.
> > 
> > Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula@caviumnetworks.com>
> > Signed-off-by: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
> > ---
> >  .../devicetree/bindings/iommu/arm,smmu.txt         | 16 ++++++
> >  drivers/iommu/arm-smmu.c                           | 59 ++++++++++++++++++----
> >  2 files changed, 65 insertions(+), 10 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > index 7180745..eef06d0 100644
> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > @@ -55,6 +55,22 @@ conditions.
> >                    aliases of secure registers have to be used during
> >                    SMMU configuration.
> >  
> > +- thunderx,smmu-asid-transform	: Enable proper handling for buggy
> > +		  implementations that require special transformations
> > +		  for smmu asid. if this property exists asid-transform
> > +		  property must be present.
> > +
> > +- thunderx,smmu-vmid-transform	: Enable proper handling for buggy
> > +		  implementations that require special transformations
> > +		  for smmu vmid. if this property exists vmid-transform
> > +		  property must be present.
> > +
> > +- asid-transform 	: Transform mask that needs to be applied to asid.
> > +			This property has to be specified as '/bits/ 8' value.
> > +
> > +- vmid-transform 	: Transform mask that needs to be applied to vmid.
> > +			This property has to be specified as '/bits/ 8' value.
> 
> Don't bother with /bits/ 8. It saves no space in the DTB and only adds
> to confusion. Use a full cell, and of_property_read_u32, and validate
> that the value is in range.
> 
> Having two properties for each seems redundant. The presence of a mask
> should be sufficient to make it clear that the use of the mask is
> required.
> 
> These properties aren't sufficiently described. How is the mask
> "applied", and what is it applied to? What constraints does it impose
> on the OS's selection of ASIDs/VMIDs?
> 
> From the looks of the patch, it's ANDed into the value Linux has
> selected, so it sounds like an OS must avoid using any bits set in any
> mask on any SMMU instance. That sounds very difficult to ensure in
> general, and very fragile.

A much better approach would be to have something like:

valid-asid-range : two u32 cells describing the minimum and maximum
                   ASIDs that may be used on this SMMU instance. The OS
		   must allocate ASIDs in the interval [minimum,
		   maximum].

That way the OS can prevent itself from allocating conflicting ASIDs,
which is not possible with a single base value as you have with your
asid-transform property.

Mark.

  reply	other threads:[~2016-02-05 20:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 18:47 [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704 tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8
2016-02-05 18:47 ` tchalamarla at caviumnetworks.com
     [not found] ` <1454698027-20911-1-git-send-email-tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-02-05 20:02   ` Mark Rutland
2016-02-05 20:02     ` Mark Rutland
2016-02-05 20:15     ` Mark Rutland [this message]
2016-02-05 20:15       ` Mark Rutland
2016-02-05 20:29       ` Chalamarla, Tirumalesh
2016-02-05 20:29         ` Chalamarla, Tirumalesh
2016-02-05 20:32     ` Chalamarla, Tirumalesh
2016-02-05 20:32       ` Chalamarla, Tirumalesh
2016-02-09 11:52   ` Robin Murphy
2016-02-09 11:52     ` Robin Murphy
     [not found]     ` <56B9D2F4.8070308-5wv7dgnIgG8@public.gmane.org>
2016-02-09 17:07       ` Chalamarla, Tirumalesh
2016-02-09 17:07         ` Chalamarla, Tirumalesh
  -- strict thread matches above, loose matches on Subject: below --
2016-02-24 21:13 Tirumalesh Chalamarla
2016-02-24 21:13 ` Tirumalesh Chalamarla
     [not found] ` <1456348433-3337-1-git-send-email-tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-03-02  3:07   ` Will Deacon
2016-03-02  3:07     ` Will Deacon
     [not found]     ` <20160302030756.GC7637-5wv7dgnIgG8@public.gmane.org>
2016-03-02  3:23       ` Chalamarla, Tirumalesh
2016-03-02  3:23         ` Chalamarla, Tirumalesh
     [not found]         ` <C2D36A36-8247-4432-BE50-14129D9D8E5B-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-03-02 13:35           ` Will Deacon
2016-03-02 13:35             ` Will Deacon
2016-03-02 13:10   ` Robin Murphy
2016-03-02 13:10     ` Robin Murphy
     [not found]     ` <56D6E658.1060201-5wv7dgnIgG8@public.gmane.org>
2016-03-02 18:12       ` Tirumalesh Chalamarla
2016-03-02 18:12         ` Tirumalesh Chalamarla

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=20160205201532.GA10389@leverpostej \
    --to=mark.rutland-5wv7dgnigg8@public.gmane.org \
    --cc=Geethasowjanya.Akula-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@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.