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

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

2013-02-06T04:33:55+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 
Signed-off-by: Ben Hutchings

IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround

2013-02-06T04:33:49+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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

iommu/intel: disable DMAR for g4x integrated gfx

2013-02-06T04:33:46+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 
Acked-By: David Woodhouse 
Tested-by: stathis 
Tested-by: Mihai Moldovan 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

intel-iommu: Free old page tables before creating superpage

2013-01-03T03:33:44+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: Ben Hutchings

intel-iommu: Default to non-coherent for domains unattached to iommus

2012-10-17T02:48:32+00:00

commit 2e12bc29fc5a12242d68e11875db3dd58efad9ff upstream.

domain_update_iommu_coherency() currently defaults to setting domains
as coherent when the domain is not attached to any iommus.  This
allows for a window in domain_context_mapping_one() where such a
domain can update context entries non-coherently, and only after
update the domain capability to clear iommu_coherency.

This can be seen using KVM device assignment on VT-d systems that
do not support coherency in the ecap register.  When a device is
added to a guest, a domain is created (iommu_coherency = 0), the
device is attached, and ranges are mapped.  If we then hot unplug
the device, the coherency is updated and set to the default (1)
since no iommus are attached to the domain.  A subsequent attach
of a device makes use of the same dmar domain (now marked coherent)
updates context entries with coherency enabled, and only disables
coherency as the last step in the process.

To fix this, switch domain_update_iommu_coherency() to use the
safer, non-coherent default for domains not attached to iommus.

Signed-off-by: Alex Williamson 
Tested-by: Donald Dutile 
Acked-by: Donald Dutile 
Acked-by: Chris Wright 
Signed-off-by: Joerg Roedel 
[bwh: Backported to 3.2: dmar_domain::iommu_bmp is a single unsigned long
 not an array, so add &]
Signed-off-by: Ben Hutchings

irq_remap: disable IRQ remapping if any IOAPIC lacks an IOMMU

2012-10-10T02:31:13+00:00

commit 32ab31e01e2def6f48294d872d9bb42573aae00f upstream.

The ACPI tables in the Macbook Air 5,1 define a single IOAPIC with id 2,
but the only remapping unit described in the DMAR table matches id 0.
Interrupt remapping fails as a result, and the kernel panics with the
message "timer doesn't work through Interrupt-remapped IO-APIC."

To fix this, check each IOAPIC for a corresponding IOMMU. If an IOMMU is
not found, do not allow IRQ remapping to be enabled.

v2: Move check to parse_ioapics_under_ir(), raise log level to KERN_ERR,
    and add FW_BUG to the log message
v3: Skip check if IOMMU doesn't support interrupt remapping and remove
    existing check that the IOMMU count equals the IOAPIC count

Acked-by: Suresh Siddha 
Signed-off-by: Seth Forshee 
Acked-by: Yinghai Lu 
Signed-off-by: Joerg Roedel 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

iommu/amd: Fix hotplug with iommu=pt

2012-08-02T13:37:52+00:00

commit 2c9195e990297068d0f1f1bd8e2f1d09538009da upstream.

This did not work because devices are not put into the
pt_domain. Fix this.

Signed-off-by: Joerg Roedel 
[bwh: Backported to 3.2: do not use iommu_dev_data::passthrough]
Signed-off-by: Ben Hutchings

iommu/amd: Initialize dma_ops for hotplug and sriov devices

2012-07-25T03:11:07+00:00

commit ac1534a55d1e87d59a21c09c570605933b551480 upstream.

When a device is added to the system at runtime the AMD
IOMMU driver initializes the necessary data structures to
handle translation for it. But it forgets to change the
per-device dma_ops to point to the AMD IOMMU driver. So
mapping actually never happens and all DMA accesses end in
an IO_PAGE_FAULT. Fix this.

Reported-by: Stefan Assmann 
Signed-off-by: Joerg Roedel 
[bwh: Backported to 3.2:
 - Adjust context
 - Use global iommu_pass_through; there is no per-device pass_through]
Signed-off-by: Ben Hutchings

iommu/amd: Fix missing iommu_shutdown initialization in passthrough mode

2012-07-25T03:11:06+00:00

commit f2f12b6fc032c7b1419fd6db84e2868b5f05a878 upstream.

The iommu_shutdown callback is not initialized when the AMD
IOMMU driver runs in passthrough mode. Fix that by moving
the callback initialization before the check for
passthrough mode.

Signed-off-by: Shuah Khan 
Signed-off-by: Joerg Roedel 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

iommu/amd: Cache pdev pointer to root-bridge

2012-06-10T13:42:08+00:00

commit c1bf94ec1e12d76838ad485158aecf208ebd8fb9 upstream.

At some point pci_get_bus_and_slot started to enable
interrupts. Since this function is used in the
amd_iommu_resume path it will enable interrupts on resume
which causes a warning. The fix will use a cached pointer
to the root-bridge to re-enable the IOMMU in case the BIOS
is broken.

Signed-off-by: Joerg Roedel 
Signed-off-by: Ben Hutchings