Peter Maydell <peter.mayd...@linaro.org> writes: > 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).
The challenge is how we go from what we have to what we want. Right now we have DeviceState::reset. This is used both as a soft and hard reset. What I would propose is that we: s/DeviceState::reset/DeviceState::hard_reset/g Then introduce PCIDevice::soft_reset. We can convert the PCI layer to call soft_reset() instead of hard_reset. Over time, it would be great if we could find a way to implement hard_reset in terms of device destruction/recreation but we're not there yet. I think the reset/hard_reset rename can be done via sed mostly. Would this solve the bug that you're trying to fix Michael/Paolo? Regards, Anthony Liguori >> 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
