[Skiboot] [PATCH v8 22/24] MPIPL: Reserve memory to capture architected registers data

Vasant Hegde hegdevasant at linux.vnet.ibm.com
Tue Jul 9 16:08:49 AEST 2019


On 07/05/2019 10:39 AM, Oliver O'Halloran wrote:
> On Sun, 2019-06-16 at 22:40 +0530, Vasant Hegde wrote:
>> - Split SPIRAH memory to accommodate architected register ntuple.
>>    Today we have 1K memory for SPIRAH and it uses 288 bytes. Lets split
>>    this into two parts :
>>      SPIRAH (756 bytes)
>>      architected register memory (256 bytes)
>>
>> - Update SPIRAH architected register ntuple
>>
>> - Calculate memory required to capture architected registers data
>>    Ideally we should use HDAT provided data (proc_dump_area->thread_size).
>>    But we are not getting this data during boot. Hence lets reserve fixed
>>    memory for architected registers data collection. This is sufficient
>>    for 2 socket system. In future, if we support bigger system then we
>>    have to adjust this size.
>>
>> - Add architected registers destination memory to reserve-memory DT node.
>>
>> Signed-off-by: Vasant Hegde <hegdevasant at linux.vnet.ibm.com>
>> ---
>>   core/opal-dump.c  | 30 ++++++++++++++++++++++++++++++
>>   hdata/spira.c     |  7 +++++++
>>   include/mem-map.h | 14 +++++++++++++-
>>   skiboot.lds.S     |  5 +++++
>>   4 files changed, 55 insertions(+), 1 deletion(-)
>>
>> diff --git a/core/opal-dump.c b/core/opal-dump.c
>> index 555908114..88b18f857 100644
>> --- a/core/opal-dump.c
>> +++ b/core/opal-dump.c
>> @@ -16,6 +16,7 @@
>>   
>>   #define pr_fmt(fmt)	"DUMP: " fmt
>>   
>> +#include <chip.h>
>>   #include <cpu.h>
>>   #include <device.h>
>>   #include <mem-map.h>
>> @@ -31,9 +32,18 @@
>>   
>>   #include "hdata/spira.h"
> 
>> +/* XXX Ideally we should use HDAT provided data (proc_dump_area->thread_size).
>> + *     But we are not getting this data durig boot. Hence lets reserve fixed
>> + *     memory for architected registers data collection. This is sufficient
>> + *     for 2 socket system. In future, if we support bigger system then we
>> + *     have to adjust this size.
>> + */
>> +#define ARCH_REGS_DATA_SIZE		0x100000
> 
> We'll have to fix that at some point. Add a check somewhere to see if
> proc_dump_area->thread_size is non-zero. If it is then we should print
> a warning to say we're ignoring it so it doesn't fall through the
> cracks.

Sure. Will fix it.

> 
>>   /* Actual address of MDST and MDDT table */
>>   #define MDST_TABLE_BASE		(SKIBOOT_BASE + MDST_TABLE_OFF)
>>   #define MDDT_TABLE_BASE		(SKIBOOT_BASE + MDDT_TABLE_OFF)
>> +#define PROC_DUMP_AREA_BASE	(SKIBOOT_BASE + PROC_DUMP_AREA_OFF)
>>   
>>   static struct spira_ntuple *ntuple_mdst;
>>   static struct spira_ntuple *ntuple_mddt;
>> @@ -213,6 +223,8 @@ static int opal_mpipl_remove_entry_mddt(bool remove_all, u8 region, u64 dest)
>>   static void opal_mpipl_register(void)
>>   {
>>   	u64 opal_dest, opal_size;
>> +	u64 arch_regs_dest, arch_regs_size;
>> +	struct proc_dump_area *proc_dump = (void *)(PROC_DUMP_AREA_BASE);
>>   
>>   	/* Get OPAL runtime size */
>>   	if (!dt_find_property(opal_node, "opal-runtime-size")) {
>> @@ -229,6 +241,24 @@ static void opal_mpipl_register(void)
>>   	opal_dest = SKIBOOT_BASE + opal_size;
>>   	mem_reserve_fw("ibm,firmware-dump", opal_dest, opal_size);
> 
>> +	/* Calculate memory to capture CPU register data */
>> +	arch_regs_dest = opal_dest + opal_size;
>> +	arch_regs_size = ARCH_REGS_DATA_SIZE;
>> +
>> +	if (nr_chips() > 2 ) {
>> +		prlog(PR_ERR, "NOT SUPPORTED ON > 2 SOCKET SYSTEM\n");
>> +		prlog(PR_ERR, "INCREASE ARCHITECTED REGISTERS RESERVED MEMORY SIZE\n");
>> +		assert(false);
>> +	}
> 
> We have people using OPAL on four socket systems in the lab. I don't
> think we've ever shipped it to customers, but it's still something that
> we (as in the OPAL team) support. If the system can't do mpipl then
> that's fine, just disable the feature and keep booting.

Yeah. I think I can improve this little bit. Rather than hardcoding for 2 socket
I can get NR_CHIPS and allocate memory. Will fix it in v9.

Thanks!

-Vasant



More information about the Skiboot mailing list