Messages in this thread | | | Date | Tue, 17 Jan 2023 13:21:13 -0600 | From | Alex Elder <> | Subject | Re: [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
| |