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

[Julien Grall <julien.grall@xxxxxxx>]

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@xxxxxxx>
Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

---

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(-)

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> )`
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel