Features/ResetAPI: Difference between revisions
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 |