From:   Nathan Lynch <nathanl@linux.ibm.com>
To:     Laurent Dufour <ldufour@linux.ibm.com>,
        linuxppc-dev@lists.ozlabs.org
Cc:     linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/pseries: read the lpar name from the firmware
In-Reply-To: <20211201144826.45342-1-ldufour@linux.ibm.com>
References: <20211201144826.45342-1-ldufour@linux.ibm.com>
Date:   Wed, 01 Dec 2021 09:30:29 -0600
Message-ID: <87h7bsny0a.fsf@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Laurent Dufour <ldufour@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 <ldufour@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.