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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 06E6EC433ED for ; Tue, 18 May 2021 11:51:25 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BA2B0610A2 for ; Tue, 18 May 2021 11:51:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA2B0610A2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=hcEWx2HPJUtrxa6WMD1TC2+whRtc0u3eOIaURGy4OXo=; b=bzd6N8fuguZxVupmEVINYQaUr SD5fXM+1obn4S3EmEgvMllTKrHX4dWPgGNYRlpK9f0ks6Ug3zItjFhdluTRZZ+kh+EkQ7SMhFp0jR UTMyGVFeSkCkDd12OOv537R6lvwMN1I1jqTYCOI5Ojam0SR6bJfLa4/tCZV6npNkWoMKvlNLBsi1B jSBc7qVAIFxFKsYE1hCALfJIcZSLxL6pxjs90hQvvVw/hCe9HJfoCO8fvHLcuFDKQXcbx7EFM2L4M XAGO1vP4+T/aR4zgX/pwdWSCfIILM5fImiBVm4o6o53YkhsZKjNgO8RCUb8L6mBMmlpI+EA9608H1 LOJ6Quw5w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1liyEN-000dgE-Hl; Tue, 18 May 2021 11:49:47 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1liyDj-000dUL-OC; Tue, 18 May 2021 11:49:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=dz/HynUQwr1V5LCzsOveTiuqrV90+CFma1jEl+NTIX4=; b=Jsn3rdJpSpOS6TMlP76n0lCbgn beaamdNqLdRXo7UjGo4yR+Ih9IEdhR+l8lmFm8eZqjGxVMOrN/Hbzugx2/pjtUgG1WnIijp4O+M2B ZA6AcqHY15fLmB6VvcBKW5Kwf6/4X4Vg1LJSpqSx5EEPTkapE3VlBcnjQXX7iXU85wadatytgw8Kz j4+Hbb870DDpuLY6iTDN/4InQxJX6uUF8g5r21ZyjZphc/J+kmvKVkwyPFAIPFe+LpN6O0g2j7VRB LCwxlYExuEmiH2KkSgKzUk/XcqcYB1ddxXIzGxZ4Ztdp8EdPetH+fh/svlBrNTLqGQOMn2sIMcJRS cpJOdluQ==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1liyDh-00EcFg-7y; Tue, 18 May 2021 11:49:06 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9FCB4610A2; Tue, 18 May 2021 11:49:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621338544; bh=LSR8cULDG+3dqeRWrIrXD51l2GKgAbwx/0xs249uFt8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SZksEu+V2hX8vOPpiIRGxeBf7IMkF5W3VRwA5Y+akOR5cv9Dd88oEfG4D6vEbLeoW jKLre89DByUWkESeVjaL9bRB9MIKFAIcFAuVf19xyIoAEL4pjX6CoDF37LW3NqPv8l +JLXI6gbOIvnHFazkFBnNkotkVzssnHS4nqpRxEY1BERWEIlHQ6tKj+BFPv3IH6JlP emoiQ4N39LOKFztnTRiLz3knK9WJokHRhxfkW1eJJhliH7pWcWlE/Y0FpPcTteY9g5 CvpHLVBxGhGaq0etfNGw2z3gq2Tp+SXwwzUJ5yrAjL0RdlVn0tgdDGV1XFWUNadMJ7 2HRkE1fJMXfWQ== Date: Tue, 18 May 2021 12:48:58 +0100 From: Will Deacon To: Marc Zyngier Cc: kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Catalin Marinas , Ard Biesheuvel , Mark Rutland , James Morse , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , Eric Biederman , bhupesh.sharma@linaro.org, AKASHI Takahiro , kernel-team@android.com Subject: Re: [PATCH 0/2] arm64: kexec_file_load vs memory reservations Message-ID: <20210518114857.GA7914@willie-the-truck> References: <20210429133533.1750721-1-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210429133533.1750721-1-maz@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210518_044905_322536_2491972E X-CRM114-Status: GOOD ( 17.64 ) 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 [Fixing Bhupesh's email address] On Thu, Apr 29, 2021 at 02:35:31PM +0100, Marc Zyngier wrote: > It recently became apparent that using kexec with kexec_file_load() on > arm64 is pretty similar to playing Russian roulette. > > Depending on the amount of memory, the HW supported and the firmware > interface used, your secondary kernel may overwrite critical memory > regions without which the secondary kernel cannot boot (the GICv3 LPI > tables being a prime example of such reserved regions). > > It turns out that there is at least two ways for reserved memory > regions to be described to kexec: /proc/iomem for the userspace > implementation, and memblock.reserved for kexec_file. And of course, > our LPI tables are only reserved using the resource tree, leading to > the aforementioned stamping. Similar things could happen with ACPI > tables as well. > > On my 24xA53 system artificially limited to 256MB of RAM (yes, it > boots with that little memory), trying to kexec a secondary kernel > failed every times. I can only presume that this was mostly tested > using kdump, which preserves the entire kernel memory range. > > This small series aims at triggering a discussion on what are the > expectations for kexec_file, and whether we should unify the two > reservation mechanisms. Bhupesh, since you've been involved with kexec file on arm64 before, please could you take a look at these patches? Thanks, Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel