Re: [PATCH v2] cxl/mbox: Add background cmd handling machinery

[Dan Williams <dan.j.williams@intel.com>]

Davidlohr Bueso wrote:
> It at least removes one point of potential disambiguity. This out of sync
> issue with timeouts was one of the reasons I originally proposed dealing
> with all bg commands asynchronously (which doesn't prevent users from still
> time-slicing). This approach is supposed to make the code simpler, but leaves
> this mess. Currently we state:
> 
> 	 * In the event of timeout, the mailbox state is
> 	 * indeterminate until the next successful command submission and the
> 	 * driver can get back in sync with the hardware state.

Right, but my struggle is how to explain to userspace what to do next.
Does userspace keep submitting until it gets a successful acceptance?
How does userspace know that its failure is induced by background
command collision?

That's why I think it is ok to block and wait on the previous background
command completion when the next command is submitted. That seems to satisfy
least surprise. The submitter asked for the last command to end in
failure and is asking for the next one to queue up and complete.

I think this means that cxl_mbox_background_complete() needs to be called
before every submission and needs to check for "background operation"
(mailbox status bit0) being cleared to manage potential collisions.