From patchwork Tue Aug 20 06:59:41 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 11103091 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DD6691399 for ; Tue, 20 Aug 2019 07:23:26 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BF62F2082F for ; Tue, 20 Aug 2019 07:23:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF62F2082F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Received: from localhost ([::1]:34040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hzyUH-0000U5-Vd for patchwork-qemu-devel@patchwork.kernel.org; Tue, 20 Aug 2019 03:23:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42756) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hzy8j-0005qo-NS for qemu-devel@nongnu.org; Tue, 20 Aug 2019 03:01:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hzy8c-0003UZ-Sh for qemu-devel@nongnu.org; Tue, 20 Aug 2019 03:01:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37116) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hzy8b-0003OZ-0A for qemu-devel@nongnu.org; Tue, 20 Aug 2019 03:01:01 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AEE5A8DA29; Tue, 20 Aug 2019 07:00:57 +0000 (UTC) Received: from 640k.localdomain.com (ovpn-112-20.ams2.redhat.com [10.36.112.20]) by smtp.corp.redhat.com (Postfix) with ESMTP id 680337E009; Tue, 20 Aug 2019 07:00:56 +0000 (UTC) From: Paolo Bonzini To: qemu-devel@nongnu.org Date: Tue, 20 Aug 2019 08:59:41 +0200 Message-Id: <1566284395-30287-23-git-send-email-pbonzini@redhat.com> In-Reply-To: <1566284395-30287-1-git-send-email-pbonzini@redhat.com> References: <1566284395-30287-1-git-send-email-pbonzini@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 20 Aug 2019 07:00:57 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 22/36] replay: document development rules X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pavel Dovgalyuk , Pavel Dovgalyuk Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.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 mode. Signed-off-by: Pavel Dovgalyuk --- v9: fixed external virtual clock description (reported by Artem Pisarenko) Message-Id: <156404426119.18669.6707258931552832854.stgit@pasha-Precision-3630-Tower> Signed-off-by: Paolo Bonzini Signed-off-by: Pavel Dovgalyuk --- 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 0000000..e641c35 --- /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 +====== + +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 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 +============= + +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.