Re: [Qemu-devel] [PATCH 1/2] Allow QEMUMachine to override reset sequencing

[David Gibson]

On Wed, Aug 01, 2012 at 09:37:39PM -0500, Anthony Liguori wrote:
> David Gibson <address@hidden> writes:
> 
> > At present the qemu_system_reset() function always performs the same basic
> > actions on all machines.  This includes running all the reset handler
> > hooks, however the order in which they run is not controlled by the board
> > logic.
> 
> Let's be careful here in referring to "board logic".
> 
> Reset should propagate--there's no argument there.  Having all devices
> register in a list with no control over how reset is dispatched is
> wrong.  It's workable because of qdev imposes per-bus reset functions
> and typically we have a small number of busses and ordering doesn't
> matter.
> 
> > This is incorrect: any modern real hardware will generally have some sort
> > of reset controller, sometimes a full microcontroller or even service
> > processor which will control the order in which components on the board are
> > reset.
> 
> I think this is true only with a loose definition of "modern", but okay.
> 
> I don't think this is the right argument.  The machine should serve as
> the entry point for reset.  What components get reset in what order will
> need to be a machine hook for practical purposes (since not everything
> will be fully QOMized all at once).
> 
> So I think this is the right approach for now.
> 
> But all of the DT initialization stuff that is leading to this
> discussion in the first place is a gross hack to make a PV architecture
> work that took far too many short cuts.

Hrm.  The "short cuts" you seem to refer to is the fact that we do a
bunch of our machine initialization direct from qemu, rather than from
firmware executed within the guest.  Doing it this way is both easier
to write, easier to follow and faster to execute, so if that counts as
a gross hack then I think your design priorities need
re-consideration.

Because of the arcane history of the PC boot sequence I can see why
executing a BIOS image within the guest is the preferred model there,
but that's no reason to put the same restriction on platforms that
have a clear and well documented firmware to OS handoff state.

[snip]
> > -void qemu_system_reset(bool report)
> > +void qemu_default_system_reset(bool report)
> >  {
> >      QEMUResetEntry *re, *nre;
> >  
> > @@ -1410,6 +1410,14 @@ void qemu_system_reset(bool report)
> >      cpu_synchronize_all_post_reset();
> >  }
> 
> Not a huge fan of the naming here.  How about qemu_devices_reset()?

Ok, I'll change that.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson