Re: [Qemu-devel] reset strategy?

[Liviu Ionescu]

> On 27 Jun 2015, at 21:03, Peter Crosthwaite <address@hidden> wrote:
> 
> Try this after object creation (see xlnx-zynqmp init fn):
> 
>    qdev_set_parent_bus(DEVICE(&s->gic), sysbus_get_default());

ah, sure, I already tried this, if I set the bus, everything works as before.


but probably my question was not clear enough.

my latest configuration uses no qdev_* calls at all, none of my objects are 
connected to sysbus, and apparently everything works without problems.

the reset strategy that I used was to register a reset callback for the MCU:

    CortexMState *cm_state = CORTEXM_MCU_STATE(dev);
    ....
    qemu_register_reset(cortexm_mcu_registered_reset_callback, cm_state);


static void cortexm_mcu_registered_reset_callback(void *opaque)
{
    DeviceState *dev = opaque;

    /* This will actually go to derived class reset. */
    device_reset(dev);
}


and in the object reset callback to explicitly reset all contained objects:

static void cortexm_mcu_reset_callback(DeviceState *dev)
{
    qemu_log_function_name();

    /* Call parent reset(). */
    cm_device_parent_reset(dev, TYPE_CORTEXM_MCU);

    CortexMState *cm_state = CORTEXM_MCU_STATE(dev);

#if defined(CONFIG_VERBOSE)
    if (verbosity_level >= VERBOSITY_COMMON) {
        printf("%s core reset.\n", cm_state->display_model);
    }
#endif

    /* 
     * Ensure the image is copied into memory before reset
     * fetches MSP & PC 
     */

    rom_reset(NULL);

    /* 
     * With the new image available, MSP & PC are correct
     * and execution will start. 
     */

    cpu_reset(CPU(cm_state->cpu));

    device_reset(cm_state->nvic);

    if (cm_state->itm) {
        device_reset(cm_state->itm);
    }
}

> Note we are trying to phase out object_new in favor of embedding the
> device structs in the SoC container, which would mean use of
> object_initialise instead of object_new.

any special reasons in favour of this?

in my configuration some of the contained objects are created conditionally, 
and it seemed more natural to dynamically allocate only the needed ones.

an extreme example is the STM32 objects, which should allocate space for all 
possible peripherals, for all STM32 families and sub-families, and 
object_initialise only the needed ones.

but I got your point, where possible I'll use statically allocated objects.

> Ultimately that's a bug, the system wide reset should not depend on
> qdev.

I did not check the code, but it seems it does not depend on qdev, if there are 
functions registered with qemu_register_reset(), they are called, regardless if 
connected to sysbus or not.


my conclusion is that, at least for my use case, we can get rid completely of 
qdev calls and sysbus, as long as each object explicitly resets all objects it 
creates, which is somehow expected.


regards,

Liviu