Re: [Qemu-devel] [RFC 00/17] multi-phase reset mechanism

[Peter Maydell]

On Mon, 20 May 2019 at 15:32, Damien Hedde <address@hidden> wrote:
>
> Hi,
>
> On 5/16/19 2:41 PM, Peter Maydell wrote:
> > Handling migration of the bus base class reset count is a little
> >  awkward -- we'll need to put it in a vmstate subsection which
> >  is part of the vmstate of the device which owns the bus.
> >  (I talked to David Gilbert on IRC about this and have some
> >  possibilities for how to do it, but will postpone writing them
> >  out until we've decided whether we like the APIs.)
>
> If:
>   1. we say we cannot use a Bus as holdable reset entry point (we can
> reset it but not (de)assert_reset it without passing by its parent Device)
>   2. if there is no additional reset dedicated state (right now a reset
> on a bus mostly propagates it to sub-devices)
> Then we have no state migration needed for buses and we can probably
> find a way to use the parent Device's reset_count.

Yeah, I thought about this, but I decided I didn't like having
"there's a Resettable interface but you have to know that
some implementations are special and it's not possible to
do the same things with them you can with some others".
Implementing migration of the child bus reset state as part of
the parent device's vmstate is a bit tedious but not impossible.
(Basically in the parent device's pre-save function you have
to create a temporary array, populate it by walking the list
of child buses and looking at their reset flags, then migrate
the contents of the array, and in post-load you do "walk child
buses and fill in the reset flags from the array". There's a
VMSTATE_WITH_TMP macro that can apparently assist with this.)

> This is somewhat related to the API TRANSITION part below but I was
> wondering if I should add some kind of flag in the interface class to
> indicate the support of "migration-during-reset" functionality. It could
> be used to at least warn when trying to hold the reset state in such an
> class.
> This flag will default to false and one would have to set it when
> implementing the functionality for a given object class (like I did with
> the cadence_uart device).

I think that migration-during-reset should Just Work, without
necessarily needing any specific changes for a device.
I'm not sure a warning that only prints when the guest does
something to cause device-reset is going to be very helpful:
what would be the thing that the warning would tell us we needed
to do?

thanks
-- PMM