Re: [v2 1/5] arm64: kdump: reserve memory for crash dump kernel

[AKASHI Takahiro]

On 05/11/2015 04:54 PM, Baoquan He wrote:
> On 05/11/15 at 04:38pm, AKASHI Takahiro wrote:
> > Hi Baoquan,
> >
> > On 04/28/2015 06:19 PM, Baoquan He wrote:
> > > > +#ifdef CONFIG_CRASH_DUMP
> > > > +/*
> > > > + * reserve_elfcorehdr() - reserves memory for elf core header
> > > > + *
> > > > + * This function reserves memory area given in "elfcorehdr=" kernel command
> > > > + * line parameter. The memory reserved is used by a dump capture kernel to
> > > > + * identify the memory used by primary kernel.
> > > > + */
> > >
> > > Hi AKASHI,
> > >
> > > May I know why elfcorehdr need be reserved separately but not locate a
> > > memory region in crashkernel reserved region like all other ARCHs? Is
> > > there any special reason?
> >
> > I don't get your point, but arm as well as arm64 locates elfcorehdr
> > in a crash kernel's memory region.
> > See kexec/arch/arm{,64}/crashdump-arm{,64}.c in kexec-tools.
> >
> > And this region is reserved at boot time *on crash kernel* because we don't want
> > to corrupt it accidentally.
> > (After Mark's comment, we might better remove the mmu mapping for this region, too.)
>
>
> Sorry, I don't make myself clear.
>
> In this patch you reserve a separate memory region in 1st kernel to
> store elfcorehdr. I am wondering why you don't call add_buffer in
> kexec-tools directly. Like this you can get a region from reserved
> crashkernel region. Then you don't need reserve_elfcorehdr() to reserve
> memory for elfcorehdr specifically. Like other ARCHs do only one memory
> region is reserved in 1st kernel, that's crashkernel region.

I think that you misunderstand somewhat.
* Kexec-tools only locates/identifies a small region for elfcore header within crash kernel's
memory region while 1st kernel is running.
* the data in elfcore header is filled up by kexec_load system call on 1st kernel.
* 1st kernel doesn't reserve any region for elfcore header because the kernel
commandline parameters don't contains "elfcorehdr=" parameter, then elfcorehdr_size=0.
* Crash dump kernel does reserve the region, as I said, because we don't want to
corrupt the info in elfcore header accidentally while crash kernel is running.

Clear?

-Takahiro AKASHI

> Thanks
> Baoquan
> > Make sense?
> >
> > -Takahiro AKASHI
> >
> > > Thanks
> > > Baoquan
> > >
> > > > +static void __init reserve_elfcorehdr(void)
> > > > +{
> > > > +	if (!elfcorehdr_size)
> > > > +		return;
> > > > +
> > > > +	if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
> > > > +		pr_warn("elfcorehdr reservation failed - memory is in use (0x%llx)\n",
> > > > +			elfcorehdr_addr);
> > > > +		return;
> > > > +	}
> > > > +
> > > > +	if (memblock_reserve(elfcorehdr_addr, elfcorehdr_size)) {
> > > > +		pr_warn("elfcorehdr reservation failed - out of memory\n");
> > > > +		return;
> > > > +	}
> > > > +
> > > > +	pr_info("Reserving %lldKB of memory at %lldMB for elfcorehdr\n",
> > > > +		elfcorehdr_size >> 10, elfcorehdr_addr >> 20);
> > > > +}
> > > > +#endif /* CONFIG_CRASH_DUMP */
> > > >   /*
> > > >    * Return the maximum physical address for ZONE_DMA (DMA_BIT_MASK(32)). It
> > > >    * currently assumes that for memory starting above 4G, 32-bit devices will
> > > > @@ -170,6 +247,13 @@ void __init arm64_memblock_init(void)
> > > >   		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
> > > >   #endif
> > > >
> > > > +#ifdef CONFIG_KEXEC
> > > > +	reserve_crashkernel(memory_limit);
> > > > +#endif
> > > > +#ifdef CONFIG_CRASH_DUMP
> > > > +	reserve_elfcorehdr();
> > > > +#endif
> > > > +
> > > >   	early_init_fdt_scan_reserved_mem();
> > > >
> > > >   	/* 4GB maximum for 32-bit only capable devices */
> > > > --
> > > > 1.7.9.5
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > > Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/