diff --git a/doc/api/GVT-g_api.rst b/doc/api/GVT-g_api.rst index e1630de16..76989e807 100644 --- a/doc/api/GVT-g_api.rst +++ b/doc/api/GVT-g_api.rst @@ -9,7 +9,7 @@ named XenGT, and over ACRN it is named AcrnGT. GVT-g can exports multiple virtual GPU (vGPU) instances for virtual machine system (VM). A VM could be assigned one vGPU instance. The guest OS graphic driver needs minor modification to drive the vGPU adapter in a VM. Every vGPU instance will adopt -the full HW GPU’s accelerate capability for 3D render and display. +the full HW GPU's accelerate capability for 3D render and display. In the following document, AcrnGT refers to the glue layer between ACRN hypervisor and GVT-g core device model. It works as the agent of diff --git a/doc/developer-guides/hld/hld-APL_GVT-g.rst b/doc/developer-guides/hld/hld-APL_GVT-g.rst index 8541d53cd..6579b7d24 100644 --- a/doc/developer-guides/hld/hld-APL_GVT-g.rst +++ b/doc/developer-guides/hld/hld-APL_GVT-g.rst @@ -10,7 +10,7 @@ Purpose of this Document ======================== This high-level design (HLD) document describes the usage requirements -and high level design for Intel® Graphics Virtualization Technology for +and high level design for Intel |reg| Graphics Virtualization Technology for shared virtual :term:`GPU` technology (:term:`GVT-g`) on Apollo Lake-I SoCs. @@ -26,10 +26,10 @@ Audience ======== This document is for developers, validation teams, architects and -maintainers of Intel® GVT-g for the Apollo Lake SoCs. +maintainers of Intel |reg| GVT-g for the Apollo Lake SoCs. The reader should have some familiarity with the basic concepts of -system virtualization and Intel® processor graphics. +system virtualization and Intel processor graphics. Reference Documents =================== @@ -45,19 +45,19 @@ The following documents were used as references for this specification: Background ********** -Intel® GVT-g is an enabling technology in emerging graphics +Intel GVT-g is an enabling technology in emerging graphics virtualization scenarios. It adopts a full GPU virtualization approach based on mediated pass-through technology, to achieve good performance, scalability and secure isolation among Virtual Machines (VMs). A virtual GPU (vGPU), with full GPU features, is presented to each VM so that a native graphics driver can run directly inside a VM. -Intel® GVT-g technology for Apollo Lake (APL) has been implemented in +Intel GVT-g technology for Apollo Lake (APL) has been implemented in open source hypervisors or Virtual Machine Monitors (VMMs): -- Intel® GVT-g for ACRN, also known as, "AcrnGT" -- Intel® GVT-g for KVM, also known as, "KVMGT" -- Intel® GVT-g for Xen, also known as, "XenGT" +- Intel GVT-g for ACRN, also known as, "AcrnGT" +- Intel GVT-g for KVM, also known as, "KVMGT" +- Intel GVT-g for Xen, also known as, "XenGT" The core vGPU device model is released under BSD/MIT dual license, so it can be reused in other proprietary hypervisors. @@ -119,7 +119,7 @@ virtualization technology. It has been used in commercial virtualization productions, for example, VMware*, PCoIP*, and Microsoft* RemoteFx*. It is a natural path when researchers study a new type of I/O virtualization usage, for example, when GPGPU computing in VM was -initially proposed. Intel® GVT-s is based on this approach. +initially proposed. Intel GVT-s is based on this approach. The architecture of API forwarding is shown in :numref:`api-forwarding`: @@ -170,7 +170,7 @@ capability among VMs. Only one VM at a time can use the hardware acceleration capability of the GPU, which is a major limitation of this technique. However, it is still a good approach to enable graphics virtualization usages on Intel server platforms, as an intermediate -solution. Intel® GVT-d uses this mechanism. +solution. Intel GVT-d uses this mechanism. .. figure:: images/APL_GVT-g-pass-through.png :width: 400px @@ -189,7 +189,7 @@ with each VF directly assignable to a VM. Mediated Pass-Through ********************* -Intel® GVT-g achieves full GPU virtualization using a "mediated +Intel GVT-g achieves full GPU virtualization using a "mediated pass-through" technique. Concept diff --git a/doc/developer-guides/hld/hld-virtio-devices.rst b/doc/developer-guides/hld/hld-virtio-devices.rst index 3bfdf1854..4c9391dab 100644 --- a/doc/developer-guides/hld/hld-virtio-devices.rst +++ b/doc/developer-guides/hld/hld-virtio-devices.rst @@ -275,7 +275,7 @@ The architecture of ACRN VBS-K is shown in :numref:`kernel-virtio-framework` below. Generally VBS-K provides acceleration towards performance critical -devices emulated by VBS-U modules by handling the “data plane” of the +devices emulated by VBS-U modules by handling the "data plane" of the devices directly in the kernel. When VBS-K is enabled for certain devices, the kernel-land vring service API helpers, instead of the user-land helpers, are used to access the virtqueues shared by the FE diff --git a/doc/developer-guides/hld/hv-ioc-virt.rst b/doc/developer-guides/hld/hv-ioc-virt.rst index c17a2e42b..0984ef096 100644 --- a/doc/developer-guides/hld/hv-ioc-virt.rst +++ b/doc/developer-guides/hld/hv-ioc-virt.rst @@ -154,7 +154,7 @@ char devices and UART DM immediately. data comes from a raw channel, the data will be passed forward. Before transmitting to the virtual UART interface, all data needs to be packed with an address header and link header. -- For Rx direction, the data comeis from the UOS. The IOC mediator receives link +- For Rx direction, the data comes from the UOS. The IOC mediator receives link data from the virtual UART interface. The data will be unpacked by Core thread, and then forwarded to Rx queue, similar to how the Tx direction flow is done except that the heartbeat and RTC are only used by the IOC @@ -456,7 +456,7 @@ the SoC. System control - Heartbeat -Heartbeate frame definiton is shown here: +Heartbeat frame definition is shown here: .. figure:: images/ioc-image6.png :width: 900px diff --git a/doc/developer-guides/hld/usb-virt-hld.rst b/doc/developer-guides/hld/usb-virt-hld.rst index ed998dcd1..8890a64d7 100644 --- a/doc/developer-guides/hld/usb-virt-hld.rst +++ b/doc/developer-guides/hld/usb-virt-hld.rst @@ -113,7 +113,7 @@ follows:: -s ,xhci,[bus1-port1,bus2-port2],cap=platform - *cap*: cap means virtual xHCI capability. This parameter - indicates virtual xHCI should emulate the named platform’s xHCI + indicates virtual xHCI should emulate the named platform's xHCI capabilities. A simple example:: diff --git a/doc/developer-guides/l1tf.rst b/doc/developer-guides/l1tf.rst index da6136ea0..786f85fd7 100644 --- a/doc/developer-guides/l1tf.rst +++ b/doc/developer-guides/l1tf.rst @@ -38,7 +38,7 @@ Because the resulting probed physical address is not a true translation of the virtual address, the resulting address is not constrained by various memory range checks or nested translations. Specifically: -* Intel® SGX protected memory checks are not applied. +* Intel |reg| SGX protected memory checks are not applied. * Extended Page Table (EPT) guest physical to host physical address translation is not applied. * SMM protected memory checks are not applied. @@ -46,7 +46,7 @@ memory range checks or nested translations. Specifically: The following CVE entries are related to the L1TF: ============= ================= ============================== -CVE-2018-3615 L1 Terminal Fault Intel® SGX related aspects +CVE-2018-3615 L1 Terminal Fault Intel SGX related aspects CVE-2018-3620 L1 Terminal Fault OS, SMM related aspects CVE-2018-3646 L1 Terminal Fault Virtualization related aspects ============= ================= ============================== @@ -64,7 +64,7 @@ Malicious user space is not a concern to ACRN hypervisor, because every guest runs in VMX non-root. It is responsibility of guest kernel to protect itself from malicious user space attack. -Intel® SGX/SMM related attacks are mitigated by using latest microcode. +Intel SGX/SMM related attacks are mitigated by using latest microcode. There is no additional action in ACRN hypervisor. Guest -> hypervisor Attack @@ -77,7 +77,7 @@ PTEs (with present bit cleared, or reserved bit set) pointing to valid host PFNs, a malicious guest may use those EPT PTEs to construct an attack. A special aspect of L1TF in the context of virtualization is symmetric -multi threading (SMT), e.g. Intel® Hyper-Threading Technology. +multi threading (SMT), e.g. Intel |reg| Hyper-Threading Technology. Logical processors on the affected physical cores share the L1 Data Cache (L1D). This fact could make more variants of L1TF-based attack, e.g. a malicious guest running on one logical processor can attack the data which @@ -113,7 +113,7 @@ breaking the security model as expected by Android guest. Affected Processors =================== -L1TF affects a range of Intel processors, but Intel ATOM® processors +L1TF affects a range of Intel processors, but Intel Atom |reg| processors (including Apollo Lake) are immune to it. Currently ACRN hypervisor supports only Apollo Lake. Support for other core-based platforms is planned, so we still need a mitigation plan in ACRN. @@ -127,7 +127,7 @@ Please refer to `Intel Analysis of L1TF`_ for more details. L1TF Mitigation in ACRN *********************** -Use the latest microcode, which mitigates SMM and Intel® SGX cases +Use the latest microcode, which mitigates SMM and Intel SGX cases while also providing necessary capability for VMM to use for further mitigation. diff --git a/doc/developer-guides/modularity.rst b/doc/developer-guides/modularity.rst index 94e25a659..7ca80aa3b 100644 --- a/doc/developer-guides/modularity.rst +++ b/doc/developer-guides/modularity.rst @@ -126,7 +126,7 @@ functions of that layer as well as the layers below. References ********** -.. [IEC_61508-3] IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 3: Software requirements +.. [IEC_61508-3] IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements .. [ISO_26262-6] ISO 26262-6:2011, Road vehicles - Functional safety - Part 6: Product development at the software level diff --git a/doc/developer-guides/primer.rst b/doc/developer-guides/primer.rst index d9eaa2e46..a0d390c85 100644 --- a/doc/developer-guides/primer.rst +++ b/doc/developer-guides/primer.rst @@ -448,7 +448,7 @@ MMIO range mapping may be added. Graphic mediation ***************** -Intel |reg| Graphics Virtualization Technology –g (Intel |reg| GVT-g) +Intel |reg| Graphics Virtualization Technology -g (Intel |reg| GVT-g) provides GPU sharing capability to multiple VMs by using a mediated pass-through technique. This allows a VM to access performance critical I/O resources (usually partitioned) directly, without intervention from diff --git a/doc/getting-started/apl-nuc.rst b/doc/getting-started/apl-nuc.rst index 9f1727b39..665ec233d 100644 --- a/doc/getting-started/apl-nuc.rst +++ b/doc/getting-started/apl-nuc.rst @@ -61,7 +61,7 @@ complete this setup. #. Name the host "clr-sos-guest" #. Add an administrative user "clear" with "sudoers" privilege #. Add these additional bundles "editors", "user-basic", "desktop-autostart", "network-basic" - #. For network, choose “DHCP” + #. For network, choose "DHCP" #. After installation is complete, boot into Clear Linux OS, login as **clear**, and set a password. diff --git a/doc/introduction/index.rst b/doc/introduction/index.rst index 7755a289f..3ab2d2b2b 100644 --- a/doc/introduction/index.rst +++ b/doc/introduction/index.rst @@ -138,7 +138,7 @@ Boot Sequence ************* In :numref:`boot-flow` we show a verified Boot Sequence with UEFI -on an Intel |reg| Architecture platform NUC (see :ref:`hardware`). +on an Intel Architecture platform NUC (see :ref:`hardware`). .. graphviz:: images/boot-flow.dot :name: boot-flow diff --git a/doc/release_notes_0.2.rst b/doc/release_notes_0.2.rst index 21ad59a35..281db6e2f 100644 --- a/doc/release_notes_0.2.rst +++ b/doc/release_notes_0.2.rst @@ -96,7 +96,7 @@ Bluetooth ACRN hypervisor supports bluetooth controller passthrough to a single Guest OS (IVI). -GPU – Preemption +GPU - Preemption ================== GPU Preemption is one typical automotive use case which requires the system to preempt GPU resources occupied by lower priority workloads. @@ -104,7 +104,7 @@ This is done to ensure performance of the most critical workload can be achieved. Three different schedulers for the GPU are involved: i915 UOS scheduler, Mediator GVT scheduler, and i915 SOS scheduler. -GPU – display surface sharing via Hyper DMA +GPU - display surface sharing via Hyper DMA ============================================ Surface sharing is one typical automotive use case which requires that the SOS accesses an individual surface or a set of surfaces @@ -161,7 +161,7 @@ Known Issues issue will be fixed in the next release. -:acrn-issue:`1319` - SD card pass-through: UOS can’t see SD card after UOS reboot. +:acrn-issue:`1319` - SD card pass-through: UOS can't see SD card after UOS reboot. SD card could not be found after UOS reboot in pass-through mode. **Impact:** There is no SD card after UOS reboot. **Workaround:** None. The issue will be fixed in the next release. diff --git a/doc/release_notes_0.4.rst b/doc/release_notes_0.4.rst index 8208e9153..465bec245 100644 --- a/doc/release_notes_0.4.rst +++ b/doc/release_notes_0.4.rst @@ -117,7 +117,7 @@ Known Issues **Workaround:** Power off and boot again. The issues will be fixed in the next release. :acrn-issue:`1986` - UOS will hang once watchdog reset triggered - If Launching UOS with “-s 8,wdt-i6300esb”, UOS will hang if the watchdog reset is triggered. + If Launching UOS with "-s 8,wdt-i6300esb", UOS will hang if the watchdog reset is triggered. **Impact:** UOS cannot self-recover after a watchdog reset is triggered. @@ -151,7 +151,7 @@ Known Issues :acrn-issue:`1996` - There is an error log when using "acrnd&" to boot UOS An error log is printed when starting acrnd as a background job (``acrnd&``) to boot UOS. The UOS still boots up - normally, but prints: “Failed to open the socket(sos-lcs) to query the reason for the wake-up. + normally, but prints: "Failed to open the socket(sos-lcs) to query the reason for the wake-up. Activating all vms when acrnd & to boot uos." **Impact:** UOS boots normally, but prints an error log message. @@ -273,7 +273,7 @@ release in Nov 2018 (click on the CommitID link to see details): - :acrn-commit:`06b2ab55` Update using_ubuntu_as_sos.rst - :acrn-commit:`e4941b22` Update using_ubuntu_as_sos.rst - :acrn-commit:`65f21a77` Update the version of Ubuntu to 18.04 -- :acrn-commit:`abfa1c16` update the length of ＊ +- :acrn-commit:`abfa1c16` update the length of * - :acrn-commit:`1664ba5f` Update using_ubuntu_as_sos.rst - :acrn-commit:`f3527c63` Update using_ubuntu_as_sos.rst - :acrn-commit:`e4b616d5` Update using_ubuntu_as_sos.rst diff --git a/doc/release_notes_0.5.rst b/doc/release_notes_0.5.rst index 529a7e49a..68969cb9f 100644 --- a/doc/release_notes_0.5.rst +++ b/doc/release_notes_0.5.rst @@ -191,7 +191,7 @@ Known Issues :acrn-issue:`1996` - There is an error log when using "acrnd&" to boot UOS An error log is printed when starting acrnd as a background job (``acrnd&``) to boot UOS. The UOS still boots up - normally, but prints: “Failed to open the socket(sos-lcs) to query the reason for the wake-up. + normally, but prints: "Failed to open the socket(sos-lcs) to query the reason for the wake-up. Activating all vms when acrnd & to boot uos." **Impact:** UOS boots normally, but prints an error log message. @@ -231,7 +231,7 @@ Known Issues After exiting UOS with mediator Usb_KeyBoard and Mouse, SOS cannot use the Usb_KeyBoard and Mouse. Reproduce Steps as below: - 1) Insert USB keyboard and mouse in standard A port（USB3.0 port） + 1) Insert USB keyboard and mouse in standard A port (USB3.0 port) 2) Boot UOS by sharing the USB keyboard and mouse in cmd line: -s n,xhci,1-1:1-2:1-3:1-4:2-1:2-2:2-3:2-4 \ @@ -407,7 +407,7 @@ release in Dec 2018 (click on the CommitID link to see details): - :acrn-commit:`2c6c383e` hv: string: fix MISRA-C violations related to break - :acrn-commit:`b319e654` HV: fix bug adapt uart mmio to bdf for HV cmdline - :acrn-commit:`23c2166a` HV: change serial PCI cfg to bus:dev.func format -- :acrn-commit:`1caf58f2` hv:clean io_request.c misra violations +- :acrn-commit:`1caf58f2` hv:clean io_request.c MISRA violations - :acrn-commit:`530388db` hv: irq: fix MISRA-C violations in irq.c and idt.h - :acrn-commit:`08cf8f64` hv: lapic: fix MISRA-C violation of potential numeric overflow - :acrn-commit:`83ebd432` hv: ptdev: fix MISRA-C violations @@ -542,7 +542,7 @@ release in Dec 2018 (click on the CommitID link to see details): - :acrn-commit:`6bfbf166` Doc: Update some statements - :acrn-commit:`85b30685` Doc: define swap partition with 1G - :acrn-commit:`fae136c2` doc: remove "software-defined-cockpit" -- :acrn-commit:`33b87064` Doc: Update the doc of "Build UOS from ClearLinux" +- :acrn-commit:`33b87064` Doc: Update the doc of "Build UOS from Clear Linux" - :acrn-commit:`8b83cadd` doc: update the layout of the doc - :acrn-commit:`71bf586e` doc: upload tutorial of 'Build UOS from Clear Linux' - :acrn-commit:`bc5b27a7` tools: acrnctl: increase STOP_TIMEOUT to 30s when reset VM diff --git a/doc/release_notes_0.6.rst b/doc/release_notes_0.6.rst index 2c632b12b..dd1f1feb8 100644 --- a/doc/release_notes_0.6.rst +++ b/doc/release_notes_0.6.rst @@ -147,7 +147,7 @@ Known Issues :acrn-issue:`1996` - There is an error log when using "acrnd&" to boot UOS An error log is printed when starting acrnd as a background job (``acrnd&``) to boot UOS. The UOS still boots up - normally, but prints: “Failed to open the socket(sos-lcs) to query the reason for the wake-up. + normally, but prints: "Failed to open the socket(sos-lcs) to query the reason for the wake-up. Activating all vms when acrnd & to boot uos." **Impact:** UOS boots normally, but prints an error log message. diff --git a/doc/tutorials/agl-vms.rst b/doc/tutorials/agl-vms.rst index 7c520a093..928f334f8 100644 --- a/doc/tutorials/agl-vms.rst +++ b/doc/tutorials/agl-vms.rst @@ -132,9 +132,9 @@ Service OS `_ as a starting point for installing Clear Linux OS onto your platform. Follow the recommended options for choosing an Automatic installation - type, and using the platform’s storage as the target device for + type, and using the platform's storage as the target device for installation (overwriting the existing data and creating three - partitions on the platform’s storage drive). + partitions on the platform's storage drive). #. After installation is complete, boot into Clear Linux OS, login as root, and set a password. diff --git a/doc/tutorials/skl-nuc.rst b/doc/tutorials/skl-nuc.rst index 0da80c030..8ce3c63b8 100644 --- a/doc/tutorials/skl-nuc.rst +++ b/doc/tutorials/skl-nuc.rst @@ -42,10 +42,10 @@ Please follow the :ref:`getting-started-apl-nuc`, with the following changes: Clear Linux OS will update to the latest version during installation. Run this command (as root) to roll back to version 25130, using the - ``–x`` switch to ignore version mismatch:: + ``-x`` switch to ignore version mismatch:: # swupd verify -x --fix --picky -m 25130 - # swupd autoupdate -–disable + # swupd autoupdate --disable # reboot #. Add the ACRN hypervisor to the EFI Partition diff --git a/doc/tutorials/using_agl_as_uos.rst b/doc/tutorials/using_agl_as_uos.rst index 9356af415..b7989b51d 100644 --- a/doc/tutorials/using_agl_as_uos.rst +++ b/doc/tutorials/using_agl_as_uos.rst @@ -23,7 +23,7 @@ accelerate the development and adoption of a fully open software stack for the connected car. With Linux at its core, AGL is developing an open platform from the ground up that can serve as the de facto industry standard to enable rapid development of new features and technologies. -For more information about AGL, please visit `AGL’s official website +For more information about AGL, please visit `AGL's official website `_. Steps for using AGL as the UOS diff --git a/doc/tutorials/using_sbl_on_up2.rst b/doc/tutorials/using_sbl_on_up2.rst index c4fe0c9f5..e8dc220b2 100644 --- a/doc/tutorials/using_sbl_on_up2.rst +++ b/doc/tutorials/using_sbl_on_up2.rst @@ -15,7 +15,7 @@ please visit ``_. .. image:: images/sbl_boot_flow_UP2.png :align: center -We show a verified Boot Sequence with SBL on an Intel® Architecture platform UP2, +We show a verified Boot Sequence with SBL on an Intel Architecture platform UP2, and the boot process proceeds as follows: #. SBL verifies and boots the ACRN hypervisor and Service OS kernel @@ -162,7 +162,7 @@ which is also in the directory ``~/acrn-hypervisor/doc/tutorials/``. | up2_laag.img | This is the root filesystem image for the SOS. | | | It has an integrated kernel and userspace. | +------------------------------+---------------------------------------------------+ - | flash_LaaG.json | Configuration file for Intel® Platform Flash Tool | + | flash_LaaG.json | Configuration file for Intel Platform Flash Tool | | | to flash SOS image + hypervisor/SOS boot image + | | | SOS userland | +------------------------------+---------------------------------------------------+ @@ -173,7 +173,7 @@ which is also in the directory ``~/acrn-hypervisor/doc/tutorials/``. Download and install flash tool ******************************* -#. Download Intel® Platform Flash Tool Lite from +#. Download Intel Platform Flash Tool Lite from ``_. #. For Ubuntu host, install `platformflashtoollite_5.8.9.0_linux_x86_64.deb @@ -203,7 +203,7 @@ SOS and LaaG Installation both HW and SW flow control are turned off. #. When you see following console log, please press any key to enter - shell command： + shell command: .. code-block:: none @@ -245,7 +245,7 @@ SOS and LaaG Installation Shell> exit - … + ... 40E0 | 175118 ms | 158 ms | Kernel setup 40F0 | 175144 ms | 26 ms | FSP ReadyToBoot/EndOfFirmware notify diff --git a/doc/tutorials/using_ubuntu_as_sos.rst b/doc/tutorials/using_ubuntu_as_sos.rst index 1c15534d9..a8b35289f 100644 --- a/doc/tutorials/using_ubuntu_as_sos.rst +++ b/doc/tutorials/using_ubuntu_as_sos.rst @@ -16,10 +16,10 @@ Ubuntu 18.04.1 LTS was used throughout this document, other older versions such 16.04 works too. * Download Ubuntu 18.04 from the `Ubuntu 18.04.1 LTS (Bionic Beaver) page - `_ and select the `ubuntu-18.04.1-desktop-amd64.iso + `_ and select the `ubuntu-18.04.1-desktop-amd64.iso `_ image. -* Follow Ubuntu's `online instructions `_ +* Follow Ubuntu's `online instructions `_ to install it on your device. .. note:: @@ -83,7 +83,7 @@ the source code, build it, and install it on your device. #. Add the ACRN hypervisor and Service OS kernel to it (as ``root``) .. code-block:: none - + ls /boot/efi/EFI/ubuntu/ You should see the following output: @@ -102,28 +102,28 @@ the source code, build it, and install it on your device. #. Configure the EFI firmware to boot the ACRN hypervisor by default .. code-block:: none - + # For SATA sudo efibootmgr -c -l "\EFI\acrn\acrn.efi" -d /dev/sda -p 1 \ -L "ACRN Hypervisor" -u "bootloader=\EFI\ubuntu\grubx64.efi" # For NVMe sudo efibootmgr -c -l "\EFI\acrn\acrn.efi" -d /dev/nvme0n1 -p 1 \ - -L "ACRN Hypervisor" -u "bootloader=\EFI\ubuntu\grubx64.efi" - + -L "ACRN Hypervisor" -u "bootloader=\EFI\ubuntu\grubx64.efi" + #. Verify that the "ACRN Hypervisor" is added and make sure it will be booted first - - .. code-block:: none - + + .. code-block:: none + sudo efibootmgr -v #. You can change the boot order at any time using ``efibootmgr -o XXX,XXX,XXX`` - - .. code-block:: none - - sudo efibootmgr -o xxx,xxx,xxx + + .. code-block:: none + + sudo efibootmgr -o xxx,xxx,xxx .. note:: - By default, the “ACRN Hypervisor” you have just added should be + By default, the "ACRN Hypervisor" you have just added should be the first one to boot. Verify this by using ``efibootmgr -v`` or by entering the EFI firmware at boot (using :kbd:`F10`) @@ -183,7 +183,7 @@ You can download latest Service OS kernel from .. note:: You will also need to adjust the kernel name if you used a different RPM file as the source of your Service OS kernel. - + .. note:: The command line for the kernel in /etc/grub.d/40_custom should be all as a single line, not as multiple lines. Otherwise the kernel will fail to boot @@ -192,7 +192,7 @@ You can download latest Service OS kernel from There are a couple of lines to be modified, as shown below. .. code-block:: none - + #GRUB_TIMEOUT_STYLE=hidden #GRUB_HIDDEN_TIMEOUT=0 GRUB_HIDDEN_TIMEOUT_QUIET=false @@ -204,20 +204,20 @@ You can download latest Service OS kernel from sudo update-grub #. Reboot the system - - Reboot system. You should see the Grub menu with the new “ACRN ubuntu SOS” + + Reboot system. You should see the Grub menu with the new "ACRN ubuntu SOS" entry. Select it and proceed to booting the platform. The system will start the Ubuntu Desktop and you can now log in (as before). .. note:: If you don't see the Grub menu after rebooting the system (and you're not booting into the ACRN hypervisor), you'll need to enter the - EFI firmware at boot (using :kbd:`F10`) and manually select ``ACRN Hypervisor``. - + EFI firmware at boot (using :kbd:`F10`) and manually select ``ACRN Hypervisor``. + .. note:: - If you see a black screen on the first-time reboot after installing the ACRN Hypervisor, + If you see a black screen on the first-time reboot after installing the ACRN Hypervisor, wait a few moments and the Ubuntu desktop will be displayed. - + To check if the hypervisor is effectively running, check ``dmesg``. The typical output of a successful installation will look like this: @@ -243,7 +243,7 @@ For the User OS, we are using the same `Clear Linux OS`_ release version as the * Download the "kernel-iot-lts2018" kernel .. code-block:: none - + sudo mkdir ~/uos-kernel-build cd ~/uos-kernel-build wget https://download.clearlinux.org/releases/26440/clear/x86_64/os/Packages/linux-iot-lts2018-4.19.0-22.x86_64.rpm @@ -274,7 +274,7 @@ For the User OS, we are using the same `Clear Linux OS`_ release version as the sudo cp /usr/bin/iasl /usr/sbin/iasl * Adjust ``launch_uos.sh`` - + You need to adjust the ``/usr/share/acrn/samples/nuc/launch_uos.sh`` script to match your installation. These are the couple of lines you need to modify: @@ -282,9 +282,9 @@ For the User OS, we are using the same `Clear Linux OS`_ release version as the -s 3,virtio-blk,~/clear-26440-kvm.img -k /lib/modules/kernel/default-iot-lts2018 - + .. note:: - The image of UOS can be stored in other directories instead of ``~/``, + The image of UOS can be stored in other directories instead of ``~/``, and please remember to modify the directory of image in ``launch_uos.sh`` too. Start the User OS (UOS) @@ -299,7 +299,7 @@ You are now all set to start the User OS (UOS) **Congratulations**, you are now watching the User OS booting up! -Enabling network sharing +Enabling network sharing ************************ After booting up the SOS and UOS, network sharing must be enabled to give network @@ -308,15 +308,15 @@ script example shows how to set this up (verified in Ubuntu 16.04 and 18.04 as t .. code-block:: none - + #!/bin/bash #setup bridge for uos network br=$(brctl show | grep acrn-br0) br=${br-:0:6} ip tuntap add dev acrn_tap0 mode tap - + taps=$(ifconfig | grep acrn_ | awk '{print $1}') - + # if bridge not existed if [ "$br"x != "acrn-br0"x ]; then #setup bridge for uos network @@ -332,7 +332,7 @@ script example shows how to set this up (verified in Ubuntu 16.04 and 18.04 as t ip link set dev $tap up done fi - + brctl addif acrn-br0 acrn_tap0 ip link set dev acrn_tap0 up @@ -346,5 +346,5 @@ Enabling USB keyboard and mouse Please refer to :ref:`getting-started-apl-nuc` for enabling the USB keyboard and mouse for the UOS. - + .. _Clear Linux OS: https://clearlinux.org diff --git a/doc/user-guides/acrn-dm-parameters.rst b/doc/user-guides/acrn-dm-parameters.rst index aaa06c063..8b0e66122 100644 --- a/doc/user-guides/acrn-dm-parameters.rst +++ b/doc/user-guides/acrn-dm-parameters.rst @@ -159,7 +159,7 @@ Here are descriptions for each of these ``acrn-dm`` command line parameters: * - :kbd:`--mac_seed ` - Set a platform unique string as a seed to generate the mac address. - Each VM should have a different “seed_string”. The “seed_string” can + Each VM should have a different "seed_string". The "seed_string" can be generated by the following method where $(vm_name) contains the name of the VM you are going to launch. diff --git a/hypervisor/README.rst b/hypervisor/README.rst index 515d3badf..c445c41e8 100644 --- a/hypervisor/README.rst +++ b/hypervisor/README.rst @@ -5,7 +5,7 @@ The open source `Project ACRN`_ defines a device hypervisor reference stack and an architecture for running multiple software subsystems, managed securely, on a consolidated system by means of a virtual machine manager. It also defines a reference framework implementation for virtual device emulation, called the -“ACRN Device Model”. +"ACRN Device Model". The ACRN Hypervisor is a Type 1 reference hypervisor stack, running directly on the bare-metal hardware, and is suitable for a variety of IoT and embedded diff --git a/tools/README.rst b/tools/README.rst index f7597502a..fec19ddc6 100644 --- a/tools/README.rst +++ b/tools/README.rst @@ -5,7 +5,7 @@ The open source `Project ACRN`_ defines a device hypervisor reference stack and an architecture for running multiple software subsystems, managed securely, on a consolidated system by means of a virtual machine manager. It also defines a reference framework implementation for virtual device emulation, called the -“ACRN Device Model”. +"ACRN Device Model". This folder holds the source to a number of tools that facilitate the management, debugging, profiling, and logging of multi-OS systems based on diff --git a/tools/acrn-crashlog/README.rst b/tools/acrn-crashlog/README.rst index 5d56a7f93..e06a55cb0 100644 --- a/tools/acrn-crashlog/README.rst +++ b/tools/acrn-crashlog/README.rst @@ -83,19 +83,16 @@ Then it will show: '/etc/systemd/system.conf.d/40-watchdog.conf' '/usr/share/acrn/crashlog/80-coredump.conf' -> '/etc/sysctl.d/80-coredump.conf' - Created symlink /etc/systemd/system/hprobe.timer → /dev/null. - Created symlink /etc/systemd/system/telemd-update-trigger.service → - /dev/null. - Created symlink /etc/systemd/system/pstore-clean.service → /dev/null. - Created symlink /etc/systemd/system/pstore-probe.service → /dev/null. - Created symlink /etc/systemd/system/oops-probe.service → /dev/null. - Created symlink /etc/systemd/system/klogscanner.service → /dev/null. - Created symlink /etc/systemd/system/journal-probe.service → /dev/null. - Created symlink /etc/systemd/system/bert-probe.service → /dev/null. - Created symlink /etc/systemd/system/multi-user.target.wants/acrnprobe.service - → /usr/lib/systemd/system/acrnprobe.service. - Created symlink /etc/systemd/system/multi-user.target.wants/usercrash.service - → /usr/lib/systemd/system/usercrash.service. + Created symlink /etc/systemd/system/hprobe.timer -> /dev/null. + Created symlink /etc/systemd/system/telemd-update-trigger.service -> /dev/null. + Created symlink /etc/systemd/system/pstore-clean.service -> /dev/null. + Created symlink /etc/systemd/system/pstore-probe.service -> /dev/null. + Created symlink /etc/systemd/system/oops-probe.service -> /dev/null. + Created symlink /etc/systemd/system/klogscanner.service -> /dev/null. + Created symlink /etc/systemd/system/journal-probe.service -> /dev/null. + Created symlink /etc/systemd/system/bert-probe.service -> /dev/null. + Created symlink /etc/systemd/system/multi-user.target.wants/acrnprobe.service -> /usr/lib/systemd/system/acrnprobe.service. + Created symlink /etc/systemd/system/multi-user.target.wants/usercrash.service -> /usr/lib/systemd/system/usercrash.service. *** Please reboot your system. *** Follow the hints to reboot the system: diff --git a/tools/acrn-crashlog/usercrash/README.rst b/tools/acrn-crashlog/usercrash/README.rst index 75ff1ee7f..934df80bc 100644 --- a/tools/acrn-crashlog/usercrash/README.rst +++ b/tools/acrn-crashlog/usercrash/README.rst @@ -72,8 +72,8 @@ Usage You need to be ``root`` to use the ``debugger``. -Souce Code -********** +Source Code +*********** - client.c : This file is the implementation for client of ``usercrash``, which is responsible for delivering the ``usercrash`` event to the server, and