15 Oct, 2019

2 commits

  • IOASID allocation may rely on platform specific methods. One use case is
    that when running in the guest, in order to obtain system wide global
    IOASIDs, emulated allocation interface is needed to communicate with the
    host. Here we call these platform specific allocators custom allocators.

    Custom IOASID allocators can be registered at runtime and take precedence
    over the default XArray allocator. They have these attributes:

    - provides platform specific alloc()/free() functions with private data.
    - allocation results lookup are not provided by the allocator, lookup
    request must be done by the IOASID framework by its own XArray.
    - allocators can be unregistered at runtime, either fallback to the next
    custom allocator or to the default allocator.
    - custom allocators can share the same set of alloc()/free() helpers, in
    this case they also share the same IOASID space, thus the same XArray.
    - switching between allocators requires all outstanding IOASIDs to be
    freed unless the two allocators share the same alloc()/free() helpers.

    Signed-off-by: Jean-Philippe Brucker
    Signed-off-by: Jacob Pan
    Link: https://lkml.org/lkml/2019/4/26/462
    Reviewed-by: Jean-Philippe Brucker
    Reviewed-by: Eric Auger
    Signed-off-by: Joerg Roedel

    Jacob Pan
     
  • Some devices might support multiple DMA address spaces, in particular
    those that have the PCI PASID feature. PASID (Process Address Space ID)
    allows to share process address spaces with devices (SVA), partition a
    device into VM-assignable entities (VFIO mdev) or simply provide
    multiple DMA address space to kernel drivers. Add a global PASID
    allocator usable by different drivers at the same time. Name it I/O ASID
    to avoid confusion with ASIDs allocated by arch code, which are usually
    a separate ID space.

    The IOASID space is global. Each device can have its own PASID space,
    but by convention the IOMMU ended up having a global PASID space, so
    that with SVA, each mm_struct is associated to a single PASID.

    The allocator is primarily used by IOMMU subsystem but in rare occasions
    drivers would like to allocate PASIDs for devices that aren't managed by
    an IOMMU, using the same ID space as IOMMU.

    Signed-off-by: Jean-Philippe Brucker
    Signed-off-by: Jacob Pan
    Reviewed-by: Jean-Philippe Brucker
    Reviewed-by: Eric Auger
    Signed-off-by: Joerg Roedel

    Jean-Philippe Brucker