[Skiboot] [PATCH v4 10/18] hdata: Create ibm,dump DT node

Vasant Hegde hegdevasant at linux.vnet.ibm.com
Wed Aug 15 22:04:27 AEST 2018


On 08/07/2018 10:46 AM, Stewart Smith wrote:
> Vasant Hegde <hegdevasant at linux.vnet.ibm.com> writes:
>> We use MPIPL system parameter to detect whether MPIPL is supported or not.
>> If its supported create new device tree node (/ibm,dump) to pass all dump
>> related information to kernel. This patch creates new node and populates
>> below properties:
>>    - compatible   - ibm,dump version
>>    - fw-load-area - Memory used by OPAL to load kernel/initrd from PNOR
>>                     (KERNEL_LOAD_BASE & INITRAMFS_LOAD_BASE)
>>                     This is the temporary memory used by OPAL during boot.
>> 		   Later Linux kernel is free to use this memory. We will
>> 		   pass this information to Linux. If Linux kernel is using
>> 		   these memory it will take necessary steps to make sure
>> 		   OPAL stomping these memory doesn't impact kernel
>> 		   dump.
> 
> Thinking through this a bit, I don't think we can completely accurately
> tell the kernel this, as if we've done something like a firmware update
> followed by a dump we *could* (depending on BMC implementation) end up
> getting a different PAYLOAD than we originally booted with, using a
> different amount of memory.

This is not for PAYLOAD itself. Instead this is the memory used by OPAL to copy 
petitboot
kernel and initrd from BMC. OPAL uses during load time. After that we release 
this memory
so that kernel can make use of this memory.

> 
> If the aim is to have the kernel not have any memory in this range
> needing to be dumped, wouldn't we have that knowledge in firmware and be
> able to work around it for the kernel?
Here aim is to inform kernel that during MPIPL boot (second boot) OPAL is going 
to use
this memory. So if kernel used this memory area, it should allocate destination 
memory
to copy the content during MPIPL boot and pass detail to OPAL.

We can workaround in OPAL like below :
  1 - reserve these memory so that kernel won't touch.. We unnecessarily endup 
wasting
memory without good reason.
  2 - Let OPAL reserve destination memory -- it violates layering as OPAL takes 
care of
reservation for kernel used memory. Further at boot time we are not sure whether 
kernel is
booted with FADUMP config or not.

So I think its better we just send information to kernel and let kernel take 
care of it.



>>
>> Signed-off-by: Vasant Hegde <hegdevasant at linux.vnet.ibm.com>
>> ---
>>   hdata/spira.c | 23 +++++++++++++++++++++++
>>   hdata/spira.h |  1 +
>>   2 files changed, 24 insertions(+)
>>
>> diff --git a/hdata/spira.c b/hdata/spira.c
>> index 9d968fbcb..82928af53 100644
>> --- a/hdata/spira.c
>> +++ b/hdata/spira.c
>> @@ -1030,6 +1030,25 @@ static void dt_init_secureboot_node(const struct iplparams_sysparams *sysparams)
>>   	dt_add_property_cells(node, "hw-key-hash-size", hw_key_hash_size);
>>   }
>>
>> +static void fadump_add_node(void)
>> +{
>> +	u64 fw_load_area[4];
>> +	struct dt_node *node;
>> +
>> +	if (proc_gen < proc_gen_p9)
>> +		return;
>> +
>> +	node = dt_new(dt_root, "ibm,dump");
> 
> This should probably come under /ibm,opal/ rather than root.

Ok . I will move this under "ibm,opal" node.

> 
>> +	assert(node);
>> +	dt_add_property_string(node, "compatible", "ibm,opal-dump-v1");
> 
> We can probably leave off the 'v1' as it's going to be implied.
> 

Sure. Will fix in v5.

-Vasant



More information about the Skiboot mailing list