All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Baoquan He <bhe@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org, hbabus@us.ibm.com,
	linaro-kernel@lists.linaro.org, geoff@infradead.org,
	catalin.marinas@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, broonie@kernel.org,
	david.griego@linaro.org, kexec@lists.infradead.org,
	vgoyal@redhat.com
Subject: Re: [v2 1/5] arm64: kdump: reserve memory for crash dump kernel
Date: Mon, 11 May 2015 16:38:57 +0900	[thread overview]
Message-ID: <55505C91.8070503@linaro.org> (raw)
In-Reply-To: <20150428091935.GJ15033@dhcp-16-116.nay.redhat.com>

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.)


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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/

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

WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [v2 1/5] arm64: kdump: reserve memory for crash dump kernel
Date: Mon, 11 May 2015 16:38:57 +0900	[thread overview]
Message-ID: <55505C91.8070503@linaro.org> (raw)
In-Reply-To: <20150428091935.GJ15033@dhcp-16-116.nay.redhat.com>

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.)


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 at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/

WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Baoquan He <bhe@redhat.com>
Cc: catalin.marinas@arm.com, will.deacon@arm.com, vgoyal@redhat.com,
	hbabus@us.ibm.com, geoff@infradead.org, broonie@kernel.org,
	david.griego@linaro.org, kexec@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [v2 1/5] arm64: kdump: reserve memory for crash dump kernel
Date: Mon, 11 May 2015 16:38:57 +0900	[thread overview]
Message-ID: <55505C91.8070503@linaro.org> (raw)
In-Reply-To: <20150428091935.GJ15033@dhcp-16-116.nay.redhat.com>

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.)


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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/

  reply	other threads:[~2015-05-11  7:39 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24  7:53 [v2 0/5] arm64: add kdump support AKASHI Takahiro
2015-04-24  7:53 ` AKASHI Takahiro
2015-04-24  7:53 ` AKASHI Takahiro
2015-04-24  7:53 ` [v2 1/5] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24 10:11   ` Mark Rutland
2015-04-24 10:11     ` Mark Rutland
2015-04-24 10:11     ` Mark Rutland
2015-05-11  6:44     ` AKASHI Takahiro
2015-05-11  6:44       ` AKASHI Takahiro
2015-05-11  6:44       ` AKASHI Takahiro
2015-04-28  9:19   ` Baoquan He
2015-04-28  9:19     ` Baoquan He
2015-04-28  9:19     ` Baoquan He
2015-05-11  7:38     ` AKASHI Takahiro [this message]
2015-05-11  7:38       ` AKASHI Takahiro
2015-05-11  7:38       ` AKASHI Takahiro
2015-05-11  7:54       ` Baoquan He
2015-05-11  7:54         ` Baoquan He
2015-05-11  7:54         ` Baoquan He
2015-05-11  8:17         ` AKASHI Takahiro
2015-05-11  8:17           ` AKASHI Takahiro
2015-05-11  8:17           ` AKASHI Takahiro
2015-05-11  9:41           ` Baoquan He
2015-05-11  9:41             ` Baoquan He
2015-05-11  9:41             ` Baoquan He
2015-05-12  7:32             ` AKASHI Takahiro
2015-05-12  7:32               ` AKASHI Takahiro
2015-05-12  7:32               ` AKASHI Takahiro
2015-04-24  7:53 ` [v2 2/5] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24 10:39   ` Mark Rutland
2015-04-24 10:39     ` Mark Rutland
2015-04-24 10:39     ` Mark Rutland
2015-04-24 10:43     ` Marc Zyngier
2015-04-24 10:43       ` Marc Zyngier
2015-04-24 10:43       ` Marc Zyngier
2015-08-06  7:09       ` AKASHI Takahiro
2015-08-06  7:09         ` AKASHI Takahiro
2015-08-06  7:09         ` AKASHI Takahiro
2015-08-06 15:51         ` Marc Zyngier
2015-08-06 15:51           ` Marc Zyngier
2015-08-06 15:51           ` Marc Zyngier
2015-08-07  4:24           ` AKASHI Takahiro
2015-08-07  4:24             ` AKASHI Takahiro
2015-08-07  4:24             ` AKASHI Takahiro
2015-05-11  7:10     ` AKASHI Takahiro
2015-05-11  7:10       ` AKASHI Takahiro
2015-05-11  7:10       ` AKASHI Takahiro
2015-05-22  5:56       ` AKASHI Takahiro
2015-05-22  5:56         ` AKASHI Takahiro
2015-05-22  5:56         ` AKASHI Takahiro
2015-04-24  7:53 ` [v2 3/5] arm64: kdump: do not go into EL2 before starting a crash dump kernel AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  7:53 ` [v2 4/5] arm64: add kdump support AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-05-08 12:19   ` Dave Young
2015-05-08 12:19     ` Dave Young
2015-05-08 12:19     ` Dave Young
2015-05-11  7:47     ` Dave Young
2015-05-11  7:47       ` Dave Young
2015-05-11  7:47       ` Dave Young
2015-05-11  7:58       ` AKASHI Takahiro
2015-05-11  7:58         ` AKASHI Takahiro
2015-05-11  7:58         ` AKASHI Takahiro
2015-05-11  8:39         ` Dave Young
2015-05-11  8:39           ` Dave Young
2015-05-11  8:39           ` Dave Young
2015-04-24  7:53 ` [v2 5/5] arm64: enable kdump in the arm64 defconfig AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  9:53 ` [v2 0/5] arm64: add kdump support Mark Rutland
2015-04-24  9:53   ` Mark Rutland
2015-04-24  9:53   ` Mark Rutland
2015-05-11  6:16   ` AKASHI Takahiro
2015-05-11  6:16     ` AKASHI Takahiro
2015-05-11  6:16     ` AKASHI Takahiro
2015-05-12  5:43     ` Dave Young
2015-05-12  5:43       ` Dave Young
2015-05-12  5:43       ` Dave Young
2015-05-18  8:08       ` AKASHI Takahiro
2015-05-18  8:08         ` AKASHI Takahiro
2015-05-18  8:08         ` AKASHI Takahiro

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=55505C91.8070503@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=bhe@redhat.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=david.griego@linaro.org \
    --cc=geoff@infradead.org \
    --cc=hbabus@us.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    --cc=will.deacon@arm.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.