Re: [Qemu-devel] [PATCH v7 1/4] hw/pci: introduce pcie-pci-bridge device

[Aleksandr Bezzubikov]

2017-09-20 17:02 GMT+03:00 Marcel Apfelbaum <address@hidden>:
> On 20/09/2017 16:57, Eduardo Habkost wrote:
>>
>> On Wed, Sep 20, 2017 at 09:52:01AM +0000, Aleksandr Bezzubikov wrote:
>>>
>>> ср, 20 сент. 2017 г. в 10:13, Marcel Apfelbaum <address@hidden>:
>>>
>>>> On 19/09/2017 23:34, Eduardo Habkost wrote:
>>>>>
>>>>> On Fri, Aug 18, 2017 at 02:36:47AM +0300, Aleksandr Bezzubikov wrote:
>>>>>>
>>>>>> Introduce a new PCIExpress-to-PCI Bridge device,
>>>>>> which is a hot-pluggable PCI Express device and
>>>>>> supports devices hot-plug with SHPC.
>>>>>>
>>>>>> This device is intended to replace the DMI-to-PCI Bridge.
>>>>>>
>>>>>> Signed-off-by: Aleksandr Bezzubikov <address@hidden>
>>>>>> Reviewed-by: Marcel Apfelbaum <address@hidden>
>>>>>
>>>>>
>>>>> It's possible to crash QEMU by instantiating this device, with;
>>>>>
>>>>>     $ qemu-system-ppc64 -machine prep -device pcie-pci-bridge
>>>>>     qemu-system-ppc64: qemu/memory.c:1533: memory_region_finalize:
>>>>
>>>> Assertion `!mr->container' failed.
>>>>>
>>>>>     Aborted
>>>>
>>>>
>>>> Hi Edurado,
>>>>
>>>>>
>>>>> I didn't investigate the root cause.
>>>>>
>>>>
>>>> Thanks for reporting it!
>>>> Aleksandr, can you have a look? Maybe we should not compile
>>>> the device for ppc arch. (x86 and arm is enough)
>>>
>>>
>>>
>>> I will see what can we do. Is x86 and arm really enough?
>>
>>
>> I would investigate the original cause before disabling the device on
>> other
>> architectures, as we could be hiding a bug that's also present in x86.
>
>
> Agreed, it worth finding out the reason. But the restriction
> still makes sense.
>
>
> Thanks,
> Marcel
>
>
>   The
>>
>> backtrace looks like broken error handling logic somewhere:
>>
>> #0  0x00007fffea9ff1f7 in __GI_raise (address@hidden) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>> #1  0x00007fffeaa008e8 in __GI_abort () at abort.c:90
>> #2  0x00007fffea9f8266 in __assert_fail_base (fmt=0x7fffeab4ae68
>> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
>> address@hidden "!mr->container",
>> address@hidden "/root/qemu/memory.c", address@hidden,
>> address@hidden <__PRETTY_FUNCTION__.28908>
>> "memory_region_finalize") at assert.c:92
>> #3  0x00007fffea9f8312 in __GI___assert_fail
>> (address@hidden "!mr->container",
>> address@hidden "/root/qemu/memory.c", address@hidden,
>> address@hidden <__PRETTY_FUNCTION__.28908>
>> "memory_region_finalize") at assert.c:101
>> #4  0x00005555557ff2df in memory_region_finalize (obj=<optimized out>) at
>> /root/qemu/memory.c:1533
>> #5  0x0000555555ae77a2 in object_unref (type=<optimized out>,
>> obj=0x555557c00d80) at /root/qemu/qom/object.c:453
>> #6  0x0000555555ae77a2 in object_unref (data=0x555557c00d80) at
>> /root/qemu/qom/object.c:467
>> #7  0x0000555555ae77a2 in object_unref (obj=0x555557c00d80) at
>> /root/qemu/qom/object.c:902
>> #8  0x0000555555ae67d7 in object_property_del_child (obj=0x555557ab6500,
>> address@hidden, errp=0x0) at /root/qemu/qom/object.c:427
>> #9  0x0000555555ae6ff4 in object_unparent (address@hidden)
>> at /root/qemu/qom/object.c:446
>> #10 0x0000555555a1c94e in shpc_free (address@hidden) at
>> /root/qemu/hw/pci/shpc.c:676
>> #11 0x0000555555a12560 in pcie_pci_bridge_realize (d=0x555557ab6500,
>> errp=0x7fffffffd530) at /root/qemu/hw/pci-bridge/pcie_pci_bridge.c:84
>> #12 0x0000555555a18d07 in pci_qdev_realize (qdev=0x555557ab6500,
>> errp=0x7fffffffd5d0) at /root/qemu/hw/pci/pci.c:2024
>> #13 0x00005555559b53aa in device_set_realized (obj=<optimized out>,
>> value=<optimized out>, errp=0x7fffffffd708) at /root/qemu/hw/core/qdev.c:914
>> #14 0x0000555555ae62fe in property_set_bool (obj=0x555557ab6500,
>> v=<optimized out>, name=<optimized out>, opaque=0x555557ab7b30,
>> errp=0x7fffffffd708) at /root/qemu/qom/object.c:1886
>> #15 0x0000555555aea3ef in object_property_set_qobject
>> (address@hidden, address@hidden,
>> address@hidden "realized", address@hidden)
>> at /root/qemu/qom/qom-qobject.c:27
>> #16 0x0000555555ae80a0 in object_property_set_bool (obj=0x555557ab6500,
>> value=<optimized out>, name=0x555555c4f217 "realized", errp=0x7fffffffd708)
>> at /root/qemu/qom/object.c:1162
>> #17 0x0000555555949824 in qdev_device_add (opts=0x5555567795b0,
>> address@hidden) at /root/qemu/qdev-monitor.c:630
>> #18 0x000055555594be87 in device_init_func (opaque=<optimized out>,
>> opts=<optimized out>, errp=<optimized out>) at /root/qemu/vl.c:2418
>> #19 0x0000555555bc85ba in qemu_opts_foreach (list=<optimized out>,
>> address@hidden <device_init_func>, address@hidden,
>> address@hidden) at /root/qemu/util/qemu-option.c:1104
>> #20 0x000055555579f497 in main (argc=<optimized out>, argv=<optimized
>> out>, envp=<optimized out>) at /root/qemu/vl.c:4745
>> (gdb) fr 11
>> #11 0x0000555555a12560 in pcie_pci_bridge_realize (d=0x555557ab6500,
>> errp=0x7fffffffd530) at /root/qemu/hw/pci-bridge/pcie_pci_bridge.c:84
>> 84          shpc_free(d);
>> (gdb) l
>> 79          pcie_aer_exit(d);
>> 80      aer_error:
>> 81      pm_error:
>> 82          pcie_cap_exit(d);
>> 83      cap_error:
>> 84          shpc_free(d);
>> 85      error:
>> 86          pci_bridge_exitfn(d);
>> 87      }
>> 88
>> (gdb)
>>
>>
>

I've discovered the root cause of the problem - MSI is not supported
by interrupt controller in 'prep' ppc64 machine,
and then it seems that shpc_free is definitely not the right function
to be used in this case. I suppose shpc_cleanup should be used there,
I'll submit a patch to fix that.


-- 
Aleksandr Bezzubikov