Pavel Dovgalyuk <pavel.dovga...@gmail.com> writes:
> The set of patches include the block-related updates > of the record/replay icount feature: > - application of 'snapshot' option on the file layer instead of > the top one: command line and documentation fix > - implementation of bdrv_snapshot_goto for blkreplay driver > - start/stop fix in replay mode with attached block devices > - record/replay of bh oneshot events, used in the block layer Can we come up with a reasonable smoke test to verify record/replay is functional? AIUI we don't need a full OS but we do need a block device to store the replay data. Could we use one of the simple system tests like "memory" and run that through a record and replay cycle? If we can defend the basic functionally in "make check" then breakage is less likely to slip through and you'll have less bisecting to do. > > --- > > Pavel Dovgaluk (6): > block: implement bdrv_snapshot_goto for blkreplay > replay: disable default snapshot for record/replay > replay: update docs for record/replay with block devices > replay: don't drain/flush bdrv queue while RR is working > replay: finish record/replay before closing the disks > replay: add BH oneshot event for block layer > > > block/blkreplay.c | 8 ++++++++ > block/block-backend.c | 9 ++++++--- > block/io.c | 32 ++++++++++++++++++++++++++++++-- > block/iscsi.c | 5 +++-- > block/nfs.c | 6 ++++-- > block/null.c | 4 +++- > block/nvme.c | 6 ++++-- > block/rbd.c | 5 +++-- > block/vxhs.c | 5 +++-- > cpus.c | 2 -- > docs/replay.txt | 12 +++++++++--- > include/sysemu/replay.h | 4 ++++ > replay/replay-events.c | 16 ++++++++++++++++ > replay/replay-internal.h | 1 + > replay/replay.c | 2 ++ > stubs/Makefile.objs | 1 + > stubs/replay-user.c | 9 +++++++++ > vl.c | 11 +++++++++-- > 18 files changed, 115 insertions(+), 23 deletions(-) > create mode 100644 stubs/replay-user.c -- Alex Bennée
