[Xen-devel,for-4.13,v4,04/19] docs/misc: xen-command-line: Rework documentation of the option 'serrors'

Message ID 20191031150922.22938-5-julien.grall@arm.com
State New
Headers show
Series
  • xen/arm: XSA-201 and XSA-263 fixes
Related show

Commit Message

Julien Grall Oct. 31, 2019, 3:09 p.m.
The current documentation is misleading for a few reasons:
    1) The synchronization happens on all exit/entry from/to the guest.
       This includes from EL0 (i.e userspace).
    2) Trusted guest can also generate SErrors (e.g. memory failure)
    3) Without RAS support, SErrors are IMP DEFINED. Unless you have a
    complete TRM in hand, you can't really make a decision.
    4) The documentation is written around performance when this is not
    the first concern.

The documentation is now reworked to focus on the consequences of using
serrors="panic" and avoid to go in details on the exact implementation.

Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>

---

TBH, I think this was a mistake to introduce more options without
understanding the real use case from the users and the impact. I am not
totally against serrors="panic" but I don't think this can be safely
used by anyone withtout having a TRM in hand that exhaustively describes
all the SErrors.

    Changes in v4:
        - Add Stefano's acked-by

    Changes in v2:
        - Patch added
---
 docs/misc/xen-command-line.pandoc | 33 +++++++++------------------------
 1 file changed, 9 insertions(+), 24 deletions(-)

Patch

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index b8a09ce5c4..451d213c8c 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1854,34 +1854,19 @@  Set the serial transmit buffer size.
 
 > Default: `diverse`
 
-This parameter is provided to administrators to determine how the
-hypervisors handle SErrors.
-
-In order to distinguish guest-generated SErrors from hypervisor-generated
-SErrors we have to place SError checking code in every EL1 <-> EL2 paths.
-That will cause overhead on entries and exits due to dsb/isb. However, not all
-platforms need to categorize SErrors. For example, a host that is running with
-trusted guests. The administrator can confirm that all guests that are running
-on the host will not trigger such SErrors. In this case, the administrator can
-use this parameter to skip categorizing SErrors and reduce the overhead of
-dsb/isb.
-
-We provided the following 2 options to administrators to determine how the
-hypervisors handle SErrors:
+This parameter is provided to administrators to determine how the hypervisor
+handles SErrors.
 
 * `diverse`:
-  The hypervisor will distinguish guest SErrors from hypervisor SErrors.
-  The guest generated SErrors will be forwarded to guests, the hypervisor
-  generated SErrors will cause the whole system to crash.
-  It requires:
-  1. dsb/isb on all EL1 -> EL2 trap entries to categorize SErrors correctly.
-  2. dsb/isb on EL2 -> EL1 return paths to prevent slipping hypervisor
-     SErrors to guests.
+  The hypervisor will distinguish guest SErrors from hypervisor SErrors:
+    - The guest generated SErrors will be forwarded to the currently running
+      guest.
+    - The hypervisor generated SErrors will cause the whole system to crash
 
 * `panic`:
-  The hypervisor will not distinguish guest SErrors from hypervisor SErrors.
-  All SErrors will crash the whole system. This option will avoid all overhead
-  of the dsb/isb pairs.
+  All SErrors will cause the whole system to crash. This option should only
+  be used if you trust all your guests and/or they don't have a gadget (e.g.
+  device) to generate SErrors in normal run.
 
 ### shim_mem (x86)
 > `= List of ( min:<size> | max:<size> | <size> )`