On Wed, Dec 12, 2012 at 02:50:50PM +0100, Stefan Hajnoczi wrote: > 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.
Could not find it. It needs to be in virtio-blk in order to know to update the used ring once it completes, right? > So I think > inuse != 0 when migrating with pending failed I/O requests. > > Stefan Okay but let's make sure this is not a bug.
