Pavel Dovgalyuk <dovga...@ispras.ru> writes:
>> -----Original Message----- >> From: Alex Bennée [mailto:alex.ben...@linaro.org] >> Sent: Tuesday, September 17, 2019 10:02 PM >> To: Pavel Dovgalyuk >> Cc: qemu-devel@nongnu.org; kw...@redhat.com; peter.mayd...@linaro.org; >> crosthwaite.pe...@gmail.com; boost.li...@gmail.com; >> artem.k.pisare...@gmail.com; >> quint...@redhat.com; ciro.santi...@gmail.com; jasow...@redhat.com; >> m...@redhat.com; >> arm...@redhat.com; mre...@redhat.com; maria.klimushenk...@ispras.ru; >> dovga...@ispras.ru; >> kra...@redhat.com; pavel.dovga...@ispras.ru; thomas.dull...@googlemail.com; >> pbonz...@redhat.com; dgilb...@redhat.com; r...@twiddle.net >> Subject: Re: [for-4.2 PATCH 0/6] Block-related record/replay fixes >> >> >> 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? > > That's would be great. > I'm not familiar with testing framework and couldn't find "memory" > test that you refer to. The memory test code is in tests/tcg/multiarch/system and gets combined with the boot code for whichever target can build it. For example on aarch64 it is run like: timeout 15 $BLD/aarch64-softmmu/qemu-system-aarch64 -monitor none -display none -chardev file,path=memory.out,id=output -M virt -cpu max -display none -semihosting-config enable=on,target=native,chardev=output -kernel memory The test binaries will be in $BLD/tests/tcg/aarch64-softmmu and are built when you run "make check-tcg" and have either the appropriate cross compilers installed on your system or docker enabled and setup (see docs/devel/testing.rst). > Replay test must at least the following: > 1. record some execution > 2. replay that execution > > And there could be several endings: > 1. record stalled > 2. record crashed > 3. replay stalled > 4. replay crashed > 5. all executions finished successfully If you can provide an appropriate set of invocations I can plumb them into the Makefiles for you. > > Pavel Dovgalyuk > >> >> > >> > --- >> > >> > 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 -- Alex Bennée
