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

["Shan, Haitao" <haitao.shan@xxxxxxxxx>]

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