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 <geoffroy.vancutsem@intel.com>

Author: Geoffroy Van Cutsem

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.