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

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

> From: Pavel Dovgalyuk [mailto:dovgaluk@ispras.ru]
> > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > 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.

Kevin, do you have some ideas how to fix this issue?
This happens because of coroutines may be assigned to different threads.
Maybe there is some way of making this assignment more deterministic?

> 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