All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code
@ 2011-05-27  1:32 Mike Travis
  2011-05-27  1:32 ` [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask Mike Travis
                   ` (6 more replies)
  0 siblings, 7 replies; 17+ messages in thread
From: Mike Travis @ 2011-05-27  1:32 UTC (permalink / raw)
  To: David Woodhouse, Chris Wright, Andrew Morton, Ingo Molnar
  Cc: Mike Habeck, Jesse Barnes, stable, iommu, linux-pci, linux-kernel


	Various problems exist in the Intel IOMMU PCI driver when
	using DMA remapping in 1:1 identity mode on UV systems and
	devices cannot address all of physical memory.

	This patchset addresses those problems.

-- 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask
  2011-05-27  1:32 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
@ 2011-05-27  1:32 ` Mike Travis
  2011-05-27  7:18   ` [stable] " Greg KH
  2011-05-27  1:32 ` [PATCH 2/7] Intel pci: Speed up processing of the identity_mapping function Mike Travis
                   ` (5 subsequent siblings)
  6 siblings, 1 reply; 17+ messages in thread
From: Mike Travis @ 2011-05-27  1:32 UTC (permalink / raw)
  To: David Woodhouse, Chris Wright, Andrew Morton, Ingo Molnar
  Cc: Mike Habeck, Jesse Barnes, stable, iommu, linux-pci, linux-kernel

[-- Attachment #1: check-against-reqd-mask.patch --]
[-- Type: text/plain, Size: 1425 bytes --]

	The identity mapping code appears to make the assumption that
	if the devices dma_mask is greater than 32bits the device can
	use identity mapping.  But that is not true, take the case 
	where we have a 40bit device in a 44bit architecture.  The
	device can potentially receive a physical address that it
	will truncate and cause incorrect addresses to be used.

	Instead check to see if the device's dma_mask is large enough
	to address the system's dma_mask.

From: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Mike Travis <travis@sgi.com>
Reviewed-by: Mike Habeck <habeck@sgi.com>
---
 drivers/pci/intel-iommu.c |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

--- linux.orig/drivers/pci/intel-iommu.c
+++ linux/drivers/pci/intel-iommu.c
@@ -2187,8 +2187,19 @@ static int iommu_should_identity_map(str
 	 * Assume that they will -- if they turn out not to be, then we can 
 	 * take them out of the 1:1 domain later.
 	 */
-	if (!startup)
-		return pdev->dma_mask > DMA_BIT_MASK(32);
+	if (!startup) {
+		/*
+		 * If the device's dma_mask is less than the system's memory
+		 * size then this is not a candidate for identity mapping.
+		 */
+		u64 dma_mask = pdev->dma_mask;
+
+		if (pdev->dev.coherent_dma_mask &&
+		    pdev->dev.coherent_dma_mask < dma_mask)
+			dma_mask = pdev->dev.coherent_dma_mask;
+
+		return dma_mask >= dma_get_required_mask(&pdev->dev);
+	}
 
 	return 1;
 }

-- 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 2/7] Intel pci: Speed up processing of the identity_mapping function
  2011-05-27  1:32 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
  2011-05-27  1:32 ` [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask Mike Travis
@ 2011-05-27  1:32 ` Mike Travis
  2011-05-27  1:32 ` [PATCH 3/7] Intel pci: Dont cache iova above 32bit Mike Travis
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 17+ messages in thread
From: Mike Travis @ 2011-05-27  1:32 UTC (permalink / raw)
  To: David Woodhouse, Chris Wright, Andrew Morton, Ingo Molnar
  Cc: Mike Habeck, Jesse Barnes, stable, iommu, linux-pci, linux-kernel

[-- Attachment #1: speed-up-iommu_no_mapping.patch --]
[-- Type: text/plain, Size: 933 bytes --]

    When there are a large count of PCI devices, and the pass
    through option for iommu is set, much time is spent in the
    identity_mapping function hunting though the iommu domains to
    check if a specific device is "identity mapped".

    Speed up the function by checking the cached info to see if
    it's mapped to the static identity domain.

Signed-off-by: Mike Travis <travis@sgi.com>
---
 drivers/pci/intel-iommu.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux.orig/drivers/pci/intel-iommu.c
+++ linux/drivers/pci/intel-iommu.c
@@ -2106,10 +2106,10 @@ static int identity_mapping(struct pci_d
 	if (likely(!iommu_identity_mapping))
 		return 0;
 
+	info = pdev->dev.archdata.iommu;
+	if (info && info != DUMMY_DEVICE_DOMAIN_INFO)
+		return (info->domain == si_domain);
 
-	list_for_each_entry(info, &si_domain->devices, link)
-		if (info->dev == pdev)
-			return 1;
 	return 0;
 }
 

-- 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 3/7] Intel pci: Dont cache iova above 32bit
  2011-05-27  1:32 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
  2011-05-27  1:32 ` [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask Mike Travis
  2011-05-27  1:32 ` [PATCH 2/7] Intel pci: Speed up processing of the identity_mapping function Mike Travis
@ 2011-05-27  1:32 ` Mike Travis
  2011-05-27  1:32 ` [PATCH 4/7] Intel pci: Use coherent DMA mask when requested Mike Travis
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 17+ messages in thread
From: Mike Travis @ 2011-05-27  1:32 UTC (permalink / raw)
  To: David Woodhouse, Chris Wright, Andrew Morton, Ingo Molnar
  Cc: Mike Habeck, Jesse Barnes, stable, iommu, linux-pci, linux-kernel

[-- Attachment #1: dont-cache-iova-above-32bit.patch --]
[-- Type: text/plain, Size: 2193 bytes --]

Mike Travis and Mike Habeck reported an issue where iova allocation
would return a range that was larger than a device's dma mask.

https://lkml.org/lkml/2011/3/29/423

The dmar initialization code will reserve all PCI MMIO regions and copy
those reservations into a domain specific iova tree.  It is possible for
one of those regions to be above the dma mask of a device.  It is typical
to allocate iovas with a 32bit mask (despite device's dma mask possibly
being larger) and cache the result until it exhausts the lower 32bit
address space.  Freeing the iova range that is >= the last iova in the
lower 32bit range when there is still an iova above the 32bit range will
corrupt the cached iova by pointing it to a region that is above 32bit.
If that region is also larger than the device's dma mask, a subsequent
allocation will return an unusable iova and cause dma failure.

Simply don't cache an iova that is above the 32bit caching boundary.

From: Chris Wright <chrisw@sous-sol.org>
Reported-by: Mike Travis <travis@sgi.com>
Reported-by: Mike Habeck <habeck@sgi.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: stable@kernel.org
Acked-by: Mike Travis <travis@sgi.com>
Tested-by: Mike Habeck <habeck@sgi.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

v3: rb_next() can return NULL, found when testing on my hw

David, Mike Travis will collect and resumbit full series when he's back.

 drivers/pci/iova.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- linux.orig/drivers/pci/iova.c
+++ linux/drivers/pci/iova.c
@@ -63,8 +63,16 @@ __cached_rbnode_delete_update(struct iov
 	curr = iovad->cached32_node;
 	cached_iova = container_of(curr, struct iova, node);
 
-	if (free->pfn_lo >= cached_iova->pfn_lo)
-		iovad->cached32_node = rb_next(&free->node);
+	if (free->pfn_lo >= cached_iova->pfn_lo) {
+		struct rb_node *node = rb_next(&free->node);
+		struct iova *iova = container_of(node, struct iova, node);
+
+		/* only cache if it's below 32bit pfn */
+		if (node && iova->pfn_lo < iovad->dma_32bit_pfn)
+			iovad->cached32_node = node;
+		else
+			iovad->cached32_node = NULL;
+	}
 }
 
 /* Computes the padding size required, to make the

-- 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 4/7] Intel pci: Use coherent DMA mask when requested
  2011-05-27  1:32 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
                   ` (2 preceding siblings ...)
  2011-05-27  1:32 ` [PATCH 3/7] Intel pci: Dont cache iova above 32bit Mike Travis
@ 2011-05-27  1:32 ` Mike Travis
  2011-05-27  1:32 ` [PATCH 5/7] Intel pci: Remove Host Bridge devices from identity mapping Mike Travis
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 17+ messages in thread
From: Mike Travis @ 2011-05-27  1:32 UTC (permalink / raw)
  To: David Woodhouse, Chris Wright, Andrew Morton, Ingo Molnar
  Cc: Mike Habeck, Jesse Barnes, stable, iommu, linux-pci, linux-kernel

[-- Attachment #1: use-coherent-dma-mask.patch --]
[-- Type: text/plain, Size: 806 bytes --]

    The __intel_map_single function is not honoring the passed in
    DMA mask.  This results in not using the coherent DMA mask when
    called from intel_alloc_coherent().

Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Reviewed-by: Mike Habeck <habeck@sgi.com>
---
 drivers/pci/intel-iommu.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- linux.orig/drivers/pci/intel-iommu.c
+++ linux/drivers/pci/intel-iommu.c
@@ -2603,8 +2603,7 @@ static dma_addr_t __intel_map_single(str
 	iommu = domain_get_iommu(domain);
 	size = aligned_nrpages(paddr, size);
 
-	iova = intel_alloc_iova(hwdev, domain, dma_to_mm_pfn(size),
-				pdev->dma_mask);
+	iova = intel_alloc_iova(hwdev, domain, dma_to_mm_pfn(size), dma_mask);
 	if (!iova)
 		goto error;
 

-- 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 5/7] Intel pci: Remove Host Bridge devices from identity mapping
  2011-05-27  1:32 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
                   ` (3 preceding siblings ...)
  2011-05-27  1:32 ` [PATCH 4/7] Intel pci: Use coherent DMA mask when requested Mike Travis
@ 2011-05-27  1:32 ` Mike Travis
  2011-05-27  1:32 ` [PATCH 6/7] Intel pci: Add domain check in domain_remove_one_dev_info Mike Travis
  2011-05-27  1:32 ` [PATCH 7/7] Intel pci: Indicate 64-bit IOMMU passthrough available Mike Travis
  6 siblings, 0 replies; 17+ messages in thread
From: Mike Travis @ 2011-05-27  1:32 UTC (permalink / raw)
  To: David Woodhouse, Chris Wright, Andrew Morton, Ingo Molnar
  Cc: Mike Habeck, Jesse Barnes, stable, iommu, linux-pci, linux-kernel

[-- Attachment #1: remove-pci-host-bridge-devices.patch --]
[-- Type: text/plain, Size: 5828 bytes --]

    When using the 1:1 (identity) PCI DMA remapping, PCI Host Bridge
    devices that do not use the IOMMU causes a kernel panic.  Fix that
    by not inserting those devices into the si_domain.

Signed-off-by: Mike Travis <travis@sgi.com>
Reviewed-by: Mike Habeck <habeck@sgi.com>
---

Specific panic message:

 IOMMU 0 0xfd020000: using Queued invalidation
 IOMMU 1 0xfd040000: using Queued invalidation
 IOMMU 2 0xfd060000: using Queued invalidation
 IOMMU 3 0xfd080000: using Queued invalidation
 IOMMU 4 0xfd0a0000: using Queued invalidation
 IOMMU 5 0xfd0c0000: using Queued invalidation
 IOMMU: hardware identity mapping for device 1000:3e:00.0
 Failed to setup IOMMU pass-through
 BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
 IP: [<ffffffff816378fd>] _raw_spin_lock_irqsave+0xc/0x23
 PGD 0
 Oops: 0002 [#1] SMP
 last sysfs file:
 CPU 512
 Modules linked in:

 Pid: 1, comm: swapper Not tainted 2.6.39-rc7+ #2 Intel Corp. Stoutland Platform
 RIP: 0010:[<ffffffff816378fd>]  [<ffffffff816378fd>] _raw_spin_lock_irqsave+0xc/0x23
 RSP: 0000:ffff88105fd99d00  EFLAGS: 00010046
 RAX: 0000000000000046 RBX: 0000000000000000 RCX: 0000000000000007
 RDX: 0000000000010000 RSI: 00000000000000b8 RDI: 000000000000001c
 RBP: ffff88105fd99d00 R08: 0000000000000000 R09: ffff88107d400470
 R10: 000000000000000a R11: 0000000000000086 R12: 000000000000001c
 R13: 00000000000000b8 R14: ffff88107d82947c R15: 0000000000000286
 FS:  0000000000000000(0000) GS:ffff88107fd00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 000000000000001c CR3: 0000000001c03000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process swapper (pid: 1, threadinfo ffff88105fd98000, task ffff88105fd90000)
 Stack:
  ffff88105fd99d20 ffffffff812ad179 ffff88107d829400 ffff8b6ffe820f00
  ffff88105fd99d40 ffffffff8108eb2f ffff88105fd99d40 ffff88107d829400
  ffff88105fd99d80 ffffffff8108e396 ffff8beffa854c00 ffff88107d829400
 Call Trace:
  [<ffffffff812ad179>] dmar_msi_mask+0x17/0x3b
  [<ffffffff8108eb2f>] irq_shutdown+0x43/0x4e
  [<ffffffff8108e396>] __free_irq+0xd1/0x15d
  [<ffffffff8108e47b>] free_irq+0x59/0x72
  [<ffffffff812b09b3>] free_dmar_iommu+0x10a/0x1cb
  [<ffffffff812acc7f>] free_iommu+0x16/0x30
  [<ffffffff81e85564>] intel_iommu_init+0x8c1/0x9de
  [<ffffffff81e608c7>] ? dma32_reserve_bootmem+0x6/0x6
  [<ffffffff81e608dd>] pci_iommu_init+0x16/0x41
  [<ffffffff81000218>] do_one_initcall+0x7c/0x130
  [<ffffffff81e5b8a2>] kernel_init+0xf9/0x17e
  [<ffffffff8163eab4>] kernel_thread_helper+0x4/0x10
  [<ffffffff81e5b7a9>] ? do_early_param+0x89/0x89
  [<ffffffff8163eab0>] ? gs_change+0xb/0xb
 Code: b8 00 00 01 00 48 89 e5 f0 0f c1 07 0f b7 d0 c1 e8 10 39 c2 74 07 f3 90 0f b7 17 eb f5 c9 c3 55 48 89 e5 9c 58 fa ba 00 00 01 00 <f0> 0f c1 17 0f b7 ca c1 ea 10 39 d1 74 07 f3 90 0f b7 0f eb f5
 RIP  [<ffffffff816378fd>] _raw_spin_lock_irqsave+0xc/0x23
  RSP <ffff88105fd99d00>
 CR2: 000000000000001c
 ---[ end trace 32b2ebdae113b4c3 ]---
 swapper used greatest stack depth: 3952 bytes left
 Kernel panic - not syncing: Attempted to kill init!
 Pid: 1, comm: swapper Tainted: G      D     2.6.39-rc7+ #2
 Call Trace:
  [<ffffffff81040993>] panic+0xb7/0x1be
  [<ffffffff810338f5>] ? task_rq_unlock+0xc/0xe
  [<ffffffff810340d4>] ? sched_move_task+0xb0/0xbb
  [<ffffffff8107c479>] ? __put_css_set+0x24/0x150
  [<ffffffff81043d0c>] do_exit+0xa9/0x775
  [<ffffffff81040ccb>] ? spin_unlock_irqrestore+0x9/0xb
  [<ffffffff81638931>] oops_end+0xb3/0xbb
  [<ffffffff81027a01>] no_context+0x1f5/0x204
  [<ffffffff81027b92>] __bad_area_nosemaphore+0x182/0x1a5
  [<ffffffff81290b55>] ? __delay+0xa/0xc
  [<ffffffff81290b90>] ? __const_udelay+0x39/0x3b
  [<ffffffff81027c2b>] bad_area_nosemaphore+0xe/0x10
  [<ffffffff8163a65c>] do_page_fault+0x170/0x320
  [<ffffffff81290b55>] ? __delay+0xa/0xc
  [<ffffffff8130f8ec>] ? wait_for_xmitr+0x24/0x89
  [<ffffffff81040b9a>] ? __call_console_drivers+0x78/0x8a
  [<ffffffff8163e36e>] ? apic_timer_interrupt+0xe/0x20
  [<ffffffff81637edf>] page_fault+0x1f/0x30
  [<ffffffff816378fd>] ? _raw_spin_lock_irqsave+0xc/0x23
  [<ffffffff812ad179>] dmar_msi_mask+0x17/0x3b
  [<ffffffff8108eb2f>] irq_shutdown+0x43/0x4e
  [<ffffffff8108e396>] __free_irq+0xd1/0x15d
  [<ffffffff8108e47b>] free_irq+0x59/0x72
  [<ffffffff812b09b3>] free_dmar_iommu+0x10a/0x1cb
  [<ffffffff812acc7f>] free_iommu+0x16/0x30
  [<ffffffff81e85564>] intel_iommu_init+0x8c1/0x9de
  [<ffffffff81e608c7>] ? dma32_reserve_bootmem+0x6/0x6
  [<ffffffff81e608dd>] pci_iommu_init+0x16/0x41
  [<ffffffff81000218>] do_one_initcall+0x7c/0x130
  [<ffffffff81e5b8a2>] kernel_init+0xf9/0x17e
  [<ffffffff8163eab4>] kernel_thread_helper+0x4/0x10
  [<ffffffff81e5b7a9>] ? do_early_param+0x89/0x89
  [<ffffffff8163eab0>] ? gs_change+0xb/0xb

---
 drivers/pci/intel-iommu.c |    5 +++++
 1 file changed, 5 insertions(+)

--- linux.orig/drivers/pci/intel-iommu.c
+++ linux/drivers/pci/intel-iommu.c
@@ -47,6 +47,8 @@
 #define ROOT_SIZE		VTD_PAGE_SIZE
 #define CONTEXT_SIZE		VTD_PAGE_SIZE
 
+#define IS_BRIDGE_HOST_DEVICE(pdev) \
+			    ((pdev->class >> 8) == PCI_CLASS_BRIDGE_HOST)
 #define IS_GFX_DEVICE(pdev) ((pdev->class >> 16) == PCI_BASE_CLASS_DISPLAY)
 #define IS_ISA_DEVICE(pdev) ((pdev->class >> 8) == PCI_CLASS_BRIDGE_ISA)
 #define IS_AZALIA(pdev) ((pdev)->vendor == 0x8086 && (pdev)->device == 0x3a3e)
@@ -2214,6 +2216,9 @@ static int __init iommu_prepare_static_i
 		return -EFAULT;
 
 	for_each_pci_dev(pdev) {
+		/* Skip Host/PCI Bridge devices */
+		if (IS_BRIDGE_HOST_DEVICE(pdev))
+			continue;
 		if (iommu_should_identity_map(pdev, 1)) {
 			printk(KERN_INFO "IOMMU: %s identity mapping for device %s\n",
 			       hw ? "hardware" : "software", pci_name(pdev));

-- 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 6/7] Intel pci: Add domain check in domain_remove_one_dev_info
  2011-05-27  1:32 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
                   ` (4 preceding siblings ...)
  2011-05-27  1:32 ` [PATCH 5/7] Intel pci: Remove Host Bridge devices from identity mapping Mike Travis
@ 2011-05-27  1:32 ` Mike Travis
  2011-05-27  1:32 ` [PATCH 7/7] Intel pci: Indicate 64-bit IOMMU passthrough available Mike Travis
  6 siblings, 0 replies; 17+ messages in thread
From: Mike Travis @ 2011-05-27  1:32 UTC (permalink / raw)
  To: David Woodhouse, Chris Wright, Andrew Morton, Ingo Molnar
  Cc: Mike Habeck, Jesse Barnes, stable, iommu, linux-pci, linux-kernel

[-- Attachment #1: fix-domain_remove_one_dev_info.patch --]
[-- Type: text/plain, Size: 1136 bytes --]

	The comment in domain_remove_one_dev_info() states "No need
	to compare PCI domain; it has to be the same".	But for the
	si_domain that isn't going to be true, as it consists of all the
	PCI devices that are identity mapped thus multiple PCI domains can
	be in si_domain.  The code needs to validate the PCI domain too.

From: Mike Habeck <habeck@sgi.com>
Signed-off-by: Mike Habeck <habeck@sgi.com>
Signed-off-by: Mike Travis <travis@sgi.com>
---
 drivers/pci/intel-iommu.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux.orig/drivers/pci/intel-iommu.c
+++ linux/drivers/pci/intel-iommu.c
@@ -3395,8 +3395,8 @@ static void domain_remove_one_dev_info(s
 	spin_lock_irqsave(&device_domain_lock, flags);
 	list_for_each_safe(entry, tmp, &domain->devices) {
 		info = list_entry(entry, struct device_domain_info, link);
-		/* No need to compare PCI domain; it has to be the same */
-		if (info->bus == pdev->bus->number &&
+		if (info->segment == pci_domain_nr(pdev->bus) &&
+		    info->bus == pdev->bus->number &&
 		    info->devfn == pdev->devfn) {
 			list_del(&info->link);
 			list_del(&info->global);

-- 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 7/7] Intel pci: Indicate 64-bit IOMMU passthrough available
  2011-05-27  1:32 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
                   ` (5 preceding siblings ...)
  2011-05-27  1:32 ` [PATCH 6/7] Intel pci: Add domain check in domain_remove_one_dev_info Mike Travis
@ 2011-05-27  1:32 ` Mike Travis
  2011-05-27 15:01   ` David Woodhouse
  6 siblings, 1 reply; 17+ messages in thread
From: Mike Travis @ 2011-05-27  1:32 UTC (permalink / raw)
  To: David Woodhouse, Chris Wright, Andrew Morton, Ingo Molnar
  Cc: Mike Habeck, Jesse Barnes, stable, iommu, linux-pci,
	linux-kernel, Dimitri Sivanich

[-- Attachment #1: indicate-iommu-fixed.patch --]
[-- Type: text/plain, Size: 1195 bytes --]

    Prior to these IOMMU patches, the passthrough option
    could not be used because it would cause the kernel to
    panic.  Provide an indication that a kernel is capable
    of handling passthrough mode through the introduction
    of a specific variable name.  This allows automatic
    configuration utilities to set the "iommu=pt" kernel
    cmdline option safely.

Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Dimitri Sivanich <sivanich@sgi.com>
---
 drivers/pci/intel-iommu.c |    4 ++++
 1 file changed, 4 insertions(+)

--- linux.orig/drivers/pci/intel-iommu.c
+++ linux/drivers/pci/intel-iommu.c
@@ -390,6 +390,9 @@ static int dmar_map_gfx = 1;
 static int dmar_forcedac;
 static int intel_iommu_strict;
 
+/* specifically named variable that indicates "iommu=pt" is available */
+static int __initdata intel_iommu_64bit_pt;
+
 #define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
 static DEFINE_SPINLOCK(device_domain_lock);
 static LIST_HEAD(device_domain_list);
@@ -425,6 +428,7 @@ static int __init intel_iommu_setup(char
 		while (*str == ',')
 			str++;
 	}
+	intel_iommu_64bit_pt = 1;
 	return 0;
 }
 __setup("intel_iommu=", intel_iommu_setup);

-- 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [stable] [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask
  2011-05-27  1:32 ` [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask Mike Travis
@ 2011-05-27  7:18   ` Greg KH
  2011-05-27  9:30     ` Ingo Molnar
  0 siblings, 1 reply; 17+ messages in thread
From: Greg KH @ 2011-05-27  7:18 UTC (permalink / raw)
  To: Mike Travis
  Cc: David Woodhouse, Chris Wright, Andrew Morton, Ingo Molnar,
	linux-pci, linux-kernel, Jesse Barnes, iommu, Mike Habeck,
	stable

On Thu, May 26, 2011 at 08:32:22PM -0500, Mike Travis wrote:
> 	The identity mapping code appears to make the assumption that
> 	if the devices dma_mask is greater than 32bits the device can
> 	use identity mapping.  But that is not true, take the case 
> 	where we have a 40bit device in a 44bit architecture.  The
> 	device can potentially receive a physical address that it
> 	will truncate and cause incorrect addresses to be used.
> 
> 	Instead check to see if the device's dma_mask is large enough
> 	to address the system's dma_mask.
> 
> From: Chris Wright <chrisw@sous-sol.org>
> Signed-off-by: Mike Travis <travis@sgi.com>
> Reviewed-by: Mike Habeck <habeck@sgi.com>
> ---
>  drivers/pci/intel-iommu.c |   15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

</formletter>

I'll not send this out for the other 6 patches that also do not follow
the proper format, as I'm sure you would get bored reading them.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [stable] [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask
  2011-05-27  7:18   ` [stable] " Greg KH
@ 2011-05-27  9:30     ` Ingo Molnar
  2011-05-27  9:42       ` Joerg Roedel
  0 siblings, 1 reply; 17+ messages in thread
From: Ingo Molnar @ 2011-05-27  9:30 UTC (permalink / raw)
  To: Greg KH
  Cc: Mike Travis, David Woodhouse, Chris Wright, Andrew Morton,
	linux-pci, linux-kernel, Jesse Barnes, iommu, Mike Habeck,
	stable


* Greg KH <greg@kroah.com> wrote:

> <formletter>
> 
> This is not the correct way to submit patches for inclusion in the 
> stable kernel tree.  Please read 
> Documentation/stable_kernel_rules.txt for how to do this properly.
> 
> </formletter>
> 
> I'll not send this out for the other 6 patches that also do not 
> follow the proper format, as I'm sure you would get bored reading 
> them.

None of these patches exist upstream yet so it will take some time 
until any of this can touch -stable. You can ignore it safely for 
now.

Mike: please add proposed stable Cc: tags in the patch only, never 
send it out to the stable email address itself!!

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [stable] [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask
  2011-05-27  9:30     ` Ingo Molnar
@ 2011-05-27  9:42       ` Joerg Roedel
  2011-05-27  9:59         ` Greg KH
  0 siblings, 1 reply; 17+ messages in thread
From: Joerg Roedel @ 2011-05-27  9:42 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Greg KH, linux-pci, linux-kernel, Jesse Barnes, Mike Travis,
	Chris Wright, iommu, Mike Habeck, Andrew Morton, David Woodhouse,
	stable

On Fri, May 27, 2011 at 05:30:42AM -0400, Ingo Molnar wrote:
> 
> * Greg KH <greg@kroah.com> wrote:
> 
> > <formletter>
> > 
> > This is not the correct way to submit patches for inclusion in the 
> > stable kernel tree.  Please read 
> > Documentation/stable_kernel_rules.txt for how to do this properly.
> > 
> > </formletter>
> > 
> > I'll not send this out for the other 6 patches that also do not 
> > follow the proper format, as I'm sure you would get bored reading 
> > them.
> 
> None of these patches exist upstream yet so it will take some time 
> until any of this can touch -stable. You can ignore it safely for 
> now.
> 
> Mike: please add proposed stable Cc: tags in the patch only, never 
> send it out to the stable email address itself!!

Well, with the Cc: tag git-send-email will Cc it automatically if not
done by the user explicitly.

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [stable] [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask
  2011-05-27  9:42       ` Joerg Roedel
@ 2011-05-27  9:59         ` Greg KH
  0 siblings, 0 replies; 17+ messages in thread
From: Greg KH @ 2011-05-27  9:59 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Ingo Molnar, linux-pci, linux-kernel, Jesse Barnes, Mike Travis,
	Chris Wright, iommu, Mike Habeck, Andrew Morton, David Woodhouse,
	stable

On Fri, May 27, 2011 at 11:42:09AM +0200, Joerg Roedel wrote:
> On Fri, May 27, 2011 at 05:30:42AM -0400, Ingo Molnar wrote:
> > 
> > * Greg KH <greg@kroah.com> wrote:
> > 
> > > <formletter>
> > > 
> > > This is not the correct way to submit patches for inclusion in the 
> > > stable kernel tree.  Please read 
> > > Documentation/stable_kernel_rules.txt for how to do this properly.
> > > 
> > > </formletter>
> > > 
> > > I'll not send this out for the other 6 patches that also do not 
> > > follow the proper format, as I'm sure you would get bored reading 
> > > them.
> > 
> > None of these patches exist upstream yet so it will take some time 
> > until any of this can touch -stable. You can ignore it safely for 
> > now.
> > 
> > Mike: please add proposed stable Cc: tags in the patch only, never 
> > send it out to the stable email address itself!!
> 
> Well, with the Cc: tag git-send-email will Cc it automatically if not
> done by the user explicitly.

And that's fine, I don't object to that at all, and it makes life easier
for me as I know it is coming eventually, and I try to watch out for it
in case the subsystem maintainer forgets to apply it.

It's when the Cc: in the signed-off-area is not there that my
form-letter kicks in to advise people that they are doing something
wrong and that their patch will not get applied to the stable tree this
way.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 7/7] Intel pci: Indicate 64-bit IOMMU passthrough available
  2011-05-27  1:32 ` [PATCH 7/7] Intel pci: Indicate 64-bit IOMMU passthrough available Mike Travis
@ 2011-05-27 15:01   ` David Woodhouse
  0 siblings, 0 replies; 17+ messages in thread
From: David Woodhouse @ 2011-05-27 15:01 UTC (permalink / raw)
  To: Mike Travis
  Cc: Chris Wright, Andrew Morton, Ingo Molnar, Mike Habeck,
	Jesse Barnes, stable, iommu, linux-pci, linux-kernel,
	Dimitri Sivanich

On Thu, 2011-05-26 at 20:32 -0500, Mike Travis wrote:
>     Prior to these IOMMU patches, the passthrough option
>     could not be used because it would cause the kernel to
>     panic. 

Could not be used on certain hardware? In certain configurations? It
wasn't just *completely* broken (unless it got broken in a recent
regression).

>  Provide an indication that a kernel is capable
>     of handling passthrough mode through the introduction
>     of a specific variable name.  This allows automatic
>     configuration utilities to set the "iommu=pt" kernel
>     cmdline option safely. 

That implies that there is a follow-up patch to somehow export this
information to userspace? Where the information in question is just the
fact that a certain set of bugs have been fixed?

Since these *are* actually bugs, and not new features, I take it we're
looking at merging them for 2.6.40? I was planning to ask Linus to pull
my tree today, and I'm not entirely happy with merging them at the last
minute.

So I'll plan to merge them into my tree after the outstanding merge, and
then perhaps ask Linus to take them *after* -rc1? Since they're actually
bug fixes, I suspect that's the best way to proceed?

-- 
dwmw2


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code
  2011-05-29  0:12 ` David Woodhouse
  2011-05-30 20:57   ` Mike Travis
@ 2011-06-03 14:03   ` David Woodhouse
  1 sibling, 0 replies; 17+ messages in thread
From: David Woodhouse @ 2011-06-03 14:03 UTC (permalink / raw)
  To: Mike Travis
  Cc: Dimitri Sivanich, Derek Fults, linux-pci, linux-kernel,
	Jesse Barnes, stable, Chris Wright, iommu, Mike Habeck,
	Andrew Morton, Ingo Molnar

On Sun, 2011-05-29 at 01:12 +0100, David Woodhouse wrote:
> Patches 1-6 applied to iommu-2.6.git. Please test. Thanks.

This is all now in Linus' tree for 3.0-rc2, and since you included
'Cc: stable' in the commit comments it should magically turn up in a
stable tree near you.

I will leave you to deal with the question of how to mark 'old' kernels
as actually having had later bugs fixed.

-- 
dwmw2





^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code
  2011-05-29  0:12 ` David Woodhouse
@ 2011-05-30 20:57   ` Mike Travis
  2011-06-03 14:03   ` David Woodhouse
  1 sibling, 0 replies; 17+ messages in thread
From: Mike Travis @ 2011-05-30 20:57 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Chris Wright, Andrew Morton, Ingo Molnar, Mike Habeck,
	Dimitri Sivanich, Derek Fults, Jesse Barnes, stable, iommu,
	linux-pci, linux-kernel



On 05/28/2011 05:12 PM, David Woodhouse wrote:
> On Sat, 2011-05-28 at 13:15 -0500, Mike Travis wrote:
>> 	Various problems exist in the Intel IOMMU PCI driver when
>> 	using DMA remapping in 1:1 identity mode on UV systems and
>> 	devices cannot address all of physical memory.
>>
>> 	This patchset addresses those problems.
>
> Patches 1-6 applied to iommu-2.6.git. Please test. Thanks.
>
> Please note for future reference that 'From:' lines such as the one in
> your patch 1/7 should be *first* in the body of your email. The git-am
> tool doesn't find them and set the authorship if you put them with the
> Signed-off-bys. Also please avoid putting whitespace at the beginning of
> every line of your commit comments.
>
> I still hate patch 7, but the point was that I wouldn't have to care
> about it. Once your patches 1-6 are included in known stable releases
> that your SCU can recognise, it can just pass 'iommu=pt' for those.
>
> It's only the "probably buggy" kernels with older release numbers that
> you'll pass 'forcedac,pt64' to, so your mission is to get patch 7 or
> some variant of it accepted into *those* kernels.
>

Thanks David, all noted.  The From: thing is swallowed by the
quilt mail command if it's first.  I'll see if I can't fix that.

Cheers.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code
  2011-05-28 18:15 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
@ 2011-05-29  0:12 ` David Woodhouse
  2011-05-30 20:57   ` Mike Travis
  2011-06-03 14:03   ` David Woodhouse
  0 siblings, 2 replies; 17+ messages in thread
From: David Woodhouse @ 2011-05-29  0:12 UTC (permalink / raw)
  To: Mike Travis
  Cc: Chris Wright, Andrew Morton, Ingo Molnar, Mike Habeck,
	Dimitri Sivanich, Derek Fults, Jesse Barnes, stable, iommu,
	linux-pci, linux-kernel

On Sat, 2011-05-28 at 13:15 -0500, Mike Travis wrote:
> 	Various problems exist in the Intel IOMMU PCI driver when
> 	using DMA remapping in 1:1 identity mode on UV systems and
> 	devices cannot address all of physical memory.
> 
> 	This patchset addresses those problems.

Patches 1-6 applied to iommu-2.6.git. Please test. Thanks.

Please note for future reference that 'From:' lines such as the one in
your patch 1/7 should be *first* in the body of your email. The git-am
tool doesn't find them and set the authorship if you put them with the
Signed-off-bys. Also please avoid putting whitespace at the beginning of
every line of your commit comments.

I still hate patch 7, but the point was that I wouldn't have to care
about it. Once your patches 1-6 are included in known stable releases
that your SCU can recognise, it can just pass 'iommu=pt' for those.

It's only the "probably buggy" kernels with older release numbers that
you'll pass 'forcedac,pt64' to, so your mission is to get patch 7 or
some variant of it accepted into *those* kernels.

-- 
dwmw2


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code
@ 2011-05-28 18:15 Mike Travis
  2011-05-29  0:12 ` David Woodhouse
  0 siblings, 1 reply; 17+ messages in thread
From: Mike Travis @ 2011-05-28 18:15 UTC (permalink / raw)
  To: David Woodhouse, Chris Wright, Andrew Morton, Ingo Molnar
  Cc: Mike Habeck, Dimitri Sivanich, Derek Fults, Jesse Barnes, stable,
	iommu, linux-pci, linux-kernel


	Various problems exist in the Intel IOMMU PCI driver when
	using DMA remapping in 1:1 identity mode on UV systems and
	devices cannot address all of physical memory.

	This patchset addresses those problems.

-- 

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2011-06-03 14:04 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-27  1:32 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
2011-05-27  1:32 ` [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask Mike Travis
2011-05-27  7:18   ` [stable] " Greg KH
2011-05-27  9:30     ` Ingo Molnar
2011-05-27  9:42       ` Joerg Roedel
2011-05-27  9:59         ` Greg KH
2011-05-27  1:32 ` [PATCH 2/7] Intel pci: Speed up processing of the identity_mapping function Mike Travis
2011-05-27  1:32 ` [PATCH 3/7] Intel pci: Dont cache iova above 32bit Mike Travis
2011-05-27  1:32 ` [PATCH 4/7] Intel pci: Use coherent DMA mask when requested Mike Travis
2011-05-27  1:32 ` [PATCH 5/7] Intel pci: Remove Host Bridge devices from identity mapping Mike Travis
2011-05-27  1:32 ` [PATCH 6/7] Intel pci: Add domain check in domain_remove_one_dev_info Mike Travis
2011-05-27  1:32 ` [PATCH 7/7] Intel pci: Indicate 64-bit IOMMU passthrough available Mike Travis
2011-05-27 15:01   ` David Woodhouse
2011-05-28 18:15 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
2011-05-29  0:12 ` David Woodhouse
2011-05-30 20:57   ` Mike Travis
2011-06-03 14:03   ` David Woodhouse

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.