diff --git a/doc/developer-guides/hld/hld-security.rst b/doc/developer-guides/hld/hld-security.rst index cefd260b2..ce2f143ce 100644 --- a/doc/developer-guides/hld/hld-security.rst +++ b/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. -#. `.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: diff --git a/doc/developer-guides/hld/hld-trace-log.rst b/doc/developer-guides/hld/hld-trace-log.rst index 123a2cd13..a80b7db91 100644 --- a/doc/developer-guides/hld/hld-trace-log.rst +++ b/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. diff --git a/doc/developer-guides/hld/hv-cpu-virt.rst b/doc/developer-guides/hld/hv-cpu-virt.rst index 49016af5d..eb0111491 100644 --- a/doc/developer-guides/hld/hv-cpu-virt.rst +++ b/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]` - 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 *************** diff --git a/doc/release_notes/release_notes_3.0.rst b/doc/release_notes/release_notes_3.0.rst index 3a1f19a12..60c911bc4 100644 --- a/doc/release_notes/release_notes_3.0.rst +++ b/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 `_. - Extract common ioapic information such as ioapic id, address, gsi base, and gsi num: see PR `#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 `_. - Bring up all cores online so Board Inspector can run cpuid to extract all available cores' information: see PR `#7120 `_. diff --git a/doc/tutorials/docbuild.rst b/doc/tutorials/docbuild.rst index f15583158..d194e40e0 100644 --- a/doc/tutorials/docbuild.rst +++ b/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: