On 18.05.2017 15:20, Aurelien Jarno wrote: > On 2017-05-18 14:59, Thomas Huth wrote: >> On 18.05.2017 14:23, David Hildenbrand wrote: >>> >>>> diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c >>>> index f6e5bce..de0ecd4 100644 >>>> --- a/target/s390x/mem_helper.c >>>> +++ b/target/s390x/mem_helper.c >>>> @@ -20,6 +20,7 @@ >>>> >>>> #include "qemu/osdep.h" >>>> #include "cpu.h" >>>> +#include "exec/address-spaces.h" >>>> #include "exec/helper-proto.h" >>>> #include "exec/exec-all.h" >>>> #include "exec/cpu_ldst.h" >>>> @@ -973,6 +974,33 @@ void HELPER(stctl)(CPUS390XState *env, uint32_t r1, >>>> uint64_t a2, uint32_t r3) >>>> } >>>> } >>>> >>>> +uint32_t HELPER(testblock)(CPUS390XState *env, uint64_t real_addr) >>>> +{ >>>> + CPUState *cs = CPU(s390_env_get_cpu(env)); >>>> + uint64_t abs_addr; >>>> + int i; >>>> + >>> >>> It is somewhat strange that we set a condition code in case of a program >>> interrupt (I assume that's the magic of the return value?). But maybe >>> setting the CC on program interrupts is perfectly valid. >> >> According to the PoP: >> >> "[...] The operation is ter- >> minated on addressing and protection exceptions. If >> termination occurs, the condition code and the con- >> tents of bit positions 32-63 of general register 0 are >> unpredictable in the 24-bit or 31-bit addressing >> mode, or the condition code and bits 0-63 of the reg- >> ister are unpredictable in the 64-bit addressing mode." >> >> So setting CC=1 seems a valid behavior here ;-) > > Actually program_interrupt will never return, so CC is left unchanged in > case of an exception. It's also matches the unpredictable value > described in the PoP ;-).
Ah, right, program_interrupt() calls cpu_loop_exit() which in turn does the longjump ... makes more sense to me now, thanks for the hint! Thomas