From 904c9e291e2b966eedae4c68a1b9c061d23bfd10 Mon Sep 17 00:00:00 2001 From: Geoffroy Van Cutsem Date: Thu, 21 Mar 2019 10:00:27 +0100 Subject: [PATCH] doc: add more details to the FAQ (for version 0.7) Add more details and clarifications to the new FAQ being added for v0.7 Signed-off-by: Geoffroy Van Cutsem --- doc/faq.rst | 88 ++++++++++++++++++++++++++--------------------------- 1 file changed, 43 insertions(+), 45 deletions(-) diff --git a/doc/faq.rst b/doc/faq.rst index 7cd990e77..ff8b4cc8a 100644 --- a/doc/faq.rst +++ b/doc/faq.rst @@ -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.