From patchwork Thu Aug 10 15:36:06 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eugenio Perez Martin X-Patchwork-Id: 13349644 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id C588BC001E0 for ; Thu, 10 Aug 2023 15:38:04 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qU7i7-00052Y-LS; Thu, 10 Aug 2023 11:36:27 -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 1qU7i5-000523-St for qemu-devel@nongnu.org; Thu, 10 Aug 2023 11:36:25 -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 1qU7i4-00038k-1G for qemu-devel@nongnu.org; Thu, 10 Aug 2023 11:36:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691681782; 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; bh=orF9RQE/xpWurBtCFUZqeLc0LA26vBB7/iIuyGwVWI0=; b=C94s7AyxEVCY8fct5FpunAHQowu3oRGnGNbIni2a1AidALnGai3+uM+VOzl7uNQx131ech VgnWYmGLC+zj6+W4Pp9tVgcJlYhVZguJ+LbPN82vUAGNNoHGJW1Bb3L12QdHNa007GBfUA ZpKHKji3uVhQP71v0lzMY1AGl7kxa2A= 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-562-5brm8E8uMrKWVeDwQKg80Q-1; Thu, 10 Aug 2023 11:36:18 -0400 X-MC-Unique: 5brm8E8uMrKWVeDwQKg80Q-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 16750185A78B; Thu, 10 Aug 2023 15:36:18 +0000 (UTC) Received: from eperezma.remote.csb (unknown [10.39.194.195]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4C4522166B28; Thu, 10 Aug 2023 15:36:14 +0000 (UTC) From: =?utf-8?q?Eugenio_P=C3=A9rez?= To: qemu-devel@nongnu.org Cc: Laurent Vivier , Dragos Tatulea , si-wei.liu@oracle.com, Parav Pandit , Gautam Dawar , Zhu Lingshan , "Michael S. Tsirkin" , Cindy Lu , Harpreet Singh Anand , Stefano Garzarella , Jason Wang , Hawkins Jiawei , Shannon Nelson , Lei Yang Subject: [PATCH v2 0/5] Enable vdpa net migration with features depending on CVQ Date: Thu, 10 Aug 2023 17:36:06 +0200 Message-Id: <20230810153611.3410882-1-eperezma@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 Received-SPF: pass client-ip=170.10.133.124; envelope-from=eperezma@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+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org At this moment the migration of net features that depends on CVQ is not possible, as there is no reliable way to restore the device state like mac address, number of enabled queues, etc to the destination. This is mainly caused because the device must only read CVQ, and process all the commands before resuming the dataplane. This series lift that requirement, sending the VHOST_VDPA_SET_VRING_ENABLE ioctl for dataplane vqs only after the device has processed all commands. --- From v1: * Factor out VRING_ENABLE ioctls from vhost_vdpa_dev_start to the caller, instead of providing a callback to know if it must be called or not. * at https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg05447.html From FRC: * Enable vqs early in case CVQ cannot be shadowed. * at https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg01325.html Eugenio Pérez (5): vdpa: use first queue SVQ state for CVQ default vdpa: export vhost_vdpa_set_vring_ready vdpa: rename vhost_vdpa_net_load to vhost_vdpa_net_cvq_load vdpa: move vhost_vdpa_set_vrings_ready to the caller vdpa: remove net cvq migration blocker include/hw/virtio/vhost-vdpa.h | 1 + hw/virtio/vdpa-dev.c | 3 ++ hw/virtio/vhost-vdpa.c | 22 +++++----- net/vhost-vdpa.c | 75 +++++++++++++++++++--------------- hw/virtio/trace-events | 2 +- 5 files changed, 57 insertions(+), 46 deletions(-)