1. 22 3月, 2017 1 次提交
    • R
      iommu: Disambiguate MSI region types · 9d3a4de4
      Robin Murphy 提交于
      The introduction of reserved regions has left a couple of rough edges
      which we could do with sorting out sooner rather than later. Since we
      are not yet addressing the potential dynamic aspect of software-managed
      reservations and presenting them at arbitrary fixed addresses, it is
      incongruous that we end up displaying hardware vs. software-managed MSI
      regions to userspace differently, especially since ARM-based systems may
      actually require one or the other, or even potentially both at once,
      (which iommu-dma currently has no hope of dealing with at all). Let's
      resolve the former user-visible inconsistency ASAP before the ABI has
      been baked into a kernel release, in a way that also lays the groundwork
      for the latter shortcoming to be addressed by follow-up patches.
      
      For clarity, rename the software-managed type to IOMMU_RESV_SW_MSI, use
      IOMMU_RESV_MSI to describe the hardware type, and document everything a
      little bit. Since the x86 MSI remapping hardware falls squarely under
      this meaning of IOMMU_RESV_MSI, apply that type to their regions as well,
      so that we tell the same story to userspace across all platforms.
      
      Secondly, as the various region types require quite different handling,
      and it really makes little sense to ever try combining them, convert the
      bitfield-esque #defines to a plain enum in the process before anyone
      gets the wrong impression.
      
      Fixes: d30ddcaa ("iommu: Add a new type field in iommu_resv_region")
      Reviewed-by: NEric Auger <eric.auger@redhat.com>
      CC: Alex Williamson <alex.williamson@redhat.com>
      CC: David Woodhouse <dwmw2@infradead.org>
      CC: kvm@vger.kernel.org
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      9d3a4de4
  2. 10 2月, 2017 6 次提交
  3. 23 1月, 2017 4 次提交
  4. 19 1月, 2017 1 次提交
  5. 29 11月, 2016 1 次提交
    • L
      iommu: Make of_iommu_set/get_ops() DT agnostic · e4f10ffe
      Lorenzo Pieralisi 提交于
      The of_iommu_{set/get}_ops() API is used to associate a device
      tree node with a specific set of IOMMU operations. The same
      kernel interface is required on systems booting with ACPI, where
      devices are not associated with a device tree node, therefore
      the interface requires generalization.
      
      The struct device fwnode member represents the fwnode token associated
      with the device and the struct it points at is firmware specific;
      regardless, it is initialized on both ACPI and DT systems and makes an
      ideal candidate to use it to associate a set of IOMMU operations to a
      given device, through its struct device.fwnode member pointer, paving
      the way for representing per-device iommu_ops (ie an iommu instance
      associated with a device).
      
      Convert the DT specific of_iommu_{set/get}_ops() interface to
      use struct device.fwnode as a look-up token, making the interface
      usable on ACPI systems and rename the data structures and the
      registration API so that they are made to represent their usage
      more clearly.
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      Reviewed-by: NTomasz Nowicki <tn@semihalf.com>
      Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
      Tested-by: NTomasz Nowicki <tn@semihalf.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      e4f10ffe
  6. 15 11月, 2016 1 次提交
  7. 16 9月, 2016 1 次提交
    • R
      iommu: Introduce iommu_fwspec · 57f98d2f
      Robin Murphy 提交于
      Introduce a common structure to hold the per-device firmware data that
      most IOMMU drivers need to keep track of. This enables us to configure
      much of that data from common firmware code, and consolidate a lot of
      the equivalent implementations, device look-up tables, etc. which are
      currently strewn across IOMMU drivers.
      
      This will also be enable us to address the outstanding "multiple IOMMUs
      on the platform bus" problem by tweaking IOMMU API calls to prefer
      dev->fwspec->ops before falling back to dev->bus->iommu_ops, and thus
      gracefully handle those troublesome systems which we currently cannot.
      
      As the first user, hook up the OF IOMMU configuration mechanism. The
      driver-defined nature of DT cells means that we still need the drivers
      to translate and add the IDs themselves, but future users such as the
      much less free-form ACPI IORT will be much simpler and self-contained.
      
      CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Suggested-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      57f98d2f
  8. 13 7月, 2016 1 次提交
  9. 09 5月, 2016 2 次提交
  10. 07 4月, 2016 1 次提交
  11. 05 4月, 2016 1 次提交
    • A
      iommu: provide of_xlate pointer unconditionally · b70bb984
      Arnd Bergmann 提交于
      iommu drivers that support the standard DT bindings use a of_xlate
      callback pointer, but that is only part of struct iommu_ops when
      CONFIG_OF_IOMMU is enabled, leading to build errors in randconfig
      builds when that is not provided:
      
      drivers/iommu/mtk_iommu.c:497:2: error: unknown field 'of_xlate' specified in initializer
        .of_xlate = mtk_iommu_of_xlate,
        ^
      drivers/iommu/mtk_iommu.c:497:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
        .of_xlate = mtk_iommu_of_xlate,
                    ^~~~~~~~~~~~~~~~~~
      drivers/iommu/mtk_iommu.c:497:14: note: (near initialization for 'mtk_iommu_ops.domain_get_attr')
      
      We can work around it by adding more #ifdefs in each driver, but
      it seems nicer to just allow setting the pointer even if it is
      unused. This makes the driver code look nicer, and it gives better
      compile-time coverage when test building on other architectures.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 0df4fabe ("iommu/mediatek: Add mt8173 IOMMU driver")
      Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      b70bb984
  12. 29 1月, 2016 1 次提交
  13. 22 10月, 2015 3 次提交
  14. 15 10月, 2015 1 次提交
    • R
      iommu: Implement common IOMMU ops for DMA mapping · 0db2e5d1
      Robin Murphy 提交于
      Taking inspiration from the existing arch/arm code, break out some
      generic functions to interface the DMA-API to the IOMMU-API. This will
      do the bulk of the heavy lifting for IOMMU-backed dma-mapping.
      
      Since associating an IOVA allocator with an IOMMU domain is a fairly
      common need, rather than introduce yet another private structure just to
      do this for ourselves, extend the top-level struct iommu_domain with the
      notion. A simple opaque cookie allows reuse by other IOMMU API users
      with their various different incompatible allocator types.
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      0db2e5d1
  15. 18 7月, 2015 1 次提交
  16. 11 6月, 2015 1 次提交
  17. 09 6月, 2015 3 次提交
  18. 31 3月, 2015 3 次提交
  19. 02 12月, 2014 2 次提交
  20. 14 11月, 2014 2 次提交
  21. 04 11月, 2014 1 次提交
    • O
      iommu: Add iommu_map_sg() function · 315786eb
      Olav Haugan 提交于
      Mapping and unmapping are more often than not in the critical path.
      map_sg allows IOMMU driver implementations to optimize the process
      of mapping buffers into the IOMMU page tables.
      
      Instead of mapping a buffer one page at a time and requiring potentially
      expensive TLB operations for each page, this function allows the driver
      to map all pages in one go and defer TLB maintenance until after all
      pages have been mapped.
      
      Additionally, the mapping operation would be faster in general since
      clients does not have to keep calling map API over and over again for
      each physically contiguous chunk of memory that needs to be mapped to a
      virtually contiguous region.
      Signed-off-by: NOlav Haugan <ohaugan@codeaurora.org>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      315786eb
  22. 30 9月, 2014 1 次提交
    • W
      iommu: introduce domain attribute for nesting IOMMUs · c02607aa
      Will Deacon 提交于
      Some IOMMUs, such as the ARM SMMU, support two stages of translation.
      The idea behind such a scheme is to allow a guest operating system to
      use the IOMMU for DMA mappings in the first stage of translation, with
      the hypervisor then installing mappings in the second stage to provide
      isolation of the DMA to the physical range assigned to that virtual
      machine.
      
      In order to allow IOMMU domains to be used for second-stage translation,
      this patch adds a new iommu_attr (IOMMU_ATTR_NESTING) for setting
      second-stage domains prior to device attach. The attribute can also be
      queried to see if a domain is actually making use of nesting.
      Acked-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      c02607aa
  23. 25 9月, 2014 1 次提交
新手
引导
客服 返回
顶部