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=0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, 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 2F9C6C35640 for ; Fri, 21 Feb 2020 07:01:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CB68220656 for ; Fri, 21 Feb 2020 07:01:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB68220656 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 30F736B0003; Fri, 21 Feb 2020 02:01:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C0986B0006; Fri, 21 Feb 2020 02:01:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D56D6B0007; Fri, 21 Feb 2020 02:01:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id 0757A6B0003 for ; Fri, 21 Feb 2020 02:01:49 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9CEE92DFC for ; Fri, 21 Feb 2020 07:01:48 +0000 (UTC) X-FDA: 76513239096.18.ink15_49e86696dcb40 X-HE-Tag: ink15_49e86696dcb40 X-Filterd-Recvd-Size: 7643 Received: from huawei.com (szxga06-in.huawei.com [45.249.212.32]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Feb 2020 07:01:47 +0000 (UTC) Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id DDEFAA8682FB5D642CB7; Fri, 21 Feb 2020 15:01:39 +0800 (CST) Received: from [10.173.220.79] (10.173.220.79) by smtp.huawei.com (10.3.19.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 21 Feb 2020 15:01:30 +0800 Subject: Re: [PATCH 0/2] arm64: Support to find mirrored memory ranges To: Ard Biesheuvel References: <1582289580-24045-1-git-send-email-jingxiangfeng@huawei.com> CC: Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , Darren Hart , Andy Shevchenko , linux-efi , Linux Kernel Mailing List , , Linux-MM , "Kefeng Wang" From: j00447129 Message-ID: <5E4F8049.9020805@huawei.com> Date: Fri, 21 Feb 2020 15:01:29 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010502020101020408080501" X-Originating-IP: [10.173.220.79] X-CFilter-Loop: Reflected X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --------------010502020101020408080501 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 2020/2/20 17:21, Ard Biesheuvel wrote: > On Thu, 20 Feb 2020 at 04:43, Jing Xiangfeng wrote: >> This series enable finding mirrored memory ranges >> functionality on arm64 platform. This feature has been >> implemented on the x86 platform, so we move some >> functions from x86. >> > Hello Jing Xiangfeng, > > Could you explain your use case a bit better? Usually, the firmware is > a better place to make modifications to the EFI memory map. > > The reason I am asking is that currently, on ARM and arm64, we never > make *any* changes to the firmware provided tables (EFI system table, > EFI memory map, DT/ACPI/SMBIOS tables etc), in order to ensure that > kexec is idempotent, i.e., it will always see the exact same state as > far as the firmware is concerned. This is a bit different from x86, > where the memory map is already modified for various other reasons, so > using it for fake memory regions is not such a big deal. I am not familiar with the firmware specifications. If we want to support this functionality now, does it mean that the UEFI spec needs to be modified? kexec related functions also need to be verified under synchronization, right? > > Do you see a use case for this in production? I'm debugging it by fake memory regions. Our server is expected to support it. Thanks for your comments > >> Jing Xiangfeng (2): >> efi: allow EFI_FAKE_MEMMAP on arm64 platform >> arm64/efi: support to find mirrored memory ranges >> >> arch/x86/include/asm/efi.h | 5 ----- >> arch/x86/platform/efi/efi.c | 39 --------------------------------------- >> drivers/firmware/efi/Kconfig | 2 +- >> drivers/firmware/efi/arm-init.c | 2 ++ >> drivers/firmware/efi/efi.c | 23 +++++++++++++++++++++++ >> drivers/firmware/efi/memmap.c | 16 ++++++++++++++++ >> include/linux/efi.h | 5 +++++ >> 7 files changed, 47 insertions(+), 45 deletions(-) >> >> -- >> 1.8.3.1 >> > . > --------------010502020101020408080501 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

On 2020/2/20 17:21, Ard Biesheuvel wrote:
On Thu, 20 Feb 2020 at 04:43, Jing Xiangfeng <=
jingxiangfeng@huawei.com> wrote:

This series enable finding mirrored memory ranges
functionality on arm64 platform. This feature has been
implemented on the x86 platform, so we move some
functions from x86.


Hello Jing Xiangfeng,

Could you explain your use case a bit better? Usually, the firmware is
a better place to make modifications to the EFI memory map.

The reason I am asking is that currently, on ARM and arm64, we never
make *any* changes to the firmware provided tables (EFI system table,
EFI memory map, DT/ACPI/SMBIOS tables etc), in order to ensure that
kexec is idempotent, i.e., it will always see the exact same state as
far as the firmware is concerned. This is a bit different from x86,
where the memory map is already modified for various other reasons, so
using it for fake memory regions is not such a big deal.
=C2=A0=C2=A0=C2=A0 I am not familiar with the firmware specifications= . If we want to support
=C2=A0=C2=A0=C2=A0 this functionality now, does it mean that the UEFI= spec needs to be modified?
=C2=A0=C2=A0=C2=A0 kexec related functions also need to be verified u= nder synchronization, right?

Do you see a use case for this in production?
=C2=A0=C2=A0=C2=A0 I'm debugging it by fake memory regions.=C2=A0 Our= server is expected to support it.

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Thanks for your comments


Jing Xiangfeng (2):
  efi: allow EFI_FAKE_MEMMAP on arm64 platform
  arm64/efi: support to find mirrored memory ranges

 arch/x86/include/asm/efi.h      |  5 -----
 arch/x86/platform/efi/efi.c     | 39 -----------------------------------=
----
 drivers/firmware/efi/Kconfig    |  2 +-
 drivers/firmware/efi/arm-init.c |  2 ++
 drivers/firmware/efi/efi.c      | 23 +++++++++++++++++++++++
 drivers/firmware/efi/memmap.c   | 16 ++++++++++++++++
 include/linux/efi.h             |  5 +++++
 7 files changed, 47 insertions(+), 45 deletions(-)

--
1.8.3.1


.

--------------010502020101020408080501--