On 4 April 2018 at 18:20, Thomas Huth <th...@redhat.com> wrote: > The instance_init function of a device can be called at any time, even > if the device is not going to be used (i.e. not going to be realized). > So a instance_init function must not do things that could cause QEMU > to exit, like calling qemu_check_nic_model(&nd_table[0], ...) for example. > But this is what the instance_init function of the allwinner-a10 device > is currently doing - and this causes QEMU to quit unexpectedly when > you run the 'device-list-properties' QMP command for example: > > $ echo "{'execute':'qmp_capabilities'}"\ > "{'execute':'device-list-properties',"\ > " 'arguments':{'typename':'allwinner-a10'}}" \ > | arm-softmmu/qemu-system-arm -M mps2-an505,accel=qtest -qmp stdio > {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, > "package": "build-all"}, "capabilities": []}} > {"return": {}} > Unsupported NIC model: lan9118 > > ... and QEMU quits after printing the last line (which should not happen > just because of running 'device-list-properties' here). > > And with the cubieboard, this even causes QEMU to abort(): > > $ echo "{'execute':'qmp_capabilities'}"\ > "{'execute':'device-list-properties',"\ > " 'arguments':{'typename':'allwinner-a10'}}" \ > | arm-softmmu/qemu-system-arm -M cubieboard,accel=qtest -qmp stdio > {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, > "package": "build-all"}, "capabilities": []}} > {"return": {}} > Unexpected error in error_set_from_qdev_prop_error() at > hw/core/qdev-properties.c:1095: > Property 'allwinner-emac.netdev' can't take value 'hub0port0', it's in use > Aborted (core dumped) > > To fix the problem we've got to move the offending code to the realize > function instead. > > Signed-off-by: Thomas Huth <th...@redhat.com> > --- > I know, an even cleaner fix would likely be to remove serial_hds and > nd_table from the device completely and wire it up from the board code > instead - but that's a major rework compared to this simple fix here, > which we likely should avoid at this point in time of the hard freeze > period. >
Applied to target-arm.next, thanks. -- PMM