qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/3] replay: introduce block devices record/repl


From: Pavel Dovgalyuk
Subject: Re: [Qemu-devel] [PATCH 3/3] replay: introduce block devices record/replay
Date: Thu, 18 Feb 2016 12:18:54 +0300

> From: Kevin Wolf [mailto:address@hidden
> Am 16.02.2016 um 12:20 hat Pavel Dovgalyuk geschrieben:
> > Coroutine                                                         Replay
> > bool *done = req_replayed_list_get(reqid) // NULL
> >                                                                   co =
> req_completed_list_get(e.reqid); // NULL
> 
> There was no yield, this context switch is impossible to happen. Same
> for the switch back.
> 
> > req_completed_list_insert(reqid, qemu_coroutine_self());
> > qemu_coroutine_yield();
> 
> This is the point at which a context switch happens. The only other
> point in my code is the qemu_coroutine_enter() in the other function.

I've fixed aio_poll problem by disabling mutex lock for the 
replay_run_block_event()
execution. Now virtual machine deterministically runs 4e8 instructions of 
Windows XP booting.

But then one non-deterministic event happens.
Callback after finishing coroutine may be called from different contexts.
apic_update_irq() function behaves differently being called from vcpu and io 
threads.
In one case it sets CPU_INTERRUPT_POLL and in other - nothing happens.

Therefore execution becomes non-deterministic.
In previous version of the patch I solved this problem by linking block events 
to the
execution checkpoints. IO thread have its own checkpoints and vcpu - its own.
Therefore apic callbacks are always called from the same thread in replay as in 
recording phase.

Pavel Dovgalyuk




reply via email to

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