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
