From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v2] xen/arm: Correctly support WARN_ON Date: Wed, 10 Sep 2014 12:02:37 -0700 Message-ID: <5410A04D.8010405@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> <540F4793.8080603@linaro.org> <1410341710.8217.265.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 1XRnA9-0005ZR-N9 for xen-devel@lists.xenproject.org; Wed, 10 Sep 2014 19:02:41 +0000 Received: by mail-qc0-f179.google.com with SMTP id o8so3747866qcw.10 for ; Wed, 10 Sep 2014 12:02:39 -0700 (PDT) In-Reply-To: <1410341710.8217.265.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 10/09/14 02:35, Ian Campbell wrote: > On Tue, 2014-09-09 at 11:31 -0700, Julien Grall wrote: >> 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. > > Yes, as I said it would need to be horribly broken firmware. I wouldn't > rule out the ability of firmware to do horribly broken things though. Ok. I will add a check and directly go to die. Regards, -- Julien Grall