github/acrn-hypervisor
1
0
Fork 0
mirror of https://github.com/projectacrn/acrn-hypervisor.git synced 2025-06-20 12:42:54 +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

88
doc/faq.rst
View File

@ -83,67 +83,65 @@ HV_RAM_SIZE is changed to 240M
default 0x0f000000 if PLATFORM_UEFI
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
display the overlay video. The hardware can support up to 3 monitors simultaneously.
Some parameters are available to control how display monitors are assigned between the
SOS and UOS, simplifying the assignment policy and providing configuration
flexibility for the pipes and planes in various IOT scenarios
Apollo Lake HW has three pipes and each pipe can have three or four planes which
help to display the overlay video. The hardware can support up to 3 monitors
simultaneously. Some parameters are available to control how display monitors
are assigned between the SOS and UOS(s), simplifying the assignment policy and
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.domain_plane_owners: for controlling the domain mapping for each plane
* ``i915.avail_planes_per_pipe``: for controlling how planes are assigned to the
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.
Currently, pipe A is assigned to SOS and pipes B and C are assigned to UOS,
which uses the below parameter:
In the default configuration, pipe A is assigned to the SOS and pipes B and C
are assigned to the UOS, as described by these parameters:
* SOS:
* SOS::
.. code-block:: bash
i915.avail_planes_per_pipe=0x01010F
i915.domain_plane_owners=0x011111110000
i915.avail_planes_per_pipe=0x01010F
i915.domain_plane_owners=0x011111110000
* UOS::
* UOS:
i915.avail_planes_per_pipe=0x0070F00
.. code-block:: bash
To assign pipes A and B to the UOS, while pipe C is assigned to the SOS, use
these parameters:
i915.avail_planes_per_pipe=0x0070F00
* SOS::
If pipes A and B are assigned to UOS, while pipe C is assigned to SOS,
the below parameters can be used:
i915.avail_planes_per_pipe=0x070101
i915.domain_plane_owners=0x000011111111
* UOS::
* SOS:
i915.avail_planes_per_pipe=0x000F0F
.. code-block:: bash
.. note::
i915.avail_planes_per_pipe=0x070101
i915.domain_plane_owners=0x000011111111
The careful reader may have noticed that in all examples given above, the SOS
always has at least one plane per pipe. This is intentional, and the driver
will enforce this if the parameters do not do this.
* UOS:
Why does ACRN need to know how much RAM the system has?
*******************************************************
.. code-block:: bash
Configuring ACRN at compile time with the system RAM size is a tradeoff between
flexibility and functional safety certification. For server virtualization, one
binary is typically used for all platforms 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 for that product.
i915.avail_planes_per_pipe=0x000F0F
Why does ACRN need to be know how much RAM the system has?
************************************************************
Configuring ACRN at compile time with the system RAM size is
a tradeoff between flexibility and functionality certification.
For server virtualization, one binary is typically used for all platforms
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
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" like 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.
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.