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. 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). > 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? -- PMM
