On Fri, 25 Jan 2019 11:24:37 +0100 Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > On Thu, 24 Jan 2019 21:37:44 -0500 > Eric Farman <farman@xxxxxxxxxxxxx> wrote: > > > On 01/24/2019 09:25 PM, Eric Farman wrote: > > > > > > > > > On 01/21/2019 06:03 AM, Cornelia Huck wrote: > > > > [1] I think these changes are cool. We end up going into (and staying > > > in) state=BUSY if we get cc=0 on the SSCH, rather than in/out as we > > > bumble along. > > > > > > But why can't these be separated out from this patch? It does change > > > the behavior of the state machine, and seem distinct from the addition > > > of the mutex you otherwise add here? At the very least, this behavior > > > change should be documented in the commit since it's otherwise lost in > > > the mutex/EAGAIN stuff. > > That's a very good idea. I'll factor them out into a separate patch. And now that I've factored it out, I noticed some more problems. What we basically need is the following, I think: - The code should not be interrupted while we process the channel program, do the ssch etc. We want the caller to try again later (i.e. return -EAGAIN) - We currently do not want the user space to submit another channel program while the first one is still in flight. As submitting another one is a valid request, however, we should allow this in the future (once we have the code to handle that in place). - With the async interface, we want user space to be able to submit a halt/clear while a start request is still in flight, but not while we're processing a start request with translation etc. We probably want to do -EAGAIN in that case. My idea would be: - The BUSY state denotes "I'm busy processing a request right now, try again". We hold it while processing the cp and doing the ssch and leave it afterwards (i.e., while the start request is processed by the hardware). I/O requests and async requests get -EAGAIN in that state. - A new state (CP_PENDING?) is entered after ssch returned with cc 0 (from the BUSY state). We stay in there as long as no final state for that request has been received and delivered. (This may be final interrupt for that request, a deferred cc, or successful halt/clear.) I/O requests get -EBUSY, async requests are processed. This state can be removed again once we are able to handle more than one outstanding cp. Does that make sense?
