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 ;-). -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net