All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Jiri Bohac <jbohac@suse.cz>
Cc: Toshi Kani <toshi.kani@hpe.com>, David Airlie <airlied@linux.ie>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore
Date: Mon, 6 Nov 2017 10:41:43 +0800	[thread overview]
Message-ID: <20171106024143.GA3669@x1> (raw)
In-Reply-To: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>

Hi Jiri,

On 11/03/17 at 06:28pm, Jiri Bohac wrote:
> On machines where the GART aperture is mapped over physical RAM
> /proc/vmcore contains the remapped range and reading it may
> cause hangs or reboots. This range needs to be excluded from /proc/vmcore.
> 
> This has originally been implemented by commit dd5f726076cc ("kexec:
> support for kexec on panic using new system call").
> 
> The implementation relied on the GART code adding an iomem_resource for
> this range called "GART", as implemented by commit 56dd669a138c ("[PATCH]
> Insert GART region into resource map")
> 
> However, inserting the iomem_resource from the early GART code caused
> resource conflicts with some AGP drivers (bko#72201), which got avoided by
> reverting the patch in commit 707d4eefbdb3 ("Revert [PATCH] Insert GART
> region into resource map"). This revert introduced the /proc/vmcore bug.
> 
> With the "GART" iomem_resource removed, the defunct code in crash.c has
> been removed by commit f296f2634920 ("x86/kexec: Remove walk_iomem_res()
> call with GART type")

Is this reproduced on a machine with GART existing and passing test with
this patch applied? Do you have a /proc/iomem printing about the machine
you are testing on?

If this patch works, then I am wondering how we shold deal with the old
way in which no '-s' is specified. Since no GART information is exported
to /proc/iomem.

Do we have a way to pick GART region away from iomem_resource to not let
the aperture seen from /proc/iomem?

Thanks
Baoquan

> 
> The patch below stores the location of the GART region in two variables
> (named gart_stolen_ram_start and gart_stolen_ram_end) and reverts/adapts
> parts of f296f2634920 to exclude the region from /proc/vmcore.
> 
> Passing the information via an iomem_resource (or by reserving the range
> in the e820, which would propagate into an iomem_resource) would
> reintroduce bko#72201.
> 
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
> Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map")
> 
> diff --git a/arch/x86/include/asm/gart.h b/arch/x86/include/asm/gart.h
> index 1d268098ac2e..324a0a19d166 100644
> --- a/arch/x86/include/asm/gart.h
> +++ b/arch/x86/include/asm/gart.h
> @@ -2,6 +2,7 @@
>  #define _ASM_X86_GART_H
>  
>  #include <asm/e820/api.h>
> +#include <linux/pci.h>
>  
>  extern void set_up_gart_resume(u32, u32);
>  
> @@ -33,6 +34,8 @@ extern int fix_aperture;
>  extern int gart_iommu_aperture;
>  extern int gart_iommu_aperture_allowed;
>  extern int gart_iommu_aperture_disabled;
> +extern u32 gart_stolen_ram_start;
> +extern u32 gart_stolen_ram_end;
>  
>  extern void early_gart_iommu_check(void);
>  extern int gart_iommu_init(void);
> @@ -43,6 +46,8 @@ extern int gart_iommu_hole_init(void);
>  #define gart_iommu_aperture            0
>  #define gart_iommu_aperture_allowed    0
>  #define gart_iommu_aperture_disabled   1
> +#define gart_stolen_ram_start	       0
> +#define gart_stolen_ram_end	       0
>  
>  static inline void early_gart_iommu_check(void)
>  {
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index ef2859f9fcce..bc9a9b5b88e3 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -49,6 +49,8 @@
>  int gart_iommu_aperture;
>  int gart_iommu_aperture_disabled __initdata;
>  int gart_iommu_aperture_allowed __initdata;
> +u32 gart_stolen_ram_start;
> +u32 gart_stolen_ram_end;
>  
>  int fallback_aper_order __initdata = 1; /* 64MB */
>  int fallback_aper_force __initdata;
> @@ -87,6 +89,9 @@ static u32 __init allocate_aperture(void)
>  	register_nosave_region(addr >> PAGE_SHIFT,
>  			       (addr+aper_size) >> PAGE_SHIFT);
>  
> +	gart_stolen_ram_start = (u32)addr;
> +	gart_stolen_ram_end = (u32)addr + aper_size - 1;
> +
>  	return (u32)addr;
>  }
>  
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 44404e2307bb..ce065d72656d 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -37,6 +37,7 @@
>  #include <asm/reboot.h>
>  #include <asm/virtext.h>
>  #include <asm/intel_pt.h>
> +#include <asm/gart.h>
>  
>  /* Alignment required for elf header segment */
>  #define ELF_CORE_HEADER_ALIGN   4096
> @@ -58,7 +59,7 @@ struct crash_elf_data {
>  	struct kimage *image;
>  	/*
>  	 * Total number of ram ranges we have after various adjustments for
> -	 * crash reserved region, etc.
> +	 * GART, crash reserved region etc.
>  	 */
>  	unsigned int max_nr_ranges;
>  
> @@ -217,7 +218,6 @@ static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
>  	return 0;
>  }
>  
> -
>  /* Gather all the required information to prepare elf headers for ram regions */
>  static void fill_up_crash_elf_data(struct crash_elf_data *ced,
>  				   struct kimage *image)
> @@ -231,6 +231,15 @@ static void fill_up_crash_elf_data(struct crash_elf_data *ced,
>  
>  	ced->max_nr_ranges = nr_ranges;
>  
> +	/*
> +	 * We don't create ELF headers for GART aperture as an attempt
> +	 * to dump this memory in second kernel leads to hang/crash.
> +	 * If gart aperture is mapped over RAM, one needs to exclude that region
> +	 * and that requires an extra phdr.
> +	 */
> +	if (gart_stolen_ram_start)
> +		ced->max_nr_ranges++;
> +
>  	/* Exclusion of crash region could split memory ranges */
>  	ced->max_nr_ranges++;
>  
> @@ -339,6 +348,14 @@ static int elf_header_exclude_ranges(struct crash_elf_data *ced,
>  			return ret;
>  	}
>  
> +	/* Exclude GART region */
> +	if (gart_stolen_ram_start) {
> +		ret = exclude_mem_range(cmem, gart_stolen_ram_start,
> +					gart_stolen_ram_end);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	return ret;
>  }
>  
> -- 
> Jiri Bohac <jbohac@suse.cz>
> SUSE Labs, Prague, Czechia
> 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Jiri Bohac <jbohac@suse.cz>
Cc: David Airlie <airlied@linux.ie>, Dave Young <dyoung@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Toshi Kani <toshi.kani@hpe.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore
Date: Mon, 6 Nov 2017 10:41:43 +0800	[thread overview]
Message-ID: <20171106024143.GA3669@x1> (raw)
In-Reply-To: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>

Hi Jiri,

On 11/03/17 at 06:28pm, Jiri Bohac wrote:
> On machines where the GART aperture is mapped over physical RAM
> /proc/vmcore contains the remapped range and reading it may
> cause hangs or reboots. This range needs to be excluded from /proc/vmcore.
> 
> This has originally been implemented by commit dd5f726076cc ("kexec:
> support for kexec on panic using new system call").
> 
> The implementation relied on the GART code adding an iomem_resource for
> this range called "GART", as implemented by commit 56dd669a138c ("[PATCH]
> Insert GART region into resource map")
> 
> However, inserting the iomem_resource from the early GART code caused
> resource conflicts with some AGP drivers (bko#72201), which got avoided by
> reverting the patch in commit 707d4eefbdb3 ("Revert [PATCH] Insert GART
> region into resource map"). This revert introduced the /proc/vmcore bug.
> 
> With the "GART" iomem_resource removed, the defunct code in crash.c has
> been removed by commit f296f2634920 ("x86/kexec: Remove walk_iomem_res()
> call with GART type")

Is this reproduced on a machine with GART existing and passing test with
this patch applied? Do you have a /proc/iomem printing about the machine
you are testing on?

If this patch works, then I am wondering how we shold deal with the old
way in which no '-s' is specified. Since no GART information is exported
to /proc/iomem.

Do we have a way to pick GART region away from iomem_resource to not let
the aperture seen from /proc/iomem?

Thanks
Baoquan

> 
> The patch below stores the location of the GART region in two variables
> (named gart_stolen_ram_start and gart_stolen_ram_end) and reverts/adapts
> parts of f296f2634920 to exclude the region from /proc/vmcore.
> 
> Passing the information via an iomem_resource (or by reserving the range
> in the e820, which would propagate into an iomem_resource) would
> reintroduce bko#72201.
> 
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
> Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map")
> 
> diff --git a/arch/x86/include/asm/gart.h b/arch/x86/include/asm/gart.h
> index 1d268098ac2e..324a0a19d166 100644
> --- a/arch/x86/include/asm/gart.h
> +++ b/arch/x86/include/asm/gart.h
> @@ -2,6 +2,7 @@
>  #define _ASM_X86_GART_H
>  
>  #include <asm/e820/api.h>
> +#include <linux/pci.h>
>  
>  extern void set_up_gart_resume(u32, u32);
>  
> @@ -33,6 +34,8 @@ extern int fix_aperture;
>  extern int gart_iommu_aperture;
>  extern int gart_iommu_aperture_allowed;
>  extern int gart_iommu_aperture_disabled;
> +extern u32 gart_stolen_ram_start;
> +extern u32 gart_stolen_ram_end;
>  
>  extern void early_gart_iommu_check(void);
>  extern int gart_iommu_init(void);
> @@ -43,6 +46,8 @@ extern int gart_iommu_hole_init(void);
>  #define gart_iommu_aperture            0
>  #define gart_iommu_aperture_allowed    0
>  #define gart_iommu_aperture_disabled   1
> +#define gart_stolen_ram_start	       0
> +#define gart_stolen_ram_end	       0
>  
>  static inline void early_gart_iommu_check(void)
>  {
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index ef2859f9fcce..bc9a9b5b88e3 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -49,6 +49,8 @@
>  int gart_iommu_aperture;
>  int gart_iommu_aperture_disabled __initdata;
>  int gart_iommu_aperture_allowed __initdata;
> +u32 gart_stolen_ram_start;
> +u32 gart_stolen_ram_end;
>  
>  int fallback_aper_order __initdata = 1; /* 64MB */
>  int fallback_aper_force __initdata;
> @@ -87,6 +89,9 @@ static u32 __init allocate_aperture(void)
>  	register_nosave_region(addr >> PAGE_SHIFT,
>  			       (addr+aper_size) >> PAGE_SHIFT);
>  
> +	gart_stolen_ram_start = (u32)addr;
> +	gart_stolen_ram_end = (u32)addr + aper_size - 1;
> +
>  	return (u32)addr;
>  }
>  
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 44404e2307bb..ce065d72656d 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -37,6 +37,7 @@
>  #include <asm/reboot.h>
>  #include <asm/virtext.h>
>  #include <asm/intel_pt.h>
> +#include <asm/gart.h>
>  
>  /* Alignment required for elf header segment */
>  #define ELF_CORE_HEADER_ALIGN   4096
> @@ -58,7 +59,7 @@ struct crash_elf_data {
>  	struct kimage *image;
>  	/*
>  	 * Total number of ram ranges we have after various adjustments for
> -	 * crash reserved region, etc.
> +	 * GART, crash reserved region etc.
>  	 */
>  	unsigned int max_nr_ranges;
>  
> @@ -217,7 +218,6 @@ static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
>  	return 0;
>  }
>  
> -
>  /* Gather all the required information to prepare elf headers for ram regions */
>  static void fill_up_crash_elf_data(struct crash_elf_data *ced,
>  				   struct kimage *image)
> @@ -231,6 +231,15 @@ static void fill_up_crash_elf_data(struct crash_elf_data *ced,
>  
>  	ced->max_nr_ranges = nr_ranges;
>  
> +	/*
> +	 * We don't create ELF headers for GART aperture as an attempt
> +	 * to dump this memory in second kernel leads to hang/crash.
> +	 * If gart aperture is mapped over RAM, one needs to exclude that region
> +	 * and that requires an extra phdr.
> +	 */
> +	if (gart_stolen_ram_start)
> +		ced->max_nr_ranges++;
> +
>  	/* Exclusion of crash region could split memory ranges */
>  	ced->max_nr_ranges++;
>  
> @@ -339,6 +348,14 @@ static int elf_header_exclude_ranges(struct crash_elf_data *ced,
>  			return ret;
>  	}
>  
> +	/* Exclude GART region */
> +	if (gart_stolen_ram_start) {
> +		ret = exclude_mem_range(cmem, gart_stolen_ram_start,
> +					gart_stolen_ram_end);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	return ret;
>  }
>  
> -- 
> Jiri Bohac <jbohac@suse.cz>
> SUSE Labs, Prague, Czechia
> 

  reply	other threads:[~2017-11-06  2:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-03 17:28 [PATCH] x86/kexec: Exclude GART aperture from vmcore Jiri Bohac
2017-11-03 17:28 ` Jiri Bohac
2017-11-06  2:41 ` Baoquan He [this message]
2017-11-06  2:41   ` Baoquan He
2017-11-06  9:01   ` Jiri Bohac
2017-11-06  9:01     ` Jiri Bohac
2017-11-06  9:27     ` Baoquan He
2017-11-06  9:27       ` Baoquan He
2017-11-06  9:56       ` Jiri Bohac
2017-11-06  9:56         ` Jiri Bohac
2017-11-07 11:39         ` Baoquan He
2017-11-07 11:39           ` Baoquan He
2017-11-07 13:42           ` Jiri Bohac
2017-11-07 13:42             ` Jiri Bohac
2017-11-07 15:34             ` Jiri Bohac
2017-11-07 15:34               ` Jiri Bohac
2017-11-12  8:04               ` Baoquan He
2017-11-12  8:04                 ` Baoquan He
2017-11-12 10:23                 ` Baoquan He
2017-11-12 10:23                   ` Baoquan He
2017-11-28 21:58                 ` Jiri Bohac
2017-11-28 21:58                   ` Jiri Bohac
2017-11-29  2:43                   ` Baoquan He
2017-11-29  2:43                     ` Baoquan He
2017-11-29 12:27                     ` Jiri Bohac
2017-11-29 12:27                       ` Jiri Bohac

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171106024143.GA3669@x1 \
    --to=bhe@redhat.com \
    --cc=airlied@linux.ie \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jbohac@suse.cz \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=toshi.kani@hpe.com \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.