[Skiboot] [PATCH 2/7] opal-msg: Add get_opal_msg2

[Mahesh Jagannath Salgaonkar]

On 3/28/19 4:48 PM, Vasant Hegde wrote:
> Linux uses get_opal_msg (GET_OPAL_MSG) API to get OPAL messages. This interface
> supports upto 8 params (64 bytes). Also OPAL doesn't return actual message.
> 
> We have a requirement to send bigger data to Linux. Hence this patch introduces
> new API - GET_OPAL_MSG2.
> 
> - get_opal_msg2(uint64_t *buffer, uint64_t *size)
>   Linux will allocate and send buffer and buffer size to OPAL.
>   OPAL copies opal_msg to buffer and updates size with actual message size.
> 
> - Replaced `reserved` feild in "struct opal_msg" with `size`. So that Linux
>   side get_opal_msg2 user can detect message data size. We don't need to
>   change existing opal message notifier in Linux.
> 
> - This patch introduces new variable (opal_msg2_supported) to detect whether
>   Linux supports new API or not. So that we can support both get_opal_msg
>   and get_opal_msg2 (like new petitboot kernel and old host linux kernel).
> 
> - We will queue opal message with > 64 bytes of data, only if Linux supports
>   new API.
> 
> - Add new internal function (opal_queue_msg_extended()) to queue opal_msg with
>   bigger data.
> 
> Signed-off-by: Vasant Hegde <hegdevasant at linux.vnet.ibm.com>
> ---
>  core/opal-msg.c                    | 91 +++++++++++++++++++++++++++++++++-----
>  doc/opal-api/opal-get-msg2-170.rst | 30 +++++++++++++
>  include/opal-api.h                 |  5 ++-
>  include/opal-msg.h                 |  8 ++++
>  4 files changed, 120 insertions(+), 14 deletions(-)
>  create mode 100644 doc/opal-api/opal-get-msg2-170.rst
> 
> diff --git a/core/opal-msg.c b/core/opal-msg.c
> index 19714670e..98489c28b 100644
> --- a/core/opal-msg.c
> +++ b/core/opal-msg.c
[..]> +static int __opal_queue_msg(enum opal_msg_type msg_type, void *data,
> +			    void (*consumed)(void *data), size_t params_size,
> +			    const void *params)
>  {
>  	struct opal_msg_entry *entry;
> 
> +	/* Check whether opal_get_msg2 is supported by kernel */
> +	if (!opal_msg2_supported &&
> +	    params_size > OPAL_MSG_FIXED_PARAMS_SIZE) {
> +		prerror("Discarding extra parameters\n");
> +		params_size = OPAL_MSG_FIXED_PARAMS_SIZE;
> +	}
> +
> +	if ((params_size + offsetof(struct opal_msg, params)) > OPAL_MSG_SIZE) {
> +		prlog(PR_DEBUG, "Message size (0x%x) > opal-msg-size (0x%x)\n",
> +		      (u32)params_size, (u32)OPAL_MSG_SIZE);
> +		return OPAL_PARAMETER;
> +	}
> +
[...]> +
> +static int64_t opal_get_msg2(uint64_t *buffer, uint64_t *size)
> +{
> +	opal_msg2_supported = true;

Would it be possible that opal may try to queue up an extended message
before linux makes its first call to opal_get_msg2 ? Linux calls
opal_get_msg only when there is a OPAL_EVENT_MSG_PENDING event surfaces
to linux. OR Are we ok with that rare case ?

> +	return __opal_get_msg(buffer, size);
> +}
> +opal_call(OPAL_GET_MSG2, opal_get_msg2, 2);

Rest looks good to me.

Thanks,
-Mahesh.