Re: [for-4.2 PATCH 3/6] replay: update docs for record/replay with block devices

[Kevin Wolf <kwolf@redhat.com>]

Am 20.09.2019 um 09:25 hat Pavel Dovgalyuk geschrieben:
> > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > Am 19.09.2019 um 14:10 hat Pavel Dovgalyuk geschrieben:
> > > > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > > > diff --git a/block/block-backend.c b/block/block-backend.c
> > > > index 1c605d5444..c57d3d9fdf 100644
> > > > --- a/block/block-backend.c
> > > > +++ b/block/block-backend.c
> > > > @@ -17,6 +17,7 @@
> > > >  #include "block/throttle-groups.h"
> > > >  #include "hw/qdev-core.h"
> > > >  #include "sysemu/blockdev.h"
> > > > +#include "sysemu/replay.h"
> > > >  #include "sysemu/runstate.h"
> > > >  #include "qapi/error.h"
> > > >  #include "qapi/qapi-events-block.h"
> > > > @@ -808,6 +809,12 @@ void blk_remove_bs(BlockBackend *blk)
> > > >  int blk_insert_bs(BlockBackend *blk, BlockDriverState *bs, Error **errp)
> > > >  {
> > > >      ThrottleGroupMember *tgm = &blk->public.throttle_group_member;
> > > > +
> > > > +    if (replay_mode != REPLAY_MODE_NONE && bs->drv != &bdrv_blkreplay) {
> > > > +        error_setg(errp, "Root node must be blkreplay");
> > > > +        return -ENOTSUP;
> > > > +    }
> > >
> > > I guess this is opposite direction - bs->drv is bdrv_file.
> > > And we should check its parent.
> > 
> > If bs->drv is bdrv_file, you want this to fail because only
> > bdrv_blkreplay should be able to be attached to devices.
> 
> There was a regular rr invocation (as described in docs).
> And bs->drv always was a pointer to bdrv_file: for original image,
> and for temporary snapshot.

Hm, what was the actual command line you used? I can see that you have a
separate -drive for the qcow2 file, so I can see how you get an unused
BlockBackend for the qcow2 node, but I don't see how it would be a file
node.

Anyway, this leaves us two options: Either change the recommended
command line to use -blockdev for the qcow2 file so that no BlockBackend
is created for it (I think this might be preferable), or restrict the
error to when the BlockBackend is used.

The second option would probably have to be done in blk_attach_dev().
The problem with this is that the only expected error so far is that the
BlockBackend is already attached to a different device. So if you return
a new error there, you will have to touch its callers as well to have
this error correctly passed to the user.

Kevin