doc: fix incorrect single back-tick usage

In markdown a single backtick around a term says to format it as
fixed-width text, e.g., `fixed-width text`.  The rst language uses
double back-ticks, e.g., ``fixed-width text``.

Fix misuses of single backtick in our documentation.

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

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

@@ -234,24 +234,24 @@ UEFI Secure Boot implementations use these keys:
 
 And keys and certificates are in multiple formats:
 
-#. `.key`  PEM format private keys for EFI binary and EFI signature list signing.
+#. ``.key``  PEM format private keys for EFI binary and EFI signature list signing.
-#. `.crt`  PEM format certificates for sbsign.
+#. ``.crt``  PEM format certificates for sbsign.
-#. `.cer`  DER format certificates for firmware.
+#. ``.cer``  DER format certificates for firmware.
 
 In ACRN, User VM Secure Boot can be enabled as follows:
 
 #. Generate keys (PK/KEK/DB) with a key generation tool such as Ubuntu
-   KeyGeneration. `PK.der`, `KEK.der`, and `db.der` will be enrolled in UEFI
+   KeyGeneration. ``PK.der``, ``KEK.der``, and ``db.der`` will be enrolled in UEFI
-   BIOS. `db.key` and `db.crt` will be used to sign the User VM
+   BIOS. ``db.key`` and ``db.crt`` will be used to sign the User VM
    bootloader/kernel.
-#. Create a virtual disk to hold `PK.der`, `KEK.der`, and `db.der`, then launch
+#. Create a virtual disk to hold ``PK.der``, ``KEK.der``, and ``db.der``, then launch
    the User VM with this virtual disk.
 #. Start the OVMF in writeback mode to ensure the keys are persistently stored
    in the OVMF image.
 #. Enroll the keys in the OVMF GUI by following the Secure Boot configuration
    flow and enable Secure Boot mode.
 #. Perform writeback via reset in OVMF.
-#. Sign the User VM images with `db.key` and `db.crt`.
+#. Sign the User VM images with ``db.key`` and ``db.crt``.
 #. Boot the User VM with Secure Boot enabled.
 
 .. _service_vm_hardening:

doc/developer-guides/hld/hld-trace-log.rst

@@ -181,7 +181,7 @@ the hypervisor.
 Service VM ACRN Log Module
 ==========================
 
-ACRNLog module provides one kernel option `hvlog=$size@$pbase` to configure
+ACRNLog module provides one kernel option ``hvlog=$size@$pbase`` to configure
 the size and base address of hypervisor log buffer. This space will be further divided
 into two buffers with equal size: last log buffer and current log buffer.
 

doc/developer-guides/hld/hv-cpu-virt.rst

@@ -1205,20 +1205,20 @@ following linearity relationship holds between the TSC and the ART hardware:
 
    ``TSC_Value = (ART_Value * CPUID.15H:EBX[31:0]) / CPUID.15H:EAX[31:0] + K``
 
-Where `K` is an offset that can be adjusted by a privileged agent.
+Where ``K`` is an offset that can be adjusted by a privileged agent.
 When ART hardware is reset, both invariant TSC and K are also reset.
 
 The guideline of ART virtualization (vART) is that software in native can run in
 the VM too. The vART solution is:
 
--  Present the ART capability to the guest through CPUID leaf 15H for `CPUID.15H:EBX[31:0]`
+-  Present the ART capability to the guest through CPUID leaf 15H for ``CPUID.15H:EBX[31:0]``
-   and `CPUID.15H:EAX[31:0]`.
+   and ``CPUID.15H:EAX[31:0]``.
 -  Passthrough devices see the physical ART_Value (vART_Value = pART_Value).
 -  Relationship between the ART and TSC in the guest is:
    ``vTSC_Value = (vART_Value * CPUID.15H:EBX[31:0]) / CPUID.15H:EAX[31:0] + vK``
-   where `vK = K + VMCS.TSC_OFFSET`.
+   where ``vK = K + VMCS.TSC_OFFSET``.
--  If the guest changes `vK` or `vTSC_Value`, we change the `VMCS.TSC_OFFSET` accordingly.
+-  If the guest changes ``vK`` or ``vTSC_Value``, we change the ``VMCS.TSC_OFFSET`` accordingly.
--  `K` should never be changed by the hypervisor.
+-  ``K`` should never be changed by the hypervisor.
 
 XSAVE Emulation
 ***************

doc/release_notes/release_notes_3.0.rst

@@ -145,7 +145,7 @@ XML file for supporting new features and fixes:
   - Extract all serial TTYs and virtio input devices: see PR `#7219 <https://github.com/projectacrn/acrn-hypervisor/pull/7219>`_.
   - Extract common ioapic information such as ioapic id, address, gsi base, and gsi num:
     see PR `#6987 <https://github.com/projectacrn/acrn-hypervisor/pull/6987>`_.
-  - Add another level of `die` node even though the hardware reports die topology in CPUID:
+  - Add another level of ``die`` node even though the hardware reports die topology in CPUID:
     see PR `#7080 <https://github.com/projectacrn/acrn-hypervisor/pull/7080>`_.
   - Bring up all cores online so Board Inspector can run cpuid to extract all available cores'
     information: see PR `#7120 <https://github.com/projectacrn/acrn-hypervisor/pull/7120>`_.

doc/tutorials/docbuild.rst

@@ -125,7 +125,7 @@ later, and these other tools:
 * doxygen                   version: 1.8.17 (Ubuntu 20.04) and 1.9.1 (Ubuntu 22.04)
 
 Depending on your Linux version, install the needed tools. You may get a
-different (newer) version of doxygen (installed using `apt`) than shown here,
+different (newer) version of doxygen (installed using ``apt``) than shown here,
 that may also work.
 
 For Ubuntu use: