[PATCH v2 0/4] kexec-tools, x86: E820 memmap pass for kdump

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



First question is if Calgary even exists anymore and if so if someone actually cares about it enough to maintain it.

On February 24, 2014 6:58:41 AM PST, WANG Chao <chaowang at redhat.com> wrote:
>On 02/24/14 at 11:38am, Thomas Renninger wrote:
>> On Thursday, February 20, 2014 05:28:28 PM WANG Chao wrote:
>> > Hi, All
>> > 
>> > When kaslr comes in and kdump is broken, it seems about the right
>time to
>> > use E820 instead of memmap=exactmap to pass memmap for kdump for
>the
>> > default memmap passing mechanism:
>> >
>http://lists.infradead.org/pipermail/kexec/2014-February/011048.html
>> > 
>> > Unfortunately, saved_max_pfn still got its user out there (calgry
>pci, it
>> > looks like the only one). So for backward compatibility, I'm
>introducing a
>> > new option --pass-memmap-cmdline to force kexec-tools to pass
>> > memmap=exactmap, the old way.
>> The saved_max_pfn usage is calgary pci looks bad/wrong and I wonder:
>>   - whether this is still worth touching, so that the old mechanism:
>>     --pass-memmap-cmdline could vanish in the one or other year and
>need
>>     not to be carried forever
>> I tried to find such a machine, but couldn't find anything mentioning
>calgary
>> in quite some machines' dmesg.
>> 
>> Approaches to avoid saved_max_pfn in calgary case:
>>   1) If done correctly from the beginning, the TCE table size would
>have
>>      been exposed via /sys and kexec-tools could simply add:
>>      calgary="128k|512K...|8M" which is already caught by pci-calgary
>and
>>      saved_max_pfn is not needed/touched anymore.
>>      -> Disadvantage: needs a new sysfs entry
>>   2) When finding max_pfn for calgary table size usage, we could try
>in 
>>      kdump case to use the highest memory (RAM or RESERVED) showing
>up
>>      in e820 map.
>
>How could this replace saved_max_pfn? The highest memory in kdump can't
>necessarily be the real ram size. In kdump, RAM range is just part of
>the real
>ram, not mentioning we don't pass RESERVED range to kdump E820.
>
>Thanks
>WANG Chao
>
>> 
>> Please find below a patch which would eleminate the last
>saved_max_pfn
>> user. Unfortunately I could not find a calgary system to test this
>on.
>> 
>> Be aware: I could not test this.
>> If someone tells me for what kind of machine (and BIOS stuff
>enabled?)
>> I should look for, I can try to search for such a platform.
>> 
>> Something else: There is quite some duplicate code in kexec-tools
>when it
>> is about retrieving the e820 table info (normal kexec vs kdump).
>> Did you see my cleanups I posted long ago? Do you plan to still clean
>up
>> a bit after this series?
>
>Yes, I saw them and find some of them are pretty useful for this
>patchset. I suppose some cleanups can be done later. Feel free to clean
>up after this patchset is settled.
>
>> 
>>         Thomas
>> 
>> 
>> 
>> X86: Eliminate saved_max_pfn user in pci-calgary and remove the
>unused variable
>> 
>> Searching for the highest value of RAM and RESERVED memory in kdump
>case
>> should be the same as max_pfn of the original kernel.
>> At least this is always the case as long as type usable RAM is the
>highest
>> entry in original e820 map.
>> 
>> Signed-off-by: Thomas Renninger <trenn at suse.de>
>> 
>> diff --git a/arch/x86/include/asm/e820.h
>b/arch/x86/include/asm/e820.h
>> index 779c2ef..712173e 100644
>> --- a/arch/x86/include/asm/e820.h
>> +++ b/arch/x86/include/asm/e820.h
>> @@ -49,6 +49,7 @@ static inline void early_memtest(unsigned long
>start, unsigned long end)
>>  #endif
>>  
>>  extern unsigned long e820_end_of_ram_pfn(void);
>> +extern unsigned long e820_end_of_e820_pfn(void);
>>  extern unsigned long e820_end_of_low_ram_pfn(void);
>>  extern u64 early_reserve_e820(u64 sizet, u64 align);
>>  
>> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
>> index 988c00a..699e8fe 100644
>> --- a/arch/x86/kernel/e820.c
>> +++ b/arch/x86/kernel/e820.c
>> @@ -757,7 +757,7 @@ u64 __init early_reserve_e820(u64 size, u64
>align)
>>  /*
>>   * Find the highest page frame number we have available
>>   */
>> -static unsigned long __init e820_end_pfn(unsigned long limit_pfn,
>unsigned type)
>> +unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned
>type)
>>  {
>>  	int i;
>>  	unsigned long last_pfn = 0;
>> @@ -796,6 +796,12 @@ unsigned long __init e820_end_of_ram_pfn(void)
>>  	return e820_end_pfn(MAX_ARCH_PFN, E820_RAM);
>>  }
>>  
>> +unsigned long __init e820_end_of_e820_pfn(void)
>> +{
>> +	return max(e820_end_pfn(MAX_ARCH_PFN, E820_RAM),
>> +		   e820_end_pfn(MAX_ARCH_PFN, E820_RESERVED);
>> +}
>> +
>>  unsigned long __init e820_end_of_low_ram_pfn(void)
>>  {
>>  	return e820_end_pfn(1UL<<(32 - PAGE_SHIFT), E820_RAM);
>> @@ -847,14 +853,6 @@ static int __init parse_memmap_one(char *p)
>>  		return -EINVAL;
>>  
>>  	if (!strncmp(p, "exactmap", 8)) {
>> -#ifdef CONFIG_CRASH_DUMP
>> -		/*
>> -		 * If we are doing a crash dump, we still need to know
>> -		 * the real mem size before original memory map is
>> -		 * reset.
>> -		 */
>> -		saved_max_pfn = e820_end_of_ram_pfn();
>> -#endif
>>  		e820.nr_map = 0;
>>  		userdef = 1;
>>  		return 0;
>> diff --git a/arch/x86/kernel/pci-calgary_64.c
>b/arch/x86/kernel/pci-calgary_64.c
>> index 299d493..89ae766 100644
>> --- a/arch/x86/kernel/pci-calgary_64.c
>> +++ b/arch/x86/kernel/pci-calgary_64.c
>> @@ -1371,6 +1371,7 @@ int __init detect_calgary(void)
>>  	unsigned long ptr;
>>  	unsigned int offset, prev_offset;
>>  	int ret;
>> +	unsigned long orig_max_pfn = max_pfn;
>>  
>>  	/*
>>  	 * if the user specified iommu=off or iommu=soft or we found
>> @@ -1418,8 +1419,10 @@ int __init detect_calgary(void)
>>  		return -ENOMEM;
>>  	}
>>  
>> -	specified_table_size = determine_tce_table_size((is_kdump_kernel()
>?
>> -					saved_max_pfn : max_pfn) * PAGE_SIZE);
>> +	if (is_kdump_kernel())
>> +		orig_max_pfn = e820_end_of_e820_pfn();
>> +	specified_table_size = determine_tce_table_size(orig_max_pfn
>> +							* PAGE_SIZE);
>>  
>>  	for (bus = 0; bus < MAX_PHB_BUS_NUM; bus++) {
>>  		struct calgary_bus_info *info = &bus_info[bus];
>> diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
>> index 7032518..bce4d97 100644
>> --- a/include/linux/crash_dump.h
>> +++ b/include/linux/crash_dump.h
>> @@ -87,5 +87,4 @@ extern void unregister_oldmem_pfn_is_ram(void);
>>  static inline int is_kdump_kernel(void) { return 0; }
>>  #endif /* CONFIG_CRASH_DUMP */
>>  
>> -extern unsigned long saved_max_pfn;
>>  #endif /* LINUX_CRASHDUMP_H */
>> diff --git a/kernel/crash_dump.c b/kernel/crash_dump.c
>> index c766ee5..9d50486 100644
>> --- a/kernel/crash_dump.c
>> +++ b/kernel/crash_dump.c
>> @@ -5,12 +5,6 @@
>>  #include <linux/export.h>
>>  
>>  /*
>> - * If we have booted due to a crash, max_pfn will be a very low
>value. We need
>> - * to know the amount of memory that the previous kernel used.
>> - */
>> -unsigned long saved_max_pfn;
>> -
>> -/*
>>   * stores the physical address of elf header of crash image
>>   *
>>   * Note: elfcorehdr_addr is not just limited to vmcore. It is also
>used by
>> 

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux