[Xen-changelog] [xen staging] xen/arm: Update the ASSERT() in SYNCHRONIZE_SERROR()

[patchbot@xxxxxxx]

commit 2e2356c7bd8f99aa42ed60ceed0e4ba4e06adb8f
Author:     Julien Grall <julien.grall@xxxxxxx>
AuthorDate: Mon Oct 7 13:57:00 2019 +0100
Commit:     Julien Grall <julien.grall@xxxxxxx>
CommitDate: Fri Nov 1 14:33:32 2019 +0000

    xen/arm: Update the ASSERT() in SYNCHRONIZE_SERROR()
    
    The macro SYNCHRONIZE_SERROR() has an assert to check whether it will
    be called with Abort interrupt unmasked. However, this is only done if
    a given cap is not enabled.
    
    None of the callers will treat the abort interrupt differently
    depending on a feature. Furthermore, it makes more difficult to check
    whether SYNCHRONIZE_SERROR() is going to be called with abort interrupt
    unmasked.
    
    Therefore, we now require the abort interrupt to be unmasked regardless
    the state of the cap.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>
---
 xen/include/asm-arm/processor.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index e9d2ae2715..aa642e3ab2 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -542,7 +542,7 @@ register_t get_default_hcr_flags(void);
  */
 #define SYNCHRONIZE_SERROR(feat)                                  \
     do {                                                          \
-        ASSERT(!cpus_have_cap(feat) || local_abort_is_enabled()); \
+        ASSERT(local_abort_is_enabled());                         \
         asm volatile(ALTERNATIVE("dsb sy; isb",                   \
                                  "nop; nop", feat)                \
                                  : : : "memory");                 \
--
generated by git-patchbot for /home/xen/git/xen.git#staging

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