[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] target/s390x: Add support for the TEST BLOCK
From: |
Thomas Huth |
Subject: |
Re: [Qemu-devel] [PATCH v2] target/s390x: Add support for the TEST BLOCK instruction |
Date: |
Thu, 18 May 2017 15:30:06 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 |
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