Am 16.11.2016 um 10:49 hat Pavel Dovgalyuk geschrieben: > > From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru] > > > From: Kevin Wolf [mailto:kw...@redhat.com] > > > My command line was assuming a raw image. It looks like you're using a > > > qcow (hopefully qcow2?) image. If so, then you need to include the qcow2 > > > driver: > > > > > > -drive driver=blkreplay,if=none,image.driver=qcow2,\ > > > image.file.driver=file,image.file.filename=testdisk.qcow,id=img-blkreplay > > > > This doesn't work for some reason. Replay just hangs at some moment. > > > > Maybe there exists some internal difference between command line with one > > or two -drive > > options? > > 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=testdisk.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. Kevin
