On Fri, Oct 18, 2024 at 03:15:56PM -0400, Steven Sistare wrote: > I understand this now. The old code worked in this order: > > qemu_create_early_backends() > ... creates "-object can-bus,id=canbus" > qemu_create_machine() > qemu_apply_machine_options() > applies link property "canbus0" with value canbus, finds canbus object > > The new code fails: > > qemu_create_machine() > qemu_apply_machine_options() > applies link property "canbus0" with value canbus, > error because fails to find canbus object > ... > qemu_exit_precreate() > qemu_create_early_backends() > ... creates "-object can-bus,id=canbus" > > The fix is to provide a new function, called before qemu_create_machine, > which creates only the backends that are needed to create the machine. > AFAIK can-bus is the only one, because the xlnx-zcu102 machine has > link properties.
Wanna share more on the specific solution? I wonder if the plan is to add one more special window for creating -object just for can-bus, and how to justify that extra phase. Perhaps whatever that do not require fd to back it (so not affected by CPR)? But not sure whether that's too special. I wished it could be simply put into the "very early" stage (pre-sandbox), but I think object_create_pre_sandbox() did mention that we need explicit reasons for those, and I'm not sure whether this reason justifies either for why can-bus is so special so can be created without the sandboxing. -- Peter Xu
