On 10/28/2015 01:11 PM, Juan Quintela wrote:
"Denis V. Lunev" <d...@openvz.org> wrote:
aio_context should be locked in the similar way as was done in QMP
snapshot creation in the other case there are a lot of possible
troubles if native AIO mode is enabled for disk.
- the command can hang (HMP thread) with missed wakeup (the operation is
actually complete)
io_submit
ioq_submit
laio_submit
raw_aio_submit
raw_aio_readv
bdrv_co_io_em
bdrv_co_readv_em
bdrv_aligned_preadv
bdrv_co_do_preadv
bdrv_co_do_readv
bdrv_co_readv
qcow2_co_readv
bdrv_aligned_preadv
bdrv_co_do_pwritev
bdrv_rw_co_entry
- QEMU can assert in coroutine re-enter
__GI_abort
qemu_coroutine_enter
bdrv_co_io_em_complete
qemu_laio_process_completion
qemu_laio_completion_bh
aio_bh_poll
aio_dispatch
aio_poll
iothread_run
AioContext lock is reqursive. Thus nested locking should not be a problem.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Stefan Hajnoczi <stefa...@redhat.com>
CC: Paolo Bonzini <pbonz...@redhat.com>
CC: Juan Quintela <quint...@redhat.com>
CC: Amit Shah <amit.s...@redhat.com>
---
block/snapshot.c | 5 +++++
migration/savevm.c | 7 +++++++
2 files changed, 12 insertions(+)
Reviewed-by: Juan Quintela <quint...@redhat.com>
But once there, I can't understand why migration have to know about
aio_contexts at all.
I *think* that it would be a good idea to "hide" the
adi_context_acquire(aio_context) inside qemu_fopen_bdrv() (yes, it is
still in migration/*, but you get the idea). But don't propose it,
because we don't have qemu_fclose_bdrv(). Yes we could add an
aio_context inside QemuFile, and release it on qemu_fclose(), but I
guess this needs more thought yet.
BTW, once that I got your attention, why is this needed on hmp_savevm()
but it is not needed on load_vmstate()? We are also using
qemu_fopen_bdrv()? Because we are only reading from there? Just curios
the reason or if we are missing something there.
Thanks, Juan.
I think that the race is still there (I have checked this several times
but less
amount of times then create/delete snapshot) but the windows is seriously
reduced due to bdrv_drain_all at the beginning.
In general your are right. But in this case we are almost doomed. Any single
read/write operation could executed in iothread only. May be I have missed
something in this puzzle.
OK. What about bdrv_fclose callback and similar (new) callback for open
which should be called through qemu_fopen_bdrv for block driver only?
Den
