On Wed, 17 Jan 2024 at 09:16, <pet...@redhat.com> wrote: > > From: Peter Xu <pet...@redhat.com> > > QEMU resets do not have a way to order reset hooks. Add one coarse grained > reset stage so that some devices can be reset later than some others. > > Signed-off-by: Peter Xu <pet...@redhat.com> > --- > include/sysemu/reset.h | 5 ++++ > hw/core/reset.c | 60 +++++++++++++++++++++++++++++++----------- > 2 files changed, 49 insertions(+), 16 deletions(-) > > diff --git a/include/sysemu/reset.h b/include/sysemu/reset.h > index 609e4d50c2..0de697ce9f 100644 > --- a/include/sysemu/reset.h > +++ b/include/sysemu/reset.h > @@ -5,9 +5,14 @@ > > typedef void QEMUResetHandler(void *opaque); > > +#define QEMU_RESET_STAGES_N 2 > +
Our reset handling APIs are already pretty complicated, and raw qemu_register_reset() is kind of a legacy API that I would prefer that we try to move away from, not add extra complexity to. Our device reset design already has a multiple-phase system (see docs/devel/reset.rst), part of the point of which is to try to give us a way to deal with reset-ordering problems. I feel like the right way to handle the issue you're trying to address is to ensure that the thing that needs to happen last is done in the 'exit' phase rather than the 'hold' phase (which is where legacy reset methods get called). There are some annoying wrinkles here, notably that legacy qemu_register_reset() doesn't support 3-phase reset and so the phasing only happens for devices reset via the device/bus tree hierarchy. But I think the way to go is to try to move forward with that design (i.e. expand 3-phase reset to qemu_register_reset() and/or move things using qemu_register_reset() to device reset where that makes sense), not to ignore it and put a completely different reset-ordering API in a different place. thanks -- PMM
