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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90E10C432C3 for ; Sat, 16 Nov 2019 19:31:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5288A20733 for ; Sat, 16 Nov 2019 19:31:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="C24zPtv/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727421AbfKPTba (ORCPT ); Sat, 16 Nov 2019 14:31:30 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:41131 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727195AbfKPTba (ORCPT ); Sat, 16 Nov 2019 14:31:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573932689; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kXpw2dVrTazyKaZMh6ck8gLXd7z/Kkh/NRaCUtk9LZE=; b=C24zPtv/tOXiiZuK8es2a1qkHRNrsO0FSZAiVXeo7we/Qau5HWKvbcXk1vh/BeBwhJMLH/ SPbR+xtT0PMq55RHCNSJ6DbivoSN64Ssn0cDfoq8iNjw9dFG7xDOM1RyF05u6MwFG0PZcM gSZI/pWphW/k5Z6wzMEC4+zLX+3zhhk= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-75-1LeQT-2TPYqvFXXRtIWR6Q-1; Sat, 16 Nov 2019 14:31:25 -0500 Received: by mail-lf1-f69.google.com with SMTP id q1so4085195lfp.16 for ; Sat, 16 Nov 2019 11:31:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=tr1QPh7Xu6oqNv9urwYmGQnpnrlexXqmQZ13m1gKg9g=; b=bih6Mup8FL83GbL1XHWA4KZHd9qYf3z37bJsonyKjyWWVzoCMS279sY6UYquJSfT/a 2PfL3K0SRGQDoOf8/9Npfa9L7DTO0dhHwT87KS5Hqn1nIgq6In7TtF+LFYZ60f9+e8Z7 e2iTySPSL0/X5gtnlbNRdWNSvR3gBAyNzUTx3InHacNi0OoBZ4uiKnKtiid6tOqO3PWL V5pwNppVSVvswE7Zx39NX56CivkhLBtMGtzj6cYsocU/x5zStxMT1pLPUULpwdPVNm0V dLOOcBdco0xlZs/lo1W8ASF4heLPy2FpQLQcMjm2tR6S95fAog64YnMgP7GEKSw9QvWD qoGQ== X-Gm-Message-State: APjAAAWxJ4R2NrIJVTzoaiCPdBm8mh+WhTWxKsE6nhVkweq0MvmAPkfY tVo6ngZAXLCx9mJrdzFyVN15bSYNev+N4v/2sDJQVh/JWkC2F/eFIAlu2HOJWIufxb8yXDncJgN 0CQ11h+bNzvI1bt4AKP6Ax3hIZp1RRRUHS/X66E5h X-Received: by 2002:a2e:98c6:: with SMTP id s6mr14176667ljj.235.1573932684240; Sat, 16 Nov 2019 11:31:24 -0800 (PST) X-Google-Smtp-Source: APXvYqzV/Uq0MfcKB6Ngj9rRD+2Lhzxf6cVhsnPdiYYnO35ay585YEXFW53R4j8ojT574iLVnqEYnyQDdNGcl2Jhl3c= X-Received: by 2002:a2e:98c6:: with SMTP id s6mr14176647ljj.235.1573932683821; Sat, 16 Nov 2019 11:31:23 -0800 (PST) MIME-Version: 1.0 References: <1573459282-26989-1-git-send-email-bhsharma@redhat.com> <20191113063858.GE22427@linaro.org> <20191115015959.GI22427@linaro.org> In-Reply-To: <20191115015959.GI22427@linaro.org> From: Bhupesh Sharma Date: Sun, 17 Nov 2019 01:01:05 +0530 Message-ID: Subject: Re: [PATCH v4 0/3] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs) To: AKASHI Takahiro , Bhupesh Sharma , Linux Kernel Mailing List , Bhupesh SHARMA , Boris Petkov , Ingo Molnar , Thomas Gleixner , Jonathan Corbet , James Morse , Mark Rutland , Will Deacon , Steve Capper , Catalin Marinas , Ard Biesheuvel , Michael Ellerman , Paul Mackerras , Benjamin Herrenschmidt , Dave Anderson , Kazuhito Hagio , x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel , Linux Doc Mailing List , kexec mailing list X-MC-Unique: 1LeQT-2TPYqvFXXRtIWR6Q-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Akashi, On Fri, Nov 15, 2019 at 7:29 AM AKASHI Takahiro wrote: > > Bhupesh, > > On Fri, Nov 15, 2019 at 01:24:17AM +0530, Bhupesh Sharma wrote: > > Hi Akashi, > > > > On Wed, Nov 13, 2019 at 12:11 PM AKASHI Takahiro > > wrote: > > > > > > Hi Bhupesh, > > > > > > Do you have a corresponding patch for userspace tools, > > > including crash util and/or makedumpfile? > > > Otherwise, we can't verify that a generated core file is > > > correctly handled. > > > > Sure. I am still working on the crash-utility related changes, but you > > can find the makedumpfile changes I posted a couple of days ago here > > (see [0]) and the github link for the makedumpfile changes can be seen > > via [1]. > > > > I will post the crash-util changes shortly as well. > > Thanks for having a look at the same. > > Thank you. > I have tested my kdump patch with a hacked version of crash > where VA_BITS_ACTUAL is calculated from tcr_el1_t1sz in vmcoreinfo. Thanks a lot for testing the changes. I will push the crash utility changes for review shortly and also Cc you to the patches. It would be great to have your Tested-by for this patch-set, if the user-space works fine for you with these changes. Regards, Bhupesh > -Takahiro Akashi > > > > [0]. http://lists.infradead.org/pipermail/kexec/2019-November/023963.ht= ml > > [1]. https://github.com/bhupesh-sharma/makedumpfile/tree/52-bit-va-supp= ort-via-vmcore-upstream-v4 > > > > Regards, > > Bhupesh > > > > > > > > Thanks, > > > -Takahiro Akashi > > > > > > On Mon, Nov 11, 2019 at 01:31:19PM +0530, Bhupesh Sharma wrote: > > > > Changes since v3: > > > > ---------------- > > > > - v3 can be seen here: > > > > http://lists.infradead.org/pipermail/kexec/2019-March/022590.html > > > > - Addressed comments from James and exported TCR_EL1.T1SZ in vmcore= info > > > > instead of PTRS_PER_PGD. > > > > - Added a new patch (via [PATCH 3/3]), which fixes a simple typo in > > > > 'Documentation/arm64/memory.rst' > > > > > > > > Changes since v2: > > > > ---------------- > > > > - v2 can be seen here: > > > > http://lists.infradead.org/pipermail/kexec/2019-March/022531.html > > > > - Protected 'MAX_PHYSMEM_BITS' vmcoreinfo variable under CONFIG_SPA= RSEMEM > > > > ifdef sections, as suggested by Kazu. > > > > - Updated vmcoreinfo documentation to add description about > > > > 'MAX_PHYSMEM_BITS' variable (via [PATCH 3/3]). > > > > > > > > Changes since v1: > > > > ---------------- > > > > - v1 was sent out as a single patch which can be seen here: > > > > http://lists.infradead.org/pipermail/kexec/2019-February/022411.h= tml > > > > > > > > - v2 breaks the single patch into two independent patches: > > > > [PATCH 1/2] appends 'PTRS_PER_PGD' to vmcoreinfo for arm64 arch, = whereas > > > > [PATCH 2/2] appends 'MAX_PHYSMEM_BITS' to vmcoreinfo in core kern= el code (all archs) > > > > > > > > This patchset primarily fixes the regression reported in user-space > > > > utilities like 'makedumpfile' and 'crash-utility' on arm64 architec= ture > > > > with the availability of 52-bit address space feature in underlying > > > > kernel. These regressions have been reported both on CPUs which don= 't > > > > support ARMv8.2 extensions (i.e. LVA, LPA) and are running newer ke= rnels > > > > and also on prototype platforms (like ARMv8 FVP simulator model) wh= ich > > > > support ARMv8.2 extensions and are running newer kernels. > > > > > > > > The reason for these regressions is that right now user-space tools > > > > have no direct access to these values (since these are not exported > > > > from the kernel) and hence need to rely on a best-guess method of > > > > determining value of 'vabits_actual' and 'MAX_PHYSMEM_BITS' support= ed > > > > by underlying kernel. > > > > > > > > Exporting these values via vmcoreinfo will help user-land in such c= ases. > > > > In addition, as per suggestion from makedumpfile maintainer (Kazu), > > > > it makes more sense to append 'MAX_PHYSMEM_BITS' to > > > > vmcoreinfo in the core code itself rather than in arm64 arch-specif= ic > > > > code, so that the user-space code for other archs can also benefit = from > > > > this addition to the vmcoreinfo and use it as a standard way of > > > > determining 'SECTIONS_SHIFT' value in user-land. > > > > > > > > Cc: Boris Petkov > > > > Cc: Ingo Molnar > > > > Cc: Thomas Gleixner > > > > Cc: Jonathan Corbet > > > > Cc: James Morse > > > > Cc: Mark Rutland > > > > Cc: Will Deacon > > > > Cc: Steve Capper > > > > Cc: Catalin Marinas > > > > Cc: Ard Biesheuvel > > > > Cc: Michael Ellerman > > > > Cc: Paul Mackerras > > > > Cc: Benjamin Herrenschmidt > > > > Cc: Dave Anderson > > > > Cc: Kazuhito Hagio > > > > Cc: x86@kernel.org > > > > Cc: linuxppc-dev@lists.ozlabs.org > > > > Cc: linux-arm-kernel@lists.infradead.org > > > > Cc: linux-kernel@vger.kernel.org > > > > Cc: linux-doc@vger.kernel.org > > > > Cc: kexec@lists.infradead.org > > > > > > > > Bhupesh Sharma (3): > > > > crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo > > > > arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo > > > > Documentation/arm64: Fix a simple typo in memory.rst > > > > > > > > Documentation/arm64/memory.rst | 2 +- > > > > arch/arm64/include/asm/pgtable-hwdef.h | 1 + > > > > arch/arm64/kernel/crash_core.c | 9 +++++++++ > > > > kernel/crash_core.c | 1 + > > > > 4 files changed, 12 insertions(+), 1 deletion(-) > > > > > > > > -- > > > > 2.7.4 > > > > > > > > > >