linux-toradex.git/drivers/iommu, branch v3.4.62

iommu/amd: Only unmap large pages from the first pte

2013-07-28T23:25:47+00:00

commit 60d0ca3cfd199b6612bbbbf4999a3470dad38bb1 upstream.

If we use a large mapping, the expectation is that only unmaps from
the first pte in the superpage are supported.  Unmaps from offsets
into the superpage should fail (ie. return zero sized unmap).  In the
current code, unmapping from an offset clears the size of the full
mapping starting from an offset.  For instance, if we map a 16k
physically contiguous range at IOVA 0x0 with a large page, then
attempt to unmap 4k at offset 12k, 4 ptes are cleared (12k - 28k) and
the unmap returns 16k unmapped.  This potentially incorrectly clears
valid mappings and confuses drivers like VFIO that use the unmap size
to release pinned pages.

Fix by refusing to unmap from offsets into the page.

Signed-off-by: Alex Williamson 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Workaround for ERBT1312

2013-06-07T19:49:48+00:00

commit d3263bc29706e42f74d8800807c2dedf320d77f1 upstream.

Work around an IOMMU  hardware bug where clearing the
EVT_INT or PPR_INT bit in the status register may race with
the hardware trying to set it again. When not handled the
bit might not be cleared and we lose all future event or ppr
interrupts.

Reported-by: Suravee Suthikulpanit 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Re-enable IOMMU event log interrupt after handling.

2013-06-07T19:49:35+00:00

commit 925fe08bce38d1ff052fe2209b9e2b8d5fbb7f98 upstream.

Current driver does not clear the IOMMU event log interrupt bit
in the IOMMU status register after processing an interrupt.
This causes the IOMMU hardware to generate event log interrupt only once.
This has been observed in both IOMMU v1 and V2 hardware.
This patch clears the bit by writing 1 to bit 1 of the IOMMU
status register (MMIO Offset 2020h)

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Make sure dma_ops are set for hotplug devices

2013-04-05T17:04:18+00:00

commit c2a2876e863356b092967ea62bebdb4dd663af80 upstream.

There is a bug introduced with commit 27c2127 that causes
devices which are hot unplugged and then hot-replugged to
not have per-device dma_ops set. This causes these devices
to not function correctly. Fixed with this patch.

Reported-by: Andreas Degert 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Initialize device table after dma_ops

2013-03-03T22:06:37+00:00

commit f528d980c17b8714aedc918ba86e058af914d66b upstream.

When dma_ops are initialized the unity mappings are
created. The init_device_table_dma() function makes sure DMA
from all devices is blocked by default. This opens a short
window in time where DMA to unity mapped regions is blocked
by the IOMMU. Make sure this does not happen by initializing
the device table after dma_ops.

Signed-off-by: Joerg Roedel 
Signed-off-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman

intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets

2013-02-28T14:59:03+00:00

commit 210561ffd72d00eccf12c0131b8024d5436bae95 upstream.

We already have the quirk entry for the mobile platform, but also
reports on some desktop versions. So be paranoid and set it
everywhere.

References: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html
Reported-and-tested-by: Mihai Moldovan 
Cc: David Woodhouse 
Cc: "Sankaran, Rajesh" 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

iommu/intel: disable DMAR for g4x integrated gfx

2013-02-04T00:24:41+00:00

commit 9452618e7462181ed9755236803b6719298a13ce upstream.

DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
So don't bother, but instead disable it by default to allow distros to
unconditionally enable DMAR support.

v2: Actually wire up the right quirk entry, spotted by Adam Jackson.

Note that according to intel marketing materials only g45 and gm45
support DMAR/VT-d. So we have reports for all relevant gen4 pci ids by
now. Still, keep all the other gen4 ids in the quirk table in case the
marketing stuff confused me again, which would not be the first time.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51921
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163
Cc: Adam Jackson 
Cc: David Woodhouse 
Cc: stable@vger.kernel.org
Acked-By: David Woodhouse 
Tested-by: stathis 
Tested-by: Mihai Moldovan 
Signed-off-by: Daniel Vetter 
Signed-off-by: Mihai Moldovan 
Signed-off-by: Greg Kroah-Hartman

IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround

2013-02-04T00:24:40+00:00

commit 318fe782539c4150d1b8e4e6c9dc3a896512cb8a upstream.

The IOMMU may stop processing page translations due to a perceived lack
of credits for writing upstream peripheral page service request (PPR)
or event logs. If the L2B miscellaneous clock gating feature is enabled
the IOMMU does not properly register credits after the log request has
completed, leading to a potential system hang.

BIOSes are supposed to disable L2B micellaneous clock gating by setting
L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This
patch corrects that for those which do not enable this workaround.

Signed-off-by: Suravee Suthikulpanit 
Acked-by: Borislav Petkov 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Prevent devices with RMRRs from being placed into SI Domain

2013-01-21T19:45:24+00:00

commit ea2447f700cab264019b52e2b417d689e052dcfd upstream.

This patch is to prevent non-USB devices that have RMRRs associated with them from
being placed into the SI Domain during init. This fixes the issue where the RMRR info
for devices being placed in and out of the SI Domain gets lost.

Signed-off-by: Thomas Mingarelli 
Tested-by: Shuah Khan 
Reviewed-by: Donald Dutile 
Reviewed-by: Alex Williamson 
Signed-off-by: Joerg Roedel 
Cc: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Free old page tables before creating superpage

2013-01-17T16:50:46+00:00

commit 6491d4d02893d9787ba67279595990217177b351 upstream.

The dma_pte_free_pagetable() function will only free a page table page
if it is asked to free the *entire* 2MiB range that it covers. So if a
page table page was used for one or more small mappings, it's likely to
end up still present in the page tables... but with no valid PTEs.

This was fine when we'd only be repopulating it with 4KiB PTEs anyway
but the same virtual address range can end up being reused for a
*large-page* mapping. And in that case were were trying to insert the
large page into the second-level page table, and getting a complaint
from the sanity check in __domain_mapping() because there was already a
corresponding entry. This was *relatively* harmless; it led to a memory
leak of the old page table page, but no other ill-effects.

Fix it by calling dma_pte_clear_range (hopefully redundant) and
dma_pte_free_pagetable() before setting up the new large page.

Signed-off-by: David Woodhouse 
Tested-by: Ravi Murty 
Tested-by: Sudeep Dutt 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman