Re: [Qemu-devel] Re: [PATCH 5/5] RFC: distinguish warm reset from cold reset.

[Anthony Liguori]

On 08/30/2010 02:36 PM, Blue Swirl wrote:
> On Mon, Aug 30, 2010 at 7:25 PM, Anthony Liguori<address@hidden>  wrote:
>    
> > On 08/30/2010 02:16 PM, Blue Swirl wrote:
> >      
> > > On Mon, Aug 30, 2010 at 1:03 PM, Anthony Liguori<address@hidden>
> > >   wrote:
> > >
> > >        
> > > > On 08/30/2010 03:50 AM, Paolo Bonzini wrote:
> > > >
> > > >          
> > > > > On 08/30/2010 09:49 AM, Isaku Yamahata wrote:
> > > > >
> > > > >            
> > > > > > +/* those two functions are obsoleted by cold/warm reset API. */
> > > > > > [qemu_register_reset/qemu_unregister_reset]
> > > > > >
> > > > > >              
> > > > > Are they?
> > > > >
> > > > >            
> > > > Yes, but introduce more reset functions isn't the right approach.
> > > >
> > > > Reset should be a method of the device tree, not a stand alone function.
> > > >
> > > >          
> > > In theory the reset tree may be very different from device tree. In
> > > practice the reset tree is probably very flat (global reset signal, a
> > > few bus reset signals) so device tree approach may get the same
> > > results.
> > >
> > >        
> > Well the device tree doesn't really have to be a tree :-)
> >      
> True, but is the non-tree still always useful for other things besides
> reset? Again, in theory.
>    

I think non-tree transversal are not the norm.  But I guess my point is, 
being a tree verses a directed graph is really just a state of mind :-)

If we use a visitor pattern and then allow a visitor to redirect the 
recursion, then assuming the nodes have links to other nodes that don't 
fall in the normal tree hierarchy, it should just work.

OTOH, if we really designed it as a graph we would need to keep a 
visited history which generally is a pain in the butt.  I don't want to 
do that but I think what we have now is good enough.

> > My thinking if we need to support custom reset propagation is that we have
> > the current reset() handler return 0 to propagate to children,<  0 on error,
> > and>  0 to not propagate to direct children just as we do with the walkers.
> >
> > In the case of>  0, the device can choose to propagate to any device that it
> > knows about independent of the default walking order.  This makes the device
> > tree a directed graph whereas the transversal path can be arbitrarily
> > custom.
> >      
> I'd rather not have that much knowledge about the reset tree in the devices.
>    

Aren't the devices the precise place where that knowledge should 
reside?  Is the reset tree really every implemented entirely based on 
complex wiring that exists outside of any type of bus topology?

> > The only questions in my mind are, do we truly need this and do we need more
> > than a single type of reset.  We could make this almost arbitrarily
> > complicated if we wanted to but we should try to keep things simply unless
> > there's a compelling reason not to.
> >      
> Fully agreed, I think current model works. But I'm not opposed to a
> more generic approach, like VM events, combining also power control
> with reset. Though events would not help with the disjoint tree
> problem.
>
> With qemu_irq approach, each event would be replaced by a signal type
> with a few instances. The devices would be as simple as now, but
> wiring in the board level would be bloated.
>    

A signal/slot infrastructure would be a better way to express this sort 
of thing because at the wire level, you'll quickly encounter line 
repeaters, muxers, and demuxers.

But I think we're far ahead of ourselves.  I think we'll solve the 
current problem merely by taking the approach in my previous patch and 
simply making something like PCI AER initialization part of the init() 
routine and not part of the reset() routine.

Regards,

Anthony Liguori