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 F0BEEC52D7B for ; Tue, 13 Aug 2024 12:05:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type: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=hgU2zxbO4L9WwJ4Iy3G9S7gibS8Uxav3KIGUQEEyFZY=; b=YbjnhR5edBWbBrpg9sniziQZF9 xjH+mTnQ/mDQPnrct57TcrkweN2ykIt0qaELTfm1ZrXCTCjXe0ZUBLDXtP1B1Cu++axpX6kqN+y1K qGl1dfXMuCg4FdjWufFpdRFEh7nHUX6wtGUlFLxtcE408PwrwXkOzH2fCQQTccdDhVA4frvh6Nl1b lhDeOWN9KkASR1NO9j5dpTZ+6QAUv3UJV/tk/vyCvu70L7JRFln+54+bk9f2fCtz8ZtwlfxQK+vZH A8cU+Qo17jlSJYpBSEyBnilRxfczNW7nJyDdD3JMi394wYpJd6h0HbaAEQuFfxVaqJQb0MlbfkA+4 zoR9QkqA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdqH8-00000003cAD-1eDl; Tue, 13 Aug 2024 12:05:18 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdqGV-00000003bxf-1mCS; Tue, 13 Aug 2024 12:04:41 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 20BD3CE0FC9; Tue, 13 Aug 2024 12:04:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B67DCC4AF0B; Tue, 13 Aug 2024 12:04:33 +0000 (UTC) Date: Tue, 13 Aug 2024 13:04:31 +0100 From: Catalin Marinas To: Petr =?utf-8?B?VGVzYcWZw61r?= Cc: Baoquan He , Jinjie Ruan , vgoyal@redhat.com, dyoung@redhat.com, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, chenjiahao16@huawei.com, akpm@linux-foundation.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Will Deacon Subject: Re: [PATCH -next] crash: Fix riscv64 crash memory reserve dead loop Message-ID: References: <20240802090105.3871929-1-ruanjinjie@huawei.com> <20240813104006.520bf42d@mordecai.tesarici.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240813104006.520bf42d@mordecai.tesarici.cz> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240813_050439_677537_C2108ACB X-CRM114-Status: GOOD ( 21.30 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Petr, On Tue, Aug 13, 2024 at 10:40:06AM +0200, Petr Tesařík wrote: > On Tue, 6 Aug 2024 20:34:42 +0100 > Catalin Marinas wrote: > > I haven't tried but it's possible that this patch also breaks those > > arm64 platforms with all RAM above 4GB when CRASH_ADDR_LOW_MAX is > > memblock_end_of_DRAM(). Here all memory would be low and in the absence > > of no fallback, it fails to allocate. > > I'm afraid you've just opened a Pandora box... ;-) Not that bad ;) but, yeah, this patch was dropped in favour of this: https://lore.kernel.org/r/20240812062017.2674441-1-ruanjinjie@huawei.com/ > Another (unrelated) patch series made us aware of a platforms where RAM > starts at 32G, but IIUC the host bridge maps 32G-33G to bus addresses > 0-1G, and there is a device on that bus which can produce only 30-bit > addresses. > > Now, what was the idea behind allocating some crash memory "low"? > Right, it should allow the crash kernel to access devices with > addressing constraints. So, on the above-mentioned platform, allocating > "low" would in fact mean allocating between 32G and 33G (in host address > domain). Indeed. If that's not available, the crash kernel won't be able to boot (unless the corresponding device is removed from DT or ACPI tables). > Should we rethink the whole concept of high/low? Yeah, it would be good to revisit those at some point. For the time being, 'low' in this context on arm64 means ZONE_DMA memory, basically the common denominator address range that supports all devices on an SoC. For others like x86_32, this means the memory that the kernel can actually map (not necessarily device/DMA related). So, it's not always about the DMA capabilities but also what the crash kernel can map (so somewhat different from the zone allocator case we've been discussing in other threads). -- Catalin