On Tue, Apr 27, 2021 at 11:20:07AM +0200, Philippe Mathieu-Daudé wrote: > On 4/27/21 3:45 AM, David Gibson wrote: > > On Sat, Apr 24, 2021 at 06:22:25PM +0200, Philippe Mathieu-Daudé wrote: > >> The TYPE_SPAPR_TCE_TABLE device is bus-less, thus isn't reset > >> automatically. Register a reset handler to get reset with the > >> machine. > >> > >> It doesn't seem to be an issue because it is that way since the > >> device QDev'ifycation 8 years ago, in commit a83000f5e3f > >> ("spapr-tce: make sPAPRTCETable a proper device"). > >> Still, correct to have a proper API usage. > > > > So, the reason this works now is that we explicitly call > > device_reset() on the TCE table from the TCE tables "owner", either a > > PHB (spapr_phb_reset()) or a VIO device (spapr_vio_quiesce_one()). > > > > I think we want either that, or the register_reset(), not both. > > rtas_quiesce() seems to call a DeviceClass::reset() on the > children of TYPE_SPAPR_VIO_BUS: > > Abstract TYPE_VIO_SPAPR_DEVICE has the TYPE_SPAPR_VIO_BUS bus_type, > and registers the spapr_vio_busdev_reset() handler, which calls > spapr_vio_quiesce_one()... > > So either we already have 2 resets, or the bus is never reset?
There are 2 resets, and this is intentional. We reset once at machine reset time, via the bus. Once a booting OS is done with the firmware it calls "quiesce" to put all the devices back into a safe state. The easiest way to do that is just to invoke their reset callbacks, so that's what we do. > The bus is created in spapr_machine_init(): > > /* Set up VIO bus */ > spapr->vio_bus = spapr_vio_bus_init(); > > TYPE_SPAPR_MACHINE class registers spapr_machine_reset(), which > manually calls qemu_devices_reset() and spapr_drc_reset_all(), > but I can't understand if a callee resets vio_bus... > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature