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

Message ID 20180703061727.8789-11-hegdevasant@linux.vnet.ibm.com
State Superseded
Headers show
Series
  • MPIPL support
Related show

Commit Message

Vasant Hegde July 3, 2018, 6:17 a.m.
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.

Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
 hdata/spira.c | 23 +++++++++++++++++++++++
 hdata/spira.h |  1 +
 2 files changed, 24 insertions(+)

Comments

Stewart Smith Aug. 7, 2018, 5:16 a.m. | #1
Vasant Hegde <hegdevasant@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.

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?

>
> Signed-off-by: Vasant Hegde <hegdevasant@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.

> +	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.
Vasant Hegde Aug. 15, 2018, 12:04 p.m. | #2
On 08/07/2018 10:46 AM, Stewart Smith wrote:
> Vasant Hegde <hegdevasant@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@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

Patch

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");
+	assert(node);
+	dt_add_property_string(node, "compatible", "ibm,opal-dump-v1");
+
+	fw_load_area[0] = (u64)KERNEL_LOAD_BASE;
+	fw_load_area[1] = KERNEL_LOAD_SIZE;
+	fw_load_area[2] = (u64)INITRAMFS_LOAD_BASE;
+	fw_load_area[3] = INITRAMFS_LOAD_SIZE;
+	dt_add_property(node, "fw-load-area", fw_load_area, sizeof(fw_load_area));
+}
+
 static void add_iplparams_sys_params(const void *iplp, struct dt_node *node)
 {
 	const struct iplparams_sysparams *p;
@@ -1117,6 +1136,10 @@  static void add_iplparams_sys_params(const void *iplp, struct dt_node *node)
 	if (sys_attributes & SYS_ATTR_RISK_LEVEL)
 		dt_add_property(node, "elevated-risk-level", NULL, 0);
 
+	/* Populate fadump node */
+	if (sys_attributes & SYS_ATTR_MPIPL_SUPPORTED)
+		fadump_add_node();
+
 	if (version >= 0x60 && proc_gen >= proc_gen_p9)
 		dt_init_secureboot_node(p);
 }
diff --git a/hdata/spira.h b/hdata/spira.h
index ef2aec257..398c1151a 100644
--- a/hdata/spira.h
+++ b/hdata/spira.h
@@ -363,6 +363,7 @@  struct iplparams_sysparams {
 	__be32		sys_eco_mode;
 #define SYS_ATTR_MULTIPLE_TPM PPC_BIT32(0)
 #define SYS_ATTR_RISK_LEVEL PPC_BIT32(3)
+#define SYS_ATTR_MPIPL_SUPPORTED PPC_BIT32(4)
 	__be32		sys_attributes;
 	__be32		mem_scrubbing;
 	__be16		cur_spl_value;