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