* Amit Shah (address@hidden) wrote:
From: "Denis V. Lunev" <address@hidden>
There is a possibility to hit an assert in qcow2_get_specific_info that
s->qcow_version is undefined. This happens when VM in starting from
suspended state, i.e. it processes incoming migration, and in the same
time 'info block' is called.
The problem is that qcow2_invalidate_cache() closes the image and
memset()s BDRVQcowState in the middle.
The patch moves processing of bdrv_invalidate_cache_all out of
coroutine context for postcopy migration to avoid that. This function
is called with the following stack:
process_incoming_migration_co
qemu_loadvm_state
qemu_loadvm_state_main
loadvm_process_command
loadvm_postcopy_handle_run
Signed-off-by: Denis V. Lunev <address@hidden>
Tested-by: Dr. David Alan Gilbert <address@hidden>
hmm; actually - this segs in a variety of different ways;
there are two problems:
a) + bh = qemu_bh_new(loadvm_postcopy_handle_run_bh, NULL);
That's the easy one; that NULL should be 'mis', because
the bh is expecting to use it as a MigrationIncomingState
so it segs fairly reliably in the qemu_bh_delete(mis->bh)
b) The harder problem is that there's a race where qemu_bh_delete
segs, and I'm not 100% sure why yet - it only does it sometime
(i.e. run virt-test and leave it and it occasionally does it).
From the core it looks like qemu->bh is corrupt (0x10101010...)
so maybe mis has been freed at that point?
I'm suspecting this is the postcopy_ram_listen_thread freeing
mis at the end of it, but I don't know yet.
Dave
1.diff