public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: David Vrabel <david.vrabel@csr.com>
Cc: Kernel development list <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: PCI: MSI interrupts masked using prohibited method
Date: Fri, 27 Jun 2008 10:07:25 -0700	[thread overview]
Message-ID: <200806271007.26248.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <4864DA54.6000205@csr.com>

On Friday, June 27, 2008 5:17 am David Vrabel wrote:
> Jesse Barnes wrote:
> > On Tuesday, June 24, 2008 3:46 am David Vrabel wrote:
> >> PCI MSI interrupts are masked and unmasked using a method (by writing
> >> the MSI Enable capability bit) that is prohibited by the PCI
> >> specification.
> >
> > Yeah, it's probably quite a bit slower too (I assume you're talking about
> > io_apic_64's msi_mask_irq).  Seems like masking this at the ioapic level
> > would make more sense anyway...
> >
> >> This behaviour can cause missed interrupts with some devices if the
> >> interrupt is asserted by the hardware while MSI is disabled.
> >>
> >> I believe the interrupt should be masked/unmasked on the interrupt
> >> controller (the APIC on x86, for example).   I'm going to test this now
> >> and see if it works.
>
> After further research it seems that MSI interrupts aren't routed via
> the IO-APIC, so this cannot be done.
>
> I think the only solution is to not perform any sort of masking and rely
> on the device driver being able to handle this.

On x86, they're targetted at the LAPIC block (see section 8 of the IA SDM); 
maybe we could modify the message address or data such that it won't generate 
an interrupt instead?  I think this latest approach is correct in the sense 
that both the system and drivers have to take care that
  1) we don't miss interrupts, and 
  2) we don't generate spurious unhandled interrupts (as might happen if we 
disable MSI and the device generates a legacy IRQ on a different vector).

But it looks like the real problem is in the system interrupt code that 
handles MSIs.  We should only be disabling MSIs using the capability bit at 
device enable or disable time, not during the normal course of interrupt 
handling, since if we do we may miss device interrupts or have them routed to 
the wrong (legacy) vector.

Cc'ing Ingo & Thomas since they know the core interrupt code pretty well.

Jesse

  reply	other threads:[~2008-06-27 17:08 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-24 10:46 PCI: MSI interrupts masked using prohibited method David Vrabel
2008-06-25 21:20 ` Jesse Barnes
2008-06-27 12:17   ` David Vrabel
2008-06-27 17:07     ` Jesse Barnes [this message]
2008-07-16 19:43       ` Jesse Barnes
2008-07-16 19:58         ` Matthew Wilcox
2008-07-16 20:35           ` David Miller
2008-07-17 12:16           ` Krzysztof Halasa
2008-07-17 12:43             ` Matthew Wilcox
2008-07-17 13:14           ` David Vrabel
2008-07-17 15:39             ` Matthew Wilcox
2008-07-17 15:58               ` Thomas Gleixner
2008-07-17 16:11                 ` Matthew Wilcox
2008-07-17 17:04                   ` Thomas Gleixner
2008-07-17 16:56                 ` Matthew Wilcox
     [not found]                   ` <487F7DFA.10101@csr.com>
2008-07-17 19:48                     ` Matthew Wilcox
2008-07-18 10:33                       ` David Vrabel
2008-07-22 13:56                         ` Michal Schmidt
2008-07-22 17:52                           ` Jesse Barnes
2008-07-23 13:02                             ` Michal Schmidt
2008-07-25 13:29                             ` Michal Schmidt
2008-07-25 13:42                               ` Matthew Wilcox
2008-07-25 13:53                                 ` Michal Schmidt
2008-07-25 15:51                                   ` Matthew Wilcox
2008-07-28  9:54                                     ` Michal Schmidt
2008-07-25 16:37                                   ` David Vrabel
2008-07-25 16:56                                     ` Matthew Wilcox
2008-07-25 19:12                                       ` Jesse Barnes
2008-07-28  9:59                                       ` Michal Schmidt
2008-07-28 22:04                                         ` Jesse Barnes

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=200806271007.26248.jbarnes@virtuousgeek.org \
    --to=jbarnes@virtuousgeek.org \
    --cc=david.vrabel@csr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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