[v4,09/18] fadump: Define FADUMP structure

Message ID 20180703061727.8789-10-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.
This structure is shared between OPAL and payload. During fadump registration
payload will use this structure to pass kernel memory reservation details to
OPAL. OPAL will use this structure to fill MDST, MDDT table. After fadump,
OPAL uses MDRT table to fill this structure and passes this to payload via
device tree.

Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
 include/opal-api.h | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

Comments

Stewart Smith Aug. 7, 2018, 4:07 a.m. | #1
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
> This structure is shared between OPAL and payload. During fadump registration
> payload will use this structure to pass kernel memory reservation details to
> OPAL. OPAL will use this structure to fill MDST, MDDT table. After fadump,
> OPAL uses MDRT table to fill this structure and passes this to payload via
> device tree.

We alread yhave the OPAL_(UN)REGISTER_DUMP_REGION calls, which look
really similar to this (and existing kernels support). Why not just use
these calls instead?
Vasant Hegde Aug. 14, 2018, 12:10 p.m. | #2
On 08/07/2018 09:37 AM, Stewart Smith wrote:
> Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>> This structure is shared between OPAL and payload. During fadump registration
>> payload will use this structure to pass kernel memory reservation details to
>> OPAL. OPAL will use this structure to fill MDST, MDDT table. After fadump,
>> OPAL uses MDRT table to fill this structure and passes this to payload via
>> device tree.

Stewart,

> 
> We alread yhave the OPAL_(UN)REGISTER_DUMP_REGION calls, which look
> really similar to this (and existing kernels support). Why not just use
> these calls instead?

Ideally we should have reused existing APIs. But unfortunately these existing 
one doesn't suite
our requirement here.
OPAL_REGISTER_DUMP_REGION : Passes kernel memory to be copied as part of dump. 
But we
don't have a way to pass destination memory details.

In case of MPIPL kernel will reserve destination memory for kernel memory to be 
preserved.
We want to pass below information to OPAL:
   source address / size , destination address

Hence I created separate API. Also unlike OPAL_(UN)REGISTER_DUMP_REGION, here we 
will
use single API for registration,un- registration.

-Vasant
Stewart Smith Sept. 10, 2018, 12:57 a.m. | #3
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
> On 08/07/2018 09:37 AM, Stewart Smith wrote:
>> Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
>>> This structure is shared between OPAL and payload. During fadump registration
>>> payload will use this structure to pass kernel memory reservation details to
>>> OPAL. OPAL will use this structure to fill MDST, MDDT table. After fadump,
>>> OPAL uses MDRT table to fill this structure and passes this to payload via
>>> device tree.
>
> Stewart,
>
>> 
>> We alread yhave the OPAL_(UN)REGISTER_DUMP_REGION calls, which look
>> really similar to this (and existing kernels support). Why not just use
>> these calls instead?
>
> Ideally we should have reused existing APIs. But unfortunately these existing 
> one doesn't suite
> our requirement here.
> OPAL_REGISTER_DUMP_REGION : Passes kernel memory to be copied as part of dump. 
> But we
> don't have a way to pass destination memory details.
>
> In case of MPIPL kernel will reserve destination memory for kernel memory to be 
> preserved.
> We want to pass below information to OPAL:
>    source address / size , destination address
>
> Hence I created separate API. Also unlike OPAL_(UN)REGISTER_DUMP_REGION, here we 
> will
> use single API for registration,un- registration.

Ahh yep, makes sense. We should probably ensure we have good API docs
that explain the difference and why.

Something like "OPAL can help with OS or firmware crash analysis by
saving machine state to be passed to the OS on next boot as a 'crash
dump'. The OPAL_DUMP_(UN)REGISTER calls are for explicitly setting small
amounts of memory (e.g. kernel log buffer) to be collected by an
external entity, typically over a (relatively) slow bus. The second
method is OPAL_FADUMP_ calls, which allow for a "

I do wonder if we could do something like reserve a few MB of memory in
OPAL for what would typically be registered for a sysdump and provide
some support to older kernels purely through a bit of trickery in OPAL
and maybe a bit of a fun time in the petitboot environment.

Patch

diff --git a/include/opal-api.h b/include/opal-api.h
index f766dce9d..e35b621b2 100644
--- a/include/opal-api.h
+++ b/include/opal-api.h
@@ -1312,6 +1312,36 @@  enum {
 	OPAL_PCI_P2P_TARGET	= 1,
 };
 
+/*
+ * FADUMP memory region ID usable by kernel
+ * 0x80 - 0xff -> Payload
+ */
+#define FADUMP_REGION_HOST_START	0x80
+#define FADUMP_REGION_HOST_END		0xff
+
+/*
+ * fadump section details. This structure is shared between OPAL and payload.
+ * During fadump registration payload will use this structure to pass kernel
+ * memory reservation details to OPAL. OPAL will use this structure to fill
+ * MDST, MDDT table. After fadump, OPAL uses MDRT table to fill this structure.
+ * And passes this to payload via device tree.
+ */
+struct fadump_section {
+	u8	source_type;	/* FADUMP_REGION_* */
+	u8	reserved[7];
+	u64	source_addr;
+	u64	source_size;
+	u64	dest_addr;
+	u64	dest_size;
+} __packed;
+
+struct fadump {
+	u16	fadump_section_size;	/* sizeof(struct fadump_section) */
+	u16	section_count;
+	u32	reserved;
+	struct	fadump_section section[];
+};
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __OPAL_API_H */