On 3/19/21 12:23 PM, Cornelia Huck wrote:
On Fri, 19 Mar 2021 10:50:09 +0100
Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote:
On 3/19/21 10:09 AM, Janosch Frank wrote:
On 3/18/21 2:26 PM, Pierre Morel wrote:
When waiting for an interrupt we may need to check the cause of
the interrupt depending on the test case.
Let's provide the tests the possibility to check if the last valid
IRQ received is for the expected instruction.
s/instruction/command/?
Right, instruction may not be the optimal wording.
I/O architecture description have some strange (for me) wording, the
best is certainly to stick on this.
Then I will use "the expected function" here.
We're checking for some value in an IO structure, right?
Instruction makes me expect an actual processor instruction.
Is there another word that can be used to describe what we're checking
here? If yes please also add it to the "pending" variable. "pending_fc"
or "pending_scsw_fc" for example.
Pending is used to specify that the instruction has been accepted but
the according function is still pending, i.e. not finished and will stay
pending for a normal operation until the device active bit is set.
So pending is not the right word, what we check here is the function
control, indicating the function the status refers too.
...snip...
* Only report failures.
*/
-int wait_and_check_io_completion(int schid)
+int wait_and_check_io_completion(int schid, uint32_t pending)
Consequently I will change "pending" with "function_ctrl"
Thanks for forcing clarification
I hope Connie will agree with this :)
I'm not quite sure yet :)
I/O wording and operation can be complicated... we basically have:
- various instructions: ssch, hsch, csch
- invoking one of those instructions may initiate a function at the
subchannel
- if an instruction lead to a function being initiated (but not
necessarily actually being performed!), the matching bit is set in
the fctl
- the fctl bits are accumulative (e.g. if you do a hsch on a subchannel
where a start function is still in progress, you'll have both the
start and the halt function indicated) and only cleared after
collecting final status
So, setting the function is a direct consequence of executing an I/O
instruction -- but the interrupt may not be directly related to *all*
of the functions that are indicated (e.g. in the example above, where
we may get an interrupt for the hsch, but none directly for the ssch;
you can also add a csch on top of this; fortunately, we only stack in
the start->halt->clear direction.)
For the real machine but QEMU serialize every I/O instruction so we
never get 2 activities indicated at the same time.
That is something I tried to check with the last 2 patches.
Regarding wording:
Maybe
"if the last valid IRQ received is for the function expected
after executing an instruction or sequence of instructions."
and
int wait_and_check_io_completion(int schid, uint32_t expected_fctl)
?
Yes better.
Thanks for the comments,
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
