Re: [Xen-devel] [PATCH v2 4/9] xen: arm: correctly handle vtimer traps from userspace

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-02-19 at 14:42 +0000, Julien Grall wrote:
> >>
> >> [..]
> >>
> >>> @@ -2062,8 +2053,7 @@ asmlinkage void do_trap_hypervisor(struct 
> >>> cpu_user_regs *regs)
> >>>           do_cp15_32(regs, hsr);
> >>>           break;
> >>>       case HSR_EC_CP15_64:
> >>> -        if ( !is_32bit_domain(current->domain) )
> >>> -            goto bad_trap;
> >>> +        BUG_ON(!psr_mode_is_32bit(regs->cpsr));
> >>
> >> You should mention the change from if ( .... ) goto bad_trap to BUG_ON( 
> >> ... ) in the commit message.
> > 
> > OK.
> > 
> >> Although, I think the debug message in bad_trap is useful to keep. It 
> >> may be handy to have the HSR and the guest stack trace printed if Xen 
> >> hit the condition.
> > 
> > Doesn't BUG_ON include all that? It should really.
> 
> Not really BUG_ON will jump into the exception mode and therefore print
> the HSR of the exception (breakpoint for ARM64 and undef for ARM32).

Hrm, good point.

Rather than reintroducing the goto idiom what about some form of
noreturn panic helper for checking for sane h/w state (since these
failures are really of the "buggy hardware" variety) e.g.
ASSERT_GUEST_STATE(is_32bit_domain(...)) which would dump the guest
state and then panic?

Since these scenarios really indicate some sort of h/w fault I'm
considering making them debug=y only, as indicated by the use of
ASSERT_FOO.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel