|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [RFC 05/16] xen/arm: traps: Move the implementation of GUEST_BUG_ON in traps.h
GUEST_BUG_ON may be used in other files doing guest emulation.
Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
---
The patch was previously sent separately.
---
xen/arch/arm/traps.c | 24 ------------------------
xen/include/asm-arm/traps.h | 24 ++++++++++++++++++++++++
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9251ae50b8..b40798084d 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -68,30 +68,6 @@ static inline void check_stack_alignment_constraints(void) {
#endif
}
-/*
- * GUEST_BUG_ON is intended for checking that the guest state has not been
- * corrupted in hardware and/or that the hardware behaves as we
- * believe it should (i.e. that certain traps can only occur when the
- * guest is in a particular mode).
- *
- * The intention is to limit the damage such h/w bugs (or spec
- * misunderstandings) can do by turning them into Denial of Service
- * attacks instead of e.g. information leaks or privilege escalations.
- *
- * GUEST_BUG_ON *MUST* *NOT* be used to check for guest controllable state!
- *
- * Compared with regular BUG_ON it dumps the guest vcpu state instead
- * of Xen's state.
- */
-#define guest_bug_on_failed(p) \
-do { \
- show_execution_state(guest_cpu_user_regs()); \
- panic("Guest Bug: %pv: '%s', line %d, file %s\n", \
- current, p, __LINE__, __FILE__); \
-} while (0)
-#define GUEST_BUG_ON(p) \
- do { if ( unlikely(p) ) guest_bug_on_failed(#p); } while (0)
-
#ifdef CONFIG_ARM_32
static int debug_stack_lines = 20;
#define stack_words_per_line 8
diff --git a/xen/include/asm-arm/traps.h b/xen/include/asm-arm/traps.h
index 70b52d1d16..0acf7de67d 100644
--- a/xen/include/asm-arm/traps.h
+++ b/xen/include/asm-arm/traps.h
@@ -9,6 +9,30 @@
# include <asm/arm64/traps.h>
#endif
+/*
+ * GUEST_BUG_ON is intended for checking that the guest state has not been
+ * corrupted in hardware and/or that the hardware behaves as we
+ * believe it should (i.e. that certain traps can only occur when the
+ * guest is in a particular mode).
+ *
+ * The intention is to limit the damage such h/w bugs (or spec
+ * misunderstandings) can do by turning them into Denial of Service
+ * attacks instead of e.g. information leaks or privilege escalations.
+ *
+ * GUEST_BUG_ON *MUST* *NOT* be used to check for guest controllable state!
+ *
+ * Compared with regular BUG_ON it dumps the guest vcpu state instead
+ * of Xen's state.
+ */
+#define guest_bug_on_failed(p) \
+do { \
+ show_execution_state(guest_cpu_user_regs()); \
+ panic("Guest Bug: %pv: '%s', line %d, file %s\n", \
+ current, p, __LINE__, __FILE__); \
+} while (0)
+#define GUEST_BUG_ON(p) \
+ do { if ( unlikely(p) ) guest_bug_on_failed(#p); } while (0)
+
int check_conditional_instr(struct cpu_user_regs *regs, const union hsr hsr);
void advance_pc(struct cpu_user_regs *regs, const union hsr hsr);
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |