Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp240377ybl; Wed, 4 Dec 2019 01:52:09 -0800 (PST) X-Google-Smtp-Source: APXvYqxmAKN2KUMnxUmkoXcltfmapy5fe7JymWtaDisPw3Q+IB3xe8ZqYMwgPeNZGVzBlKKRpwWT X-Received: by 2002:aca:4587:: with SMTP id s129mr1750999oia.124.1575453128890; Wed, 04 Dec 2019 01:52:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575453128; cv=none; d=google.com; s=arc-20160816; b=MlzA2YP3kChmhkY0sRJV2se60dUTtHhGTQYEAWexm4zKp00T9BUpOTNX/G7ufp40ty tLWXv2o1K16i8LVVb9DlEMyPJfN0HGcK9dMhzo5Vdtjcqon+KKqt0m3WVg4Xce4LG8QE ZmGTLMveVbkOC04Ewa5u07xVNUNWfTahA0uXSe11W8pX4XZhfs4La9XbAeoNMSVX3/vf iuWDR98ATynSocirgmz3IALEpFmlKRtx89TpMMG7Z2qF1ADoV3XkjaseDvhggPaOtNPS HyvXi247H/XLZssh1ar8zNcb12D/lev2DogwRPgzmIqry10vH9h6E3ONlW/i7iZ+4HsJ rbZw== 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=U+MqMdaqYA9wxrEDifn792XFhLysGc8RSGDMrug+w3U=; b=g3k8qgiVhD8LQSNtxchaZHbqXN1jfrtuhyFdnM76Tq9Szdx3oZ+WughOkHMQKh2u7g ImaZFPrz/U8ISKDyC8l+2Bxky8Ewkk+wb3e+M3FycDHNgUTPHMknFYukDIky4HlWqFke hPfK0K+D3r3xvusr0jqQPraleNg6vJ31Swhbzs3msAbCY1piUSE+kXa6uWLvN4DtMI8N txayzeFsifbhIjlyBfmYm7IFbusA6AO8iJzr0eEZVY9kgHQIXj8YNj87Dny20Md/M6rR GgS/RUVVXdei47FPYB2mTgYE4nsg4DOMsVYC3vcvx5uo1hf4L6ys8r2MeQrgzxuYOjeN 376A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Przb2Mp6; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 89si2803180otn.277.2019.12.04.01.51.55; Wed, 04 Dec 2019 01:52:08 -0800 (PST) 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=@linaro.org header.s=google header.b=Przb2Mp6; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727412AbfLDJvT (ORCPT + 99 others); Wed, 4 Dec 2019 04:51:19 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:36763 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727158AbfLDJvT (ORCPT ); Wed, 4 Dec 2019 04:51:19 -0500 Received: by mail-wm1-f65.google.com with SMTP id p17so7107121wma.1 for ; Wed, 04 Dec 2019 01:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U+MqMdaqYA9wxrEDifn792XFhLysGc8RSGDMrug+w3U=; b=Przb2Mp6fXtj52PQek5CbvK0m72zcxvl/tkEZHPbnWSa++nCWSJZZmS9++pPkRXrHG BmP235WX29P6BS93AZhlst2RD7hH2WoH2RVk3T/9HoyC4AgEsDCHcd1EHI0AlYUuXjJe dI3x/0u7OgFjrMrvJ6WcKeOUmYgR0U1yn16Yy5SlGY6ZJDeX94v6WUG23ht7i1IPjrMw okf5mTcha9+T7jwil9n90t9RCeixq59sYXp9pI34nZ9pevxFrWCHHd0Suk3OvMD0bdvY NyMXQL9g/QB8vKBbvg2D257IjR/amd+XQRUdX4R+nQbtGGP3uveM6gu9gV1MrkTo+DW+ pA8A== 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=U+MqMdaqYA9wxrEDifn792XFhLysGc8RSGDMrug+w3U=; b=SrfzotT6rQ+GHDcTINGna8xGeqRakB9LXWuv5vgIaMLlqBojvCV4Nf9Gtwt5zzrWQk WvMqpl6gIqGQW3RMZQThkN8qCUSw7fENj4VL4Rqnz4YysxzQYFfNZH2FWQzIs8ULhMKx jnTeJw5+UPJstWm7EbqdFolZTJv3K3Y/Qlf0DEXOFtMpRGgxq8NaJe5nTq5wury620hO qgZ5wzEiFOSFFvVJ8YhCE5R27Mj5aINqTNA55FlMWkqUV4fYInYzJPl2c5dJM8V8ciCm q5vB8+ya4NERfcHE/8N/mVAzPArB9SrY7Ihv/5vt5EXchEhJTP6uNvF+NAT/OoleNkMp +s5Q== X-Gm-Message-State: APjAAAVif3FqnYcdV9cMHXymiwIL3slBu3yF9jMQ/aDHli9UmUZ0vphk IimkabQb2P7sb8lC2UgzdXTgMELH1lI9LlhNSystwQ== X-Received: by 2002:a05:600c:141:: with SMTP id w1mr18577201wmm.61.1575453077074; Wed, 04 Dec 2019 01:51:17 -0800 (PST) MIME-Version: 1.0 References: <20191203201410.28045-1-msys.mizuma@gmail.com> In-Reply-To: <20191203201410.28045-1-msys.mizuma@gmail.com> From: Ard Biesheuvel Date: Wed, 4 Dec 2019 09:51:13 +0000 Message-ID: Subject: Re: [PATCH v2 0/2] efi: arm64: Introduce /proc/efi/memreserve to tell the persistent pages To: Masayoshi Mizuma , James Morse Cc: linux-arm-kernel , linux-efi , Masayoshi Mizuma , Linux Kernel Mailing List , Kexec Mailing List , d.hatayama@fujitsu.com, Eric Biederman , Matthias Brugger 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 Tue, 3 Dec 2019 at 20:14, Masayoshi Mizuma wrote: > > From: Masayoshi Mizuma > > kexec reboot sometime fails in early boot sequence on aarch64 machine. > That is because kexec overwrites the LPI property tables and pending > tables with the initrd. > > To avoid the overwrite, introduce /proc/efi/memreserve to tell the > tables region to kexec so that kexec can avoid the memory region to > locate initrd. > > kexec also needs a patch to handle /proc/efi/memreserve. I'm preparing > the patch for kexec. > > Changelog > v2: - Change memreserve file location from sysfs to procfs. > memreserve may exceed the PAGE_SIZE in case efi_memreserve_root > has a lot of entries. So we cannot use sysfs_kf_seq_show(). > Use seq_printf() in procfs instead. > > Masayoshi Mizuma (2): > efi: add /proc/efi directory > efi: arm64: Introduce /proc/efi/memreserve to tell the persistent > pages > Apologies for the tardy response. Adding /proc/efi is really out of the question. *If* we add any special files to expose this information, it should be under sysfs. However, this is still only a partial solution, since it only solves the problem for userspace based kexec, and we need something for kexec_file_load() as well. The fundamental issue here is that /proc/iomem apparently lacks the entries that describe these regions as 'reserved', so we should try to address that instead.