From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35917)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1ZBetX-0002DC-5y
	for qemu-devel@nongnu.org; Sun, 05 Jul 2015 04:03:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1ZBetT-0006zO-7y
	for qemu-devel@nongnu.org; Sun, 05 Jul 2015 04:03:23 -0400
Received: from gate.crashing.org ([63.228.1.57]:39172)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1ZBetS-0006yl-Vt
	for qemu-devel@nongnu.org; Sun, 05 Jul 2015 04:03:19 -0400
Message-ID: <1436083393.3948.52.camel@kernel.crashing.org>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sun, 05 Jul 2015 18:03:13 +1000
In-Reply-To: <20150705084150-mutt-send-email-mst@redhat.com>
References: <1436052508.3948.41.camel@kernel.crashing.org>
	<20150705084150-mutt-send-email-mst@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] pci: Don't call pci_irq_handler() for a
	negative intx
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, Marcel Apfelbaum <marcel.a@redhat.com>

On Sun, 2015-07-05 at 09:03 +0200, Michael S. Tsirkin wrote:
> On Sun, Jul 05, 2015 at 09:28:28AM +1000, Benjamin Herrenschmidt wrote:
> > Under some circumstances, pci_intx() can return -1 (when the interrupt
> > pin in the config space is 0 which normally means no interrupt).
> > 
> > I have seen cases of pci_set_irq() being called on such devices, in
> > turn causing pci_irq_handler() to be called with "-1" as an argument
> > which doesn't seem like a terribly good idea.
> > 
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> 
> Isn't this a device bug though?

Possibly, I can try to dig a bit more see if I can reproduce and find
out who is causing it.

> I did a grep over all callers of pci_set_irq and didn't
> find any that fails to set an interrupt pin.
> 
> So how about an assert instead?
> 
> And maybe stick it in pci_intx to make sure all callers
> get checked.

Ok, It's also possible that this doesn't happen anymore, I've carried
that patch for monthes and rebased several times on top of newer qemu's.

I *think* it might have been something that happens due to some generic
code initializations, something like pci_update_irq_disabled() in
pci_default_write_config()... I'll dbl check.

Cheers,
Ben.