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

[Avi Kivity <avi@redhat.com>]

  On 08/31/2010 04:58 PM, Anthony Liguori wrote:
> On 08/31/2010 08:46 AM, Avi Kivity wrote:
>>  On 08/31/2010 04:34 PM, Anthony Liguori wrote:
>>> On 08/31/2010 08:29 AM, Avi Kivity wrote:
>>>> Note, for most devices there's no difference.  x86 has INIT and 
>>>> RESET, with the keyboard controller RESET signal sometimes wired to 
>>>> INIT, and RAM doesn't have RESET.  Otherwise most devices don't see 
>>>> a difference.
>>>
>>> Yes, that's why I'm wondering if we can just get away with using a 
>>> simple reset() callback and for the handful of devices that don't do 
>>> a full reset, they can just move the state unaffected by warm reset 
>>> to ->init().
>>>
>>
>> This seems reasonable.
>
> But I'm still not sure whether the reset signal can be deliver based 
> on a pre-order transversal or whether a custom transversal was 
> required that each bus participates in.

There's no such thing as a global reset.  There's a trace on the board 
that's called RESET that's connected to many chip's RESET input (but 
perhaps not all).  A PCI bus controller will likely propagate its RESET 
input into the PCI reset signal, however it's called.  So individual 
RESET traces are connected by chips, which have different conditions for 
asserting them.

So yes, we need a custom traversal.  Some bus controllers will block off 
RESET completely, some will pass it through, some can reset the devices 
on their bus independently of the controller's RESET input, if it has one.

(but I think we're drifting off into pointlessness here)

>
>>> For cold reset, I'd rather approach it as a device destroy + 
>>> create.  This means that given a DeviceState, we need to collect 
>>> enough information to recreate the device.  I'm not 100% sure we 
>>> have that today but if we solve that problem, it means we can 
>>> migrate the device tree during migration which is a feature I'd 
>>> really like to see.
>>
>> Why do we need a cold reset at all?  it doesn't map to anything.
>
> That's why I'm suggesting a second-class approach to implementing it 
> if someone really wants it.

Sure.

-- 
error compiling committee.c: too many arguments to function