From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] xen/arm: Correctly support WARN_ON Date: Thu, 03 Jul 2014 13:33:37 +0100 Message-ID: <53B54DA1.3000506@linaro.org> References: <1404240719-13164-1-git-send-email-julien.grall@linaro.org> <1404383420.14865.53.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1X2gCu-00069H-H7 for xen-devel@lists.xenproject.org; Thu, 03 Jul 2014 12:33:44 +0000 Received: by mail-wg0-f41.google.com with SMTP id a1so164386wgh.12 for ; Thu, 03 Jul 2014 05:33:42 -0700 (PDT) In-Reply-To: <1404383420.14865.53.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org 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? >> +/* 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. Regards, -- Julien Grall