doc: use kbd consistently and fix misspellings

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>

doc/developer-guides/hld/hv-console.rst

@@ -70,7 +70,7 @@ Specifically:
    the hypervisor shell. Inputs to the physical UART will be
    redirected to the vUART starting from the next timer event.
 
--  The vUART is deactivated after a :kbd:`Ctrl + Space` hotkey is received
+-  The vUART is deactivated after a :kbd:`Ctrl` + :kbd:`Space` hotkey is received
    from the physical UART. Inputs to the physical UART will be
    handled by the hypervisor shell starting from the next timer
    event.

doc/developer-guides/hld/ivshmem-hld.rst

@@ -186,7 +186,7 @@ Inter-VM Communication Security hardening (BKMs)
 ************************************************
 
 As previously highlighted, ACRN 2.0 provides the capability to create shared
-memory regions between Post-Launch user VMs known as “Inter-VM Communication”. 
+memory regions between Post-Launch user VMs known as "Inter-VM Communication".
 This mechanism is based on ivshmem v1.0 exposing virtual PCI devices for the
 shared regions (in Service VM's memory for this release). This feature adopts a
 community-approved design for shared memory between VMs, following same
@@ -194,7 +194,7 @@ specification for KVM/QEMU (`Link <https://git.qemu.org/?p=qemu.git;a=blob_plain
 
 Following the ACRN threat model, the policy definition for allocation and
 assignment of these regions is controlled by the Service VM, which is part of
-ACRN’s Trusted Computing Base (TCB). However, to secure inter-VM communication
+ACRN's Trusted Computing Base (TCB). However, to secure inter-VM communication
 between any userspace applications that harness this channel, applications will
 face more requirements for the confidentiality, integrity, and authenticity of
 shared or transferred data. It is the application development team's
@@ -218,17 +218,17 @@ architecture and threat model for your application.
    - Add restrictions based on behavior or subject and object rules around information flow and accesses.
    - In Service VM, consider the ``/dev/shm`` device node as a critical interface with special access requirement. Those requirements can be fulfilled using any of the existing opensource MAC technologies or even ACLs depending on the OS compatibility (Ubuntu, Windows, etc..) and integration complexity.
    - In the User VM, the shared memory region can be accessed using ``mmap()`` of UIO device node. Other complementary info can be found under:
-   
+
       - ``/sys/class/uio/uioX/device/resource2`` --> shared memory base address
       - ``/sys/class/uio/uioX/device/config`` --> shared memory Size.
-    
+
    - For Linux-based User VMs, we recommend using the standard ``UIO`` and ``UIO_PCI_GENERIC`` drivers through the device node (for example, ``/dev/uioX``).
    - Reference: `AppArmor <https://wiki.ubuntuusers.de/AppArmor/>`_, `SELinux <https://selinuxproject.org/page/Main_Page>`_, `UIO driver-API <https://www.kernel.org/doc/html/v4.12/driver-api/uio-howto.html>`_
 
 
 3. **Crypto Support and Secure Applied Crypto**
 
-   - According to the application’s threat model and the defined assets that need to be shared securely, define the requirements for crypto algorithms.Those algorithms should enable operations such as authenticated encryption and decryption, secure key exchange, true random number generation, and seed extraction. In addition, consider the landscape of your attack surface and define the need for security engine (for example CSME services.
+   - According to the application's threat model and the defined assets that need to be shared securely, define the requirements for crypto algorithms.Those algorithms should enable operations such as authenticated encryption and decryption, secure key exchange, true random number generation, and seed extraction. In addition, consider the landscape of your attack surface and define the need for security engine (for example CSME services.
    - Don't implement your own crypto functions. Use available compliant crypto libraries as applicable, such as. (`Intel IPP <https://github.com/intel/ipp-crypto>`_ or `TinyCrypt <https://01.org/tinycrypt>`_)
    - Utilize the platform/kernel infrastructure and services (e.g., :ref:`hld-security` , `Kernel Crypto backend/APIs <https://www.kernel.org/doc/html/v5.4/crypto/index.html>`_ , `keyring subsystem <https://www.man7.org/linux/man-pages/man7/keyrings.7.html>`_, etc..).
    - Implement necessary flows for key lifecycle management including wrapping,revocation and migration, depending on the crypto key type used and if there are requirements for key persistence across system and power management events.

doc/tutorials/pre-launched-rt.rst

@@ -106,8 +106,8 @@ Reboot the system, and it will boot into Pre-Launched RT Mode
    dbbbd4347a574216a12c2201f1ab0240   1   ACRN SOS VM                      Running
    ACRN:\>
 
-Connect console of VM0, via 'vm_console' ACRN shell command (Use 'Ctrl + Space' key to
-escape VM0 console)
+Connect console of VM0, via 'vm_console' ACRN shell command (Press
+:kbd:`Ctrl` + :kbd:`Space` to return to the ACRN shell.)
 
 .. code-block:: none
 

doc/tutorials/using_hybrid_mode_on_nuc.rst

@@ -84,11 +84,11 @@ Hybrid Scenario Startup Checking
 #. Use these steps to verify all VMs are running properly:
 
    a. Use the ``vm_console 0`` to switch to VM0 (Zephyr) console. It will display **Hello world! acrn**.
-   #. Enter :kbd:`Ctrl+Spacebar` to return to the ACRN hypervisor shell.
+   #. Enter :kbd:`Ctrl` + :kbd:`Space` to return to the ACRN hypervisor shell.
    #. Use the ``vm_console 1`` command to switch to the VM1 (Service VM) console.
    #. Verify that the VM1's Service VM can boot up and you can log in.
    #. ssh to VM1 and launch the post-launched VM2 using the ACRN device model launch script.
-   #. Go to the Service VM console, and enter :kbd:`Ctrl+Spacebar` to return to the ACRN hypervisor shell.
+   #. Go to the Service VM console, and enter :kbd:`Ctrl` + :kbd:`Space` to return to the ACRN hypervisor shell.
    #. Use the ``vm_console 2`` command to switch to the VM2 (User VM) console.
    #. Verify that VM2 can boot up and you can log in.
 

doc/tutorials/using_partition_mode_on_nuc.rst

@@ -207,7 +207,7 @@ Update Ubuntu GRUB to boot hypervisor and load kernel image
       The multiboot2 module param ``XXXXXX`` is the bzImage tag and must exactly match the ``kernel_mod_tag``
       configured in the ``misc/vm_configs/scenarios/hybrid/vm_configurations.c`` file.
 
-#. Modify the `/etc/default/grub` file as follows to make the GRUB menu
+#. Modify the ``/etc/default/grub`` file as follows to make the GRUB menu
    visible when booting:
 
    .. code-block:: none
@@ -242,7 +242,7 @@ Logical partition scenario startup checking
 
    #. Use the ``vm_console 0`` to switch to VM0's console.
    #. The VM0's Clear Linux OS should boot up and log in.
-   #. Use a :kbd:`CTRL` + :kbd:`Space` to return to the Acrn hypervisor shell.
+   #. Use a :kbd:`Ctrl` + :kbd:`Space` to return to the ACRN hypervisor shell.
    #. Use the ``vm_console 1`` to switch to VM1's console.
    #. The VM1's Clear Linux OS should boot up and log in.
 

doc/user-guides/acrn-shell.rst

@@ -28,7 +28,7 @@ The ACRN hypervisor shell supports the following commands:
      - Dump a User VM (guest) memory region based on the VM ID (``vm_id``, in decimal),
        the start of the memory region ``gva`` (in hexadecimal) and its length ``length`` (in bytes, decimal number).
    * - vm_console <vm_id>
-     - Switch to the VM's console. Use :kbd:`Ctrl+Spacebar` to return to the ACRN
+     - Switch to the VM's console. Use :kbd:`Ctrl` + :kbd:`Space` to return to the ACRN
        shell console
    * - int
      - List interrupt information per CPU
@@ -156,7 +156,7 @@ vm_console
 ===========
 
 The ``vm_console`` command switches the ACRN's console to become the VM's console.
-Use a :kbd:`Ctrl-Spacebar` to return to the ACRN shell console.
+Press :kbd:`Ctrl` + :kbd:`Space` to return to the ACRN shell console.
 
 vioapic
 =======