1. 25 9月, 2018 2 次提交
    • R
      iommu: Tidy up window attributes · 701d8a62
      Robin Murphy 提交于
      The external interface to get/set window attributes is already
      abstracted behind iommu_domain_{get,set}_attr(), so there's no real
      reason for the internal interface to be different. Since we only have
      one window-based driver anyway, clean up the core code by just moving
      the DOMAIN_ATTR_WINDOWS handling directly into the PAMU driver.
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      701d8a62
    • R
      iommu: Add fast hook for getting DMA domains · 6af588fe
      Robin Murphy 提交于
      While iommu_get_domain_for_dev() is the robust way for arbitrary IOMMU
      API callers to retrieve the domain pointer, for DMA ops domains it
      doesn't scale well for large systems and multi-queue devices, since the
      momentary refcount adjustment will lead to exclusive cacheline contention
      when multiple CPUs are operating in parallel on different mappings for
      the same device.
      
      In the case of DMA ops domains, however, this refcounting is actually
      unnecessary, since they already imply that the group exists and is
      managed by platform code and IOMMU internals (by virtue of
      iommu_group_get_for_dev()) such that a reference will already be held
      for the lifetime of the device. Thus we can avoid the bottleneck by
      providing a fast lookup specifically for the DMA code to retrieve the
      default domain it already knows it has set up - a simple read-only
      dereference plays much nicer with cache-coherency protocols.
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Tested-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      6af588fe
  2. 08 8月, 2018 1 次提交
  3. 27 7月, 2018 2 次提交
  4. 06 7月, 2018 1 次提交
    • G
      iommu: Enable debugfs exposure of IOMMU driver internals · bad614b2
      Gary R Hook 提交于
      Provide base enablement for using debugfs to expose internal data of an
      IOMMU driver. When called, create the /sys/kernel/debug/iommu directory.
      
      Emit a strong warning at boot time to indicate that this feature is
      enabled.
      
      This function is called from iommu_init, and creates the initial DebugFS
      directory. Drivers may then call iommu_debugfs_new_driver_dir() to
      instantiate a device-specific directory to expose internal data.
      It will return a pointer to the new dentry structure created in
      /sys/kernel/debug/iommu, or NULL in the event of a failure.
      
      Since the IOMMU driver can not be removed from the running system, there
      is no need for an "off" function.
      Signed-off-by: NGary R Hook <gary.hook@amd.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      bad614b2
  5. 15 5月, 2018 2 次提交
  6. 14 2月, 2018 1 次提交
  7. 21 12月, 2017 1 次提交
  8. 31 8月, 2017 1 次提交
    • J
      iommu: Introduce Interface for IOMMU TLB Flushing · add02cfd
      Joerg Roedel 提交于
      With the current IOMMU-API the hardware TLBs have to be
      flushed in every iommu_ops->unmap() call-back.
      
      For unmapping large amounts of address space, like it
      happens when a KVM domain with assigned devices is
      destroyed, this causes thousands of unnecessary TLB flushes
      in the IOMMU hardware because the unmap call-back runs for
      every unmapped physical page.
      
      With the TLB Flush Interface and the new iommu_unmap_fast()
      function introduced here the need to clean the hardware TLBs
      is removed from the unmapping code-path. Users of
      iommu_unmap_fast() have to explicitly call the TLB-Flush
      functions to sync the page-table changes to the hardware.
      
      Three functions for TLB-Flushes are introduced:
      
      	* iommu_flush_tlb_all() - Flushes all TLB entries
      	                          associated with that
      				  domain. TLBs entries are
      				  flushed when this function
      				  returns.
      
      	* iommu_tlb_range_add() - This will add a given
      				  range to the flush queue
      				  for this domain.
      
      	* iommu_tlb_sync() - Flushes all queued ranges from
      			     the hardware TLBs. Returns when
      			     the flush is finished.
      
      The semantic of this interface is intentionally similar to
      the iommu_gather_ops from the io-pgtable code.
      
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      add02cfd
  9. 18 8月, 2017 1 次提交
    • R
      iommu: Avoid NULL group dereference · 1464d0b1
      Robin Murphy 提交于
      The recently-removed FIXME in iommu_get_domain_for_dev() turns out to
      have been a little misleading, since that check is still worthwhile even
      when groups *are* universal. We have a few IOMMU-aware drivers which
      only care whether their device is already attached to an existing domain
      or not, for which the previous behaviour of iommu_get_domain_for_dev()
      was ideal, and who now crash if their device does not have an IOMMU.
      
      With IOMMU groups now serving as a reliable indicator of whether a
      device has an IOMMU or not (barring false-positives from VFIO no-IOMMU
      mode), drivers could arguably do this:
      
      	group = iommu_group_get(dev);
      	if (group) {
      		domain = iommu_get_domain_for_dev(dev);
      		iommu_group_put(group);
      	}
      
      However, rather than duplicate that code across multiple callsites,
      particularly when it's still only the domain they care about, let's skip
      straight to the next step and factor out the check into the common place
      it applies - in iommu_get_domain_for_dev() itself. Sure, it ends up
      looking rather familiar, but now it's backed by the reasoning of having
      a robust API able to do the expected thing for all devices regardless.
      
      Fixes: 05f80300 ("iommu: Finish making iommu_group support mandatory")
      Reported-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      1464d0b1
  10. 16 8月, 2017 1 次提交
  11. 10 8月, 2017 1 次提交
    • R
      iommu: Finish making iommu_group support mandatory · 05f80300
      Robin Murphy 提交于
      Now that all the drivers properly implementing the IOMMU API support
      groups (I'm ignoring the etnaviv GPU MMUs which seemingly only do just
      enough to convince the ARM DMA mapping ops), we can remove the FIXME
      workarounds from the core code. In the process, it also seems logical to
      make the .device_group callback non-optional for drivers calling
      iommu_group_get_for_dev() - the current callers all implement it anyway,
      and it doesn't make sense for any future callers not to either.
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      05f80300
  12. 28 6月, 2017 2 次提交
  13. 27 4月, 2017 1 次提交
  14. 20 4月, 2017 1 次提交
  15. 06 4月, 2017 1 次提交
    • W
      iommu: Allow default domain type to be set on the kernel command line · fccb4e3b
      Will Deacon 提交于
      The IOMMU core currently initialises the default domain for each group
      to IOMMU_DOMAIN_DMA, under the assumption that devices will use
      IOMMU-backed DMA ops by default. However, in some cases it is desirable
      for the DMA ops to bypass the IOMMU for performance reasons, reserving
      use of translation for subsystems such as VFIO that require it for
      enforcing device isolation.
      
      Rather than modify each IOMMU driver to provide different semantics for
      DMA domains, instead we introduce a command line parameter that can be
      used to change the type of the default domain. Passthrough can then be
      specified using "iommu.passthrough=1" on the kernel command line.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      fccb4e3b
  16. 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
  17. 10 2月, 2017 4 次提交
  18. 06 2月, 2017 2 次提交
  19. 23 1月, 2017 5 次提交
  20. 17 1月, 2017 1 次提交
    • R
      iommu: Handle default domain attach failure · 797a8b4d
      Robin Murphy 提交于
      We wouldn't normally expect ops->attach_dev() to fail, but on IOMMUs
      with limited hardware resources, or generally misconfigured systems,
      it is certainly possible. We report failure correctly from the external
      iommu_attach_device() interface, but do not do so in iommu_group_add()
      when attaching to the default domain. The result of failure there is
      that the device, group and domain all get left in a broken,
      part-configured state which leads to weird errors and misbehaviour down
      the line when IOMMU API calls sort-of-but-don't-quite work.
      
      Check the return value of __iommu_attach_device() on the default domain,
      and refactor the error handling paths to cope with its failure and clean
      up correctly in such cases.
      
      Fixes: e39cb8a3 ("iommu: Make sure a device is always attached to a domain")
      Reported-by: NPunit Agrawal <punit.agrawal@arm.com>
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      797a8b4d
  21. 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
  22. 15 11月, 2016 1 次提交
  23. 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
  24. 13 7月, 2016 3 次提交
  25. 09 5月, 2016 1 次提交
    • R
      iommu: Allow selecting page sizes per domain · d16e0faa
      Robin Murphy 提交于
      Many IOMMUs support multiple page table formats, meaning that any given
      domain may only support a subset of the hardware page sizes presented in
      iommu_ops->pgsize_bitmap. There are also certain use-cases where the
      creator of a domain may want to control which page sizes are used, for
      example to force the use of hugepage mappings to reduce pagetable walk
      depth.
      
      To this end, add a per-domain pgsize_bitmap to represent the subset of
      page sizes actually in use, to make it possible for domains with
      different requirements to coexist.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      [rm: hijacked and rebased original patch with new commit message]
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      d16e0faa
  26. 12 4月, 2016 1 次提交