mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-pci@atrey.karlin.mff.cuni.cz,
	Greg Kroah-Hartman <greg@kroah.com>,
	"David S. Miller" <davem@davemloft.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	daniel.e.wolstenholme@intel.com
Subject: Re: [PATCH 13/21] MSI: Do MSI masking in the arch code
Date: Thu, 29 Mar 2007 18:58:40 +1000	[thread overview]
Message-ID: <1175158720.16660.69.camel@concordia.ozlabs.ibm.com> (raw)
In-Reply-To: <m1y7lhrhwm.fsf@ebiederm.dsl.xmission.com>

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

On Wed, 2007-03-28 at 00:39 -0600, Eric W. Biederman wrote:
> Michael Ellerman <michael@ellerman.id.au> writes:
> 
> > It's an arch detail whether MSI irqs need to be masked using the PCI
> > MSI registers.
> 
> Agreed.  It isn't an arch detail that they need to be unmasked in
> the pci configuration space.
> 
> I assume this patch is motivated just to make arch support easier
> and not for RTAS compatibility reason.
> 
> > This changes behaviour in that previously we unconditionally masked
> > all MSIs, eventhough we only ever enable one, whereas now we only
> > mask the irqs we're using.
> >
> > To be super paranoid I have the archs mask the irq before they write
> > the msi message, just in case the device doesn't respect the MSI enable
> > bit or MSI is already enabled or something else crazy.
> >
> > For MSI-X this might mean we mask the already masked MSI-X on the device,
> > but that should be harmless.
> 
> I don't think this patch really makes sense.  I think we should mask
> all possible vectors for msi and msi-x initially in the generic code
> and then unmask them.
> 
> If we were trying to support Dave Miller's example of hypervisors
> that don't let us touch the msi registers I think there would be a
> point.  As it is I think this just makes the code more brittle.

The main motivation was to have the arch in control of as much direct
register writing as possible. Even though our HV does allow us to write
to config space, it's not obviously safe for Linux to be flipping bits
and also calling the HV to configure things. What's worse, I don't have
hardware that supports the mask bits, so I can't test it.

I also thought this would save me from having custom MSI irq_chips for
the powerpc backends. But I think I need them now anyway, so I guess
that's not a concern.

So I guess we'll drop this one, although I might try and tidy up the
implementation of "mask all MSIs" in msi_capability_init() as another
patch.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-03-29  8:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070322105342.B8317DDF6A@ozlabs.org>
2007-03-28  6:39 ` Eric W. Biederman
2007-03-29  8:58   ` Michael Ellerman [this message]
2007-03-29 13:31     ` Eric W. Biederman

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=1175158720.16660.69.camel@concordia.ozlabs.ibm.com \
    --to=michael@ellerman.id.au \
    --cc=akpm@osdl.org \
    --cc=benh@kernel.crashing.org \
    --cc=daniel.e.wolstenholme@intel.com \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    /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

all inboxes | Powered by JetHome®