[Xen-changelog] [xen master] xen/arm: Introduce a command line parameter for SErrors/Aborts

[patchbot@xxxxxxx]

commit be3a53a1cc1da732bbb1ec83157f1572d78e29f4
Author:     Wei Chen <Wei.Chen@xxxxxxx>
AuthorDate: Wed Apr 5 17:09:09 2017 +0800
Commit:     Stefano Stabellini <sstabellini@xxxxxxxxxx>
CommitDate: Wed Apr 5 12:12:20 2017 -0700

    xen/arm: Introduce a command line parameter for SErrors/Aborts
    
    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 want 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 use-case, we should provide some options to administrators to avoid
    categorizing SErrors and then reduce the overhead of dsb/isb.
    
    We provided the following 3 options to administrators to determine how
    the hypervisors handle 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.
      3. dsb/isb in context switch to isolate SErrors between 2 vCPUs.
    
    * `forward`:
      The hypervisor will not distinguish guest SErrors from hypervisor
      SErrors. All SErrors will be forwarded to guests, except the SErrors
      generated when  the idle vCPU is running. The idle domain doesn't have
      the ability to handle SErrors, so we have to crash the whole system when
      we get SErros with the idle vCPU. This option will avoid most overhead
      of the dsb/isb, except the dsb/isb in context switch which is used to
      isolate the SErrors between 2 vCPUs.
    
    * `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.
    
    Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
---
 docs/misc/xen-command-line.markdown | 44 +++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c                | 19 ++++++++++++++++
 2 files changed, 63 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 9690512..5815d87 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1470,6 +1470,50 @@ enabling more sockets and cores to go into deeper sleep 
states.
 
 Set the serial transmit buffer size.
 
+### serrors (ARM)
+> `= diverse | forward | panic`
+
+> 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 3 options to administrators to determine how the
+hypervisors handle 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.
+  3. dsb/isb in context switch to isolate SErrors between 2 vCPUs.
+
+* `forward`:
+  The hypervisor will not distinguish guest SErrors from hypervisor SErrors.
+  All SErrors will be forwarded to guests, except the SErrors generated when
+  the idle vCPU is running. The idle domain doesn't have the ability to handle
+  SErrors, so we have to crash the whole system when we get SErros with the
+  idle vCPU. This option will avoid most overhead of the dsb/isb, except the
+  dsb/isb in context switch which is used to isolate the SErrors between 2
+  vCPUs.
+
+* `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.
+
 ### smap
 > `= <boolean> | hvm`
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index a24d986..41955af 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -143,6 +143,25 @@ register_t get_default_hcr_flags(void)
              HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB);
 }
 
+static enum {
+    SERRORS_DIVERSE,
+    SERRORS_FORWARD,
+    SERRORS_PANIC,
+} serrors_op;
+
+static void __init parse_serrors_behavior(const char *str)
+{
+    if ( !strcmp(str, "forward") )
+        serrors_op = SERRORS_FORWARD;
+    else if ( !strcmp(str, "panic") )
+        serrors_op = SERRORS_PANIC;
+    else
+        serrors_op = SERRORS_DIVERSE;
+
+    return;
+}
+custom_param("serrors", parse_serrors_behavior);
+
 void init_traps(void)
 {
     /* Setup Hyp vector base */
--
generated by git-patchbot for /home/xen/git/xen.git#master

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
https://lists.xenproject.org/xen-changelog