Re: [kvm-unit-tests PATCH v1 4/6] s390x: lib: css: add expectations to wait for interrupt

[Cornelia Huck <cohuck@redhat.com>]

On Fri, 19 Mar 2021 10:50:09 +0100
Pierre Morel <pmorel@linux.ibm.com> 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.)

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)

?