diff options
author | Greg Kurz <groug@kaod.org> | 2019-11-18 00:20:52 +0100 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2019-12-17 10:39:47 +1100 |
commit | 818a6d30e0011e7a9cf8b1d4a1d6f3255778e1d7 (patch) | |
tree | b42c95db953c12ab05eb67eb564f1fa012c895b7 /util/lockcnt.c | |
parent | e388d66b407366e09228fa60b783cea1ac828066 (diff) | |
download | qemu-818a6d30e0011e7a9cf8b1d4a1d6f3255778e1d7.zip qemu-818a6d30e0011e7a9cf8b1d4a1d6f3255778e1d7.tar.gz qemu-818a6d30e0011e7a9cf8b1d4a1d6f3255778e1d7.tar.bz2 |
spapr: Abort if XICS interrupt controller cannot be initialized
Failing to set any of the ICS property should really never happen:
- object_property_add_child() always succeed unless the child object
already has a parent, which isn't the case here obviously since the
ICS has just been created with object_new()
- the ICS has an "nr-irqs" property than can be set as long as the ICS
isn't realized
In both cases, an error indicates there is a bug in QEMU. Propagating the
error, ie. exiting QEMU since spapr_irq_init() is called with &error_fatal
doesn't make much sense. Abort instead. This is consistent with what is
done with XIVE : both qdev_create() and qdev_prop_set_uint32() abort QEMU
on error.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <157403285265.409804.8683093665795248192.stgit@bahia.lan>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'util/lockcnt.c')
0 files changed, 0 insertions, 0 deletions