qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O ha


From: Farhan Ali
Subject: Re: [qemu-s390x] [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling
Date: Wed, 30 Jan 2019 09:32:50 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0



On 01/30/2019 08:29 AM, Cornelia Huck wrote:
On Tue, 29 Jan 2019 20:39:33 +0100
Halil Pasic <address@hidden> wrote:

On Tue, 29 Jan 2019 10:58:40 +0100
Cornelia Huck <address@hidden> 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:
<address@hidden>).

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]