Doc: content updates to ACRN Config Tool and Build frm Source

Signed-off-by: Deb Taylor <deb.taylor@intel.com>

doc/tutorials/acrn_configuration_tool.rst

@@ -2,23 +2,26 @@
 
 ACRN Configuration Tool
 #######################
-ACRN configuration tool is designed for System Integrators / Tier1’s to customize
-ACRN to meet their own needs. It consists of two tools. The ``Kconfig`` tool and the 
-``acrn-config`` tool. The latter allows users to provision VMs via a WebUI and configure 
-the hypervisor from XML files at build time.
 
-ACRN Configurations Introduction
-********************************
-There are three types of configurations in ACRN: Hypervisor,
-Board, and VM. We'll explore each of these in the following sections.
+The ACRN configuration tool is designed for System Integrators / Tier 1s to
+customize ACRN to meet their own needs. It consists of two tools, the
+``Kconfig`` tool and the ``acrn-config`` tool. The latter allows users to provision
+VMs via a web interface and configure the hypervisor from XML files at build time.
+
+Introduction
+************
+
+ACRN includes three types of configurations: Hypervisor, Board, and VM. Each
+are discussed in the following sections.
 
 Hypervisor configuration
 ========================
-Hypervisor configuration selects a working scenario and target
+
+The hypervisor configuration selects a working scenario and target
 board by configuring the hypervisor image features and capabilities such as
 setting up the log and the serial port.
 
-Hypervisor configuration is done using the ``Kconfig`` ``make
+The hypervisor configuration uses the ``Kconfig`` ``make
 menuconfig`` mechanism.  The configuration file is located at::
 
    acrn-hypervisor/hypervisor/arch/x86/configs/Kconfig
@@ -27,29 +30,30 @@ A board-specific ``defconfig`` file, located at::
 
    acrn-hypervisor/hypervisor/arch/x86/configs/$(BOARD)/$(BOARD).config
 
-will be loaded first, as the default ``Kconfig`` for the specified board.
+is loaded first; it is the default ``Kconfig`` for the specified board.
 
 Board configuration
 ===================
+
 The board configuration stores board-specific settings referenced by the
-ACRN hypervisor. This includes *scenario-relevant* information such as
-board settings, root device selection, and kernel cmdline, and
-*scenario-irrelevant** hardware-specific information such as ACPI/PCI
-and BDF information.  The board configuration is organized as
+ACRN hypervisor. This includes **scenario-relevant** information such as
+board settings, root device selection, and the kernel cmdline. It also includes
+**scenario-irrelevant** hardware-specific information such as ACPI/PCI
+and BDF information. The board configuration is organized as
 ``*.c/*.h`` files located at::
 
    acrn-hypervisor/hypervisor/arch/x86/$(BOARD)/
 
 VM configuration
 =================
-VM configuration includes *scenario-based* VM configuration
-information, used to describe the characteristics and attributes for VMs
-on each user scenario, and *launch script-based* VM configuration, where
-parameters are passed to the device model to launch post-launched User
-VMs.
 
-Scenario based VM configurations are organized
-as ``*.c/*.h`` files located at::
+VM configuration includes **scenario-based** VM configuration
+information that is used to describe the characteristics and attributes for
+VMs on each user scenario. It also includes **launch script-based** VM
+configuration information, where parameters are passed to the device model
+to launch post-launched User VMs.
+
+Scenario based VM configurations are organized as ``*.c/*.h`` files located at::
 
    acrn-hypervisor/hypervisor/scenarios/$(SCENARIO)/
 
@@ -57,121 +61,147 @@ User VM launch script samples are located at::
 
    acrn-hypervisor/devicemodel/samples/
 
-ACRN Configuration XMLs
+ACRN configuration XMLs
 ***********************
-ACRN configuration introduced three kinds of XMLs for acrn-config usage:
-**board**, **scenario** and **launch** XML.
-All scenario-irrelevant hardware-specific information of Board configuration is
-stored in **board** XML. The XML is generated by ``misc/acrn-config/target/board_parser.py``
-which shall be run on target board.
-The scenario-relevant Board configuration and scenario-based VM
-configuration are stored in **scenario** XML. The launch script-based VM
-configuration is stored in **launch** XML. These two XMLs could be customized
-with WebUI tool at ``misc/acrn-config/config-app/app.py``. End users could load
-their own configurations by importing customized XMLs or save the
+
+The ACRN configuration includes three kinds of XMLs for acrn-config usage:
+``board``, ``scenario``, and ``launch`` XML. All scenario-irrelevant
+hardware-specific information for the board configuration is
+stored in the ``board`` XML. The XML is generated by ``misc/acrn-config/target/board_parser.py``
+which runs on the target board. The scenario-relevant board and
+scenario-based VM
+configurations are stored in the ``scenario`` XML. The launch script-based VM
+configuration is stored in the ``launch`` XML. These two XMLs can be customized
+by using the web inteface tool at ``misc/acrn-config/config-app/app.py``. End users can load
+their own configurations by importing customized XMLs or by saving the
 configurations by exporting XMLs.
 
+
 Board XML format
 ================
-Board XML has a root element of ``acrn-config`` with attribute of **board**, i.e.
+
+The board XML has an ``acrn-config`` root element and a ``board`` attribute:
 
 .. code-block:: xml
 
    <acrn-config board=”BOARD”>
 
-As an input for ``acrn-config`` tool, end users do not need to care about the
-format of board XML and should not modify it.
+As an input for the ``acrn-config`` tool, end users do not need to care about the format of board XML and should not modify it.
 
 Scenario XML format
 ===================
-Scenario XML has a root element of ``acrn-config`` with attributes of **board**
-and **scenario**, i.e.
+
+The scenario XML has an ``acrn-config`` root element as well as ``board`` and ``scenario`` attributes:
 
 .. code-block:: xml
 
    <acrn-config board=”BOARD” scenario=”SCENARIO”>
 
-Below is the usage of other elements:
+Additional scenario XML elements:
 
-:``vm``: Specify the VM with VMID by its "id" attribute.
-:``load_order``: Specify the VM by its load order:
-             PRE_LAUNCHED_VM, SOS_VM or POST_LAUNCHED_VM.
-:``name`` under parent of ``vm``: Specify the VM name which will be
-                          shown in hypervisor console command: vm_list.
-:``uuid``: UUID of the VM. It is for internal use and not configurable.
-:``guest_flags``: Select all applicable flags for the VM.
-:``size`` under parent of ``epc_section``: SGX EPC section base, must be page aligned.
-:``base`` under parent of ``epc_section``: SGX EPC section size in Bytes, must be page aligned.
-:``clos``: Class of Service for Cache Allocation Technology. Please refer SDM 17.19.2
-       for details and use with caution.
-:``start_hpa``: The start physical address in host for the VM.
-:``size`` under parent of ``memory``: The memory size in Bytes for the VM
-:``name`` under parent of ``os_config``: Specify the OS name of VM, currently it is not
-                                 referenced by hypervisor code.
-:``kern_type``: Specify the kernel image type so that hypervisor could load it correctly.
-            Currently support KERNEL_BZIMAGE and KERNEL_ZEPHYR.
-:``kern_mod``: The tag for kernel image which act as multiboot module, it must exactly match
-           the module tag in GRUB multiboot cmdline.
-:``bootargs`` under parent of ``os_config``: It is for internal use and not configurable. Please
-           specify the kernel boot arguments in bootargs under parent of board_private.
-:``vuart``: Specify the vuart(A.K.A COM) with vUART ID by its "id" attribute. Please refer
-        :ref:`vuart_config` for detailed vUART setting.
-:``type`` under parent of ``vuart``: vUART(A.K.A COM) type, currently only support legacy PIO mode.
-:``base`` under parent of ``vuart``: vUART(A.K.A COM) enabling switch. Enable by exposing its
-                             COM_BASE(SOS_COM_BASE for Service VM), disable by returning INVALID_COM_BASE.
-:``irq`` under parent of ``vuart``: vCOM irq.
-:``target_vm_id``: COM2 is used for VM communications. When it is enabled, please specify which
-               target VM that current VM connect to.
-:``target_uart_id``: target vUART ID that vCOM2 connect to.
-:``pci_dev_num``: pci devices number of the VM, it is hard-coded for each scenario so is not configurable for now.
-:``pci_devs``: PCI devices list of the VM, it is hard-coded for each scenario so is not configurable for now.
-:``board_private``: Stores scenario-relevant Board configuration.
-:``rootfs``: rootfs for Linux kernel.
-:``console``: ttyS console for Linux kernel
-:``bootargs`` under parent of ``board_private``: Specify kernel boot arguments.
+``vm``: Specify the VM with VMID by its "id" attribute.
+
+``load_order``: Specify the VM by its load order: PRE_LAUNCHED_VM, SOS_VM or POST_LAUNCHED_VM.
+
+``name`` under parent of ``vm``: Specify the VM name which will be shown in the hypervisor console command: vm_list.
+
+``uuid``: UUID of the VM. It is for internal use and is not configurable.
+
+``guest_flags``: Select all applicable flags for the VM.
+
+``size`` under parent of ``epc_section``: SGX EPC section base; must be page aligned.
+
+``base`` under parent of ``epc_section``: SGX EPC section size in Bytes; must be page aligned.
+
+``clos``: Class of Service for Cache Allocation Technology. Refer to the SDM 17.19.2 for details and use with caution.
+
+``start_hpa``: The start physical address in host for the VM.
+
+``size`` under parent of ``memory``: The memory size in Bytes for the VM.
+
+``name`` under parent of ``os_config``: Specify the OS name of VM; currently, it is not referenced by the hypervisor code.
+
+``kern_type``: Specify the kernel image type so that the hypervisor can load it correctly. Currently supports KERNEL_BZIMAGE and KERNEL_ZEPHYR.
+
+``kern_mod``: The tag for the kernel image that acts as a multiboot module; it must exactly match the module tag in the GRUB multiboot cmdline.
+
+``bootargs`` under parent of ``os_config``: For internal use and is not configurable. Specify the kernel boot arguments in bootargs under the parent of board_private.
+
+``vuart``: Specify the vuart (A.K.A COM) with the vUART ID by its "id" attribute. Refer to :ref:`vuart_config` for detailed vUART settings.
+
+``type`` under parent of ``vuart``: vUART (A.K.A COM) type, currently only supports the legacy PIO mode.
+
+``base`` under parent of ``vuart``: vUART (A.K.A COM) enabling switch. Enable by exposing its COM_BASE (SOS_COM_BASE for Service VM); disable by returning INVALID_COM_BASE.
+
+``irq`` under parent of ``vuart``: vCOM irq.
+
+``target_vm_id``: COM2 is used for VM communications. When it is enabled, specify which target VM the current VM connects to.
+
+``target_uart_id``: Target vUART ID that vCOM2 connects to.
+
+``pci_dev_num``: PCI devices number of the VM; it is hard-coded for each scenario so it is not configurable for now.
+
+``pci_devs``: PCI devices list of the VM; it is hard-coded for each scenario so it is not configurable for now.
+
+``board_private``: Stores scenario-relevant board configuration.
+
+``rootfs``: rootfs for the Linux kernel.
+
+``console``: ttyS console for the Linux kernel.
+
+``bootargs`` under parent of ``board_private``: Specify kernel boot arguments.
 
 Launch XML format
 =================
-Launch XML has a root element of ``acrn-config`` with attributes of
-**board**, **scenario** and **uos_launcher**, i.e.
+
+The launch XML has an ``acrn-config`` root element as well as
+``board``, ``scenario`` and ``uos_launcher`` attributes:
 
 .. code-block:: xml
 
    <acrn-config board="BOARD" scenario="SCENARIO" uos_launcher="UOS_NUMBER">
 
-Attribute of **uos_launcher** specified the number of User VM that current scenario has:
+Attributes of the ``uos_launcher`` specify the number of User VMs that the current scenario has:
 
-:``uos``: Specify the User VM with its relative ID to Service VM by "id" attribute.
-:``uos_type``: Specify the User VM type, like CLEARLINUX, ANDROID, or VXWORKS
-:``rtos_type``: Specify User VM Realtime capability: Soft RT, Hard RT, or none of them.
-:``cpu_num``: Specify max cpu number for the VM.
-:``mem_size``: Specify User VM memory size in Mbyte.
-:``gvt_args``: GVT argument for the VM.
-:``vbootloader``: virtual bootloader type, currently only support OVMF.
-:``rootfs_dev``: Which device where User VM rootfs located.
-:``rootfs_img``: User VM rootfs image file including path.
-:``console_type``: Specify User VM console is virtio or vUART, please refer
-               :ref:`vuart_config` for details.
-:``poweroff_channel``: Specify User VM power off channel is through IOC or Powerbutton or vUART.
-:``passthrough_devices``: select the passthrough device from lspci list, currently we
-                      support selection for usb_xdci, audio, audio_codec, ipu, ipu_i2c,
-                      cse, wifi, Bluetooth, sd_card, ethernet, wifi, sata and nvme.
+``uos``: Specify the User VM with its relative ID to Service VM by the "id" attribute.
 
-.. note:: Attribute of **configurable** and **readonly** are used to mark whether
-   the items is configurable for user. When ``configurable=”0”`` and ``readonly=”true”``,
-   the item is not configurable from WebUI. Particularly, the item would not be
-   shown on UI when ``configurable=“0”``.
+``uos_type``: Specify the User VM type, such as  CLEARLINUX, ANDROID, or VXWORKS.
+
+``rtos_type``: Specify the User VM Realtime capability: Soft RT, Hard RT, or none of them.
+
+``cpu_num``: Specify the max cpu number for the VM.
+
+``mem_size``: Specify the User VM memory size in Mbyte.
+
+``gvt_args``: GVT argument for the VM.
+
+``vbootloader``: Virtual bootloader type; currently only supports OVMF.
+
+``rootfs_dev``: The device where User VM rootfs located.
+
+``rootfs_img``: User VM rootfs image file including path.
+
+``console_type``: Specify whether the User VM console is virtio or vUART; refer to :ref:`vuart_config` for details.
+
+``poweroff_channel``: Specify whether the User VM power off channel is through the IOC, Powerbutton, or vUART.
+
+``passthrough_devices``: Select the passthrough device from the lspci list; currently we support: usb_xdci, audio, audio_codec, ipu, ipu_i2c, cse, wifi, Bluetooth, sd_card, ethernet, wifi, sata, and nvme.
+
+.. note::
+
+   The ``configurable`` and ``readonly`` attributes are used to mark whether the items is configurable for users. When ``configurable=”0”`` and ``readonly=”true”``, the item is not configurable from the web interface. When ``configurable=“0”``. the item does not appear on the interface.
 
 Configuration tool workflow
 ***************************
 
 Hypervisor configuration workflow
 ==================================
-Hypervisor configuration is based on the ``Kconfig`` ``make menuconfig``
-mechanism.  You begin by creating a board specific ``defconfig`` file to
+
+The hypervisor configuration is based on the ``Kconfig`` ``make menuconfig``
+mechanism. Begin by creating a board-specific ``defconfig`` file to
 set up the default ``Kconfig`` values for the specified board.
-Then you configure the hypervisor build options using the ``make
-menuconfig`` graphical interface.  The resulting ``.config`` file is
+Next, configure the hypervisor build options using the ``make
+menuconfig`` graphical interface. The resulting ``.config`` file is
 used by the ACRN build process to create a configured scenario- and
 board-specific hypervisor image.
 
@@ -185,13 +215,15 @@ board-specific hypervisor image.
 
    menuconfig interface sample
 
-Please refer to the :ref:`getting-started-hypervisor-configuration` for
-detailed steps.
+Refer to :ref:`getting-started-hypervisor-configuration` for
+detailed configuration steps.
+
 
 .. _vm_config_workflow:
 
 Board and VM configuration workflow
 ===================================
+
 Python offline tools are provided to configure Board and VM configurations.
 The tool source folder is located at::
 
@@ -199,13 +231,13 @@ The tool source folder is located at::
 
 Here is the offline configuration tool workflow:
 
-#. Get board info.
+#. Get the board info.
 
-   a. Set up native Linux environment on target board.
-   #. Copy ``target`` folder into target file system and then run
+   a. Set up a native Linux environment on the target board.
+   #. Copy the ``target`` folder into the target file system and then run the
       ``sudo python3 board_parser.py $(BOARD)`` command.
    #. A $(BOARD).xml that includes all needed hardware-specific information
-      will be generated in the ``./out/`` folder. (Here ``$(BOARD)`` is the
+      is generated in the ``./out/`` folder. (Here ``$(BOARD)`` is the
       specified board name)
 
       | **Native Linux requirement:**
@@ -215,197 +247,176 @@ Here is the offline configuration tool workflow:
 
 #. Customize your needs.
 
-   a. Copy ``$(BOARD).xml`` to the host develop machine.
-   #. Run ``misc/acrn-config/config-app/app.py`` tool on the host machine
-      and import the ``$(BOARD).xml``, select your working scenario under
-      **Scenario Setting** and input the desired scenario settings. The tool
-      will do a sanity check on the input based on ``$(BOARD).xml``. The
-      customized settings could be exported to your own ``$(SCENARIO).xml``.
-   #. In the configuration tool UI, input the launch script parameters for the
-      post-launched User VM under **Launch Setting**. The tool will sanity
-      check the input based on both ``$(BOARD).xml`` and ``$(SCENARIO).xml``
-      and then export settings to your ``$(LAUNCH).xml``.
-   #. The user defined XMLs could be imported by acrn-config for modification.
+   a. Copy ``$(BOARD).xml`` to the host development machine.
+   #. Run the ``misc/acrn-config/config-app/app.py`` tool on the host machine and import the $(BOARD).xml. Select your working scenario under  **Scenario Setting** and input the desired scenario settings. The tool will do a sanity check on the input based on the $(BOARD).xml. The customized settings can be exported to your own $(SCENARIO).xml.
+   #. In the configuration tool UI, input the launch script parameters for the post-launched User VM under **Launch Setting**. The tool will sanity check the input based on both the $(BOARD).xml and $(SCENARIO).xml and then export settings to your $(LAUNCH).xml.
+   #. The user defined XMLs can be imported by acrn-config for modification.
 
-   .. note:: Please refer :ref:`acrn_config_tool_ui` for more details on
+ .. note:: Refer to :ref:`acrn_config_tool_ui` for more details on
       the configuration tool UI.
 
-#. Auto generate code.
+3. Auto generate the code.
 
    Python tools are used to generate configurations in patch format.
-   The patches will be applied to your local ``acrn-hypervisor`` git tree
+   The patches are applied to your local ``acrn-hypervisor`` git tree
    automatically.
 
-   a. Generate a patch for the board-related configuration with:
-
-      .. code-block:: console
+   a. Generate a patch for the board-related configuration::
 
          cd misc/board_config
          python3 board_cfg_gen.py --board $(BOARD).xml --scenario $(SCENARIO).xml
 
-      .. note:: This could be done by click **Generate Board SRC** in acrn-config UI.
+      Note that this can also be done by clicking **Generate Board SRC** in the acrn-config UI.
 
-   #. Generate a patch for scenario-based VM configuration with:
 
-      .. code-block:: console
+   #. Generate a patch for scenario-based VM configuration::
 
          cd misc/scenario_config
-         python3 scenario_cfg_gen.py --board $(BOARD).xml --scenario $(SCENARIO).xml
+         python3 scenario_cfg_gen.py --board $(BOARD).xml --scenario
 
-      .. note:: This could be done by click **Generate Scenario SRC** in acrn-config UI.
-
-   #. Generate the launch script for the specified post-launched User VM with:
-
-      .. code-block:: console
+   #. Generate the launch script for the specified
+      post-launch User VM::
 
          cd misc/launch_config
-         python3 launch_cfg_gen.py --board $(BOARD).xml --scenario $(SCENARIO).xml --launch $(LAUNCH).xml$
+         python3 launch_cfg_gen.py --board $(BOARD).xml --scenario $(SCENARIO).xml --launch $(LAUNCH_PARAM).xml$
 
-      .. note:: This could be done by click **Generate Launch Script** in acrn-config UI.
+      Note that this can also be done by clicking **Generate Launch Script** in the acrn-config UI.
 
-#. Re-build the ACRN hypervisor. Please refer to the
-   :ref:`getting-started-building` to re-build ACRN hypervisor on host machine.
+#. Re-build the ACRN hypervisor. Refer to
+   :ref:`getting-started-building` to re-build the ACRN hypervisor on the host machine.
 
-#. Deploy VMs and run ACRN hypervisor on target board.
+#. Deploy VMs and run ACRN hypervisor on the target board.
 
 .. figure:: images/offline_tools_workflow.png
    :align: center
 
-   offline tool workflow
+   Offline tool workflow
+
 
 .. _acrn_config_tool_ui:
 
-How to use ACRN configuration app
-*********************************
-ACRN configuration app is a web UI application to read board info, configure and validate
-scenario setting, automatically generate a patch for board related configuration,
-scenario-based VM configuration, configure and validate launch settings, generate
-the launch scripts for the specified post-launched User VMs.
+Use the ACRN configuration app
+******************************
+
+The ACRN configuration app is a web user interface application that performs the following:
+- reads board info
+- configures and validates scenario settings
+- automatically generates patches for board-related configurations and
+scenario-based VM configurations
+- configures and validates launch settings
+- generates launch scripts for the specified post-launched User VMs.
 
 Prerequisites
 =============
+
 .. _get acrn repo guide:
    https://projectacrn.github.io/latest/getting-started/building-from-source.html#get-the-acrn-hypervisor-source-code
 
 - Follow the :ref:`instruction <getting-started-building>` to install the
   ACRN hypervisor dependencies and tools on your development host.
 
-- Follow the `get acrn repo guide`_ to download ACRN hypervisor repo to your host.
+- Follow the `get acrn repo guide`_ to download the ACRN hypervisor repo to your host.
 
 - Install ACRN configuration app dependencies:
 
-  .. code-block:: console
+  .. code-block:: none
 
      $ cd ~/acrn-hypervisor/misc/acrn-config/config_app
      $ sudo pip3 install -r requirements
 
-How to use ACRN configuration app
-=================================
-#. Launch ACRN configuration app:
+Instructions
+============
 
-   .. code-block:: console
+#. Launch the ACRN configuration app:
+
+   .. code-block:: none
 
       $ python3 app.py
 
-#. The browser should be launched and navigated to the website:
-   `<http://127.0.0.1:5001/>`_ automatically, or you may need to visit this website manually.
+#. Open a browser and navigate to the website
+   `<http://127.0.0.1:5001/>`_ automatically, or you may need to visit this website manually. Make sure you can connect to open network from browser because the app needs to download some javascript files.
 
-   .. note:: Make sure you can connect to open network from browser because the app needs
-      to download some javascript files.
+   .. note:: The ACRN configuration app is supported on Chrome, Firefox, and MS Edge, do not use IE.
 
-   .. note:: The ACRN configuration app is supported on Chrome, Firefox or MS Edge, do not use IE.
-
-   The website as shown below:
+   The website is shown below:
 
    .. figure:: images/config_app_main_menu.png
       :align: center
-      :scale: 70%
       :name: ACRN config tool main menu
 
 #. Set the board info:
 
-   a. Click the button **Import Board info**.
+   a. Click **Import Board info**.
 
       .. figure:: images/click_import_board_info_button.png
          :align: center
-         :scale: 70%
 
-   #. Upload the board info you have generated by ACRN config tool.
+   #. Upload the board info you have generated from the ACRN config tool.
 
-   #. After board info uploaded, you will see the board name from the Board info list,
-      select the board name to be configured.
+   #. After board info is uploaded, you will see the board name from the Board info list. Select the board name to be configured.
 
       .. figure:: images/select_board_info.png
          :align: center
-         :scale: 70%
 
-#. Choose a scenario from the “Scenario Setting” menu which lists all the scenarios
-   including default scenarios and user-defined scenarios for the board you selected
-   in the previous step. The scenario configuration xmls are located in
+#. Choose a scenario from the **Scenario Setting** menu which lists all the scenarios,
+   including the efault scenarios and the user-defined scenarios for the board you selected
+   in the previous step. The scenario configuration xmls are located at
    ``acrn-hypervisor/misc/xmls/config-xmls/[board]/``.
 
    .. figure:: images/choose_scenario.png
       :align: center
-      :scale: 70%
 
-#. It is also allowed to use a customized scenario xml by clicking the Import button.
-   The configuration app will automatically direct to the new scenario xml once the import is completed.
+   Note that you can also use a customized scenario xml by clicking **Import**.
+   The configuration app automatically directs to the new scenario xml once the import is complete.
 
-#. The configurable items will be displayed after one scenario is selected. Here is
+#. The configurable items display after one scenario is selected. Here is
    the example of "SDC" scenario:
 
    .. figure:: images/configure_scenario.png
       :align: center
-      :scale: 70%
 
-   - You can edit those items directly in the text boxes, choose single or even multiple
+   - You can edit these items directly in the text boxes, cor you can choose single or even multiple
      items from the drop down list.
 
    - Read-only items are marked as grey.
 
    - Hover the mouse pointer over the item to display the description.
 
-#. Click **Export** button to save the scenario xml, you can rename it in the pop-up modal.
+#. Click **Export** to save the scenario xml; you can rename it in the pop-up modal.
 
    .. note:: All customized scenario xmls will be in user-defined groups which located in
       ``acrn-hypervisor/misc/xmls/config-xmls/[board]/user_defined/``.
 
-   Before saving the scenario xml, the configuration app will validate the configurable items;
-   If there are errors, the configuration app will list all wrong configurable items and show errors as below:
+   Before saving the scenario xml, the configuration app will validate the configurable items. If errors exist, the configuration app lists all wrong configurable items and shows the errors as below:
 
    .. figure:: images/err_acrn_configuration.png
       :align: center
-      :scale: 70%
 
-   After the scenario is saved, the page will automatically direct to the saved scenario xmls.
-   You can delete the configured scenario by click button **Export** -> **Remove**.
+   After the scenario is saved, the page automatically directs to the saved scenario xmls.
+   You can delete the configured scenario by clicking **Export** -> **Remove**.
 
-#. Click **Generate Board SRC** to save current scenario setting and then generate
+#. Click **Generate Board SRC** to save the current scenario setting and then generate
    a patch for the board-related configuration source codes in
    ``acrn-hypervisor/hypervisor/arch/x86/configs/[board]/``.
 
-#. Click **Generate Scenario SRC** to save current scenario setting and then generate
-   a patch for scenario-based VM configuration scenario source codes in
+#. Click **Generate Scenario SRC** to save the current scenario setting and then generate
+   a patch for the scenario-based VM configuration scenario source codes in
    ``acrn-hypervisor/hypervisor/scenarios/[scenario]/``.
 
-#. **Launch Setting** is quite similar with **Scenario Setting**:
+The **Launch Setting** is quite similar to the **Scenario Setting**:
 
-   a. Upload board info or selecting one board as current board.
+#. Upload board info or select one board as the current board.
 
-   #. Import your local launch setting xml by clicking button **Import** or selecting one launch
-      setting xml from menu.
+#. Import your local launch setting xml by clicking **Import** or selecting one launch setting xml from the menu.
 
-   #. Select one scenario for current launch setting from the drop down box **Select Scenario**.
+#. Select one scenario for the current launch setting from the **Select Scenario** drop down box.
 
-   #. Configure the items for current launch setting.
+#. Configure the items for the current launch setting.
 
-   #. Save current launch setting to user defined xml files by clicking the button **Export**.
-      The configuration app will validate current configuration and will list all wrong configurable
-      items and show errors.
+#. Save the current launch setting to the user-defined xml files by clicking **Export**. The configuration app validates the current configuration and lists all wrong configurable items and shows errors.
 
-   #. Click the button **Generate Launch Script** to save current launch setting and then
-      generate launch script.
+#. Click **Generate Launch Script** to save the current launch setting and then generate the launch script.
+
+   .. figure:: images/generate_launch_script.png
+      :align: center
 
-      .. figure:: images/generate_launch_script.png
-         :align: center
-         :scale: 70%