[Qemu-devel] [PATCH] pci: Don't call pci_irq_handler() for a negative intx

[Qemu-devel] [PATCH] pci: Don't call pci_irq_handler() for a negative intx

[Benjamin Herrenschmidt]

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>
---
 hw/pci/pci.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 8185bbc..eea6f5d 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1281,7 +1281,9 @@ qemu_irq pci_allocate_irq(PCIDevice *pci_dev)
 void pci_set_irq(PCIDevice *pci_dev, int level)
 {
     int intx = pci_intx(pci_dev);
-    pci_irq_handler(pci_dev, intx, level);
+    if (intx >= 0) {
+        pci_irq_handler(pci_dev, intx, level);
+    }
 }
 
 /* Special hooks used by device assignment */

Re: [Qemu-devel] [PATCH] pci: Don't call pci_irq_handler() for a negative intx

[Michael S. Tsirkin]

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?

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.

> ---
>  hw/pci/pci.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 8185bbc..eea6f5d 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -1281,7 +1281,9 @@ qemu_irq pci_allocate_irq(PCIDevice *pci_dev)
>  void pci_set_irq(PCIDevice *pci_dev, int level)
>  {
>      int intx = pci_intx(pci_dev);
> -    pci_irq_handler(pci_dev, intx, level);
> +    if (intx >= 0) {
> +        pci_irq_handler(pci_dev, intx, level);
> +    }
>  }
>  
>  /* Special hooks used by device assignment */
> 

Re: [Qemu-devel] [PATCH] pci: Don't call pci_irq_handler() for a negative intx

[Benjamin Herrenschmidt]

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.

[Qemu-devel] [PATCH] pci: Don't call pci_irq_handler() for a negative intx

[Cédric Le Goater]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

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>
[clg: updated for qemu-2.9 ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/pci/pci.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Index: qemu-powernv-2.9.git/hw/pci/pci.c
===================================================================
--- qemu-powernv-2.9.git.orig/hw/pci/pci.c
+++ qemu-powernv-2.9.git/hw/pci/pci.c
@@ -1419,7 +1419,9 @@ qemu_irq pci_allocate_irq(PCIDevice *pci
 void pci_set_irq(PCIDevice *pci_dev, int level)
 {
     int intx = pci_intx(pci_dev);
-    pci_irq_handler(pci_dev, intx, level);
+    if (intx >= 0) {
+        pci_irq_handler(pci_dev, intx, level);
+    }
 }
 
 /* Special hooks used by device assignment */