Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3686736yba; Mon, 29 Apr 2019 06:57:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqzaDBEtTz4Z03tragOBnxgJ5YFcImxJS6a2uKJXqanfU3PYYftab+/9tWKT1JOhqt737wah X-Received: by 2002:a65:5184:: with SMTP id h4mr10476847pgq.109.1556546225495; Mon, 29 Apr 2019 06:57:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556546225; cv=none; d=google.com; s=arc-20160816; b=T8p5Tr1wAtqHWpNlB1eeW2RPu5YI/x7nvJsETzVdFRvWH13aQceKkiAM0xW8DjZppp Un0nSrbMdIgn13ssalBq6hHj09ygIHfoh1YT81UuqXG/aqcAh/CiU+qH9OMfcnD/nAow 06AUZZukTDnjhjM1um+HURlPbdHCaD0YqG/ffJ58gEIJASAysGSsgPLVA+4lJ79fn3ai R3BNVe6+5Ls4q6cB/ftLTsYgfgupZ/xzp2kvmyT8yp3WB5YHIGndiKLwE2w7blsrk+vP YZJUGUQJuVoElZkxIZjUoZa6cd3L9MSFEDlFEcb6sgtXKCfICbb2P5yN/a5/EHJ3dBd6 1VrQ== 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:dkim-signature; bh=pkKmQx1hXyy8yc+54Irk8GBhU0FUwLSYEGMtUyIifSQ=; b=1Gh+Pd5BfI0vcfrRe66jGpJ3yskOJDNBJBskK3cqAHcMOqPYprzwuFUJXAoNE7zlaA PYYBkS55oq1r70HrNK4KDm1bemf+9O4p0DsPtju4psKNYaIvLPYy6JaH5VlL/BEiCj9B YQAiLPZKi+Su7Ihr0unCJ01i+fupeyZDqAIF8UyIBl0ulVQ/KP8XzYWFbi61SmNvijIu 2ewhpCsd7yBb9PxSlw1Kuidqppgh2dWH7X7TFh71LxcCatMn7P+8oS0LjJdIIIn+OB1d GwqgaG8awy/jOS13FCZ3AAvliguUri7H9o/w8uqvXPhzO777U9uTEpgnmFFQ6tsVPNMn EfiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=WXH8zV6s; 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=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k33si34042051pld.27.2019.04.29.06.56.49; Mon, 29 Apr 2019 06:57:05 -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; dkim=pass header.i=@alien8.de header.s=dkim header.b=WXH8zV6s; 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=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728243AbfD2Nzp (ORCPT + 99 others); Mon, 29 Apr 2019 09:55:45 -0400 Received: from mail.skyhub.de ([5.9.137.197]:40790 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725838AbfD2Nzp (ORCPT ); Mon, 29 Apr 2019 09:55:45 -0400 Received: from zn.tnic (p200300EC2F073600329C23FFFEA6A903.dip0.t-ipconnect.de [IPv6:2003:ec:2f07:3600:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 38CAF1EC014A; Mon, 29 Apr 2019 15:55:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1556546143; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pkKmQx1hXyy8yc+54Irk8GBhU0FUwLSYEGMtUyIifSQ=; b=WXH8zV6ssFWvah6GS6OaGyVtonfgmw3FoGJwMsdAf4qccou6hk/IPHMk/bjUAn0ARuYxHl EOKAAnJYV0oISYMsL6g7ybg6XGU6XPdz6ZFFT8yPUHD/7lVnl5tonjLhRKbyO89iLsUtFE VIm6zXvR7AKAshtaT2unlq8odKNypn8= Date: Mon, 29 Apr 2019 15:55:36 +0200 From: Borislav Petkov To: Baoquan He 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: <20190429135536.GC2324@zn.tnic> References: <20190424092944.30481-1-bhe@redhat.com> <20190424092944.30481-2-bhe@redhat.com> <20190429002318.GA25400@MiWiFi-R3L-srv> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190429002318.GA25400@MiWiFi-R3L-srv> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: --- 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.