Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp7931298ioo; Fri, 3 Jun 2022 17:20:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5txIP3LOYgzWRPqQF8l7Ajcf4Pyt8Q1E4fmR6Ujt20S9EmJqs7BLg8oCVhNRNbCZO95is X-Received: by 2002:a05:6402:1e88:b0:42f:b1ff:7858 with SMTP id f8-20020a0564021e8800b0042fb1ff7858mr3052535edf.407.1654302049949; Fri, 03 Jun 2022 17:20:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654302049; cv=none; d=google.com; s=arc-20160816; b=zthXMxC8FGKai9ziLy2ovzdrogEj0M5QhT7BRAUmAcQBlvemw/git5lzCg44LOJB6B OKLzsBi+9HxUADowi/c1IIbnvJI0GBOkrnSmmhCYGzxo/Cicfv9xc3nkUMy9IKtobppm +CIWsYoEn2edAp/lgvmB8twZqmGSTrrTWYreaS8qib76gD73kWvFzc6Bh/oIE+Oz8mtS 7FXvNv0DX7VUPSeYJyW53cNDRMdQg6BTCHgvkjCi7XvbiXOw0Tfk/QTLf0MJFMUCQ+n/ p0EzEmcYc1p+mrz1oItp2OjLiGchPYXAd6luE+Ibvpv+hV4EehYQD5MpVm/Mqueo6FXZ D6TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=VJfV/hotJTL7ZePv0RbAazmYZHrUQpKxi4Jb173Q20w=; b=Ecodb7tgRgJUYaHZ/TqZ1aR0XdaYgmp+0B914R1dr32BUzVI4vY0lDFnQJuj5qDc0+ +MXmEWwFlCU4jJz3oTILU19S77AR4QqDHwyhl8zIA2rn+4H3xcqJXFyEM8bGhjmTn45r a57dzv5r0dd6bTwEnOSa356iLYQuKVsqa0jVoWnVlDOfc4HOIhiHwxFdahJbP4kMUWa2 90NRK/hKHlFfWBKplGvoFOqOR9kWwDdMZp4vNwx5q/p9RVkt9RUMxdw1gefw7KA/wHU6 bL/LjOL6QPgpiGlV0NjDnzN3R9gKKj9krp6lw2Gh4UUTxOKwmMo/lqS1ySPmVx/3Ev3h o3BQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Owgufx5o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t17-20020a50ab51000000b0042b6529b4fesi1847717edc.483.2022.06.03.17.20.13; Fri, 03 Jun 2022 17:20:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Owgufx5o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243504AbiFCKKv (ORCPT + 99 others); Fri, 3 Jun 2022 06:10:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46258 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243393AbiFCKKi (ORCPT ); Fri, 3 Jun 2022 06:10:38 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6B4523B3FB for ; Fri, 3 Jun 2022 03:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654251025; 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=VJfV/hotJTL7ZePv0RbAazmYZHrUQpKxi4Jb173Q20w=; b=Owgufx5oHAQ/94ZPzQ3GtGh6WRkfhSgqE6A54U/HjhLhBkX7/4QFtfjf7xduIxd33sRLIR WXdqXH95X0XE2IVbpYahZSypcViks9jcqVEszAjgad8DWPiGIFGCAvyiqM+g4jJ0IZ3RkK TFXQiIyu7BzUZBkZVVJxvTsYGiOTyJw= 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-619-y528ceswNBifW8e9WJwpEQ-1; Fri, 03 Jun 2022 06:10:21 -0400 X-MC-Unique: y528ceswNBifW8e9WJwpEQ-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4ABF038005D1; Fri, 3 Jun 2022 10:10:09 +0000 (UTC) Received: from eperezma.remote.csb (unknown [10.40.192.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id 39019492C3B; Fri, 3 Jun 2022 10:10:04 +0000 (UTC) From: =?UTF-8?q?Eugenio=20P=C3=A9rez?= To: kvm@vger.kernel.org, Jason Wang , "Michael S. Tsirkin" , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org Cc: Christophe JAILLET , Longpeng , Stefano Garzarella , dinang@xilinx.com, Piotr.Uminski@intel.com, martinpo@xilinx.com, tanuj.kamde@amd.com, Parav Pandit , Zhang Min , habetsm.xilinx@gmail.com, Zhu Lingshan , lulu@redhat.com, hanand@xilinx.com, martinh@xilinx.com, Si-Wei Liu , gautam.dawar@amd.com, Xie Yongji , ecree.xilinx@gmail.com, pabloc@xilinx.com, lvivier@redhat.com, Eli Cohen , Wu Zongyong , Dan Carpenter Subject: [PATCH v5 3/4] vhost-vdpa: uAPI to suspend the device Date: Fri, 3 Jun 2022 12:09:43 +0200 Message-Id: <20220603100944.871727-4-eperezma@redhat.com> In-Reply-To: <20220603100944.871727-1-eperezma@redhat.com> References: <20220603100944.871727-1-eperezma@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The ioctl adds support for suspending the device from userspace. This is a must before getting virtqueue indexes (base) for live migration, since the device could modify them after userland gets them. There are individual ways to perform that action for some devices (VHOST_NET_SET_BACKEND, VHOST_VSOCK_SET_RUNNING, ...) but there was no way to perform it for any vhost device (and, in particular, vhost-vdpa). After a successful return of ioctl with suspend = 1, the device must not process more virtqueue descriptors, and it must not send any config interrupt. The device can answer to read or writes of config fields as if it were not suspended. In particular, writing to "queue_enable" with a value of 1 will not make the device start processing buffers of the virtqueue until the device is resumed (suspend = 0). After a successful return of ioctl with suspend = 0, the device will start processing data of the virtqueues if other expected conditions are met (queue is enabled, DRIVER_OK has already been set to status, etc.) If not, the device should be in the same state as if no call to suspend callback with suspend = 1 has been performed. Signed-off-by: Eugenio PĂ©rez --- drivers/vhost/vdpa.c | 31 +++++++++++++++++++++++++++++++ include/uapi/linux/vhost.h | 14 ++++++++++++++ 2 files changed, 45 insertions(+) diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index f4b492526c6f8..cb47c10bbf471 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -478,6 +478,34 @@ static long vhost_vdpa_get_vqs_count(struct vhost_vdpa *v, u32 __user *argp) return 0; } +/* After a successful return of ioctl with suspend = 1, the device must not + * process more virtqueue descriptors, and it must not send any config + * interrupt. The device can answer to read or writes of config fields as if it + * were not suspended. In particular, writing to "queue_enable" with a value of + * 1 will not make the device start processing buffers of the virtqueue until + * the device is resumed (suspend = 0). + * + * After a successful return of ioctl with suspend = 0, the device will start + * processing data of the virtqueues if other expected conditions are met + * (queue is enabled, DRIVER_OK has already been set to status, etc.) If not, + * the device should be in the same state as if no call to suspend callback + * with suspend = 1 has been performed. + */ +static long vhost_vdpa_suspend(struct vhost_vdpa *v, u32 __user *argp) +{ + struct vdpa_device *vdpa = v->vdpa; + const struct vdpa_config_ops *ops = vdpa->config; + int suspend; + + if (!ops->suspend) + return -EOPNOTSUPP; + + if (copy_from_user(&suspend, argp, sizeof(suspend))) + return -EFAULT; + + return ops->suspend(vdpa, suspend); +} + static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd, void __user *argp) { @@ -652,6 +680,9 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep, case VHOST_VDPA_GET_VQS_COUNT: r = vhost_vdpa_get_vqs_count(v, argp); break; + case VHOST_VDPA_SUSPEND: + r = vhost_vdpa_suspend(v, argp); + break; default: r = vhost_dev_ioctl(&v->vdev, cmd, argp); if (r == -ENOIOCTLCMD) diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h index cab645d4a6455..6d9f451631557 100644 --- a/include/uapi/linux/vhost.h +++ b/include/uapi/linux/vhost.h @@ -171,4 +171,18 @@ #define VHOST_VDPA_SET_GROUP_ASID _IOW(VHOST_VIRTIO, 0x7C, \ struct vhost_vring_state) +/* Suspend or resume a device so it does not process virtqueue requests anymore + * + * After the return of ioctl with suspend != 0, the device must finish any + * pending operations like in flight requests. It must also preserve all the + * necessary state (the virtqueue vring base plus the possible device specific + * states) that is required for restoring in the future. The device must not + * change its configuration after that point. + * + * After the return of ioctl with suspend == 0, the device can continue + * processing buffers as long as typical conditions are met (vq is enabled, + * DRIVER_OK status bit is enabled, etc). + */ +#define VHOST_VDPA_SUSPEND _IOW(VHOST_VIRTIO, 0x7D, int) + #endif -- 2.31.1