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 <kasong@xxxxxxxxxx>
> 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 <kasong@xxxxxxxxxx>
> Signed-off-by: Baoquan He <bhe@xxxxxxxxxx>
> Signed-off-by: Borislav Petkov <bp@xxxxxxx>
> Cc: dyoung@xxxxxxxxxx
> Cc: fanc.fnst@xxxxxxxxxxxxxx
> Cc: "H. Peter Anvin" <hpa@xxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: j-nomura@xxxxxxxxxxxxx
> Cc: kexec@xxxxxxxxxxxxxxxxxxx
> Cc: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
> Cc: Lianbo Jiang <lijiang@xxxxxxxxxx>
> Cc: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: x86-ml <x86@xxxxxxxxxx>
> 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 <linux/io.h>
> #include <linux/suspend.h>
> #include <linux/vmalloc.h>
> +#include <linux/efi.h>
>
> #include <asm/init.h>
> #include <asm/pgtable.h>
> @@ -29,6 +30,43 @@
> #include <asm/setup.h>
> #include <asm/set_memory.h>
>
> +#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.
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
