Re: [RFC v2 06/13] vduse: Introduce VDUSE - vDPA Device in Userspace
On 12/22/20 10:52 PM, Xie Yongji wrote: > This VDUSE driver enables implementing vDPA devices in userspace. > Both control path and data path of vDPA devices will be able to > be handled in userspace. > > In the control path, the VDUSE driver will make use of message > mechnism to forward the config operation from vdpa bus driver > to userspace. Userspace can use read()/write() to receive/reply > those control messages. > > In the data path, the VDUSE driver implements a MMU-based on-chip > IOMMU driver which supports mapping the kernel dma buffer to a > userspace iova region dynamically. Userspace can access those > iova region via mmap(). Besides, the eventfd mechanism is used to > trigger interrupt callbacks and receive virtqueue kicks in userspace > > Now we only support virtio-vdpa bus driver with this patch applied. > > Signed-off-by: Xie Yongji > --- > Documentation/driver-api/vduse.rst | 74 ++ > Documentation/userspace-api/ioctl/ioctl-number.rst |1 + > drivers/vdpa/Kconfig |8 + > drivers/vdpa/Makefile |1 + > drivers/vdpa/vdpa_user/Makefile|5 + > drivers/vdpa/vdpa_user/eventfd.c | 221 > drivers/vdpa/vdpa_user/eventfd.h | 48 + > drivers/vdpa/vdpa_user/iova_domain.c | 442 > drivers/vdpa/vdpa_user/iova_domain.h | 93 ++ > drivers/vdpa/vdpa_user/vduse.h | 59 ++ > drivers/vdpa/vdpa_user/vduse_dev.c | 1121 > > include/uapi/linux/vdpa.h |1 + > include/uapi/linux/vduse.h | 99 ++ > 13 files changed, 2173 insertions(+) > create mode 100644 Documentation/driver-api/vduse.rst > create mode 100644 drivers/vdpa/vdpa_user/Makefile > create mode 100644 drivers/vdpa/vdpa_user/eventfd.c > create mode 100644 drivers/vdpa/vdpa_user/eventfd.h > create mode 100644 drivers/vdpa/vdpa_user/iova_domain.c > create mode 100644 drivers/vdpa/vdpa_user/iova_domain.h > create mode 100644 drivers/vdpa/vdpa_user/vduse.h > create mode 100644 drivers/vdpa/vdpa_user/vduse_dev.c > create mode 100644 include/uapi/linux/vduse.h > > diff --git a/Documentation/driver-api/vduse.rst > b/Documentation/driver-api/vduse.rst > new file mode 100644 > index ..da9b3040f20a > --- /dev/null > +++ b/Documentation/driver-api/vduse.rst > @@ -0,0 +1,74 @@ > +== > +VDUSE - "vDPA Device in Userspace" > +== > + > +vDPA (virtio data path acceleration) device is a device that uses a > +datapath which complies with the virtio specifications with vendor > +specific control path. vDPA devices can be both physically located on > +the hardware or emulated by software. VDUSE is a framework that makes it > +possible to implement software-emulated vDPA devices in userspace. > + Could you explain a bit more why need a VDUSE framework? Software emulated vDPA devices is more likely used by debugging only when don't have real hardware. Do you think do the emulation in kernel space is not enough? Thanks, Bob > +How VDUSE works > + > +Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on > +the VDUSE character device (/dev/vduse). Then a file descriptor pointing > +to the new resources will be returned, which can be used to implement the > +userspace vDPA device's control path and data path. > + > +To implement control path, the read/write operations to the file descriptor > +will be used to receive/reply the control messages from/to VDUSE driver. > +Those control messages are based on the vdpa_config_ops which defines a > +unified interface to control different types of vDPA device. > + ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 00/12] block/bio, fs: convert put_page() to put_user_page*()
On 7/24/19 12:25 PM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Hi,
>
> This is mostly Jerome's work, converting the block/bio and related areas
> to call put_user_page*() instead of put_page(). Because I've changed
> Jerome's patches, in some cases significantly, I'd like to get his
> feedback before we actually leave him listed as the author (he might
> want to disown some or all of these).
>
Could you add some background to the commit log for people don't have the
context..
Why this converting? What's the main differences?
Regards, -Bob
> I added a new patch, in order to make this work with Christoph Hellwig's
> recent overhaul to bio_release_pages(): "block: bio_release_pages: use
> flags arg instead of bool".
>
> I've started the series with a patch that I've posted in another
> series ("mm/gup: add make_dirty arg to put_user_pages_dirty_lock()"[1]),
> because I'm not sure which of these will go in first, and this allows each
> to stand alone.
>
> Testing: not much beyond build and boot testing has been done yet. And
> I'm not set up to even exercise all of it (especially the IB parts) at
> run time.
>
> Anyway, changes here are:
>
> * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter.
> Then, use the new iov_iter_get_pages_use_gup() to retrieve it when
> it is time to release the pages. That allows choosing between put_page()
> and put_user_page*().
>
> * Pass in one more piece of information to bio_release_pages: a "from_gup"
> parameter. Similar use as above.
>
> * Change the block layer, and several file systems, to use
> put_user_page*().
>
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_r_20190724012606.25844-2D2-2Djhubbard-40nvidia.com=DwIDaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=1ktT0U2YS_I8Zz2o-MS1YcCAzWZ6hFGtyTgvVMGM7gI=FpFhv2rjbKCAYGmO6Hy8WJAottr1Qz_mDKDLObQ40FU=q-_mX3daEr22WbdZMElc_ZbD8L9oGLD7U0xLeyJ661Y=
>
> And please note the correction email that I posted as a follow-up,
> if you're looking closely at that patch. :) The fixed version is
> included here.
>
> John Hubbard (3):
> mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
> block: bio_release_pages: use flags arg instead of bool
> fs/ceph: fix a build warning: returning a value from void function
>
> Jérôme Glisse (9):
> iov_iter: add helper to test if an iter would use GUP v2
> block: bio_release_pages: convert put_page() to put_user_page*()
> block_dev: convert put_page() to put_user_page*()
> fs/nfs: convert put_page() to put_user_page*()
> vhost-scsi: convert put_page() to put_user_page*()
> fs/cifs: convert put_page() to put_user_page*()
> fs/fuse: convert put_page() to put_user_page*()
> fs/ceph: convert put_page() to put_user_page*()
> 9p/net: convert put_page() to put_user_page*()
>
> block/bio.c| 81 ---
> drivers/infiniband/core/umem.c | 5 +-
> drivers/infiniband/hw/hfi1/user_pages.c| 5 +-
> drivers/infiniband/hw/qib/qib_user_pages.c | 5 +-
> drivers/infiniband/hw/usnic/usnic_uiom.c | 5 +-
> drivers/infiniband/sw/siw/siw_mem.c| 8 +-
> drivers/vhost/scsi.c | 13 ++-
> fs/block_dev.c | 22 +++-
> fs/ceph/debugfs.c | 2 +-
> fs/ceph/file.c | 62 ---
> fs/cifs/cifsglob.h | 3 +
> fs/cifs/file.c | 22 +++-
> fs/cifs/misc.c | 19 +++-
> fs/direct-io.c | 2 +-
> fs/fuse/dev.c | 22 +++-
> fs/fuse/file.c | 53 +++---
> fs/nfs/direct.c| 10 +-
> include/linux/bio.h| 22 +++-
> include/linux/mm.h | 5 +-
> include/linux/uio.h| 11 ++
> mm/gup.c | 115 +
> net/9p/trans_common.c | 14 ++-
> net/9p/trans_common.h | 3 +-
> net/9p/trans_virtio.c | 18 +++-
> 24 files changed, 357 insertions(+), 170 deletions(-)
>
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drivers: virtio_blk: notify blk-core when hw-queue number changes
On 06/19/2016 06:10 AM, Paolo Bonzini wrote: > > > On 13/06/2016 11:58, Bob Liu wrote: >> A guest might be migrated to other hosts with different num_queues, the >> blk-core should aware of that else the reference of >vqs[qid] may be >> wrong. >> >> Signed-off-by: Bob Liu <bob@oracle.com> >> --- >> drivers/block/virtio_blk.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c >> index 42758b5..c169238 100644 >> --- a/drivers/block/virtio_blk.c >> +++ b/drivers/block/virtio_blk.c >> @@ -819,6 +819,9 @@ static int virtblk_restore(struct virtio_device *vdev) >> if (ret) >> return ret; >> >> +if (vblk->num_vqs != vblk->tag_set.nr_hw_queues) >> +blk_mq_update_nr_hw_queues(>tag_set, vblk->num_vqs); >> + >> virtio_device_ready(vdev); >> >> blk_mq_start_stopped_hw_queues(vblk->disk->queue, true); >> > > This should never happen; it'd be a configuration problem. > Do you mean all hosts have to be configured with the same number of ->num_vqs? What about cases like migrating a guest from HostA to HostB while HostB is much more powerful and would like to run more hardware queues to get better performance. Thanks, Bob Liu ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] drivers: virtio_blk: notify blk-core when hw-queue number changes
A guest might be migrated to other hosts with different num_queues, the blk-core should aware of that else the reference of >vqs[qid] may be wrong. Signed-off-by: Bob Liu <bob@oracle.com> --- drivers/block/virtio_blk.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 42758b5..c169238 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -819,6 +819,9 @@ static int virtblk_restore(struct virtio_device *vdev) if (ret) return ret; + if (vblk->num_vqs != vblk->tag_set.nr_hw_queues) + blk_mq_update_nr_hw_queues(>tag_set, vblk->num_vqs); + virtio_device_ready(vdev); blk_mq_start_stopped_hw_queues(vblk->disk->queue, true); -- 2.7.4 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
