github/acrn-hypervisor
1
0
Fork 0
mirror of https://github.com/projectacrn/acrn-hypervisor.git synced 2025-06-21 13:08:42 +00:00
Code Issues Projects Releases Wiki Activity

doc: add more details to the FAQ (for version 0.7)

Browse Source 
Add more details and clarifications to the new FAQ being added for v0.7

Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
This commit is contained in:
Geoffroy Van Cutsem 2019-03-21 10:00:27 +01:00 committed by David Kinder
parent c47efa3f5a
commit 904c9e291e
1 changed files with 43 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
doc/faq.rst
View File

@ -83,67 +83,65 @@ HV_RAM_SIZE is changed to 240M
default 0x0f000000 if PLATFORM_UEFI default 0x0f000000 if PLATFORM_UEFI
How to modify the default display output for a UOS? How to modify the default display output for a UOS?
****************************************************************************** ***************************************************
Apollo Lake HW has three pipes and each pipe can have three or four planes which help to Apollo Lake HW has three pipes and each pipe can have three or four planes which
display the overlay video. The hardware can support up to 3 monitors simultaneously. help to display the overlay video. The hardware can support up to 3 monitors
Some parameters are available to control how display monitors are assigned between the simultaneously. Some parameters are available to control how display monitors
SOS and UOS, simplifying the assignment policy and providing configuration are assigned between the SOS and UOS(s), simplifying the assignment policy and
flexibility for the pipes and planes in various IOT scenarios providing configuration flexibility for the pipes and planes for various IoT
scenarios. This is known as the **plane restriction** feature.
* i915.avail_planes_per_pipe: for controlling the planes * ``i915.avail_planes_per_pipe``: for controlling how planes are assigned to the
* i915.domain_plane_owners: for controlling the domain mapping for each plane pipes
* ``i915.domain_plane_owners``: for controlling which domain (VM) will have
access to which plane
Refer to :ref:`GVT-g-kernel-options` for detailed parameter descriptions. Refer to :ref:`GVT-g-kernel-options` for detailed parameter descriptions.
Currently, pipe A is assigned to SOS and pipes B and C are assigned to UOS, In the default configuration, pipe A is assigned to the SOS and pipes B and C
which uses the below parameter: are assigned to the UOS, as described by these parameters:
* SOS: * SOS::
.. code-block:: bash
i915.avail_planes_per_pipe=0x01010F i915.avail_planes_per_pipe=0x01010F
i915.domain_plane_owners=0x011111110000 i915.domain_plane_owners=0x011111110000
* UOS: * UOS::
.. code-block:: bash
i915.avail_planes_per_pipe=0x0070F00 i915.avail_planes_per_pipe=0x0070F00
If pipes A and B are assigned to UOS, while pipe C is assigned to SOS, To assign pipes A and B to the UOS, while pipe C is assigned to the SOS, use
the below parameters can be used: these parameters:
* SOS::
* SOS:
.. code-block:: bash
i915.avail_planes_per_pipe=0x070101 i915.avail_planes_per_pipe=0x070101
i915.domain_plane_owners=0x000011111111 i915.domain_plane_owners=0x000011111111
* UOS: * UOS::
.. code-block:: bash
i915.avail_planes_per_pipe=0x000F0F i915.avail_planes_per_pipe=0x000F0F
Why does ACRN need to be know how much RAM the system has? .. note::
************************************************************
Configuring ACRN at compile time with the system RAM size is The careful reader may have noticed that in all examples given above, the SOS
a tradeoff between flexibility and functionality certification. always has at least one plane per pipe. This is intentional, and the driver
For server virtualization, one binary is typically used for all platforms will enforce this if the parameters do not do this.
with flexible configuration options given at run time.
But, for IoT applications, the image is typically configured and built
for a particular product platform and optimized product use.
Important features for ACRN include functional safety (FuSa) and Why does ACRN need to know how much RAM the system has?
real-time behavior. FuSa requires a static allocation policy to avoid *******************************************************
the potential of dynamic allocation failures. Real-time applications
similarly benefit from static memory allocation. This is why ACRN Configuring ACRN at compile time with the system RAM size is a tradeoff between
removed all "malloc" like code, and why it needs to pre-identify flexibility and functional safety certification. For server virtualization, one
the size of all buffers and structures used in the Virtual Memory binary is typically used for all platforms with flexible configuration options
Manager. For this reason, knowing the available RAM size at compile given at run time. But, for IoT applications, the image is typically configured
time is necessary to statically allocate memory usage. and built for a particular product platform and optimized for that product.
Important features for ACRN include Functional Safety (FuSa) and real-time
behavior. FuSa requires a static allocation policy to avoid the potential of
dynamic allocation failures. Real-time applications similarly benefit from
static memory allocation. This is why ACRN removed all ``malloc()``-type code,
and why it needs to pre-identify the size of all buffers and structures used in
the Virtual Memory Manager. For this reason, knowing the available RAM size at
compile time is necessary to statically allocate memory usage.