On Sat, 18 Jul 2020 at 09:27, Liviu Ionescu <i...@livius.net> wrote: > For me it was difficult to draw a line of what initialisations should be done > in .instance_init and what in .realize, but given that .realise is called > when the whole hierarchy is ready, it might do links between objects, which > are not available when .instance_init is called.
Yeah, we have not been able as a project to come up with a nice rule for how to do this split. There are a few definite rules: * anything that can fail and return an error must go in realize (because instance_init has no failure-return mechanism) * anything you need to do to set up a QOM property on the object must go in instance_init (so that the property can be set by the user of the device object before realizing it) * anything that changes the state of the simulation must go in realize (some QMP monitor commands to introspect objects will do instance_init/look at object/delete) but a lot of things could validly go in either method, and we haven't set a convention for those cases. (There's a bunch of inconclusive discussions in the mailing list archives.) > A simple rule would be for .instance_init to ensure that all members have > default values and properties associated with them, and defer all functional > initialisations to .realize. Yeah, this is a reasonable default rule. Note that for a lot of device state struct members (where they correspond to guest registers state), you want to set their values in the device's reset method, not in instance_init or realize. That's because the guest-visible register state needs to be set back to its initial value on a system reset anyway, and QEMU guarantees that we will reset a device before first use. thanks -- PMM
