Re: [Qemu-block] [PATCH v5 7/9] block: don't make snapshots for filters

[Pavel Dovgalyuk]

> From: Kevin Wolf [mailto:address@hidden
> Am 16.11.2016 um 10:49 hat Pavel Dovgalyuk geschrieben:
> > > From: Pavel Dovgalyuk [mailto:address@hidden
> >
> > I've investigated this issue.
> > This command line works ok:
> >  -drive 
> > driver=blkreplay,if=none,image.driver=file,image.filename=testdisk.qcow,id=img-
> blkreplay
> >  -device ide-hd,drive=img-blkreplay
> >
> > And this does not:
> >  -drive
> >
> driver=blkreplay,if=none,image.driver=qcow2,image.file.driver=file,image.file.filename=testdis
> k.qcow
> > ,id=img-blkreplay
> >  -device ide-hd,drive=img-blkreplay
> >
> > QEMU hangs at some moment of replay.
> >
> > I found that some dma requests do not pass through the blkreplay driver
> > due to the following line in block-backend.c:
> >     return bdrv_co_preadv(blk->root, offset, bytes, qiov, flags);
> >
> > This line passes read request directly to qcow driver and blkreplay cannot
> > process it to make deterministic.
> 
> How does that bypass blkreplay? blk->root is supposed to be the blkreply
> node, do you see something different? If it were the qcow2 node, then I
> would expect that no requests at all go through the blkreplay layer.

It seems, that the problem is in -snapshot option.
We have one of the following block layers depending on command line:
 tmp_overlay1 -> blkreplay -> tmp_overlay2 -> disk_image
 tmp_overlay1 -> blkreplay -> disk_image

But the correct scheme is intended to be the following:
 blkreplay -> tmp_overlay1 -> disk_image

How can we fix it?
Maybe we should add blkreplay automatically to all block devices and not
to specify it in the command line?

Pavel Dovgalyuk