[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen-unstable: xen panic RIP: dpci_softirq



>>> On 17.11.14 at 23:40, <linux@xxxxxxxxxxxxxx> wrote:
> OK, i still don't get why the output of debug-key 'i' reports +47 as pirq 
> here instead of the guest value 
> (g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a 
> MSI with the PIRQ ?

No - as you said yourself, it's a matter of who uses which numbers.
Xen can't know the IRQ number the guest OS choses internally. It
can only tell you the number the hypervisor uses internally and the
one it told the guest to use to refer to it (the former is what we
commonly refer to as IRQ, while the latter is the pIRQ). Pin-based
(i.e. IO-APIC) interrupts should always use the same number for
both; MSI ones could only happen to have them match up, but
would use distinct numbers normally.

>> I am puzzled by the driver binding twice to the same interrupt, but perhaps 
> that
>> is just a buggy driver.
> 
> Doesn't that happen more often like with integrated USB controllers ?
>   17:          4          0          0          0          0          0  
> xen-pirq-ioapic-level  ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3
>   18:       4385          0          0          0          0          0  
> xen-pirq-ioapic-level  ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, 
> ohci_hcd:usb7

No, these are all distinct devices - if you look at you lspci output,
you should find multiple EHCI and OHCI controller instances. It's
slightly odd that each kind gets grouped onto a single IO-APIC pin,
but that's a (legal) BIOS decision.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.