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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

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 ?

--
Sander

> Jan




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