Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9399825ybi; Wed, 10 Jul 2019 09:36:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqyoxymKycdQ3q8iI7Zr+r39jYaNlBMRw4xA49F4jUCwRL6JdkFuNX6NCT3a2B1eWZ3VjTt/ X-Received: by 2002:a17:90a:4803:: with SMTP id a3mr8193024pjh.58.1562776599403; Wed, 10 Jul 2019 09:36:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562776599; cv=none; d=google.com; s=arc-20160816; b=TbUq1QznsRPiZOBIMQAWnDnBHtscMtw4UuxsYrkQwjaRCXrkNstnkImgh4TqlRESPT WU94iXhVgDUo1DBZURvx4OdO47TMuHLTnUBDZRVz7dbO8UKPigBbC1oGqdlvkk2iQ4Br ciFNmIGn2l6Wjos0a+Uaov6ApAjLr9tPlYSMu5VjzrE/MaaTZekXOup+MrzfK6M081IG NG0PIJdTJYskle4ncWzZxS6GEcRo4A3ER1kx6BDxhbd9u9MDKuDi3jF8vmDZDZzwvaMH uk3nE4IhhSVFnw2hYFm1M9ie/zZ2SJztWQb0akWJGDtJ74O8QisZboE/0JS0bBItOxpx nvqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=SE9Vxq9JsyyCtEQXLxEilGHVjL/mEwj53ZCNAymixzQ=; b=I3ZBr/rWEVR1DjAdGrh5s6IsmkBdC3DbmA80wjUQMonLMucwyJp6w0k7OJyn7J3xBE jO9auUrbniVg40Sa2IanlLpj11BdX6gvlKsd1E7pqbZ6eUlkp1FhIypyi5BKQdZnMfiI t984+b6g4J52UTBtJxStszrDJJyTghWcdyuTxjlVwamCOzfrmU2OU4kJEpkfAyEbRrqP +TYkmPRq7CYq8aLq5RdDCggKkl7VQrjwP8YmYkNbv6qPr6x9v8kDx0hHnyWuyuJR9iGC XLV2vCJGQDcF98L83pdKlGwBEzXPTscuQMzpqPSEjmyUDX8CcMrE9z2HIgTrNsKxdt/u 0dkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s33si2614395pgk.112.2019.07.10.09.36.23; Wed, 10 Jul 2019 09:36:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727884AbfGJPTM (ORCPT + 99 others); Wed, 10 Jul 2019 11:19:12 -0400 Received: from foss.arm.com ([217.140.110.172]:35200 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726080AbfGJPTM (ORCPT ); Wed, 10 Jul 2019 11:19:12 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9CE0F2B; Wed, 10 Jul 2019 08:19:11 -0700 (PDT) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 078203F246; Wed, 10 Jul 2019 08:19:08 -0700 (PDT) Subject: Re: [v1 0/5] allow to reserve memory for normal kexec kernel To: Pavel Tatashin Cc: Bhupesh Sharma , James Morris , Sasha Levin , Eric Biederman , kexec mailing list , Linux Kernel Mailing List , Jonathan Corbet , Catalin Marinas , will@kernel.org, Linux Doc Mailing List , linux-arm-kernel References: <20190708211528.12392-1-pasha.tatashin@soleen.com> <2d60f302-5161-638a-76cd-d7d79e5631fe@arm.com> From: James Morse Message-ID: Date: Wed, 10 Jul 2019 16:19:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pasha, On 09/07/2019 14:07, Pavel Tatashin wrote: >>> Enabling MMU and D-Cache for relocation would essentially require the >>> same changes in kernel. Could you please share exactly why these were >>> not accepted upstream into kexec-tools? >> >> Because '--no-checks' is a much simpler alternative. >> >> More of the discussion: >> https://lore.kernel.org/linux-arm-kernel/5599813d-f83c-d154-287a-c131c48292ca@arm.com/ >> >> While you can make purgatory a fully-fledged operating system, it doesn't really need to >> do anything on arm64. Errata-workarounds alone are a reason not do start down this path. > > Thank you James. I will summaries the information gathered from the > yesterday's/today's discussion and add it to the cover letter together > with ARM64 tag. I think, the patch series makes sense for ARM64 only, > unless there are other platforms that disable caching/MMU during > relocation. I'd prefer not to reserve additional memory for regular kexec just to avoid the relocation. If the kernel's relocation work is so painful we can investigate doing it while the MMU is enabled. If you can compare regular-kexec with kexec_file_load() you eliminate the purgatory part of the work. Thanks, James