On 07/02/19 11:37, Philippe Mathieu-Daudé wrote: > 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?
works for me, sure. Thanks Laszlo
