From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 866FFC0650F for ; Thu, 8 Aug 2019 15:04:24 +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 5A335217D7 for ; Thu, 8 Aug 2019 15:04:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A335217D7 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+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:52540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvjxn-0001aF-Hl for qemu-devel@archiver.kernel.org; Thu, 08 Aug 2019 11:04:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34082) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvjx0-00010v-2n for qemu-devel@nongnu.org; Thu, 08 Aug 2019 11:03:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvjwz-0006g3-13 for qemu-devel@nongnu.org; Thu, 08 Aug 2019 11:03:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32141) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hvjwy-0006dp-SK for qemu-devel@nongnu.org; Thu, 08 Aug 2019 11:03:32 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C282F30EF4D2 for ; Thu, 8 Aug 2019 15:03:30 +0000 (UTC) Received: from localhost (ovpn-112-57.ams2.redhat.com [10.36.112.57]) by smtp.corp.redhat.com (Postfix) with ESMTP id AE5C55C22C; Thu, 8 Aug 2019 15:03:29 +0000 (UTC) From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= To: qemu-devel@nongnu.org Date: Thu, 8 Aug 2019 19:03:23 +0400 Message-Id: <20190808150325.21939-1-marcandre.lureau@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Thu, 08 Aug 2019 15:03:30 +0000 (UTC) Content-Transfer-Encoding: quoted-printable 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] [PATCH v2 0/2] Add dbus-vmstate 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: Laurent Vivier , Thomas Huth , Juan Quintela , "Dr. David Alan Gilbert" , Paolo Bonzini , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Hi, With external processes or helpers participating to the VM support, it becomes necessary to handle their migration. Various options exist to transfer their state: 1) as the VM memory, RAM or devices (we could say that's how vhost-user devices can be handled today, they are expected to restore from ring state) 2) other "vmstate" (as with TPM emulator state blobs) 3) left to be handled by management layer 1) is not practical, since an external processes may legitimatelly need arbitrary state date to back a device or a service, or may not even have an associated device. 2) needs ad-hoc code for each helper, but is simple and working 3) is complicated for management layer, QEMU has the migration timing The proposed "dbus-vmstate" object will connect to a given D-Bus peer address, and save/load from org.qemu.VMState1 interface. This way, helpers can have their state migrated with QEMU, without implementing another ad-hoc support (such as done for TPM emulation) I chose D-Bus as it is ubiquitous on Linux (it is systemd IPC), and can be made to work on various other OSes. There are several implementations and good bindings for various languages. (the tests/dbus-vmstate-test.c is a good example of how simple the implementation of services can be, even in C) v2: - D-Bus is most common and practical through a bus, but it requires a daemon to be running. I argue that the benefits outweight the cost of running an extra daemon in v1 in the context of multi-process qemu, but it is also possible to connect in p2p mode as done in this new version. dbus-vmstate is put into use by the libvirt series "[PATCH v2 00/23] Use a slirp helper process". Marc-Andr=C3=A9 Lureau (2): qemu-file: move qemu_{get,put}_counted_string() declarations Add dbus-vmstate object MAINTAINERS | 6 + backends/Makefile.objs | 4 + backends/dbus-vmstate.c | 332 +++++++++++++++++++++++++ configure | 7 + docs/interop/dbus-vmstate.rst | 63 +++++ docs/interop/index.rst | 1 + include/migration/qemu-file-types.h | 4 + migration/qemu-file.h | 4 - tests/Makefile.include | 18 +- tests/dbus-vmstate-test.c | 371 ++++++++++++++++++++++++++++ tests/dbus-vmstate1.xml | 12 + 11 files changed, 817 insertions(+), 5 deletions(-) create mode 100644 backends/dbus-vmstate.c create mode 100644 docs/interop/dbus-vmstate.rst create mode 100644 tests/dbus-vmstate-test.c create mode 100644 tests/dbus-vmstate1.xml --=20 2.23.0.rc1