Re: [Qemu-devel] [RESEND PATCH v8 2/4] hw: add a wrapper for registering reset handler

[Igor Mammedov]

On Tue, 30 Jun 2015 14:31:50 +0800
Zhu Guihua <address@hidden> wrote:

> 
> On 06/26/2015 01:28 AM, Andreas Färber wrote:
> > Am 25.06.2015 um 19:00 schrieb Paolo Bonzini:
> >> On 25/06/2015 04:17, Zhu Guihua wrote:
> >>> Add a wrapper to specify reset order when registering reset handler,
> >>> instead of non-obvious initiazation code ordering.
> >>>
> >>> Signed-off-by: Zhu Guihua <address@hidden>
> >> I'm sorry, this is not really acceptable.  The initialization code
> >> ordering is good because it should be okay to run reset handlers in the
> >> same order as code is run.  If there are dependencies between reset
> >> handlers, a random integer is not a maintainable way to maintain them.
> >>
> >> Instead, you should have a single reset handler that calls the reset
> >> handlers in the right order; for example a qdev bus such as icc_bus
> >> always resets children before parents.
> >>
> >> Are you sure that you want to remove the icc_bus?... What are you
> >> gaining exactly by doing so?
> > >From my view we would be gaining by making the APIC an integral part
> > (child<>) of the CPU in a follow-up step (there's a TODO to make things
> > link<>s).
> >
> > But either way the CPU's existing reset handler should be able to handle
> > CPU/APIC interdependencies just fine, somehow. Which is what Eduardo
> > said on v6 and v7. (Another alternative he raised was a machine init
> > notifier, but I see no code for that after its mention on v7?)
> 
> According to Eduardo's suggestions on v7, the simpler way is to add a 
> ordering parameter
> to qemu_register_reset(), so that we can ensure the order of apic reset 
> handler(apic reset
> must be after the other devices' reset on x86).
> 
> This way will  not influence the initialization code ordering expect 
> apic reset.
> Can we take this way? or someone have a better one?
could you explain once more why apic->reset() doesn't work
when it's called from cpu->reset(), please?

> 
> Thanks,
> Zhu
> 
> >
> > Cheers,
> > Andreas
> >
>