From: Jason Wang <jasowang@redhat.com>
To: Cindy Lu <lulu@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v5 3/5] vduse: Add function to get/free the pages for reconnection
Date: Wed, 24 Apr 2024 11:51:39 +0800 [thread overview]
Message-ID: <CACGkMEsfCa=awV6WebT_jm1ng4uY4afj4KLML4bHdi5=iakZYg@mail.gmail.com> (raw)
In-Reply-To: <CACLfguXzMEjXrC9dnO=q7cvoVAusQT930Wh8w4cHon_KTLpOtA@mail.gmail.com>
On Wed, Apr 24, 2024 at 11:15 AM Cindy Lu <lulu@redhat.com> wrote:
>
> On Wed, Apr 24, 2024 at 8:44 AM Jason Wang <jasowang@redhat.com> wrote:
> >
> > On Tue, Apr 23, 2024 at 4:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Tue, Apr 23, 2024 at 11:09:59AM +0800, Jason Wang wrote:
> > > > On Tue, Apr 23, 2024 at 4:05 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > >
> > > > > On Thu, Apr 18, 2024 at 08:57:51AM +0800, Jason Wang wrote:
> > > > > > On Wed, Apr 17, 2024 at 5:29 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > >
> > > > > > > On Fri, Apr 12, 2024 at 09:28:23PM +0800, Cindy Lu wrote:
> > > > > > > > Add the function vduse_alloc_reconnnect_info_mem
> > > > > > > > and vduse_alloc_reconnnect_info_mem
> > > > > > > > These functions allow vduse to allocate and free memory for reconnection
> > > > > > > > information. The amount of memory allocated is vq_num pages.
> > > > > > > > Each VQS will map its own page where the reconnection information will be saved
> > > > > > > >
> > > > > > > > Signed-off-by: Cindy Lu <lulu@redhat.com>
> > > > > > > > ---
> > > > > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 40 ++++++++++++++++++++++++++++++
> > > > > > > > 1 file changed, 40 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > > index ef3c9681941e..2da659d5f4a8 100644
> > > > > > > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > > @@ -65,6 +65,7 @@ struct vduse_virtqueue {
> > > > > > > > int irq_effective_cpu;
> > > > > > > > struct cpumask irq_affinity;
> > > > > > > > struct kobject kobj;
> > > > > > > > + unsigned long vdpa_reconnect_vaddr;
> > > > > > > > };
> > > > > > > >
> > > > > > > > struct vduse_dev;
> > > > > > > > @@ -1105,6 +1106,38 @@ static void vduse_vq_update_effective_cpu(struct vduse_virtqueue *vq)
> > > > > > > >
> > > > > > > > vq->irq_effective_cpu = curr_cpu;
> > > > > > > > }
> > > > > > > > +static int vduse_alloc_reconnnect_info_mem(struct vduse_dev *dev)
> > > > > > > > +{
> > > > > > > > + unsigned long vaddr = 0;
> > > > > > > > + struct vduse_virtqueue *vq;
> > > > > > > > +
> > > > > > > > + for (int i = 0; i < dev->vq_num; i++) {
> > > > > > > > + /*page 0~ vq_num save the reconnect info for vq*/
> > > > > > > > + vq = dev->vqs[i];
> > > > > > > > + vaddr = get_zeroed_page(GFP_KERNEL);
> > > > > > >
> > > > > > >
> > > > > > > I don't get why you insist on stealing kernel memory for something
> > > > > > > that is just used by userspace to store data for its own use.
> > > > > > > Userspace does not lack ways to persist data, for example,
> > > > > > > create a regular file anywhere in the filesystem.
> > > > > >
> > > > > > Good point. So the motivation here is to:
> > > > > >
> > > > > > 1) be self contained, no dependency for high speed persist data
> > > > > > storage like tmpfs
> > > > >
> > > > > No idea what this means.
> > > >
> > > > I mean a regular file may slow down the datapath performance, so
> > > > usually the application will try to use tmpfs and other which is a
> > > > dependency for implementing the reconnection.
> > >
> > > Are we worried about systems without tmpfs now?
> >
> > Yes.
> >
> > >
> > >
> > > > >
> > > > > > 2) standardize the format in uAPI which allows reconnection from
> > > > > > arbitrary userspace, unfortunately, such effort was removed in new
> > > > > > versions
> > > > >
> > > > > And I don't see why that has to live in the kernel tree either.
> > > >
> > > > I can't find a better place, any idea?
> > > >
> > > > Thanks
> > >
> > >
> > > Well anywhere on github really. with libvhost-user maybe?
> > > It's harmless enough in Documentation
> > > if you like but ties you to the kernel release cycle in a way that
> > > is completely unnecessary.
> >
> > Ok.
> >
> > Thanks
> >
> Sure, got it. Do we need to withdraw all the series? maybe we can keep
> the patch for support ioctl to get status and configure?
We can leave the mmap part for future, the rest is still useful unless
I miss anything.
Thanks
>
> thanks
> cindy
>
> > >
> > > > >
> > > > > > If the above doesn't make sense, we don't need to offer those pages by VDUSE.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > + if (vaddr == 0)
> > > > > > > > + return -ENOMEM;
> > > > > > > > +
> > > > > > > > + vq->vdpa_reconnect_vaddr = vaddr;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + return 0;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +static int vduse_free_reconnnect_info_mem(struct vduse_dev *dev)
> > > > > > > > +{
> > > > > > > > + struct vduse_virtqueue *vq;
> > > > > > > > +
> > > > > > > > + for (int i = 0; i < dev->vq_num; i++) {
> > > > > > > > + vq = dev->vqs[i];
> > > > > > > > +
> > > > > > > > + if (vq->vdpa_reconnect_vaddr)
> > > > > > > > + free_page(vq->vdpa_reconnect_vaddr);
> > > > > > > > + vq->vdpa_reconnect_vaddr = 0;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + return 0;
> > > > > > > > +}
> > > > > > > >
> > > > > > > > static long vduse_dev_ioctl(struct file *file, unsigned int cmd,
> > > > > > > > unsigned long arg)
> > > > > > > > @@ -1672,6 +1705,8 @@ static int vduse_destroy_dev(char *name)
> > > > > > > > mutex_unlock(&dev->lock);
> > > > > > > > return -EBUSY;
> > > > > > > > }
> > > > > > > > + vduse_free_reconnnect_info_mem(dev);
> > > > > > > > +
> > > > > > > > dev->connected = true;
> > > > > > > > mutex_unlock(&dev->lock);
> > > > > > > >
> > > > > > > > @@ -1855,12 +1890,17 @@ static int vduse_create_dev(struct vduse_dev_config *config,
> > > > > > > > ret = vduse_dev_init_vqs(dev, config->vq_align, config->vq_num);
> > > > > > > > if (ret)
> > > > > > > > goto err_vqs;
> > > > > > > > + ret = vduse_alloc_reconnnect_info_mem(dev);
> > > > > > > > + if (ret < 0)
> > > > > > > > + goto err_mem;
> > > > > > > >
> > > > > > > > __module_get(THIS_MODULE);
> > > > > > > >
> > > > > > > > return 0;
> > > > > > > > err_vqs:
> > > > > > > > device_destroy(&vduse_class, MKDEV(MAJOR(vduse_major), dev->minor));
> > > > > > > > +err_mem:
> > > > > > > > + vduse_free_reconnnect_info_mem(dev);
> > > > > > > > err_dev:
> > > > > > > > idr_remove(&vduse_idr, dev->minor);
> > > > > > > > err_idr:
> > > > > > > > --
> > > > > > > > 2.43.0
> > > > > > >
> > > > >
> > >
> >
>
next prev parent reply other threads:[~2024-04-24 3:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 13:28 [PATCH v5 0/5] vduse: Add support for reconnection Cindy Lu
2024-04-12 13:28 ` [PATCH v5 1/5] vduse: Add new ioctl VDUSE_DEV_GET_CONFIG Cindy Lu
2024-04-12 13:28 ` [PATCH v5 2/5] vduse: Add new ioctl VDUSE_DEV_GET_STATUS Cindy Lu
2024-04-12 13:28 ` [PATCH v5 3/5] vduse: Add function to get/free the pages for reconnection Cindy Lu
2024-04-17 9:29 ` Michael S. Tsirkin
2024-04-18 0:57 ` Jason Wang
2024-04-22 20:05 ` Michael S. Tsirkin
2024-04-23 3:09 ` Jason Wang
2024-04-23 8:42 ` Michael S. Tsirkin
2024-04-24 0:44 ` Jason Wang
2024-04-24 3:14 ` Cindy Lu
2024-04-24 3:51 ` Jason Wang [this message]
2024-04-24 9:51 ` Michael S. Tsirkin
2024-04-25 1:35 ` Jason Wang
2024-04-25 10:26 ` Michael S. Tsirkin
2024-04-12 13:28 ` [PATCH v5 4/5] vduse: Add file operation for mmap Cindy Lu
2024-04-12 13:28 ` [PATCH v5 5/5] Documentation: Add reconnect process for VDUSE Cindy Lu
2024-04-16 3:46 ` Jason Wang
2024-04-17 8:46 ` Cindy Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACGkMEsfCa=awV6WebT_jm1ng4uY4afj4KLML4bHdi5=iakZYg@mail.gmail.com' \
--to=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=mst@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).