> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> On 31/10/2017 12:26, Pavel Dovgalyuk wrote:
> > This patch resets icount_decr.u32.high before calling cpu_exec_nocache
> > when exception is pending. Exception is caused by the first instruction
> > in the block and it cannot be executed without resetting the flag.
> >
> > Signed-off-by: Maria Klimushenkova <maria.klimushenk...@ispras.ru>
> > Signed-off-by: Pavel Dovgalyuk <pavel.dovga...@ispras.ru>
> >
> > ---
> >  accel/tcg/cpu-exec.c |    1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
> > index 35d0240..aaa9c2d 100644
> > --- a/accel/tcg/cpu-exec.c
> > +++ b/accel/tcg/cpu-exec.c
> > @@ -500,6 +500,7 @@ static inline bool cpu_handle_exception(CPUState *cpu, 
> > int *ret)
> >      } else if (replay_has_exception()
> >                 && cpu->icount_decr.u16.low + cpu->icount_extra == 0) {
> >          /* try to cause an exception pending in the log */
> > +        atomic_set(&cpu->icount_decr.u16.high, 0);
> >          cpu_exec_nocache(cpu, 1, tb_find(cpu, NULL, 0, curr_cflags()), 
> > true);
> >          *ret = -1;
> >          return true;
> >
> 
> 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.

> 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


Reply via email to