Re: [Qemu-devel] [RFC PATCH v1 8/9] cpus: don't credit executed instructions before they have run

["Pavel Dovgalyuk" <dovgaluk@ispras.ru>]

> From: mttcg-request@listserver.greensocs.com [mailto:mttcg-request@listserver.greensocs.com]
> On 04/04/2017 07:37, Pavel Dovgalyuk wrote:
> >> -        icount -= (cpu->icount_decr.u16.low + cpu->icount_extra);
> >> +        /* Take into account what has run */
> >> +        icount += cpu_get_icount_executed(cpu);
> >>      }
> >>      return icount;
> > As far, as I understand, this one will return the same value in iothread
> > until vCPU thread finishes cpu_exec?
> > This value will not jump forward and backward, but still will not allow
> > making execution deterministic.
> >
> > Consider the following scenarios:
> >
> > First:
> > vCPU            iothread
> > access HW       ----
> > ...             access HW in timer
> >
> > Second:
> > vCPU            iothread
> > ...             access HW in timer
> > access HW       ----
> >
> > These scenarios will generate the same order of events in the log.
> > Synchronization checkpoint in iothread will try to write already
> > executed instructions, but it does not have access to current_cpu
> > and the icount value will point to the "past" - it will have less
> > instructions than already executed.
> 
> The actual access should be covered by a lock, but I think you're right
> that the two threads can be nondeterministically off by one instruction,
> even if we make gen_io_start update timers_state.qemu_icount atomically.

Yes. The actual problem is that icount is updated once for the whole TB.
But TB execution is not atomic and machine state is different in different
parts of TB.

Therefore iothread may expose different behavior depending on moment
when it is activated.

Pavel Dovgalyuk