Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9359878ybi; Wed, 10 Jul 2019 08:58:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqyOHE4F9vz2tP7SyCvafABTAahdCzKE+cKFSCwMFLHmpSsH1wCNLbptmHZWPD5B/vZMm5Gf X-Received: by 2002:a17:90a:a404:: with SMTP id y4mr8141121pjp.58.1562774308776; Wed, 10 Jul 2019 08:58:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562774308; cv=none; d=google.com; s=arc-20160816; b=TalQiS+ndbSOmENU9qvS0b4xPQFKDlMp+A7QoczVRnAHyOjIMz1yRJRdlsLwmPXZs0 bCGSEqRHpiotzfNHYwq7GU4vF4+cZljoArYit3DvxlPpOrmkZlgHZm/yOvktVaiDYgQo K1rVMlwImmnKMh0OWFVmyzuLiqegNlOQcBU4lU6XAg8enfoZgcOVcw98ZkKkHVVEOYN3 7fhaNdTuB26HJsAFvCt6dI6piDPiLT2bhruyycKKneM4p170GEKQUadkjQuoqI8A49uO /qUIihkfPIRvpqgYKmO11YCIKf4gVeDYP9B+HUBt3jNmyZZje50cqhw8qv2gilAjaB7l lRxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=CZgPHxQSyDYYtNmHA3/wZ3DRhIFFkShs7w2jP3T5tpc=; b=p6VvZ2PtTpqTwJ2Q8TGkGKIZnRq/5jMzken5jsl8XZNPuC9LSPUMIpL3/75pOKrUe6 oax+RPs9AhSL/b08xcP6sCkw3RXFib9pZSEnQpKYa9/fjbxYJzVfy/8aFR9GjoZtpJ4s 5m+3iQJPTTLv1de+Ywg0x9xp3xwuZOkX8cDENnRx4nUhBtJxih2bJBmKoijJdP5sGQcL 2lrodaPTR4tFycICKlZHvvHTMO4ikcdlH4bgRWt65nVxZY2jSj5hVEMhjHKzGe1xQdra 2j/f1+ogDMPrzIhuzMTFg2iK5fJFVUWxELNyEi843OtbGfoyzzVcuVMSgaN1JEbSuR9B EF3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@soleen.com header.s=google header.b="LEi6/Pje"; 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 l7si2399787pgp.318.2019.07.10.08.58.12; Wed, 10 Jul 2019 08:58:28 -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; dkim=pass header.i=@soleen.com header.s=google header.b="LEi6/Pje"; 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 S1727966AbfGJP5C (ORCPT + 99 others); Wed, 10 Jul 2019 11:57:02 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:33112 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727263AbfGJP5C (ORCPT ); Wed, 10 Jul 2019 11:57:02 -0400 Received: by mail-ed1-f66.google.com with SMTP id i11so2694276edq.0 for ; Wed, 10 Jul 2019 08:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CZgPHxQSyDYYtNmHA3/wZ3DRhIFFkShs7w2jP3T5tpc=; b=LEi6/PjejGkEIcti1eTkHdTyR2J5jxYV6psjYv6r+R4rq9PfMgiJvyz3sGPckQrQjf lbugIKfybDu0Y7zKpFpaEvuHTT2l8vGEYy0HOBao0Cd4zR061ANMYJt6m/w7HHj6E1tb ocYgs+QcC8JNjAUstT+ETcrq/OJtYTOLtc1b+S24v+b0gwp3Hyivo1pqM/mbRS6+5jdh WnlzF7qZHETDtcyr28wnUTIMG2EIZHypwQqXV3z2p5ZjOi9Gv2nhDxwzoWBiIcs2kcrW xTtxPMaM5lL20VjS6uVfPnp7Rlbf/WgAjHAi1S0bhstA9g1OCdvgp9kI3SWayKUOO6zT WtmA== 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:cc; bh=CZgPHxQSyDYYtNmHA3/wZ3DRhIFFkShs7w2jP3T5tpc=; b=Q+dBTnH8DqBK/chR23EIq6jUQwTTPOuRccMbr00C35yN3cQx9I0B6+Pa7wXXOg7e75 lq7P1/bk28dHwwFju6/vEpcNhtN0MwoJFwsU29zRfnf96aJVpIYXrBxoJ26K1Cbv/ztq veTusLQvE4olWCLg/NkUMtprCRZUkmc+Wa5UvIQ+Gr2UgSZ6MR+Iz6VifKGi/g+Gtg+s QYo1YOuY4dmmlJp84/kdu8Wxf+s0Uj7cFblsVEMPMdGA6uzyGytaoArILQHnrvi+BRQ7 RnC9B1khY0VYoDcoZ4Imwy9o68WSLndQaGODXXkVj8P4CPuRM5ioL7OHSfejjdunPEoX Kk+g== X-Gm-Message-State: APjAAAXbCnOSI0YL7jZiFSW5GhP5vJwF9tL1hbD/0SdfSHas9RYuQ6vD 1YJp7XxqZuhhoW17IG0V6YhbYMA5VFJ5s/ybZ67zeA== X-Received: by 2002:a50:a4ef:: with SMTP id x44mr32799017edb.304.1562774220761; Wed, 10 Jul 2019 08:57:00 -0700 (PDT) MIME-Version: 1.0 References: <20190708211528.12392-1-pasha.tatashin@soleen.com> <2d60f302-5161-638a-76cd-d7d79e5631fe@arm.com> In-Reply-To: From: Pavel Tatashin Date: Wed, 10 Jul 2019 11:56:50 -0400 Message-ID: Subject: Re: [v1 0/5] allow to reserve memory for normal kexec kernel To: James Morse 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 10, 2019 at 11:19 AM James Morse wrote: > > 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. Relocation time is exactly the same for regular-kexec and kexec_file_load(). So, the relocation is indeed painful for our case. I am working on adding MMU enabled kernel relocation. Pasha