[PULL 14/21] docs: Format literals correctly

[Peter Maydell]

In rST markup, single backticks `like this` represent "interpreted
text", which can be handled as a bunch of different things if tagged
with a specific "role":
https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#interpreted-text
(the most common one for us is "reference to a URL, which gets
hyperlinked").

The default "role" if none is specified is "title_reference",
intended for references to book or article titles, and it renders
into the HTML as <cite>...</cite> (usually comes out as italics).

This commit fixes various places in the manual which were
using single backticks when double backticks (for literal text)
were intended, and covers those files where only one or two
instances of these errors were made.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
 docs/about/index.rst                       | 2 +-
 docs/interop/live-block-operations.rst     | 2 +-
 docs/system/arm/nuvoton.rst                | 2 +-
 docs/system/arm/sbsa.rst                   | 4 ++--
 docs/system/arm/virt.rst                   | 2 +-
 docs/system/cpu-hotplug.rst                | 2 +-
 docs/system/guest-loader.rst               | 6 +++---
 docs/system/ppc/powernv.rst                | 8 ++++----
 docs/system/riscv/microchip-icicle-kit.rst | 2 +-
 docs/system/riscv/virt.rst                 | 2 +-
 10 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/docs/about/index.rst b/docs/about/index.rst
index 689a9861dc3..beb762aa0a9 100644
--- a/docs/about/index.rst
+++ b/docs/about/index.rst
@@ -15,7 +15,7 @@ where QEMU can launch processes compiled for one CPU on 
another CPU.
 In this mode the CPU is always emulated.
 
 QEMU also provides a number of standalone commandline utilities,
-such as the `qemu-img` disk image utility that allows you to create,
+such as the ``qemu-img`` disk image utility that allows you to create,
 convert and modify disk images.
 
 .. toctree::
diff --git a/docs/interop/live-block-operations.rst 
b/docs/interop/live-block-operations.rst
index 477d085f54e..9e3635b2338 100644
--- a/docs/interop/live-block-operations.rst
+++ b/docs/interop/live-block-operations.rst
@@ -781,7 +781,7 @@ the content of image [D].
         }
 
 (6) [On *destination* QEMU] Finally, resume the guest vCPUs by issuing the
-    QMP command `cont`::
+    QMP command ``cont``::
 
         (QEMU) cont
         {
diff --git a/docs/system/arm/nuvoton.rst b/docs/system/arm/nuvoton.rst
index 3cd2b2b18d8..69f57c2886f 100644
--- a/docs/system/arm/nuvoton.rst
+++ b/docs/system/arm/nuvoton.rst
@@ -79,7 +79,7 @@ Boot options
 ------------
 
 The Nuvoton machines can boot from an OpenBMC firmware image, or directly into
-a kernel using the ``-kernel`` option. OpenBMC images for `quanta-gsj` and
+a kernel using the ``-kernel`` option. OpenBMC images for ``quanta-gsj`` and
 possibly others can be downloaded from the OpenPOWER jenkins :
 
    https://openpower.xyz/
diff --git a/docs/system/arm/sbsa.rst b/docs/system/arm/sbsa.rst
index 27b0999aaca..b499d7e9272 100644
--- a/docs/system/arm/sbsa.rst
+++ b/docs/system/arm/sbsa.rst
@@ -1,8 +1,8 @@
 Arm Server Base System Architecture Reference board (``sbsa-ref``)
 ==================================================================
 
-While the `virt` board is a generic board platform that doesn't match
-any real hardware the `sbsa-ref` board intends to look like real
+While the ``virt`` board is a generic board platform that doesn't match
+any real hardware the ``sbsa-ref`` board intends to look like real
 hardware. The `Server Base System Architecture
 <https://developer.arm.com/documentation/den0029/latest>`_ defines a
 minimum base line of hardware support and importantly how the firmware
diff --git a/docs/system/arm/virt.rst b/docs/system/arm/virt.rst
index 27652adfae1..59acf0eeafa 100644
--- a/docs/system/arm/virt.rst
+++ b/docs/system/arm/virt.rst
@@ -1,7 +1,7 @@
 'virt' generic virtual platform (``virt``)
 ==========================================
 
-The `virt` board is a platform which does not correspond to any
+The ``virt`` board is a platform which does not correspond to any
 real hardware; it is designed for use in virtual machines.
 It is the recommended board type if you simply want to run
 a guest such as Linux and do not care about reproducing the
diff --git a/docs/system/cpu-hotplug.rst b/docs/system/cpu-hotplug.rst
index bd0663616e8..015ce2b6ec3 100644
--- a/docs/system/cpu-hotplug.rst
+++ b/docs/system/cpu-hotplug.rst
@@ -78,7 +78,7 @@ vCPU hotplug
       }
       (QEMU)
 
-(5) Optionally, run QMP `query-cpus-fast` for some details about the
+(5) Optionally, run QMP ``query-cpus-fast`` for some details about the
     vCPUs::
 
       (QEMU) query-cpus-fast
diff --git a/docs/system/guest-loader.rst b/docs/system/guest-loader.rst
index 37d03cbd892..4320d1183f7 100644
--- a/docs/system/guest-loader.rst
+++ b/docs/system/guest-loader.rst
@@ -4,7 +4,7 @@
 Guest Loader
 ------------
 
-The guest loader is similar to the `generic-loader` although it is
+The guest loader is similar to the ``generic-loader`` although it is
 aimed at a particular use case of loading hypervisor guests. This is
 useful for debugging hypervisors without having to jump through the
 hoops of firmware and boot-loaders.
@@ -27,12 +27,12 @@ multi-boot capability. A typical example would look like:
 In the above example the Xen hypervisor is loaded by the -kernel
 parameter and passed it's boot arguments via -append. The Dom0 guest
 is loaded into the areas of memory. Each blob will get
-`/chosen/module@<addr>` entry in the FDT to indicate it's location and
+``/chosen/module@<addr>`` entry in the FDT to indicate it's location and
 size. Additional information can be passed with by using additional
 arguments.
 
 Currently the only supported machines which use FDT data to boot are
-the ARM and RiscV `virt` machines.
+the ARM and RiscV ``virt`` machines.
 
 Arguments
 ^^^^^^^^^
diff --git a/docs/system/ppc/powernv.rst b/docs/system/ppc/powernv.rst
index 43c58bc32e7..4c4cdea527e 100644
--- a/docs/system/ppc/powernv.rst
+++ b/docs/system/ppc/powernv.rst
@@ -48,15 +48,15 @@ Firmware
 --------
 
 The OPAL firmware (OpenPower Abstraction Layer) for OpenPower systems
-includes the runtime services `skiboot` and the bootloader kernel and
-initramfs `skiroot`. Source code can be found on GitHub:
+includes the runtime services ``skiboot`` and the bootloader kernel and
+initramfs ``skiroot``. Source code can be found on GitHub:
 
   https://github.com/open-power.
 
-Prebuilt images of `skiboot` and `skiboot` are made available on the 
`OpenPOWER <https://openpower.xyz/job/openpower/job/openpower-op-build/>`__ 
site. To boot a POWER9 machine, use the `witherspoon 
<https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/>`__
 images. For POWER8, use
+Prebuilt images of ``skiboot`` and ``skiboot`` are made available on the 
`OpenPOWER <https://openpower.xyz/job/openpower/job/openpower-op-build/>`__ 
site. To boot a POWER9 machine, use the `witherspoon 
<https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/>`__
 images. For POWER8, use
 the `palmetto 
<https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=palmetto/lastSuccessfulBuild/>`__
 images.
 
-QEMU includes a prebuilt image of `skiboot` which is updated when a
+QEMU includes a prebuilt image of ``skiboot`` which is updated when a
 more recent version is required by the models.
 
 Boot options
diff --git a/docs/system/riscv/microchip-icicle-kit.rst 
b/docs/system/riscv/microchip-icicle-kit.rst
index 817d2aec9cd..40798b1aae5 100644
--- a/docs/system/riscv/microchip-icicle-kit.rst
+++ b/docs/system/riscv/microchip-icicle-kit.rst
@@ -95,7 +95,7 @@ Then we can boot the machine by:
       -serial chardev:serial1
 
 With above command line, current terminal session will be used for the first
-serial port. Open another terminal window, and use `minicom` to connect the
+serial port. Open another terminal window, and use ``minicom`` to connect the
 second serial port.
 
 .. code-block:: bash
diff --git a/docs/system/riscv/virt.rst b/docs/system/riscv/virt.rst
index 3709f057972..321d77e07d4 100644
--- a/docs/system/riscv/virt.rst
+++ b/docs/system/riscv/virt.rst
@@ -1,7 +1,7 @@
 'virt' Generic Virtual Platform (``virt``)
 ==========================================
 
-The `virt` board is a platform which does not correspond to any real hardware;
+The ``virt`` board is a platform which does not correspond to any real 
hardware;
 it is designed for use in virtual machines. It is the recommended board type
 if you simply want to run a guest such as Linux and do not care about
 reproducing the idiosyncrasies and limitations of a particular bit of
-- 
2.20.1