From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Joerg Roedel <joro@8bytes.org>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Masked MSIs expectations
Date: Fri, 21 Jun 2013 07:40:35 +1000 [thread overview]
Message-ID: <1371764435.3944.30.camel@pasglop> (raw)
In-Reply-To: <20130620133314.GR2575@8bytes.org>
On Thu, 2013-06-20 at 15:33 +0200, Joerg Roedel wrote:
> (In case this topic is still relevant)
>
> On Thu, May 09, 2013 at 06:09:42PM +1000, Benjamin Herrenschmidt wrote:
> > Do we provide drivers any guarantee to what happen if an MSI is shot
> > while masked with disable_irq() or while not yet request_irq()'ed ?
> >
> > Do we guarantee delivery (latched while masked), non-delivery, or
> > undefined ?
>
> I am not aware of any guarantees the kernel gives in this situation. I
> think it would just drop the IRQ and print a "nobody cared" message.
Well, I was not necessarily talking about the kernel reaction here, my
statement was high level, it could be that the interrupt controller
latches it and "shoots" it as soon as enabled for example in some cases,
or drops it in others.
Also we wouldn't print a message in the kernel, we "lazy disable" edge
interrupts, so we would just drop it.
> > I'm bringing up a piece of HW where if it happened, it won't be
> > automatically sent to the CPU and can block further MSIs unless I
> > explicitly either ditch it or force a resend when unmasking (at the PCI
> > Express controller PIC level).
> >
> > I'm tempted to just ditch anything that happened while masked, it would
> > make everything easier on my side, but maybe drivers have different
> > expectations (and of course an LSI would still shoot, that's not an
> > issue, only MSIs are in question here).
> >
> > I have cases of devices continuing to shoot one or two MSIs after kexec
> > and before the new kernel takes over, causing a "loss" of any subsequent
> > one unless I deal with that case one way or another.
>
> I would also just ditch such IRQs that happen in that kexec case and
> make sure that they will work again when the kexec-kernel device driver
> wants to initialize them.
Yes, in the kexec case it sounds obvious to just ditch anything, but I
wanted to make sure of the general idea, ie, if the driver temporarily
does disable_irq()/enable_irq() I can potentially ditch them all too,
rather than "latch" them.
Anyway, I've done that, so far so good.
Cheers,
Ben.
> Joerg
>
prev parent reply other threads:[~2013-06-20 21:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-09 8:09 Masked MSIs expectations Benjamin Herrenschmidt
2013-06-20 13:33 ` Joerg Roedel
2013-06-20 21:40 ` Benjamin Herrenschmidt [this message]
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=1371764435.3944.30.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).