lkml.org 
[lkml]   [2023]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v8 09/28] mailbox: Add Gunyah message queue mailbox
On 1/10/23 12:16 PM, Elliot Berman wrote:
>>> +    ret = gh_hypercall_msgq_send(msgq->tx_ghrsc->capid,
>>> msgq_data->length,
>>> +                    (uintptr_t)msgq_data->data, tx_flags, &ready);
>>> +
>>> +    /**
>>> +     * unlikely because Linux tracks state of msgq and should not
>>> try to
>>> +     * send message when msgq is full.
>>> +     */
>>
>> Is it just unlikely, or is it impossible?
>>
>
> This would require multiple mailbox controllers interacting with the
> same message queue.
>
> The only way I can think this is possible is if the Gunyah drivers are
> unloaded when the message queue is full; drivers are then re-loaded
> before the receiver processes the messages. The initial internal state
> of the message queue controller assumes that there is space in the
> message queue. We would get a Tx vIRQ once space becomes available and
> the message would then be attempted to sent again. Since there's a safe
> flow to recover from a inconsistent internal state and it's very
> unlikely to start in that state, I don't think we need to add calls to
> check if the message queue is full during initialization.

First, your explanation is appreciated but more than what I
was looking for... I just mentioned it because if it were
impossible, then there's no point in having this code handle
something that literally can't happen.

But as far as your explanation, I *hope* if the Gunyah drivers
are unloaded, everything gets fully cleaned up before that
completes. There should be no in-flight activity, or
any "previous generation" messages that could be processed.

In any case, I think my question is answered. Thanks.

-Alex

\
 
 \ /
  Last update: 2023-03-26 23:44    [W:0.083 / U:0.892 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site