[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |