Re: [Qemu-devel] [PATCH for-2.12] hw/arm/allwinner-a10: Do not use nd_table in instance_init function

[Peter Maydell]

On 4 April 2018 at 18:20, Thomas Huth <address@hidden> 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 <address@hidden>
> ---
>  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