Re: [Qemu-devel] reset strategy?

[Peter Crosthwaite]

On Sat, Jun 27, 2015 at 12:52 PM, Liviu Ionescu <address@hidden> wrote:
>
>> 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));

This should be managed by the bootloader.

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

Are are these two devices really not connected to any bus?

> }
>
>> 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?
>

I'm not sure TBH, its well discussed on list though.

> 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.
>

Yes, but you shouldn't have to register resets from machine level
code. It should just happen via:

vl.c:4412:    qemu_register_reset(qbus_reset_all_fn, sysbus_get_default());

Regards,
Peter

>
> 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
>
>
>
>