kernel/git/stable/linux.git/drivers/iommu, branch linux-3.15.y

iommu/vt-d: fix bug in handling multiple RMRRs for the same PCI device

2014-07-09T18:21:29+00:00

commit 27e249501ca06a3010519c306206cc402b61b5ab upstream. Function dmar_iommu_notify_scope_dev() makes a wrong assumption that there's one RMRR for each PCI device at most, which causes DMA failure on some HP platforms. So enhance dmar_iommu_notify_scope_dev() to handle multiple RMRRs for the same PCI device. Fixbug: https://bugzilla.novell.com/show_bug.cgi?id=879482 Reported-by: Tom Mingarelli Tested-by: Linda Knippers Signed-off-by: Jiang Liu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman

iommu/amd: fix enabling exclusion range for an exact device

2014-05-13T10:33:12+00:00

set_device_exclusion_range(u16 devid, struct ivmd_header *m) enables exclusion range for ONE device. IOMMU does not translate the access to the exclusion range from the device. The device is specified by input argument 'devid'. But 'devid' is not passed to the actual set function set_dev_entry_bit(), instead 'm->devid' is passed. 'm->devid' does not specify the exact device which needs enable the exclusion range. 'm->devid' represents DeviceID field of IVMD, which has different meaning depends on IVMD type. The caller init_exclusion_range() sets 'devid' for ONE device. When m->type is equal to ACPI_IVMD_TYPE_ALL or ACPI_IVMD_TYPE_RANGE, 'm->devid' is not equal to 'devid'. This patch fixes 'm->devid' to 'devid'. Signed-off-by: Su Friendy Signed-off-by: Tamori Masahiro Signed-off-by: Joerg Roedel

iommu/amd: Take mmap_sem when calling get_user_pages

2014-05-13T10:33:11+00:00

get_user_pages requires caller to hold a read lock on mmap_sem. Signed-off-by: Jay Cornwall Signed-off-by: Suravee Suthikulpanit Signed-off-by: Joerg Roedel

iommu/amd: Fix interrupt remapping for aliased devices

2014-05-13T10:33:11+00:00

An apparent cut and paste error prevents the correct flags from being set on the alias device resulting in MSI on conventional PCI devices failing to work. This also produces error events from the IOMMU like: AMD-Vi: Event logged [INVALID_DEVICE_REQUEST device=00:14.4 address=0x000000fdf8000000 flags=0x0a00] Where 14.4 is a PCIe-to-PCI bridge with a device behind it trying to use MSI interrupts. Signed-off-by: Alex Williamson Cc: stable@vger.kernel.org Signed-off-by: Joerg Roedel

Merge git://git.infradead.org/iommu-2.6 into iommu/fixes

2014-04-16T14:09:40+00:00

iommu/arm-smmu: fix panic in arm_smmu_alloc_init_pte

2014-04-15T11:23:11+00:00

kernel panic happened when iommu_unmap a buffer larger than 2MB, more than expected pmd entries got “invalidated”, due to a wrong range passed to arm_smmu_alloc_init_pte. it was likely a typo, now we fix it, passing the correct "end" address to arm_smmu_alloc_init_pte. Signed-off-by: Bin Wang Signed-off-by: Will Deacon

iommu/arm-smmu: Return 0 on unmap failure

2014-04-15T11:19:33+00:00

The IOMMU core expects the unmap operation to return the number of bytes that have been unmapped or 0 on failure, a negative return value being treated like a number of bytes. Signed-off-by: Laurent Pinchart Signed-off-by: Will Deacon

iommu/vt-d: fix bug in matching PCI devices with DRHD/RMRR descriptors

2014-04-15T05:11:58+00:00

Commit "59ce0515cdaf iommu/vt-d: Update DRHD/RMRR/ATSR device scope caches when PCI hotplug happens" introduces a bug, which fails to match PCI devices with DMAR device scope entries if PCI path array in the entry has more than one level. For example, it fails to handle [1D2h 0466 1] Device Scope Entry Type : 01 [1D3h 0467 1] Entry Length : 0A [1D4h 0468 2] Reserved : 0000 [1D6h 0470 1] Enumeration ID : 00 [1D7h 0471 1] PCI Bus Number : 00 [1D8h 0472 2] PCI Path : 1C,04 [1DAh 0474 2] PCI Path : 00,02 And cause DMA failure on HP DL980 as: DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 602 dmar: DMAR:[DMA Read] Request device [02:00.2] fault addr 7f61e000 Reported-and-tested-by: Davidlohr Bueso Signed-off-by: Jiang Liu Signed-off-by: David Woodhouse

iommu/vt-d: Fix get_domain_for_dev() handling of upstream PCIe bridges

2014-04-15T05:01:30+00:00

Commit 146922ec79 ("iommu/vt-d: Make get_domain_for_dev() take struct device") introduced new variables bridge_bus and bridge_devfn to identify the upstream PCIe to PCI bridge responsible for the given target device. Leaving the original bus/devfn variables to identify the target device itself, now that it is no longer assumed to be PCI and we can no longer trivially find that information. However, the patch failed to correctly use the new variables in all cases; instead using the as-yet-uninitialised 'bus' and 'devfn' variables. Reported-by: Alex Williamson Signed-off-by: David Woodhouse

iommu/vt-d: fix memory leakage caused by commit ea8ea46

2014-04-13T12:07:56+00:00

Commit ea8ea46 "iommu/vt-d: Clean up and fix page table clear/free behaviour" introduces possible leakage of DMA page tables due to: for (pte = page_address(pg); !first_pte_in_page(pte); pte++) { if (dma_pte_present(pte) && !dma_pte_superpage(pte)) freelist = dma_pte_list_pagetables(domain, level - 1, pte, freelist); } For the first pte in a page, first_pte_in_page(pte) will always be true, thus dma_pte_list_pagetables() will never be called and leak DMA page tables if level is bigger than 1. Signed-off-by: Jiang Liu Signed-off-by: David Woodhouse