Received: by 2002:ac0:950e:0:0:0:0:0 with SMTP id f14csp276579imc; Sat, 16 Mar 2019 00:32:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqwEOT6ioTk1mVq73C3dM9zyz9abMuythx84jLG8Gbu9UWAYbabXSZJJdlDMUnEdkziWcWwI X-Received: by 2002:a62:5959:: with SMTP id n86mr8129300pfb.237.1552721552944; Sat, 16 Mar 2019 00:32:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552721552; cv=none; d=google.com; s=arc-20160816; b=OLP0EDqf577BihOz/fRfLp3d82BKK1I4n5b66amScrAZ5PXL88/GLZ+jxeLnJ0dH23 TWkR1b4wMqV18eFmBwem+hoCSQzyMJjgTkzDP3SsCrREvK/L/s0ZaUPnyerijqlLnvQS +2ftP9PiyXRImIraGKugXA1DQpHfI0CQgOu44aOHP1J/QBlpM9m7KT4DX/4JJCgccjMI RPwGs7PpId2F9JWCCPNnzd33M7QMNZPgFmXj8sP5Zy8+22SPIP7zrOPX3VqUt+fyFdQL pvqAzaWfzUfn47DsKMac8L6dFChUbYFYgXlmDEiSgZpsCIRv7hE+pJ6KilzgFjwCOcU+ Smwg== 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; bh=IQ5F4chfBFnyph4Kqqghg3qyKmpt6nc/T1NO47o2c5E=; b=saCfXurm8et7fnu6I9pbGhHbLvpspxgNbxo+Z+Bni+AJ0IyCindIWadr3ZWbMuGbWN Krpjr4yV+Ir2JAHinqUF7ZmKS50mBFMybqBbuxk4hrtojBAsqGZdUtLK4nAVfz4ayICI 9+T+e5Tjow9ARSft1YgN8/QapLpA2QXOLsDuB72kzzZu/B9/Dh0zcfiKr1BWJ8ETg+NZ BKyfsjTcCT92YSrlvfydDNIH1gB6XN0dU8TiVxVfQc+XxlmwJDT8j/+Yq+j8S1MbuGQN 7CiLvaMNqHBbyI3HbpxXRhYbvXh5ifKXY9pWT6NHvoLdC/CtnwnteEmbA+cRPygtcwf1 ecwA== 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 n23si3712641plp.182.2019.03.16.00.32.15; Sat, 16 Mar 2019 00:32:32 -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 S1726360AbfCPHbW (ORCPT + 99 others); Sat, 16 Mar 2019 03:31:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59212 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725970AbfCPHbV (ORCPT ); Sat, 16 Mar 2019 03:31:21 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 852113082E0F; Sat, 16 Mar 2019 07:31:20 +0000 (UTC) Received: from localhost.localdomain (ovpn-12-223.pek2.redhat.com [10.72.12.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3631C60BE6; Sat, 16 Mar 2019 07:31:04 +0000 (UTC) Subject: Re: [PATCH 1/2 v8] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED' To: "Lendacky, Thomas" Cc: Dave Young , "linux-kernel@vger.kernel.org" , "kexec@lists.infradead.org" , "x86@kernel.org" , "linux-ia64@vger.kernel.org" , "linux-efi@vger.kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "akpm@linux-foundation.org" , "dave.hansen@linux.intel.com" , "luto@kernel.org" , "peterz@infradead.org" , "ard.biesheuvel@linaro.org" , "tony.luck@intel.com" , "fenghua.yu@intel.com" , "bhe@redhat.com" , Toshi Kani , Dan Williams References: <20181129080956.20776-1-lijiang@redhat.com> <20181129080956.20776-2-lijiang@redhat.com> <20181130033703.GA23624@dhcp-128-65.nay.redhat.com> From: lijiang Message-ID: <95661569-d9c9-af13-11c4-c0d752710a1f@redhat.com> Date: Sat, 16 Mar 2019 15:31:00 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Sat, 16 Mar 2019 07:31:20 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2018年12月05日 05:33, Lendacky, Thomas 写道: > On 11/29/2018 09:37 PM, Dave Young wrote: >> + more people >> >> On 11/29/18 at 04:09pm, Lianbo Jiang wrote: >>> When doing kexec_file_load, the first kernel needs to pass the e820 >>> reserved ranges to the second kernel. But kernel can not exactly >>> match the e820 reserved ranges when walking through the iomem resources >>> with the descriptor 'IORES_DESC_NONE', because several e820 types( >>> e.g. E820_TYPE_RESERVED_KERN/E820_TYPE_RAM/E820_TYPE_UNUSABLE/E820 >>> _TYPE_RESERVED) are converted to the descriptor 'IORES_DESC_NONE'. It >>> may pass these four types to the kdump kernel, that is not desired result. >>> >>> So, this patch adds a new I/O resource descriptor 'IORES_DESC_RESERVED' >>> for the iomem resources search interfaces. It is helpful to exactly >>> match the reserved resource ranges when walking through iomem resources. >>> >>> In addition, since the new descriptor 'IORES_DESC_RESERVED' is introduced, >>> these code originally related to the descriptor 'IORES_DESC_NONE' need to >>> be updated. Otherwise, it will be easily confused and also cause some >>> errors. Because the 'E820_TYPE_RESERVED' type is converted to the new >>> descriptor 'IORES_DESC_RESERVED' instead of 'IORES_DESC_NONE', it has been >>> changed. >>> >>> Suggested-by: Dave Young >>> Signed-off-by: Lianbo Jiang >>> --- >>> arch/ia64/kernel/efi.c | 4 ++++ >>> arch/x86/kernel/e820.c | 2 +- >>> arch/x86/mm/ioremap.c | 13 ++++++++++++- >>> include/linux/ioport.h | 1 + >>> kernel/resource.c | 6 +++--- >>> 5 files changed, 21 insertions(+), 5 deletions(-) >>> >>> diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c >>> index 8f106638913c..1841e9b4db30 100644 >>> --- a/arch/ia64/kernel/efi.c >>> +++ b/arch/ia64/kernel/efi.c >>> @@ -1231,6 +1231,10 @@ efi_initialize_iomem_resources(struct resource *code_resource, >>> break; >>> >>> case EFI_RESERVED_TYPE: >>> + name = "reserved"; >> >> Ingo updated X86 code to use "Reserved", I think it would be good to do >> same for this case as well >> >>> + desc = IORES_DESC_RESERVED; >>> + break; >>> + >>> case EFI_RUNTIME_SERVICES_CODE: >>> case EFI_RUNTIME_SERVICES_DATA: >>> case EFI_ACPI_RECLAIM_MEMORY: >> >> Originally, above 3 are all "reserved", so probably they all should be >> IORES_DESC_RESERVED. >> >> Can any IA64 people to review this? >> >>> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c >>> index 50895c2f937d..57fafdafb860 100644 >>> --- a/arch/x86/kernel/e820.c >>> +++ b/arch/x86/kernel/e820.c >>> @@ -1048,10 +1048,10 @@ static unsigned long __init e820_type_to_iores_desc(struct e820_entry *entry) >>> case E820_TYPE_NVS: return IORES_DESC_ACPI_NV_STORAGE; >>> case E820_TYPE_PMEM: return IORES_DESC_PERSISTENT_MEMORY; >>> case E820_TYPE_PRAM: return IORES_DESC_PERSISTENT_MEMORY_LEGACY; >>> + case E820_TYPE_RESERVED: return IORES_DESC_RESERVED; >>> case E820_TYPE_RESERVED_KERN: /* Fall-through: */ >>> case E820_TYPE_RAM: /* Fall-through: */ >>> case E820_TYPE_UNUSABLE: /* Fall-through: */ >>> - case E820_TYPE_RESERVED: /* Fall-through: */ >>> default: return IORES_DESC_NONE; >>> } >>> } >>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c >>> index 5378d10f1d31..fea2ef99415d 100644 >>> --- a/arch/x86/mm/ioremap.c >>> +++ b/arch/x86/mm/ioremap.c >>> @@ -83,7 +83,18 @@ static bool __ioremap_check_ram(struct resource *res) >>> >>> static int __ioremap_check_desc_other(struct resource *res) >>> { >>> - return (res->desc != IORES_DESC_NONE); >>> + /* >>> + * But now, the 'E820_TYPE_RESERVED' type is converted to the new >>> + * descriptor 'IORES_DESC_RESERVED' instead of 'IORES_DESC_NONE', >>> + * it has been changed. And the value of 'mem_flags.desc_other' >>> + * is equal to 'true' if we don't strengthen the condition in this >>> + * function, that is wrong. Because originally it is equal to >>> + * 'false' for the same reserved type. >>> + * >>> + * So, that would be nice to keep it the same as before. >>> + */ >>> + return ((res->desc != IORES_DESC_NONE) && >>> + (res->desc != IORES_DESC_RESERVED)); >>> } >> >> Added Tom since he added the check function. Is it possible to only >> check explict valid desc types instead of exclude IORES_DESC_NONE? > > Sorry for the delay... > > The original intent of the check was to map most memory as encrypted under > SEV if it was marked with a specific descriptor, since it was likely to > not be MMIO. I tried converting most things that mapped memory to memremap > vs ioremap, but ACPI was one area that I left alone and this check catches > the mapping of the ACPI tables. I suppose it's possible to change this to > check just for IORES_DESC_ACPI_* values, but I would have to do some > testing. Recently, i tested it according to your advice, here it is really checking for the 'IORES_DESC_ACPI_*' values. If you agree to this change, i would add the following patch into this patch set and post them again. [root@localhost linux]# git diff arch/x86/mm/ioremap.c diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 0029604af8a4..0e3ba620612d 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -83,7 +83,8 @@ static bool __ioremap_check_ram(struct resource *res) static int __ioremap_check_desc_other(struct resource *res) { - return (res->desc != IORES_DESC_NONE); + return ((res->desc == IORES_DESC_ACPI_TABLES) || + (res->desc == IORES_DESC_ACPI_NV_STORAGE)); } Thanks. Lianbo > > Thanks, > Tom > >> >>> >>> static int __ioremap_res_check(struct resource *res, void *arg) >>> diff --git a/include/linux/ioport.h b/include/linux/ioport.h >>> index da0ebaec25f0..6ed59de48bd5 100644 >>> --- a/include/linux/ioport.h >>> +++ b/include/linux/ioport.h >>> @@ -133,6 +133,7 @@ enum { >>> IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5, >>> IORES_DESC_DEVICE_PRIVATE_MEMORY = 6, >>> IORES_DESC_DEVICE_PUBLIC_MEMORY = 7, >>> + IORES_DESC_RESERVED = 8, >>> }; >>> >>> /* helpers to define resources */ >>> diff --git a/kernel/resource.c b/kernel/resource.c >>> index b0fbf685c77a..f34a632c4169 100644 >>> --- a/kernel/resource.c >>> +++ b/kernel/resource.c >>> @@ -994,7 +994,7 @@ __reserve_region_with_split(struct resource *root, resource_size_t start, >>> res->start = start; >>> res->end = end; >>> res->flags = type | IORESOURCE_BUSY; >>> - res->desc = IORES_DESC_NONE; >>> + res->desc = IORES_DESC_RESERVED; >>> >>> while (1) { >>> >>> @@ -1029,7 +1029,7 @@ __reserve_region_with_split(struct resource *root, resource_size_t start, >>> next_res->start = conflict->end + 1; >>> next_res->end = end; >>> next_res->flags = type | IORESOURCE_BUSY; >>> - next_res->desc = IORES_DESC_NONE; >>> + next_res->desc = IORES_DESC_RESERVED; >>> } >>> } else { >>> res->start = conflict->end + 1; >>> @@ -1477,7 +1477,7 @@ static int __init reserve_setup(char *str) >>> res->start = io_start; >>> res->end = io_start + io_num - 1; >>> res->flags |= IORESOURCE_BUSY; >>> - res->desc = IORES_DESC_NONE; >>> + res->desc = IORES_DESC_RESERVED; >>> res->child = NULL; >>> if (request_resource(parent, res) == 0) >>> reserved = x+1; >>> -- >>> 2.17.1 >>> >> >> >> There are a lot of places call region_intersects which use DESC_NONE, >> I'm not sure if needed changes accordingly. Cced Dan and Toshi. >> >> >> Thanks >> Dave >>