@@ -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);
}
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@arm.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> --- 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(-)