Received: by 2002:a19:f614:0:0:0:0:0 with SMTP id x20csp68419lfe; Fri, 15 Apr 2022 19:56:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxS+vCTDS+VuhhPkaiT3qEQwLFZLHbOAIxpIQWF3ZU+mblVALFLxWcllh0fx20w2NFuYelu X-Received: by 2002:a17:90a:eb0e:b0:1cb:7d07:52f6 with SMTP id j14-20020a17090aeb0e00b001cb7d0752f6mr7335460pjz.66.1650077783314; Fri, 15 Apr 2022 19:56:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650077783; cv=none; d=google.com; s=arc-20160816; b=i4nLjo27pXkdgGpVDBfEhHQEy8O3c8iJ5H5ArBLPr+VYJvbLBU6IGne4JbYa2BHoyB 4btgXPwj0F+uXg3PyYl6e5A6rdv640IxGjb8uS82zdrLd8X8dcrIzDFJUyiTeDypg1UX Q9Gz+Dk7IrLixBiGdbfLIvUFgmn4wAdfjDzHGjeUXScYxsgju4Gjw+9rHGanZyzn9N/H rsYeGaMdGzcfyZVRY6OXRlxI0iemq56SX0UBTnkfBS8WGMwDFZhnmOyBIf8jd1gMWC3D H5S+0QiFSGLOgouxE2G5Y4dnBMmS5Zmidi2qzYvofsubLUeSeQLhUaRkQHV+u27kVu8w u6EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=PQHgfwwKPq86Db3iuUuH7izspMPTgHPzv+9wokpiVxk=; b=m+/tfBXBs/N4oPIXBabmhBCMrxg6r2CKoSMlSRjClmDwEZdJv/DOZ9DhZLSOm1ncep UQO+2isuS0zj44nZQ0K+GcuM6N2yuO5sJ+5D3GkX8UohrQPXjUQFqp5qRRf5pLUpP1hi UYCEPjzO25d9UP7OTMu4GvzGCXcWCkdPvaL32FMnZwRIH11ezaKK3pXjWql5RtmMCjFo YVg6/lYhW401ErJYVRXLb3AC38bfnIgwvdbeZZqoyAT+HN3+AS2TC1C5UFF39SE5xjxH zuIw2sz24fPu+APECROnTL190m8RmL/OKxgLpV37zIWj37RF2rbctX0oQ7r+B3Hvp9c6 EX4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id 132-20020a63048a000000b0039e2daa40d5si2896405pge.527.2022.04.15.19.56.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 19:56:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 152474A92E; Fri, 15 Apr 2022 19:17:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229458AbiDPCT1 (ORCPT + 99 others); Fri, 15 Apr 2022 22:19:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229454AbiDPCTA (ORCPT ); Fri, 15 Apr 2022 22:19:00 -0400 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A45A93C72F; Fri, 15 Apr 2022 19:16:24 -0700 (PDT) Received: from dggpemm500021.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4KgFtl21SZzCr3Z; Sat, 16 Apr 2022 09:27:43 +0800 (CST) Received: from dggpemm500014.china.huawei.com (7.185.36.153) by dggpemm500021.china.huawei.com (7.185.36.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 16 Apr 2022 09:32:04 +0800 Received: from [10.174.178.120] (10.174.178.120) by dggpemm500014.china.huawei.com (7.185.36.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 16 Apr 2022 09:32:02 +0800 Message-ID: <6de859df-e1c3-e9aa-4530-3b61b9c69a28@huawei.com> Date: Sat, 16 Apr 2022 09:32:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v2 0/9] introduce mirrored memory support for arm64 To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <20220414101314.1250667-1-mawupeng1@huawei.com> From: mawupeng In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.120] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500014.china.huawei.com (7.185.36.153) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2022/4/14 18:22, Ard Biesheuvel 写道: > On Thu, 14 Apr 2022 at 11:54, Wupeng Ma wrote: >> >> From: Ma Wupeng >> >> Commit b05b9f5f9dcf ("x86, mirror: x86 enabling - find mirrored memory ranges") >> introduced mirrored memory support for x86. This support rely on UEFI to >> report mirrored memory address ranges. See UEFI 2.5 spec pages 157-158: >> >> http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf >> >> Memory mirroring is a technique used to separate memory into two separate >> channels, usually on a memory device, like a server. In memory mirroring, >> one channel is copied to another to create redundancy. This method makes >> input/output (I/O) registers and memory appear with more than one address >> range because the same physical byte is accessible at more than one >> address. Using memory mirroring, higher memory reliability and a higher >> level of memory consolidation are possible. >> >> Arm64 can support this too. So mirrored memory support is added to support >> arm64. >> >> Efi_fake_mem is used for testing mirrored features and will not be used in >> production environment. This test features can fake memory's attribute >> values. >> >> The reason why efi_fake_mem support is put first is that memory's attribute >> is reported by BIOS which is hard to simulate. With this support, any arm64 >> machines with efi support can easily test mirrored features. >> >> The main purpose of this patchset is to introduce mirrored support for >> arm64 and we have already fixed the problems we had which is shown in >> patch #5 to patch #7 and try to bring total isolation in patch #8 which >> will disable mirror feature if kernelcore is not specified. >> >> In order to test this support in arm64: >> - patch this patchset >> - add efi_fake_mem=8G@0:0x10000 in kernel parameter to simulate mirrored >> memroy between phy addr 0-8G. >> - add kernelcore=mirror in kernel parameter >> - start you kernel >> > > As I explained before: > > - NAK to EFI fake_mem support on arm64 fake_mem support on arm64 will be removed in subsequent version. > - NAK to the whole series until you come up with a proposal on how to > locate the static kernel image itself into more reliable memory, as > there is really no point to any of this otherwise. Sorry I am not familiar with this, as you metioned before, > you have to iterate over the memory map and look for regions with > the desired attribute, and allocate those pages explicitly. Do you mean this is x86, commit c05cd79750fb ("x86/boot/KASLR: Prefer mirrored memory regions for the kernel physical address"). I will do some research. > I'd prefer to implement this in the bootloader, and only add minimal > logic to the stub to respect the placement of the kernel by the loader > if the loader signals it to do so. Does this bootloader refer to grub and then add minimal logic to arm64-stub.c? What is the loader signal? System exists mirrored memory reported by uefi? Thanks for reviewing, sorry for my ignorance on this. > .