Re: [PATCH 4/4] icount: preserve cflags when custom tb is about to execute

[Richard Henderson]

On 10/28/21 4:48 AM, Pavel Dovgalyuk wrote:
> +        if (cpu->cflags_next_tb == -1
> +            && (!use_icount || !(tb->cflags & CF_USE_ICOUNT)
> +                || cpu_neg(cpu)->icount_decr.u16.low >= tb->icount)) {
> +            /*
> +             * icount is disabled or there are enough instructions
> +             * in the budget, do not retranslate this block with
> +             * different parameters.
> +             */
> +            cpu->cflags_next_tb = tb->cflags;
> +        }

I can't see that this will work.

We've been asked to exit to the main loop; probably for an interrupt.  The next thing 
that's likely to happen is that cpu_cc->do_interrupt will adjust cpu state to continue in 
the guest interrupt handler.  The cflags_next_tb flag that you're setting up is not 
relevant to that context.

This seems related to Phil's reported problem

  https://gitlab.com/qemu-project/qemu/-/issues/245

in which an interrupt arrives before we finish processing the watchpoint.

I *think* we need to make cflags_next_tb != -1 be treated like any other interrupt disable 
bit, and delay delivery of the interrupt.  Which also means that we should not check for 
exit_tb at the beginning of any TB we generate for the watchpoint step.

I simply haven't taken the time to investigate this properly.


r~