| Message ID | 20180703061727.8789-10-hegdevasant@linux.vnet.ibm.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | MPIPL support | expand |
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?
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
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.
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 */
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(+)