Laurent Dufour <lduf...@linux.ibm.com> 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?
> 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 <lduf...@linux.ibm.com>
> ---
> 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.
