iommu/arm-smmu-v2 ASID/VMID calculation

[Will Deacon]

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