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>
This commit is contained in:
parent
a4f1a2f185
commit
983f4b90c2
|
@ -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.
|
||||
#. `.crt` PEM format certificates for sbsign.
|
||||
#. `.cer` DER format certificates for firmware.
|
||||
#. ``.key`` PEM format private keys for EFI binary and EFI signature list signing.
|
||||
#. ``.crt`` PEM format certificates for sbsign.
|
||||
#. ``.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
|
||||
BIOS. `db.key` and `db.crt` will be used to sign the User VM
|
||||
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
|
||||
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:
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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]`
|
||||
and `CPUID.15H:EAX[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]``.
|
||||
- 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`.
|
||||
- If the guest changes `vK` or `vTSC_Value`, we change the `VMCS.TSC_OFFSET` accordingly.
|
||||
- `K` should never be changed by the hypervisor.
|
||||
where ``vK = K + VMCS.TSC_OFFSET``.
|
||||
- If the guest changes ``vK`` or ``vTSC_Value``, we change the ``VMCS.TSC_OFFSET`` accordingly.
|
||||
- ``K`` should never be changed by the hypervisor.
|
||||
|
||||
XSAVE Emulation
|
||||
***************
|
||||
|
|
|
@ -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>`_.
|
||||
|
|
|
@ -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:
|
||||
|
|
Loading…
Reference in New Issue