linux-toradex.git/drivers/iommu, branch v4.4.36

iommu/vt-d: Fix IOMMU lookup for SR-IOV Virtual Functions

2016-12-02T08:09:00+00:00

commit 1c387188c60f53b338c20eee32db055dfe022a9b upstream.

The VT-d specification (§8.3.3) says:
    ‘Virtual Functions’ of a ‘Physical Function’ are under the scope
    of the same remapping unit as the ‘Physical Function’.

The BIOS is not required to list all the possible VFs in the scope
tables, and arguably *shouldn't* make any attempt to do so, since there
could be a huge number of them.

This has been broken basically for ever — the VF is never going to match
against a specific unit's scope, so it ends up being assigned to the
INCLUDE_ALL IOMMU. Which was always actually correct by coincidence, but
now we're looking at Root-Complex integrated devices with SR-IOV support
it's going to start being wrong.

Fix it to simply use pci_physfn() before doing the lookup for PCI devices.

Signed-off-by: Sainath Grandhi 
Signed-off-by: Ashok Raj 
Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Fix PASID table allocation

2016-12-02T08:09:00+00:00

commit 910170442944e1f8674fd5ddbeeb8ccd1877ea98 upstream.

Somehow I ended up with an off-by-three error in calculating the size of
the PASID and PASID State tables, which triggers allocations failures as
those tables unfortunately have to be physically contiguous.

In fact, even the *correct* maximum size of 8MiB is problematic and is
wont to lead to allocation failures. Since I have extracted a promise
that this *will* be fixed in hardware, I'm happy to limit it on the
current hardware to a maximum of 0x20000 PASIDs, which gives us 1MiB
tables — still not ideal, but better than before.

Reported by Mika Kuoppala  and also by
Xunlei Pang  who submitted a simpler patch to fix
only the allocation (and not the free) to the "correct" limit... which
was still problematic.

Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Fix dead-locks in disable_dmar_iommu() path

2016-11-18T09:48:36+00:00

commit bea64033dd7b5fb6296eda8266acab6364ce1554 upstream.

It turns out that the disable_dmar_iommu() code-path tried
to get the device_domain_lock recursivly, which will
dead-lock when this code runs on dmar removal. Fix both
code-paths that could lead to the dead-lock.

Fixes: 55d940430ab9 ('iommu/vt-d: Get rid of domain->iommu_lock')
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Free domain id when free a domain of struct dma_ops_domain

2016-11-18T09:48:36+00:00

commit c3db901c54466a9c135d1e6e95fec452e8a42666 upstream.

The current code missed freeing domain id when free a domain of
struct dma_ops_domain.

Signed-off-by: Baoquan He 
Fixes: ec487d1a110a ('x86, AMD IOMMU: add domain allocation and deallocation functions')
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

Add braces to avoid "ambiguous ‘else’" compiler warnings

2016-09-30T08:18:35+00:00

commit 194dc870a5890e855ecffb30f3b80ba7c88f96d6 upstream.

Some of our "for_each_xyz()" macro constructs make gcc unhappy about
lack of braces around if-statements inside or outside the loop, because
the loop construct itself has a "if-then-else" statement inside of it.

The resulting warnings look something like this:

  drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_dump_lrc’:
  drivers/gpu/drm/i915/i915_debugfs.c:2103:6: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses]
     if (ctx != dev_priv->kernel_context)
        ^

even if the code itself is fine.

Since the warning is fairly easy to avoid by adding a braces around the
if-statement near the for_each_xyz() construct, do so, rather than
disabling the otherwise potentially useful warning.

(The if-then-else statements used in the "for_each_xyz()" constructs are
designed to be inherently safe even with no braces, but in this case
it's quite understandable that gcc isn't really able to tell that).

This finally leaves the standard "allmodconfig" build with just a
handful of remaining warnings, so new and valid warnings hopefully will
stand out.

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

iommu/arm-smmu: Don't BUG() if we find aborting STEs with disable_bypass

2016-09-07T06:32:41+00:00

commit 5bc0a11664e17e9f9551983f5b660bd48b57483c upstream.

The disable_bypass cmdline option changes the SMMUv3 driver to put down
faulting stream table entries by default, as opposed to bypassing
transactions from unconfigured devices.

In this mode of operation, it is entirely expected to see aborting
entries in the stream table if and when we come to installing a valid
translation, so don't trigger a BUG() as a result of misdiagnosing these
entries as stream table corruption.

Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices")
Tested-by: Robin Murphy 
Reported-by: Robin Murphy 
Reviewed-by: Robin Murphy 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

iommu/arm-smmu: Fix CMDQ error handling

2016-09-07T06:32:40+00:00

commit aea2037e0d3e23c3be1498feae29f71ca997d9e6 upstream.

In the unlikely event of a global command queue error, the ARM SMMUv3
driver attempts to convert the problematic command into a CMD_SYNC and
resume the command queue. Unfortunately, this code is pretty badly
broken:

  1. It uses the index into the error string table as the CMDQ index,
     so we probably read the wrong entry out of the queue

  2. The arguments to queue_write are the wrong way round, so we end up
     writing from the queue onto the stack.

These happily cancel out, so the kernel is likely to stay alive, but
the command queue will probably fault again when we resume.

This patch fixes the error handling code to use the correct queue index
and write back the CMD_SYNC to the faulting entry.

Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices")
Reported-by: Diwakar Subraveti 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

iommu/dma: Don't put uninitialised IOVA domains

2016-09-07T06:32:40+00:00

commit 3ec60043f7c02e1f79e4a90045ff2d2e80042941 upstream.

Due to the limitations of having to wait until we see a device's DMA
restrictions before we know how we want an IOVA domain initialised,
there is a window for error if a DMA ops domain is allocated but later
freed without ever being used. In that case, init_iova_domain() was
never called, so calling put_iova_domain() from iommu_put_dma_cookie()
ends up trying to take an uninitialised lock and crashing.

Make things robust by skipping the call unless the IOVA domain actually
has been initialised, as we probably should have done from the start.

Fixes: 0db2e5d18f76 ("iommu: Implement common IOMMU ops for DMA mapping")
Reported-by: Nate Watterson 
Reviewed-by: Nate Watterson 
Tested-by: Nate Watterson 
Reviewed-by: Eric Auger 
Tested-by: Eric Auger 
Signed-off-by: Robin Murphy 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Update Alias-DTE in update_device_table()

2016-08-20T16:09:21+00:00

commit 3254de6bf74fe94c197c9f819fe62a3a3c36f073 upstream.

Not doing so might cause IO-Page-Faults when a device uses
an alias request-id and the alias-dte is left in a lower
page-mode which does not cover the address allocated from
the iova-allocator.

Fixes: 492667dacc0a ('x86/amd-iommu: Remove amd_iommu_pd_table')
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Init unity mappings only for dma_ops domains

2016-08-20T16:09:21+00:00

commit b548e786ce47017107765bbeb0f100202525ea83 upstream.

The default domain for a device might also be
identity-mapped. In this case the kernel would crash when
unity mappings are defined for the device. Fix that by
making sure the domain is a dma_ops domain.

Fixes: 0bb6e243d7fb ('iommu/amd: Support IOMMU_DOMAIN_DMA type allocation')
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman