From patchwork Wed Oct 10 13:35:22 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pavel Dovgalyuk X-Patchwork-Id: 10634589 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 5D55569B1 for ; Wed, 10 Oct 2018 13:41:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 493252A12E for ; Wed, 10 Oct 2018 13:41:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 46DB82A14B; Wed, 10 Oct 2018 13:41:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id DA67F2A12E for ; Wed, 10 Oct 2018 13:41:58 +0000 (UTC) Received: from localhost ([::1]:57348 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gAEkP-0001cN-VF for patchwork-qemu-devel@patchwork.kernel.org; Wed, 10 Oct 2018 09:41:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gAEay-0002bg-8U for qemu-devel@nongnu.org; Wed, 10 Oct 2018 09:32:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gAEav-00038h-KN for qemu-devel@nongnu.org; Wed, 10 Oct 2018 09:32:12 -0400 Received: from mail.ispras.ru ([83.149.199.45]:44358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gAEav-00038O-CD for qemu-devel@nongnu.org; Wed, 10 Oct 2018 09:32:09 -0400 Received: from [127.0.1.1] (unknown [85.142.117.226]) by mail.ispras.ru (Postfix) with ESMTPSA id 6CCB4540089; Wed, 10 Oct 2018 16:32:08 +0300 (MSK) From: Pavel Dovgalyuk To: qemu-devel@nongnu.org Date: Wed, 10 Oct 2018 16:35:22 +0300 Message-ID: <20181010133522.24538.48800.stgit@pasha-VirtualBox> In-Reply-To: <20181010133333.24538.53169.stgit@pasha-VirtualBox> References: <20181010133333.24538.53169.stgit@pasha-VirtualBox> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 83.149.199.45 Subject: [Qemu-devel] [PATCH v7 19/19] 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: peter.maydell@linaro.org, war2jordan@live.com, pavel.dovgaluk@ispras.ru, mst@redhat.com, jasowang@redhat.com, zuban32s@gmail.com, kraxel@redhat.com, thomas.dullien@googlemail.com, artem.k.pisarenko@gmail.com, quintela@redhat.com, ciro.santilli@gmail.com, armbru@redhat.com, dovgaluk@ispras.ru, dgilbert@redhat.com, boost.lists@gmail.com, alex.bennee@linaro.org, rth@twiddle.net, kwolf@redhat.com, crosthwaite.peter@gmail.com, mreitz@redhat.com, maria.klimushenkova@ispras.ru, pbonzini@redhat.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP This patch introduces docs/devel/replay.txt which describes the rules that should be followed to make virtual devices usable in record/replay mode. Signed-off-by: Pavel Dovgalyuk --- docs/devel/replay.txt | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 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 0000000..61dac1b --- /dev/null +++ b/docs/devel/replay.txt @@ -0,0 +1,45 @@ +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 +====== + +All virtual devices should use virtual clock for timers that change the guest +state. Virtual clock is deterministic, therefore such timers are deterministic +too. + +Virtual devices can also use realtime clock for the events that do not change +the guest state directly. When the clock ticking should depend on VM execution +speed, use virtual ext clock. 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 +============= + +Bottom half callbacks, that affect the guest state, should be invoked through +replay_bh_schedule_event or replay_bh_schedule_oneshot_event functions. +Their invocations are saved in record mode and synchronized with the existing +log in replay mode. + +Saving/restoring the VM state +============================= + +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 +=============== + +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 change.