From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anish Bhatt Subject: Re: MSI causing softpanics in guest Date: Fri, 26 Sep 2008 22:41:34 -0400 Message-ID: <48DD9D5E.5090806@cc.gatech.edu> References: <48D40332.5090706@cc.gatech.edu> <48D76F81.76E4.0078.0@novell.com> <48D878CB.6060404@gatech.edu> <48D8B59E.76E4.0078.0@novell.com> <48D984DC.3030904@cc.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Shan, Haitao" Cc: "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.org Works fine now with your patch, but I still see the ' physdev.c:90:d0 remap pirq fa vector 49 while not unmap' message in dom0 xm dmesg. Is that something to be bothered about ? -Anish Shan, Haitao wrote: > It is supposed to work on dom0. This is a bug. > Please refer to Keir's reply in this mail thread. > > Shan Haitao > > -----Original Message----- > From: Anish Bhatt [mailto:anish@cc.gatech.edu] > Sent: 2008年9月24日 8:08 > To: Shan, Haitao > Cc: Jan Beulich; xen-devel@lists.xensource.com; Keir Fraser > Subject: Re: [Xen-devel] MSI causing softpanics in guest > > No, the bug_on is not triggered in dom0. I also saw the following error > message in xm dmesg, : > /physdev.c:90:d0 remap pirq fa vector 49 while not unmap/ > Its part of the code added for MSI, I wonder if its of any significance. > > -Anish > > Shan, Haitao wrote: > >> 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@novell.com] >> Sent: 2008年9月23日 15:24 >> To: Anish Bhatt >> Cc: Keir Fraser; Shan, Haitao; xen-devel@lists.xensource.com >> 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 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 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" 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:[] 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: >>>> [] startup_pirq+0x3f/0x250 >>>> [] setup_irq+0x160/0x1b0 >>>> [] nfe_interrupt_handler+0x0/0x30 [nfemsg] >>>> [] request_irq+0xa3/0xc0 >>>> [] nfemsg_module_init+0x8ad/0x133e [nfemsg] >>>> [] cond_resched+0x2b/0x40 >>>> [] wait_for_completion+0x19/0xf0 >>>> [] sys_init_module+0x148/0x1b50 >>>> [] 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: [] 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: [] 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@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> > > > -- > As long as the music's loud enough, we won't hear the world falling apart. > > -- As long as the music's loud enough, we won't hear the world falling apart.