WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] MSI causing softpanics in guest

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Anish Bhatt <anish@xxxxxxxxxx>
Subject: RE: [Xen-devel] MSI causing softpanics in guest
From: "Shan, Haitao" <haitao.shan@xxxxxxxxx>
Date: Tue, 23 Sep 2008 15:50:57 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 23 Sep 2008 00:51:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48D8B59E.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <48D40332.5090706@xxxxxxxxxxxxx> <C4FA6F98.1D5F8%keir.fraser@xxxxxxxxxxxxx> <48D76F81.76E4.0078.0@xxxxxxxxxx> <48D878CB.6060404@xxxxxxxxxx> <48D8B59E.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckdTTttN+B04fljRNKKzhKmLGeNyAAAdvAw
Thread-topic: [Xen-devel] MSI causing softpanics in guest
Just some thoughts on Anish's problem. It seems he reveals a bug in current 
code, I think.

Currently, evnchn_map_pirq is hooked on msi_map_vector 
(pci_enable_msi->msi_capability_init->msi_map_vector). Here the pirq type is 
set to IRQT_PIRQ. Then request_irq should succeed since pirq type is already 
set.

However, this path only works on the assumption that msi_map_vector and 
request_irq are executed in the same domain, to be more specific, dom0.
For PV domU guest, there is no msi_map_vector in its pci_enable_msi ( PV domU 
actually asks dom0 to do the msi map, instead. This is a decision made by Keir 
and Yunhong long ago. I think it is base on security considerations). So its 
irq type is not set correctly (What's more, it incorrectly sets the dom0's irq 
type). Then request_irq can trigger this bug_on().

Anish, if you use the device in dom0 itself, does it also have this bug_on?

Keir and Jan,
Do you think this explanation is reasonable for issues Anish met?

Best Regards
Shan Haitao

-----Original Message-----
From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx]
Sent: 2008年9月23日 15:24
To: Anish Bhatt
Cc: Keir Fraser; Shan, Haitao; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] MSI causing softpanics in guest

So the question is what irq you pass in to request_irq() and where you got
it from. Jan

>>> Anish Bhatt <anish@xxxxxxxxxx> 23.09.08 07:04 >>>
I put a printk before BUG_ON, Its expecting IRQT_PIRQ, but getting
IRQT_UNBOUND instead.
-Anish

Jan Beulich wrote:
>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 20.09.08 10:15 >>>
>>>>
>> On 3.3.0 you need to specify msi=1 on Xen's command line to enable MSI. In
>> xen-unstable, MSI support is always enabled.
>>
>> I changed a check in evtchn_get_xen_pirq() into a BUG_ON() as it looks to me
>> like it should never trigger. Jan Beulich was the original authour of that
>> function -- cc'ed in case he can indicate whether I've actually broken the
>> function. :-)
>>
>
> No, I think that BUG_ON() you added is valid. It definitely is in the context
> of startup_pirq(). I'd be curious to know what the type of that irq really is,
> but that cannot be determined from the backtrace alone. Anish, could you
> perhaps add a simple printk() before the BUG_ON()? Unfortunately the
> driver in question does not appear to be part of the tree, so we can't even
> check what it does prior to calling request_irq()...
>
>  -- Keir
>
> On 19/9/08 20:53, "Anish Bhatt" <anish@xxxxxxxxxxxxx> wrote:
>
>
>> lspci shows MSI enabled for PCI device. PCI passthrough works fine.
>> However, as soon as the MSI driver for card is insmodded, kernel panics.
>> This is on xen-unstable.  Tried the same with xen-3.3.0 which is
>> supposed to have MSI passthrough, but the same guest shows MSI as disabled.
>> Any else seen this bug, or know of a workaround ?
>>
>> Trace is as follows :
>>
>> ------------[ cut here ]------------
>> kernel BUG at
>>
>>
> /usr/src/xen/xen-unstable.hg/linux-2.6.18-xen.hg/drivers/xen/core/evtchn.c:809>
> !
>
>> invalid opcode: 0000 [#1]
>> SMP
>> Modules linked in: nfemsg nfdvnet ipv6 binfmt_misc dm_mod nfe usbcore
>> ext3 jbd processor fuse
>> CPU:    0
>> EIP:    0061:[<c02487f5>]    Tainted: GF     VLI
>> EFLAGS: 00210097   (2.6.18.8-xen #2)
>> EIP is at evtchn_get_xen_pirq+0x35/0x40
>> eax: ffffffff   ebx: 00000002   ecx: c0372e60   edx: 00000000
>> esi: c2103560   edi: c03d3080   ebp: 000004f9   esp: ed385dac
>> ds: 007b   es: 007b   ss: 0069
>> Process modprobe (pid: 2590, ti=ed384000 task=ed7b1100 task.ti=ed384000)
>> Stack: c0248aef 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>>        00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>>        00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> Call Trace:
>>  [<c0248aef>] startup_pirq+0x3f/0x250
>>  [<c0150b50>] setup_irq+0x160/0x1b0
>>  [<ee0dd270>] nfe_interrupt_handler+0x0/0x30 [nfemsg]
>>  [<c0150c43>] request_irq+0xa3/0xc0
>>  [<ee02c8ad>] nfemsg_module_init+0x8ad/0x133e [nfemsg]
>>  [<c030531b>] cond_resched+0x2b/0x40
>>  [<c0305369>] wait_for_completion+0x19/0xf0
>>  [<c0142818>] sys_init_module+0x148/0x1b50
>>  [<c010595f>] syscall_call+0x7/0xb
>> Code: 00 00 89 d1 d3 e0 85 05 c4 2c 42 c0 74 1a 8b 14 95 c0 c0 44 c0 89
>> d0 c1 e8 1c 83 e8 01 75 0c c1 ea 0c 81 e2 ff ff 00 00 89 d0 c3 <0f> 0b
>> 29 03 a4 f1 32 c0 eb ea 90 83 ec 08 89 74 24 04 89 c6 a1
>> EIP: [<c02487f5>] evtchn_get_xen_pirq+0x35/0x40 SS:ESP 0069:ed385dac
>>  ### card [0] start: host progs ###
>> -bash-3.2#
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: ------------[ cut here ]------------
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: kernel BUG at
>>
>>
> /usr/src/xen/xen-unstable.hg/linux-2.6.18-xen.hg/drivers/xen/core/evtchn.c:809>
> !
>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: invalid opcode: 0000 [#1]
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: SMP
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: CPU:    0
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: EIP is at evtchn_get_xen_pirq+0x35/0x40
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: eax: ffffffff   ebx: 00000002   ecx: c0372e60   edx: 00000000
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: esi: c2103560   edi: c03d3080   ebp: 000004f9   esp: ed385dac
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: ds: 007b   es: 007b   ss: 0069
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: Process modprobe (pid: 2590, ti=ed384000 task=ed7b1100
>> task.ti=ed384000)
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: Stack: c0248aef 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel:        00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel:        00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: Call Trace:
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: Code: 00 00 89 d1 d3 e0 85 05 c4 2c 42 c0 74 1a 8b 14 95 c0 c0
>> 44 c0 89 d0 c1 e8 1c 83 e8 01 75 0c c1 ea 0c 81 e2 ff ff 00 00 89 d0 c3
>> <0f> 0b 29 03 a4 f1 32 c0 eb ea 90 83 ec 08 89 74 24 04 89 c6 a1
>>
>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>  kernel: EIP: [<c02487f5>] evtchn_get_xen_pirq+0x35/0x40 SS:ESP
>> 0069:ed385dac
>>
>
>
>


--
As long as the music's loud enough, we won't hear the world falling apart.


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