Re: [PATCH] powerpc/pseries: read the lpar name from the firmware
From: Nathan Lynch <hidden>
Date: 2021-12-01 15:30:40
Also in:
lkml
Laurent Dufour [off-list ref] writes:
The LPAR name may be changed after the LPAR has been started in the HMC. In that case lparstat command is not reporting the updated value because it reads it from the device tree which is read at boot time.
Could lparstat be changed to make the appropriate get-system-parameter call via librtas, avoiding a kernel change?
quoted hunk ↗ jump to hunk
However this value could be read from RTAS. Adding this value in the /proc/powerpc/lparcfg output allows to read the updated value. Signed-off-by: Laurent Dufour <redacted> --- arch/powerpc/platforms/pseries/lparcfg.c | 50 ++++++++++++++++++++++++ 1 file changed, 50 insertions(+)diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c index f71eac74ea92..b597b132ce32 100644 --- a/arch/powerpc/platforms/pseries/lparcfg.c +++ b/arch/powerpc/platforms/pseries/lparcfg.c@@ -311,6 +311,55 @@ static void parse_mpp_x_data(struct seq_file *m) seq_printf(m, "coalesce_pool_spurr=%ld\n", mpp_x_data.pool_spurr_cycles); } +/* + * PAPR defines no maximum for the LPAR name, and defines that the maximum + * length of the get-system-parameter's output buffer is 4000 plus 2 bytes for + * the length. Limit LPAR's name size to 1024 + */ +#define SPLPAR_LPAR_NAME_MAXLEN 1026 +#define SPLPAR_LPAR_NAME_TOKEN 55 +static void parse_lpar_name(struct seq_file *m) +{ + int call_status, len; + unsigned char *local_buffer; + + local_buffer = kmalloc(SPLPAR_LPAR_NAME_MAXLEN, GFP_KERNEL); + if (!local_buffer) { + pr_err("%s %s kmalloc failure at line %d\n", + __FILE__, __func__, __LINE__); + return; + }
No error prints on memory allocation failure, the mm code will do that.
+
+ spin_lock(&rtas_data_buf_lock);
+ memset(rtas_data_buf, 0, RTAS_DATA_BUF_SIZE);
+ call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
+ NULL,
+ SPLPAR_LPAR_NAME_TOKEN,
+ __pa(rtas_data_buf),
+ RTAS_DATA_BUF_SIZE);
+ memcpy(local_buffer, rtas_data_buf, SPLPAR_LPAR_NAME_MAXLEN);
+ spin_unlock(&rtas_data_buf_lock);
+
+ if (call_status != 0) {
+ pr_err("%s %s Error calling get-system-parameter (0x%x)\n",
+ __FILE__, __func__, call_status);If this yields an error then it should fall back to the device tree. ibm,get-system-parameter can return -2 or 990x, which are not errors. Callers of ibm,get-system-parameter must handle these statuses using rtas_busy_delay() or similar, which potentially involves sleeping. Granted this is inconvenient when dealing the rtas_data_buf and rtas_data_buf_lock - you can't call rtas_busy_delay() before you've released the buffer lock. See dlpar_configure_connector() for an example of how this can be structured. It looks like most existing users of ibm,get-system-parameter have this bug, unfortunately.