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

[Pierre Morel <pmorel@linux.ibm.com>]

On 3/19/21 12:23 PM, Cornelia Huck wrote:
> 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.)

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