qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v8 08/21] cpu: replay instructions sequence


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH v8 08/21] cpu: replay instructions sequence
Date: Mon, 16 Feb 2015 14:31:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0


On 16/02/2015 14:27, Pavel Dovgaluk wrote:
>> From: Paolo Bonzini [mailto:address@hidden 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
> 
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]