On 18.05.2017 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 ;-)
So Reviewed-by: David Hildenbrand <da...@redhat.com> -- Thanks, David