From: Yongji Xie <xieyongji@bytedance.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Parav Pandit" <parav@nvidia.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Christian Brauner" <christian.brauner@canonical.com>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Matthew Wilcox" <willy@infradead.org>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Jens Axboe" <axboe@kernel.dk>,
bcrl@kvack.org, "Jonathan Corbet" <corbet@lwn.net>,
"Mika Penttilä" <mika.penttila@nextfour.com>,
"Dan Carpenter" <dan.carpenter@oracle.com>,
joro@8bytes.org,
virtualization <virtualization@lists.linux-foundation.org>,
netdev@vger.kernel.org, kvm <kvm@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
Date: Mon, 31 May 2021 14:19:37 +0800 [thread overview]
Message-ID: <CACycT3vRHPfOGxmy1Uv=8_dqqq8iG4YTZHUizo+y8EYKGS5g8g@mail.gmail.com> (raw)
In-Reply-To: <YLRsehBRAiCJEDl0@kroah.com>
Hi Greg,
Thanks a lot for the review!
On Mon, May 31, 2021 at 12:56 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, May 17, 2021 at 05:55:12PM +0800, Xie Yongji wrote:
> > +struct vduse_dev {
> > + struct vduse_vdpa *vdev;
> > + struct device dev;
> > + struct cdev cdev;
>
> You now have 2 reference counted devices controling the lifespace of a
> single structure. A mess that is guaranteed to go wrong. Please never
> do this.
>
These two are both used by cdev_device_add(). Looks like I didn't find
any problem. Any suggestions?
> > + struct vduse_virtqueue *vqs;
> > + struct vduse_iova_domain *domain;
> > + char *name;
> > + struct mutex lock;
> > + spinlock_t msg_lock;
> > + atomic64_t msg_unique;
>
> Why do you need an atomic and a lock?
>
You are right. We don't need an atomic here.
> > + wait_queue_head_t waitq;
> > + struct list_head send_list;
> > + struct list_head recv_list;
> > + struct list_head list;
> > + struct vdpa_callback config_cb;
> > + struct work_struct inject;
> > + spinlock_t irq_lock;
> > + unsigned long api_version;
> > + bool connected;
> > + int minor;
> > + u16 vq_size_max;
> > + u32 vq_num;
> > + u32 vq_align;
> > + u32 config_size;
> > + u32 device_id;
> > + u32 vendor_id;
> > +};
> > +
> > +struct vduse_dev_msg {
> > + struct vduse_dev_request req;
> > + struct vduse_dev_response resp;
> > + struct list_head list;
> > + wait_queue_head_t waitq;
> > + bool completed;
> > +};
> > +
> > +struct vduse_control {
> > + unsigned long api_version;
>
> u64?
>
OK.
> > +};
> > +
> > +static unsigned long max_bounce_size = (64 * 1024 * 1024);
> > +module_param(max_bounce_size, ulong, 0444);
> > +MODULE_PARM_DESC(max_bounce_size, "Maximum bounce buffer size. (default: 64M)");
> > +
> > +static unsigned long max_iova_size = (128 * 1024 * 1024);
> > +module_param(max_iova_size, ulong, 0444);
> > +MODULE_PARM_DESC(max_iova_size, "Maximum iova space size (default: 128M)");
> > +
> > +static bool allow_unsafe_device_emulation;
> > +module_param(allow_unsafe_device_emulation, bool, 0444);
> > +MODULE_PARM_DESC(allow_unsafe_device_emulation, "Allow emulating unsafe device."
> > + " We must make sure the userspace device emulation process is trusted."
> > + " Otherwise, don't enable this option. (default: false)");
> > +
>
> This is not the 1990's anymore, please never use module parameters, make
> these per-device attributes if you really need them.
>
These parameters will be used before the device is created. Or do you
mean add some attributes to the control device?
> > +static int vduse_init(void)
> > +{
> > + int ret;
> > +
> > + if (max_bounce_size >= max_iova_size)
> > + return -EINVAL;
> > +
> > + ret = misc_register(&vduse_misc);
> > + if (ret)
> > + return ret;
> > +
> > + vduse_class = class_create(THIS_MODULE, "vduse");
>
> If you have a misc device, you do not need to create a class at the same
> time. Why are you doing both here? Just stick with the misc device, no
> need for anything else.
>
The misc device is the control device represented by
/dev/vduse/control. Then a VDUSE device represented by
/dev/vduse/$NAME can be created by the ioctl(VDUSE_CREATE_DEV) on this
control device.
> > + if (IS_ERR(vduse_class)) {
> > + ret = PTR_ERR(vduse_class);
> > + goto err_class;
> > + }
> > + vduse_class->devnode = vduse_devnode;
> > +
> > + ret = alloc_chrdev_region(&vduse_major, 0, VDUSE_DEV_MAX, "vduse");
>
> Wait, you want a whole major? What is the misc device for?
>
The misc device is used for controlling. And VDUSE devices are
allocated in a dynamic chardev range. Or do I need to reserve the
first minor for the control device instead?
> > +MODULE_VERSION(DRV_VERSION);
>
> MODULE_VERSION() makes no sense when the code is merged into the kernel
> tree, so you can just drop that.
>
Will do it.
Thanks,
Yongji
next prev parent reply other threads:[~2021-05-31 6:20 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-05-17 9:55 ` [PATCH v7 01/12] iova: Export alloc_iova_fast() Xie Yongji
2021-05-26 2:36 ` Jason Wang
2021-05-26 2:43 ` Yongji Xie
2021-05-17 9:55 ` [PATCH v7 02/12] file: Export receive_fd() to modules Xie Yongji
2021-05-20 6:18 ` Al Viro
2021-05-20 6:32 ` Yongji Xie
2021-05-17 9:55 ` [PATCH v7 03/12] eventfd: Increase the recursion depth of eventfd_signal() Xie Yongji
2021-05-17 9:55 ` [PATCH v7 04/12] virtio-blk: Add validation for block size in config space Xie Yongji
2021-05-19 13:39 ` Yongji Xie
2021-05-19 14:42 ` Dan Carpenter
2021-05-20 5:25 ` Yongji Xie
2021-05-20 5:43 ` Michael S. Tsirkin
2021-05-20 7:08 ` Yongji Xie
2021-05-17 9:55 ` [PATCH v7 05/12] virtio_scsi: Add validation for residual bytes from response Xie Yongji
2021-05-26 2:41 ` Jason Wang
2021-05-17 9:55 ` [PATCH v7 06/12] vhost-iotlb: Add an opaque pointer for vhost IOTLB Xie Yongji
2021-05-17 9:55 ` [PATCH v7 07/12] vdpa: Add an opaque pointer for vdpa_config_ops.dma_map() Xie Yongji
2021-05-17 9:55 ` [PATCH v7 08/12] vdpa: factor out vhost_vdpa_pa_map() and vhost_vdpa_pa_unmap() Xie Yongji
2021-05-17 9:55 ` [PATCH v7 09/12] vdpa: Support transferring virtual addressing during DMA mapping Xie Yongji
2021-05-17 9:55 ` [PATCH v7 10/12] vduse: Implement an MMU-based IOMMU driver Xie Yongji
2021-05-17 9:55 ` [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-05-20 6:28 ` Al Viro
2021-05-20 7:03 ` Yongji Xie
2021-05-27 4:12 ` Jason Wang
2021-05-27 4:57 ` Yongji Xie
2021-05-27 5:00 ` Jason Wang
2021-05-27 5:08 ` Yongji Xie
2021-05-27 5:40 ` Jason Wang
2021-05-27 7:34 ` Yongji Xie
2021-05-27 8:41 ` Jason Wang
2021-05-27 8:43 ` Jason Wang
2021-05-27 10:14 ` Yongji Xie
2021-05-28 1:33 ` Jason Wang
2021-05-28 3:54 ` Yongji Xie
2021-05-28 6:38 ` Jason Wang
2021-05-27 13:17 ` Yongji Xie
2021-05-28 2:31 ` Jason Wang
2021-05-31 4:27 ` Yongji Xie
2021-05-31 4:38 ` Jason Wang
2021-05-31 6:24 ` Yongji Xie
2021-05-31 4:56 ` Greg KH
2021-05-31 6:19 ` Yongji Xie [this message]
2021-05-31 6:32 ` Greg KH
2021-05-31 7:13 ` Yongji Xie
2021-05-17 9:55 ` [PATCH v7 12/12] Documentation: Add documentation for VDUSE Xie Yongji
2021-05-20 6:06 ` [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Michael S. Tsirkin
2021-05-20 9:06 ` Yongji Xie
2021-05-25 6:40 ` Jason Wang
2021-05-25 6:48 ` Michael S. Tsirkin
2021-05-25 7:11 ` Jason Wang
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='CACycT3vRHPfOGxmy1Uv=8_dqqq8iG4YTZHUizo+y8EYKGS5g8g@mail.gmail.com' \
--to=xieyongji@bytedance.com \
--cc=axboe@kernel.dk \
--cc=bcrl@kvack.org \
--cc=christian.brauner@canonical.com \
--cc=corbet@lwn.net \
--cc=dan.carpenter@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jasowang@redhat.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.penttila@nextfour.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=parav@nvidia.com \
--cc=rdunlap@infradead.org \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=virtualization@lists.linux-foundation.org \
--cc=willy@infradead.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 NNTP newsgroup(s).