mirror of
https://github.com/projectacrn/acrn-hypervisor.git
synced 2025-07-29 22:47:21 +00:00
doc: fix utf-8 punctuation, branding, spelling
Fix some stray UTF-8 punctuation and symbol characters, unnecessary trademark symbols, and some misspellings missed during regular reviews. Tracked-On: #2712 Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
David B. Kinder
David Kinder
parent
9e78ad52d9
commit
e9335fcee6
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -113,7 +113,7 @@ follows::
|
||||
-s <slot>,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::
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -132,9 +132,9 @@ Service OS
|
||||
<https://clearlinux.org/documentation/clear-linux/get-started/bare-metal-install>`_
|
||||
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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
<https://www.automotivelinux.org/>`_.
|
||||
|
||||
Steps for using AGL as the UOS
|
||||
|
||||
@ -15,7 +15,7 @@ please visit `<https://slimbootloader.github.io/how-tos/boot-acrn.html>`_.
|
||||
.. 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
|
||||
`<https://github.com/projectceladon/tools/tree/master/platform_flash_tool_lite/latest/>`_.
|
||||
|
||||
#. 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
|
||||
|
||||
@ -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
|
||||
<http://releases.ubuntu.com/18.04.1/>`_ and select the `ubuntu-18.04.1-desktop-amd64.iso
|
||||
<http://releases.ubuntu.com/18.04.1/>`_ and select the `ubuntu-18.04.1-desktop-amd64.iso
|
||||
<http://releases.ubuntu.com/18.04.1/ubuntu-18.04.1-desktop-amd64.iso>`_ image.
|
||||
|
||||
* Follow Ubuntu's `online instructions <https://tutorials.ubuntu.com/tutorial/tutorial-install-ubuntu-desktop?_ga=2.114179015.1954550575.1530817291-1278304647.1523530035>`_
|
||||
* Follow Ubuntu's `online instructions <https://tutorials.ubuntu.com/tutorial/tutorial-install-ubuntu-desktop>`_
|
||||
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
|
||||
|
||||
@ -159,7 +159,7 @@ Here are descriptions for each of these ``acrn-dm`` command line parameters:
|
||||
|
||||
* - :kbd:`--mac_seed <seed_string>`
|
||||
- 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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user