From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v2] xen/arm: Correctly support WARN_ON Date: Tue, 09 Sep 2014 11:31:47 -0700 Message-ID: <540F4793.8080603@linaro.org> References: <1407256336-11839-1-git-send-email-julien.grall@linaro.org> <1410181281.3680.3.camel@kazak.uk.xensource.com> <540E0128.8070506@linaro.org> <1410254228.8217.50.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XRQCn-0004SF-1j for xen-devel@lists.xenproject.org; Tue, 09 Sep 2014 18:31:53 +0000 Received: by mail-qg0-f49.google.com with SMTP id j5so4473675qga.8 for ; Tue, 09 Sep 2014 11:31:49 -0700 (PDT) In-Reply-To: <1410254228.8217.50.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 09/09/14 02:17, Ian Campbell wrote: > On Mon, 2014-09-08 at 12:19 -0700, Julien Grall wrote: >> Hi Ian, >> >> On 08/09/14 06:01, Ian Campbell wrote: >>>> + /* PC is always 4-byte align, as Xen is using ARM instruction set */ >>> >>> "aligned" >> >> Ok. >> >>> Is it worth a check here? I presume the nested fault if PC were >>> misaligned would be pretty exciting, print+goto die would seem >>> appropriate. >> >> I don't think so. The "undefined instruction" is only used when the >> processor is unable to decode the instruction. If it fails to load the >> instruction (because a wrong memory address, pc misaligned), Xen would >> have received a "prefetch abort". > > I was thinking of something either wrongly or rightly transitioning to > thumb mode. It'd have to be something horrible like a broken firmware > returning from a PSCI call in the wrong mode or something like that > though. The thumb mode is stored in SPSR which is a banked registers. Your use case can only happen if the secure mode decides to modify the registers of the hypervisor. It would be very stupid from the firmware and other bad things could happen. >>>> }> +#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 >>>> + */ >>> >>> BUG_ON? ;-O >> >> Sounds a good plan. > > Just be careful that it won't recurse ;-) Panic should never go in exception mode, so I will use it instead. Regards, -- Julien Grall