On 7/2/19 11:23 AM, Peter Maydell wrote: > On Tue, 2 Jul 2019 at 04:16, John Snow <js...@redhat.com> wrote: >> Does reset always get called as part of realize, really? >> >> Or are we just trusting that the device is probably going to get reset >> by the guest during bringup? > > Reset is not called "as part of realize", but it is guaranteed > to be called after realize and before we try to run the guest, > as long as the device is in the qbus tree. Things are in the > qbus tree if either: > * they're plugged into something already in the tree (eg > pci devices, scsi disks) > * they're a sysbus device (which is automatically plugged into > the 'main system bus' which is effectively the root of the > qbus tree) > > In this case TYPE_PFLASH_CFI01 is a subclass of TYPE_SYS_BUS_DEVICE, > so it will always be reset as part of system reset. > > (the main things which don't get automatically reset are direct > subclasses of TYPE_DEVICE, notably CPU objects.)
Thanks for the clarification! I will update the commit description paraphrasing Peter: The TYPE_DEVICE interface provides a DeviceReset handler. This pflash device is a subclass of TYPE_SYS_BUS_DEVICE (which is a subclass of TYPE_DEVICE). SYS_BUS devices are automatically plugged into the 'main system bus', which is the root of the qbus tree. Devices in the qbus tree are guaranteed to have their reset() handler called after realize() and before we try to run the guest. To avoid incoherent states when the machine resets (see but report below), factor out the reset code into pflash_cfi01_system_reset, and register the method as a device reset callback. John, Laszlo, is that OK with you? Thanks, Phil.
