From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: "Chalamarla,
Tirumalesh"
<Tirumalesh.Chalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
linux-arm-kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: iommu/arm-smmu-v2 ASID/VMID calculation
Date: Tue, 26 Jan 2016 11:54:35 +0000 [thread overview]
Message-ID: <20160126115435.GB21553@arm.com> (raw)
In-Reply-To: <6F24A28A-6302-4C48-A933-B47A9735808C-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
On Tue, Jan 26, 2016 at 03:11:27AM +0000, Chalamarla, Tirumalesh wrote:
> one my colleague points out, ASIDPNE also implementation defined.
It looks pretty well defined to me, despite being a hint:
This ASIDPNE indication is only a hint, and an SMMU can ignore it. In
particular, if the SMMU implementation does not support the ASIDPNE
feature, broadcast TLB invalidate operations ignore this hint and
invalidate matching TLB entries when broadcast TLB invalidation is
enabled.
But what does this have to do with the problem at hand?
> >I don’t think it followed spec.
> >
> >The SMMU spec (IHI0062C) says (section 2.2):
> >
> > - The exact behavior of any TLB functionality is IMPLEMENTATION DEFINED
... and immediately qualifies that with:
The SMMU architecture does not limit how a TLB is implemented, provided
it obeys the TLB Invalidate operations.
which is to say, you can build the TLB how you like, providing that it
follows the programmers model for invalidation. Otherwise portable
software will break and people will send patches to "fix" it.
> >Section 2.2 describes the constraints on sharing (e.g. multiple contexts
> >using the same ASID says):
> >
> > "If multiple context banks have hte same attributes but describe
> > different translations, the results of a TLB lookup are UNPREDICTABLE".
That's describing a TLB conflict. These don't occur, because we ensure
each of your 128 context banks has different attributes (i.e. ASID/VMID).
The problem is that you have shared state between multiple SMMU instances,
which I don't think is correct. I'm fine with a workaround, but I don't
want this logic to be used on other implementations where it is not
needed.
> >The present smmu driver assumes ASID should only be unique per SMMU, this
> >might not be true for all Implementations.
So far, it appears to be true for all Implementations apart from yours
and therefore needs to be quirked.
Will
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: iommu/arm-smmu-v2 ASID/VMID calculation
Date: Tue, 26 Jan 2016 11:54:35 +0000 [thread overview]
Message-ID: <20160126115435.GB21553@arm.com> (raw)
In-Reply-To: <6F24A28A-6302-4C48-A933-B47A9735808C@caviumnetworks.com>
On Tue, Jan 26, 2016 at 03:11:27AM +0000, Chalamarla, Tirumalesh wrote:
> one my colleague points out, ASIDPNE also implementation defined.
It looks pretty well defined to me, despite being a hint:
This ASIDPNE indication is only a hint, and an SMMU can ignore it. In
particular, if the SMMU implementation does not support the ASIDPNE
feature, broadcast TLB invalidate operations ignore this hint and
invalidate matching TLB entries when broadcast TLB invalidation is
enabled.
But what does this have to do with the problem at hand?
> >I don?t think it followed spec.
> >
> >The SMMU spec (IHI0062C) says (section 2.2):
> >
> > - The exact behavior of any TLB functionality is IMPLEMENTATION DEFINED
... and immediately qualifies that with:
The SMMU architecture does not limit how a TLB is implemented, provided
it obeys the TLB Invalidate operations.
which is to say, you can build the TLB how you like, providing that it
follows the programmers model for invalidation. Otherwise portable
software will break and people will send patches to "fix" it.
> >Section 2.2 describes the constraints on sharing (e.g. multiple contexts
> >using the same ASID says):
> >
> > "If multiple context banks have hte same attributes but describe
> > different translations, the results of a TLB lookup are UNPREDICTABLE".
That's describing a TLB conflict. These don't occur, because we ensure
each of your 128 context banks has different attributes (i.e. ASID/VMID).
The problem is that you have shared state between multiple SMMU instances,
which I don't think is correct. I'm fine with a workaround, but I don't
want this logic to be used on other implementations where it is not
needed.
> >The present smmu driver assumes ASID should only be unique per SMMU, this
> >might not be true for all Implementations.
So far, it appears to be true for all Implementations apart from yours
and therefore needs to be quirked.
Will
next prev parent reply other threads:[~2016-01-26 11:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-21 18:52 iommu/arm-smmu-v2 ASID/VMID calculation Chalamarla, Tirumalesh
[not found] ` <198F501C-8D30-4EB5-BC40-4F40BB75D40B-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-01-25 17:03 ` Will Deacon
2016-01-25 17:03 ` Will Deacon
[not found] ` <20160125170312.GJ22927-5wv7dgnIgG8@public.gmane.org>
2016-01-26 0:48 ` Chalamarla, Tirumalesh
2016-01-26 0:48 ` Chalamarla, Tirumalesh
[not found] ` <E978AB4F-5CB0-42D8-8152-04C77DB664A1-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-01-26 3:11 ` Chalamarla, Tirumalesh
2016-01-26 3:11 ` Chalamarla, Tirumalesh
[not found] ` <6F24A28A-6302-4C48-A933-B47A9735808C-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-01-26 11:48 ` Robin Murphy
2016-01-26 11:48 ` Robin Murphy
[not found] ` <56A75D0A.7000806-5wv7dgnIgG8@public.gmane.org>
2016-01-27 19:05 ` Chalamarla, Tirumalesh
2016-01-27 19:05 ` Chalamarla, Tirumalesh
2016-01-26 11:54 ` Will Deacon [this message]
2016-01-26 11:54 ` Will Deacon
[not found] ` <20160126115435.GB21553-5wv7dgnIgG8@public.gmane.org>
2016-01-27 19:06 ` Chalamarla, Tirumalesh
2016-01-27 19:06 ` Chalamarla, Tirumalesh
[not found] ` <E0484253-BE37-476A-9F4A-ABE6B74EC174-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-01-27 19:08 ` Will Deacon
2016-01-27 19:08 ` 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=20160126115435.GB21553@arm.com \
--to=will.deacon-5wv7dgnigg8@public.gmane.org \
--cc=Tirumalesh.Chalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@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.