On 30.09.19 18:15, Richard Henderson wrote:
> On 9/30/19 8:42 AM, David Hildenbrand wrote:
>>> Of course, but it's no different with this case than any other. If the
>>> interrupt has already been handled, then we will simply restart the next TB
>>> as
>>> per normal.
>> Yeah, I was mostly concer
On 9/30/19 8:42 AM, David Hildenbrand wrote:
>> Of course, but it's no different with this case than any other. If the
>> interrupt has already been handled, then we will simply restart the next TB
>> as
>> per normal.
> Yeah, I was mostly concerned that "the next TB" will be "the next
> instruct
On 30.09.19 17:03, Richard Henderson wrote:
> On 9/30/19 12:55 AM, David Hildenbrand wrote:
>>> What I think you should do instead is check env_neg(env)->icount_decr,
>>> exactly
>>> like we do at the start of every basic block, and use that as an indication
>>> that you should exit back to the ma
On 9/30/19 12:55 AM, David Hildenbrand wrote:
>> What I think you should do instead is check env_neg(env)->icount_decr,
>> exactly
>> like we do at the start of every basic block, and use that as an indication
>> that you should exit back to the main loop.
>
> The issue is that when we return to
On 27.09.19 18:02, Richard Henderson wrote:
> On 9/27/19 3:30 AM, David Hildenbrand wrote:
>>> +/* Update ILEN, except for breakpoint, where we didn't load an insn.
>>> */
>>> +if (ilen) {
>>> +env->int_pgm_ilen = ilen;
>>> +}
>>
>> I am not completely sure about breakpoint ha
On 9/27/19 3:30 AM, David Hildenbrand wrote:
>> +/* Update ILEN, except for breakpoint, where we didn't load an insn. */
>> +if (ilen) {
>> +env->int_pgm_ilen = ilen;
>> +}
>
> I am not completely sure about breakpoint handling and which
> implications we'll have when not sett
On 26.09.19 18:25, Richard Henderson wrote:
> From: Richard Henderson
>
> Use ILEN_UNWIND to signal that we have in fact that
> cpu_restore_state will have been called by the time
> we arrive in do_program_interrupt.
>
> Signed-off-by: Richard Henderson
> ---
> target/s390x/cpu.h | 4 ++
