From nobody Mon Nov 10 11:23:54 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1555932889; cv=none; d=zoho.com; s=zohoarc; b=FFE73aBRGQhmGEWmRiGnWmOW+yf/OiRI8wNtIVfpV7dtfxsM3xGrtRI1AKpNyX2Z7cmTOH9KnuFbSzAHpqiwADXZjZp16vPHbo/+MFeKMgRbTcMr/VteEbuIXFQoKv/js9JWQLOaoSSIW2g+ZVJc6rsLK2o2FXlMbkngIp5592U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1555932889; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=8ihHEaEmEQs266HY8i9RIsFrv0NlHuRc3X6MKQwEvPs=; b=nrouwvZTxXqC/76O+btCpEBuxGk49a4945AJAdTmHyhukO5aLBnvmew4Cq1c3QRiFDjXzEhmmlQgEC9ScQGLUbwOHcBxShsBO9TMfYpKUQADHhcM+VeqsFSc1yyoJG4xbq+p4ez40jxDzM/FIBFUOcqxPliZAlsdv0B3WmX+eio= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1555932889026762.3875267164392; Mon, 22 Apr 2019 04:34:49 -0700 (PDT) Received: from localhost ([127.0.0.1]:35944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIXDe-0003j2-1V for importer@patchew.org; Mon, 22 Apr 2019 07:34:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIX0y-00012u-Hi for qemu-devel@nongnu.org; Mon, 22 Apr 2019 07:21:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hIX0w-0002RY-Ur for qemu-devel@nongnu.org; Mon, 22 Apr 2019 07:21:36 -0400 Received: from mail.ispras.ru ([83.149.199.45]:47310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIX0w-0002R5-M3 for qemu-devel@nongnu.org; Mon, 22 Apr 2019 07:21:34 -0400 Received: from [127.0.1.1] (unknown [85.142.117.226]) by mail.ispras.ru (Postfix) with ESMTPSA id 0E1745400A9; Mon, 22 Apr 2019 14:21:33 +0300 (MSK) From: Pavel Dovgalyuk To: qemu-devel@nongnu.org Date: Mon, 22 Apr 2019 14:21:32 +0300 Message-ID: <155593209287.21079.6402350212322496096.stgit@pasha-Precision-3630-Tower> In-Reply-To: <155593197705.21079.8238359471765771689.stgit@pasha-Precision-3630-Tower> References: <155593197705.21079.8238359471765771689.stgit@pasha-Precision-3630-Tower> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 83.149.199.45 Subject: [Qemu-devel] [PATCH for-4.1 20/24] replay: document development rules 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: kwolf@redhat.com, peter.maydell@linaro.org, war2jordan@live.com, pavel.dovgaluk@ispras.ru, pbonzini@redhat.com, crosthwaite.peter@gmail.com, ciro.santilli@gmail.com, jasowang@redhat.com, quintela@redhat.com, armbru@redhat.com, mreitz@redhat.com, alex.bennee@linaro.org, maria.klimushenkova@ispras.ru, mst@redhat.com, kraxel@redhat.com, boost.lists@gmail.com, thomas.dullien@googlemail.com, dovgaluk@ispras.ru, artem.k.pisarenko@gmail.com, dgilbert@redhat.com, rth@twiddle.net Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" From: Pavel Dovgalyuk This patch introduces docs/devel/replay.txt which describes the rules that should be followed to make virtual devices usable in record/replay mod= e. Signed-off-by: Pavel Dovgalyuk -- v9: fixed external virtual clock description (reported by Artem Pisarenko) --- docs/devel/replay.txt | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 docs/devel/replay.txt diff --git a/docs/devel/replay.txt b/docs/devel/replay.txt new file mode 100644 index 0000000000..e641c35add --- /dev/null +++ b/docs/devel/replay.txt @@ -0,0 +1,46 @@ +Record/replay mechanism, that could be enabled through icount mode, expects +the virtual devices to satisfy the following requirements. + +The main idea behind this document is that everything that affects +the guest state during execution in icount mode should be deterministic. + +Timers +=3D=3D=3D=3D=3D=3D + +All virtual devices should use virtual clock for timers that change the gu= est +state. Virtual clock is deterministic, therefore such timers are determini= stic +too. + +Virtual devices can also use realtime clock for the events that do not cha= nge +the guest state directly. When the clock ticking should depend on VM execu= tion +speed, use virtual clock with EXTERNAL attribute. It is not deterministic, +but its speed depends on the guest execution. This clock is used by +the virtual devices (e.g., slirp routing device) that lie outside the +replayed guest. + +Bottom halves +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Bottom half callbacks, that affect the guest state, should be invoked thro= ugh +replay_bh_schedule_event or replay_bh_schedule_oneshot_event functions. +Their invocations are saved in record mode and synchronized with the exist= ing +log in replay mode. + +Saving/restoring the VM state +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D + +All fields in the device state structure (including virtual timers) +should be restored by loadvm to the same values they had before savevm. + +Avoid accessing other devices' state, because the order of saving/restoring +is not defined. It means that you should not call functions like +'update_irq' in post_load callback. Save everything explicitly to avoid +the dependencies that may make restoring the VM state non-deterministic. + +Stopping the VM +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Stopping the guest should not interfere with its state (with the exception +of the network connections, that could be broken by the remote timeouts). +VM can be stopped at any moment of replay by the user. Restarting the VM +after that stop should not break the replay by the unneeded guest state ch= ange.