qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]