[Xen-changelog] [xen master] xen/arm32: Distinguish guest SError from Xen data aborts

[patchbot@xxxxxxx]

commit 777aecb631402b281882e9465268f287202ec7a4
Author:     Wei Chen <Wei.Chen@xxxxxxx>
AuthorDate: Thu May 4 11:27:49 2017 +0800
Commit:     Stefano Stabellini <sstabellini@xxxxxxxxxx>
CommitDate: Thu May 4 15:00:44 2017 -0700

    xen/arm32: Distinguish guest SError from Xen data aborts
    
    ARM32 doesn't have an exception similar to hyp_sync of ARM64 to catch
    the synchronous data abort (For example, a NULL pointer has been 
referenced).
    Hence the SError and sync data abort will be caught by the same data abort
    exception.
    
    Since commit "3f16c8cb" we treat all data aborts caught by this excetpion
    as SError. This means, we will forward Xen synchronous data abort to guest,
    if the serror_op=FORWARD. This is obviously incorrect. But we don't have
    any method to distinguish SError from Xen data aborts.
    
    But we can distinguish guest generated SError from Xen data aborts. So we
    want to change the policy to handle data aborts for ARM32:
    1. If this data abort is guest generated SError, we will handle this data
       abort follow the SError handle option setting.
    2. If this data abort is synchronous data abort or Xen generate SError, we
       will PANIC the whole system.
    
    Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
---
 xen/arch/arm/arm32/traps.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm32/traps.c b/xen/arch/arm/arm32/traps.c
index 5bc5f64..48baa64 100644
--- a/xen/arch/arm/arm32/traps.c
+++ b/xen/arch/arm/arm32/traps.c
@@ -62,7 +62,18 @@ asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs 
*regs)
 
 asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
 {
-    do_trap_hyp_serror(regs);
+    /*
+     * We cannot distinguish Xen SErrors from synchronous data aborts. We
+     * want to avoid treating any Xen synchronous aborts as SErrors and
+     * forwarding them to the guest. Instead, crash the system in all
+     * cases when the abort comes from Xen. Even if they are Xen SErrors
+     * it would be a reasonable thing to do, and the default behavior with
+     * serror_op == DIVERSE.
+     */
+    if ( VABORT_GEN_BY_GUEST(regs) )
+        do_trap_guest_serror(regs);
+    else
+        do_unexpected_trap("Data Abort", regs);
 }
 
 /*
--
generated by git-patchbot for /home/xen/git/xen.git#master

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