From nobody Tue Feb 10 10:54:59 2026 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=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1566285820; cv=none; d=zoho.com; s=zohoarc; b=nG8Tc8YlN7ApoHi7tO14rokq3mSt1d11KXMppXTQgHE0qZ89NwH8YZNyZM/eorJPn+5nLEuPihAqbGQNxUnIQoziWGt3aD4Q1F9IP/+TzkvI7UHOi93wTwDZJTeNJ+AtP2mhr/IdeK9hWNR+DR/tPSLNKZJdTqmPOStYO6kug5s= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1566285820; h=Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=5gdz7zCKzOHgcTxkV/rbiunxm+Md0GR+SMvyBfW1WxA=; b=c3JW8p4mAUpYJhxYvmEY8JIzJdFRl7OatVYKL9O2+TdACu5M2fPU+yWAN6/PNGzzhlrhWYYRYPUxnriupzPEd8ZZ2am7c7W47H05bBBoxgYyJciWGltG5z0We88roDtp3ELCqBi0j7RpTLJIG/Sl7DPeYvMXleA5UeqygZUWDvw= 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 1566285820927557.3965876633647; Tue, 20 Aug 2019 00:23:40 -0700 (PDT) Received: from localhost ([::1]:34040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hzyUV-0000U5-Qq for importer@patchew.org; Tue, 20 Aug 2019 03:23:39 -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+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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) Message-Id: <156404426119.18669.6707258931552832854.stgit@pasha-Precision-3= 630-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 +=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. --=20 1.8.3.1