On Wed, Dec 12, 2012 at 12:51:01PM +0200, Michael S. Tsirkin wrote: > Add sanity check to address the following concern: > > During migration, all we pass the index of the request; > the rest can be re-read from the ring. > > This is not generally enough if any available requests are outstanding. > Imagine a ring of size 4. Below A means available U means used. > > A 1 > A 2 > U 2 > A 2 > U 2 > A 2 > U 2 > A 2 > U 2 > > At this point available ring has wrapped around, the only > way to know head 1 is outstanding is because backend > has stored this info somewhere. > > The reason we manage to migrate without tracking this in migration > state is because we flush outstanding requests before > migration. > This flush is device-specific though, let's add > a safeguard in virtio core to ensure it's done properly. > > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > --- > > Changes from v1: > v1 was against the wrong tree, it didn't build against qemu.git > > hw/virtio.c | 2 ++ > 1 file changed, 2 insertions(+)
VirtIOBlock->rq can trigger the assertion. IIUC hw/virtio-blk.c may handle I/O errors by keeping the request pending and on a list (->rq). This allows the user to restart them after, for example, adding more space to the host file system containing the disk image file. We keep a list of failed requests and we migrate this list. So I think inuse != 0 when migrating with pending failed I/O requests. Stefan
