linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Bharat Kumar Gogada <bharatku@xilinx.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ravikiran Gummaluri <rgummal@xilinx.com>
Subject: Re: [PATCH v3] PCI: xilinx-nwl: Fix Multi MSI data programming
Date: Mon, 10 Jun 2019 11:27:16 +0100	[thread overview]
Message-ID: <20190610102716.GD25976@redmoon> (raw)
In-Reply-To: <86lfyfgp1a.wl-marc.zyngier@arm.com>

On Thu, Jun 06, 2019 at 08:18:25AM +0100, Marc Zyngier wrote:
> On Thu, 06 Jun 2019 05:49:45 +0100,
> Bharat Kumar Gogada <bharatku@xilinx.com> wrote:
> > 
> > > On 31/05/2019 17:09, Lorenzo Pieralisi wrote:
> > > > [+Marc]
> > > >
> > > > On Wed, May 29, 2019 at 06:07:49PM +0530, Bharat Kumar Gogada wrote:
> > > >> The current Multi MSI data programming fails if multiple end points
> > > >> requesting MSI and multi MSI are connected with switch, i.e the
> > > >> current multi MSI data being given is not considering the number of
> > > >> vectors being requested in case of multi MSI.
> > > >> Ex: Two EP's connected via switch, EP1 requesting single MSI first,
> > > >> EP2 requesting Multi MSI of count four. The current code gives MSI
> > > >> data 0x0 to EP1 and 0x1 to EP2, but EP2 can modify lower two bits due
> > > >> to which EP2 also sends interrupt with MSI data 0x0 which results in
> > > >> always invoking virq of EP1 due to which EP2 MSI interrupt never gets
> > > >> handled.
> > > >
> > > > If this is a problem it is not the only driver where it should be
> > > > fixed it seems. CC'ed Marc in case I have missed something in relation
> > > > to MSI IRQs but AFAIU it looks like HW is allowed to toggled bits
> > > > (according to bits[6:4] in Message Control for MSI) in the MSI data,
> > > > given that the data written is the hwirq number (in this specific MSI
> > > > controller) it ought to be fixed.
> > > 
> > > Yeah, it looks like a number of MSI controllers could be quite broken in this
> > > particular area.
> > > 
> > > >
> > > > The commit log and patch should be rewritten (I will do that) but
> > > > first I would like to understand if there are more drivers to be
> > > > updated.
> > > >
> > > > 
> > Hi Lorenzo and Marc, thanks for your time.
> > Marc, I'm yet to test the below suggested solution,
> > GIC v2m and GIC v3 supports multi MSI, do we see above issue in
> > these MSI controllers ?
> 
> To the best of my knowledge, these drivers do support MultiMSI
> correctly. GICv2m actually gained the support pretty recently (see
> de337ee30142). The GICv3 ITS never ha an issue with that, given that
> per device EventIDs are always 0-based.

AFAIU I think the issues is only present in controllers that use the
hwirq as MSI data and bitmap allocation that is not a power of two and
that's what Marc suggested as fix. There is still some chasing to do to
fix other MSI controllers in the kernel where this subtle issue went
undetected (and the driver has the same bitmap allocation issues as
this one).

@Bharat, please test Marc's patch and post it on completion, I will
rewrite your commit log because I want it to be clear so that we
have a reference to the issue linked to the specs.

Thanks,
Lorenzo

      reply	other threads:[~2019-06-10 10:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 12:37 [PATCH v3] PCI: xilinx-nwl: Fix Multi MSI data programming Bharat Kumar Gogada
2019-05-31 16:09 ` Lorenzo Pieralisi
2019-06-03  8:49   ` Marc Zyngier
2019-06-06  4:49     ` Bharat Kumar Gogada
2019-06-06  7:18       ` Marc Zyngier
2019-06-10 10:27         ` Lorenzo Pieralisi [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=20190610102716.GD25976@redmoon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=bharatku@xilinx.com \
    --cc=bhelgaas@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=rgummal@xilinx.com \
    /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).