On 10/21/24 18:20, Peter Xu wrote:
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.
Unfortunately, I don't think there's _anything_ that can justify an
extra phase of command line processing. The only sensible way to do
precreate is to get rid of as much as possible of the command line.
There is an old thread explaining what was fixed in preconfig in 2022
and what was missing. Start here:
https://patchew.org/QEMU/b31f442d28920447690a6b8cee865bdbacde1283.1635160056.git.mpriv...@redhat.com/#7f54174b-4f90-13bf-6905-6febb6203...@redhat.com
Already there I wrote "one thing I don't like of preconfig is that command line
arguments linger until they are triggered by x-exit-preconfig".
Paolo
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.
