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. Paolo
