All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.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: Thu, 20 Jun 2013 15:33:14 +0200	[thread overview]
Message-ID: <20130620133314.GR2575@8bytes.org> (raw)
In-Reply-To: <1368086982.25488.165.camel@pasglop>

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

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


	Joerg



  reply	other threads:[~2013-06-20 13:33 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 [this message]
2013-06-20 21:40   ` Benjamin Herrenschmidt

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=20130620133314.GR2575@8bytes.org \
    --to=joro@8bytes.org \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --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 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.