From patchwork Thu Jul 6 19:12:21 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: 13304082 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 AED0CEB64DD for ; Thu, 6 Jul 2023 19:14:14 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHUPC-000635-4p; Thu, 06 Jul 2023 15:12:42 -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 1qHUPA-00062X-Ln for qemu-devel@nongnu.org; Thu, 06 Jul 2023 15:12:40 -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 1qHUP8-0003es-Ox for qemu-devel@nongnu.org; Thu, 06 Jul 2023 15:12:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688670757; 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=vA6VZraYIjzYxbDaNGvgiO66f1LsbKPy5Fs8TnSWCfc=; b=PMBBCfOMC+MzGERS8NGN9BNvZOPuPmDlxSnQABerAV8sAU9efhnXrCTx+Qnhh3+fsy69Bz c8LctgV5L+5M8u83R+SBrna5hJa/SjWMmIzPGzG3x2M7LLW/HhmgCmcg5fKX/LpiB1RGko trY2A17TYS//zcQZrHPTeFSLq0Bfb/Q= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-144-vesBVK-pMMSneZNQ3gvWqQ-1; Thu, 06 Jul 2023 15:12:32 -0400 X-MC-Unique: vesBVK-pMMSneZNQ3gvWqQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 615553C100BD; Thu, 6 Jul 2023 19:12:31 +0000 (UTC) Received: from eperezma.remote.csb (unknown [10.39.194.147]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1D46F4087C6A; Thu, 6 Jul 2023 19:12:28 +0000 (UTC) From: =?utf-8?q?Eugenio_P=C3=A9rez?= To: qemu-devel@nongnu.org Cc: Laurent Vivier , "Michael S. Tsirkin" , Cindy Lu , si-wei.liu@oracle.com, Stefano Garzarella , Shannon Nelson , Gautam Dawar , Jason Wang , Harpreet Singh Anand , Parav Pandit , Dragos Tatulea , Zhu Lingshan , Lei Yang Subject: [RFC PATCH 0/6] Enable vdpa net migration with features depending on CVQ Date: Thu, 6 Jul 2023 21:12:21 +0200 Message-Id: <20230706191227.835526-1-eperezma@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 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, T_SCC_BODY_TEXT_LINE=-0.01 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 RFC lift that requirement, sending the VHOST_VDPA_SET_VRING_ENABLE ioctl for dataplane vqs only after the device has processed all commands. If this method is valid or not, or if it must be signalled by the parent driver somehow, is still under discussion. In case it is valid, this code allows testing the vDPA device for it. Eugenio Pérez (6): vdpa: export vhost_vdpa_set_vring_ready vdpa: add should_enable op vdpa: use virtio_ops->should_enable at vhost_vdpa_set_vrings_ready vdpa: add stub vhost_vdpa_should_enable vdpa: delay enable of data vqs vdpa: remove net cvq migration blocker include/hw/virtio/vhost-vdpa.h | 9 +++++++ hw/virtio/vhost-vdpa.c | 33 +++++++++++++++++++------ net/vhost-vdpa.c | 45 +++++++++++++++++++++++++--------- hw/virtio/trace-events | 2 +- 4 files changed, 68 insertions(+), 21 deletions(-)