[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC V1 04/14] accel: set accelerator and machine props earlier
From: |
Peter Xu |
Subject: |
Re: [RFC V1 04/14] accel: set accelerator and machine props earlier |
Date: |
Mon, 21 Oct 2024 12:20:51 -0400 |
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
Re: [RFC V1 04/14] accel: set accelerator and machine props earlier, Peter Xu, 2024/10/21
Re: [RFC V1 04/14] accel: set accelerator and machine props earlier, Paolo Bonzini, 2024/10/23
[RFC V1 02/14] accel: accel preinit function, Steve Sistare, 2024/10/17