> From: Kevin Wolf [mailto:kw...@redhat.com] > Am 16.11.2016 um 10:49 hat Pavel Dovgalyuk geschrieben: > > > From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru] > > > > 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
