ioh3420: Add a map_irq function

Every bridge needs to know how to map IRQs from it's secondary bus to
the primary bus.  We seem to be direct mapped on ioh3420.  This avoids
segfaults when trying to put assigned devices behind root ports.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
 hw/ioh3420.c |    7 +++++++
 1 file changed, 7 insertions(+)

On 02/28/2013 10:49 AM, Alex Williamson wrote:
> Every bridge needs to know how to map IRQs from it's secondary bus to
> the primary bus.  We seem to be direct mapped on ioh3420.  This avoids
> segfaults when trying to put assigned devices behind root ports.
> 
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> 
> ---
> hw/ioh3420.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/hw/ioh3420.c b/hw/ioh3420.c
> index 95bceb5..6ac4fe7 100644
> --- a/hw/ioh3420.c
> +++ b/hw/ioh3420.c
> @@ -90,6 +90,11 @@ static void ioh3420_reset(DeviceState *qdev)
>      pci_bridge_disable_base_limit(d);
>  }
>  
> +static int ioh3420_map_irq(PCIDevice *pci_dev, int irq_num)
> +{
> +    return irq_num;
> +}
> +
>  static int ioh3420_initfn(PCIDevice *d)
>  {
>      PCIBridge* br = DO_UPCAST(PCIBridge, dev, d);
> @@ -97,6 +102,8 @@ static int ioh3420_initfn(PCIDevice *d)
>      PCIESlot *s = DO_UPCAST(PCIESlot, port, p);
>      int rc;
>  
> +    pci_bridge_map_irq(br, NULL, ioh3420_map_irq);
> +
>      rc = pci_bridge_initfn(d);
>      if (rc < 0) {
>          return rc;
> 

What became of this patch?  I believe I am seeing the issue described
when I assign a MSI-X capable virtual device to the secondary bus of an
ioh3420, and applying this patch seems to resolve the issue.  Was there
an alternate patch proposed and if so where can I find it?

Thanks,

Alex

On Fri, 2013-09-27 at 15:10 -0700, Alexander Duyck wrote:
> On 02/28/2013 10:49 AM, Alex Williamson wrote:
> > Every bridge needs to know how to map IRQs from it's secondary bus to
> > the primary bus.  We seem to be direct mapped on ioh3420.  This avoids
> > segfaults when trying to put assigned devices behind root ports.
> > 
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > 
> > ---
> > hw/ioh3420.c |    7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/hw/ioh3420.c b/hw/ioh3420.c
> > index 95bceb5..6ac4fe7 100644
> > --- a/hw/ioh3420.c
> > +++ b/hw/ioh3420.c
> > @@ -90,6 +90,11 @@ static void ioh3420_reset(DeviceState *qdev)
> >      pci_bridge_disable_base_limit(d);
> >  }
> >  
> > +static int ioh3420_map_irq(PCIDevice *pci_dev, int irq_num)
> > +{
> > +    return irq_num;
> > +}
> > +
> >  static int ioh3420_initfn(PCIDevice *d)
> >  {
> >      PCIBridge* br = DO_UPCAST(PCIBridge, dev, d);
> > @@ -97,6 +102,8 @@ static int ioh3420_initfn(PCIDevice *d)
> >      PCIESlot *s = DO_UPCAST(PCIESlot, port, p);
> >      int rc;
> >  
> > +    pci_bridge_map_irq(br, NULL, ioh3420_map_irq);
> > +
> >      rc = pci_bridge_initfn(d);
> >      if (rc < 0) {
> >          return rc;
> > 
> 
> What became of this patch?  I believe I am seeing the issue described
> when I assign a MSI-X capable virtual device to the secondary bus of an
> ioh3420, and applying this patch seems to resolve the issue.  Was there
> an alternate patch proposed and if so where can I find it?

Hmm, I thought it was no longer necessary with
pci_device_route_intx_to_irq(), especially if you're assigning a VF that
doesn't support INTx.  Are you using the latest qemu bits?  pci-assign
or vfio-pci?  Maybe provide a backtrace?  Thanks,

Alex

On 10/02/2013 10:12 AM, Alex Williamson wrote:
> On Fri, 2013-09-27 at 15:10 -0700, Alexander Duyck wrote:
>> On 02/28/2013 10:49 AM, Alex Williamson wrote:
>>> Every bridge needs to know how to map IRQs from it's secondary bus to
>>> the primary bus.  We seem to be direct mapped on ioh3420.  This avoids
>>> segfaults when trying to put assigned devices behind root ports.
>>>
>>> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>>>
>>> ---
>>> hw/ioh3420.c |    7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/hw/ioh3420.c b/hw/ioh3420.c
>>> index 95bceb5..6ac4fe7 100644
>>> --- a/hw/ioh3420.c
>>> +++ b/hw/ioh3420.c
>>> @@ -90,6 +90,11 @@ static void ioh3420_reset(DeviceState *qdev)
>>>      pci_bridge_disable_base_limit(d);
>>>  }
>>>  
>>> +static int ioh3420_map_irq(PCIDevice *pci_dev, int irq_num)
>>> +{
>>> +    return irq_num;
>>> +}
>>> +
>>>  static int ioh3420_initfn(PCIDevice *d)
>>>  {
>>>      PCIBridge* br = DO_UPCAST(PCIBridge, dev, d);
>>> @@ -97,6 +102,8 @@ static int ioh3420_initfn(PCIDevice *d)
>>>      PCIESlot *s = DO_UPCAST(PCIESlot, port, p);
>>>      int rc;
>>>  
>>> +    pci_bridge_map_irq(br, NULL, ioh3420_map_irq);
>>> +
>>>      rc = pci_bridge_initfn(d);
>>>      if (rc < 0) {
>>>          return rc;
>>>
>> What became of this patch?  I believe I am seeing the issue described
>> when I assign a MSI-X capable virtual device to the secondary bus of an
>> ioh3420, and applying this patch seems to resolve the issue.  Was there
>> an alternate patch proposed and if so where can I find it?
> Hmm, I thought it was no longer necessary with
> pci_device_route_intx_to_irq(), especially if you're assigning a VF that
> doesn't support INTx.  Are you using the latest qemu bits?  pci-assign
> or vfio-pci?  Maybe provide a backtrace?  Thanks,
>
> Alex

I'm seeing it with an emulated interface using MSI-X, not with a VF or
assigned device.

I'll try to get you a backtrack when I have some time.  I'm currently
chasing down another issue and will try to remember to follow up on this
one.

Thanks,

Alex