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.william...@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