[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.


Xen-devel mailing list



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