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

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



On Thu, 2014-07-03 at 13:33 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 07/03/2014 11:30 AM, Ian Campbell wrote:
> > On Tue, 2014-07-01 at 19:51 +0100, Julien Grall wrote:
> > 
> >> TODO:
> >> I haven't yet hook the code on ARM64 as I'm not sure how undefined
> >> instruction are handled. It looks like there is multiple way to get it
> >> via HSR.
> > 
> > I think EC==0x00 (the catchall) is where it will end up "The attempted
> > execution of an instruction bit patterns that has no allocated
> > instruction at the current Exception level".
> 
> So if EC==0x00 I can safely assume this is a undefined instruction
> exception, right?

No, EC=0x00 is a catch all thing, I think you would need to work out
which reason it was. It might be that having consulted the ARM ARM you
decide that an undefined instruction is the only cause which applies to
us.

> 
> >> +/* ARM doesn't provide any undefined instruction, make our own based on
> >> + * a combination of bits which is not used by the instruction set
> >> + */
> >> +#define BUG_INSTR 0xe7f000f0
> > 
> > Linux uses 0xe7f001f2. I'm not sure what the difference is but it seems
> > safer to follow suit.
> 
> Linux uses multiple different undefined opcode (bug, debugger,...). This
> value is already used in Xen by dump_execution_state (see
> include/asm-arm/processor.h).
> 
> I don't see why we should change it.

OK.



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


 


Rackspace

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