On 28.10.2021 22:26, Richard Henderson wrote:
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.
Please check the new series, it probably solves the problem described in
that issue.
Pavel Dovgalyuk
