[Xen-devel] [PATCH for-4.13 v4 03/19] xen/arm: traps: Rework __do_serror() documentation

[Julien Grall <julien.grall@xxxxxxx>]

The documentation on top of __do_serror() is trying to describe all the
possibilities to receive an SErrors.

The description of type#2 is quite misleading because receiving an
SError in EL2 after unmasking SError interrupt ({PSTATE, CPSR}.A) does
not necessarily imply the SError were generated by the guest. You also
need to be in a special window (see abort_guest_exist_{guest, end}).

However, for the context of the function it does not matter how we
categorize the interrupts. What matter is to know whether this is a
guest-generated SError.

All the documentation of __do_serror() is now reworked to avoid
misleading information.

Take the opportunity to simplify the code after the forward option has
been dropped.

Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

---
    Changes in v3:
        - Fix typo
        - Add Stefano's acked-by

    Changes in v2:
        - Patch added
---
 xen/arch/arm/traps.c | 36 +++++++++++++-----------------------
 1 file changed, 13 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6ed9e66710..3262052f47 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -660,41 +660,31 @@ static void inject_vabt_exception(struct cpu_user_regs 
*regs)
 }
 
 /*
- * SError exception handler. We only handle the following 3 types of SErrors:
- * 1) Guest-generated SError and had been delivered in EL1 and then
- *    been forwarded to EL2.
- * 2) Guest-generated SError but hadn't been delivered in EL1 before
- *    trapping to EL2. This SError would be caught in EL2 as soon as
- *    we just unmasked the PSTATE.A bit.
- * 3) Hypervisor generated native SError, that would be a bug.
+ * SError exception handler.
  *
  * A true parameter "guest" means that the SError is type#1 or type#2.
  *
+ * @guest indicates whether this is a SError generated by the guest.
+ *
+ * If true, the SError was generated by the guest, so it is safe to continue
+ * and forward to the guest (if requested).
+ *
+ * If false, the SError was likely generated by the hypervisor. As we cannot
+ * distinguish between precise and imprecise SErrors, it is not safe to
+ * continue.
+ *
  * Note that Arm32 asynchronous external abort generated by the
  * hypervisor will be handled in do_trap_data_abort().
  */
 static void __do_trap_serror(struct cpu_user_regs *regs, bool guest)
 {
     /*
-     * Only "DIVERSE" option needs to distinguish the guest-generated SErrors
-     * from hypervisor SErrors.
+     * When using "DIVERSE", the SErrors generated by the guest will be
+     * forwarded to the currently running vCPU.
      */
-    if ( serrors_op == SERRORS_DIVERSE )
-    {
-        /* Forward the type#1 and type#2 SErrors to guests. */
-        if ( guest )
+    if ( serrors_op == SERRORS_DIVERSE && guest )
             return inject_vabt_exception(regs);
 
-        /* Type#3 SErrors will panic the whole system */
-        goto crash_system;
-    }
-
-crash_system:
-    /*
-     * Two possibilities to crash the whole system:
-     * 1) "DIVERSE" option with Hypervisor generated SErrors.
-     * 2) "PANIC" option with all SErrors.
-     */
     do_unexpected_trap("SError", regs);
 }
 
-- 
2.11.0


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