From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 725DEECAAD3 for ; Fri, 9 Sep 2022 10:38:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9e9qeEHDVafr+A1p+GdDb55kmAHWICIpWNq+V4jRo7o=; b=WzZ2CAbvAGDspm 1rI39ZGJnOVXVgmqvWBnhSw7phZf4vdMwat3WBXj+4A6AwfjQh+0HSrLvuslPhrCcwvLDRbMzb31W THlMwAgGtIzXPCkDs2/j70gFzyfxr7RkuMGEivvYJ8muS/kVwFdPDPg80dqRj00ugG6+AGmxLhGmN PbHKT0b/+GA3+sJ3IYTDdxV9SPh5hIwa/s5er2PapFoykFMqr01rvjIRZpak45/FaPOZh6+Kvm5Pn kHE9rog2CPKPn43IYtqRT3p/0WljIXVoYEmPo/Kgpe0h/QzuEra3zp336/9vT6Fld0LTWRevBsieA r6Eha/xTTZNpKVARyKxw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oWbON-00FQ50-1a; Fri, 09 Sep 2022 10:37:47 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oWbOD-00FQ3I-OY for linux-arm-kernel@lists.infradead.org; Fri, 09 Sep 2022 10:37:43 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 57D9CB82244; Fri, 9 Sep 2022 10:37:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF642C433C1; Fri, 9 Sep 2022 10:37:33 +0000 (UTC) Date: Fri, 9 Sep 2022 11:37:30 +0100 From: Catalin Marinas To: Peter Collingbourne Cc: Will Deacon , Mark Brown , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: translate register values to physical addresses in kernel panics Message-ID: References: <20220812183530.2261795-1-pcc@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220812183530.2261795-1-pcc@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220909_033737_989014_FACCB100 X-CRM114-Status: GOOD ( 21.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Aug 12, 2022 at 11:35:30AM -0700, Peter Collingbourne wrote: > When debugging a kernel panic it is sometimes useful to know the physical > address of any virtual addresses stored in registers. Therefore, pass > all register values through AT S1E1R and print the resulting PAR_EL1 > value next to the register. I don't see much value in this but I haven't come across a use-case yet. For page faults the kernel prints the content of the PTE and that's what I'm usually interested in. > Not sure if this should land in this form (I imagine there could be > all kinds of parsers that are expecting the existing format) but > maybe behind an option. Let me know what you think. While that's not considered user ABI, there might be some scripts parsing it, though I suspect they don't pay attention to the registers (I might be wrong though). > +static unsigned long at(unsigned long addr) > +{ > + unsigned long pa; > + > + __asm__ __volatile__("at s1e1r, %1\n" > + "mrs %0, par_el1\n" > + : "=r"(pa) > + : "r"(addr) > + : "memory"); > + return pa; > +} This should take the translation fault into account. If PAR_EL1.F is 1, the other bits can't be treated as a physical address. Also if you want the actual address, it's also worth masking out the non-relevant bits from PAR_EL1 and adding the offset from 'addr' into the lower 12 bits. > void __show_regs(struct pt_regs *regs) > { > int i, top_reg; > @@ -231,10 +243,10 @@ void __show_regs(struct pt_regs *regs) > i = top_reg; > > while (i >= 0) { > - printk("x%-2d: %016llx", i, regs->regs[i]); > + printk("x%-2d: %016llx (%016llx)", i, regs->regs[i], at(regs->regs[i])); > > while (i-- % 3) > - pr_cont(" x%-2d: %016llx", i, regs->regs[i]); > + pr_cont(" x%-2d: %016llx (%016llx)", i, regs->regs[i], at(regs->regs[i])); How long are the lines printed here? Maybe a better option without cluttering the register values is to do another pass through the register and print the potential VA->PA translations (only those kernel addresses that do not fault). If one is interested they could look them up on the following lines. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel