> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > On 02/11/2017 12:24, Pavel Dovgalyuk wrote: > >> I am not sure about this. I think if instead you should return false > >> from here and EXCP_INTERRUPT from cpu_exec. > > The problem is inside the TB. It checks cpu->icount_decr.u16.high which is > > -1. > > And we have to enter the TB to cause an exception (because it exists in > > replay log). > > That is why we reset this flag and try to execute the TB. > > But if u16.high is -1, shouldn't you return EXCP_INTERRUPT first (via > "Finally, check if we need to exit to the main loop" in > cpu_handle_interrupt)? Then only cause the exception when that one is > processed.
The case is the following. 1. There are no pending instructions to execute, cpu_loop_exec_tb finished. 2. There are no interrupts and cpu_handle_interrupt sets cpu->exception_index = EXCP_INTERRUPT 3. There are no pending exceptions and cpu_handle_exception goes to the last branch, because there is an exception flag in the log. 4. cpu_exec_nocache translates the block and tries to execute it, causing an exception > > Paolo > > >> More important: there is still a race, because high can be set to -1 > >> right after your atomic_set. > > I'm not sure about it. But even the race exists, exec_nocache attempt will > > be repeated > > after failed try. > > > > Returning true is ok here, because we know that exception will happen > > (because it is > > recorded in the log). Pavel Dovgalyuk
