Features/ResetAPI: Difference between revisions

From QEMU
No edit summary
No edit summary
 
Line 98: Line 98:
== Links ==
== Links ==
* [http://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00186.html| qdev: Reset hotplugged devices]
* [http://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00186.html| qdev: Reset hotplugged devices]
[[Category:Obsolete feature pages]]

Latest revision as of 14:43, 11 October 2016

Summary

Clean up qemu reset API and qdev reset API. Then implement pci bus reset cleanly by utilizing qdev reset frame work.

Discussions on ML

From ML Discussion:

TODO:put discussion summary


Terminology and Reset Types

The following is the list of terminology and reset types in order to help discussion. (Terminology heavily owe to PCIe spec.)

reset
Bring the state of hardware state to consistent state. (some state might be left unknown.)


system reset
a hardware mechanism for setting or returning all hardware states to the initial conditions.
* Use case
In qemu, system_system_reset().


cold reset(power on reset)
system reset following the application of power.


* Use case
In qemu, system_reset() in main().
We might want to use this as a power cycle.
When a device is hot plugged, the device should be cold reset too.
* Guarantee
The internal status must be same to qdev_init() + qdev_reset()


warm reset
system reset without cycling the supplied power.
* Use case
In qemu, system_reset() in main_loop(). There are many places which calls qemu_system_reset_request().
Some state are retained across warm reset. Like PCIe AER, error reporting registers need to keep its contents across warm reset
as OS would examine them and report it when hardware errors caused warm reset.


bus reset
Reset bus and devices on the bus.
Bus reset is usually triggered when cold reset, warm reset and commanding the bus controller to reset the child bus.
When bus reset is triggered as command to bus controller, the effect is usually same to warm reset on devices on the bus.
Typically on parallel bus, bus reset is started by asserting a designated signal.
* Example: PCI RST#, ATA RESET-, SCSI RST
* Use case
bus reset as result of programming bus controller.
Qemu is currently missing it which I'd like to fill for pci bus.
ATA and SCSI could benefit from this.
* Guarantee
device state under the bus is same as warm reset.


device/function reset
Reset triggered by sending reset command to a device. This is bus/device specific.
There might be many reset commands whose effects are different.
* Example: PCI FLR, ATA DEVICE RESET command, scsi bus device reset message.
This reset is bus specific, so it wouldn't be suitable for qdev frame work and could be handled by each bus level.


hot reset
A reset propagated in-band across a Link using a Physical Layer mechanism.
I just put it here for completeness because pcie defines hot reset.
Qemu doesn't emulate physical layer, so we don't care it. From software point of view, hot reset has same effect to warm reset.


TODO

Item Status
split up reset callback into cold/warm reset callback
qdev framework for bus reset
pci bus reset emulation


Links