Re: [Xen-devel] Xen-unstable: pci-passthrough "irq 16: nobody cared" on HVM guest shutdown on irq of device not passed through.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.10.14 at 15:43, <linux@xxxxxxxxxxxxxx> wrote:
> I am seeing a couple of "oddities" (although i could be misinterpreting 
> stuff):
> 
> - When MSI gets enabled on pci-passthrough during the boot of the guest, 
> dev->irq changes
>   (and with it the irq reported by lspci and reported at 
> /sys/bus/pci/devices/<BDF>/irq)
>   from 22 to 68. It probably is/shouldn't be used since we should be using 
> MSI (55) now.
>   However this "68" doesn't seem to be listed anywhere as irq, not in dom0 
> in /proc/interrupts, not
>   in the hypervisor output of the debug-keys "i, I, M".
> 
> 
> - After the guest is fully booted the hypervisor reports shows an irq mapped 
> to the guest, while 22 is still mapped to dom0:
>   (XEN) [2014-10-21 02:11:03]    IRQ:  22 affinity:8 vec:d8 
> type=IO-APIC-level   
> status=00000030 in-flight=0 domain-list=0: 22(---),
>   ...
>   (XEN) [2014-10-21 02:11:03]    IRQ:  32 affinity:4 vec:69 type=PCI-MSI      
>   
>  status=00000030 in-flight=0 domain-list=1: 55(---),
>   MSI 55 corresponds to what dom0 reports .. but i can't place IRQ 32 though 
> .. it's not 22 .. it's not 68 ..

Just to make things difficult, 3.17's changes for IRQ domains result in
even more of a mix-up of numbers. When you quote any, please make
sure you properly separate
- Xen's IRQ number (for pin based IRQs this would normally equal the
  GSI)
- the IRQ number Xen assigns for Dom0 (or DomU)
- the IRQ number the Dom0 (or DomU) kernel uses internally

That said, I'm more than happy to look into issues you find with the
hypervisor, but I'm generally the wrong one to ask about problems
with upstream Linux (for the time being we continue to use forward
ported kernels here, and I'm simply lacking the time to also play
with upstream ones). And with what you reported here I don't think
there are indications of hypervisor side things going wrong (other
than is presumably the case with the $subject issue, which btw
hints at it being a bad idea to hijack another [already convoluted]
thread).

Jan


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