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

[Blue Swirl]

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.

> 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.

> 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.