All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] fix iommu interrupt setup
@ 2009-02-12  2:59 Kouya Shimura
  2009-02-12  8:42 ` Keir Fraser
  2009-02-12 22:17 ` Kay, Allen M
  0 siblings, 2 replies; 14+ messages in thread
From: Kouya Shimura @ 2009-02-12  2:59 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 496 bytes --]

iommu is disabled since cset 19175:ab514cfbcdc5 with the following message:

(XEN) [VT-D]iommu.c:890:d32767 IOMMU: can't request irq
(XEN) [VT-D]iommu.c:1686:d32767 IOMMU: interrupt setup failed
(XEN) I/O virtualisation disabled

This patch fixes it.
- rename request_irq to request_vector, no conversion by irq_to_vector(irq)
- set vector_to_iommu[vector] before calling request_vector
  since null pointer exceptions occurs
- some cleanups

Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>


[-- Attachment #2: fix_cset19175.patch --]
[-- Type: text/x-patch, Size: 5614 bytes --]

diff -r bf9cdbec516a xen/arch/ia64/linux-xen/irq_ia64.c
--- a/xen/arch/ia64/linux-xen/irq_ia64.c	Wed Feb 11 16:36:59 2009 +0000
+++ b/xen/arch/ia64/linux-xen/irq_ia64.c	Thu Feb 12 11:01:54 2009 +0900
@@ -267,7 +267,7 @@ register_percpu_irq (ia64_vector vec, st
 }
 
 #ifdef XEN
-int request_irq(unsigned int irq,
+int request_vector(unsigned int vector,
 		void (*handler)(int, void *, struct cpu_user_regs *),
 		unsigned long irqflags, const char * devname, void *dev_id)
 {
@@ -279,7 +279,7 @@ int request_irq(unsigned int irq,
 	 * otherwise we'll have trouble later trying to figure out
 	 * which interrupt is which (messes up the interrupt freeing logic etc).
 	 *                          */
-	if (irq >= NR_IRQS)
+	if (vector >= NR_VECTORS)
 		return -EINVAL;
 	if (!handler)
 		return -EINVAL;
@@ -291,7 +291,7 @@ int request_irq(unsigned int irq,
 	action->handler = handler;
 	action->name = devname;
 	action->dev_id = dev_id;
-	setup_vector(irq, action);
+	setup_vector(vector, action);
 	if (retval)
 		xfree(action);
 
diff -r bf9cdbec516a xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c	Wed Feb 11 16:36:59 2009 +0000
+++ b/xen/arch/x86/irq.c	Thu Feb 12 11:01:54 2009 +0900
@@ -33,6 +33,7 @@ int vector_irq[NR_VECTORS] __read_mostly
 };
 
 static void __do_IRQ_guest(int vector);
+static int setup_vector(unsigned int vector, struct irqaction *new);
 
 void no_action(int cpl, void *dev_id, struct cpu_user_regs *regs) { }
 
@@ -159,7 +160,7 @@ asmlinkage void do_IRQ(struct cpu_user_r
     spin_unlock(&desc->lock);
 }
 
-int request_irq(unsigned int irq,
+int request_vector(unsigned int vector,
         void (*handler)(int, void *, struct cpu_user_regs *),
         unsigned long irqflags, const char * devname, void *dev_id)
 {
@@ -172,7 +173,7 @@ int request_irq(unsigned int irq,
      * which interrupt is which (messes up the interrupt freeing
      * logic etc).
      */
-    if (irq >= NR_IRQS)
+    if (vector >= NR_VECTORS)
         return -EINVAL;
     if (!handler)
         return -EINVAL;
@@ -185,7 +186,7 @@ int request_irq(unsigned int irq,
     action->name = devname;
     action->dev_id = dev_id;
 
-    retval = setup_irq(irq, action);
+    retval = setup_vector(vector, action);
     if (retval)
         xfree(action);
 
@@ -209,9 +210,8 @@ void free_irq(unsigned int irq)
     do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
 }
 
-int setup_irq(unsigned int irq, struct irqaction *new)
+static int setup_vector(unsigned int vector, struct irqaction *new)
 {
-    unsigned int  vector = irq_to_vector(irq);
     irq_desc_t   *desc = &irq_desc[vector];
     unsigned long flags;
  
@@ -231,6 +231,11 @@ int setup_irq(unsigned int irq, struct i
     spin_unlock_irqrestore(&desc->lock,flags);
 
     return 0;
+}
+
+int setup_irq(unsigned int irq, struct irqaction *new)
+{
+    return setup_vector(irq_to_vector(irq), new);
 }
 
 
diff -r bf9cdbec516a xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Feb 11 16:36:59 2009 +0000
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Feb 12 11:01:54 2009 +0900
@@ -487,10 +487,12 @@ static int set_iommu_interrupt_handler(s
     }
 
     irq_desc[vector].handler = &iommu_msi_type;
-    ret = request_irq(vector, amd_iommu_page_fault, 0, "amd_iommu", iommu);
+    vector_to_iommu[vector] = iommu;
+    ret = request_vector(vector, amd_iommu_page_fault, 0, "amd_iommu", iommu);
     if ( ret )
     {
         irq_desc[vector].handler = &no_irq_type;
+        vector_to_iommu[vector] = NULL;
         free_irq_vector(vector);
         amd_iov_error("can't request irq\n");
         return 0;
@@ -498,7 +500,6 @@ static int set_iommu_interrupt_handler(s
 
     /* Make sure that vector is never re-used. */
     vector_irq[vector] = NEVER_ASSIGN;
-    vector_to_iommu[vector] = iommu;
     iommu->vector = vector;
     return vector;
 }
diff -r bf9cdbec516a xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c	Wed Feb 11 16:36:59 2009 +0000
+++ b/xen/drivers/passthrough/vtd/iommu.c	Thu Feb 12 11:01:54 2009 +0900
@@ -870,7 +870,7 @@ static struct hw_interrupt_type dma_msi_
     .set_affinity = dma_msi_set_affinity,
 };
 
-int iommu_set_interrupt(struct iommu *iommu)
+static int iommu_set_interrupt(struct iommu *iommu)
 {
     int vector, ret;
 
@@ -882,10 +882,12 @@ int iommu_set_interrupt(struct iommu *io
     }
 
     irq_desc[vector].handler = &dma_msi_type;
-    ret = request_irq(vector, iommu_page_fault, 0, "dmar", iommu);
+    vector_to_iommu[vector] = iommu;
+    ret = request_vector(vector, iommu_page_fault, 0, "dmar", iommu);
     if ( ret )
     {
         irq_desc[vector].handler = &no_irq_type;
+        vector_to_iommu[vector] = NULL;
         free_irq_vector(vector);
         gdprintk(XENLOG_ERR VTDPREFIX, "IOMMU: can't request irq\n");
         return ret;
@@ -893,7 +895,6 @@ int iommu_set_interrupt(struct iommu *io
 
     /* Make sure that vector is never re-used. */
     vector_irq[vector] = NEVER_ASSIGN;
-    vector_to_iommu[vector] = iommu;
 
     return vector;
 }
diff -r bf9cdbec516a xen/include/xen/irq.h
--- a/xen/include/xen/irq.h	Wed Feb 11 16:36:59 2009 +0000
+++ b/xen/include/xen/irq.h	Thu Feb 12 11:01:54 2009 +0900
@@ -66,7 +66,7 @@ extern irq_desc_t irq_desc[NR_VECTORS];
 
 extern int setup_irq(unsigned int, struct irqaction *);
 extern void free_irq(unsigned int);
-extern int request_irq(unsigned int irq,
+extern int request_vector(unsigned int irq,
                void (*handler)(int, void *, struct cpu_user_regs *),
                unsigned long irqflags, const char * devname, void *dev_id);
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

* Re: [PATCH] fix iommu interrupt setup
  2009-02-12  2:59 [PATCH] fix iommu interrupt setup Kouya Shimura
@ 2009-02-12  8:42 ` Keir Fraser
  2009-02-12 22:17 ` Kay, Allen M
  1 sibling, 0 replies; 14+ messages in thread
From: Keir Fraser @ 2009-02-12  8:42 UTC (permalink / raw)
  To: Kouya Shimura, xen-devel

Espen and Isaku have a patch now which should hopefully also fix this issue.
I'll be checking theirs in shortly.

 Thanks,
 Keir

On 12/02/2009 02:59, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote:

> iommu is disabled since cset 19175:ab514cfbcdc5 with the following message:
> 
> (XEN) [VT-D]iommu.c:890:d32767 IOMMU: can't request irq
> (XEN) [VT-D]iommu.c:1686:d32767 IOMMU: interrupt setup failed
> (XEN) I/O virtualisation disabled
> 
> This patch fixes it.
> - rename request_irq to request_vector, no conversion by irq_to_vector(irq)
> - set vector_to_iommu[vector] before calling request_vector
>   since null pointer exceptions occurs
> - some cleanups
> 
> Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>

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

* RE: [PATCH] fix iommu interrupt setup
  2009-02-12  2:59 [PATCH] fix iommu interrupt setup Kouya Shimura
  2009-02-12  8:42 ` Keir Fraser
@ 2009-02-12 22:17 ` Kay, Allen M
  2009-02-12 22:56   ` Alexia Benington
                     ` (2 more replies)
  1 sibling, 3 replies; 14+ messages in thread
From: Kay, Allen M @ 2009-02-12 22:17 UTC (permalink / raw)
  To: Kouya Shimura, xen-devel

Interrupt handling cleanup in changeset 19195 is causing following failure on my system:

(XEN) ----[ Xen-3.4-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff828c8011b591>] check_lock+0x19/0x4e
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: 0000000000000040   rcx: 0000000000000001
(XEN) rdx: 0000000000000082   rsi: 0000000000000001   rdi: 0000000000000044
(XEN) rbp: ffff828c80277c58   rsp: ffff828c80277c58   r8:  0000000000000005
(XEN) r9:  0000000000000001   r10: 0000000000000001   r11: 0000000000000000
(XEN) r12: 0000000000000082   r13: 0000000000000282   r14: 0000000000000090
(XEN) r15: ffff83007f2c4160   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000007f47c000   cr2: 0000000000000044
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff828c80277c58:
(XEN)    ffff828c80277c78 ffff828c8011b70c 0000000000000000 0000000000000040
(XEN)    ffff828c80277c98 ffff828c8012df24 ffff828c802a1c00 ffff828c802a1c24
(XEN)    ffff828c80277ca8 ffff828c8012df83 ffff828c80277ce8 ffff828c80147cc0
(XEN)    ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e639
(XEN)    ffff828c801e2191 ffff83007f4d9df0 ffff828c80277d28 ffff828c801481fa
(XEN)    ffff83007f2c4160 0000000000000090 ffff83007f4d9df0 0000000000004800
(XEN)    ffff83007f4d9df0 ffff828c8029d400 ffff828c80277d68 ffff828c8012e2f0
(XEN)    ffff828c80277d48 0000000000000000 ffff83007f4d9df0 0000000000000282
(XEN)    ffff83007f6df130 0000000000100000 ffff828c80277d98 ffff828c8012e4a2
(XEN)    0000000000000000 ffff83007f4d9df0 ffff828c8020b8b0 0000000000000020
(XEN)    ffff828c80277de8 ffff828c8012fb38 ffff828c80277dd8 ffff828c8012a183
(XEN)    0000000000000004 00010001802093c0 0001000100010001 00000000ffffffed
(XEN)    ffff828c8022ec08 0000000000000017 ffff828c80277e08 ffff828c8012be18
(XEN)    ffff828c80277e08 ffff828c8022eaf8 ffff828c80277f18 ffff828c80222ca8
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffff828c8020e675
(XEN)    ffffffffc0270000 ffff83007f47cff8 ffff83007f47dff8 000000000020e610
(XEN)    000000000008bf60 0000000000000000 0000000000000000 0000000000000000
(XEN)    ffff83000008bfc0 ffff83000008bf60 0000000000b0c800 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000800000000 000000010000006e
(XEN) Xen call trace:
(XEN)    [<ffff828c8011b591>] check_lock+0x19/0x4e
(XEN)    [<ffff828c8011b70c>] _spin_lock_irqsave+0x21/0x3f
(XEN)    [<ffff828c8012df24>] dma_msi_unmask+0x2a/0x4b
(XEN)    [<ffff828c8012df83>] dma_msi_startup+0x9/0x10
(XEN)    [<ffff828c80147cc0>] setup_irq_vector+0x73/0x99
(XEN)    [<ffff828c801481fa>] request_irq_vector+0x6c/0x9a
(XEN)    [<ffff828c8012e2f0>] iommu_set_interrupt+0x97/0x10f
(XEN)    [<ffff828c8012e4a2>] init_vtd_hw+0x13a/0x2d1
(XEN)    [<ffff828c8012fb38>] intel_vtd_setup+0x332/0x4bd
(XEN)    [<ffff828c8012be18>] iommu_setup+0x2d/0xf5
(XEN)    [<ffff828c80222ca8>] __start_xen+0x457d/0x4895
(XEN)    
(XEN) Pagetable walk from 0000000000000044:
(XEN)  L4[0x000] = 000000007f706063 5555555555555555
(XEN)  L3[0x000] = 000000007e6f1063 5555555555555555
(XEN)  L2[0x000] = 000000007e6f0063 5555555555555555 
(XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
(XEN) 
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 0000000000000044
(XEN) ****************************************
(XEN) 
(XEN) Reboot in five seconds...

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Kouya Shimura
Sent: Wednesday, February 11, 2009 7:00 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] fix iommu interrupt setup

iommu is disabled since cset 19175:ab514cfbcdc5 with the following message:

(XEN) [VT-D]iommu.c:890:d32767 IOMMU: can't request irq
(XEN) [VT-D]iommu.c:1686:d32767 IOMMU: interrupt setup failed
(XEN) I/O virtualisation disabled

This patch fixes it.
- rename request_irq to request_vector, no conversion by irq_to_vector(irq)
- set vector_to_iommu[vector] before calling request_vector
  since null pointer exceptions occurs
- some cleanups

Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>

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

* Re: [PATCH] fix iommu interrupt setup
  2009-02-12 22:17 ` Kay, Allen M
@ 2009-02-12 22:56   ` Alexia Benington
  2009-02-13  0:57     ` Jiang, Yunhong
  2009-02-13  1:46   ` kouya
  2009-02-13  8:48   ` Keir Fraser
  2 siblings, 1 reply; 14+ messages in thread
From: Alexia Benington @ 2009-02-12 22:56 UTC (permalink / raw)
  To: xen-devel

I'm getting the same bug.
-Alex

(XEN) ----[ Xen-3.4-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff828c8011b62f>] check_lock+0x19/0x4e
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: 0000000000000040   rcx: 0000000000000001
(XEN) rdx: 0000000000000082   rsi: 0000000000000001   rdi: 0000000000000044
(XEN) rbp: ffff828c80277c58   rsp: ffff828c80277c58   r8:  0000000000000005
(XEN) r9:  0000000000000001   r10: 0000000000000001   r11: ffff828c8028e360
(XEN) r12: 0000000000000082   r13: 0000000000000282   r14: 0000000000000090
(XEN) r15: ffff83013bfba430   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 00000000bd47c000   cr2: 0000000000000044
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff828c80277c58:
(XEN)    ffff828c80277c78 ffff828c8011b7aa 0000000000000000 0000000000000040
(XEN)    ffff828c80277c98 ffff828c8012e223 ffff828c802a1c00 ffff828c802a1c24
(XEN)    ffff828c80277ca8 ffff828c8012e282 ffff828c80277ce8 ffff828c80147e90
(XEN)    ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e938
(XEN)    ffff828c801e31cd ffff83013bff1f90 ffff828c80277d28 ffff828c801483be
(XEN)    ffff83013bfba430 0000000000000090 ffff83013bff1f90 0000000000004800
(XEN)    ffff83013bff1f90 ffff828c8029d400 ffff828c80277d68 ffff828c8012e5ef
(XEN)    ffff828c80277d48 0000000000000003 ffff83013bff1f90 0000000000000282
(XEN)    ffff83013bff16f0 0000000000100000 ffff828c80277d98 ffff828c8012e7a1
(XEN)    0000000000000003 ffff83013bfba330 ffff828c8020c930 0000000000000020
(XEN)    ffff828c80277de8 ffff828c8012fe48 ffff828c80277dd8 ffff828c8012a2e9
(XEN)    0000000000000002 000100018020a4c0 0001000100010001 00000000ffffffed
(XEN)    ffff828c8022fc08 0000000000000003 ffff828c80277e08 ffff828c8012c008
(XEN)    ffff828c80277e08 ffff828c8022faf8 ffff828c80277f18 ffff828c80223d09
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffff828c8020f665
(XEN)    ffffffffc0270000 ffff8300bd47cff8 ffff8300bd47dff8 000000000008bf50
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffff83000008bfc0
(XEN)    ffff83000008bf50 0000000000cc3c00 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000800000000 000000010000006e
(XEN) Xen call trace:
(XEN)    [<ffff828c8011b62f>] check_lock+0x19/0x4e
(XEN)    [<ffff828c8011b7aa>] _spin_lock_irqsave+0x21/0x3f
(XEN)    [<ffff828c8012e223>] dma_msi_unmask+0x2a/0x4b
(XEN)    [<ffff828c8012e282>] dma_msi_startup+0x9/0x10
(XEN)    [<ffff828c80147e90>] setup_irq_vector+0x73/0x99
(XEN)    [<ffff828c801483be>] request_irq_vector+0x6c/0x9a
(XEN)    [<ffff828c8012e5ef>] iommu_set_interrupt+0x97/0x10f
(XEN)    [<ffff828c8012e7a1>] init_vtd_hw+0x13a/0x2d1
(XEN)    [<ffff828c8012fe48>] intel_vtd_setup+0x330/0x4bb
(XEN)    [<ffff828c8012c008>] iommu_setup+0x2d/0xf5
(XEN)    [<ffff828c80223d09>] __start_xen+0x463f/0x4956
(XEN)
(XEN) Pagetable walk from 0000000000000044:
(XEN)  L4[0x000] = 000000013bff0063 5555555555555555
(XEN)  L3[0x000] = 000000013bfef063 5555555555555555
(XEN)  L2[0x000] = 000000013bfee063 5555555555555555
(XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 0000000000000044
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

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

* RE: [PATCH] fix iommu interrupt setup
  2009-02-12 22:56   ` Alexia Benington
@ 2009-02-13  0:57     ` Jiang, Yunhong
  2009-02-13  1:00       ` Jiang, Yunhong
  0 siblings, 1 reply; 14+ messages in thread
From: Jiang, Yunhong @ 2009-02-13  0:57 UTC (permalink / raw)
  To: Alexia Benington, xen-devel

Allen, this is because the register_lock is not always called with irq disabled. Seems it is called with spin_lock(), instead of spin_lock_irqsave() in queue_invalidate_wait(). 

But I'm a bit curios why intel_vtd_setup() will be called after queue_invalidate_wait(). 

Thanks
Yunhong Jiang

xen-devel-bounces@lists.xensource.com <> wrote:
> I'm getting the same bug.
> -Alex
> 
> (XEN) ----[ Xen-3.4-unstable  x86_64  debug=y  Not tainted ]---- (XEN) CPU:
> 0 (XEN) RIP:    e008:[<ffff828c8011b62f>] check_lock+0x19/0x4e
> (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
> (XEN) rax: 0000000000000001   rbx: 0000000000000040   rcx: 0000000000000001
> (XEN) rdx: 0000000000000082   rsi: 0000000000000001   rdi: 0000000000000044
> (XEN) rbp: ffff828c80277c58   rsp: ffff828c80277c58   r8: 0000000000000005
> (XEN) r9:  0000000000000001   r10: 0000000000000001   r11: ffff828c8028e360
> (XEN) r12: 0000000000000082   r13: 0000000000000282   r14: 0000000000000090
> (XEN) r15: ffff83013bfba430   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 00000000bd47c000   cr2: 0000000000000044
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen stack trace from rsp=ffff828c80277c58:
> (XEN)    ffff828c80277c78 ffff828c8011b7aa 0000000000000000 0000000000000040
> (XEN)    ffff828c80277c98 ffff828c8012e223 ffff828c802a1c00 ffff828c802a1c24
> (XEN)    ffff828c80277ca8 ffff828c8012e282 ffff828c80277ce8 ffff828c80147e90
> (XEN)    ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e938
> (XEN)    ffff828c801e31cd ffff83013bff1f90 ffff828c80277d28 ffff828c801483be
> (XEN)    ffff83013bfba430 0000000000000090 ffff83013bff1f90 0000000000004800
> (XEN)    ffff83013bff1f90 ffff828c8029d400 ffff828c80277d68 ffff828c8012e5ef
> (XEN)    ffff828c80277d48 0000000000000003 ffff83013bff1f90 0000000000000282
> (XEN)    ffff83013bff16f0 0000000000100000 ffff828c80277d98 ffff828c8012e7a1
> (XEN)    0000000000000003 ffff83013bfba330 ffff828c8020c930 0000000000000020
> (XEN)    ffff828c80277de8 ffff828c8012fe48 ffff828c80277dd8 ffff828c8012a2e9
> (XEN)    0000000000000002 000100018020a4c0 0001000100010001 00000000ffffffed
> (XEN)    ffff828c8022fc08 0000000000000003 ffff828c80277e08 ffff828c8012c008
> (XEN)    ffff828c80277e08 ffff828c8022faf8 ffff828c80277f18 ffff828c80223d09
> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff828c8020f665
> (XEN)    ffffffffc0270000 ffff8300bd47cff8 ffff8300bd47dff8 000000000008bf50
> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff83000008bfc0
> (XEN)    ffff83000008bf50 0000000000cc3c00 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000800000000 000000010000006e
> (XEN) Xen call trace:
> (XEN)    [<ffff828c8011b62f>] check_lock+0x19/0x4e
> (XEN)    [<ffff828c8011b7aa>] _spin_lock_irqsave+0x21/0x3f
> (XEN)    [<ffff828c8012e223>] dma_msi_unmask+0x2a/0x4b
> (XEN)    [<ffff828c8012e282>] dma_msi_startup+0x9/0x10
> (XEN)    [<ffff828c80147e90>] setup_irq_vector+0x73/0x99
> (XEN)    [<ffff828c801483be>] request_irq_vector+0x6c/0x9a
> (XEN)    [<ffff828c8012e5ef>] iommu_set_interrupt+0x97/0x10f
> (XEN)    [<ffff828c8012e7a1>] init_vtd_hw+0x13a/0x2d1
> (XEN)    [<ffff828c8012fe48>] intel_vtd_setup+0x330/0x4bb
> (XEN)    [<ffff828c8012c008>] iommu_setup+0x2d/0xf5
> (XEN)    [<ffff828c80223d09>] __start_xen+0x463f/0x4956 (XEN)
> (XEN) Pagetable walk from 0000000000000044:
> (XEN)  L4[0x000] = 000000013bff0063 5555555555555555
> (XEN)  L3[0x000] = 000000013bfef063 5555555555555555
> (XEN)  L2[0x000] = 000000013bfee063 5555555555555555
> (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0000]
> (XEN) Faulting linear address: 0000000000000044
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

* RE: [PATCH] fix iommu interrupt setup
  2009-02-13  0:57     ` Jiang, Yunhong
@ 2009-02-13  1:00       ` Jiang, Yunhong
  2009-02-13  1:09         ` Jiang, Yunhong
  0 siblings, 1 reply; 14+ messages in thread
From: Jiang, Yunhong @ 2009-02-13  1:00 UTC (permalink / raw)
  To: Jiang, Yunhong, Alexia Benington, xen-devel

Sorry, seems queue_invalidate_wait() has irq disabled also :$
So there should have other reason for it.

-- Yunhong Jiang

xen-devel-bounces@lists.xensource.com <> wrote:
> Allen, this is because the register_lock is not always called
> with irq disabled. Seems it is called with spin_lock(),
> instead of spin_lock_irqsave() in queue_invalidate_wait().
> 
> But I'm a bit curios why intel_vtd_setup() will be called
> after queue_invalidate_wait().
> 
> Thanks
> Yunhong Jiang
> 
> xen-devel-bounces@lists.xensource.com <> wrote:
>> I'm getting the same bug.
>> -Alex
>> 
>> (XEN) ----[ Xen-3.4-unstable  x86_64  debug=y  Not tainted ]---- (XEN) CPU:
>> 0 (XEN) RIP:    e008:[<ffff828c8011b62f>] check_lock+0x19/0x4e
>> (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
>> (XEN) rax: 0000000000000001   rbx: 0000000000000040   rcx: 0000000000000001
>> (XEN) rdx: 0000000000000082   rsi: 0000000000000001   rdi: 0000000000000044
>> (XEN) rbp: ffff828c80277c58   rsp: ffff828c80277c58   r8: 0000000000000005
>> (XEN) r9:  0000000000000001   r10: 0000000000000001   r11: ffff828c8028e360
>> (XEN) r12: 0000000000000082   r13: 0000000000000282   r14: 0000000000000090
>> (XEN) r15: ffff83013bfba430   cr0: 000000008005003b   cr4: 00000000000026f0
>> (XEN) cr3: 00000000bd47c000   cr2: 0000000000000044
>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
>> (XEN) Xen stack trace from rsp=ffff828c80277c58:
>> (XEN)    ffff828c80277c78 ffff828c8011b7aa 0000000000000000
>> 0000000000000040 (XEN)    ffff828c80277c98 ffff828c8012e223
>> ffff828c802a1c00 ffff828c802a1c24 (XEN)    ffff828c80277ca8
>> ffff828c8012e282 ffff828c80277ce8 ffff828c80147e90 (XEN)   
>> ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e938 (XEN) 
>> ffff828c801e31cd ffff83013bff1f90 ffff828c80277d28 ffff828c801483be (XEN) 
>> ffff83013bfba430 0000000000000090 ffff83013bff1f90 0000000000004800 (XEN) 
>> ffff83013bff1f90 ffff828c8029d400 ffff828c80277d68 ffff828c8012e5ef (XEN) 
>> ffff828c80277d48 0000000000000003 ffff83013bff1f90 0000000000000282 (XEN) 
>> ffff83013bff16f0 0000000000100000 ffff828c80277d98 ffff828c8012e7a1 (XEN) 
>> 0000000000000003 ffff83013bfba330 ffff828c8020c930 0000000000000020 (XEN) 
>> ffff828c80277de8 ffff828c8012fe48 ffff828c80277dd8 ffff828c8012a2e9 (XEN) 
>> 0000000000000002 000100018020a4c0 0001000100010001 00000000ffffffed (XEN) 
>> ffff828c8022fc08 0000000000000003 ffff828c80277e08 ffff828c8012c008 (XEN) 
>> ffff828c80277e08 ffff828c8022faf8 ffff828c80277f18 ffff828c80223d09 (XEN) 
>> 0000000000000000 0000000000000000 0000000000000000 ffff828c8020f665 (XEN) 
>> ffffffffc0270000 ffff8300bd47cff8 ffff8300bd47dff8 000000000008bf50 (XEN) 
>> 0000000000000000 0000000000000000 0000000000000000 ffff83000008bfc0 (XEN) 
>> ffff83000008bf50 0000000000cc3c00 0000000000000000 0000000000000000 (XEN) 
>> 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 
>> 0000000000000000 0000000000000000 0000000800000000 000000010000006e (XEN)
>> Xen call trace: (XEN)    [<ffff828c8011b62f>] check_lock+0x19/0x4e (XEN)  
>> [<ffff828c8011b7aa>] _spin_lock_irqsave+0x21/0x3f (XEN)   
>> [<ffff828c8012e223>] dma_msi_unmask+0x2a/0x4b (XEN)   
>> [<ffff828c8012e282>] dma_msi_startup+0x9/0x10 (XEN)   
>> [<ffff828c80147e90>] setup_irq_vector+0x73/0x99 (XEN)   
>> [<ffff828c801483be>] request_irq_vector+0x6c/0x9a (XEN)   
>> [<ffff828c8012e5ef>] iommu_set_interrupt+0x97/0x10f (XEN)   
>> [<ffff828c8012e7a1>] init_vtd_hw+0x13a/0x2d1 (XEN)    [<ffff828c8012fe48>]
>> intel_vtd_setup+0x330/0x4bb (XEN)    [<ffff828c8012c008>]
>> iommu_setup+0x2d/0xf5 (XEN)    [<ffff828c80223d09>]
>> __start_xen+0x463f/0x4956 (XEN) (XEN) Pagetable walk from 0000000000000044:
>> (XEN)  L4[0x000] = 000000013bff0063 5555555555555555
>> (XEN)  L3[0x000] = 000000013bfef063 5555555555555555
>> (XEN)  L2[0x000] = 000000013bfee063 5555555555555555
>> (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) FATAL PAGE FAULT
>> (XEN) [error_code=0000]
>> (XEN) Faulting linear address: 0000000000000044
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

* RE: [PATCH] fix iommu interrupt setup
  2009-02-13  1:00       ` Jiang, Yunhong
@ 2009-02-13  1:09         ` Jiang, Yunhong
  0 siblings, 0 replies; 14+ messages in thread
From: Jiang, Yunhong @ 2009-02-13  1:09 UTC (permalink / raw)
  To: Jiang, Yunhong, Alexia Benington, xen-devel, Kay, Allen M

It is because in iommu_set_interrupt(), the vector_to_iommu[] is setup after request_irq(), while request_irq() will call start_up(), which will need the vector_to_iommu[].
So maybe we can setup the vector_to_iommup[] before  request_irq().

Thanks
Yunhong Jiang

Jiang, Yunhong <> wrote:
> Sorry, seems queue_invalidate_wait() has irq disabled also :$
> So there should have other reason for it.
> 
> -- Yunhong Jiang
> 
> xen-devel-bounces@lists.xensource.com <> wrote:
>> Allen, this is because the register_lock is not always called
>> with irq disabled. Seems it is called with spin_lock(),
>> instead of spin_lock_irqsave() in queue_invalidate_wait().
>> 
>> But I'm a bit curios why intel_vtd_setup() will be called
>> after queue_invalidate_wait().
>> 
>> Thanks
>> Yunhong Jiang
>> 
>> xen-devel-bounces@lists.xensource.com <> wrote:
>>> I'm getting the same bug.
>>> -Alex
>>> 
>>> (XEN) ----[ Xen-3.4-unstable  x86_64  debug=y  Not tainted ]---- (XEN)
>>> CPU: 0 (XEN) RIP:    e008:[<ffff828c8011b62f>] check_lock+0x19/0x4e
>>> (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
>>> (XEN) rax: 0000000000000001   rbx: 0000000000000040   rcx:
>>> 0000000000000001 (XEN) rdx: 0000000000000082   rsi: 0000000000000001  
>>> rdi: 0000000000000044 (XEN) rbp: ffff828c80277c58   rsp: ffff828c80277c58
>>> r8: 0000000000000005 (XEN) r9:  0000000000000001   r10: 0000000000000001 
>>> r11: ffff828c8028e360 (XEN) r12: 0000000000000082   r13: 0000000000000282
>>> r14: 0000000000000090 (XEN) r15: ffff83013bfba430   cr0: 000000008005003b
>>> cr4: 00000000000026f0 (XEN) cr3: 00000000bd47c000   cr2: 0000000000000044
>>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000 cs: e008
>>> (XEN) Xen stack trace from rsp=ffff828c80277c58:
>>> (XEN)    ffff828c80277c78 ffff828c8011b7aa 0000000000000000
>>> 0000000000000040 (XEN)    ffff828c80277c98 ffff828c8012e223
>>> ffff828c802a1c00 ffff828c802a1c24 (XEN)    ffff828c80277ca8
>>> ffff828c8012e282 ffff828c80277ce8 ffff828c80147e90 (XEN)
>>> ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e938 (XEN)
>>> ffff828c801e31cd ffff83013bff1f90 ffff828c80277d28 ffff828c801483be (XEN)
>>> ffff83013bfba430 0000000000000090 ffff83013bff1f90 0000000000004800 (XEN)
>>> ffff83013bff1f90 ffff828c8029d400 ffff828c80277d68 ffff828c8012e5ef (XEN)
>>> ffff828c80277d48 0000000000000003 ffff83013bff1f90 0000000000000282 (XEN)
>>> ffff83013bff16f0 0000000000100000 ffff828c80277d98 ffff828c8012e7a1 (XEN)
>>> 0000000000000003 ffff83013bfba330 ffff828c8020c930 0000000000000020 (XEN)
>>> ffff828c80277de8 ffff828c8012fe48 ffff828c80277dd8 ffff828c8012a2e9 (XEN)
>>> 0000000000000002 000100018020a4c0 0001000100010001 00000000ffffffed (XEN)
>>> ffff828c8022fc08 0000000000000003 ffff828c80277e08 ffff828c8012c008 (XEN)
>>> ffff828c80277e08 ffff828c8022faf8 ffff828c80277f18 ffff828c80223d09 (XEN)
>>> 0000000000000000 0000000000000000 0000000000000000 ffff828c8020f665 (XEN)
>>> ffffffffc0270000 ffff8300bd47cff8 ffff8300bd47dff8 000000000008bf50 (XEN)
>>> 0000000000000000 0000000000000000 0000000000000000 ffff83000008bfc0 (XEN)
>>> ffff83000008bf50 0000000000cc3c00 0000000000000000 0000000000000000 (XEN)
>>> 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN)
>>> 0000000000000000 0000000000000000 0000000800000000 000000010000006e (XEN)
>>> Xen call trace: (XEN)    [<ffff828c8011b62f>] check_lock+0x19/0x4e (XEN)
>>> [<ffff828c8011b7aa>] _spin_lock_irqsave+0x21/0x3f (XEN)
>>> [<ffff828c8012e223>] dma_msi_unmask+0x2a/0x4b (XEN)
>>> [<ffff828c8012e282>] dma_msi_startup+0x9/0x10 (XEN)
>>> [<ffff828c80147e90>] setup_irq_vector+0x73/0x99 (XEN)
>>> [<ffff828c801483be>] request_irq_vector+0x6c/0x9a (XEN)
>>> [<ffff828c8012e5ef>] iommu_set_interrupt+0x97/0x10f (XEN)
>>> [<ffff828c8012e7a1>] init_vtd_hw+0x13a/0x2d1 (XEN) [<ffff828c8012fe48>]
>>> intel_vtd_setup+0x330/0x4bb (XEN)    [<ffff828c8012c008>]
>>> iommu_setup+0x2d/0xf5 (XEN)    [<ffff828c80223d09>]
>>> __start_xen+0x463f/0x4956 (XEN) (XEN) Pagetable walk from
>>> 0000000000000044: (XEN)  L4[0x000] = 000000013bff0063 5555555555555555
>>> (XEN)  L3[0x000] = 000000013bfef063 5555555555555555
>>> (XEN)  L2[0x000] = 000000013bfee063 5555555555555555
>>> (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff (XEN)
>>> (XEN) ****************************************
>>> (XEN) Panic on CPU 0:
>>> (XEN) FATAL PAGE FAULT
>>> (XEN) [error_code=0000]
>>> (XEN) Faulting linear address: 0000000000000044
>>> (XEN) ****************************************
>>> (XEN)
>>> (XEN) Reboot in five seconds...
>>> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

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

* RE: [PATCH] fix iommu interrupt setup
  2009-02-12 22:17 ` Kay, Allen M
  2009-02-12 22:56   ` Alexia Benington
@ 2009-02-13  1:46   ` kouya
  2009-02-13  8:55     ` Keir Fraser
  2009-02-13  8:48   ` Keir Fraser
  2 siblings, 1 reply; 14+ messages in thread
From: kouya @ 2009-02-13  1:46 UTC (permalink / raw)
  To: xen-devel; +Cc: alexbenington, yunhong.jiang, allen.m.kay

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 240 bytes --]

Hi,

Attached patch may help. This is extracted from my previous patch.
- set vector_to_iommu[vector] before calling request_vector
  since null pointer exceptions occurs

Thanks,
Kouya

Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>


[-- Attachment #2: fix_iommu_interrupt_setup.patch --]
[-- Type: text/x-patch, Size: 2081 bytes --]

diff -r 32b154137492 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Feb 12 10:54:17 2009 +0000
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Fri Feb 13 09:22:41 2009 +0900
@@ -487,11 +487,13 @@ static int set_iommu_interrupt_handler(s
     }
 
     irq_desc[vector].handler = &iommu_msi_type;
+    vector_to_iommu[vector] = iommu;
     ret = request_irq_vector(vector, amd_iommu_page_fault, 0,
                              "amd_iommu", iommu);
     if ( ret )
     {
         irq_desc[vector].handler = &no_irq_type;
+    vector_to_iommu[vector] = NULL;
         free_irq_vector(vector);
         amd_iov_error("can't request irq\n");
         return 0;
@@ -499,7 +501,6 @@ static int set_iommu_interrupt_handler(s
 
     /* Make sure that vector is never re-used. */
     vector_irq[vector] = NEVER_ASSIGN_IRQ;
-    vector_to_iommu[vector] = iommu;
     iommu->vector = vector;
     return vector;
 }
diff -r 32b154137492 xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c	Thu Feb 12 10:54:17 2009 +0000
+++ b/xen/drivers/passthrough/vtd/iommu.c	Fri Feb 13 09:22:41 2009 +0900
@@ -870,7 +870,7 @@ static struct hw_interrupt_type dma_msi_
     .set_affinity = dma_msi_set_affinity,
 };
 
-int iommu_set_interrupt(struct iommu *iommu)
+static int iommu_set_interrupt(struct iommu *iommu)
 {
     int vector, ret;
 
@@ -882,10 +882,12 @@ int iommu_set_interrupt(struct iommu *io
     }
 
     irq_desc[vector].handler = &dma_msi_type;
+    vector_to_iommu[vector] = iommu;
     ret = request_irq_vector(vector, iommu_page_fault, 0, "dmar", iommu);
     if ( ret )
     {
         irq_desc[vector].handler = &no_irq_type;
+        vector_to_iommu[vector] = NULL;
         free_irq_vector(vector);
         gdprintk(XENLOG_ERR VTDPREFIX, "IOMMU: can't request irq\n");
         return ret;
@@ -893,7 +895,6 @@ int iommu_set_interrupt(struct iommu *io
 
     /* Make sure that vector is never re-used. */
     vector_irq[vector] = NEVER_ASSIGN_IRQ;
-    vector_to_iommu[vector] = iommu;
 
     return vector;
 }

[-- Attachment #3: message body text --]
[-- Type: text/plain, Size: 4576 bytes --]


Kay, Allen M writes:
> Interrupt handling cleanup in changeset 19195 is causing following failure on my system:
> 
> (XEN) ----[ Xen-3.4-unstable  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff828c8011b591>] check_lock+0x19/0x4e
> (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
> (XEN) rax: 0000000000000001   rbx: 0000000000000040   rcx: 0000000000000001
> (XEN) rdx: 0000000000000082   rsi: 0000000000000001   rdi: 0000000000000044
> (XEN) rbp: ffff828c80277c58   rsp: ffff828c80277c58   r8:  0000000000000005
> (XEN) r9:  0000000000000001   r10: 0000000000000001   r11: 0000000000000000
> (XEN) r12: 0000000000000082   r13: 0000000000000282   r14: 0000000000000090
> (XEN) r15: ffff83007f2c4160   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 000000007f47c000   cr2: 0000000000000044
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen stack trace from rsp=ffff828c80277c58:
> (XEN)    ffff828c80277c78 ffff828c8011b70c 0000000000000000 0000000000000040
> (XEN)    ffff828c80277c98 ffff828c8012df24 ffff828c802a1c00 ffff828c802a1c24
> (XEN)    ffff828c80277ca8 ffff828c8012df83 ffff828c80277ce8 ffff828c80147cc0
> (XEN)    ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e639
> (XEN)    ffff828c801e2191 ffff83007f4d9df0 ffff828c80277d28 ffff828c801481fa
> (XEN)    ffff83007f2c4160 0000000000000090 ffff83007f4d9df0 0000000000004800
> (XEN)    ffff83007f4d9df0 ffff828c8029d400 ffff828c80277d68 ffff828c8012e2f0
> (XEN)    ffff828c80277d48 0000000000000000 ffff83007f4d9df0 0000000000000282
> (XEN)    ffff83007f6df130 0000000000100000 ffff828c80277d98 ffff828c8012e4a2
> (XEN)    0000000000000000 ffff83007f4d9df0 ffff828c8020b8b0 0000000000000020
> (XEN)    ffff828c80277de8 ffff828c8012fb38 ffff828c80277dd8 ffff828c8012a183
> (XEN)    0000000000000004 00010001802093c0 0001000100010001 00000000ffffffed
> (XEN)    ffff828c8022ec08 0000000000000017 ffff828c80277e08 ffff828c8012be18
> (XEN)    ffff828c80277e08 ffff828c8022eaf8 ffff828c80277f18 ffff828c80222ca8
> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff828c8020e675
> (XEN)    ffffffffc0270000 ffff83007f47cff8 ffff83007f47dff8 000000000020e610
> (XEN)    000000000008bf60 0000000000000000 0000000000000000 0000000000000000
> (XEN)    ffff83000008bfc0 ffff83000008bf60 0000000000b0c800 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000800000000 000000010000006e
> (XEN) Xen call trace:
> (XEN)    [<ffff828c8011b591>] check_lock+0x19/0x4e
> (XEN)    [<ffff828c8011b70c>] _spin_lock_irqsave+0x21/0x3f
> (XEN)    [<ffff828c8012df24>] dma_msi_unmask+0x2a/0x4b
> (XEN)    [<ffff828c8012df83>] dma_msi_startup+0x9/0x10
> (XEN)    [<ffff828c80147cc0>] setup_irq_vector+0x73/0x99
> (XEN)    [<ffff828c801481fa>] request_irq_vector+0x6c/0x9a
> (XEN)    [<ffff828c8012e2f0>] iommu_set_interrupt+0x97/0x10f
> (XEN)    [<ffff828c8012e4a2>] init_vtd_hw+0x13a/0x2d1
> (XEN)    [<ffff828c8012fb38>] intel_vtd_setup+0x332/0x4bd
> (XEN)    [<ffff828c8012be18>] iommu_setup+0x2d/0xf5
> (XEN)    [<ffff828c80222ca8>] __start_xen+0x457d/0x4895
> (XEN)    
> (XEN) Pagetable walk from 0000000000000044:
> (XEN)  L4[0x000] = 000000007f706063 5555555555555555
> (XEN)  L3[0x000] = 000000007e6f1063 5555555555555555
> (XEN)  L2[0x000] = 000000007e6f0063 5555555555555555 
> (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
> (XEN) 
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0000]
> (XEN) Faulting linear address: 0000000000000044
> (XEN) ****************************************
> (XEN) 
> (XEN) Reboot in five seconds...
> 
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Kouya Shimura
> Sent: Wednesday, February 11, 2009 7:00 PM
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] fix iommu interrupt setup
> 
> iommu is disabled since cset 19175:ab514cfbcdc5 with the following message:
> 
> (XEN) [VT-D]iommu.c:890:d32767 IOMMU: can't request irq
> (XEN) [VT-D]iommu.c:1686:d32767 IOMMU: interrupt setup failed
> (XEN) I/O virtualisation disabled
> 
> This patch fixes it.
> - rename request_irq to request_vector, no conversion by irq_to_vector(irq)
> - set vector_to_iommu[vector] before calling request_vector
>   since null pointer exceptions occurs
> - some cleanups
> 
> Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>


[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

* Re: [PATCH] fix iommu interrupt setup
  2009-02-12 22:17 ` Kay, Allen M
  2009-02-12 22:56   ` Alexia Benington
  2009-02-13  1:46   ` kouya
@ 2009-02-13  8:48   ` Keir Fraser
  2009-02-13 11:33     ` Espen Skoglund
  2 siblings, 1 reply; 14+ messages in thread
From: Keir Fraser @ 2009-02-13  8:48 UTC (permalink / raw)
  To: Kay, Allen M, xen-devel; +Cc: Espen Skoglund

On 12/02/2009 22:17, "Kay, Allen M" <allen.m.kay@intel.com> wrote:

> Interrupt handling cleanup in changeset 19195 is causing following failure on
> my system:
> 
> (XEN) ----[ Xen-3.4-unstable  x86_64  debug=y  Not tainted ]----

The guy you want to complain to is Espen, not Kouya.

These interrupt cleanups have not gone smoothly. I'll give it a while longer
but I will rip them all back out if the situation doesn't get better by next
week.

 -- Keir

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

* Re: [PATCH] fix iommu interrupt setup
  2009-02-13  1:46   ` kouya
@ 2009-02-13  8:55     ` Keir Fraser
  0 siblings, 0 replies; 14+ messages in thread
From: Keir Fraser @ 2009-02-13  8:55 UTC (permalink / raw)
  To: kouya, xen-devel
  Cc: alexbenington, Espen Skoglund, yunhong.jiang, allen.m.kay

On 13/02/2009 01:46, "kouya@jp.fujitsu.com" <kouya@jp.fujitsu.com> wrote:

> Hi,
> 
> Attached patch may help. This is extracted from my previous patch.
> - set vector_to_iommu[vector] before calling request_vector
>   since null pointer exceptions occurs

Thanks Kouya, let's hope this puts the issues to rest.

 -- Keir

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

* Re: [PATCH] fix iommu interrupt setup
  2009-02-13  8:48   ` Keir Fraser
@ 2009-02-13 11:33     ` Espen Skoglund
  2009-02-13 11:48       ` Keir Fraser
  0 siblings, 1 reply; 14+ messages in thread
From: Espen Skoglund @ 2009-02-13 11:33 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Espen Skoglund, xen-devel, Kay, Allen M

[Keir Fraser]
> On 12/02/2009 22:17, "Kay, Allen M" <allen.m.kay@intel.com> wrote:
>> Interrupt handling cleanup in changeset 19195 is causing following
>> failure on my system:
>> 
>> (XEN) ----[ Xen-3.4-unstable  x86_64  debug=y  Not tainted ]----

> The guy you want to complain to is Espen, not Kouya.

It's always nice when someone else accidentally gets the blame. :)

> These interrupt cleanups have not gone smoothly. I'll give it a
> while longer but I will rip them all back out if the situation
> doesn't get better by next week.

Things have not gone smoothly at all.  Hopefully Kouya's patch will
sort out that IOMMU issue.  And hopefully I can get my hands on a new
Tylersburg system so that I can test out all the VT-d interrupt
remapping stuff myself.

	eSk

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

* Re: [PATCH] fix iommu interrupt setup
  2009-02-13 11:33     ` Espen Skoglund
@ 2009-02-13 11:48       ` Keir Fraser
  2009-02-13 11:57         ` Espen Skoglund
  0 siblings, 1 reply; 14+ messages in thread
From: Keir Fraser @ 2009-02-13 11:48 UTC (permalink / raw)
  To: Espen Skoglund; +Cc: xen-devel, Kay, Allen M

On 13/02/2009 11:33, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:

>> These interrupt cleanups have not gone smoothly. I'll give it a
>> while longer but I will rip them all back out if the situation
>> doesn't get better by next week.
> 
> Things have not gone smoothly at all.  Hopefully Kouya's patch will
> sort out that IOMMU issue.  And hopefully I can get my hands on a new
> Tylersburg system so that I can test out all the VT-d interrupt
> remapping stuff myself.

By the way, one of your other patches got reverted since it broke booting on
a bunch of systems. It was applied as c/s 19178 and reverted as c/s 19182.
It was the one that separates IOAPIC mgmt from vector mgmt.

 -- Keir

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

* Re: [PATCH] fix iommu interrupt setup
  2009-02-13 11:48       ` Keir Fraser
@ 2009-02-13 11:57         ` Espen Skoglund
  2009-02-13 12:21           ` Keir Fraser
  0 siblings, 1 reply; 14+ messages in thread
From: Espen Skoglund @ 2009-02-13 11:57 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Kay, Allen M, xen-devel, Espen Skoglund

[Keir Fraser]
> On 13/02/2009 11:33, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:
>>> These interrupt cleanups have not gone smoothly. I'll give it a
>>> while longer but I will rip them all back out if the situation
>>> doesn't get better by next week.
>> 
>> Things have not gone smoothly at all.  Hopefully Kouya's patch will
>> sort out that IOMMU issue.  And hopefully I can get my hands on a
>> new Tylersburg system so that I can test out all the VT-d interrupt
>> remapping stuff myself.

> By the way, one of your other patches got reverted since it broke
> booting on a bunch of systems. It was applied as c/s 19178 and
> reverted as c/s 19182.  It was the one that separates IOAPIC mgmt
> from vector mgmt.

Yes.  I noticed.  Was going to ask about more info on this one.  Is
there some bugzilla entry or something that gives some more detail
about what the problems were?  (I'm a bugzilla newbie and don't follow
xen-bugs@ at all.)

	eSk

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

* Re: [PATCH] fix iommu interrupt setup
  2009-02-13 11:57         ` Espen Skoglund
@ 2009-02-13 12:21           ` Keir Fraser
  0 siblings, 0 replies; 14+ messages in thread
From: Keir Fraser @ 2009-02-13 12:21 UTC (permalink / raw)
  To: Espen Skoglund; +Cc: xen-devel, Kay, Allen M

On 13/02/2009 11:57, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:

>> By the way, one of your other patches got reverted since it broke
>> booting on a bunch of systems. It was applied as c/s 19178 and
>> reverted as c/s 19182.  It was the one that separates IOAPIC mgmt
>> from vector mgmt.
> 
> Yes.  I noticed.  Was going to ask about more info on this one.  Is
> there some bugzilla entry or something that gives some more detail
> about what the problems were?  (I'm a bugzilla newbie and don't follow
> xen-bugs@ at all.)

Hangs when bringing up the disc controller (whether SCSI or IDE) with
command timeouts and the like which generally point to broken interrupts.
When I said it didn't work on a 'wide range' of systems, we didn't actually
find a single system it *did* work on! We must have tested on at least four
separate systems with 100% failure on those. I reckon you should be able to
repro it yourself pretty easily.

 -- Keir

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

end of thread, other threads:[~2009-02-13 12:21 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-12  2:59 [PATCH] fix iommu interrupt setup Kouya Shimura
2009-02-12  8:42 ` Keir Fraser
2009-02-12 22:17 ` Kay, Allen M
2009-02-12 22:56   ` Alexia Benington
2009-02-13  0:57     ` Jiang, Yunhong
2009-02-13  1:00       ` Jiang, Yunhong
2009-02-13  1:09         ` Jiang, Yunhong
2009-02-13  1:46   ` kouya
2009-02-13  8:55     ` Keir Fraser
2009-02-13  8:48   ` Keir Fraser
2009-02-13 11:33     ` Espen Skoglund
2009-02-13 11:48       ` Keir Fraser
2009-02-13 11:57         ` Espen Skoglund
2009-02-13 12:21           ` Keir Fraser

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.