Il 10/01/2013 13:31, Peter Maydell ha scritto: > On 10 January 2013 12:12, Paolo Bonzini <pbonz...@redhat.com> wrote: >> Il 10/01/2013 12:59, Peter Maydell ha scritto: >>>>>>>>>>> It's possible. I'll move the SCSI bus away from qdev reset. >>>>>>>>>>> Anthony/Michael, can you help doing the same with PCIDevice? And >>>>>>>>>>> perhaps Peter and Andreas with sysbus? >>>>>>> What does it even mean to reset a sysbus? Do we do it anywhere? >>>>>>> (it looks like vl.c does, just as a shortcut so memory mapped devices >>>>>>> get their reset hooks called?) >>> So how should it work instead? I kind of feel like all qdev devices should >>> get their reset hook called on machine reset, regardless of bus [since it's >>> modelling power cycling the whole system], but would that break >>> something? >> >> 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. > 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. Paolo
