> I'm surprised at how many separate hangs we actually had! Note that I have seen quite a few before, though I am not sure about the details and the reproducibility. The release/acquire was hidden behind RFifoLock contention callbacks instead of BDRV_POLL_WHILE.
Paolo > > > > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> > > --- > > block/io.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > Reviewed-by: Eric Blake <ebl...@redhat.com> > > > > > diff --git a/block/io.c b/block/io.c > > index cc56e90..f0041cd 100644 > > --- a/block/io.c > > +++ b/block/io.c > > @@ -2031,9 +2031,7 @@ bdrv_rw_vmstate(BlockDriverState *bs, QEMUIOVector > > *qiov, int64_t pos, > > Coroutine *co = qemu_coroutine_create(bdrv_co_rw_vmstate_entry, > > &data); > > > > bdrv_coroutine_enter(bs, co); > > - while (data.ret == -EINPROGRESS) { > > - aio_poll(bdrv_get_aio_context(bs), true); > > - } > > + BDRV_POLL_WHILE(bs, data.ret == -EINPROGRESS); > > return data.ret; > > } > > Do we have other culprits (not necessarily for vmsave, but for other > situations), where we should be using BDRV_POLL_WHILE in separate > patches? For example, a quick grep show that at least hw/9pfs/9p.c makes > a direct call to aio_poll(,true) in a while loop. > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org > >