Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3712487yba; Mon, 29 Apr 2019 07:20:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqz+TJ1yBN+Pml32bIuSre4evV/u2CZYVT9CG4KPwLKza/H4hWO9nxJcxyzXcUL2BZdS13SZ X-Received: by 2002:a62:1b8a:: with SMTP id b132mr62481270pfb.19.1556547620070; Mon, 29 Apr 2019 07:20:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556547620; cv=none; d=google.com; s=arc-20160816; b=CHdqS/cyT+XFHRJ9yqv5B0P5VR6Ewa00g3wXujxobe68bZga09ui4whZaRBh0N3CQs V1XYsPkyWToSrUU1vBBTHFTJg7n/AEC3fi8tpt4XHFCy7T1AefCsEZx0nqANmTteRkS7 WIqov1j9A0KYGOccYqZeaaaqjkgIrE6IyCJZMXUrCnLXvR//a4IwTJjOkTs3WqDUOjwx GKPWJIqjXxKuiX+LOOFXAL/roIW6kYMvb0N8SSqhKnNcX0YOyc6/KKwBkXhHWORObnBV U8TDL4UrbvzrHKWhE+AtJf0/kLID1o8k0XxNoYzGIPlWoi2BW28SM3XkZGRMUq9FCpPm ErnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=IT0PS0jtlguAQJX2OTh5Gqtnvo3Mr3bgrOOjuw1JiTE=; b=YDTK3QsA7W4DCtjGEzbfQo7JJpIoQ7JIwl42+2qx0/HniGHMwSHiLvfzuoG3h3djiA 2u5efimdjOu7otSTdPXtH0n47i43UBEquCXqbin7T3MYFxjEaiNHwG5qB26HBnhhR6f4 IR2O33JkKiwob32xLg4wpWi9s4FLI1GeG/O9Dzik27O9Y8nSttg+ENfui1X5Om0BypxD eNLmADol7VRdVIeGyMSorEKl8LFKG8GKPe3E7DxzIus9sxrKvXh77WCPlvdJf7KoEcXK B3iM0fweArIkRlsAEzSVSdnbIcBhqwxD9w2H2au6lQ7AtJ8P05HyTP2Ql0t092LUaStl 5Cog== 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 g12si33576610plp.340.2019.04.29.07.20.03; Mon, 29 Apr 2019 07:20:20 -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 S1728396AbfD2OQo (ORCPT + 99 others); Mon, 29 Apr 2019 10:16:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55490 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728258AbfD2OQn (ORCPT ); Mon, 29 Apr 2019 10:16:43 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 85E1B81E09; Mon, 29 Apr 2019 14:16:41 +0000 (UTC) Received: from localhost (ovpn-12-38.pek2.redhat.com [10.72.12.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6FA8E5799; Mon, 29 Apr 2019 14:16:39 +0000 (UTC) Date: Mon, 29 Apr 2019 22:16:36 +0800 From: Baoquan He To: bp@alien8.de Cc: j-nomura@ce.jp.nec.com, kasong@redhat.com, dyoung@redhat.com, fanc.fnst@cn.fujitsu.com, x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, hpa@zytor.com, tglx@linutronix.de Subject: Re: [PATCH v6 1/2] x86/kexec: Build identity mapping for EFI systab and ACPI tables Message-ID: <20190429141636.GB14140@MiWiFi-R3L-srv> References: <20190424092944.30481-1-bhe@redhat.com> <20190424092944.30481-2-bhe@redhat.com> <20190429002318.GA25400@MiWiFi-R3L-srv> <20190429135536.GC2324@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190429135536.GC2324@zn.tnic> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 29 Apr 2019 14:16:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/29/19 at 03:55pm, Borislav Petkov wrote: > On Mon, Apr 29, 2019 at 08:23:18AM +0800, Baoquan He wrote: > > +static int > > +map_acpi_tables(struct x86_mapping_info *info, pgd_t *level4p) > > +{ > > + unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY; > > + struct init_pgtable_data data; > > + > > + data.info = info; > > + data.level4p = level4p; > > + flags = IORESOURCE_MEM | IORESOURCE_BUSY; > > + return walk_iomem_res_desc(IORES_DESC_ACPI_TABLES, flags, 0, -1, > > + &data, mem_region_callback); > > +} > > +#else > > +static int init_acpi_pgtable(struct x86_mapping_info *info, > > Did you at least build-test the !CONFIG_ACPI case? > > arch/x86/kernel/machine_kexec_64.c: In function ‘init_pgtable’: > arch/x86/kernel/machine_kexec_64.c:237:11: error: implicit declaration of function ‘map_acpi_tables’; did you mean ‘init_acpi_pgtable’? [-Werror=implicit-function-declaration] > result = map_acpi_tables(&info, level4p); > ^~~~~~~~~~~~~~~ > init_acpi_pgtable > > > I don't think so. ;-( > > Sigh, next time at least build-test your patch before hurrying it out. I > fixed it up along with decyphering the commit message: Sorry, thought them simple, didn't build !CONFIG_ACPI case. Should be more careful. Thanks for fixing it and the log rewriting. > > --- > From: Kairui Song > Date: Mon, 29 Apr 2019 08:23:18 +0800 > Subject: [PATCH] x86/kexec: Add the EFI system tables and ACPI tables to the ident map > > Currently, only the whole physical memory is identity-mapped for the > kexec kernel and the regions reserved by firmware are ignored. > > However, the recent addition of RSDP parsing in the decompression stage > and especially: > > 33f0df8d843d ("x86/boot: Search for RSDP in the EFI tables") > > which tries to access EFI system tables and to dig out the RDSP address > from there, becomes a problem because in certain configurations, they > might not be mapped in the kexec'ed kernel's address space. > > What is more, this problem doesn't appear on all systems because the > kexec kernel uses gigabyte pages to build the identity mapping. And > the EFI system tables and ACPI tables can, depending on the system > configuration, end up being mapped as part of all physical memory, if > they share the same 1 GB area with the physical memory. > > Therefore, make sure they're always mapped. > > [ bp: productize half-baked patch: > - rewrite commit message. > - s/init_acpi_pgtable/map_acpi_tables/ in the !ACPI case. ] > > Signed-off-by: Kairui Song > Signed-off-by: Baoquan He > Signed-off-by: Borislav Petkov > Cc: dyoung@redhat.com > Cc: fanc.fnst@cn.fujitsu.com > Cc: "H. Peter Anvin" > Cc: Ingo Molnar > Cc: j-nomura@ce.jp.nec.com > Cc: kexec@lists.infradead.org > Cc: "Kirill A. Shutemov" > Cc: Lianbo Jiang > Cc: Tetsuo Handa > Cc: Thomas Gleixner > Cc: x86-ml > Link: https://lkml.kernel.org/r/20190429002318.GA25400@MiWiFi-R3L-srv > --- > arch/x86/kernel/machine_kexec_64.c | 75 ++++++++++++++++++++++++++++++ > 1 file changed, 75 insertions(+) > > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c > index ceba408ea982..3c77bdf7b32a 100644 > --- a/arch/x86/kernel/machine_kexec_64.c > +++ b/arch/x86/kernel/machine_kexec_64.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -29,6 +30,43 @@ > #include > #include > > +#ifdef CONFIG_ACPI > +/* > + * Used while adding mapping for ACPI tables. > + * Can be reused when other iomem regions need be mapped > + */ > +struct init_pgtable_data { > + struct x86_mapping_info *info; > + pgd_t *level4p; > +}; > + > +static int mem_region_callback(struct resource *res, void *arg) > +{ > + struct init_pgtable_data *data = arg; > + unsigned long mstart, mend; > + > + mstart = res->start; > + mend = mstart + resource_size(res) - 1; > + > + return kernel_ident_mapping_init(data->info, data->level4p, mstart, mend); > +} > + > +static int > +map_acpi_tables(struct x86_mapping_info *info, pgd_t *level4p) > +{ > + unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY; > + struct init_pgtable_data data; > + > + data.info = info; > + data.level4p = level4p; > + flags = IORESOURCE_MEM | IORESOURCE_BUSY; > + return walk_iomem_res_desc(IORES_DESC_ACPI_TABLES, flags, 0, -1, > + &data, mem_region_callback); > +} > +#else > +static int map_acpi_tables(struct x86_mapping_info *info, pgd_t *level4p) { return 0; } > +#endif > + > #ifdef CONFIG_KEXEC_FILE > const struct kexec_file_ops * const kexec_file_loaders[] = { > &kexec_bzImage64_ops, > @@ -36,6 +74,31 @@ const struct kexec_file_ops * const kexec_file_loaders[] = { > }; > #endif > > +static int > +map_efi_systab(struct x86_mapping_info *info, pgd_t *level4p) > +{ > +#ifdef CONFIG_EFI > + unsigned long mstart, mend; > + > + if (!efi_enabled(EFI_BOOT)) > + return 0; > + > + mstart = (boot_params.efi_info.efi_systab | > + ((u64)boot_params.efi_info.efi_systab_hi<<32)); > + > + if (efi_enabled(EFI_64BIT)) > + mend = mstart + sizeof(efi_system_table_64_t); > + else > + mend = mstart + sizeof(efi_system_table_32_t); > + > + if (!mstart) > + return 0; > + > + return kernel_ident_mapping_init(info, level4p, mstart, mend); > +#endif > + return 0; > +} > + > static void free_transition_pgtable(struct kimage *image) > { > free_page((unsigned long)image->arch.p4d); > @@ -159,6 +222,18 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable) > return result; > } > > + /* > + * Prepare EFI systab and ACPI tables for kexec kernel since they are > + * not covered by pfn_mapped. > + */ > + result = map_efi_systab(&info, level4p); > + if (result) > + return result; > + > + result = map_acpi_tables(&info, level4p); > + if (result) > + return result; > + > return init_transition_pgtable(image, level4p); > } > > -- > 2.21.0 > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.