* Maciej S. Szmigiero (m...@maciej.szmigiero.name) wrote: > From: "Maciej S. Szmigiero" <maciej.szmigi...@oracle.com> > > postcopy_ram_listen_thread() is a free running thread, so it needs to > take BQL around function calls to migration methods requiring BQL. > > qemu_loadvm_state_main() needs BQL held since it ultimately calls > "load_state" SaveVMHandlers. > > migration_incoming_state_destroy() needs BQL held since it ultimately calls > "load_cleanup" SaveVMHandlers. > > Signed-off-by: Maciej S. Szmigiero <maciej.szmigi...@oracle.com> > --- > migration/savevm.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/migration/savevm.c b/migration/savevm.c > index b0b74140daea..0ceea9638cc1 100644 > --- a/migration/savevm.c > +++ b/migration/savevm.c > @@ -2013,7 +2013,9 @@ static void *postcopy_ram_listen_thread(void *opaque) > * in qemu_file, and thus we must be blocking now. > */ > qemu_file_set_blocking(f, true); > + bql_lock(); > load_res = qemu_loadvm_state_main(f, mis); > + bql_unlock();
Doesn't that leave that held for a heck of a long time? That RAM loading has to happen in parallel with the loading of devices doesn't it - especially if one of the devices being loaded touches RAM. (I wish this series had a description in the cover letter!) Dave > /* > * This is tricky, but, mis->from_src_file can change after it > @@ -2073,7 +2075,9 @@ static void *postcopy_ram_listen_thread(void *opaque) > * (If something broke then qemu will have to exit anyway since it's > * got a bad migration state). > */ > + bql_lock(); > migration_incoming_state_destroy(); > + bql_unlock(); > > rcu_unregister_thread(); > mis->have_listen_thread = false; > -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
