docs: update qemu guide for efuse commands

- add mention of qemu guide in security related chapters
- also added a note about secure boot v2 config in qemu workflow

docs/en/api-guides/tools/qemu.rst

@@ -1,6 +1,8 @@
 QEMU Emulator
 =============
 
+{IDF_TARGET_CRYPT_CNT:default="SPI_BOOT_CRYPT_CNT",esp32="FLASH_CRYPT_CNT"}
+
 :link_to_translation:`zh_CN:[中文]`
 
 Espressif maintains a `fork <https://github.com/espressif/qemu>`_ of the QEMU emulator with support for {IDF_TARGET_NAME}. This fork implements emulation of the CPU, memory, and several peripherals of {IDF_TARGET_NAME}. For more information about QEMU for {IDF_TARGET_NAME}, see the `QEMU README documentation <https://github.com/espressif/esp-toolchain-docs/blob/main/qemu/README.md>`_.
@@ -119,13 +121,37 @@ QEMU supports emulation of eFuses. This can be a convenient way to test security
 
 You can use :doc:`idf.py<idf-py>` eFuse-related commands to program eFuses. When you run any of these commands together with ``qemu`` command, the eFuses are programmed in QEMU, and the ``qemu_efuse.bin`` file is updated. For example,
 
+.. only:: not SOC_FLASH_ENCRYPTION_XTS_AES
+
+    .. code-block:: console
+
+        idf.py qemu efuse-burn {IDF_TARGET_CRYPT_CNT} 1
+        idf.py qemu efuse-burn-key flash_encryption my_flash_encryption_key.bin
+
+.. only:: SOC_FLASH_ENCRYPTION_XTS_AES
+
+    .. code-block:: console
+
+        idf.py qemu efuse-burn {IDF_TARGET_CRYPT_CNT} 1
+        idf.py qemu efuse-burn-key BLOCK my_flash_encryption_key.bin KEYPURPOSE
+
+    For details regarding the ``BLOCK`` and ``KEYPURPOSE``, please refer to the :doc:`../../security/flash-encryption` guide.
+
+To dump the eFuse summary, please use the following command:
+
 .. code-block:: console
 
-    idf.py qemu efuse-burn FLASH_CRYPT_CNT 1
+    idf.py qemu efuse-summary
 
 By default, the values of eFuses are read from and written to the ``qemu_efuse.bin`` file in the build directory. You can specify a different file using the ``--efuse-file`` option. For example,
 
 .. code-block:: console
 
-    idf.py qemu --efuse-file my_efuse.bin efuse-burn FLASH_CRYPT_CNT 1
+    idf.py qemu --efuse-file my_efuse.bin efuse-burn {IDF_TARGET_CRYPT_CNT} 1
     idf.py qemu --efuse-file my_efuse.bin monitor
+
+Emulating Secure Boot
+~~~~~~~~~~~~~~~~~~~~~
+
+QEMU supports emulation of secure boot v2 scheme. Please keep :ref:`CONFIG_SECURE_BOOT_FLASH_BOOTLOADER_DEFAULT` enabled to include signed bootloader image into the qemu image artifact.
+

docs/en/security/security-features-enablement-workflows.rst

@@ -18,6 +18,11 @@ When enabling security features on ESP32 SoCs, it is recommended that power supp
 
 This guide describes a set of workflows to enable security features on the device with the assistance of an external host machine. These workflows are broken down into various stages, with each stage generating signing/encryption keys on the host machine. This allows for greater chances of recovery in case of power or other failures. Furthermore, these workflows expedites the overall provisioning process via the use of the host machine (e.g., encrypting firmware on the host is quicker than on the device).
 
+.. only:: TARGET_SUPPORT_QEMU
+
+   .. important::
+
+      It is possible to try out the security features for {IDF_TARGET_NAME} target SoC under :doc:`../api-guides/tools/qemu` virtually. Once the security workflow is established, you can then proceed to the real hardware.
 
 Goals
 -----

docs/en/security/security.rst

@@ -13,6 +13,12 @@ This guide provides an overview of the overall security features available in va
 
     In this guide, most used commands are in the form of ``idf.py secure-<command>``, which is a wrapper around corresponding ``espsecure.py <command>``. The ``idf.py`` based commands provides more user-friendly experience, although may lack some of the advanced functionality of their ``espsecure.py`` based counterparts.
 
+.. only:: TARGET_SUPPORT_QEMU
+
+   .. important::
+
+      It is possible to try out the security features for {IDF_TARGET_NAME} target SoC under :doc:`../api-guides/tools/qemu` virtually. Once the security workflow is established, you can then proceed to the real hardware.
+
 Goals
 -----