Received: by 2002:a05:7412:da14:b0:e2:908c:2ebd with SMTP id fe20csp1659201rdb; Sun, 8 Oct 2023 20:02:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFbmTTJFapWsr1571Amth0kY0SvjAl8O5+hcv5rOzlHcQWnd9wf1zwE7Ers2xXpE584l92p X-Received: by 2002:a05:6870:4707:b0:1b7:4655:2ac9 with SMTP id b7-20020a056870470700b001b746552ac9mr18048794oaq.6.1696820564236; Sun, 08 Oct 2023 20:02:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696820564; cv=none; d=google.com; s=arc-20160816; b=eDCK2CSi1Z8P0DDLXIRk4RyuGau16oPk5dki89Dz4Gq/qvmk5KXpFdXa7p8YKarSk9 /WvfLTK/6XowLlns3dcSNNj/lh3jPap2Tdu9QYyvNriTxfoVbktSAuzsFI0a72nygZp3 oZ+cxb6t3pg4drpOM2cF9DAT3KKQgS3k+/1yzFATm++SwUtdPoJjA1YakS+sphgMvlj3 ByGNSxlT7Gxzpts3hQ4vpWu9u949kkExqhLehb5n/QL6cZTJuvmeyQhEA6RxdcmQI1d1 ppkCCtrDm0eeOvRe+FBMT71QaZ7DONJYJXhXwMol/uROQdAhquhLLtVBV5q1460SXQYd JKKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=HfPpj/NYnLhR9rt7gcQcCsZvzAr7nC8MCFto+fdVExs=; fh=FVRr0P/YgmQ+KoQfTf0CL3UeCwbW5Nhb5dzcpZ3/fVg=; b=YGm1qdF+RS4Zufwk85u7yf9d5cjJ4QvdFXpfnj9fU9TI4LYXhxfrNhLWSUXRT3HJlJ UMIGIl67m76wODbeHkJxzLWHOga8Y/l6n+BKYjaM0D9Pc9YckQvMbcSWe3M7b1bTwjuf hs5MOMMc3r2KxbEUyYkhoNjpNIFeH7u8dMRUFe/ATeLqFJsNP/8dhoN/cFJ1IOsc6ENe oHMwEmy2yOshDzPg1Iq+Ppaqv6vFY+FV4ZlEZTQrTxo5jJfxzCi/VLJ3lhE3/33RJG5V LKh0F6PMOiVRcQ3MxAtwgHei5tPX9E1MiPkgrKqREpPkIBkr3NvhAGgPp94m5vK9+gbb h/IA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Z3r0heBO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 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 pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id cq26-20020a056a00331a00b0068fb1a85ec8si6407602pfb.370.2023.10.08.20.02.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Oct 2023 20:02:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Z3r0heBO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 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 pete.vger.email (Postfix) with ESMTP id B954F804C525; Sun, 8 Oct 2023 20:02:40 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344903AbjJIDCb (ORCPT + 99 others); Sun, 8 Oct 2023 23:02:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232267AbjJIDCa (ORCPT ); Sun, 8 Oct 2023 23:02:30 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 896C5A6 for ; Sun, 8 Oct 2023 20:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696820502; 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=HfPpj/NYnLhR9rt7gcQcCsZvzAr7nC8MCFto+fdVExs=; b=Z3r0heBOdXA3pQnaCoz5MVQJWiEMmWXcuvRtcRDh2AtB1UnIMYnfU8WmHI6nqMuG+/B1QV B0clrZhBdI439sPpVKE2aFSxefU8LehhgU14pDspNhTF01ODosHUxEi1Ay2qnUaucyZZl6 BgbxWCf/5v22JM0s5J8f/BYVttADTLk= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-E42dOnmwOPSwVlMOGGQ3Uw-1; Sun, 08 Oct 2023 23:01:41 -0400 X-MC-Unique: E42dOnmwOPSwVlMOGGQ3Uw-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-9b97f1b493dso326999566b.3 for ; Sun, 08 Oct 2023 20:01:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696820499; x=1697425299; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HfPpj/NYnLhR9rt7gcQcCsZvzAr7nC8MCFto+fdVExs=; b=uWsnwYRCJECzUbTIVZeuXdchMpeS93zOj1qquWfaqYxxJQNg8iSi0illuHjbktaODr zLR69KYb5Xrriq7OM5kvrQRb9WdoOzaVLObtx31auJ5EZyNmmBmwcH1DfoNz/V3jpBcP EAysU/6riuQAZGR3WqT4PCDx1JqVAnwiOE/Jm/dAmDeGldK+PrAsYF/xIRCu50vN43OM lh6qMTLkZ6FjC0R6CeJNOHpQvrn65ycxU+TfTqvZWJfzi4L+pyGoqdMBkAhj+43upjLz CLIRHgtDMzUNUQhfWHQGv0XhKn6I8MnMxILcNjjew79ySFxyIxgyEjSmZyBVXrvmwSP6 E6Ug== X-Gm-Message-State: AOJu0YzQ0fWI0Omf2neqhqMwL3KjhNJ79/oYeF4PLhcfWscElfylxLqi rdHt2yD1lUP2BM2idumS7tvXmAYAkCdi6fbIb+E6LetuF2Qc6lr01OD7Lfc/2WvBv+iVswwogyf SSzqOOuQYZZbtpRyjLTM5Q7aDkJbYJOI1O1/oYTWkKvrBdnNl X-Received: by 2002:aa7:da83:0:b0:533:d81b:36d5 with SMTP id q3-20020aa7da83000000b00533d81b36d5mr11984919eds.15.1696820498955; Sun, 08 Oct 2023 20:01:38 -0700 (PDT) X-Received: by 2002:aa7:da83:0:b0:533:d81b:36d5 with SMTP id q3-20020aa7da83000000b00533d81b36d5mr11984907eds.15.1696820498625; Sun, 08 Oct 2023 20:01:38 -0700 (PDT) MIME-Version: 1.0 References: <20230912030008.3599514-1-lulu@redhat.com> <20230912030008.3599514-5-lulu@redhat.com> <6c4cd924-0d44-582e-13a4-791f38d10fe8@redhat.com> In-Reply-To: <6c4cd924-0d44-582e-13a4-791f38d10fe8@redhat.com> From: Cindy Lu Date: Mon, 9 Oct 2023 11:00:30 +0800 Message-ID: Subject: Re: [RFC v2 4/4] vduse: Add new ioctl VDUSE_GET_RECONNECT_INFO To: Maxime Coquelin Cc: Jason Wang , mst@redhat.com, xieyongji@bytedance.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=2.7 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Sun, 08 Oct 2023 20:02:41 -0700 (PDT) X-Spam-Level: ** On Fri, Sep 29, 2023 at 5:08=E2=80=AFPM Maxime Coquelin wrote: > > > > On 9/25/23 04:57, Jason Wang wrote: > > On Thu, Sep 21, 2023 at 10:07=E2=80=AFPM Cindy Lu wro= te: > >> > >> On Mon, Sep 18, 2023 at 4:49=E2=80=AFPM Jason Wang wrote: > >>> > >>> On Tue, Sep 12, 2023 at 11:01=E2=80=AFAM Cindy Lu w= rote: > >>>> > >>>> In VDUSE_GET_RECONNECT_INFO, the Userspace App can get the map size > >>>> and The number of mapping memory pages from the kernel. The userspac= e > >>>> App can use this information to map the pages. > >>>> > >>>> Signed-off-by: Cindy Lu > >>>> --- > >>>> 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 =3D 0; > >>>> break; > >>>> } > >>>> + case VDUSE_GET_RECONNECT_INFO: { > >>>> + struct vduse_reconnect_mmap_info info; > >>>> + > >>>> + ret =3D -EFAULT; > >>>> + if (copy_from_user(&info, argp, sizeof(info))) > >>>> + break; > >>>> + > >>>> + info.size =3D PAGE_SIZE; > >>>> + info.max_index =3D dev->vq_num + 1; > >>>> + > >>>> + if (copy_to_user(argp, &info, sizeof(info))) > >>>> + break; > >>>> + ret =3D 0; > >>>> + break; > >>>> + } > >>>> default: > >>>> ret =3D -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 th= e > >>> 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 wil= l > >> 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 > >>>> > >>> > >> > > >