All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mahesh J. Salgaonkar" <mahesh@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>,
	Amerigo Wang <amwang@redhat.com>, Haren Myneni <hbabu@us.ibm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Kexec-ml <kexec@lists.infradead.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Milton Miller <miltonm@bga.com>,
	linuxppc-dev <linuxppc-dev@ozlabs.org>,
	Randy Dunlap <rdunlap@xenotime.net>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Ananth Narayan <ananth@in.ibm.com>
Subject: Re: [RFC PATCH v5 2/9] fadump: Reserve the memory for firmware assisted dump.
Date: Mon, 28 Nov 2011 11:51:17 +0530	[thread overview]
Message-ID: <4ED3285D.4060100@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111124230213.GC19828@bloggs.ozlabs.ibm.com>

On 11/25/2011 04:32 AM, Paul Mackerras wrote:
> On Tue, Nov 15, 2011 at 08:43:43PM +0530, Mahesh J Salgaonkar wrote:
>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>>
>> Reserve the memory during early boot to preserve CPU state data, HPTE region
>> and RMR region data in case of kernel crash. At the time of crash, powerpc
>> firmware will store CPU state data, HPTE region data and move RMR region
>> data to the reserved memory area.
> 
> What is "RMR"?  I don't see anywhere that you explain this acronym.
> Is it the same as the RMA (real mode area)?
> 

Yes, it is the same as the RMA. I think I will replace all RMR/RMO with RMA.

>> +config FA_DUMP
>> +	bool "Firmware-assisted dump"
> 
> Is this new fadump infrastructure intended to supersede the existing
> phyp dump code?  Does it use the same phyp interfaces as phyp dump?
> If so, you should probably remove the phyp dump code and config option
> as the final patch in your series.
> 
>> +/*
>> + * The RMR region will be saved for later dumping when kernel crashes.
>> + * Set this to RMO size.
>> + */
>> +#define RMR_START	0x0
>> +#define RMR_END		(ppc64_rma_size)
> 
> An explanation of "RMR" here, and what the distinction (if any)
> between RMR and RMA/RMO is, would help future readers.
> 

Will change this to RMA_START and RMA_END

>> +	sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
>> +					&size);
>> +
>> +	if (!sections)
>> +		return 0;
>> +
>> +	num_sections = size / sizeof(struct dump_section);
>> +
>> +	for (i = 0; i < num_sections; i++) {
>> +		switch (sections[i].dump_section) {
>> +		case FADUMP_CPU_STATE_DATA:
>> +			fw_dump.cpu_state_data_size = sections[i].section_size;
>> +			break;
>> +		case FADUMP_HPTE_REGION:
>> +			fw_dump.hpte_region_size = sections[i].section_size;
>> +			break;
> 
> It's generally better to use of_read_number() or of_read_ulong() to
> parse OF properties, rather than using a structure like this.
> 
>> +	/* divide by 20 to get 5% of value */
>> +	size = memblock_end_of_DRAM();
>> +	do_div(size, 20);
> 
> You could just say size = memblock_end_of_DRAM() / 20 here; no need to
> use do_div, since we won't be using this code on 32-bit platforms.
> 
>> +	if (!fw_dump.fadump_supported) {
>> +		printk(KERN_ERR "Firmware-assisted dump is not supported on"
>> +				" this hardware\n");
> 
> This shouldn't be KERN_ERR; it's not an error to boot a kernel with
> fadump configured in on a machine that doesn't have firmware fadump
> support.  I don't think we really need any message, but if we have one
> it should be KERN_INFO at most.
> 
>> +/* Look for fadump= cmdline option. */
>> +static int __init early_fadump_param(char *p)
>> +{
>> +	if (!p)
>> +		return 1;
>> +
>> +	if (p[0] == '1')
>> +		fw_dump.fadump_enabled = 1;
>> +	else if (p[0] == '0')
>> +		fw_dump.fadump_enabled = 0;
> 
> I think it's usual to allow "on" and "off" as values for this kind of
> option.  There might be a handy little helper function to parse this
> sort of thing (but if there is I don't know what it is called).

Will rework on your suggestions. Thanks for the review.

Thanks,
-Mahesh.


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

WARNING: multiple messages have this Message-ID (diff)
From: "Mahesh J. Salgaonkar" <mahesh@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>,
	Amerigo Wang <amwang@redhat.com>,
	Kexec-ml <kexec@lists.infradead.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Milton Miller <miltonm@bga.com>,
	linuxppc-dev <linuxppc-dev@ozlabs.org>,
	Randy Dunlap <rdunlap@xenotime.net>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [RFC PATCH v5 2/9] fadump: Reserve the memory for firmware assisted dump.
Date: Mon, 28 Nov 2011 11:51:17 +0530	[thread overview]
Message-ID: <4ED3285D.4060100@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111124230213.GC19828@bloggs.ozlabs.ibm.com>

On 11/25/2011 04:32 AM, Paul Mackerras wrote:
> On Tue, Nov 15, 2011 at 08:43:43PM +0530, Mahesh J Salgaonkar wrote:
>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>>
>> Reserve the memory during early boot to preserve CPU state data, HPTE region
>> and RMR region data in case of kernel crash. At the time of crash, powerpc
>> firmware will store CPU state data, HPTE region data and move RMR region
>> data to the reserved memory area.
> 
> What is "RMR"?  I don't see anywhere that you explain this acronym.
> Is it the same as the RMA (real mode area)?
> 

Yes, it is the same as the RMA. I think I will replace all RMR/RMO with RMA.

>> +config FA_DUMP
>> +	bool "Firmware-assisted dump"
> 
> Is this new fadump infrastructure intended to supersede the existing
> phyp dump code?  Does it use the same phyp interfaces as phyp dump?
> If so, you should probably remove the phyp dump code and config option
> as the final patch in your series.
> 
>> +/*
>> + * The RMR region will be saved for later dumping when kernel crashes.
>> + * Set this to RMO size.
>> + */
>> +#define RMR_START	0x0
>> +#define RMR_END		(ppc64_rma_size)
> 
> An explanation of "RMR" here, and what the distinction (if any)
> between RMR and RMA/RMO is, would help future readers.
> 

Will change this to RMA_START and RMA_END

>> +	sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
>> +					&size);
>> +
>> +	if (!sections)
>> +		return 0;
>> +
>> +	num_sections = size / sizeof(struct dump_section);
>> +
>> +	for (i = 0; i < num_sections; i++) {
>> +		switch (sections[i].dump_section) {
>> +		case FADUMP_CPU_STATE_DATA:
>> +			fw_dump.cpu_state_data_size = sections[i].section_size;
>> +			break;
>> +		case FADUMP_HPTE_REGION:
>> +			fw_dump.hpte_region_size = sections[i].section_size;
>> +			break;
> 
> It's generally better to use of_read_number() or of_read_ulong() to
> parse OF properties, rather than using a structure like this.
> 
>> +	/* divide by 20 to get 5% of value */
>> +	size = memblock_end_of_DRAM();
>> +	do_div(size, 20);
> 
> You could just say size = memblock_end_of_DRAM() / 20 here; no need to
> use do_div, since we won't be using this code on 32-bit platforms.
> 
>> +	if (!fw_dump.fadump_supported) {
>> +		printk(KERN_ERR "Firmware-assisted dump is not supported on"
>> +				" this hardware\n");
> 
> This shouldn't be KERN_ERR; it's not an error to boot a kernel with
> fadump configured in on a machine that doesn't have firmware fadump
> support.  I don't think we really need any message, but if we have one
> it should be KERN_INFO at most.
> 
>> +/* Look for fadump= cmdline option. */
>> +static int __init early_fadump_param(char *p)
>> +{
>> +	if (!p)
>> +		return 1;
>> +
>> +	if (p[0] == '1')
>> +		fw_dump.fadump_enabled = 1;
>> +	else if (p[0] == '0')
>> +		fw_dump.fadump_enabled = 0;
> 
> I think it's usual to allow "on" and "off" as values for this kind of
> option.  There might be a handy little helper function to parse this
> sort of thing (but if there is I don't know what it is called).

Will rework on your suggestions. Thanks for the review.

Thanks,
-Mahesh.

WARNING: multiple messages have this Message-ID (diff)
From: "Mahesh J. Salgaonkar" <mahesh@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org, kexec@lists.infradead.org
Subject: Re: [RFC PATCH v5 2/9] fadump: Reserve the memory for firmware assisted dump.
Date: Mon, 28 Nov 2011 11:51:17 +0530	[thread overview]
Message-ID: <4ED3285D.4060100@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111124230213.GC19828@bloggs.ozlabs.ibm.com>

On 11/25/2011 04:32 AM, Paul Mackerras wrote:
> On Tue, Nov 15, 2011 at 08:43:43PM +0530, Mahesh J Salgaonkar wrote:
>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>>
>> Reserve the memory during early boot to preserve CPU state data, HPTE region
>> and RMR region data in case of kernel crash. At the time of crash, powerpc
>> firmware will store CPU state data, HPTE region data and move RMR region
>> data to the reserved memory area.
> 
> What is "RMR"?  I don't see anywhere that you explain this acronym.
> Is it the same as the RMA (real mode area)?
> 

Yes, it is the same as the RMA. I think I will replace all RMR/RMO with RMA.

>> +config FA_DUMP
>> +	bool "Firmware-assisted dump"
> 
> Is this new fadump infrastructure intended to supersede the existing
> phyp dump code?  Does it use the same phyp interfaces as phyp dump?
> If so, you should probably remove the phyp dump code and config option
> as the final patch in your series.
> 
>> +/*
>> + * The RMR region will be saved for later dumping when kernel crashes.
>> + * Set this to RMO size.
>> + */
>> +#define RMR_START	0x0
>> +#define RMR_END		(ppc64_rma_size)
> 
> An explanation of "RMR" here, and what the distinction (if any)
> between RMR and RMA/RMO is, would help future readers.
> 

Will change this to RMA_START and RMA_END

>> +	sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
>> +					&size);
>> +
>> +	if (!sections)
>> +		return 0;
>> +
>> +	num_sections = size / sizeof(struct dump_section);
>> +
>> +	for (i = 0; i < num_sections; i++) {
>> +		switch (sections[i].dump_section) {
>> +		case FADUMP_CPU_STATE_DATA:
>> +			fw_dump.cpu_state_data_size = sections[i].section_size;
>> +			break;
>> +		case FADUMP_HPTE_REGION:
>> +			fw_dump.hpte_region_size = sections[i].section_size;
>> +			break;
> 
> It's generally better to use of_read_number() or of_read_ulong() to
> parse OF properties, rather than using a structure like this.
> 
>> +	/* divide by 20 to get 5% of value */
>> +	size = memblock_end_of_DRAM();
>> +	do_div(size, 20);
> 
> You could just say size = memblock_end_of_DRAM() / 20 here; no need to
> use do_div, since we won't be using this code on 32-bit platforms.
> 
>> +	if (!fw_dump.fadump_supported) {
>> +		printk(KERN_ERR "Firmware-assisted dump is not supported on"
>> +				" this hardware\n");
> 
> This shouldn't be KERN_ERR; it's not an error to boot a kernel with
> fadump configured in on a machine that doesn't have firmware fadump
> support.  I don't think we really need any message, but if we have one
> it should be KERN_INFO at most.
> 
>> +/* Look for fadump= cmdline option. */
>> +static int __init early_fadump_param(char *p)
>> +{
>> +	if (!p)
>> +		return 1;
>> +
>> +	if (p[0] == '1')
>> +		fw_dump.fadump_enabled = 1;
>> +	else if (p[0] == '0')
>> +		fw_dump.fadump_enabled = 0;
> 
> I think it's usual to allow "on" and "off" as values for this kind of
> option.  There might be a handy little helper function to parse this
> sort of thing (but if there is I don't know what it is called).

Will rework on your suggestions. Thanks for the review.

Thanks,
-Mahesh.


  reply	other threads:[~2011-11-28  6:22 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-15 15:13 [RFC PATCH v5 0/9] fadump: Firmware-assisted dump support for Powerpc Mahesh J Salgaonkar
2011-11-15 15:13 ` Mahesh J Salgaonkar
2011-11-15 15:13 ` Mahesh J Salgaonkar
2011-11-15 15:13 ` [RFC PATCH v5 1/9] fadump: Add documentation for firmware-assisted dump Mahesh J Salgaonkar
2011-11-15 15:13   ` Mahesh J Salgaonkar
2011-11-15 15:13   ` Mahesh J Salgaonkar
2011-11-24 22:34   ` Paul Mackerras
2011-11-24 22:34     ` Paul Mackerras
2011-11-24 22:34     ` Paul Mackerras
2011-11-25 13:30     ` Mahesh J. Salgaonkar
2011-11-25 13:30       ` Mahesh J. Salgaonkar
2011-12-10  5:02     ` Mahesh Jagannath Salgaonkar
2011-12-10  5:02       ` Mahesh Jagannath Salgaonkar
2011-11-15 15:13 ` [RFC PATCH v5 2/9] fadump: Reserve the memory for firmware assisted dump Mahesh J Salgaonkar
2011-11-15 15:13   ` Mahesh J Salgaonkar
2011-11-15 15:13   ` Mahesh J Salgaonkar
2011-11-24 23:02   ` Paul Mackerras
2011-11-24 23:02     ` Paul Mackerras
2011-11-24 23:02     ` Paul Mackerras
2011-11-28  6:21     ` Mahesh J. Salgaonkar [this message]
2011-11-28  6:21       ` Mahesh J. Salgaonkar
2011-11-28  6:21       ` Mahesh J. Salgaonkar
2011-11-15 15:13 ` [RFC PATCH v5 3/9] fadump: Register " Mahesh J Salgaonkar
2011-11-15 15:13   ` Mahesh J Salgaonkar
2011-11-15 15:13   ` Mahesh J Salgaonkar
2011-11-15 15:13 ` [RFC PATCH v5 4/9] fadump: Initialize elfcore header and add PT_LOAD program headers Mahesh J Salgaonkar
2011-11-15 15:13   ` Mahesh J Salgaonkar
2011-11-15 15:13   ` Mahesh J Salgaonkar
2011-11-15 15:14 ` [RFC PATCH v5 5/9] fadump: Convert firmware-assisted cpu state dump data into elf notes Mahesh J Salgaonkar
2011-11-15 15:14   ` Mahesh J Salgaonkar
2011-11-15 15:14   ` Mahesh J Salgaonkar
2011-11-15 15:14 ` [RFC PATCH v5 6/9] fadump: Add PT_NOTE program header for vmcoreinfo Mahesh J Salgaonkar
2011-11-15 15:14   ` Mahesh J Salgaonkar
2011-11-15 15:14   ` Mahesh J Salgaonkar
2011-11-15 15:14 ` [RFC PATCH v5 7/9] fadump: Introduce cleanup routine to invalidate /proc/vmcore Mahesh J Salgaonkar
2011-11-15 15:14   ` Mahesh J Salgaonkar
2011-11-15 15:14   ` Mahesh J Salgaonkar
2011-11-15 15:14 ` [RFC PATCH v5 8/9] fadump: Invalidate registration and release reserved memory for general use Mahesh J Salgaonkar
2011-11-15 15:14   ` Mahesh J Salgaonkar
2011-11-15 15:14   ` Mahesh J Salgaonkar
2011-11-15 15:14 ` [RFC PATCH v5 9/9] fadump: Invalidate the fadump registration during machine shutdown Mahesh J Salgaonkar
2011-11-15 15:14   ` Mahesh J Salgaonkar
2011-11-15 15:14   ` Mahesh J Salgaonkar
2011-11-21 12:03 ` [RFC PATCH v5 0/9] fadump: Firmware-assisted dump support for Powerpc Cong Wang
2011-11-21 12:03   ` Cong Wang
2011-11-21 12:03   ` Cong Wang

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=4ED3285D.4060100@linux.vnet.ibm.com \
    --to=mahesh@linux.vnet.ibm.com \
    --cc=amwang@redhat.com \
    --cc=ananth@in.ibm.com \
    --cc=anton@samba.org \
    --cc=benh@kernel.crashing.org \
    --cc=ebiederm@xmission.com \
    --cc=hbabu@us.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh.j.salgaonkar@gmail.com \
    --cc=miltonm@bga.com \
    --cc=paulus@samba.org \
    --cc=rdunlap@xenotime.net \
    --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.