[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH 15/15] 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@xxxxxxxxxx> --- 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 d1bf69b245..6751e4d754 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 |