1 2======================================= 3Reset in QEMU: the Resettable interface 4======================================= 5 6The reset of qemu objects is handled using the resettable interface declared 7in ``include/hw/resettable.h``. 8 9This interface allows objects to be grouped (on a tree basis); so that the 10whole group can be reset consistently. Each individual member object does not 11have to care about others; in particular, problems of order (which object is 12reset first) are addressed. 13 14The main object types which implement this interface are DeviceClass 15and BusClass. 16 17Triggering reset 18---------------- 19 20This section documents the APIs which "users" of a resettable object should use 21to control it. All resettable control functions must be called while holding 22the BQL. 23 24You can apply a reset to an object using ``resettable_assert_reset()``. You need 25to call ``resettable_release_reset()`` to release the object from reset. To 26instantly reset an object, without keeping it in reset state, just call 27``resettable_reset()``. These functions take two parameters: a pointer to the 28object to reset and a reset type. 29 30Several types of reset will be supported. For now only cold reset is defined; 31others may be added later. The Resettable interface handles reset types with an 32enum: 33 34``RESET_TYPE_COLD`` 35 Cold reset is supported by every resettable object. In QEMU, it means we reset 36 to the initial state corresponding to the start of QEMU; this might differ 37 from what is a real hardware cold reset. It differs from other resets (like 38 warm or bus resets) which may keep certain parts untouched. 39 40Calling ``resettable_reset()`` is equivalent to calling 41``resettable_assert_reset()`` then ``resettable_release_reset()``. It is 42possible to interleave multiple calls to these three functions. There may 43be several reset sources/controllers of a given object. The interface handles 44everything and the different reset controllers do not need to know anything 45about each others. The object will leave reset state only when each other 46controllers end their reset operation. This point is handled internally by 47maintaining a count of in-progress resets; it is crucial to call 48``resettable_release_reset()`` one time and only one time per 49``resettable_assert_reset()`` call. 50 51For now migration of a device or bus in reset is not supported. Care must be 52taken not to delay ``resettable_release_reset()`` after its 53``resettable_assert_reset()`` counterpart. 54 55Note that, since resettable is an interface, the API takes a simple Object as 56parameter. Still, it is a programming error to call a resettable function on a 57non-resettable object and it will trigger a run time assert error. Since most 58calls to resettable interface are done through base class functions, such an 59error is not likely to happen. 60 61For Devices and Buses, the following helper functions exist: 62 63- ``device_cold_reset()`` 64- ``bus_cold_reset()`` 65 66These are simple wrappers around resettable_reset() function; they only cast the 67Device or Bus into an Object and pass the cold reset type. When possible 68prefer to use these functions instead of ``resettable_reset()``. 69 70Device and bus functions co-exist because there can be semantic differences 71between resetting a bus and resetting the controller bridge which owns it. 72For example, consider a SCSI controller. Resetting the controller puts all 73its registers back to what reset state was as well as reset everything on the 74SCSI bus, whereas resetting just the SCSI bus only resets everything that's on 75it but not the controller. 76 77 78Multi-phase mechanism 79--------------------- 80 81This section documents the internals of the resettable interface. 82 83The resettable interface uses a multi-phase system to relieve objects and 84machines from reset ordering problems. To address this, the reset operation 85of an object is split into three well defined phases. 86 87When resetting several objects (for example the whole machine at simulation 88startup), all first phases of all objects are executed, then all second phases 89and then all third phases. 90 91The three phases are: 92 931. The **enter** phase is executed when the object enters reset. It resets only 94 local state of the object; it must not do anything that has a side-effect 95 on other objects, such as raising or lowering a qemu_irq line or reading or 96 writing guest memory. 97 982. The **hold** phase is executed for entry into reset, once every object in the 99 group which is being reset has had its *enter* phase executed. At this point 100 devices can do actions that affect other objects. 101 1023. The **exit** phase is executed when the object leaves the reset state. 103 Actions affecting other objects are permitted. 104 105As said in previous section, the interface maintains a count of reset. This 106count is used to ensure phases are executed only when required. *enter* and 107*hold* phases are executed only when asserting reset for the first time 108(if an object is already in reset state when calling 109``resettable_assert_reset()`` or ``resettable_reset()``, they are not 110executed). 111The *exit* phase is executed only when the last reset operation ends. Therefore 112the object does not need to care how many of reset controllers it has and how 113many of them have started a reset. 114 115 116Handling reset in a resettable object 117------------------------------------- 118 119This section documents the APIs that an implementation of a resettable object 120must provide and what functions it has access to. It is intended for people 121who want to implement or convert a class which has the resettable interface; 122for example when specializing an existing device or bus. 123 124Methods to implement 125.................... 126 127Three methods should be defined or left empty. Each method corresponds to a 128phase of the reset; they are name ``phases.enter()``, ``phases.hold()`` and 129``phases.exit()``. They all take the object as parameter. The *enter* method 130also take the reset type as second parameter. 131 132When extending an existing class, these methods may need to be extended too. 133The ``resettable_class_set_parent_phases()`` class function may be used to 134backup parent class methods. 135 136Here follows an example to implement reset for a Device which sets an IO while 137in reset. 138 139:: 140 141 static void mydev_reset_enter(Object *obj, ResetType type) 142 { 143 MyDevClass *myclass = MYDEV_GET_CLASS(obj); 144 MyDevState *mydev = MYDEV(obj); 145 /* call parent class enter phase */ 146 if (myclass->parent_phases.enter) { 147 myclass->parent_phases.enter(obj, type); 148 } 149 /* initialize local state only */ 150 mydev->var = 0; 151 } 152 153 static void mydev_reset_hold(Object *obj) 154 { 155 MyDevClass *myclass = MYDEV_GET_CLASS(obj); 156 MyDevState *mydev = MYDEV(obj); 157 /* call parent class hold phase */ 158 if (myclass->parent_phases.hold) { 159 myclass->parent_phases.hold(obj); 160 } 161 /* set an IO */ 162 qemu_set_irq(mydev->irq, 1); 163 } 164 165 static void mydev_reset_exit(Object *obj) 166 { 167 MyDevClass *myclass = MYDEV_GET_CLASS(obj); 168 MyDevState *mydev = MYDEV(obj); 169 /* call parent class exit phase */ 170 if (myclass->parent_phases.exit) { 171 myclass->parent_phases.exit(obj); 172 } 173 /* clear an IO */ 174 qemu_set_irq(mydev->irq, 0); 175 } 176 177 typedef struct MyDevClass { 178 MyParentClass parent_class; 179 /* to store eventual parent reset methods */ 180 ResettablePhases parent_phases; 181 } MyDevClass; 182 183 static void mydev_class_init(ObjectClass *class, void *data) 184 { 185 MyDevClass *myclass = MYDEV_CLASS(class); 186 ResettableClass *rc = RESETTABLE_CLASS(class); 187 resettable_class_set_parent_phases(rc, 188 mydev_reset_enter, 189 mydev_reset_hold, 190 mydev_reset_exit, 191 &myclass->parent_phases); 192 } 193 194In the above example, we override all three phases. It is possible to override 195only some of them by passing NULL instead of a function pointer to 196``resettable_class_set_parent_phases()``. For example, the following will 197only override the *enter* phase and leave *hold* and *exit* untouched:: 198 199 resettable_class_set_parent_phases(rc, mydev_reset_enter, NULL, NULL, 200 &myclass->parent_phases); 201 202This is equivalent to providing a trivial implementation of the hold and exit 203phases which does nothing but call the parent class's implementation of the 204phase. 205 206Polling the reset state 207....................... 208 209Resettable interface provides the ``resettable_is_in_reset()`` function. 210This function returns true if the object parameter is currently under reset. 211 212An object is under reset from the beginning of the *enter* phase (before 213either its children or its own enter method is called) to the *exit* 214phase. During *enter* and *hold* phase only, the function will return that the 215object is in reset. The state is changed after the *exit* is propagated to 216its children and just before calling the object's own *exit* method. 217 218This function may be used if the object behavior has to be adapted 219while in reset state. For example if a device has an irq input, 220it will probably need to ignore it while in reset; then it can for 221example check the reset state at the beginning of the irq callback. 222 223Note that until migration of the reset state is supported, an object 224should not be left in reset. So apart from being currently executing 225one of the reset phases, the only cases when this function will return 226true is if an external interaction (like changing an io) is made during 227*hold* or *exit* phase of another object in the same reset group. 228 229Helpers ``device_is_in_reset()`` and ``bus_is_in_reset()`` are also provided 230for devices and buses and should be preferred. 231 232 233Base class handling of reset 234---------------------------- 235 236This section documents parts of the reset mechanism that you only need to know 237about if you are extending it to work with a new base class other than 238DeviceClass or BusClass, or maintaining the existing code in those classes. Most 239people can ignore it. 240 241Methods to implement 242.................... 243 244There are two other methods that need to exist in a class implementing the 245interface: ``get_state()`` and ``child_foreach()``. 246 247``get_state()`` is simple. *resettable* is an interface and, as a consequence, 248does not have any class state structure. But in order to factorize the code, we 249need one. This method must return a pointer to ``ResettableState`` structure. 250The structure must be allocated by the base class; preferably it should be 251located inside the object instance structure. 252 253``child_foreach()`` is more complex. It should execute the given callback on 254every reset child of the given resettable object. All children must be 255resettable too. Additional parameters (a reset type and an opaque pointer) must 256be passed to the callback too. 257 258In ``DeviceClass`` and ``BusClass`` the ``ResettableState`` is located 259``DeviceState`` and ``BusState`` structure. ``child_foreach()`` is implemented 260to follow the bus hierarchy; for a bus, it calls the function on every child 261device; for a device, it calls the function on every bus child. When we reset 262the main system bus, we reset the whole machine bus tree. 263 264Changing a resettable parent 265............................ 266 267One thing which should be taken care of by the base class is handling reset 268hierarchy changes. 269 270The reset hierarchy is supposed to be static and built during machine creation. 271But there are actually some exceptions. To cope with this, the resettable API 272provides ``resettable_change_parent()``. This function allows to set, update or 273remove the parent of a resettable object after machine creation is done. As 274parameters, it takes the object being moved, the old parent if any and the new 275parent if any. 276 277This function can be used at any time when not in a reset operation. During 278a reset operation it must be used only in *hold* phase. Using it in *enter* or 279*exit* phase is an error. 280Also it should not be used during machine creation, although it is harmless to 281do so: the function is a no-op as long as old and new parent are NULL or not 282in reset. 283 284There is currently 2 cases where this function is used: 285 2861. *device hotplug*; it means a new device is introduced on a live bus. 287 2882. *hot bus change*; it means an existing live device is added, moved or 289 removed in the bus hierarchy. At the moment, it occurs only in the raspi 290 machines for changing the sdbus used by sd card. 291 292Reset of the complete system 293---------------------------- 294 295Reset of the complete system is a little complicated. The typical 296flow is: 297 2981. Code which wishes to reset the entire system does so by calling 299 ``qemu_system_reset_request()``. This schedules a reset, but the 300 reset will happen asynchronously after the function returns. 301 That makes this safe to call from, for example, device models. 302 3032. The function which is called to make the reset happen is 304 ``qemu_system_reset()``. Generally only core system code should 305 call this directly. 306 3073. ``qemu_system_reset()`` calls the ``MachineClass::reset`` method of 308 the current machine, if it has one. That method must call 309 ``qemu_devices_reset()``. If the machine has no reset method, 310 ``qemu_system_reset()`` calls ``qemu_devices_reset()`` directly. 311 3124. ``qemu_devices_reset()`` performs a reset of the system, using 313 the three-phase mechanism listed above. It resets all objects 314 that were registered with it using ``qemu_register_resettable()``. 315 It also calls all the functions registered with it using 316 ``qemu_register_reset()``. Those functions are called during the 317 "hold" phase of this reset. 318 3195. The most important object that this reset resets is the 320 'sysbus' bus. The sysbus bus is the root of the qbus tree. This 321 means that all devices on the sysbus are reset, and all their 322 child buses, and all the devices on those child buses. 323 3246. Devices which are not on the qbus tree are *not* automatically 325 reset! (The most obvious example of this is CPU objects, but 326 anything that directly inherits from ``TYPE_OBJECT`` or ``TYPE_DEVICE`` 327 rather than from ``TYPE_SYS_BUS_DEVICE`` or some other plugs-into-a-bus 328 type will be in this category.) You need to therefore arrange for these 329 to be reset in some other way (e.g. using ``qemu_register_resettable()`` 330 or ``qemu_register_reset()``). 331