[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] dom0 kernel - irq nobody cared ... the continuing saga ..
On 10/02/15 10:47, Sander Eikelenboom wrote: > Tuesday, February 10, 2015, 11:36:48 AM, you wrote: > >>>>> On 10.02.15 at 11:03, <linux@xxxxxxxxxxxxxx> wrote: >>> Tuesday, February 10, 2015, 10:35:36 AM, you wrote: >>>> 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 ... >> No - such a shared IRQ gets sent to both domains. There's no notion >> of one domain claiming it and the other then not seeing it, as any >> instance of the interrupt may mean more than one of the devices >> signaled it - remember that shared interrupts are always level >> triggered, i.e. there is no way of telling how many devices request >> servicing. > Ok .. just thinking out loud .. > > But how would that work then ? > If the interrupt gets always sent to both domains > and > there is no handler for it in dom0 > > Wouldn't that then *always* cause a "irq nobody cared" .. > unless it's masked ? > > And if so .. wouldn't that imply that since i sometimes (but not always) > get the "irq nobody cared", that it is unmasked at some point in time ? > > And if so .. is there a way to detect that it's get unmasked ? Xen should only deliver the interrupt to domains which have a device on the appropriate line. In this case there are two devices using the line, one with no driver and one passed through. In the case of passthrough, the device is actually in a hybrid state in both dom0 and domU (with both having actual access), which means line level interrupts will be delivered to both domains. I presume the irq handler pciback registers will not claim the line level interrupts, as it cant know for certain whether the interrupt was for the passed-through device. This in turn will (presumably) cause the dom0 kernel to declare that nobody cared. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |