Re: [Qemu-devel] [PATCH v2 2/8] s390x/css: IO instr handler ending control

[Halil Pasic <pasic@linux.vnet.ibm.com>]

On 10/09/2017 10:20 AM, Thomas Huth wrote:
> On 04.10.2017 17:41, Halil Pasic wrote:
>> CSS code needs to tell the IO instruction handlers located in how should
> 
> located in how?
> 

First, thanks for your review!

Wanted to say: in target/s390x/ioinst.c just forgot to copy paste.

>> the emulated instruction be ended. Currently this is done by returning
>> generic (POSIX) error codes, and mapping them to outcomes like condition
>> codes. This makes bugs easy to create and hard to recognise.
>>
>> As a preparation for moving a way form (mis)using generic error codes for
>> flow control let us introduce a struct which tells the instruction
>> handler function how to end the instruction, in a more straight-forward
>> and less ambiguous way.
>>
>> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
>> ---
>>  include/hw/s390x/css.h | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
>> index 0653d3c9be..66916b6546 100644
>> --- a/include/hw/s390x/css.h
>> +++ b/include/hw/s390x/css.h
>> @@ -75,6 +75,18 @@ typedef struct CMBE {
>>      uint32_t reserved[7];
>>  } QEMU_PACKED CMBE;
>>  
>> +/* IO instructions conclude according this */
>> +typedef struct IOInstEnding {
>> +        /*
>> +         * General semantic of cc codes of IO instructions is (brief):
>> +         * 0 -- produced expected result
>> +         * 1 --  status conditions were present or produced alternate result
>> +         * 2 -- ineffective, because busy with previously initiated function
>> +         * 3 -- ineffective, not operational
>> +         */
>> +        int cc;
>> +} IOInstEnding;
> 
> Why do you need a struct for this? Do you plan to extend it later? If
> so, I think you should mention that in the patch description. If not,
> please use a named enum or a "typedef unsigned int IOInstEnding" instead.
> 
>  Thomas

We may, we may not. In the previous version we also had to support
do end a certain instruction with an addressing exception, but this
is going away in patch #3. Honestly I don't expect this being extended.

I have other reasons for the struct. Type safety and clear semantics,
and frankly at least for s390 and linux I don't see any downsides given
what is written in the "zSeries ELF Application Binary Interface Supplement".
Can you please explain to me what is the problem with using this struct, and
what is the benefit switching to a unsigned int?

Regards,
Halil
>