linux-stable.git/drivers/iommu, branch v3.2.97

iommu/amd: Finish TLB flush in amd_iommu_unmap()

2018-01-01T20:50:58+00:00

commit ce76353f169a6471542d999baf3d29b121dce9c0 upstream.

The function only sends the flush command to the IOMMU(s),
but does not wait for its completion when it returns. Fix
that.

Fixes: 601367d76bd1 ('x86/amd-iommu: Remove iommu_flush_domain function')
Signed-off-by: Joerg Roedel 
Signed-off-by: Ben Hutchings

iommu/amd: Fix the left value check of cmd buffer

2017-03-16T02:18:39+00:00

commit 432abf68a79332282329286d190e21fe3ac02a31 upstream.

The generic command buffer entry is 128 bits (16 bytes), so the offset
of tail and head pointer should be 16 bytes aligned and increased with
0x10 per command.

When cmd buf is full, head = (tail + 0x10) % CMD_BUFFER_SIZE.

So when left space of cmd buf should be able to store only two
command, we should be issued one COMPLETE_WAIT additionally to wait
all older commands completed. Then the left space should be increased
after IOMMU fetching from cmd buf.

So left check value should be left <= 0x20 (two commands).

Signed-off-by: Huang Rui 
Fixes: ac0ea6e92b222 ('x86/amd-iommu: Improve handling of full command buffer')
Signed-off-by: Joerg Roedel 
Signed-off-by: Ben Hutchings

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

2017-02-23T03:50:49+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: Ben Hutchings

iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG

2016-04-01T00:54:31+00:00

commit fda3bec12d0979aae3f02ee645913d66fbc8a26e upstream.

This is a 32-bit register. Apparently harmless on real hardware, but
causing justified warnings in simulation.

Signed-off-by: CQ Tang 
Signed-off-by: David Woodhouse 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

iommu/vt-d: Fix ATSR handling for Root-Complex integrated endpoints

2015-11-27T12:48:20+00:00

commit d14053b3c714178525f22660e6aaf41263d00056 upstream.

The VT-d specification says that "Software must enable ATS on endpoint
devices behind a Root Port only if the Root Port is reported as
supporting ATS transactions."

We walk up the tree to find a Root Port, but for integrated devices we
don't find one — we get to the host bridge. In that case we *should*
allow ATS. Currently we don't, which means that we are incorrectly
failing to use ATS for the integrated graphics. Fix that.

We should never break out of this loop "naturally" with bus==NULL,
since we'll always find bridge==NULL in that case (and now return 1).

So remove the check for (!bridge) after the loop, since it can never
happen. If it did, it would be worthy of a BUG_ON(!bridge). But since
it'll oops anyway in that case, that'll do just as well.

Signed-off-by: David Woodhouse 
[bwh: Backported to 3.2:
 - Adjust context
 - There's no (!bridge) check to remove]
Signed-off-by: Ben Hutchings

iommu/vt-d: fix range computation when making room for large pages

2015-11-17T15:54:43+00:00

commit ba2374fd2bf379f933773811fdb06cb6a5445f41 upstream.

In preparation for the installation of a large page, any small page
tables that may still exist in the target IOV address range are
removed.  However, if a scatter/gather list entry is large enough to
fit more than one large page, the address space for any subsequent
large pages is not cleared of conflicting small page tables.

This can cause legitimate mapping requests to fail with errors of the
form below, potentially followed by a series of IOMMU faults:

ERROR: DMA PTE for vPFN 0xfde00 already set (to 7f83a4003 not 7e9e00083)

In this example, a 4MiB scatter/gather list entry resulted in the
successful installation of a large page @ vPFN 0xfdc00, followed by
a failed attempt to install another large page @ vPFN 0xfde00, due to
the presence of a pointer to a small page table @ 0x7f83a4000.

To address this problem, compute the number of large pages that fit
into a given scatter/gather list entry, and use it to derive the
last vPFN covered by the large page(s).

Signed-off-by: Christian Zander 
Signed-off-by: David Woodhouse 
[bwh: Backported to 3.2:
 - Add the lvl_pages variable, added by an earlier commit upstream
 - Also change arguments to dma_pte_clear_range(), which is called by
   dma_pte_free_pagetable() upstream]
Signed-off-by: Ben Hutchings

iommu/vt-d: Fix an off-by-one bug in __domain_mapping()

2015-02-20T00:49:29+00:00

commit cc4f14aa170d895c9a43bdb56f62070c8a6da908 upstream.

There's an off-by-one bug in function __domain_mapping(), which may
trigger the BUG_ON(nr_pages < lvl_pages) when
	(nr_pages + 1) & superpage_mask == 0

The issue was introduced by commit 9051aa0268dc "intel-iommu: Combine
domain_pfn_mapping() and domain_sg_mapping()", which sets sg_res to
"nr_pages + 1" to avoid some of the 'sg_res==0' code paths.

It's safe to remove extra "+1" because sg_res is only used to calculate
page size now.

Reported-And-Tested-by: Sudeep Dutt 
Signed-off-by: Jiang Liu 
Acked-By: David Woodhouse 
Signed-off-by: Joerg Roedel 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

iommu/amd: Fix cleanup_domain for mass device removal

2014-09-13T22:41:45+00:00

commit 9b29d3c6510407d91786c1cf9183ff4debb3473a upstream.

When multiple devices are detached in __detach_device, they
are also removed from the domains dev_list. This makes it
unsafe to use list_for_each_entry_safe, as the next pointer
might also not be in the list anymore after __detach_device
returns. So just repeatedly remove the first element of the
list until it is empty.

Tested-by: Marti Raudsepp 
Signed-off-by: Joerg Roedel 
Signed-off-by: Ben Hutchings

iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains

2014-09-13T22:41:40+00:00

commit c875d2c1b8083cd627ea0463e20bf22c2d7421ee upstream.

The user of the IOMMU API domain expects to have full control of
the IOVA space for the domain.  RMRRs are fundamentally incompatible
with that idea.  We can neither map the RMRR into the IOMMU API
domain, nor can we guarantee that the device won't continue DMA with
the area described by the RMRR as part of the new domain.  Therefore
we must prevent such devices from being used by the IOMMU API.

Signed-off-by: Alex Williamson 
Cc: David Woodhouse 
Signed-off-by: Joerg Roedel 
[bwh: Backported to 3.2: driver only operates on PCI devices]
Signed-off-by: Ben Hutchings

iommu/vt-d: Disable translation if already enabled

2014-08-06T17:07:42+00:00

commit 3a93c841c2b3b14824f7728dd74bd00a1cedb806 upstream.

This patch disables translation(dma-remapping) before its initialization
if it is already enabled.

This is needed for kexec/kdump boot. If dma-remapping is enabled in the
first kernel, it need to be disabled before initializing its page table
during second kernel boot. Wei Hu also reported that this is needed
when second kernel boots with intel_iommu=off.

Basically iommu->gcmd is used to know whether translation is enabled or
disabled, but it is always zero at boot time even when translation is
enabled since iommu->gcmd is initialized without considering such a
case. Therefor this patch synchronizes iommu->gcmd value with global
command register when iommu structure is allocated.

Signed-off-by: Takao Indoh 
Signed-off-by: Joerg Roedel 
[wyj: Backported to 3.4: adjust context]
Signed-off-by: Yijing Wang 
Signed-off-by: Ben Hutchings