From bda8c24cb564afe88d7ab713e44aeefdcb10ff63 Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Tue, 29 Oct 2024 12:54:41 +0000 Subject: docs/system/cpu-hotplug: Update example's socket-id/core-id The example of how to do vCPU hotplug and hot-unlpug in the cpu-hotplug documentation no longer works, because the way we allocate socket-id and core-id to CPUs by default has changed at some point. The output also no longer matches what current QEMU produces in some more cosmetic ways. Update the example to match current QEMU. The differences are: * the second CPU is now socket-id=0 core-id=1, not socket-id=1 core-id=0 * the order of fields in QMP responses is now in alphabetical order * the "arch" member is no longer present in the query-cpus-fast output (it was removed in QEMU 6.0) Signed-off-by: Peter Maydell Acked-by: Igor Mammedov Message-id: 20241010131800.3210161-1-peter.maydell@linaro.org Message-id: 20240819144303.37852-1-peter.maydell@linaro.org --- docs/system/cpu-hotplug.rst | 54 ++++++++++++++++++++++----------------------- 1 file changed, 26 insertions(+), 28 deletions(-) (limited to 'docs') diff --git a/docs/system/cpu-hotplug.rst b/docs/system/cpu-hotplug.rst index 015ce2b..cc50937 100644 --- a/docs/system/cpu-hotplug.rst +++ b/docs/system/cpu-hotplug.rst @@ -33,23 +33,23 @@ vCPU hotplug { "return": [ { - "type": "IvyBridge-IBRS-x86_64-cpu", - "vcpus-count": 1, "props": { - "socket-id": 1, - "core-id": 0, + "core-id": 1, + "socket-id": 0, "thread-id": 0 - } + }, + "type": "IvyBridge-IBRS-x86_64-cpu", + "vcpus-count": 1 }, { - "qom-path": "/machine/unattached/device[0]", - "type": "IvyBridge-IBRS-x86_64-cpu", - "vcpus-count": 1, "props": { - "socket-id": 0, "core-id": 0, + "socket-id": 0, "thread-id": 0 - } + }, + "qom-path": "/machine/unattached/device[0]", + "type": "IvyBridge-IBRS-x86_64-cpu", + "vcpus-count": 1 } ] } @@ -58,18 +58,18 @@ vCPU hotplug (4) The ``query-hotpluggable-cpus`` command returns an object for CPUs that are present (containing a "qom-path" member) or which may be hot-plugged (no "qom-path" member). From its output in step (3), we - can see that ``IvyBridge-IBRS-x86_64-cpu`` is present in socket 0, - while hot-plugging a CPU into socket 1 requires passing the listed + can see that ``IvyBridge-IBRS-x86_64-cpu`` is present in socket 0 core 0, + while hot-plugging a CPU into socket 0 core 1 requires passing the listed properties to QMP ``device_add``:: - (QEMU) device_add id=cpu-2 driver=IvyBridge-IBRS-x86_64-cpu socket-id=1 core-id=0 thread-id=0 + (QEMU) device_add id=cpu-2 driver=IvyBridge-IBRS-x86_64-cpu socket-id=0 core-id=1 thread-id=0 { "execute": "device_add", "arguments": { - "socket-id": 1, + "core-id": 1, "driver": "IvyBridge-IBRS-x86_64-cpu", "id": "cpu-2", - "core-id": 0, + "socket-id": 0, "thread-id": 0 } } @@ -83,34 +83,32 @@ vCPU hotplug (QEMU) query-cpus-fast { - "execute": "query-cpus-fast", "arguments": {} + "execute": "query-cpus-fast", } { "return": [ { - "qom-path": "/machine/unattached/device[0]", - "target": "x86_64", - "thread-id": 11534, "cpu-index": 0, "props": { - "socket-id": 0, "core-id": 0, + "socket-id": 0, "thread-id": 0 }, - "arch": "x86" + "qom-path": "/machine/unattached/device[0]", + "target": "x86_64", + "thread-id": 28957 }, { - "qom-path": "/machine/peripheral/cpu-2", - "target": "x86_64", - "thread-id": 12106, "cpu-index": 1, "props": { - "socket-id": 1, - "core-id": 0, + "core-id": 1, + "socket-id": 0, "thread-id": 0 }, - "arch": "x86" + "qom-path": "/machine/peripheral/cpu-2", + "target": "x86_64", + "thread-id": 29095 } ] } @@ -123,10 +121,10 @@ From the 'qmp-shell', invoke the QMP ``device_del`` command:: (QEMU) device_del id=cpu-2 { - "execute": "device_del", "arguments": { "id": "cpu-2" } + "execute": "device_del", } { "return": {} -- cgit v1.1 From 800cbbfb01a3e5dece01dea6b7133c0a4c02e856 Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Tue, 29 Oct 2024 12:54:43 +0000 Subject: docs/system/arm/stm32: List olimex-stm32-h405 in document title MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List the olimex-stm32-h405 board in the document title, so that the board name appears in the table of contents in system/target-arm.rst. Signed-off-by: Peter Maydell Reviewed-by: Alex Bennée Reviewed-by: Cédric Le Goater Message-id: 20241018141332.942844-2-peter.maydell@linaro.org --- docs/system/arm/stm32.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/system/arm/stm32.rst b/docs/system/arm/stm32.rst index ca7a558..511e3eb 100644 --- a/docs/system/arm/stm32.rst +++ b/docs/system/arm/stm32.rst @@ -1,5 +1,5 @@ -STMicroelectronics STM32 boards (``netduino2``, ``netduinoplus2``, ``stm32vldiscovery``) -======================================================================================== +STMicroelectronics STM32 boards (``netduino2``, ``netduinoplus2``, ``olimex-stm32-h405``, ``stm32vldiscovery``) +=============================================================================================================== The `STM32`_ chips are a family of 32-bit ARM-based microcontroller by STMicroelectronics. -- cgit v1.1 From 23a26bfeea5a9c831067cb0c4529d7c067b79564 Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Tue, 29 Oct 2024 12:54:43 +0000 Subject: docs/system/arm: Don't use wildcard '*-bmc' in doc titles MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We have two Arm board doc files which both use '*-bmc' in their documentation title. The result is that when you read the table of contents in system/target-arm.html you don't know which boards are covered by which file. Expand out the board names entirely in the document titles. Signed-off-by: Peter Maydell Reviewed-by: Alex Bennée Reviewed-by: Cédric Le Goater Message-id: 20241018141332.942844-3-peter.maydell@linaro.org --- docs/system/arm/aspeed.rst | 4 ++-- docs/system/arm/nuvoton.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/system/arm/aspeed.rst b/docs/system/arm/aspeed.rst index 6733ffd..968ba88 100644 --- a/docs/system/arm/aspeed.rst +++ b/docs/system/arm/aspeed.rst @@ -1,5 +1,5 @@ -Aspeed family boards (``*-bmc``, ``ast2500-evb``, ``ast2600-evb``, ``ast2700-evb``) -=================================================================================== +Aspeed family boards (``ast2500-evb``, ``ast2600-evb``, ``ast2700-evb``, ``bletchley-bmc``, ``fuji-bmc``, ``fby35-bmc``, ``fp5280g2-bmc``, ``g220a-bmc``, ``palmetto-bmc``, ``qcom-dc-scm-v1-bmc``, ``qcom-firework-bmc``, ``quanta-q71l-bmc``, ``rainier-bmc``, ``romulus-bmc``, ``sonorapass-bmc``, ``supermicrox11-bmc``, ``tiogapass-bmc``, ``tacoma-bmc``, ``witherspoon-bmc``, ``yosemitev2-bmc``) +======================================================================================================================================================================================================================================================================================================================================================================================================== The QEMU Aspeed machines model BMCs of various OpenPOWER systems and Aspeed evaluation boards. They are based on different releases of the diff --git a/docs/system/arm/nuvoton.rst b/docs/system/arm/nuvoton.rst index 0424cae..0505937 100644 --- a/docs/system/arm/nuvoton.rst +++ b/docs/system/arm/nuvoton.rst @@ -1,5 +1,5 @@ -Nuvoton iBMC boards (``*-bmc``, ``npcm750-evb``, ``quanta-gsj``) -================================================================ +Nuvoton iBMC boards (``kudo-bmc``, ``mori-bmc``, ``npcm750-evb``, ``quanta-gbs-bmc``, ``quanta-gsj``) +===================================================================================================== The `Nuvoton iBMC`_ chips (NPCM7xx) are a family of ARM-based SoCs that are designed to be used as Baseboard Management Controllers (BMCs) in various -- cgit v1.1 From 6a98e614e5cc3ae9aa15a6bdf30fbdb4472bf2ff Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Tue, 29 Oct 2024 12:54:44 +0000 Subject: docs/system/arm: Split fby35 out from aspeed.rst MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The fby35 machine is not implemented in hw/arm/aspeed.c, but its documentation is currently stuck at the end of aspeed.rst, formatted in a way that it gets its own heading in the top-level list of boards in target-arm.html. We don't have any other boards that we document like this; split it out into its own rst file. This improves consistency with other board docs and means we can have the entry in the target-arm list be in the correct alphabetical order. Signed-off-by: Peter Maydell Reviewed-by: Alex Bennée Reviewed-by: Cédric Le Goater Message-id: 20241018141332.942844-4-peter.maydell@linaro.org --- docs/system/arm/aspeed.rst | 48 ---------------------------------------------- docs/system/arm/fby35.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++ docs/system/target-arm.rst | 1 + 3 files changed, 48 insertions(+), 48 deletions(-) create mode 100644 docs/system/arm/fby35.rst (limited to 'docs') diff --git a/docs/system/arm/aspeed.rst b/docs/system/arm/aspeed.rst index 968ba88..63910d3 100644 --- a/docs/system/arm/aspeed.rst +++ b/docs/system/arm/aspeed.rst @@ -257,51 +257,3 @@ To boot a kernel directly from a Zephyr build tree: $ qemu-system-arm -M ast1030-evb -nographic \ -kernel zephyr.elf - -Facebook Yosemite v3.5 Platform and CraterLake Server (``fby35``) -================================================================== - -Facebook has a series of multi-node compute server designs named -Yosemite. The most recent version released was -`Yosemite v3 `__. - -Yosemite v3.5 is an iteration on this design, and is very similar: there's a -baseboard with a BMC, and 4 server slots. The new server board design termed -"CraterLake" includes a Bridge IC (BIC), with room for expansion boards to -include various compute accelerators (video, inferencing, etc). At the moment, -only the first server slot's BIC is included. - -Yosemite v3.5 is itself a sled which fits into a 40U chassis, and 3 sleds -can be fit into a chassis. See `here `__ -for an example. - -In this generation, the BMC is an AST2600 and each BIC is an AST1030. The BMC -runs `OpenBMC `__, and the BIC runs -`OpenBIC `__. - -Firmware images can be retrieved from the Github releases or built from the -source code, see the README's for instructions on that. This image uses the -"fby35" machine recipe from OpenBMC, and the "yv35-cl" target from OpenBIC. -Some reference images can also be found here: - -.. code-block:: bash - - $ wget https://github.com/facebook/openbmc/releases/download/openbmc-e2294ff5d31d/fby35.mtd - $ wget https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.13.01/Y35BCL.elf - -Since this machine has multiple SoC's, each with their own serial console, the -recommended way to run it is to allocate a pseudoterminal for each serial -console and let the monitor use stdio. Also, starting in a paused state is -useful because it allows you to attach to the pseudoterminals before the boot -process starts. - -.. code-block:: bash - - $ qemu-system-arm -machine fby35 \ - -drive file=fby35.mtd,format=raw,if=mtd \ - -device loader,file=Y35BCL.elf,addr=0,cpu-num=2 \ - -serial pty -serial pty -serial mon:stdio \ - -display none -S - $ screen /dev/tty0 # In a separate TMUX pane, terminal window, etc. - $ screen /dev/tty1 - $ (qemu) c # Start the boot process once screen is setup. diff --git a/docs/system/arm/fby35.rst b/docs/system/arm/fby35.rst new file mode 100644 index 0000000..742b887 --- /dev/null +++ b/docs/system/arm/fby35.rst @@ -0,0 +1,47 @@ +Facebook Yosemite v3.5 Platform and CraterLake Server (``fby35``) +================================================================== + +Facebook has a series of multi-node compute server designs named +Yosemite. The most recent version released was +`Yosemite v3 `__. + +Yosemite v3.5 is an iteration on this design, and is very similar: there's a +baseboard with a BMC, and 4 server slots. The new server board design termed +"CraterLake" includes a Bridge IC (BIC), with room for expansion boards to +include various compute accelerators (video, inferencing, etc). At the moment, +only the first server slot's BIC is included. + +Yosemite v3.5 is itself a sled which fits into a 40U chassis, and 3 sleds +can be fit into a chassis. See `here `__ +for an example. + +In this generation, the BMC is an AST2600 and each BIC is an AST1030. The BMC +runs `OpenBMC `__, and the BIC runs +`OpenBIC `__. + +Firmware images can be retrieved from the Github releases or built from the +source code, see the README's for instructions on that. This image uses the +"fby35" machine recipe from OpenBMC, and the "yv35-cl" target from OpenBIC. +Some reference images can also be found here: + +.. code-block:: bash + + $ wget https://github.com/facebook/openbmc/releases/download/openbmc-e2294ff5d31d/fby35.mtd + $ wget https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.13.01/Y35BCL.elf + +Since this machine has multiple SoC's, each with their own serial console, the +recommended way to run it is to allocate a pseudoterminal for each serial +console and let the monitor use stdio. Also, starting in a paused state is +useful because it allows you to attach to the pseudoterminals before the boot +process starts. + +.. code-block:: bash + + $ qemu-system-arm -machine fby35 \ + -drive file=fby35.mtd,format=raw,if=mtd \ + -device loader,file=Y35BCL.elf,addr=0,cpu-num=2 \ + -serial pty -serial pty -serial mon:stdio \ + -display none -S + $ screen /dev/tty0 # In a separate TMUX pane, terminal window, etc. + $ screen /dev/tty1 + $ (qemu) c # Start the boot process once screen is setup. diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst index 3c0a584..9c01e66 100644 --- a/docs/system/target-arm.rst +++ b/docs/system/target-arm.rst @@ -90,6 +90,7 @@ undocumented; you can get a complete list by running arm/digic arm/cubieboard arm/emcraft-sf2 + arm/fby35 arm/musicpal arm/kzm arm/nrf -- cgit v1.1 From f99e1d314d655561a0022902563eb5bffc260dc0 Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Tue, 29 Oct 2024 12:54:44 +0000 Subject: docs/system/arm: Add placeholder doc for exynos4 boards MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add a placeholder doc for the exynos4 boards nuri and smdkc210. Signed-off-by: Peter Maydell Reviewed-by: Alex Bennée Reviewed-by: Cédric Le Goater Message-id: 20241018141332.942844-5-peter.maydell@linaro.org --- docs/system/arm/exynos.rst | 9 +++++++++ docs/system/target-arm.rst | 1 + 2 files changed, 10 insertions(+) create mode 100644 docs/system/arm/exynos.rst (limited to 'docs') diff --git a/docs/system/arm/exynos.rst b/docs/system/arm/exynos.rst new file mode 100644 index 0000000..86894bc --- /dev/null +++ b/docs/system/arm/exynos.rst @@ -0,0 +1,9 @@ +Exynos4 boards (``nuri``, ``smdkc210``) +======================================= + +These are machines which use the Samsung Exynos4210 SoC, which has Cortex-A9 CPUs. + +``nuri`` models the Samsung NURI board. + +``smdkc210`` models the Samsung SMDKC210 board. + diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst index 9c01e66..a7f88c8 100644 --- a/docs/system/target-arm.rst +++ b/docs/system/target-arm.rst @@ -90,6 +90,7 @@ undocumented; you can get a complete list by running arm/digic arm/cubieboard arm/emcraft-sf2 + arm/exynos arm/fby35 arm/musicpal arm/kzm -- cgit v1.1 From 6128720af88eb9b5b3857f88785d32bc052049a7 Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Tue, 29 Oct 2024 12:54:44 +0000 Subject: docs/system/arm: Add placeholder doc for xlnx-zcu102 board MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add a placeholder doc for the xlnx-zcu102 board. Signed-off-by: Peter Maydell Reviewed-by: Alex Bennée Reviewed-by: Cédric Le Goater Reviewed-by: Alistair Francis Message-id: 20241018141332.942844-6-peter.maydell@linaro.org --- docs/system/arm/xlnx-zcu102.rst | 19 +++++++++++++++++++ docs/system/target-arm.rst | 1 + 2 files changed, 20 insertions(+) create mode 100644 docs/system/arm/xlnx-zcu102.rst (limited to 'docs') diff --git a/docs/system/arm/xlnx-zcu102.rst b/docs/system/arm/xlnx-zcu102.rst new file mode 100644 index 0000000..534cd1d --- /dev/null +++ b/docs/system/arm/xlnx-zcu102.rst @@ -0,0 +1,19 @@ +Xilinx ZynqMP ZCU102 (``xlnx-zcu102``) +====================================== + +The ``xlnx-zcu102`` board models the Xilinx ZynqMP ZCU102 board. +This board has 4 Cortex-A53 CPUs and 2 Cortex-R5F CPUs. + +Machine-specific options +"""""""""""""""""""""""" + +The following machine-specific options are supported: + +secure + Set ``on``/``off`` to enable/disable emulating a guest CPU which implements the + Arm Security Extensions (TrustZone). The default is ``off``. + +virtualization + Set ``on``/``off`` to enable/disable emulating a guest CPU which implements the + Arm Virtualization Extensions. The default is ``off``. + diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst index a7f88c8..ace36d1 100644 --- a/docs/system/target-arm.rst +++ b/docs/system/target-arm.rst @@ -107,6 +107,7 @@ undocumented; you can get a complete list by running arm/xenpvh arm/xlnx-versal-virt arm/xlnx-zynq + arm/xlnx-zcu102 Emulated CPU architecture support ================================= -- cgit v1.1 From 946f9ef267f3da3a24cc052a337bfd5d54347e52 Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Tue, 29 Oct 2024 12:54:44 +0000 Subject: docs/system/arm: Add placeholder docs for mcimx6ul-evk and mcimx7d-sabre MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add placeholder docs for the mcimx6ul-evk and mcimx7d-sabre boards. Signed-off-by: Peter Maydell Reviewed-by: Alex Bennée Reviewed-by: Cédric Le Goater Reviewed-by: Alistair Francis Message-id: 20241018141332.942844-7-peter.maydell@linaro.org --- docs/system/arm/mcimx6ul-evk.rst | 5 +++++ docs/system/arm/mcimx7d-sabre.rst | 5 +++++ docs/system/target-arm.rst | 2 ++ 3 files changed, 12 insertions(+) create mode 100644 docs/system/arm/mcimx6ul-evk.rst create mode 100644 docs/system/arm/mcimx7d-sabre.rst (limited to 'docs') diff --git a/docs/system/arm/mcimx6ul-evk.rst b/docs/system/arm/mcimx6ul-evk.rst new file mode 100644 index 0000000..8871138 --- /dev/null +++ b/docs/system/arm/mcimx6ul-evk.rst @@ -0,0 +1,5 @@ +NXP MCIMX6UL-EVK (``mcimx6ul-evk``) +=================================== + +The ``mcimx6ul-evk`` machine models the NXP i.MX6UltraLite Evaluation Kit +MCIMX6UL-EVK development board. It has a single Cortex-A7 CPU. diff --git a/docs/system/arm/mcimx7d-sabre.rst b/docs/system/arm/mcimx7d-sabre.rst new file mode 100644 index 0000000..c5d35af --- /dev/null +++ b/docs/system/arm/mcimx7d-sabre.rst @@ -0,0 +1,5 @@ +NXP MCIMX7D Sabre (``mcimx7d-sabre``) +===================================== + +The ``mcimx7d-sabre`` machine models the NXP SABRE Board MCIMX7SABRE, +based an an i.MX7Dual SoC. diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst index ace36d1..1f806cf 100644 --- a/docs/system/target-arm.rst +++ b/docs/system/target-arm.rst @@ -97,6 +97,8 @@ undocumented; you can get a complete list by running arm/nrf arm/nuvoton arm/imx25-pdk + arm/mcimx6ul-evk + arm/mcimx7d-sabre arm/orangepi arm/raspi arm/collie -- cgit v1.1 From a892728021e581019cbc9d6d19c4f20cdcd1afa0 Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Tue, 29 Oct 2024 12:54:45 +0000 Subject: docs/system/target-arm.rst: Remove "many boards are undocumented" note MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We now have at least placeholder documentation for every Arm board, so we can remove the apologetic note that says that there are undocumented ones which you can only find out about via the ``--machine help`` option. Signed-off-by: Peter Maydell Reviewed-by: Alex Bennée Reviewed-by: Cédric Le Goater Reviewed-by: Alistair Francis Message-id: 20241018141332.942844-8-peter.maydell@linaro.org --- docs/system/target-arm.rst | 4 ---- 1 file changed, 4 deletions(-) (limited to 'docs') diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst index 1f806cf..9aaa9c4 100644 --- a/docs/system/target-arm.rst +++ b/docs/system/target-arm.rst @@ -63,10 +63,6 @@ large amounts of RAM. It also supports 64-bit CPUs. Board-specific documentation ============================ -Unfortunately many of the Arm boards QEMU supports are currently -undocumented; you can get a complete list by running -``qemu-system-aarch64 --machine help``. - .. This table of contents should be kept sorted alphabetically by the title text of each file, which isn't the same ordering -- cgit v1.1 From 361dfa9757e8b7c233592f4d235b63aa834ce57a Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Tue, 29 Oct 2024 12:54:45 +0000 Subject: docs/devel/reset: Fix minor grammatical error Fix a minor grammatical error in the reset documentation: a couple of missing words and a singular/plural swap. Signed-off-by: Axel Heider Message-id: 173006362760.28451.11319467059840843945-1@git.sr.ht [PMM: squashed two patches into one, tweaked commit message] Reviewed-by: Peter Maydell Signed-off-by: Peter Maydell --- docs/devel/reset.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/devel/reset.rst b/docs/devel/reset.rst index 74c7c01..adefd59 100644 --- a/docs/devel/reset.rst +++ b/docs/devel/reset.rst @@ -286,8 +286,8 @@ every reset child of the given resettable object. All children must be resettable too. Additional parameters (a reset type and an opaque pointer) must be passed to the callback too. -In ``DeviceClass`` and ``BusClass`` the ``ResettableState`` is located -``DeviceState`` and ``BusState`` structure. ``child_foreach()`` is implemented +In ``DeviceClass`` and ``BusClass`` the ``ResettableState`` is located in the +``DeviceState`` and ``BusState`` structures. ``child_foreach()`` is implemented to follow the bus hierarchy; for a bus, it calls the function on every child device; for a device, it calls the function on every bus child. When we reset the main system bus, we reset the whole machine bus tree. -- cgit v1.1