Message ID | 20230912030008.3599514-5-lulu@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9ecd:0:b0:3f2:4152:657d with SMTP id t13csp882216vqx; Tue, 12 Sep 2023 23:13:41 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHIrsHUd3r99iiV8cxkDptBIOFQvutoGuUc1HCh9wBQQ/+Xmxj3iAtRSRxUazsi0fl3rMxp X-Received: by 2002:a05:6870:b406:b0:1d1:425b:802d with SMTP id x6-20020a056870b40600b001d1425b802dmr1872702oap.7.1694585621347; Tue, 12 Sep 2023 23:13:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694585621; cv=none; d=google.com; s=arc-20160816; b=CiFuZv1e4HMdmlJuRE2DGaE5bfP56GZKeaAB+R5Yf3FhJ4jBYzXMX/JuMsICKXsPx2 KLWHtGDPojAQFRw3876lRhMVIrVcm+6V8pB2kSlhfSdNRMKlINy5G4j1KpBXbCWJok+W euHPENQ4cm93kH+0BoFcBNLOPnmiq5W7qvGCWIt4bqG5P3G70hFnyBN8+Jqg9DxUFVeP p8zM0zohCQpIqMgSjoH+xTH+eWBu3o+Mj/I/Tm8tKc9XBCUmIUeFoGhluabWvrNguuhO l0nKYAge3MK2X5IkXtmPuAJcxksV0ac1c2aMPaabzHodamwFpEtEpCCowrAcvVsUY6Qi ss5A== 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=WI0RMvdlyM2CoPU0JPuivhklmmTZZnT8q78FFwqlw28=; fh=E8uCy2UoKRrKjgDakfUdRLlW20LdfkTjtJs3toefLrk=; b=D6KgcMDVLmGS5vwPVeftRC6XRzZwJr0OpouVlKIEPpO5DdFS4zyWldDye2lsXDBH3i VAIGB/qMtimWmS2jIf9cwXAOPKThyCwMUk78d271k80VyS9tZB07a/JW9c05z6q5uSH2 zYgCcJnNXKvd2xnMNXdRt3I3lxvLeVXST9x6NqWQXp5U9aOulUBwgaARFFCaYPVl9cM+ ik9XOnykKpcM1NpIlWgpZ8iQkD3uwk10skt0Dn2kmZEIcVimvr66L713PFFadYtH2Q63 bObEjfOI8HkB50LKWyKExI9T9J5ANSM64+i+YP7uhebSQfWOLHOh99posZGroKZA7u5U Mg5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JfwhkaaV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id h8-20020a636c08000000b00565dd3ea771si9093344pgc.137.2023.09.12.23.13.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 23:13:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JfwhkaaV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 47F7885F6E94; Mon, 11 Sep 2023 21:50:03 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237177AbjILDYx (ORCPT <rfc822;ruipengqi7@gmail.com> + 40 others); Mon, 11 Sep 2023 23:24:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236375AbjILDYd (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 11 Sep 2023 23:24:33 -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 D1C03296FD for <linux-kernel@vger.kernel.org>; Mon, 11 Sep 2023 20:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694487663; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WI0RMvdlyM2CoPU0JPuivhklmmTZZnT8q78FFwqlw28=; b=JfwhkaaVuDHhGVFg6tmhOJhvCGknF15HUKw/0J2yXa3In3K43e3Swptxx0l4WXLnLW226e sYyPUYo6BLLfMLnk70heg746W5cDuXIIZFs+ctLXYHNhRa5gH3euZKo+zPbOK1j5K00y3A GfCE1Lw7qqSjnnWe1WGPdn1TNyPdpec= 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-281-ozpCd5wROgmlUEP7zF_bpA-1; Mon, 11 Sep 2023 23:00:59 -0400 X-MC-Unique: ozpCd5wROgmlUEP7zF_bpA-1 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 488CB803C96; Tue, 12 Sep 2023 03:00:59 +0000 (UTC) Received: from server.redhat.com (unknown [10.72.112.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7725110005D4; Tue, 12 Sep 2023 03:00:55 +0000 (UTC) From: Cindy Lu <lulu@redhat.com> To: lulu@redhat.com, jasowang@redhat.com, mst@redhat.com, maxime.coquelin@redhat.com, xieyongji@bytedance.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org Cc: stable@vger.kernel.org Subject: [RFC v2 4/4] vduse: Add new ioctl VDUSE_GET_RECONNECT_INFO Date: Tue, 12 Sep 2023 11:00:08 +0800 Message-Id: <20230912030008.3599514-5-lulu@redhat.com> In-Reply-To: <20230912030008.3599514-1-lulu@redhat.com> References: <20230912030008.3599514-1-lulu@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 11 Sep 2023 21:50:03 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1776901812381794951 X-GMAIL-MSGID: 1776901812381794951 |
Series |
Support reconnection in vduse
|
|
Commit Message
Cindy Lu
Sept. 12, 2023, 3 a.m. UTC
In VDUSE_GET_RECONNECT_INFO, the Userspace App can get the map size
and The number of mapping memory pages from the kernel. The userspace
App can use this information to map the pages.
Signed-off-by: Cindy Lu <lulu@redhat.com>
---
drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++++++
include/uapi/linux/vduse.h | 15 +++++++++++++++
2 files changed, 30 insertions(+)
Comments
On Tue, Sep 12, 2023 at 11:01 AM Cindy Lu <lulu@redhat.com> wrote: > > In VDUSE_GET_RECONNECT_INFO, the Userspace App can get the map size > and The number of mapping memory pages from the kernel. The userspace > App can use this information to map the pages. > > Signed-off-by: Cindy Lu <lulu@redhat.com> > --- > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++++++ > include/uapi/linux/vduse.h | 15 +++++++++++++++ > 2 files changed, 30 insertions(+) > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c > index 680b23dbdde2..c99f99892b5c 100644 > --- a/drivers/vdpa/vdpa_user/vduse_dev.c > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > @@ -1368,6 +1368,21 @@ static long vduse_dev_ioctl(struct file *file, unsigned int cmd, > ret = 0; > break; > } > + case VDUSE_GET_RECONNECT_INFO: { > + struct vduse_reconnect_mmap_info info; > + > + ret = -EFAULT; > + if (copy_from_user(&info, argp, sizeof(info))) > + break; > + > + info.size = PAGE_SIZE; > + info.max_index = dev->vq_num + 1; > + > + if (copy_to_user(argp, &info, sizeof(info))) > + break; > + ret = 0; > + break; > + } > default: > ret = -ENOIOCTLCMD; > break; > diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h > index d585425803fd..ce55e34f63d7 100644 > --- a/include/uapi/linux/vduse.h > +++ b/include/uapi/linux/vduse.h > @@ -356,4 +356,19 @@ struct vhost_reconnect_vring { > _Bool avail_wrap_counter; > }; > > +/** > + * struct vduse_reconnect_mmap_info > + * @size: mapping memory size, always page_size here > + * @max_index: the number of pages allocated in kernel,just > + * use for check > + */ > + > +struct vduse_reconnect_mmap_info { > + __u32 size; > + __u32 max_index; > +}; One thing I didn't understand is that, aren't the things we used to store connection info belong to uAPI? If not, how can we make sure the connections work across different vendors/implementations. If yes, where? Thanks > + > +#define VDUSE_GET_RECONNECT_INFO \ > + _IOWR(VDUSE_BASE, 0x1b, struct vduse_reconnect_mmap_info) > + > #endif /* _UAPI_VDUSE_H_ */ > -- > 2.34.3 >
On Mon, Sep 18, 2023 at 4:49 PM Jason Wang <jasowang@redhat.com> wrote: > > On Tue, Sep 12, 2023 at 11:01 AM Cindy Lu <lulu@redhat.com> wrote: > > > > In VDUSE_GET_RECONNECT_INFO, the Userspace App can get the map size > > and The number of mapping memory pages from the kernel. The userspace > > App can use this information to map the pages. > > > > Signed-off-by: Cindy Lu <lulu@redhat.com> > > --- > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++++++ > > include/uapi/linux/vduse.h | 15 +++++++++++++++ > > 2 files changed, 30 insertions(+) > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c > > index 680b23dbdde2..c99f99892b5c 100644 > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > > @@ -1368,6 +1368,21 @@ static long vduse_dev_ioctl(struct file *file, unsigned int cmd, > > ret = 0; > > break; > > } > > + case VDUSE_GET_RECONNECT_INFO: { > > + struct vduse_reconnect_mmap_info info; > > + > > + ret = -EFAULT; > > + if (copy_from_user(&info, argp, sizeof(info))) > > + break; > > + > > + info.size = PAGE_SIZE; > > + info.max_index = dev->vq_num + 1; > > + > > + if (copy_to_user(argp, &info, sizeof(info))) > > + break; > > + ret = 0; > > + break; > > + } > > default: > > ret = -ENOIOCTLCMD; > > break; > > diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h > > index d585425803fd..ce55e34f63d7 100644 > > --- a/include/uapi/linux/vduse.h > > +++ b/include/uapi/linux/vduse.h > > @@ -356,4 +356,19 @@ struct vhost_reconnect_vring { > > _Bool avail_wrap_counter; > > }; > > > > +/** > > + * struct vduse_reconnect_mmap_info > > + * @size: mapping memory size, always page_size here > > + * @max_index: the number of pages allocated in kernel,just > > + * use for check > > + */ > > + > > +struct vduse_reconnect_mmap_info { > > + __u32 size; > > + __u32 max_index; > > +}; > > One thing I didn't understand is that, aren't the things we used to > store connection info belong to uAPI? If not, how can we make sure the > connections work across different vendors/implementations. If yes, > where? > > Thanks > The process for this reconnecttion is A.The first-time connection 1> The userland app checks if the device exists 2> use the ioctl to create the vduse device 3> Mapping the kernel page to userland and save the App-version/features/other information to this page 4> if the Userland app needs to exit, then the Userland app will only unmap the page and then exit B, the re-connection 1> the userland app finds the device is existing 2> Mapping the kernel page to userland 3> check if the information in shared memory is satisfied to reconnect,if ok then continue to reconnect 4> continue working For now these information are all from userland,So here the page will be maintained by the userland App in the previous code we only saved the api-version by uAPI . if we need to support reconnection maybe we need to add 2 new uAPI for this, one of the uAPI is to save the reconnect information and another is to get the information maybe something like struct vhost_reconnect_data { uint32_t version; uint64_t features; uint8_t status; struct virtio_net_config config; uint32_t nr_vrings; }; #define VDUSE_GET_RECONNECT_INFO _IOR (VDUSE_BASE, 0x1c, struct vhost_reconnect_data) #define VDUSE_SET_RECONNECT_INFO _IOWR(VDUSE_BASE, 0x1d, struct vhost_reconnect_data) Thanks Cindy > > + > > +#define VDUSE_GET_RECONNECT_INFO \ > > + _IOWR(VDUSE_BASE, 0x1b, struct vduse_reconnect_mmap_info) > > + > > #endif /* _UAPI_VDUSE_H_ */ > > -- > > 2.34.3 > > >
On Thu, Sep 21, 2023 at 10:07 PM Cindy Lu <lulu@redhat.com> wrote: > > On Mon, Sep 18, 2023 at 4:49 PM Jason Wang <jasowang@redhat.com> wrote: > > > > On Tue, Sep 12, 2023 at 11:01 AM Cindy Lu <lulu@redhat.com> wrote: > > > > > > In VDUSE_GET_RECONNECT_INFO, the Userspace App can get the map size > > > and The number of mapping memory pages from the kernel. The userspace > > > App can use this information to map the pages. > > > > > > Signed-off-by: Cindy Lu <lulu@redhat.com> > > > --- > > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++++++ > > > include/uapi/linux/vduse.h | 15 +++++++++++++++ > > > 2 files changed, 30 insertions(+) > > > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c > > > index 680b23dbdde2..c99f99892b5c 100644 > > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c > > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > > > @@ -1368,6 +1368,21 @@ static long vduse_dev_ioctl(struct file *file, unsigned int cmd, > > > ret = 0; > > > break; > > > } > > > + case VDUSE_GET_RECONNECT_INFO: { > > > + struct vduse_reconnect_mmap_info info; > > > + > > > + ret = -EFAULT; > > > + if (copy_from_user(&info, argp, sizeof(info))) > > > + break; > > > + > > > + info.size = PAGE_SIZE; > > > + info.max_index = dev->vq_num + 1; > > > + > > > + if (copy_to_user(argp, &info, sizeof(info))) > > > + break; > > > + ret = 0; > > > + break; > > > + } > > > default: > > > ret = -ENOIOCTLCMD; > > > break; > > > diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h > > > index d585425803fd..ce55e34f63d7 100644 > > > --- a/include/uapi/linux/vduse.h > > > +++ b/include/uapi/linux/vduse.h > > > @@ -356,4 +356,19 @@ struct vhost_reconnect_vring { > > > _Bool avail_wrap_counter; > > > }; > > > > > > +/** > > > + * struct vduse_reconnect_mmap_info > > > + * @size: mapping memory size, always page_size here > > > + * @max_index: the number of pages allocated in kernel,just > > > + * use for check > > > + */ > > > + > > > +struct vduse_reconnect_mmap_info { > > > + __u32 size; > > > + __u32 max_index; > > > +}; > > > > One thing I didn't understand is that, aren't the things we used to > > store connection info belong to uAPI? If not, how can we make sure the > > connections work across different vendors/implementations. If yes, > > where? > > > > Thanks > > > The process for this reconnecttion is > A.The first-time connection > 1> The userland app checks if the device exists > 2> use the ioctl to create the vduse device > 3> Mapping the kernel page to userland and save the > App-version/features/other information to this page > 4> if the Userland app needs to exit, then the Userland app will only > unmap the page and then exit > > B, the re-connection > 1> the userland app finds the device is existing > 2> Mapping the kernel page to userland > 3> check if the information in shared memory is satisfied to > reconnect,if ok then continue to reconnect > 4> continue working > > For now these information are all from userland,So here the page will > be maintained by the userland App > in the previous code we only saved the api-version by uAPI . if we > need to support reconnection maybe we need to add 2 new uAPI for this, > one of the uAPI is to save the reconnect information and another is > to get the information > > maybe something like > > struct vhost_reconnect_data { > uint32_t version; > uint64_t features; > uint8_t status; > struct virtio_net_config config; > uint32_t nr_vrings; > }; Probably, then we can make sure the re-connection works across different vduse-daemon implementations. > > #define VDUSE_GET_RECONNECT_INFO _IOR (VDUSE_BASE, 0x1c, struct > vhost_reconnect_data) > > #define VDUSE_SET_RECONNECT_INFO _IOWR(VDUSE_BASE, 0x1d, struct > vhost_reconnect_data) Not sure I get this, but the idea is to map those pages to user space, any reason we need this uAPI? Thanks > > Thanks > Cindy > > > > > > > + > > > +#define VDUSE_GET_RECONNECT_INFO \ > > > + _IOWR(VDUSE_BASE, 0x1b, struct vduse_reconnect_mmap_info) > > > + > > > #endif /* _UAPI_VDUSE_H_ */ > > > -- > > > 2.34.3 > > > > > >
On Mon, Sep 25, 2023 at 10:58 AM Jason Wang <jasowang@redhat.com> wrote: > > On Thu, Sep 21, 2023 at 10:07 PM Cindy Lu <lulu@redhat.com> wrote: > > > > On Mon, Sep 18, 2023 at 4:49 PM Jason Wang <jasowang@redhat.com> wrote: > > > > > > On Tue, Sep 12, 2023 at 11:01 AM Cindy Lu <lulu@redhat.com> wrote: > > > > > > > > In VDUSE_GET_RECONNECT_INFO, the Userspace App can get the map size > > > > and The number of mapping memory pages from the kernel. The userspace > > > > App can use this information to map the pages. > > > > > > > > Signed-off-by: Cindy Lu <lulu@redhat.com> > > > > --- > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++++++ > > > > include/uapi/linux/vduse.h | 15 +++++++++++++++ > > > > 2 files changed, 30 insertions(+) > > > > > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c > > > > index 680b23dbdde2..c99f99892b5c 100644 > > > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c > > > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > > > > @@ -1368,6 +1368,21 @@ static long vduse_dev_ioctl(struct file *file, unsigned int cmd, > > > > ret = 0; > > > > break; > > > > } > > > > + case VDUSE_GET_RECONNECT_INFO: { > > > > + struct vduse_reconnect_mmap_info info; > > > > + > > > > + ret = -EFAULT; > > > > + if (copy_from_user(&info, argp, sizeof(info))) > > > > + break; > > > > + > > > > + info.size = PAGE_SIZE; > > > > + info.max_index = dev->vq_num + 1; > > > > + > > > > + if (copy_to_user(argp, &info, sizeof(info))) > > > > + break; > > > > + ret = 0; > > > > + break; > > > > + } > > > > default: > > > > ret = -ENOIOCTLCMD; > > > > break; > > > > diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h > > > > index d585425803fd..ce55e34f63d7 100644 > > > > --- a/include/uapi/linux/vduse.h > > > > +++ b/include/uapi/linux/vduse.h > > > > @@ -356,4 +356,19 @@ struct vhost_reconnect_vring { > > > > _Bool avail_wrap_counter; > > > > }; > > > > > > > > +/** > > > > + * struct vduse_reconnect_mmap_info > > > > + * @size: mapping memory size, always page_size here > > > > + * @max_index: the number of pages allocated in kernel,just > > > > + * use for check > > > > + */ > > > > + > > > > +struct vduse_reconnect_mmap_info { > > > > + __u32 size; > > > > + __u32 max_index; > > > > +}; > > > > > > One thing I didn't understand is that, aren't the things we used to > > > store connection info belong to uAPI? If not, how can we make sure the > > > connections work across different vendors/implementations. If yes, > > > where? > > > > > > Thanks > > > > > The process for this reconnecttion is > > A.The first-time connection > > 1> The userland app checks if the device exists > > 2> use the ioctl to create the vduse device > > 3> Mapping the kernel page to userland and save the > > App-version/features/other information to this page > > 4> if the Userland app needs to exit, then the Userland app will only > > unmap the page and then exit > > > > B, the re-connection > > 1> the userland app finds the device is existing > > 2> Mapping the kernel page to userland > > 3> check if the information in shared memory is satisfied to > > reconnect,if ok then continue to reconnect > > 4> continue working > > > > For now these information are all from userland,So here the page will > > be maintained by the userland App > > in the previous code we only saved the api-version by uAPI . if we > > need to support reconnection maybe we need to add 2 new uAPI for this, > > one of the uAPI is to save the reconnect information and another is > > to get the information > > > > maybe something like > > > > struct vhost_reconnect_data { > > uint32_t version; > > uint64_t features; > > uint8_t status; > > struct virtio_net_config config; > > uint32_t nr_vrings; > > }; > > Probably, then we can make sure the re-connection works across > different vduse-daemon implementations. > > > > > #define VDUSE_GET_RECONNECT_INFO _IOR (VDUSE_BASE, 0x1c, struct > > vhost_reconnect_data) > > > > #define VDUSE_SET_RECONNECT_INFO _IOWR(VDUSE_BASE, 0x1d, struct > > vhost_reconnect_data) > > Not sure I get this, but the idea is to map those pages to user space, > any reason we need this uAPI? > > Thanks > Sorry, I didn't write it clearly, I mean if I we don't want to use the mmap to sync/check the vduse status, we need to add these 2 new uAPIs, these 2 methods are all ok for me. For the vq related information still need to use the mmap to sync Thanks cindy > > > > Thanks > > Cindy > > > > > > > > > > > > + > > > > +#define VDUSE_GET_RECONNECT_INFO \ > > > > + _IOWR(VDUSE_BASE, 0x1b, struct vduse_reconnect_mmap_info) > > > > + > > > > #endif /* _UAPI_VDUSE_H_ */ > > > > -- > > > > 2.34.3 > > > > > > > > > >
On 9/25/23 04:57, Jason Wang wrote: > On Thu, Sep 21, 2023 at 10:07 PM Cindy Lu <lulu@redhat.com> wrote: >> >> On Mon, Sep 18, 2023 at 4:49 PM Jason Wang <jasowang@redhat.com> wrote: >>> >>> On Tue, Sep 12, 2023 at 11:01 AM Cindy Lu <lulu@redhat.com> wrote: >>>> >>>> In VDUSE_GET_RECONNECT_INFO, the Userspace App can get the map size >>>> and The number of mapping memory pages from the kernel. The userspace >>>> App can use this information to map the pages. >>>> >>>> Signed-off-by: Cindy Lu <lulu@redhat.com> >>>> --- >>>> drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++++++ >>>> include/uapi/linux/vduse.h | 15 +++++++++++++++ >>>> 2 files changed, 30 insertions(+) >>>> >>>> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c >>>> index 680b23dbdde2..c99f99892b5c 100644 >>>> --- a/drivers/vdpa/vdpa_user/vduse_dev.c >>>> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c >>>> @@ -1368,6 +1368,21 @@ static long vduse_dev_ioctl(struct file *file, unsigned int cmd, >>>> ret = 0; >>>> break; >>>> } >>>> + case VDUSE_GET_RECONNECT_INFO: { >>>> + struct vduse_reconnect_mmap_info info; >>>> + >>>> + ret = -EFAULT; >>>> + if (copy_from_user(&info, argp, sizeof(info))) >>>> + break; >>>> + >>>> + info.size = PAGE_SIZE; >>>> + info.max_index = dev->vq_num + 1; >>>> + >>>> + if (copy_to_user(argp, &info, sizeof(info))) >>>> + break; >>>> + ret = 0; >>>> + break; >>>> + } >>>> default: >>>> ret = -ENOIOCTLCMD; >>>> break; >>>> diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h >>>> index d585425803fd..ce55e34f63d7 100644 >>>> --- a/include/uapi/linux/vduse.h >>>> +++ b/include/uapi/linux/vduse.h >>>> @@ -356,4 +356,19 @@ struct vhost_reconnect_vring { >>>> _Bool avail_wrap_counter; >>>> }; >>>> >>>> +/** >>>> + * struct vduse_reconnect_mmap_info >>>> + * @size: mapping memory size, always page_size here >>>> + * @max_index: the number of pages allocated in kernel,just >>>> + * use for check >>>> + */ >>>> + >>>> +struct vduse_reconnect_mmap_info { >>>> + __u32 size; >>>> + __u32 max_index; >>>> +}; >>> >>> One thing I didn't understand is that, aren't the things we used to >>> store connection info belong to uAPI? If not, how can we make sure the >>> connections work across different vendors/implementations. If yes, >>> where? >>> >>> Thanks >>> >> The process for this reconnecttion is >> A.The first-time connection >> 1> The userland app checks if the device exists >> 2> use the ioctl to create the vduse device >> 3> Mapping the kernel page to userland and save the >> App-version/features/other information to this page >> 4> if the Userland app needs to exit, then the Userland app will only >> unmap the page and then exit >> >> B, the re-connection >> 1> the userland app finds the device is existing >> 2> Mapping the kernel page to userland >> 3> check if the information in shared memory is satisfied to >> reconnect,if ok then continue to reconnect >> 4> continue working >> >> For now these information are all from userland,So here the page will >> be maintained by the userland App >> in the previous code we only saved the api-version by uAPI . if we >> need to support reconnection maybe we need to add 2 new uAPI for this, >> one of the uAPI is to save the reconnect information and another is >> to get the information >> >> maybe something like >> >> struct vhost_reconnect_data { >> uint32_t version; >> uint64_t features; >> uint8_t status; >> struct virtio_net_config config; >> uint32_t nr_vrings; >> }; > > Probably, then we can make sure the re-connection works across > different vduse-daemon implementations. +1, we need to have this defined in the uAPI to support interoperability across different VDUSE userspace implementations. > >> >> #define VDUSE_GET_RECONNECT_INFO _IOR (VDUSE_BASE, 0x1c, struct >> vhost_reconnect_data) >> >> #define VDUSE_SET_RECONNECT_INFO _IOWR(VDUSE_BASE, 0x1d, struct >> vhost_reconnect_data) > > Not sure I get this, but the idea is to map those pages to user space, > any reason we need this uAPI? It should not be necessary if the mmapped layout is properly defined. Thanks, Maxime > Thanks > >> >> Thanks >> Cindy >> >> >> >> >>>> + >>>> +#define VDUSE_GET_RECONNECT_INFO \ >>>> + _IOWR(VDUSE_BASE, 0x1b, struct vduse_reconnect_mmap_info) >>>> + >>>> #endif /* _UAPI_VDUSE_H_ */ >>>> -- >>>> 2.34.3 >>>> >>> >> >
On Fri, Sep 29, 2023 at 5:08 PM Maxime Coquelin <maxime.coquelin@redhat.com> wrote: > > > > On 9/25/23 04:57, Jason Wang wrote: > > On Thu, Sep 21, 2023 at 10:07 PM Cindy Lu <lulu@redhat.com> wrote: > >> > >> On Mon, Sep 18, 2023 at 4:49 PM Jason Wang <jasowang@redhat.com> wrote: > >>> > >>> On Tue, Sep 12, 2023 at 11:01 AM Cindy Lu <lulu@redhat.com> wrote: > >>>> > >>>> In VDUSE_GET_RECONNECT_INFO, the Userspace App can get the map size > >>>> and The number of mapping memory pages from the kernel. The userspace > >>>> App can use this information to map the pages. > >>>> > >>>> Signed-off-by: Cindy Lu <lulu@redhat.com> > >>>> --- > >>>> drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++++++ > >>>> include/uapi/linux/vduse.h | 15 +++++++++++++++ > >>>> 2 files changed, 30 insertions(+) > >>>> > >>>> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c > >>>> index 680b23dbdde2..c99f99892b5c 100644 > >>>> --- a/drivers/vdpa/vdpa_user/vduse_dev.c > >>>> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > >>>> @@ -1368,6 +1368,21 @@ static long vduse_dev_ioctl(struct file *file, unsigned int cmd, > >>>> ret = 0; > >>>> break; > >>>> } > >>>> + case VDUSE_GET_RECONNECT_INFO: { > >>>> + struct vduse_reconnect_mmap_info info; > >>>> + > >>>> + ret = -EFAULT; > >>>> + if (copy_from_user(&info, argp, sizeof(info))) > >>>> + break; > >>>> + > >>>> + info.size = PAGE_SIZE; > >>>> + info.max_index = dev->vq_num + 1; > >>>> + > >>>> + if (copy_to_user(argp, &info, sizeof(info))) > >>>> + break; > >>>> + ret = 0; > >>>> + break; > >>>> + } > >>>> default: > >>>> ret = -ENOIOCTLCMD; > >>>> break; > >>>> diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h > >>>> index d585425803fd..ce55e34f63d7 100644 > >>>> --- a/include/uapi/linux/vduse.h > >>>> +++ b/include/uapi/linux/vduse.h > >>>> @@ -356,4 +356,19 @@ struct vhost_reconnect_vring { > >>>> _Bool avail_wrap_counter; > >>>> }; > >>>> > >>>> +/** > >>>> + * struct vduse_reconnect_mmap_info > >>>> + * @size: mapping memory size, always page_size here > >>>> + * @max_index: the number of pages allocated in kernel,just > >>>> + * use for check > >>>> + */ > >>>> + > >>>> +struct vduse_reconnect_mmap_info { > >>>> + __u32 size; > >>>> + __u32 max_index; > >>>> +}; > >>> > >>> One thing I didn't understand is that, aren't the things we used to > >>> store connection info belong to uAPI? If not, how can we make sure the > >>> connections work across different vendors/implementations. If yes, > >>> where? > >>> > >>> Thanks > >>> > >> The process for this reconnecttion is > >> A.The first-time connection > >> 1> The userland app checks if the device exists > >> 2> use the ioctl to create the vduse device > >> 3> Mapping the kernel page to userland and save the > >> App-version/features/other information to this page > >> 4> if the Userland app needs to exit, then the Userland app will only > >> unmap the page and then exit > >> > >> B, the re-connection > >> 1> the userland app finds the device is existing > >> 2> Mapping the kernel page to userland > >> 3> check if the information in shared memory is satisfied to > >> reconnect,if ok then continue to reconnect > >> 4> continue working > >> > >> For now these information are all from userland,So here the page will > >> be maintained by the userland App > >> in the previous code we only saved the api-version by uAPI . if we > >> need to support reconnection maybe we need to add 2 new uAPI for this, > >> one of the uAPI is to save the reconnect information and another is > >> to get the information > >> > >> maybe something like > >> > >> struct vhost_reconnect_data { > >> uint32_t version; > >> uint64_t features; > >> uint8_t status; > >> struct virtio_net_config config; > >> uint32_t nr_vrings; > >> }; > > > > Probably, then we can make sure the re-connection works across > > different vduse-daemon implementations. > > +1, we need to have this defined in the uAPI to support interoperability > across different VDUSE userspace implementations. > > > > >> > >> #define VDUSE_GET_RECONNECT_INFO _IOR (VDUSE_BASE, 0x1c, struct > >> vhost_reconnect_data) > >> > >> #define VDUSE_SET_RECONNECT_INFO _IOWR(VDUSE_BASE, 0x1d, struct > >> vhost_reconnect_data) > > > > Not sure I get this, but the idea is to map those pages to user space, > > any reason we need this uAPI? > > It should not be necessary if the mmapped layout is properly defined. > > Thanks, > Maxime > Sure , I will use mmap to sync the reconnect status Thanks cindy > > Thanks > > > >> > >> Thanks > >> Cindy > >> > >> > >> > >> > >>>> + > >>>> +#define VDUSE_GET_RECONNECT_INFO \ > >>>> + _IOWR(VDUSE_BASE, 0x1b, struct vduse_reconnect_mmap_info) > >>>> + > >>>> #endif /* _UAPI_VDUSE_H_ */ > >>>> -- > >>>> 2.34.3 > >>>> > >>> > >> > > >
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c index 680b23dbdde2..c99f99892b5c 100644 --- a/drivers/vdpa/vdpa_user/vduse_dev.c +++ b/drivers/vdpa/vdpa_user/vduse_dev.c @@ -1368,6 +1368,21 @@ static long vduse_dev_ioctl(struct file *file, unsigned int cmd, ret = 0; break; } + case VDUSE_GET_RECONNECT_INFO: { + struct vduse_reconnect_mmap_info info; + + ret = -EFAULT; + if (copy_from_user(&info, argp, sizeof(info))) + break; + + info.size = PAGE_SIZE; + info.max_index = dev->vq_num + 1; + + if (copy_to_user(argp, &info, sizeof(info))) + break; + ret = 0; + break; + } default: ret = -ENOIOCTLCMD; break; diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h index d585425803fd..ce55e34f63d7 100644 --- a/include/uapi/linux/vduse.h +++ b/include/uapi/linux/vduse.h @@ -356,4 +356,19 @@ struct vhost_reconnect_vring { _Bool avail_wrap_counter; }; +/** + * struct vduse_reconnect_mmap_info + * @size: mapping memory size, always page_size here + * @max_index: the number of pages allocated in kernel,just + * use for check + */ + +struct vduse_reconnect_mmap_info { + __u32 size; + __u32 max_index; +}; + +#define VDUSE_GET_RECONNECT_INFO \ + _IOWR(VDUSE_BASE, 0x1b, struct vduse_reconnect_mmap_info) + #endif /* _UAPI_VDUSE_H_ */