[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3] xen/arm: Correctly support WARN_ON

On Wed, 2014-09-10 at 16:33 -0700, Julien Grall wrote:
> Currently the hypervisor will hang if it hits a WARN_ON.
> The implemention uses an undefined instruction, made ourself because ARM


> doesn't provide one, to implement BUG/ASSERT/WARN_ON, and sets up the
> different tables (one for each type) which contain useful information.
> This is based on the x86 implementation (include/asm-x86/bug.h). Unfortunately
> the structure can't be shared because many ARM{32,64} gcc versions doesn't


> correctly support %c. The support of executing a function in an exception 
> handler


> is also keep unimplemented on ARM. Therefore, dump_execution_state is
> implement as WARN()


> +#ifdef CONFIG_ARM_64
> +static void do_trap_brk(struct cpu_user_regs *regs, union hsr hsr)
> +{
> +    /* HCR_EL2.TGE and MDCR_EL2.TDE are not set so we never receive
> +     * software breakpoint exception for EL1 and EL0 here
> +     */
> +    /* It's not possible to use BUG_ON here, because we would recurse */
> +    if ( unlikely(READ_SYSREG(HCR_EL2) & HCR_TGE) ||
> +         unlikely(READ_SYSREG(MDCR_EL2) & HDCR_TDE) )
> +        panic("Unable to handle brk exception from EL1/EL0");

Either of those bits being set doesn't imply that *this* trap came from

The correct check would be BUG_ON(!hyp_mode(regs)) which I think won't
recurse because the resulting BRK will pass the check the second time,
although if you want to if (!hyp_mode(regs)) panic(...) instead that's
fine too.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.