From nobody Sat May 18 15:49:41 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1694773630; cv=none; d=zohomail.com; s=zohoarc; b=GeQdchH8iJ0AIIcf1LehV30bd0WjWur8n2QL0aqXddOqhExV5d6KlI8wsmA5oPj05fDeSPZSX0RQTtCFdpwgr5BD79cBiplzZn9mE8wcAlY9dNG3h1xviY9ixulcroxj+brwHq2vhH5DKbcMwoJqxwkA2K8idZEVvUFTj9RaInE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694773630; 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; bh=uvdAjpHKLRM6KJVPEhQMXcGpxk7oDNyqqZc9xO9fsRI=; b=cYOx2+am2aTzwuPXHHfhemU5am1Xqrapady5hVVmiYaw4lgeNUT4qcCPm1G9E2hk/dAPpCBtBhhRuu5OKoBStXWuw3LT0lS1gWWd9Ljr0gLJUL1MXyizBEHU8i3iUYE0TRTNA+vG9x0nE+NKolvHUn8eDiUEEQhyXR1FQzZF0UQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1694773630704794.3023348830238; Fri, 15 Sep 2023 03:27:10 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh61o-0007Av-N8; Fri, 15 Sep 2023 06:26:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh61E-0006ce-0d for qemu-devel@nongnu.org; Fri, 15 Sep 2023 06:25:52 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh61A-0002ix-3M for qemu-devel@nongnu.org; Fri, 15 Sep 2023 06:25:47 -0400 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-370-5D9QpLDnNlOS8Lu-m1P-Tw-1; Fri, 15 Sep 2023 06:25:35 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B00E0185A79C for ; Fri, 15 Sep 2023 10:25:34 +0000 (UTC) Received: from localhost (unknown [10.39.194.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3A25B10F1BE7; Fri, 15 Sep 2023 10:25:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694773536; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uvdAjpHKLRM6KJVPEhQMXcGpxk7oDNyqqZc9xO9fsRI=; b=Wpwg0iIhFVAHA8HTDF+4xr6y0h0131a6lUspsv9XnsTVvJEjxddRIsQMQpHNlhiVXpsKjk qu4QgCMNvJjLFxS3k9/ncVx8+3rUW+HGlfhv7p5ZmKlohYtnvlShdrMhR84q/jiPFWUJtZ ZxQ0ZFtmx48MSpTqZxPZJpQw9PmLE+Q= X-MC-Unique: 5D9QpLDnNlOS8Lu-m1P-Tw-1 From: Hanna Czenczek To: qemu-devel@nongnu.org, virtio-fs@redhat.com Cc: Hanna Czenczek , Stefan Hajnoczi , "Michael S . Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , German Maglione Subject: [PATCH v3 1/5] vhost-user.rst: Migrating back-end-internal state Date: Fri, 15 Sep 2023 12:25:26 +0200 Message-ID: <20230915102531.55894-2-hreitz@redhat.com> In-Reply-To: <20230915102531.55894-1-hreitz@redhat.com> References: <20230915102531.55894-1-hreitz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 Received-SPF: pass (zohomail.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; Received-SPF: pass client-ip=170.10.133.124; envelope-from=hreitz@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1694773631958100001 For vhost-user devices, qemu can migrate the virtio state, but not the back-end's internal state. To do so, we need to be able to transfer this internal state between front-end (qemu) and back-end. At this point, this new feature is added for the purpose of virtio-fs migration. Because virtiofsd's internal state will not be too large, we believe it is best to transfer it as a single binary blob after the streaming phase. These are the additions to the protocol: - New vhost-user protocol feature VHOST_USER_PROTOCOL_F_DEVICE_STATE - SET_DEVICE_STATE_FD function: Front-end and back-end negotiate a file descriptor over which to transfer the state. - CHECK_DEVICE_STATE: After the state has been transferred through the file descriptor, the front-end invokes this function to verify success. There is no in-band way (through the file descriptor) to indicate failure, so we need to check explicitly. Once the transfer FD has been established via SET_DEVICE_STATE_FD (which includes establishing the direction of transfer and migration phase), the sending side writes its data into it, and the reading side reads it until it sees an EOF. Then, the front-end will check for success via CHECK_DEVICE_STATE, which on the destination side includes checking for integrity (i.e. errors during deserialization). Signed-off-by: Hanna Czenczek Reviewed-by: Stefan Hajnoczi --- docs/interop/vhost-user.rst | 170 ++++++++++++++++++++++++++++++++++++ 1 file changed, 170 insertions(+) diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index 5a070adbc1..bb4dd0fd60 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -275,6 +275,31 @@ Inflight description =20 :queue size: a 16-bit size of virtqueues =20 +Device state transfer parameters +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++--------------------+-----------------+ +| transfer direction | migration phase | ++--------------------+-----------------+ + +:transfer direction: a 32-bit enum, describing the direction in which + the state is transferred: + + - 0: Save: Transfer the state from the back-end to the front-end, + which happens on the source side of migration + - 1: Load: Transfer the state from the front-end to the back-end, + which happens on the destination side of migration + +:migration phase: a 32-bit enum, describing the state in which the VM + guest and devices are: + + - 0: Stopped (in the period after the transfer of memory-mapped + regions before switch-over to the destination): The VM guest and all + of the vhost-user device's rings are stopped. + + In the future, additional phases might be added e.g. to allow + iterative migration while the device is running. + C structure ----------- =20 @@ -334,6 +359,7 @@ in the ancillary data: * ``VHOST_USER_SET_VRING_ERR`` * ``VHOST_USER_SET_BACKEND_REQ_FD`` (previous name ``VHOST_USER_SET_SLAVE_= REQ_FD``) * ``VHOST_USER_SET_INFLIGHT_FD`` (if ``VHOST_USER_PROTOCOL_F_INFLIGHT_SHMF= D``) +* ``VHOST_USER_SET_DEVICE_STATE_FD`` =20 If *front-end* is unable to send the full message or receives a wrong reply it will close the connection. An optional reconnection mechanism @@ -492,6 +518,79 @@ it performs WAKE ioctl's on the userfaultfd to wake th= e stalled back-end. The front-end indicates support for this via the ``VHOST_USER_PROTOCOL_F_PAGEFAULT`` feature. =20 +.. _migrating_backend_state: + +Migrating back-end state +^^^^^^^^^^^^^^^^^^^^^^^^ + +Migrating device state involves transferring the state from one +back-end, called the source, to another back-end, called the +destination. After migration, the destination transparently resumes +operation without requiring the driver to re-initialize the device at +the VIRTIO level. If the migration fails, then the source can +transparently resume operation until another migration attempt is made. + +Generally, the front-end is connected to a virtual machine guest (which +contains the driver), which has its own state to transfer between source +and destination, and therefore will have an implementation-specific +mechanism to do so. The ``VHOST_USER_PROTOCOL_F_DEVICE_STATE`` feature +provides functionality to have the front-end include the back-end's +state in this transfer operation so the back-end does not need to +implement its own mechanism, and so the virtual machine may have its +complete state, including vhost-user devices' states, contained within a +single stream of data. + +To do this, the back-end state is transferred from back-end to front-end +on the source side, and vice versa on the destination side. This +transfer happens over a channel that is negotiated using the +``VHOST_USER_SET_DEVICE_STATE_FD`` message. This message has two +parameters: + +* Direction of transfer: On the source, the data is saved, transferring + it from the back-end to the front-end. On the destination, the data + is loaded, transferring it from the front-end to the back-end. + +* Migration phase: Currently, the only supported phase is the period + after the transfer of memory-mapped regions before switch-over to the + destination, when all of the device's rings are stopped. In the + future, additional phases might be supported to allow iterative + migration while the device is running. + +The nature of the channel is implementation-defined, but it must +generally behave like a pipe: The writing end will write all the data it +has into it, signalling the end of data by closing its end. The reading +end must read all of this data (until encountering the end of file) and +process it. + +* When saving, the writing end is the source back-end, and the reading + end is the source front-end. After reading the state data from the + channel, the source front-end must transfer it to the destination + front-end through an implementation-defined mechanism. + +* When loading, the writing end is the destination front-end, and the + reading end is the destination back-end. After reading the state data + from the channel, the destination back-end must deserialize its + internal state from that data and set itself up to allow the driver to + seamlessly resume operation on the VIRTIO level. + +Seamlessly resuming operation means that the migration must be +transparent to the guest driver, which operates on the VIRTIO level. +This driver will not perform any re-initialization steps, but continue +to use the device as if no migration had occurred. The vhost-user +front-end, however, will re-initialize the vhost state on the +destination, following the usual protocol for establishing a connection +to a vhost-user back-end: This includes, for example, setting up memory +mappings and kick and call FDs as necessary, negotiating protocol +features, or setting the initial vring base indices (to the same value +as on the source side, so that operation can resume). + +Both on the source and on the destination side, after the respective +front-end has seen all data transferred (when the transfer FD has been +closed), it sends the ``VHOST_USER_CHECK_DEVICE_STATE`` message to +verify that data transfer was successful in the back-end, too. The +back-end responds once it knows whether the transfer and processing was +successful or not. + Memory access ------------- =20 @@ -885,6 +984,7 @@ Protocol features #define VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS 15 #define VHOST_USER_PROTOCOL_F_STATUS 16 #define VHOST_USER_PROTOCOL_F_XEN_MMAP 17 + #define VHOST_USER_PROTOCOL_F_DEVICE_STATE 18 =20 Front-end message types ----------------------- @@ -1440,6 +1540,76 @@ Front-end message types query the back-end for its device status as defined in the Virtio specification. =20 +``VHOST_USER_SET_DEVICE_STATE_FD`` + :id: 41 + :equivalent ioctl: N/A + :request payload: device state transfer parameters + :reply payload: ``u64`` + + Front-end and back-end negotiate a channel over which to transfer the + back-end=E2=80=99s internal state during migration. Either side (front-= end or + back-end) may create the channel. The nature of this channel is not + restricted or defined in this document, but whichever side creates it + must create a file descriptor that is provided to the respectively + other side, allowing access to the channel. This FD must behave as + follows: + + * For the writing end, it must allow writing the whole back-end state + sequentially. Closing the file descriptor signals the end of + transfer. + + * For the reading end, it must allow reading the whole back-end state + sequentially. The end of file signals the end of the transfer. + + For example, the channel may be a pipe, in which case the two ends of + the pipe fulfill these requirements respectively. + + Initially, the front-end creates a channel along with such an FD. It + passes the FD to the back-end as ancillary data of a + ``VHOST_USER_SET_DEVICE_STATE_FD`` message. The back-end may create a + different transfer channel, passing the respective FD back to the + front-end as ancillary data of the reply. If so, the front-end must + then discard its channel and use the one provided by the back-end. + + Whether the back-end should decide to use its own channel is decided + based on efficiency: If the channel is a pipe, both ends will most + likely need to copy data into and out of it. Any channel that allows + for more efficient processing on at least one end, e.g. through + zero-copy, is considered more efficient and thus preferred. If the + back-end can provide such a channel, it should decide to use it. + + The request payload contains parameters for the subsequent data + transfer, as described in the :ref:`Migrating back-end state + ` section. + + The value returned is both an indication for success, and whether a + file descriptor for a back-end-provided channel is returned: Bits 0=E2= =80=937 + are 0 on success, and non-zero on error. Bit 8 is the invalid FD + flag; this flag is set when there is no file descriptor returned. + When this flag is not set, the front-end must use the returned file + descriptor as its end of the transfer channel. The back-end must not + both indicate an error and return a file descriptor. + + Using this function requires prior negotiation of the + ``VHOST_USER_PROTOCOL_F_DEVICE_STATE`` feature. + +``VHOST_USER_CHECK_DEVICE_STATE`` + :id: 42 + :equivalent ioctl: N/A + :request payload: N/A + :reply payload: ``u64`` + + After transferring the back-end=E2=80=99s internal state during migratio= n (see + the :ref:`Migrating back-end state ` + section), check whether the back-end was able to successfully fully + process the state. + + The value returned indicates success or error; 0 is success, any + non-zero value is an error. + + Using this function requires prior negotiation of the + ``VHOST_USER_PROTOCOL_F_DEVICE_STATE`` feature. + =20 Back-end message types ---------------------- --=20 2.41.0 From nobody Sat May 18 15:49:41 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1694773642; cv=none; d=zohomail.com; s=zohoarc; b=To2WYhNBIRv7yiovh0fYp9jVzNlOTnjiKSVgjzt84mxc7+I6DgOl1qLwGG2P3iO+3+qD2nr2MTbC60SyLpa7vnjQJxfw/bPJZi8DbckM7YtQh/AuCekufG4SG865pFmqdnnE22a6rtqqFHD0Ys5NPiRwga7Qw5Gjg3vLq8pixO8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694773642; 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; bh=1bKJvo7eC/DS/g3Qo8pX+3+4mjexf2CS6l0L7VJ7PFA=; b=dhJAv8DuXsn4XiiGG+bkCdaUvlEbTvTuzm/XcmSdmmsCFwNoCeMeGYaWIpY0EiKGFNooWffdvhzlISrKDVfRZRBLV2/JV6c0WbaSvO4sHoBKv4abVqybiKXD1AIFu2fZJUOqcNamxmCWWJR0irTeFDlYwYbHovJ8diSHmLB0gSY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 16947736419941010.5119464214143; Fri, 15 Sep 2023 03:27:21 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh61p-0007Dk-NR; Fri, 15 Sep 2023 06:26:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh61D-0006cZ-El for qemu-devel@nongnu.org; Fri, 15 Sep 2023 06:25:51 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh61A-0002mF-3M for qemu-devel@nongnu.org; Fri, 15 Sep 2023 06:25:46 -0400 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-608-67TS3hLON3umOp0DRKT5MA-1; Fri, 15 Sep 2023 06:25:36 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6D229803497 for ; Fri, 15 Sep 2023 10:25:36 +0000 (UTC) Received: from localhost (unknown [10.39.194.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EB6CB409AFC1; Fri, 15 Sep 2023 10:25:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694773538; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1bKJvo7eC/DS/g3Qo8pX+3+4mjexf2CS6l0L7VJ7PFA=; b=bjuEKYTl52sBVTmBf/BZVVuqdo/Gn/vcbMuZVIXCVhymILIGQddYYW4PT9SZWWaaCehYqH P//LvnHrme1bI3Ty+XSYcfv7PZaLw5Fu+TKah3fAK2xU2aMsZx2nuDeIya78HQqZjeUsDI Cu3PeKg1hWeivLfudnx8ukHTvkfwsQE= X-MC-Unique: 67TS3hLON3umOp0DRKT5MA-1 From: Hanna Czenczek To: qemu-devel@nongnu.org, virtio-fs@redhat.com Cc: Hanna Czenczek , Stefan Hajnoczi , "Michael S . Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , German Maglione Subject: [PATCH v3 2/5] vhost-user.rst: Clarify enabling/disabling vrings Date: Fri, 15 Sep 2023 12:25:27 +0200 Message-ID: <20230915102531.55894-3-hreitz@redhat.com> In-Reply-To: <20230915102531.55894-1-hreitz@redhat.com> References: <20230915102531.55894-1-hreitz@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 Received-SPF: pass (zohomail.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; Received-SPF: pass client-ip=170.10.133.124; envelope-from=hreitz@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1694773644205100003 Content-Type: text/plain; charset="utf-8" Currently, the vhost-user documentation says that rings are to be initialized in a disabled state when VHOST_USER_F_PROTOCOL_FEATURES is negotiated. However, by the time of feature negotiation, all rings have already been initialized, so it is not entirely clear what this means. At least the vhost-user-backend Rust crate's implementation interpreted it to mean that whenever this feature is negotiated, all rings are to put into a disabled state, which means that every SET_FEATURES call would disable all rings, effectively halting the device. This is problematic because the VHOST_F_LOG_ALL feature is also set or cleared this way, which happens during migration. Doing so should not halt the device. Other implementations have interpreted this to mean that the device is to be initialized with all rings disabled, and a subsequent SET_FEATURES call that does not set VHOST_USER_F_PROTOCOL_FEATURES will enable all of them. Here, SET_FEATURES will never disable any ring. This interpretation does not suffer the problem of unintentionally halting the device whenever features are set or cleared, so it seems better and more reasonable. We should clarify this in the documentation. Signed-off-by: Hanna Czenczek --- docs/interop/vhost-user.rst | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index bb4dd0fd60..9b9b802c60 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -409,12 +409,20 @@ and stop ring upon receiving ``VHOST_USER_GET_VRING_B= ASE``. =20 Rings can be enabled or disabled by ``VHOST_USER_SET_VRING_ENABLE``. =20 -If ``VHOST_USER_F_PROTOCOL_FEATURES`` has not been negotiated, the -ring starts directly in the enabled state. - -If ``VHOST_USER_F_PROTOCOL_FEATURES`` has been negotiated, the ring is -initialized in a disabled state and is enabled by -``VHOST_USER_SET_VRING_ENABLE`` with parameter 1. +If ``VHOST_USER_SET_FEATURES`` does not negotiate +``VHOST_USER_F_PROTOCOL_FEATURES``, rings are enabled immediately when +started. + +If ``VHOST_USER_SET_FEATURES`` does negotiate +``VHOST_USER_F_PROTOCOL_FEATURES``, each ring will remain in the disabled +state until ``VHOST_USER_SET_VRING_ENABLE`` enables it with parameter 1. + +Back-end implementations that support ``VHOST_USER_F_PROTOCOL_FEATURES`` +should implement this by initializing each ring in a disabled state, and +enabling them when ``VHOST_USER_SET_FEATURES`` is used without +negotiating ``VHOST_USER_F_PROTOCOL_FEATURES``. Other than that, rings +should only be enabled and disabled through +``VHOST_USER_SET_VRING_ENABLE``. =20 While processing the rings (whether they are enabled or not), the back-end must support changing some configuration aspects on the fly. --=20 2.41.0 From nobody Sat May 18 15:49:41 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1694773657; cv=none; d=zohomail.com; s=zohoarc; b=NL5ZWkMCUmORj8MsHVDhjSt4rVTM6myvSw0b3OoJ1dXt/kyf9Qdn6byBQ+uZem3FJ7MfRmKlK/6sdWheHBOTpfjtzoKwHivesMYmJYEL7vX9v712vuRtcV2STW3f6SB2eoIunu4qE4oEwz6nkaqJ3BJyXXpqZHSAj8auSJRzmww= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694773657; 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; bh=6sjGZIMTmJKs3XIu8dJnVUl2JxeBc+Ybc6wifhB9tGM=; b=UkGIfsj3rFBwvvYZ/nq2fKYwvySj6wy0lL5h34ad8IUjACqwkfCOjS6570O/UrOChHRKd6IjZoi2Vst68gZbaNUqa24cKAnl2dyAH/TnrOVLI5wxJWyxYmEjLCNIzts7ghBFtkYELXbY+GugbdQnmUq080OCHe3xiM9LxzI6f7g= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1694773657343250.39550019677813; Fri, 15 Sep 2023 03:27:37 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh61o-0007AF-Eq; Fri, 15 Sep 2023 06:26:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh61E-0006cf-67 for qemu-devel@nongnu.org; Fri, 15 Sep 2023 06:25:54 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh61A-0002nY-AC for qemu-devel@nongnu.org; Fri, 15 Sep 2023 06:25:47 -0400 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-658-ggpA_kF2MmmLjSZufZpujw-1; Fri, 15 Sep 2023 06:25:39 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B808E811E7E for ; Fri, 15 Sep 2023 10:25:38 +0000 (UTC) Received: from localhost (unknown [10.39.194.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AECD82026D4B; Fri, 15 Sep 2023 10:25:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694773542; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6sjGZIMTmJKs3XIu8dJnVUl2JxeBc+Ybc6wifhB9tGM=; b=aZ6CzU0Tk4T4bVy90oOYGTWSUMgsrcmnPZKBo05cIXOG3Oi1wwAh4zsa7daKn3A3pbSI09 wDsQhmK2V3FNXRrz9FICwt030rX6omZUeLvp0+68qOvLDUaT+iviDJxCtpYjomfFau7hrp BbEjoPMMomV0UpLfRURPtFGzI/Ks2bE= X-MC-Unique: ggpA_kF2MmmLjSZufZpujw-1 From: Hanna Czenczek To: qemu-devel@nongnu.org, virtio-fs@redhat.com Cc: Hanna Czenczek , Stefan Hajnoczi , "Michael S . Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , German Maglione Subject: [PATCH v3 3/5] vhost-user: Interface for migration state transfer Date: Fri, 15 Sep 2023 12:25:28 +0200 Message-ID: <20230915102531.55894-4-hreitz@redhat.com> In-Reply-To: <20230915102531.55894-1-hreitz@redhat.com> References: <20230915102531.55894-1-hreitz@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 Received-SPF: pass (zohomail.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; Received-SPF: pass client-ip=170.10.133.124; envelope-from=hreitz@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1694773658586100003 Content-Type: text/plain; charset="utf-8" Add the interface for transferring the back-end's state during migration as defined previously in vhost-user.rst. Signed-off-by: Hanna Czenczek Reviewed-by: Stefan Hajnoczi --- include/hw/virtio/vhost-backend.h | 24 +++++ include/hw/virtio/vhost.h | 79 ++++++++++++++++ hw/virtio/vhost-user.c | 148 ++++++++++++++++++++++++++++++ hw/virtio/vhost.c | 37 ++++++++ 4 files changed, 288 insertions(+) diff --git a/include/hw/virtio/vhost-backend.h b/include/hw/virtio/vhost-ba= ckend.h index 31a251a9f5..b6eee7e9fd 100644 --- a/include/hw/virtio/vhost-backend.h +++ b/include/hw/virtio/vhost-backend.h @@ -26,6 +26,18 @@ typedef enum VhostSetConfigType { VHOST_SET_CONFIG_TYPE_MIGRATION =3D 1, } VhostSetConfigType; =20 +typedef enum VhostDeviceStateDirection { + /* Transfer state from back-end (device) to front-end */ + VHOST_TRANSFER_STATE_DIRECTION_SAVE =3D 0, + /* Transfer state from front-end to back-end (device) */ + VHOST_TRANSFER_STATE_DIRECTION_LOAD =3D 1, +} VhostDeviceStateDirection; + +typedef enum VhostDeviceStatePhase { + /* The device (and all its vrings) is stopped */ + VHOST_TRANSFER_STATE_PHASE_STOPPED =3D 0, +} VhostDeviceStatePhase; + struct vhost_inflight; struct vhost_dev; struct vhost_log; @@ -133,6 +145,15 @@ typedef int (*vhost_set_config_call_op)(struct vhost_d= ev *dev, =20 typedef void (*vhost_reset_status_op)(struct vhost_dev *dev); =20 +typedef bool (*vhost_supports_device_state_op)(struct vhost_dev *dev); +typedef int (*vhost_set_device_state_fd_op)(struct vhost_dev *dev, + VhostDeviceStateDirection dire= ction, + VhostDeviceStatePhase phase, + int fd, + int *reply_fd, + Error **errp); +typedef int (*vhost_check_device_state_op)(struct vhost_dev *dev, Error **= errp); + typedef struct VhostOps { VhostBackendType backend_type; vhost_backend_init vhost_backend_init; @@ -181,6 +202,9 @@ typedef struct VhostOps { vhost_force_iommu_op vhost_force_iommu; vhost_set_config_call_op vhost_set_config_call; vhost_reset_status_op vhost_reset_status; + vhost_supports_device_state_op vhost_supports_device_state; + vhost_set_device_state_fd_op vhost_set_device_state_fd; + vhost_check_device_state_op vhost_check_device_state; } VhostOps; =20 int vhost_backend_update_device_iotlb(struct vhost_dev *dev, diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h index 6a173cb9fa..f4e19aae8b 100644 --- a/include/hw/virtio/vhost.h +++ b/include/hw/virtio/vhost.h @@ -338,4 +338,83 @@ int vhost_dev_set_inflight(struct vhost_dev *dev, int vhost_dev_get_inflight(struct vhost_dev *dev, uint16_t queue_size, struct vhost_inflight *inflight); bool vhost_dev_has_iommu(struct vhost_dev *dev); + +/** + * vhost_supports_device_state(): Checks whether the back-end supports + * transferring internal device state for the purpose of migration. + * Support for this feature is required for vhost_set_device_state_fd() + * and vhost_check_device_state(). + * + * @dev: The vhost device + * + * Returns true if the device supports these commands, and false if it + * does not. + */ +bool vhost_supports_device_state(struct vhost_dev *dev); + +/** + * vhost_set_device_state_fd(): Begin transfer of internal state from/to + * the back-end for the purpose of migration. Data is to be transferred + * over a pipe according to @direction and @phase. The sending end must + * only write to the pipe, and the receiving end must only read from it. + * Once the sending end is done, it closes its FD. The receiving end + * must take this as the end-of-transfer signal and close its FD, too. + * + * @fd is the back-end's end of the pipe: The write FD for SAVE, and the + * read FD for LOAD. This function transfers ownership of @fd to the + * back-end, i.e. closes it in the front-end. + * + * The back-end may optionally reply with an FD of its own, if this + * improves efficiency on its end. In this case, the returned FD is + * stored in *reply_fd. The back-end will discard the FD sent to it, + * and the front-end must use *reply_fd for transferring state to/from + * the back-end. + * + * @dev: The vhost device + * @direction: The direction in which the state is to be transferred. + * For outgoing migrations, this is SAVE, and data is read + * from the back-end and stored by the front-end in the + * migration stream. + * For incoming migrations, this is LOAD, and data is read + * by the front-end from the migration stream and sent to + * the back-end to restore the saved state. + * @phase: Which migration phase we are in. Currently, there is only + * STOPPED (device and all vrings are stopped), in the future, + * more phases such as PRE_COPY or POST_COPY may be added. + * @fd: Back-end's end of the pipe through which to transfer state; note + * that ownership is transferred to the back-end, so this function + * closes @fd in the front-end. + * @reply_fd: If the back-end wishes to use a different pipe for state + * transfer, this will contain an FD for the front-end to + * use. Otherwise, -1 is stored here. + * @errp: Potential error description + * + * Returns 0 on success, and -errno on failure. + */ +int vhost_set_device_state_fd(struct vhost_dev *dev, + VhostDeviceStateDirection direction, + VhostDeviceStatePhase phase, + int fd, + int *reply_fd, + Error **errp); + +/** + * vhost_set_device_state_fd(): After transferring state from/to the + * back-end via vhost_set_device_state_fd(), i.e. once the sending end + * has closed the pipe, inquire the back-end to report any potential + * errors that have occurred on its side. This allows to sense errors + * like: + * - During outgoing migration, when the source side had already started + * to produce its state, something went wrong and it failed to finish + * - During incoming migration, when the received state is somehow + * invalid and cannot be processed by the back-end + * + * @dev: The vhost device + * @errp: Potential error description + * + * Returns 0 when the back-end reports successful state transfer and + * processing, and -errno when an error occurred somewhere. + */ +int vhost_check_device_state(struct vhost_dev *dev, Error **errp); + #endif diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c index 8dcf049d42..3cdde543fa 100644 --- a/hw/virtio/vhost-user.c +++ b/hw/virtio/vhost-user.c @@ -74,6 +74,8 @@ enum VhostUserProtocolFeature { /* Feature 14 reserved for VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS.= */ VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS =3D 15, VHOST_USER_PROTOCOL_F_STATUS =3D 16, + /* Feature 17 reserved for VHOST_USER_PROTOCOL_F_XEN_MMAP. */ + VHOST_USER_PROTOCOL_F_DEVICE_STATE =3D 18, VHOST_USER_PROTOCOL_F_MAX }; =20 @@ -121,6 +123,8 @@ typedef enum VhostUserRequest { VHOST_USER_REM_MEM_REG =3D 38, VHOST_USER_SET_STATUS =3D 39, VHOST_USER_GET_STATUS =3D 40, + VHOST_USER_SET_DEVICE_STATE_FD =3D 41, + VHOST_USER_CHECK_DEVICE_STATE =3D 42, VHOST_USER_MAX } VhostUserRequest; =20 @@ -212,6 +216,12 @@ typedef struct { uint32_t size; /* the following payload size */ } QEMU_PACKED VhostUserHeader; =20 +/* Request payload of VHOST_USER_SET_DEVICE_STATE_FD */ +typedef struct VhostUserTransferDeviceState { + uint32_t direction; + uint32_t phase; +} VhostUserTransferDeviceState; + typedef union { #define VHOST_USER_VRING_IDX_MASK (0xff) #define VHOST_USER_VRING_NOFD_MASK (0x1 << 8) @@ -226,6 +236,7 @@ typedef union { VhostUserCryptoSession session; VhostUserVringArea area; VhostUserInflight inflight; + VhostUserTransferDeviceState transfer_state; } VhostUserPayload; =20 typedef struct VhostUserMsg { @@ -2741,6 +2752,140 @@ static void vhost_user_reset_status(struct vhost_de= v *dev) } } =20 +static bool vhost_user_supports_device_state(struct vhost_dev *dev) +{ + return virtio_has_feature(dev->protocol_features, + VHOST_USER_PROTOCOL_F_DEVICE_STATE); +} + +static int vhost_user_set_device_state_fd(struct vhost_dev *dev, + VhostDeviceStateDirection direct= ion, + VhostDeviceStatePhase phase, + int fd, + int *reply_fd, + Error **errp) +{ + int ret; + struct vhost_user *vu =3D dev->opaque; + VhostUserMsg msg =3D { + .hdr =3D { + .request =3D VHOST_USER_SET_DEVICE_STATE_FD, + .flags =3D VHOST_USER_VERSION, + .size =3D sizeof(msg.payload.transfer_state), + }, + .payload.transfer_state =3D { + .direction =3D direction, + .phase =3D phase, + }, + }; + + *reply_fd =3D -1; + + if (!vhost_user_supports_device_state(dev)) { + close(fd); + error_setg(errp, "Back-end does not support migration state transf= er"); + return -ENOTSUP; + } + + ret =3D vhost_user_write(dev, &msg, &fd, 1); + close(fd); + if (ret < 0) { + error_setg_errno(errp, -ret, + "Failed to send SET_DEVICE_STATE_FD message"); + return ret; + } + + ret =3D vhost_user_read(dev, &msg); + if (ret < 0) { + error_setg_errno(errp, -ret, + "Failed to receive SET_DEVICE_STATE_FD reply"); + return ret; + } + + if (msg.hdr.request !=3D VHOST_USER_SET_DEVICE_STATE_FD) { + error_setg(errp, + "Received unexpected message type, expected %d, receive= d %d", + VHOST_USER_SET_DEVICE_STATE_FD, msg.hdr.request); + return -EPROTO; + } + + if (msg.hdr.size !=3D sizeof(msg.payload.u64)) { + error_setg(errp, + "Received bad message size, expected %zu, received %" P= RIu32, + sizeof(msg.payload.u64), msg.hdr.size); + return -EPROTO; + } + + if ((msg.payload.u64 & 0xff) !=3D 0) { + error_setg(errp, "Back-end did not accept migration state transfer= "); + return -EIO; + } + + if (!(msg.payload.u64 & VHOST_USER_VRING_NOFD_MASK)) { + *reply_fd =3D qemu_chr_fe_get_msgfd(vu->user->chr); + if (*reply_fd < 0) { + error_setg(errp, + "Failed to get back-end-provided transfer pipe FD"); + *reply_fd =3D -1; + return -EIO; + } + } + + return 0; +} + +static int vhost_user_check_device_state(struct vhost_dev *dev, Error **er= rp) +{ + int ret; + VhostUserMsg msg =3D { + .hdr =3D { + .request =3D VHOST_USER_CHECK_DEVICE_STATE, + .flags =3D VHOST_USER_VERSION, + .size =3D 0, + }, + }; + + if (!vhost_user_supports_device_state(dev)) { + error_setg(errp, "Back-end does not support migration state transf= er"); + return -ENOTSUP; + } + + ret =3D vhost_user_write(dev, &msg, NULL, 0); + if (ret < 0) { + error_setg_errno(errp, -ret, + "Failed to send CHECK_DEVICE_STATE message"); + return ret; + } + + ret =3D vhost_user_read(dev, &msg); + if (ret < 0) { + error_setg_errno(errp, -ret, + "Failed to receive CHECK_DEVICE_STATE reply"); + return ret; + } + + if (msg.hdr.request !=3D VHOST_USER_CHECK_DEVICE_STATE) { + error_setg(errp, + "Received unexpected message type, expected %d, receive= d %d", + VHOST_USER_CHECK_DEVICE_STATE, msg.hdr.request); + return -EPROTO; + } + + if (msg.hdr.size !=3D sizeof(msg.payload.u64)) { + error_setg(errp, + "Received bad message size, expected %zu, received %" P= RIu32, + sizeof(msg.payload.u64), msg.hdr.size); + return -EPROTO; + } + + if (msg.payload.u64 !=3D 0) { + error_setg(errp, "Back-end failed to process its internal state"); + return -EIO; + } + + return 0; +} + const VhostOps user_ops =3D { .backend_type =3D VHOST_BACKEND_TYPE_USER, .vhost_backend_init =3D vhost_user_backend_init, @@ -2777,4 +2922,7 @@ const VhostOps user_ops =3D { .vhost_set_inflight_fd =3D vhost_user_set_inflight_fd, .vhost_dev_start =3D vhost_user_dev_start, .vhost_reset_status =3D vhost_user_reset_status, + .vhost_supports_device_state =3D vhost_user_supports_device_state, + .vhost_set_device_state_fd =3D vhost_user_set_device_state_fd, + .vhost_check_device_state =3D vhost_user_check_device_state, }; diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c index e2f6ffb446..6d34abec96 100644 --- a/hw/virtio/vhost.c +++ b/hw/virtio/vhost.c @@ -2087,3 +2087,40 @@ int vhost_net_set_backend(struct vhost_dev *hdev, =20 return -ENOSYS; } + +bool vhost_supports_device_state(struct vhost_dev *dev) +{ + if (dev->vhost_ops->vhost_supports_device_state) { + return dev->vhost_ops->vhost_supports_device_state(dev); + } + + return false; +} + +int vhost_set_device_state_fd(struct vhost_dev *dev, + VhostDeviceStateDirection direction, + VhostDeviceStatePhase phase, + int fd, + int *reply_fd, + Error **errp) +{ + if (dev->vhost_ops->vhost_set_device_state_fd) { + return dev->vhost_ops->vhost_set_device_state_fd(dev, direction, p= hase, + fd, reply_fd, err= p); + } + + error_setg(errp, + "vhost transport does not support migration state transfer"= ); + return -ENOSYS; +} + +int vhost_check_device_state(struct vhost_dev *dev, Error **errp) +{ + if (dev->vhost_ops->vhost_check_device_state) { + return dev->vhost_ops->vhost_check_device_state(dev, errp); + } + + error_setg(errp, + "vhost transport does not support migration state transfer"= ); + return -ENOSYS; +} --=20 2.41.0 From nobody Sat May 18 15:49:41 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1694773627; cv=none; d=zohomail.com; s=zohoarc; b=cCKLEUfin41RZz/g8fYnOOIE0GlEwfgPa1pLNGm/kNHyDyA6azvS3J9fM9We089C7ynqQ47p/hAwFTLsp0ezH4mVK1JNfYPci7mgSVz11okQsEpaiYIDiq8Wd/XjooL5M7xmD8d/sn3lgTJ0l/xHjGGmKl64KqknASvdJReg2OY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694773627; 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; bh=hzce+XPdZ3BiWGqajalU9GNFiQuTbGCKrobaq4PB8Dc=; b=MzfzF7evU8HKz0BJzyfsLChBkd3/2sFXqVa2oW2bljET/w8zqtFejITeG1dIIMfi4RxHUQRmRko/bGxTLwcgd22mw/Io6whXUr4oZMK+HpgilAdjqXKR25KGLzaIGB1svrZOYmQBTbZDRxgP4+nkAGJIn4nOwejamYzfjNNJzYk= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1694773627727139.2941935305737; Fri, 15 Sep 2023 03:27:07 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh61i-000722-CY; Fri, 15 Sep 2023 06:26:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh61D-0006cd-TX for qemu-devel@nongnu.org; Fri, 15 Sep 2023 06:25:51 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh61B-0002nc-E5 for qemu-devel@nongnu.org; Fri, 15 Sep 2023 06:25:47 -0400 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-158-jEIO9i1BNGqfoZOBDlTFkg-1; Fri, 15 Sep 2023 06:25:41 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1A95E85A5A8 for ; Fri, 15 Sep 2023 10:25:41 +0000 (UTC) Received: from localhost (unknown [10.39.194.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 97D5F409AFC1; Fri, 15 Sep 2023 10:25:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694773542; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hzce+XPdZ3BiWGqajalU9GNFiQuTbGCKrobaq4PB8Dc=; b=IiZ4GbKC1pkzK49rKBnMH/IZbXqbdFLVtgKRq1SuxxVffut5qDPK5A9eHsTyw+0aFYBGRA C3CzogDTlw5wFA9q4/7nGupDm4s1Eqdgj0/lkiXC95y+KB6p1c+hxcORGTFcZWIXX0dFMt PRUTQj2wv+uyW5hiEkOxU9bzBtlz/90= X-MC-Unique: jEIO9i1BNGqfoZOBDlTFkg-1 From: Hanna Czenczek To: qemu-devel@nongnu.org, virtio-fs@redhat.com Cc: Hanna Czenczek , Stefan Hajnoczi , "Michael S . Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , German Maglione Subject: [PATCH v3 4/5] vhost: Add high-level state save/load functions Date: Fri, 15 Sep 2023 12:25:29 +0200 Message-ID: <20230915102531.55894-5-hreitz@redhat.com> In-Reply-To: <20230915102531.55894-1-hreitz@redhat.com> References: <20230915102531.55894-1-hreitz@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 Received-SPF: pass (zohomail.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; Received-SPF: pass client-ip=170.10.133.124; envelope-from=hreitz@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1694773628832100001 Content-Type: text/plain; charset="utf-8" vhost_save_backend_state() and vhost_load_backend_state() can be used by vhost front-ends to easily save and load the back-end's state to/from the migration stream. Because we do not know the full state size ahead of time, vhost_save_backend_state() simply reads the data in 1 MB chunks, and writes each chunk consecutively into the migration stream, prefixed by its length. EOF is indicated by a 0-length chunk. Signed-off-by: Hanna Czenczek Reviewed-by: Stefan Hajnoczi --- include/hw/virtio/vhost.h | 35 +++++++ hw/virtio/vhost.c | 204 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 239 insertions(+) diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h index f4e19aae8b..28066ceda1 100644 --- a/include/hw/virtio/vhost.h +++ b/include/hw/virtio/vhost.h @@ -417,4 +417,39 @@ int vhost_set_device_state_fd(struct vhost_dev *dev, */ int vhost_check_device_state(struct vhost_dev *dev, Error **errp); =20 +/** + * vhost_save_backend_state(): High-level function to receive a vhost + * back-end's state, and save it in @f. Uses + * `vhost_set_device_state_fd()` to get the data from the back-end, and + * stores it in consecutive chunks that are each prefixed by their + * respective length (be32). The end is marked by a 0-length chunk. + * + * Must only be called while the device and all its vrings are stopped + * (`VHOST_TRANSFER_STATE_PHASE_STOPPED`). + * + * @dev: The vhost device from which to save the state + * @f: Migration stream in which to save the state + * @errp: Potential error message + * + * Returns 0 on success, and -errno otherwise. + */ +int vhost_save_backend_state(struct vhost_dev *dev, QEMUFile *f, Error **e= rrp); + +/** + * vhost_load_backend_state(): High-level function to load a vhost + * back-end's state from @f, and send it over to the back-end. Reads + * the data from @f in the format used by `vhost_save_state()`, and uses + * `vhost_set_device_state_fd()` to transfer it to the back-end. + * + * Must only be called while the device and all its vrings are stopped + * (`VHOST_TRANSFER_STATE_PHASE_STOPPED`). + * + * @dev: The vhost device to which to send the sate + * @f: Migration stream from which to load the state + * @errp: Potential error message + * + * Returns 0 on success, and -errno otherwise. + */ +int vhost_load_backend_state(struct vhost_dev *dev, QEMUFile *f, Error **e= rrp); + #endif diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c index 6d34abec96..164bd930d3 100644 --- a/hw/virtio/vhost.c +++ b/hw/virtio/vhost.c @@ -2124,3 +2124,207 @@ int vhost_check_device_state(struct vhost_dev *dev,= Error **errp) "vhost transport does not support migration state transfer"= ); return -ENOSYS; } + +int vhost_save_backend_state(struct vhost_dev *dev, QEMUFile *f, Error **e= rrp) +{ + /* Maximum chunk size in which to transfer the state */ + const size_t chunk_size =3D 1 * 1024 * 1024; + g_autofree void *transfer_buf =3D NULL; + g_autoptr(GError) g_err =3D NULL; + int pipe_fds[2], read_fd =3D -1, write_fd =3D -1, reply_fd =3D -1; + int ret; + + /* [0] for reading (our end), [1] for writing (back-end's end) */ + if (!g_unix_open_pipe(pipe_fds, FD_CLOEXEC, &g_err)) { + error_setg(errp, "Failed to set up state transfer pipe: %s", + g_err->message); + ret =3D -EINVAL; + goto fail; + } + + read_fd =3D pipe_fds[0]; + write_fd =3D pipe_fds[1]; + + /* + * VHOST_TRANSFER_STATE_PHASE_STOPPED means the device must be stopped. + * Ideally, it is suspended, but SUSPEND/RESUME currently do not exist= for + * vhost-user, so just check that it is stopped at all. + */ + assert(!dev->started); + + /* Transfer ownership of write_fd to the back-end */ + ret =3D vhost_set_device_state_fd(dev, + VHOST_TRANSFER_STATE_DIRECTION_SAVE, + VHOST_TRANSFER_STATE_PHASE_STOPPED, + write_fd, + &reply_fd, + errp); + if (ret < 0) { + error_prepend(errp, "Failed to initiate state transfer: "); + goto fail; + } + + /* If the back-end wishes to use a different pipe, switch over */ + if (reply_fd >=3D 0) { + close(read_fd); + read_fd =3D reply_fd; + } + + transfer_buf =3D g_malloc(chunk_size); + + while (true) { + ssize_t read_ret; + + read_ret =3D RETRY_ON_EINTR(read(read_fd, transfer_buf, chunk_size= )); + if (read_ret < 0) { + ret =3D -errno; + error_setg_errno(errp, -ret, "Failed to receive state"); + goto fail; + } + + assert(read_ret <=3D chunk_size); + qemu_put_be32(f, read_ret); + + if (read_ret =3D=3D 0) { + /* EOF */ + break; + } + + qemu_put_buffer(f, transfer_buf, read_ret); + } + + /* + * Back-end will not really care, but be clean and close our end of th= e pipe + * before inquiring the back-end about whether transfer was successful + */ + close(read_fd); + read_fd =3D -1; + + /* Also, verify that the device is still stopped */ + assert(!dev->started); + + ret =3D vhost_check_device_state(dev, errp); + if (ret < 0) { + goto fail; + } + + ret =3D 0; +fail: + if (read_fd >=3D 0) { + close(read_fd); + } + + return ret; +} + +int vhost_load_backend_state(struct vhost_dev *dev, QEMUFile *f, Error **e= rrp) +{ + size_t transfer_buf_size =3D 0; + g_autofree void *transfer_buf =3D NULL; + g_autoptr(GError) g_err =3D NULL; + int pipe_fds[2], read_fd =3D -1, write_fd =3D -1, reply_fd =3D -1; + int ret; + + /* [0] for reading (back-end's end), [1] for writing (our end) */ + if (!g_unix_open_pipe(pipe_fds, FD_CLOEXEC, &g_err)) { + error_setg(errp, "Failed to set up state transfer pipe: %s", + g_err->message); + ret =3D -EINVAL; + goto fail; + } + + read_fd =3D pipe_fds[0]; + write_fd =3D pipe_fds[1]; + + /* + * VHOST_TRANSFER_STATE_PHASE_STOPPED means the device must be stopped. + * Ideally, it is suspended, but SUSPEND/RESUME currently do not exist= for + * vhost-user, so just check that it is stopped at all. + */ + assert(!dev->started); + + /* Transfer ownership of read_fd to the back-end */ + ret =3D vhost_set_device_state_fd(dev, + VHOST_TRANSFER_STATE_DIRECTION_LOAD, + VHOST_TRANSFER_STATE_PHASE_STOPPED, + read_fd, + &reply_fd, + errp); + if (ret < 0) { + error_prepend(errp, "Failed to initiate state transfer: "); + goto fail; + } + + /* If the back-end wishes to use a different pipe, switch over */ + if (reply_fd >=3D 0) { + close(write_fd); + write_fd =3D reply_fd; + } + + while (true) { + size_t this_chunk_size =3D qemu_get_be32(f); + ssize_t write_ret; + const uint8_t *transfer_pointer; + + if (this_chunk_size =3D=3D 0) { + /* End of state */ + break; + } + + if (transfer_buf_size < this_chunk_size) { + transfer_buf =3D g_realloc(transfer_buf, this_chunk_size); + transfer_buf_size =3D this_chunk_size; + } + + if (qemu_get_buffer(f, transfer_buf, this_chunk_size) < + this_chunk_size) + { + error_setg(errp, "Failed to read state"); + ret =3D -EINVAL; + goto fail; + } + + transfer_pointer =3D transfer_buf; + while (this_chunk_size > 0) { + write_ret =3D RETRY_ON_EINTR( + write(write_fd, transfer_pointer, this_chunk_size) + ); + if (write_ret < 0) { + ret =3D -errno; + error_setg_errno(errp, -ret, "Failed to send state"); + goto fail; + } else if (write_ret =3D=3D 0) { + error_setg(errp, "Failed to send state: Connection is clos= ed"); + ret =3D -ECONNRESET; + goto fail; + } + + assert(write_ret <=3D this_chunk_size); + this_chunk_size -=3D write_ret; + transfer_pointer +=3D write_ret; + } + } + + /* + * Close our end, thus ending transfer, before inquiring the back-end = about + * whether transfer was successful + */ + close(write_fd); + write_fd =3D -1; + + /* Also, verify that the device is still stopped */ + assert(!dev->started); + + ret =3D vhost_check_device_state(dev, errp); + if (ret < 0) { + goto fail; + } + + ret =3D 0; +fail: + if (write_fd >=3D 0) { + close(write_fd); + } + + return ret; +} --=20 2.41.0 From nobody Sat May 18 15:49:41 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1694773578; cv=none; d=zohomail.com; s=zohoarc; b=G9iTBm1DiE4lw0jyfstFDCeUYgCP7XdPBEALcA+THVd1r2y/pRMNEy1k6fH1ul5bQV4cyHKJ4GILckc7e6jaLBsYe4QRGGZZFDwm+LOAi1c3UhS7eVZFZJ5SLryseiX+DCPxWAxD0vLfuTQ7EuqNmDxqlZizoSWAklQxAcw0z4A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694773578; 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; bh=9ZBkpqxm+T7IKVbIYYr65BEU4VvEReH0vO+YG9VbRzk=; b=j/J6P2XV0KalcXTat+tF1UZfMx8r5UpexBrDb0QkApkCoeFZDx39pqyytZ5pPl/suoCnnbCHsN4oxy6OA3wngmU7+biQ4eL5vVkmW5PZdOkeFZMP0qMcFi6n7qlLNvBGpdUhDQc3z4GIsc7IhKT5Mze3yD8zVMCFyGqRUBjXYqo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1694773578393537.6860355809142; Fri, 15 Sep 2023 03:26:18 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh61Z-0006wF-47; Fri, 15 Sep 2023 06:26:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh61D-0006cb-NA for qemu-devel@nongnu.org; Fri, 15 Sep 2023 06:25:51 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh61B-0002o6-Fz for qemu-devel@nongnu.org; Fri, 15 Sep 2023 06:25:47 -0400 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-643-fMAL9KAgMeGLHv5tfHqwHQ-1; Fri, 15 Sep 2023 06:25:43 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AA048101B043 for ; Fri, 15 Sep 2023 10:25:42 +0000 (UTC) Received: from localhost (unknown [10.39.194.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 51CF310F1BEA; Fri, 15 Sep 2023 10:25:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694773544; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9ZBkpqxm+T7IKVbIYYr65BEU4VvEReH0vO+YG9VbRzk=; b=jMtBcDZ5clciQ95GwXIOr4S92E7HgZ68+SSLp52QTedCr5RuD+s8t5Gp6lpLOdo425VyvM cI8A32jDudjoPptpbnTDhppOMzaVBfh6dQeVzDabMkZjcoqi/XUkE+texjMYrrmhLs+cQa nByuhwZw9+9dho6kdzpvYdHJcOWWPx4= X-MC-Unique: fMAL9KAgMeGLHv5tfHqwHQ-1 From: Hanna Czenczek To: qemu-devel@nongnu.org, virtio-fs@redhat.com Cc: Hanna Czenczek , Stefan Hajnoczi , "Michael S . Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , German Maglione Subject: [PATCH v3 5/5] vhost-user-fs: Implement internal migration Date: Fri, 15 Sep 2023 12:25:30 +0200 Message-ID: <20230915102531.55894-6-hreitz@redhat.com> In-Reply-To: <20230915102531.55894-1-hreitz@redhat.com> References: <20230915102531.55894-1-hreitz@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 Received-SPF: pass (zohomail.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; Received-SPF: pass client-ip=170.10.129.124; envelope-from=hreitz@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1694773580003100003 Content-Type: text/plain; charset="utf-8" A virtio-fs device's VM state consists of: - the virtio device (vring) state (VMSTATE_VIRTIO_DEVICE) - the back-end's (virtiofsd's) internal state We get/set the latter via the new vhost operations to transfer migratory state. It is its own dedicated subsection, so that for external migration, it can be disabled. Reviewed-by: Stefan Hajnoczi Signed-off-by: Hanna Czenczek --- hw/virtio/vhost-user-fs.c | 101 +++++++++++++++++++++++++++++++++++++- 1 file changed, 100 insertions(+), 1 deletion(-) diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c index 49d699ffc2..eb91723855 100644 --- a/hw/virtio/vhost-user-fs.c +++ b/hw/virtio/vhost-user-fs.c @@ -298,9 +298,108 @@ static struct vhost_dev *vuf_get_vhost(VirtIODevice *= vdev) return &fs->vhost_dev; } =20 +/** + * Fetch the internal state from virtiofsd and save it to `f`. + */ +static int vuf_save_state(QEMUFile *f, void *pv, size_t size, + const VMStateField *field, JSONWriter *vmdesc) +{ + VirtIODevice *vdev =3D pv; + VHostUserFS *fs =3D VHOST_USER_FS(vdev); + Error *local_error =3D NULL; + int ret; + + ret =3D vhost_save_backend_state(&fs->vhost_dev, f, &local_error); + if (ret < 0) { + error_reportf_err(local_error, + "Error saving back-end state of %s device %s " + "(tag: \"%s\"): ", + vdev->name, vdev->parent_obj.canonical_path, + fs->conf.tag ?: ""); + return ret; + } + + return 0; +} + +/** + * Load virtiofsd's internal state from `f` and send it over to virtiofsd. + */ +static int vuf_load_state(QEMUFile *f, void *pv, size_t size, + const VMStateField *field) +{ + VirtIODevice *vdev =3D pv; + VHostUserFS *fs =3D VHOST_USER_FS(vdev); + Error *local_error =3D NULL; + int ret; + + ret =3D vhost_load_backend_state(&fs->vhost_dev, f, &local_error); + if (ret < 0) { + error_reportf_err(local_error, + "Error loading back-end state of %s device %s " + "(tag: \"%s\"): ", + vdev->name, vdev->parent_obj.canonical_path, + fs->conf.tag ?: ""); + return ret; + } + + return 0; +} + +static bool vuf_is_internal_migration(void *opaque) +{ + /* TODO: Return false when an external migration is requested */ + return true; +} + +static int vuf_check_migration_support(void *opaque) +{ + VirtIODevice *vdev =3D opaque; + VHostUserFS *fs =3D VHOST_USER_FS(vdev); + + if (!vhost_supports_device_state(&fs->vhost_dev)) { + error_report("Back-end of %s device %s (tag: \"%s\") does not supp= ort " + "migration through qemu", + vdev->name, vdev->parent_obj.canonical_path, + fs->conf.tag ?: ""); + return -ENOTSUP; + } + + return 0; +} + +static const VMStateDescription vuf_backend_vmstate; + static const VMStateDescription vuf_vmstate =3D { .name =3D "vhost-user-fs", - .unmigratable =3D 1, + .version_id =3D 0, + .fields =3D (VMStateField[]) { + VMSTATE_VIRTIO_DEVICE, + VMSTATE_END_OF_LIST() + }, + .subsections =3D (const VMStateDescription * []) { + &vuf_backend_vmstate, + NULL, + } +}; + +static const VMStateDescription vuf_backend_vmstate =3D { + .name =3D "vhost-user-fs-backend", + .version_id =3D 0, + .needed =3D vuf_is_internal_migration, + .pre_load =3D vuf_check_migration_support, + .pre_save =3D vuf_check_migration_support, + .fields =3D (VMStateField[]) { + { + .name =3D "back-end", + .info =3D &(const VMStateInfo) { + .name =3D "virtio-fs back-end state", + .get =3D vuf_load_state, + .put =3D vuf_save_state, + }, + }, + VMSTATE_END_OF_LIST() + }, }; =20 static Property vuf_properties[] =3D { --=20 2.41.0