On 16/02/2015 14:27, Pavel Dovgaluk wrote:
>> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
>> Bonzini
>> On 16/02/2015 13:26, Pavel Dovgaluk wrote:
>>>>>>> I think in this case there are no events at all - just reading timers
>>>>>>> values
>>>>>>> that were made while recording.
>>>>>>> We have to replay these reads by waking iothread.
>>>>>
>>>>> I think the right place for this is in replay_read_next_clock then.
>>> It doesn't fit. Log file is not read until all instructions are executed.
>>> And the next read from the file should be performed by iothread which should
>>> be notified and waked up.
>>
>> I still don't understand. If you're getting EXCP_INTERRUPT it means:
>>
>> 1) that cpu_signal was called
>
> No, it isn't. That is the branch when icount is expired.
> And when it is expired in replay mode we have to wake up iothread,
> because nobody will care about this.
Then it's done here in qemu_tcg_cpu_thread_fn:
if (use_icount) {
int64_t deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL);
if (deadline == 0) {
qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
}
}
If you need to move the 4 lines inside the if elsewhere, that I guess it's okay.
Paolo
>>
>> 2) in turn this means that qemu_cpu_kick was called
>>
>> 3) in turn this means that the iothread is trying to run via
>> qemu_mutex_lock_iothread (the iothread_requesting_mutex stuff). So why
>> do you need an explicit qemu_notify_event?
>
> Pavel Dovgalyuk
>
>
>
