Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp288958imm; Tue, 22 May 2018 19:03:44 -0700 (PDT) X-Google-Smtp-Source: AB8JxZobD3tGxYy6mizl2y7+puf/q6jR0RXMVr/IrM7QEdSdWFomWtwKTJvl7jaC1Vqg0NBNe5I2 X-Received: by 2002:a17:902:2bc5:: with SMTP id l63-v6mr877563plb.299.1527041024261; Tue, 22 May 2018 19:03:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527041024; cv=none; d=google.com; s=arc-20160816; b=W0y1ix206EcTjMclLTyR5w5NChD9uOceyAyxgtOPKRRqLcEr07tj2tjQj2jp9uHJlN 27+aylwbtGWz7O5XtHNE+7BjC/WM7BClXeblwsUxIslCHwFIxyBJZkFmN4uuEAkn7y/8 PI4eFoQzoX4deeiPVpx1wsZu327+S2OSEOnc1XtXSbrYfbNPFmaF6fzUN0SNkOzWlCBp 2be4f/YJf5R5+u2bty+00mTvvmOCtmSm0n6M9nDe6ZqFy7J+hssCg/qbWwfapdGZMMID UW3VHZFNMjH4VK8fNtmFcE4QAkhxEV8gPOLauOA4bvbjwE9wbPLAdycNWV0K04TGo45p IEBw== 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:arc-authentication-results; bh=W5EpJZrczOunbNUPUFiZPdBGlQ26jat+XD+hk6WkS0o=; b=TsLcSqJ0g0KAFWlI//MiTvL7BKx/hDiiMgw2a4nfpDRmJjDTmMZilGlfU3zLV199RC WdkU+rAkjhQ1t9BWXz67zaIndehTGjb2zd8tzLO1vAeMngYiDMvGjL6p0iIsFCO2wvCh ZFRiOKVUmKQpas2sYsDIwV3YDo2ebTAXoqtnc0JlQGTHeWET9uX0X6Au+279+ZBJh900 3pynCulhcHKJCKp/jh75FeCvPL3eS5Zs9/QcTtqSG0lWKe4XN+P2IEaf6TAjVc3lr70Z Lxb9G+Yh0IGRfEwa9QzyOYEEb28xbeboqgz7LW6FNWfDQdJWN81xhTdgrRNDyMUxdl6M QFZQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 70-v6si18564402pfu.274.2018.05.22.19.03.29; Tue, 22 May 2018 19:03:44 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753770AbeEWCCK (ORCPT + 99 others); Tue, 22 May 2018 22:02:10 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:51288 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753715AbeEWCCJ (ORCPT ); Tue, 22 May 2018 22:02:09 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6A440406E974; Wed, 23 May 2018 02:02:09 +0000 (UTC) Received: from localhost.localdomain (ovpn-12-49.pek2.redhat.com [10.72.12.49]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EBFFE2024CD1; Wed, 23 May 2018 02:02:05 +0000 (UTC) Subject: Re: [PATCH 0/2] support kdump for AMD secure memory encryption(sme) To: Tom Lendacky , linux-kernel@vger.kernel.org Cc: kexec@lists.infradead.org, dyoung@redhat.com, bhe@redhat.com References: <20180515015133.4363-1-lijiang@redhat.com> <55bda494-bee4-5696-03e5-fc21c9d6b631@amd.com> <18309611-c8c4-92cb-161e-f35ef3d243ea@redhat.com> <3972e681-d8eb-4f4d-843a-6ddbf339f0bb@amd.com> From: lijiang Message-ID: <2cabcbab-264a-2ac5-524e-6e3a9e388e56@redhat.com> Date: Wed, 23 May 2018 10:02:00 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <3972e681-d8eb-4f4d-843a-6ddbf339f0bb@amd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 23 May 2018 02:02:09 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 23 May 2018 02:02:09 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lijiang@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2018年05月21日 21:23, Tom Lendacky 写道: > On 5/20/2018 10:45 PM, lijiang wrote: >> 在 2018年05月17日 21:45, lijiang 写道: >>> 在 2018年05月15日 21:31, Tom Lendacky 写道: >>>> On 5/14/2018 8:51 PM, Lianbo Jiang wrote: >>>>> It is convenient to remap the old memory encrypted to the second kernel by >>>>> calling ioremap_encrypted(). >>>>> >>>>> When sme enabled on AMD server, we also need to support kdump. Because >>>>> the memory is encrypted in the first kernel, we will remap the old memory >>>>> encrypted to the second kernel(crash kernel), and sme is also enabled in >>>>> the second kernel, otherwise the old memory encrypted can not be decrypted. >>>>> Because simply changing the value of a C-bit on a page will not >>>>> automatically encrypt the existing contents of a page, and any data in the >>>>> page prior to the C-bit modification will become unintelligible. A page of >>>>> memory that is marked encrypted will be automatically decrypted when read >>>>> from DRAM and will be automatically encrypted when written to DRAM. >>>>> >>>>> For the kdump, it is necessary to distinguish whether the memory is >>>>> encrypted. Furthermore, we should also know which part of the memory is >>>>> encrypted or decrypted. We will appropriately remap the memory according >>>>> to the specific situation in order to tell cpu how to deal with the >>>>> data(encrypted or decrypted). For example, when sme enabled, if the old >>>>> memory is encrypted, we will remap the old memory in encrypted way, which >>>>> will automatically decrypt the old memory encrypted when we read those data >>>>> from the remapping address. >>>>> >>>>> ---------------------------------------------- >>>>> | first-kernel | second-kernel | kdump support | >>>>> | (mem_encrypt=on|off) | (yes|no) | >>>>> |--------------+---------------+---------------| >>>>> | on | on | yes | >>>>> | off | off | yes | >>>>> | on | off | no | >>>>> | off | on | no | >>>>> |______________|_______________|_______________| >>>>> >>>>> Test tools: >>>>> makedumpfile[v1.6.3]: https://github.com/LianboJ/makedumpfile >>>>> commit e1de103eca8f (A draft for kdump vmcore about AMD SME) >>>>> Author: Lianbo Jiang >>>>> Date: Mon May 14 17:02:40 2018 +0800 >>>>> Note: This patch can only dump vmcore in the case of SME enabled. >>>>> >>>>> crash-7.2.1: https://github.com/crash-utility/crash.git >>>>> commit 1e1bd9c4c1be (Fix for the "bpf" command display on Linux 4.17-rc1) >>>>> Author: Dave Anderson >>>>> Date: Fri May 11 15:54:32 2018 -0400 >>>>> >>>>> Test environment: >>>>> HP ProLiant DL385Gen10 AMD EPYC 7251 >>>>> 8-Core Processor >>>>> 32768 MB memory >>>>> 600 GB disk space >>>>> >>>>> Linux 4.17-rc4: >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>>>> commit 75bc37fefc44 ("Linux 4.17-rc4") >>>>> Author: Linus Torvalds >>>>> Date: Sun May 6 16:57:38 2018 -1000 >>>>> >>>>> Reference: >>>>> AMD64 Architecture Programmer's Manual >>>>> https://support.amd.com/TechDocs/24593.pdf >>>>> >>>> >>>> Have you also tested this with SEV? It would be nice if the kdump >>>> changes you make work with both SME and SEV. >>>> >>> Thank you, Tom. >>> This is a great question, we originally plan to implement SEV in subsequent patches, and >>> we are also working on SEV at present. >>> Furthermore, we have another known issue that the system can't jump into the second kernel >>> when SME is enabled and kaslr is disabled in kdump mode. It seems that is a complex problems, >>> maybe it is related to kaslr and SME, currently, i'm not sure the root cause, but we will >>> also plan to fix it. Can you give me any advice about this issue? >>> >> Based on upstream 4.17-rc5, we have recently found a new issue that the system can't boot to >> use kexec when SME is enabled and kaslr is disabled. Have you ever run into this issue? >> They have similar reproduction scenarios. >> >> CC Tom & Baoquan > > I haven't encountered this issue. Can you send the kernel config that you > are using? And your kernel command line? I'll try your config and see if > I can reproduce the issue. > Thank you, Tom. It doesn't have anything special config, and it's always reproduced. I will send another email to you about kernel config and command line. > Just to be clarify, you perform a power-on boot with SME enabled and KASLR > disabled (e.g. mem_encrypt=on nokaslr), correct, and that won't boot? > The system can boot in this case. Thanks. Lianbo > Thanks, > Tom > >> >> Thanks. >> Lianbo >> >>> Thanks. >>> Lianbo >>>> Thanks, >>>> Tom >>>> >>>>> Lianbo Jiang (2): >>>>> add a function(ioremap_encrypted) for kdump when AMD sme enabled. >>>>> support kdump when AMD secure memory encryption is active >>>>> >>>>> arch/x86/include/asm/dmi.h | 14 +++++++++++++- >>>>> arch/x86/include/asm/io.h | 2 ++ >>>>> arch/x86/kernel/acpi/boot.c | 8 ++++++++ >>>>> arch/x86/kernel/crash_dump_64.c | 27 +++++++++++++++++++++++++++ >>>>> arch/x86/mm/ioremap.c | 25 +++++++++++++++++-------- >>>>> drivers/acpi/tables.c | 14 +++++++++++++- >>>>> drivers/iommu/amd_iommu_init.c | 9 ++++++++- >>>>> fs/proc/vmcore.c | 36 +++++++++++++++++++++++++++++++----- >>>>> include/linux/crash_dump.h | 4 ++++ >>>>> kernel/kexec_core.c | 12 ++++++++++++ >>>>> 10 files changed, 135 insertions(+), 16 deletions(-) >>>>>