Il 10/01/2013 14:01, Peter Maydell ha scritto:
> On 10 January 2013 12:45, Paolo Bonzini <pbonz...@redhat.com> wrote:
>> Il 10/01/2013 13:31, Peter Maydell ha scritto:
>>> On 10 January 2013 12:12, Paolo Bonzini <pbonz...@redhat.com> wrote:
>>>> It's just an implementation detail.  Right now we have a common
>>>> callback.  The idea is to give each bus its own callback.  In the case
>>>> of sysbus it would just call a method; for PCI it would reset some
>>>> configuration and then call a method; for SCSI there is no need to call
>>>> a method at all; and so on.
>>>
>>> But machine reset shouldn't call bus specific PCI or SCSI reset
>>> methods -- we've just effectively yanked the power to the VM
>>> so everything should just reset as if it was freshly constructed.
>>
>> Yes, but we do not have a way to do that, so QEMU resorts to a warm reset.
> 
> qdev reset is cold reset, not warm reset.

Whatever. :)  It resorts to a reset (as if it was freshly constructed)
instead of _really_ doing a fresh construction.

>>> A bus-specific reset method would be for buses where the bus
>>> itself has some sort of guest-triggerable reset (by prodding the
>>> chipset, for instance).
>>
>> Yes.
>>
>>>> In addition, navigating the qdev tree should be explicit in the methods.
>>>>  It will not happen anymore via the "magic" qdev_reset_all.
>>>
>>> *Something* has to say "call reset for every qdev object in the
>>> system", surely?
>>
>> It will call it on sysbus, which will call it on every sysbus child.
>> Devices that have a child bus will propagate it further down.
> 
> This doesn't work when we get rid of the idea that every qdev
> device is attached to a tree of buses.

At least for now, devices that should be bus-free are sysbus devices,
aren't they?

Paolo


Reply via email to