All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Jan Beulich <JBeulich@suse.com>
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: dom0 kernel - irq nobody cared ... the continuing saga ..
Date: Tue, 10 Feb 2015 10:59:22 +0000	[thread overview]
Message-ID: <54D9E48A.9030502@citrix.com> (raw)
In-Reply-To: <1349522326.20150210114714@eikelenboom.it>

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@eikelenboom.it> 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

  parent reply	other threads:[~2015-02-10 10:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-09 15:03 dom0 kernel - irq nobody cared ... the continuing saga Sander Eikelenboom
2015-02-09 15:18 ` David Vrabel
2015-02-09 15:39   ` Sander Eikelenboom
2015-02-09 16:36   ` Jan Beulich
2015-02-09 17:13     ` Sander Eikelenboom
2015-02-10  8:48       ` Jan Beulich
2015-02-10  9:19         ` Sander Eikelenboom
2015-02-10  9:35           ` Jan Beulich
2015-02-10 10:03             ` Sander Eikelenboom
2015-02-10 10:36               ` Jan Beulich
2015-02-10 10:47                 ` Sander Eikelenboom
2015-02-10 10:57                   ` Jan Beulich
2015-02-10 10:59                   ` Andrew Cooper [this message]
2015-02-10 11:21                     ` Jan Beulich
2015-02-10 13:07             ` Sander Eikelenboom
2015-02-10 13:26               ` Jan Beulich
2015-02-10 15:35                 ` Sander Eikelenboom
2015-02-10 15:46                   ` Konrad Rzeszutek Wilk
2015-02-10 16:22                   ` Jan Beulich
2015-02-10 17:30                     ` Sander Eikelenboom
2015-02-10 17:47                       ` Jan Beulich
2015-02-10 18:26                         ` Sander Eikelenboom
2015-02-10 15:13               ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54D9E48A.9030502@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=david.vrabel@citrix.com \
    --cc=linux@eikelenboom.it \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.