From nobody Tue Dec 16 07:06:25 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1520984476641488.2806214455511; Tue, 13 Mar 2018 16:41:16 -0700 (PDT) Received: from localhost ([::1]:43575 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evtXf-0001Dc-MT for importer@patchew.org; Tue, 13 Mar 2018 19:41:15 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evsiv-0006Ym-0h for qemu-devel@nongnu.org; Tue, 13 Mar 2018 18:48:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1evsit-0004I4-7l for qemu-devel@nongnu.org; Tue, 13 Mar 2018 18:48:48 -0400 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:34753) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1evsis-0004HK-SR for qemu-devel@nongnu.org; Tue, 13 Mar 2018 18:48:47 -0400 Received: by mail-wm0-x229.google.com with SMTP id a20so16164583wmd.1 for ; Tue, 13 Mar 2018 15:48:46 -0700 (PDT) Received: from donizetti.lan (94-36-191-219.adsl-ull.clienti.tiscali.it. [94.36.191.219]) by smtp.gmail.com with ESMTPSA id x107sm1557951wrb.97.2018.03.13.15.48.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Mar 2018 15:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references; bh=5EJ5QKXvv/r+l3jOBspIqp/YXJzdxuVremBWi0vkpdY=; b=pdpNXVTlAil1BOho6gYMqepAcGikGOeKqHOamsJ5otpdUx+MFLRuhvUqwLqxxazFVZ IxDrJzMFWc+HX7WiNM9U3wlL/jzc5dM05tyzbHyYImOG4DiONNm615K/v0y9eGLgUnnC NSAw6lpHsrCRQX31r/oDmQEHlsc3tvogy1xkVTf7XFM3ljwMGIkvu2zbPHEKI7yoUcud XEtBR7LSZpX7JtmZu5Ud/8VeUAxY3g1gMs8M0g0SdiEx2M/ASoXxNuxThZuOqgHESJdE aCi77bl+ESdNy4hjMxrhno04UNxR0JGfeUl9rPaUY0vOsPYZ/NGJ+fLF5V6XDFJV/8zs +H0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references; bh=5EJ5QKXvv/r+l3jOBspIqp/YXJzdxuVremBWi0vkpdY=; b=ngE/DQRtQoIOOuNQZdCBWnRgrZxtvPqsrwqKQFO6ZnKpTC0meZKhGjvQqQa5ABq1lk 6OK/2S0Le6lzCOtk2x/VFb5Xd7TgJg+jMHbhThUIt5XAWq4y5spEaPVtUoEUCPIjOaqo yyWUK6VcPjr6Bpyxb7ATGRrSxPSnd8y9qwz+7x40PTVBrxf+kH6OygAO2PeUKuX/e6mM 0pv9T0QZ8Vxy/uwafp1ZphnSoXc3yGhY9wuyFgU8E9vKX4HKIcSHhIHNgnccRe8kFlUa iCauWzCitL05tRY4nBuBLBQc/qpN3StLq1jSDvetyJLOsdKIAsIoxj2vPO5f3tPeQLW+ SlRA== X-Gm-Message-State: AElRT7HUG2WsE5LoVKrqWlHd2aIV49rEvmlv3DiGY1e/ziEjfJ5BUAzZ KGSXTffjYG0IAk6FHY1x0BrehRa5 X-Google-Smtp-Source: AG47ELtyA+nlME3ekvCd2wm33w0MOynFgjN/4O8VG/Mzk9PTags18+OFaxv4KjF2g3IKBCKGZGDRrQ== X-Received: by 10.28.144.82 with SMTP id s79mr1944980wmd.4.1520981325286; Tue, 13 Mar 2018 15:48:45 -0700 (PDT) From: Paolo Bonzini To: qemu-devel@nongnu.org Date: Tue, 13 Mar 2018 23:47:18 +0100 Message-Id: <20180313224719.4954-69-pbonzini@redhat.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180313224719.4954-1-pbonzini@redhat.com> References: <20180313224719.4954-1-pbonzini@redhat.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::229 Subject: [Qemu-devel] [PULL 68/69] replay: update documentation X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pavel Dovgalyuk Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Pavel Dovgalyuk This patch clarifies the description of the record/replay feature in docs/replay.txt Signed-off-by: Pavel Dovgalyuk Message-Id: <20180227095333.1060.1331.stgit@pasha-VirtualBox> Signed-off-by: Paolo Bonzini Signed-off-by: Pavel Dovgalyuk --- docs/replay.txt | 72 +++++++++++++++++++++++++++++++++++++++++------------= ---- 1 file changed, 52 insertions(+), 20 deletions(-) diff --git a/docs/replay.txt b/docs/replay.txt index 959633e7ea..2e21e9ccb0 100644 --- a/docs/replay.txt +++ b/docs/replay.txt @@ -7,14 +7,10 @@ See the COPYING file in the top-level directory. Record/replay ------------- =20 -Record/replay functions are used for the reverse execution and determinist= ic -replay of qemu execution. This implementation of deterministic replay can -be used for deterministic debugging of guest code through a gdb remote -interface. - +Record/replay functions are used for the deterministic replay of qemu exec= ution. Execution recording writes a non-deterministic events log, which can be la= ter used for replaying the execution anywhere and for unlimited number of time= s. -It also supports checkpointing for faster rewinding during reverse debuggi= ng. +It also supports checkpointing for faster rewind to the specific replay mo= ment. Execution replaying reads the log and replays all non-deterministic events including external input, hardware clocks, and interrupts. =20 @@ -28,16 +24,36 @@ Deterministic replay has the following features: input devices. =20 Usage of the record/replay: - * First, record the execution, by adding the following arguments to the c= ommand line: - '-icount shift=3D7,rr=3Drecord,rrfile=3Dreplay.bin -net none'. - Block devices' images are not actually changed in the recording mode, + * First, record the execution with the following command line: + qemu-system-i386 \ + -icount shift=3D7,rr=3Drecord,rrfile=3Dreplay.bin \ + -drive file=3Ddisk.qcow2,if=3Dnone,id=3Dimg-direct \ + -drive driver=3Dblkreplay,if=3Dnone,image=3Dimg-direct,id=3Dimg-blkre= play \ + -device ide-hd,drive=3Dimg-blkreplay \ + -netdev user,id=3Dnet1 -device rtl8139,netdev=3Dnet1 \ + -object filter-replay,id=3Dreplay,netdev=3Dnet1 + * After recording, you can replay it by using another command line: + qemu-system-i386 \ + -icount shift=3D7,rr=3Dreplay,rrfile=3Dreplay.bin \ + -drive file=3Ddisk.qcow2,if=3Dnone,id=3Dimg-direct \ + -drive driver=3Dblkreplay,if=3Dnone,image=3Dimg-direct,id=3Dimg-blkre= play \ + -device ide-hd,drive=3Dimg-blkreplay \ + -netdev user,id=3Dnet1 -device rtl8139,netdev=3Dnet1 \ + -object filter-replay,id=3Dreplay,netdev=3Dnet1 + The only difference with recording is changing the rr option + from record to replay. + * Block device images are not actually changed in the recording mode, because all of the changes are written to the temporary overlay file. - * Then you can replay it by using another command - line option: '-icount shift=3D7,rr=3Dreplay,rrfile=3Dreplay.bin -net no= ne' - * '-net none' option should also be specified if network replay patches - are not applied. - -Papers with description of deterministic replay implementation: + This behavior is enabled by using blkreplay driver. It should be used + for every enabled block device, as described in 'Block devices' section. + * '-net none' option should be specified when network is not used, + because QEMU adds network card by default. When network is needed, + it should be configured explicitly with replay filter, as described + in 'Network devices' section. + * Interaction with audio devices and serial ports are recorded and replay= ed + automatically when such devices are enabled. + +Academic papers with description of deterministic replay implementation: http://www.computer.org/csdl/proceedings/csmr/2012/4666/00/4666a553-abs.ht= ml http://dl.acm.org/citation.cfm?id=3D2786805.2803179 =20 @@ -46,8 +62,11 @@ Modifications of qemu include: * saving different asynchronous events (e.g. system shutdown) into the log * synchronization of the bottom halves execution * synchronization of the threads from thread pool - * recording/replaying user input (mouse and keyboard) + * recording/replaying user input (mouse, keyboard, and microphone) * adding internal checkpoints for cpu and io synchronization + * network filter for recording and replaying the packets + * block driver for making block layer deterministic + * serial port input record and replay =20 Locking and thread synchronisation ---------------------------------- @@ -77,12 +96,11 @@ Non-deterministic events Our record/replay system is based on saving and replaying non-deterministic events (e.g. keyboard input) and simulating deterministic ones (e.g. readi= ng from HDD or memory of the VM). Saving only non-deterministic events makes -log file smaller, simulation faster, and allows using reverse debugging ev= en -for realtime applications. +log file smaller and simulation faster. =20 The following non-deterministic data from peripheral devices is saved into the log: mouse and keyboard input, network packets, audio controller input, -USB packets, serial port input, and hardware clocks (they are non-determin= istic +serial port input, and hardware clocks (they are non-deterministic too, because their values are taken from the host machine). Inputs from simulated hardware, memory of VM, software interrupts, and execution of instructions are not saved into the log, because they are deterministic and @@ -205,7 +223,7 @@ Block devices record/replay module intercepts calls of bdrv coroutine functions at the top of block drivers stack. To record and replay block operations the drive must be configured as following: - -drive file=3Ddisk.qcow,if=3Dnone,id=3Dimg-direct + -drive file=3Ddisk.qcow2,if=3Dnone,id=3Dimg-direct -drive driver=3Dblkreplay,if=3Dnone,image=3Dimg-direct,id=3Dimg-blkreplay -device ide-hd,drive=3Dimg-blkreplay =20 @@ -234,6 +252,12 @@ This snapshot is created at start of recording and res= tored at start of replaying. It also can be loaded while replaying to roll back the execution. =20 +Use QEMU monitor to create additional snapshots. 'savevm ' command +created the snapshot and 'loadvm ' restores it. To prevent corruption +of the original disk image, use overlay files linked to the original image= s. +Therefore all new snapshots (including the starting one) will be saved in +overlays and the original image remains unchanged. + Network devices --------------- =20 @@ -255,6 +279,14 @@ Audio data is recorded and replay automatically. The c= ommand line for recording and replaying must contain identical specifications of audio hardware, e.g= .: -soundhw ac97 =20 +Serial ports +------------ + +Serial ports input is recorded and replay automatically. The command lines +for recording and replaying must contain identical number of ports in reco= rd +and replay modes, but their backends may differ. +E.g., '-serial stdio' in record mode, and '-serial null' in replay mode. + Replay log format ----------------- =20 --=20 2.14.3