[RFC,10/30] iommu/arm-smmu-v3: Add task contexts

Now that we support substreams, add the required infrastructure to use
them. Each device can be attached to multiple address spaces. The default
address space is the domain, and additional ones are tasks. Each task can
be attached to multiple devices as well.

            +------------+       +---------------+
            | group      |       |        domain |
            |            +-------+               |
            |            |       |               |  (c)
     (a) ,-----[master]-------------[context 1]---------[task]--. (d)
        /   |         \  |  (b)  |               |               \
       /    |          `------------[context 2]----.             [SMMU]
      /     |            |       |               |  \             /
   [SMMU]   +------------+       +---------------+   \           /
      \                                               `-[task]--'
       \    +------------+       +---------------+    /
        \   |            |       |               |   /
         \----.          |       |               |  /
          `----[master]-------------[context 1]----'
            |            |       |               |
            |            +-------+               |
            | group      |  (e)  |        domain |
            +------------+       +---------------+

(a) Add a rbtree of streams in each SMMU instance, indexed by stream ID.
Each stream points to a single master, and masters can be identified by
multiple stream IDs. PCIe endpoints are, for the moment, expected to have
a unique stream ID (RID), but see the discussion about groups below.
Platform devices may issue multiple stream IDs.

(b) Add a rbtree of contexts in each SVM-capable master, indexed by
substream ID. A context is the link between a device and a task. It is
bidirectional since we need to lookup all devices attached to a task when
invalidating a mapping, and all tasks attached to a device when handling a
device fault (PRI).

Both these rbtrees will allow fast lookup of an address space when
handling a fault.

(c) Add a task in each context. We need tasks and contexts to be separate
entities with their own refcounting for at least two reasons. To reduce
the number of mmu notifiers and simplify ASID tracking, tasks are allowed
to be attached to multiple masters. It is also necessary for sane PASID
invalidation but we won't go into that now.

(d) Add a list of tasks in each SMMU instance. This allows to find
existing tasks when binding to a device. We could make it an rbtree, but
it's not clear whether we need this complication yet.

Lifetime of contexts and tasks is the following:

* arm_smmu_alloc_task creates smmu_task and adds it to the list.
* arm_smmu_attach_task allocates an SSID, creates smmu_context and
  connects task to master. Context descriptor is written, so the SSID is
  active and can be used in transactions.
* users may get krefs to task and contexts temporarily, and release them
  with put_task/put_context.
* arm_smmu_detach_task severs the link between context and task, and drops
  the task's refcount. If the task was only attached to one master, it is
  freed and removed from the list. arm_smmu_detach_task also clears the
  context descriptor, after which any transaction with this SSID would
  result in a fault.
* arm_smmu_put_context is called later, freeing the dangling context.

All these structures are protected by a single context_lock spinlock for
each SMMU instance. Therefore context_lock also serializes modifications
of the context descriptors. Any update of the krefs must be done while
holding the lock. Reads of lists and context->task as well. As we expect a
lot more reads than writes on the structures introduced by this patch,
especially for handling page requests, we hope to make use of the RCU in
the future.

(e) A group still has a default DMA domain, represented by context 0 (no
SSID). When attaching to a different domain, for example a VFIO domain, we
also want to destroy all active contexts. If VFIO is handing control of a
device to a guest for instance, we do not want the guest to have access to
host tasks through bound contexts. So contexts are conceptually contained
in the domain, although we do not need to maintain any structure for this.
When detaching a domain from a group, all contexts attached to this group
are also detached.

An IOMMU group contains all devices that can't be distinguished from one
another by their IOMMU. For PCIe this may be due to buggy devices, lack of
ACS isolation, legacy or non-transparent bridges. Since PCIe SVM platforms
on ARM have yet to be seen in the wild, legacy issues don't matter and SVM
through NTB is pretty far off.

So for prototyping, we currently bypass the concept of IOMMU groups, since
we expect SVM-capable devices to be properly integrated. This might change
as soon as someone starts taping out devices. There will then be some
complication in attaching a task to a group instead of an individual
device (for instance, finding a consensus for PASID sizes of all devices
in the group, which may be altered by hotplugging a device in a group),
but the current design doesn't prevent this change.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
---
 drivers/iommu/arm-smmu-v3.c | 316 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 314 insertions(+), 2 deletions(-)

[RFC,10/30] iommu/arm-smmu-v3: Add task contexts

Commit Message

Patch