On 01/30/2019 08:29 AM, Cornelia Huck wrote:
On Tue, 29 Jan 2019 20:39:33 +0100
Halil Pasic <pasic@xxxxxxxxxxxxx> wrote:
On Tue, 29 Jan 2019 10:58:40 +0100
Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
The problem I see with the let the hardware sort it out is that, for
that to work, we need to juggle multiple translations simultaneously
(or am I wrong?). Doing that does not appear particularly simple to
me.
None in the first stage, at most two in the second stage, I guess.
Expected benefit of the second stage over the first stage? (I see none.)
Making something possible that is allowed by the architecture. Not
really important, though.
I had a chat with Farhan, and he suggested that by 'allowed by
architecture' you mean " You can submit a new request if the subchannel
is pending with primary, but not with secondary state." (from Message-ID:
<20190125152154.05120461.cohuck@xxxxxxxxxx>).
Yes. I might have mixed things up, though.
So I re-read the PoP.
From the description of the start subchannel instruction:
"""
Special Conditions
Condition code 1 is set, and no other action is
taken, when the subchannel is status pending when
START SUBCHANNEL is executed. On some mod-
els, condition code 1 is not set when the subchannel
is status pending with only secondary status; instead,
the status-pending condition is discarded.
Condition code 2 is set, and no other action is
taken, when a start, halt, or clear function is currently
in progress at the subchannel (see “Function Control
(FC)” on page 13).
"""
So I guess you mixed primary and secondary up and wanted to say:
"You can submit a new request if the subchannel
is pending with _secondary_, but not with _primary_ _status_."
But does that really mean architecture allows the subchannel
to accept multiple ssch() instructions so that it ends up processing
two or more channel programs in parallel.
That's not what I meant. The vfio-ccw driver still holds on to one cp,
while a second one could be submitted.
But let's just end discussing this here, and continue with discussing
the reworked state machine, ok? It's not really relevant for going
forward with halt/clear.
+1
I think we should move forward with halt/clear.
Thanks
Farhan
