Re: [Xen-devel] dom0 kernel - irq nobody cared ... the continuing saga ..

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Tuesday, February 10, 2015, 10:35:36 AM, you wrote:

>>>> On 10.02.15 at 10:19, <linux@xxxxxxxxxxxxxx> wrote:
>>> Coming back to the /proc/interrupts output you posted earlier:
>> 
>>> /proc/interrupts shows the high count:
>> 
>>>            CPU0       CPU1       CPU2       CPU3
>>>   8:          0          0          0          0  xen-pirq-ioapic-edge  rtc0
>>>   9:          1          0          0          0  xen-pirq-ioapic-level  
>>> acpi
>>>  16:         29          0          0          0  xen-pirq-ioapic-level  
>>> ehci_hcd:usb3
>>>  18:     200000          0          0          0  xen-pirq-ioapic-level  
>>> ata_generic
>> 
>>> I would have thought that xen-pciback would install an interrupt
>>> handler here too when a device using IRQ 18 gets handed to a
>>> guest. May there be something broken in xen_pcibk_control_isr()?
>> 
>> It seems to only do that for PV guests, not for HVM.

> Interesting; no idea why that would be.

>> Don't know how it wil go now after the bios update,
>> lspci lists the SMBUS is also using irq 18 now, but it doesn't register
>> a driver (according to lspci -k) and it doesn't appear in dom0's 
>> /proc/interrupts.

> With that I don't think you're going to have problems, as the IRQ
> then is masked.

Is there an easy way to verify that it's indeed masked ?

>> How are things supposed to work with a machine with:
>> - a shared irq
>> - iommu + interrupt remapping enabled
>> - HVM guests

> Konrad?

>> Would dom0 always see the legacy irq or is Xen or the iommu routing it 
>> directly to 
>> the guest ?

> A shared IRQ can't be routed directly, as all involved domains need
> to see it.


>> And what would i suppose to see when using Xen's debug key 'i', should there 
>> be an entry routing it to both guests ?

> Yes, if both have a driver using it.

Yes, so when no driver enables it, xen won't list it either, then my thinking 
was correct at that point.

>>. if you know some better way to figure out where the irq storm is 
>> coming from or headed to .. i'm all ears (or eyes) ..

> I suppose that's because there's no handler installed by pciback, yet
> IRQs generated by the passed through device also arrive in Dom0,
> and the driver for the device left in Dom0 doesn't claim the interrupts.

Yes so just for my idea of what happened (and i have googled):
the irq arrived at dom0 .. it went through the registered handlers:
[ 1906.422483] handlers:
[ 1906.441717] [<ffffffff8155cd42>] ata_bmdma_interrupt

In this case .. there is only one .. the handler verifies if it should
actually handle this irq by the dev_id cookie, in this case it doesn't
.. there are no handlers .. so after 200000 of those linux says hey we
have an interrupt that nobody cared about.

So there is a chance it's an irq that was actually destined to the device
that was passed through, but that didn't handle it ?
If that's the case .. why .. wasn't it handled in time .. or was it shutdown .. 
or ...

I can't remember if this even happens on shutdown of the guest (and i think i 
should if it was).

However is there a small chance on a race on guest shutdown, when the guest 
doesn't 
disable the device properly it self on shutdown ?

(i ask that because HVM guests don't cleanup properly on shutdown, due to the
xenstore entry still being "initialized" instead of "connected", so on cleanup
the guest kernel reports "initialized != connected" and doesn't cleanup.
(and the xenstore entry being not set to connected is due to libxl not properly
setting the states).
 
--
Sander                                                              

> Jan




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