[Xen-changelog] [xen staging] xen/arm: traps: Rework __do_serror() documentation

[patchbot@xxxxxxx]

commit ae2f94ca67035ee2cd769deed48e4832328d41ba
Author:     Julien Grall <julien.grall@xxxxxxx>
AuthorDate: Thu Oct 31 15:09:06 2019 +0000
Commit:     Julien Grall <julien.grall@xxxxxxx>
CommitDate: Fri Nov 1 13:57:07 2019 +0000

    xen/arm: traps: Rework __do_serror() documentation
    
    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>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>
---
 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);
 }
 
--
generated by git-patchbot for /home/xen/git/xen.git#staging

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