On Wed, 8 Jul 2020 10:03:47 +0200 Thomas Huth <[email protected]> wrote:
> > Hi, > > qemu-system-ppc64 currently abort()s when it is started with a pcie > bridge device: > > $ qemu-system-ppc64 -M pseries-5.1 -device pcie-pci-bridge > Unexpected error in object_property_find() at qom/object.c:1240: > qemu-system-ppc64: -device pcie-pci-bridge: Property '.chassis_nr' not found > Aborted (core dumped) > > or: > > $ qemu-system-ppc64 -M pseries -device dec-21154-p2p-bridge > Unexpected error in object_property_find() at qom/object.c:1240: > qemu-system-ppc64: -device dec-21154-p2p-bridge: Property '.chassis_nr' > not found > Aborted (core dumped) > > That's kind of ugly, and it shows up as error when running > scripts/device-crash-test. Is there an easy way to avoid the abort() and > fail more gracefully here? > And even worse, this can tear down a running guest with hotplug :\ (qemu) device_add pcie-pci-bridge Unexpected error in object_property_find() at /home/greg/Work/qemu/qemu-ppc/qom/object.c:1240: Property '.chassis_nr' not found Aborted (core dumped) This is caused by recent commit: commit 7ef1553dac8ef8dbe547b58d7420461a16be0eeb Author: Markus Armbruster <[email protected]> Date: Tue May 5 17:29:25 2020 +0200 spapr_pci: Drop some dead error handling chassis_from_bus() uses object_property_get_uint() to get property "chassis_nr" of the bridge device. Failure would be a programming error. Pass &error_abort, and simplify its callers. Cc: David Gibson <[email protected]> Cc: [email protected] Signed-off-by: Markus Armbruster <[email protected]> Acked-by: David Gibson <[email protected]> Reviewed-by: Greg Kurz <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Paolo Bonzini <[email protected]> Message-Id: <[email protected]> Before that, we would simply print the "chassir_nr not found" error, and in case of a cold plugged device exit. The root cause is that the sPAPR PCI code assumes that a PCI bridge has a "chassir_nr" property, ie. it is a standard PCI bridge. Other PCI bridge types don't have that. Not sure yet why this information is required, I'll check LoPAPR. In the meantime, since we're in soft freeze, I guess we should revert Markus's patch and add a big fat comment to explain what's going on and maybe change the error message to something more informative, eg. "PCIE-to-PCI bridges are not supported". Thoughts ? > Thomas >
