On 27/11/20 11:50, Igor Mammedov wrote:
it works in context of this series since+ qemu_init_board(); + qemu_create_cli_devices(); + qemu_machine_creation_done(); are called within the same command qmp_x_exit_preconfig, if preconfig is enabled we happen to call qmp_set_numa_node() and if (qdev_hotplug) {error} work as expected, since qemu_init_board() hasn't been called yet. but I'm thinking about what happens beyond this series, when we start splitting qmp_x_exit_preconfig() after this series on separate stages.
Ok, so that's the source of confusion. I don't think anymore that x-exit-preconfig should be split in separate stages; I'm not looking anymore at being able to do device-add from "qemu-system-x86_64 -preconfig". Instead, I'm looking at having a completely separate executable for QMP-only machine creation, which would not use vl.c command line parsing at all.
For this reason I've left MachinePhase to a separate series, which I still plan for 6.0. But I will add it here instead.
FWIW I intend to have four parts: 1) this 2) QemuOpts->keyval switch for -object/-M/-accel 3) making Machine's memdev property a link<memory-backend> 4) making -smp/-boot/-m sugar for non-scalar properties of Machine. I'll definitely need your review on part 3 too!
Thanks, Paolo
By using qdev_hotplug here, we practically loose dependency tracking on qemu_init_board() not being yet called. And if later we forget that, then it would allow to call qmp_set_numa_node() after qemu_init_board() but before qemu_machine_creation_done() So for this intermediate stage, instead of abusing qdev_hotplug adding a temporary is_board_created might be used. And when we introduce new phases you've described below, is_board_created could be replaced with appropriate phase check.
