Re: [PATCH v2 1/2] linux-user/s390x: signal with SIGFPE on compare-and-trap

["jonathan.albrecht" <jonathan.albrecht@linux.vnet.ibm.com>]

On 2021-07-08 1:08 pm, Richard Henderson wrote:
> On 7/7/21 6:42 AM, Jonathan Albrecht wrote:
>> +                sig = TARGET_SIGFPE;
>> +                if ((n & 0x03) == 0) {
>> +                    /* An IEEE exception, simulated or otherwise. */
>>                       if (n & 0x80) {
>>                           n = TARGET_FPE_FLTINV;
>>                       } else if (n & 0x40) {
>> @@ -121,13 +123,12 @@ void cpu_loop(CPUS390XState *env)
>>                           n = TARGET_FPE_FLTUND;
>>                       } else if (n & 0x08) {
>>                           n = TARGET_FPE_FLTRES;
>> -                    } else {
>> -                        /* ??? Quantum exception; BFP, DFP error.  */
>> -                        goto do_sigill_opn;
>>                       }
>> -                    sig = TARGET_SIGFPE;
>> -                    goto do_signal_pc;
>> +                } else {
>> +                    /* compare-and-trap */
>> +                    n = 0;
>>                   }
> 
Thanks for the review. I should have a v3 ready shortly.

> Nearly, but not quite.  Replace the ??? Quantum exception with n = 0,
> otherwise si_code will be garbage for that case.
> 
Thx I'll fix that.

> The structure of the kernel code is
> 
>   if (n != 0) {
>     /* do_fp_trap */
>     si_code = 0;
>     if ((n & 3) == 0) {
>       /* select on bits 6 & 7 */
>     }
>     raise sigfpe w/ si_code
>   } else {
>     raise sigill
>   }
> 
> The comment for compare-and-trap is misleading, because there are lots
> of entries in "Figure 6-2. Data-exception codes (DXC)" which arrive
> there and are not compare-and-trap.
> 
I'll make the comment less specific.

> As a general comment, I think a single switch over DXC would be
> cleaner for both kernel and qemu.  It seems like giving different
> si_code for e.g. "0x40 IEEE division by zero" and "0x43 Simulated IEEE
> division by zero" is actively incorrect.
> 
I went over the DXC section and I see what you mean about the si_codes
for simulated IEEE exceptions. I'll plan on handling those the same as
non-simulated IEEE if no objections. Otherwise all non-IEEE will have
si_code == 0 except DXC == 0x00 will still goto do_sigill_opn.

> 
> r~