* [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace
@ 2021-05-17 9:55 Xie Yongji
2021-05-17 9:55 ` [PATCH v7 01/12] iova: Export alloc_iova_fast() Xie Yongji
` (12 more replies)
0 siblings, 13 replies; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
This series introduces a framework, which can be used to implement
vDPA Devices in a userspace program. The work consist of two parts:
control path forwarding and data path offloading.
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 core is mapping dma buffer into VDUSE
daemon's address space, which can be implemented in different ways
depending on the vdpa bus to which the vDPA device is attached.
In virtio-vdpa case, we implements a MMU-based on-chip IOMMU driver with
bounce-buffering mechanism to achieve that. And in vhost-vdpa case, the dma
buffer is reside in a userspace memory region which can be shared to the
VDUSE userspace processs via transferring the shmfd.
The details and our user case is shown below:
------------------------ ------------------------- ----------------------------------------------
| Container | | QEMU(VM) | | VDUSE daemon |
| --------- | | ------------------- | | ------------------------- ---------------- |
| |dev/vdx| | | |/dev/vhost-vdpa-x| | | | vDPA device emulation | | block driver | |
------------+----------- -----------+------------ -------------+----------------------+---------
| | | |
| | | |
------------+---------------------------+----------------------------+----------------------+---------
| | block device | | vhost device | | vduse driver | | TCP/IP | |
| -------+-------- --------+-------- -------+-------- -----+---- |
| | | | | |
| ----------+---------- ----------+----------- -------+------- | |
| | virtio-blk driver | | vhost-vdpa driver | | vdpa device | | |
| ----------+---------- ----------+----------- -------+------- | |
| | virtio bus | | | |
| --------+----+----------- | | | |
| | | | | |
| ----------+---------- | | | |
| | virtio-blk device | | | | |
| ----------+---------- | | | |
| | | | | |
| -----------+----------- | | | |
| | virtio-vdpa driver | | | | |
| -----------+----------- | | | |
| | | | vdpa bus | |
| -----------+----------------------+---------------------------+------------ | |
| ---+--- |
-----------------------------------------------------------------------------------------| NIC |------
---+---
|
---------+---------
| Remote Storages |
-------------------
We make use of it to implement a block device connecting to
our distributed storage, which can be used both in containers and
VMs. Thus, we can have an unified technology stack in this two cases.
To test it with null-blk:
$ qemu-storage-daemon \
--chardev socket,id=charmonitor,path=/tmp/qmp.sock,server,nowait \
--monitor chardev=charmonitor \
--blockdev driver=host_device,cache.direct=on,aio=native,filename=/dev/nullb0,node-name=disk0 \
--export type=vduse-blk,id=test,node-name=disk0,writable=on,name=vduse-null,num-queues=16,queue-size=128
The qemu-storage-daemon can be found at https://github.com/bytedance/qemu/tree/vduse
To make the userspace VDUSE processes such as qemu-storage-daemon able to
run unprivileged. We did some works on virtio driver to avoid trusting
device, including:
- validating the device status:
* https://lore.kernel.org/lkml/20210517093428.670-1-xieyongji@bytedance.com/
- validating the used length:
* https://lore.kernel.org/lkml/20210517090836.533-1-xieyongji@bytedance.com/
- validating the device config:
* patch 4 ("virtio-blk: Add validation for block size in config space")
- validating the device response:
* patch 5 ("virtio_scsi: Add validation for residual bytes from response")
Since I'm not sure if I missing something during auditing, especially on some
virtio device drivers that I'm not familiar with, now we only support emualting
a few vDPA devices by default, including: virtio-net device, virtio-blk device,
virtio-scsi device and virtio-fs device. This limitaion can help to reduce
security risks. When a sysadmin trusts the userspace process enough, it can relax
the limitation with a 'allow_unsafe_device_emulation' module parameter.
Future work:
- Improve performance
- Userspace library (find a way to reuse device emulation code in qemu/rust-vmm)
V6 to V7:
- Export alloc_iova_fast()
- Add get_config_size() callback
- Add some patches to avoid trusting virtio devices
- Add limited device emulation
- Add some documents
- Use workqueue to inject config irq
- Add parameter on vq irq injecting
- Rename vduse_domain_get_mapping_page() to vduse_domain_get_coherent_page()
- Add WARN_ON() to catch message failure
- Add some padding/reserved fields to uAPI structure
- Fix some bugs
- Rebase to vhost.git
V5 to V6:
- Export receive_fd() instead of __receive_fd()
- Factor out the unmapping logic of pa and va separatedly
- Remove the logic of bounce page allocation in page fault handler
- Use PAGE_SIZE as IOVA allocation granule
- Add EPOLLOUT support
- Enable setting API version in userspace
- Fix some bugs
V4 to V5:
- Remove the patch for irq binding
- Use a single IOTLB for all types of mapping
- Factor out vhost_vdpa_pa_map()
- Add some sample codes in document
- Use receice_fd_user() to pass file descriptor
- Fix some bugs
V3 to V4:
- Rebase to vhost.git
- Split some patches
- Add some documents
- Use ioctl to inject interrupt rather than eventfd
- Enable config interrupt support
- Support binding irq to the specified cpu
- Add two module parameter to limit bounce/iova size
- Create char device rather than anon inode per vduse
- Reuse vhost IOTLB for iova domain
- Rework the message mechnism in control path
V2 to V3:
- Rework the MMU-based IOMMU driver
- Use the iova domain as iova allocator instead of genpool
- Support transferring vma->vm_file in vhost-vdpa
- Add SVA support in vhost-vdpa
- Remove the patches on bounce pages reclaim
V1 to V2:
- Add vhost-vdpa support
- Add some documents
- Based on the vdpa management tool
- Introduce a workqueue for irq injection
- Replace interval tree with array map to store the iova_map
Xie Yongji (12):
iova: Export alloc_iova_fast()
file: Export receive_fd() to modules
eventfd: Increase the recursion depth of eventfd_signal()
virtio-blk: Add validation for block size in config space
virtio_scsi: Add validation for residual bytes from response
vhost-iotlb: Add an opaque pointer for vhost IOTLB
vdpa: Add an opaque pointer for vdpa_config_ops.dma_map()
vdpa: factor out vhost_vdpa_pa_map() and vhost_vdpa_pa_unmap()
vdpa: Support transferring virtual addressing during DMA mapping
vduse: Implement an MMU-based IOMMU driver
vduse: Introduce VDUSE - vDPA Device in Userspace
Documentation: Add documentation for VDUSE
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
Documentation/userspace-api/vduse.rst | 243 ++++
drivers/block/virtio_blk.c | 2 +-
drivers/iommu/iova.c | 1 +
drivers/scsi/virtio_scsi.c | 2 +-
drivers/vdpa/Kconfig | 10 +
drivers/vdpa/Makefile | 1 +
drivers/vdpa/ifcvf/ifcvf_main.c | 2 +-
drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
drivers/vdpa/vdpa.c | 9 +-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 8 +-
drivers/vdpa/vdpa_user/Makefile | 5 +
drivers/vdpa/vdpa_user/iova_domain.c | 531 +++++++
drivers/vdpa/vdpa_user/iova_domain.h | 70 +
drivers/vdpa/vdpa_user/vduse_dev.c | 1453 ++++++++++++++++++++
drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +-
drivers/vhost/iotlb.c | 20 +-
drivers/vhost/vdpa.c | 148 +-
fs/eventfd.c | 2 +-
fs/file.c | 6 +
include/linux/eventfd.h | 5 +-
include/linux/file.h | 7 +-
include/linux/vdpa.h | 21 +-
include/linux/vhost_iotlb.h | 3 +
include/uapi/linux/vduse.h | 178 +++
26 files changed, 2681 insertions(+), 52 deletions(-)
create mode 100644 Documentation/userspace-api/vduse.rst
create mode 100644 drivers/vdpa/vdpa_user/Makefile
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_dev.c
create mode 100644 include/uapi/linux/vduse.h
--
2.11.0
^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH v7 01/12] iova: Export alloc_iova_fast()
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
@ 2021-05-17 9:55 ` Xie Yongji
2021-05-26 2:36 ` Jason Wang
2021-05-17 9:55 ` [PATCH v7 02/12] file: Export receive_fd() to modules Xie Yongji
` (11 subsequent siblings)
12 siblings, 1 reply; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
Export alloc_iova_fast() so that some modules can use it
to improve iova allocation efficiency.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
drivers/iommu/iova.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index e6e2fa85271c..317eef64ffef 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -450,6 +450,7 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long size,
return new_iova->pfn_lo;
}
+EXPORT_SYMBOL_GPL(alloc_iova_fast);
/**
* free_iova_fast - free iova pfn range into rcache
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 02/12] file: Export receive_fd() to modules
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-17 9:55 ` Xie Yongji
2021-05-20 6:18 ` Al Viro
2021-05-17 9:55 ` [PATCH v7 03/12] eventfd: Increase the recursion depth of eventfd_signal() Xie Yongji
` (10 subsequent siblings)
12 siblings, 1 reply; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
Export receive_fd() so that some modules can use
it to pass file descriptor between processes without
missing any security stuffs.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
fs/file.c | 6 ++++++
include/linux/file.h | 7 +++----
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index f633348029a5..ef4da2eaf25b 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -1135,6 +1135,12 @@ int __receive_fd(int fd, struct file *file, int __user *ufd, unsigned int o_flag
return new_fd;
}
+int receive_fd(struct file *file, unsigned int o_flags)
+{
+ return __receive_fd(-1, file, NULL, o_flags);
+}
+EXPORT_SYMBOL_GPL(receive_fd);
+
static int ksys_dup3(unsigned int oldfd, unsigned int newfd, int flags)
{
int err = -EBADF;
diff --git a/include/linux/file.h b/include/linux/file.h
index 225982792fa2..4667f9567d3e 100644
--- a/include/linux/file.h
+++ b/include/linux/file.h
@@ -94,6 +94,9 @@ extern void fd_install(unsigned int fd, struct file *file);
extern int __receive_fd(int fd, struct file *file, int __user *ufd,
unsigned int o_flags);
+
+extern int receive_fd(struct file *file, unsigned int o_flags);
+
static inline int receive_fd_user(struct file *file, int __user *ufd,
unsigned int o_flags)
{
@@ -101,10 +104,6 @@ static inline int receive_fd_user(struct file *file, int __user *ufd,
return -EFAULT;
return __receive_fd(-1, file, ufd, o_flags);
}
-static inline int receive_fd(struct file *file, unsigned int o_flags)
-{
- return __receive_fd(-1, file, NULL, o_flags);
-}
static inline int receive_fd_replace(int fd, struct file *file, unsigned int o_flags)
{
return __receive_fd(fd, file, NULL, o_flags);
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 03/12] eventfd: Increase the recursion depth of eventfd_signal()
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-17 9:55 ` [PATCH v7 02/12] file: Export receive_fd() to modules Xie Yongji
@ 2021-05-17 9:55 ` Xie Yongji
2021-05-17 9:55 ` [PATCH v7 04/12] virtio-blk: Add validation for block size in config space Xie Yongji
` (9 subsequent siblings)
12 siblings, 0 replies; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
Increase the recursion depth of eventfd_signal() to 1. This
is the maximum recursion depth we have found so far, which
can be triggered with the following call chain:
kvm_io_bus_write [kvm]
--> ioeventfd_write [kvm]
--> eventfd_signal [eventfd]
--> vhost_poll_wakeup [vhost]
--> vduse_vdpa_kick_vq [vduse]
--> eventfd_signal [eventfd]
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
fs/eventfd.c | 2 +-
include/linux/eventfd.h | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/eventfd.c b/fs/eventfd.c
index e265b6dd4f34..cc7cd1dbedd3 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -71,7 +71,7 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
* it returns true, the eventfd_signal() call should be deferred to a
* safe context.
*/
- if (WARN_ON_ONCE(this_cpu_read(eventfd_wake_count)))
+ if (WARN_ON_ONCE(this_cpu_read(eventfd_wake_count) > EFD_WAKE_DEPTH))
return 0;
spin_lock_irqsave(&ctx->wqh.lock, flags);
diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h
index fa0a524baed0..886d99cd38ef 100644
--- a/include/linux/eventfd.h
+++ b/include/linux/eventfd.h
@@ -29,6 +29,9 @@
#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE)
+/* Maximum recursion depth */
+#define EFD_WAKE_DEPTH 1
+
struct eventfd_ctx;
struct file;
@@ -47,7 +50,7 @@ DECLARE_PER_CPU(int, eventfd_wake_count);
static inline bool eventfd_signal_count(void)
{
- return this_cpu_read(eventfd_wake_count);
+ return this_cpu_read(eventfd_wake_count) > EFD_WAKE_DEPTH;
}
#else /* CONFIG_EVENTFD */
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 04/12] virtio-blk: Add validation for block size in config space
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (2 preceding siblings ...)
2021-05-17 9:55 ` [PATCH v7 03/12] eventfd: Increase the recursion depth of eventfd_signal() Xie Yongji
@ 2021-05-17 9:55 ` Xie Yongji
2021-05-19 13:39 ` Yongji Xie
2021-05-17 9:55 ` [PATCH v7 05/12] virtio_scsi: Add validation for residual bytes from response Xie Yongji
` (8 subsequent siblings)
12 siblings, 1 reply; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
This ensures that we will not use an invalid block size
in config space (might come from an untrusted device).
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
drivers/block/virtio_blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index ebb4d3fe803f..c848aa36d49b 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -826,7 +826,7 @@ static int virtblk_probe(struct virtio_device *vdev)
err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
struct virtio_blk_config, blk_size,
&blk_size);
- if (!err)
+ if (!err && blk_size > 0 && blk_size <= max_size)
blk_queue_logical_block_size(q, blk_size);
else
blk_size = queue_logical_block_size(q);
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 05/12] virtio_scsi: Add validation for residual bytes from response
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (3 preceding siblings ...)
2021-05-17 9:55 ` [PATCH v7 04/12] virtio-blk: Add validation for block size in config space Xie Yongji
@ 2021-05-17 9:55 ` 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
` (7 subsequent siblings)
12 siblings, 1 reply; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
This ensures that the residual bytes in response (might come
from an untrusted device) will not exceed the data buffer length.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
drivers/scsi/virtio_scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index efcaf0674c8d..ad7d8cecec32 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -97,7 +97,7 @@ static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device *vdev)
static void virtscsi_compute_resid(struct scsi_cmnd *sc, u32 resid)
{
if (resid)
- scsi_set_resid(sc, resid);
+ scsi_set_resid(sc, min(resid, scsi_bufflen(sc)));
}
/*
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 06/12] vhost-iotlb: Add an opaque pointer for vhost IOTLB
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (4 preceding siblings ...)
2021-05-17 9:55 ` [PATCH v7 05/12] virtio_scsi: Add validation for residual bytes from response Xie Yongji
@ 2021-05-17 9:55 ` Xie Yongji
2021-05-17 9:55 ` [PATCH v7 07/12] vdpa: Add an opaque pointer for vdpa_config_ops.dma_map() Xie Yongji
` (6 subsequent siblings)
12 siblings, 0 replies; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
Add an opaque pointer for vhost IOTLB. And introduce
vhost_iotlb_add_range_ctx() to accept it.
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/iotlb.c | 20 ++++++++++++++++----
include/linux/vhost_iotlb.h | 3 +++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/vhost/iotlb.c b/drivers/vhost/iotlb.c
index 0fd3f87e913c..5c99e1112cbb 100644
--- a/drivers/vhost/iotlb.c
+++ b/drivers/vhost/iotlb.c
@@ -36,19 +36,21 @@ void vhost_iotlb_map_free(struct vhost_iotlb *iotlb,
EXPORT_SYMBOL_GPL(vhost_iotlb_map_free);
/**
- * vhost_iotlb_add_range - add a new range to vhost IOTLB
+ * vhost_iotlb_add_range_ctx - add a new range to vhost IOTLB
* @iotlb: the IOTLB
* @start: start of the IOVA range
* @last: last of IOVA range
* @addr: the address that is mapped to @start
* @perm: access permission of this range
+ * @opaque: the opaque pointer for the new mapping
*
* Returns an error last is smaller than start or memory allocation
* fails
*/
-int vhost_iotlb_add_range(struct vhost_iotlb *iotlb,
- u64 start, u64 last,
- u64 addr, unsigned int perm)
+int vhost_iotlb_add_range_ctx(struct vhost_iotlb *iotlb,
+ u64 start, u64 last,
+ u64 addr, unsigned int perm,
+ void *opaque)
{
struct vhost_iotlb_map *map;
@@ -71,6 +73,7 @@ int vhost_iotlb_add_range(struct vhost_iotlb *iotlb,
map->last = last;
map->addr = addr;
map->perm = perm;
+ map->opaque = opaque;
iotlb->nmaps++;
vhost_iotlb_itree_insert(map, &iotlb->root);
@@ -80,6 +83,15 @@ int vhost_iotlb_add_range(struct vhost_iotlb *iotlb,
return 0;
}
+EXPORT_SYMBOL_GPL(vhost_iotlb_add_range_ctx);
+
+int vhost_iotlb_add_range(struct vhost_iotlb *iotlb,
+ u64 start, u64 last,
+ u64 addr, unsigned int perm)
+{
+ return vhost_iotlb_add_range_ctx(iotlb, start, last,
+ addr, perm, NULL);
+}
EXPORT_SYMBOL_GPL(vhost_iotlb_add_range);
/**
diff --git a/include/linux/vhost_iotlb.h b/include/linux/vhost_iotlb.h
index 6b09b786a762..2d0e2f52f938 100644
--- a/include/linux/vhost_iotlb.h
+++ b/include/linux/vhost_iotlb.h
@@ -17,6 +17,7 @@ struct vhost_iotlb_map {
u32 perm;
u32 flags_padding;
u64 __subtree_last;
+ void *opaque;
};
#define VHOST_IOTLB_FLAG_RETIRE 0x1
@@ -29,6 +30,8 @@ struct vhost_iotlb {
unsigned int flags;
};
+int vhost_iotlb_add_range_ctx(struct vhost_iotlb *iotlb, u64 start, u64 last,
+ u64 addr, unsigned int perm, void *opaque);
int vhost_iotlb_add_range(struct vhost_iotlb *iotlb, u64 start, u64 last,
u64 addr, unsigned int perm);
void vhost_iotlb_del_range(struct vhost_iotlb *iotlb, u64 start, u64 last);
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 07/12] vdpa: Add an opaque pointer for vdpa_config_ops.dma_map()
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (5 preceding siblings ...)
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 ` 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
` (5 subsequent siblings)
12 siblings, 0 replies; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
Add an opaque pointer for DMA mapping.
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 6 +++---
drivers/vhost/vdpa.c | 2 +-
include/linux/vdpa.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 98f793bc9376..efd0cb3d964d 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -542,14 +542,14 @@ static int vdpasim_set_map(struct vdpa_device *vdpa,
}
static int vdpasim_dma_map(struct vdpa_device *vdpa, u64 iova, u64 size,
- u64 pa, u32 perm)
+ u64 pa, u32 perm, void *opaque)
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
int ret;
spin_lock(&vdpasim->iommu_lock);
- ret = vhost_iotlb_add_range(vdpasim->iommu, iova, iova + size - 1, pa,
- perm);
+ ret = vhost_iotlb_add_range_ctx(vdpasim->iommu, iova, iova + size - 1,
+ pa, perm, opaque);
spin_unlock(&vdpasim->iommu_lock);
return ret;
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index a1496c596120..1dd8e07554f8 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -565,7 +565,7 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
return r;
if (ops->dma_map) {
- r = ops->dma_map(vdpa, iova, size, pa, perm);
+ r = ops->dma_map(vdpa, iova, size, pa, perm, NULL);
} else if (ops->set_map) {
if (!v->in_batch)
r = ops->set_map(vdpa, dev->iotlb);
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index f311d227aa1b..281f768cb597 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -245,7 +245,7 @@ struct vdpa_config_ops {
/* DMA ops */
int (*set_map)(struct vdpa_device *vdev, struct vhost_iotlb *iotlb);
int (*dma_map)(struct vdpa_device *vdev, u64 iova, u64 size,
- u64 pa, u32 perm);
+ u64 pa, u32 perm, void *opaque);
int (*dma_unmap)(struct vdpa_device *vdev, u64 iova, u64 size);
/* Free device resources */
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 08/12] vdpa: factor out vhost_vdpa_pa_map() and vhost_vdpa_pa_unmap()
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (6 preceding siblings ...)
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 ` Xie Yongji
2021-05-17 9:55 ` [PATCH v7 09/12] vdpa: Support transferring virtual addressing during DMA mapping Xie Yongji
` (4 subsequent siblings)
12 siblings, 0 replies; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
The upcoming patch is going to support VA mapping/unmapping.
So let's factor out the logic of PA mapping/unmapping firstly
to make the code more readable.
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/vdpa.c | 53 +++++++++++++++++++++++++++++++++-------------------
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 1dd8e07554f8..3c773654bf40 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -498,7 +498,7 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
return r;
}
-static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, u64 start, u64 last)
+static void vhost_vdpa_pa_unmap(struct vhost_vdpa *v, u64 start, u64 last)
{
struct vhost_dev *dev = &v->vdev;
struct vhost_iotlb *iotlb = dev->iotlb;
@@ -520,6 +520,11 @@ static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, u64 start, u64 last)
}
}
+static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, u64 start, u64 last)
+{
+ return vhost_vdpa_pa_unmap(v, start, last);
+}
+
static void vhost_vdpa_iotlb_free(struct vhost_vdpa *v)
{
struct vhost_dev *dev = &v->vdev;
@@ -600,37 +605,28 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size)
}
}
-static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
- struct vhost_iotlb_msg *msg)
+static int vhost_vdpa_pa_map(struct vhost_vdpa *v,
+ u64 iova, u64 size, u64 uaddr, u32 perm)
{
struct vhost_dev *dev = &v->vdev;
- struct vhost_iotlb *iotlb = dev->iotlb;
struct page **page_list;
unsigned long list_size = PAGE_SIZE / sizeof(struct page *);
unsigned int gup_flags = FOLL_LONGTERM;
unsigned long npages, cur_base, map_pfn, last_pfn = 0;
unsigned long lock_limit, sz2pin, nchunks, i;
- u64 iova = msg->iova;
+ u64 start = iova;
long pinned;
int ret = 0;
- if (msg->iova < v->range.first ||
- msg->iova + msg->size - 1 > v->range.last)
- return -EINVAL;
-
- if (vhost_iotlb_itree_first(iotlb, msg->iova,
- msg->iova + msg->size - 1))
- return -EEXIST;
-
/* Limit the use of memory for bookkeeping */
page_list = (struct page **) __get_free_page(GFP_KERNEL);
if (!page_list)
return -ENOMEM;
- if (msg->perm & VHOST_ACCESS_WO)
+ if (perm & VHOST_ACCESS_WO)
gup_flags |= FOLL_WRITE;
- npages = PAGE_ALIGN(msg->size + (iova & ~PAGE_MASK)) >> PAGE_SHIFT;
+ npages = PAGE_ALIGN(size + (iova & ~PAGE_MASK)) >> PAGE_SHIFT;
if (!npages) {
ret = -EINVAL;
goto free;
@@ -644,7 +640,7 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
goto unlock;
}
- cur_base = msg->uaddr & PAGE_MASK;
+ cur_base = uaddr & PAGE_MASK;
iova &= PAGE_MASK;
nchunks = 0;
@@ -675,7 +671,7 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
csize = (last_pfn - map_pfn + 1) << PAGE_SHIFT;
ret = vhost_vdpa_map(v, iova, csize,
map_pfn << PAGE_SHIFT,
- msg->perm);
+ perm);
if (ret) {
/*
* Unpin the pages that are left unmapped
@@ -704,7 +700,7 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
/* Pin the rest chunk */
ret = vhost_vdpa_map(v, iova, (last_pfn - map_pfn + 1) << PAGE_SHIFT,
- map_pfn << PAGE_SHIFT, msg->perm);
+ map_pfn << PAGE_SHIFT, perm);
out:
if (ret) {
if (nchunks) {
@@ -723,13 +719,32 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
for (pfn = map_pfn; pfn <= last_pfn; pfn++)
unpin_user_page(pfn_to_page(pfn));
}
- vhost_vdpa_unmap(v, msg->iova, msg->size);
+ vhost_vdpa_unmap(v, start, size);
}
unlock:
mmap_read_unlock(dev->mm);
free:
free_page((unsigned long)page_list);
return ret;
+
+}
+
+static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
+ struct vhost_iotlb_msg *msg)
+{
+ struct vhost_dev *dev = &v->vdev;
+ struct vhost_iotlb *iotlb = dev->iotlb;
+
+ if (msg->iova < v->range.first ||
+ msg->iova + msg->size - 1 > v->range.last)
+ return -EINVAL;
+
+ if (vhost_iotlb_itree_first(iotlb, msg->iova,
+ msg->iova + msg->size - 1))
+ return -EEXIST;
+
+ return vhost_vdpa_pa_map(v, msg->iova, msg->size, msg->uaddr,
+ msg->perm);
}
static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev,
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 09/12] vdpa: Support transferring virtual addressing during DMA mapping
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (7 preceding siblings ...)
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 ` Xie Yongji
2021-05-17 9:55 ` [PATCH v7 10/12] vduse: Implement an MMU-based IOMMU driver Xie Yongji
` (3 subsequent siblings)
12 siblings, 0 replies; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
This patch introduces an attribute for vDPA device to indicate
whether virtual address can be used. If vDPA device driver set
it, vhost-vdpa bus driver will not pin user page and transfer
userspace virtual address instead of physical address during
DMA mapping. And corresponding vma->vm_file and offset will be
also passed as an opaque pointer.
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/vdpa/ifcvf/ifcvf_main.c | 2 +-
drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
drivers/vdpa/vdpa.c | 9 +++-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 2 +-
drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +-
drivers/vhost/vdpa.c | 99 ++++++++++++++++++++++++++++++++++-----
include/linux/vdpa.h | 19 ++++++--
7 files changed, 116 insertions(+), 19 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index ab0ab5cf0f6e..daf9746e51e6 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -476,7 +476,7 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct pci_device_id *id)
}
adapter = vdpa_alloc_device(struct ifcvf_adapter, vdpa,
- dev, &ifc_vdpa_ops, NULL);
+ dev, &ifc_vdpa_ops, NULL, false);
if (adapter == NULL) {
IFCVF_ERR(pdev, "Failed to allocate vDPA structure");
return -ENOMEM;
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 189e4385df40..8a4cb999152b 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -2005,7 +2005,7 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name)
max_vqs = min_t(u32, max_vqs, MLX5_MAX_SUPPORTED_VQS);
ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev, mdev->device, &mlx5_vdpa_ops,
- name);
+ name, false);
if (IS_ERR(ndev))
return PTR_ERR(ndev);
diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
index bb3f1d1f0422..8f01d6a7ecc5 100644
--- a/drivers/vdpa/vdpa.c
+++ b/drivers/vdpa/vdpa.c
@@ -71,6 +71,7 @@ static void vdpa_release_dev(struct device *d)
* @config: the bus operations that is supported by this device
* @size: size of the parent structure that contains private data
* @name: name of the vdpa device; optional.
+ * @use_va: indicate whether virtual address must be used by this device
*
* Driver should use vdpa_alloc_device() wrapper macro instead of
* using this directly.
@@ -80,7 +81,8 @@ static void vdpa_release_dev(struct device *d)
*/
struct vdpa_device *__vdpa_alloc_device(struct device *parent,
const struct vdpa_config_ops *config,
- size_t size, const char *name)
+ size_t size, const char *name,
+ bool use_va)
{
struct vdpa_device *vdev;
int err = -EINVAL;
@@ -91,6 +93,10 @@ struct vdpa_device *__vdpa_alloc_device(struct device *parent,
if (!!config->dma_map != !!config->dma_unmap)
goto err;
+ /* It should only work for the device that use on-chip IOMMU */
+ if (use_va && !(config->dma_map || config->set_map))
+ goto err;
+
err = -ENOMEM;
vdev = kzalloc(size, GFP_KERNEL);
if (!vdev)
@@ -106,6 +112,7 @@ struct vdpa_device *__vdpa_alloc_device(struct device *parent,
vdev->index = err;
vdev->config = config;
vdev->features_valid = false;
+ vdev->use_va = use_va;
if (name)
err = dev_set_name(&vdev->dev, "%s", name);
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index efd0cb3d964d..a43479cf57ea 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -250,7 +250,7 @@ struct vdpasim *vdpasim_create(struct vdpasim_dev_attr *dev_attr)
ops = &vdpasim_config_ops;
vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops,
- dev_attr->name);
+ dev_attr->name, false);
if (!vdpasim)
goto err_alloc;
diff --git a/drivers/vdpa/virtio_pci/vp_vdpa.c b/drivers/vdpa/virtio_pci/vp_vdpa.c
index c76ebb531212..f907f42e83bb 100644
--- a/drivers/vdpa/virtio_pci/vp_vdpa.c
+++ b/drivers/vdpa/virtio_pci/vp_vdpa.c
@@ -399,7 +399,7 @@ static int vp_vdpa_probe(struct pci_dev *pdev, const struct pci_device_id *id)
return ret;
vp_vdpa = vdpa_alloc_device(struct vp_vdpa, vdpa,
- dev, &vp_vdpa_ops, NULL);
+ dev, &vp_vdpa_ops, NULL, false);
if (vp_vdpa == NULL) {
dev_err(dev, "vp_vdpa: Failed to allocate vDPA structure\n");
return -ENOMEM;
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 3c773654bf40..20a0a9f32331 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -520,8 +520,28 @@ static void vhost_vdpa_pa_unmap(struct vhost_vdpa *v, u64 start, u64 last)
}
}
+static void vhost_vdpa_va_unmap(struct vhost_vdpa *v, u64 start, u64 last)
+{
+ struct vhost_dev *dev = &v->vdev;
+ struct vhost_iotlb *iotlb = dev->iotlb;
+ struct vhost_iotlb_map *map;
+ struct vdpa_map_file *map_file;
+
+ while ((map = vhost_iotlb_itree_first(iotlb, start, last)) != NULL) {
+ map_file = (struct vdpa_map_file *)map->opaque;
+ fput(map_file->file);
+ kfree(map_file);
+ vhost_iotlb_map_free(iotlb, map);
+ }
+}
+
static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, u64 start, u64 last)
{
+ struct vdpa_device *vdpa = v->vdpa;
+
+ if (vdpa->use_va)
+ return vhost_vdpa_va_unmap(v, start, last);
+
return vhost_vdpa_pa_unmap(v, start, last);
}
@@ -556,21 +576,21 @@ static int perm_to_iommu_flags(u32 perm)
return flags | IOMMU_CACHE;
}
-static int vhost_vdpa_map(struct vhost_vdpa *v,
- u64 iova, u64 size, u64 pa, u32 perm)
+static int vhost_vdpa_map(struct vhost_vdpa *v, u64 iova,
+ u64 size, u64 pa, u32 perm, void *opaque)
{
struct vhost_dev *dev = &v->vdev;
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
int r = 0;
- r = vhost_iotlb_add_range(dev->iotlb, iova, iova + size - 1,
- pa, perm);
+ r = vhost_iotlb_add_range_ctx(dev->iotlb, iova, iova + size - 1,
+ pa, perm, opaque);
if (r)
return r;
if (ops->dma_map) {
- r = ops->dma_map(vdpa, iova, size, pa, perm, NULL);
+ r = ops->dma_map(vdpa, iova, size, pa, perm, opaque);
} else if (ops->set_map) {
if (!v->in_batch)
r = ops->set_map(vdpa, dev->iotlb);
@@ -578,13 +598,15 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
r = iommu_map(v->domain, iova, pa, size,
perm_to_iommu_flags(perm));
}
-
- if (r)
+ if (r) {
vhost_iotlb_del_range(dev->iotlb, iova, iova + size - 1);
- else
+ return r;
+ }
+
+ if (!vdpa->use_va)
atomic64_add(size >> PAGE_SHIFT, &dev->mm->pinned_vm);
- return r;
+ return 0;
}
static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size)
@@ -605,6 +627,56 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size)
}
}
+static int vhost_vdpa_va_map(struct vhost_vdpa *v,
+ u64 iova, u64 size, u64 uaddr, u32 perm)
+{
+ struct vhost_dev *dev = &v->vdev;
+ u64 offset, map_size, map_iova = iova;
+ struct vdpa_map_file *map_file;
+ struct vm_area_struct *vma;
+ int ret;
+
+ mmap_read_lock(dev->mm);
+
+ while (size) {
+ vma = find_vma(dev->mm, uaddr);
+ if (!vma) {
+ ret = -EINVAL;
+ break;
+ }
+ map_size = min(size, vma->vm_end - uaddr);
+ if (!(vma->vm_file && (vma->vm_flags & VM_SHARED) &&
+ !(vma->vm_flags & (VM_IO | VM_PFNMAP))))
+ goto next;
+
+ map_file = kzalloc(sizeof(*map_file), GFP_KERNEL);
+ if (!map_file) {
+ ret = -ENOMEM;
+ break;
+ }
+ offset = (vma->vm_pgoff << PAGE_SHIFT) + uaddr - vma->vm_start;
+ map_file->offset = offset;
+ map_file->file = get_file(vma->vm_file);
+ ret = vhost_vdpa_map(v, map_iova, map_size, uaddr,
+ perm, map_file);
+ if (ret) {
+ fput(map_file->file);
+ kfree(map_file);
+ break;
+ }
+next:
+ size -= map_size;
+ uaddr += map_size;
+ map_iova += map_size;
+ }
+ if (ret)
+ vhost_vdpa_unmap(v, iova, map_iova - iova);
+
+ mmap_read_unlock(dev->mm);
+
+ return ret;
+}
+
static int vhost_vdpa_pa_map(struct vhost_vdpa *v,
u64 iova, u64 size, u64 uaddr, u32 perm)
{
@@ -671,7 +743,7 @@ static int vhost_vdpa_pa_map(struct vhost_vdpa *v,
csize = (last_pfn - map_pfn + 1) << PAGE_SHIFT;
ret = vhost_vdpa_map(v, iova, csize,
map_pfn << PAGE_SHIFT,
- perm);
+ perm, NULL);
if (ret) {
/*
* Unpin the pages that are left unmapped
@@ -700,7 +772,7 @@ static int vhost_vdpa_pa_map(struct vhost_vdpa *v,
/* Pin the rest chunk */
ret = vhost_vdpa_map(v, iova, (last_pfn - map_pfn + 1) << PAGE_SHIFT,
- map_pfn << PAGE_SHIFT, perm);
+ map_pfn << PAGE_SHIFT, perm, NULL);
out:
if (ret) {
if (nchunks) {
@@ -733,6 +805,7 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
struct vhost_iotlb_msg *msg)
{
struct vhost_dev *dev = &v->vdev;
+ struct vdpa_device *vdpa = v->vdpa;
struct vhost_iotlb *iotlb = dev->iotlb;
if (msg->iova < v->range.first ||
@@ -743,6 +816,10 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
msg->iova + msg->size - 1))
return -EEXIST;
+ if (vdpa->use_va)
+ return vhost_vdpa_va_map(v, msg->iova, msg->size,
+ msg->uaddr, msg->perm);
+
return vhost_vdpa_pa_map(v, msg->iova, msg->size, msg->uaddr,
msg->perm);
}
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 281f768cb597..85124d197c55 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -44,6 +44,7 @@ struct vdpa_mgmt_dev;
* @config: the configuration ops for this device.
* @index: device index
* @features_valid: were features initialized? for legacy guests
+ * @use_va: indicate whether virtual address must be used by this device
* @nvqs: maximum number of supported virtqueues
* @mdev: management device pointer; caller must setup when registering device as part
* of dev_add() mgmtdev ops callback before invoking _vdpa_register_device().
@@ -54,6 +55,7 @@ struct vdpa_device {
const struct vdpa_config_ops *config;
unsigned int index;
bool features_valid;
+ bool use_va;
int nvqs;
struct vdpa_mgmt_dev *mdev;
};
@@ -69,6 +71,16 @@ struct vdpa_iova_range {
};
/**
+ * Corresponding file area for device memory mapping
+ * @file: vma->vm_file for the mapping
+ * @offset: mapping offset in the vm_file
+ */
+struct vdpa_map_file {
+ struct file *file;
+ u64 offset;
+};
+
+/**
* struct vdpa_config_ops - operations for configuring a vDPA device.
* Note: vDPA device drivers are required to implement all of the
* operations unless it is mentioned to be optional in the following
@@ -254,14 +266,15 @@ struct vdpa_config_ops {
struct vdpa_device *__vdpa_alloc_device(struct device *parent,
const struct vdpa_config_ops *config,
- size_t size, const char *name);
+ size_t size, const char *name,
+ bool use_va);
-#define vdpa_alloc_device(dev_struct, member, parent, config, name) \
+#define vdpa_alloc_device(dev_struct, member, parent, config, name, use_va) \
container_of(__vdpa_alloc_device( \
parent, config, \
sizeof(dev_struct) + \
BUILD_BUG_ON_ZERO(offsetof( \
- dev_struct, member)), name), \
+ dev_struct, member)), name, use_va), \
dev_struct, member)
int vdpa_register_device(struct vdpa_device *vdev, int nvqs);
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 10/12] vduse: Implement an MMU-based IOMMU driver
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (8 preceding siblings ...)
2021-05-17 9:55 ` [PATCH v7 09/12] vdpa: Support transferring virtual addressing during DMA mapping Xie Yongji
@ 2021-05-17 9:55 ` Xie Yongji
2021-05-17 9:55 ` [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (2 subsequent siblings)
12 siblings, 0 replies; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
This implements an MMU-based IOMMU driver to support mapping
kernel dma buffer into userspace. The basic idea behind it is
treating MMU (VA->PA) as IOMMU (IOVA->PA). The driver will set
up MMU mapping instead of IOMMU mapping for the DMA transfer so
that the userspace process is able to use its virtual address to
access the dma buffer in kernel.
And to avoid security issue, a bounce-buffering mechanism is
introduced to prevent userspace accessing the original buffer
directly.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/vdpa/vdpa_user/iova_domain.c | 531 +++++++++++++++++++++++++++++++++++
drivers/vdpa/vdpa_user/iova_domain.h | 70 +++++
2 files changed, 601 insertions(+)
create mode 100644 drivers/vdpa/vdpa_user/iova_domain.c
create mode 100644 drivers/vdpa/vdpa_user/iova_domain.h
diff --git a/drivers/vdpa/vdpa_user/iova_domain.c b/drivers/vdpa/vdpa_user/iova_domain.c
new file mode 100644
index 000000000000..560b0516f6cd
--- /dev/null
+++ b/drivers/vdpa/vdpa_user/iova_domain.c
@@ -0,0 +1,531 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * MMU-based IOMMU implementation
+ *
+ * Copyright (C) 2020-2021 Bytedance Inc. and/or its affiliates. All rights reserved.
+ *
+ * Author: Xie Yongji <xieyongji@bytedance.com>
+ *
+ */
+
+#include <linux/slab.h>
+#include <linux/file.h>
+#include <linux/anon_inodes.h>
+#include <linux/highmem.h>
+#include <linux/vmalloc.h>
+#include <linux/vdpa.h>
+
+#include "iova_domain.h"
+
+static int vduse_iotlb_add_range(struct vduse_iova_domain *domain,
+ u64 start, u64 last,
+ u64 addr, unsigned int perm,
+ struct file *file, u64 offset)
+{
+ struct vdpa_map_file *map_file;
+ int ret;
+
+ map_file = kmalloc(sizeof(*map_file), GFP_ATOMIC);
+ if (!map_file)
+ return -ENOMEM;
+
+ map_file->file = get_file(file);
+ map_file->offset = offset;
+
+ ret = vhost_iotlb_add_range_ctx(domain->iotlb, start, last,
+ addr, perm, map_file);
+ if (ret) {
+ fput(map_file->file);
+ kfree(map_file);
+ return ret;
+ }
+ return 0;
+}
+
+static void vduse_iotlb_del_range(struct vduse_iova_domain *domain,
+ u64 start, u64 last)
+{
+ struct vdpa_map_file *map_file;
+ struct vhost_iotlb_map *map;
+
+ while ((map = vhost_iotlb_itree_first(domain->iotlb, start, last))) {
+ map_file = (struct vdpa_map_file *)map->opaque;
+ fput(map_file->file);
+ kfree(map_file);
+ vhost_iotlb_map_free(domain->iotlb, map);
+ }
+}
+
+int vduse_domain_set_map(struct vduse_iova_domain *domain,
+ struct vhost_iotlb *iotlb)
+{
+ struct vdpa_map_file *map_file;
+ struct vhost_iotlb_map *map;
+ u64 start = 0ULL, last = ULLONG_MAX;
+ int ret;
+
+ spin_lock(&domain->iotlb_lock);
+ vduse_iotlb_del_range(domain, start, last);
+
+ for (map = vhost_iotlb_itree_first(iotlb, start, last); map;
+ map = vhost_iotlb_itree_next(map, start, last)) {
+ map_file = (struct vdpa_map_file *)map->opaque;
+ ret = vduse_iotlb_add_range(domain, map->start, map->last,
+ map->addr, map->perm,
+ map_file->file,
+ map_file->offset);
+ if (ret)
+ goto err;
+ }
+ spin_unlock(&domain->iotlb_lock);
+
+ return 0;
+err:
+ vduse_iotlb_del_range(domain, start, last);
+ spin_unlock(&domain->iotlb_lock);
+ return ret;
+}
+
+static int vduse_domain_map_bounce_page(struct vduse_iova_domain *domain,
+ u64 iova, u64 size, u64 paddr)
+{
+ struct vduse_bounce_map *map;
+ u64 last = iova + size - 1;
+
+ while (iova <= last) {
+ map = &domain->bounce_maps[iova >> PAGE_SHIFT];
+ if (!map->bounce_page) {
+ map->bounce_page = alloc_page(GFP_ATOMIC);
+ if (!map->bounce_page)
+ return -ENOMEM;
+ }
+ map->orig_phys = paddr;
+ paddr += PAGE_SIZE;
+ iova += PAGE_SIZE;
+ }
+ return 0;
+}
+
+static void vduse_domain_unmap_bounce_page(struct vduse_iova_domain *domain,
+ u64 iova, u64 size)
+{
+ struct vduse_bounce_map *map;
+ u64 last = iova + size - 1;
+
+ while (iova <= last) {
+ map = &domain->bounce_maps[iova >> PAGE_SHIFT];
+ map->orig_phys = INVALID_PHYS_ADDR;
+ iova += PAGE_SIZE;
+ }
+}
+
+static void do_bounce(phys_addr_t orig, void *addr, size_t size,
+ enum dma_data_direction dir)
+{
+ unsigned long pfn = PFN_DOWN(orig);
+ unsigned int offset = offset_in_page(orig);
+ char *buffer;
+ unsigned int sz = 0;
+
+ while (size) {
+ sz = min_t(size_t, PAGE_SIZE - offset, size);
+
+ buffer = kmap_atomic(pfn_to_page(pfn));
+ if (dir == DMA_TO_DEVICE)
+ memcpy(addr, buffer + offset, sz);
+ else
+ memcpy(buffer + offset, addr, sz);
+ kunmap_atomic(buffer);
+
+ size -= sz;
+ pfn++;
+ addr += sz;
+ offset = 0;
+ }
+}
+
+static void vduse_domain_bounce(struct vduse_iova_domain *domain,
+ dma_addr_t iova, size_t size,
+ enum dma_data_direction dir)
+{
+ struct vduse_bounce_map *map;
+ unsigned int offset;
+ void *addr;
+ size_t sz;
+
+ if (iova >= domain->bounce_size)
+ return;
+
+ while (size) {
+ map = &domain->bounce_maps[iova >> PAGE_SHIFT];
+ offset = offset_in_page(iova);
+ sz = min_t(size_t, PAGE_SIZE - offset, size);
+
+ if (WARN_ON(!map->bounce_page ||
+ map->orig_phys == INVALID_PHYS_ADDR))
+ return;
+
+ addr = page_address(map->bounce_page) + offset;
+ do_bounce(map->orig_phys + offset, addr, sz, dir);
+ size -= sz;
+ iova += sz;
+ }
+}
+
+static struct page *
+vduse_domain_get_coherent_page(struct vduse_iova_domain *domain, u64 iova)
+{
+ u64 start = iova & PAGE_MASK;
+ u64 last = start + PAGE_SIZE - 1;
+ struct vhost_iotlb_map *map;
+ struct page *page = NULL;
+
+ spin_lock(&domain->iotlb_lock);
+ map = vhost_iotlb_itree_first(domain->iotlb, start, last);
+ if (!map)
+ goto out;
+
+ page = pfn_to_page((map->addr + iova - map->start) >> PAGE_SHIFT);
+ get_page(page);
+out:
+ spin_unlock(&domain->iotlb_lock);
+
+ return page;
+}
+
+static struct page *
+vduse_domain_get_bounce_page(struct vduse_iova_domain *domain, u64 iova)
+{
+ struct vduse_bounce_map *map;
+ struct page *page = NULL;
+
+ spin_lock(&domain->iotlb_lock);
+ map = &domain->bounce_maps[iova >> PAGE_SHIFT];
+ if (!map->bounce_page)
+ goto out;
+
+ page = map->bounce_page;
+ get_page(page);
+out:
+ spin_unlock(&domain->iotlb_lock);
+
+ return page;
+}
+
+static void
+vduse_domain_free_bounce_pages(struct vduse_iova_domain *domain)
+{
+ struct vduse_bounce_map *map;
+ unsigned long pfn, bounce_pfns;
+
+ spin_lock(&domain->iotlb_lock);
+ bounce_pfns = domain->bounce_size >> PAGE_SHIFT;
+
+ for (pfn = 0; pfn < bounce_pfns; pfn++) {
+ map = &domain->bounce_maps[pfn];
+ if (WARN_ON(map->orig_phys != INVALID_PHYS_ADDR))
+ continue;
+
+ if (!map->bounce_page)
+ continue;
+
+ __free_page(map->bounce_page);
+ map->bounce_page = NULL;
+ }
+ spin_unlock(&domain->iotlb_lock);
+}
+
+void vduse_domain_reset_bounce_map(struct vduse_iova_domain *domain)
+{
+ if (!domain->bounce_map)
+ return;
+
+ spin_lock(&domain->iotlb_lock);
+ if (!domain->bounce_map)
+ goto unlock;
+
+ vduse_iotlb_del_range(domain, 0, domain->bounce_size - 1);
+ domain->bounce_map = 0;
+unlock:
+ spin_unlock(&domain->iotlb_lock);
+}
+
+static int vduse_domain_init_bounce_map(struct vduse_iova_domain *domain)
+{
+ int ret = 0;
+
+ if (domain->bounce_map)
+ return 0;
+
+ spin_lock(&domain->iotlb_lock);
+ if (domain->bounce_map)
+ goto unlock;
+
+ ret = vduse_iotlb_add_range(domain, 0, domain->bounce_size - 1,
+ 0, VHOST_MAP_RW, domain->file, 0);
+ if (ret)
+ goto unlock;
+
+ domain->bounce_map = 1;
+unlock:
+ spin_unlock(&domain->iotlb_lock);
+ return ret;
+}
+
+static dma_addr_t
+vduse_domain_alloc_iova(struct iova_domain *iovad,
+ unsigned long size, unsigned long limit)
+{
+ unsigned long shift = iova_shift(iovad);
+ unsigned long iova_len = iova_align(iovad, size) >> shift;
+ unsigned long iova_pfn;
+
+ /*
+ * Freeing non-power-of-two-sized allocations back into the IOVA caches
+ * will come back to bite us badly, so we have to waste a bit of space
+ * rounding up anything cacheable to make sure that can't happen. The
+ * order of the unadjusted size will still match upon freeing.
+ */
+ if (iova_len < (1 << (IOVA_RANGE_CACHE_MAX_SIZE - 1)))
+ iova_len = roundup_pow_of_two(iova_len);
+ iova_pfn = alloc_iova_fast(iovad, iova_len, limit >> shift, true);
+
+ return iova_pfn << shift;
+}
+
+static void vduse_domain_free_iova(struct iova_domain *iovad,
+ dma_addr_t iova, size_t size)
+{
+ unsigned long shift = iova_shift(iovad);
+ unsigned long iova_len = iova_align(iovad, size) >> shift;
+
+ free_iova_fast(iovad, iova >> shift, iova_len);
+}
+
+dma_addr_t vduse_domain_map_page(struct vduse_iova_domain *domain,
+ struct page *page, unsigned long offset,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct iova_domain *iovad = &domain->stream_iovad;
+ unsigned long limit = domain->bounce_size - 1;
+ phys_addr_t pa = page_to_phys(page) + offset;
+ dma_addr_t iova = vduse_domain_alloc_iova(iovad, size, limit);
+
+ if (!iova)
+ return DMA_MAPPING_ERROR;
+
+ if (vduse_domain_init_bounce_map(domain))
+ goto err;
+
+ if (vduse_domain_map_bounce_page(domain, (u64)iova, (u64)size, pa))
+ goto err;
+
+ if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
+ vduse_domain_bounce(domain, iova, size, DMA_TO_DEVICE);
+
+ return iova;
+err:
+ vduse_domain_free_iova(iovad, iova, size);
+ return DMA_MAPPING_ERROR;
+}
+
+void vduse_domain_unmap_page(struct vduse_iova_domain *domain,
+ dma_addr_t dma_addr, size_t size,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ struct iova_domain *iovad = &domain->stream_iovad;
+
+ if (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL)
+ vduse_domain_bounce(domain, dma_addr, size, DMA_FROM_DEVICE);
+
+ vduse_domain_unmap_bounce_page(domain, (u64)dma_addr, (u64)size);
+ vduse_domain_free_iova(iovad, dma_addr, size);
+}
+
+void *vduse_domain_alloc_coherent(struct vduse_iova_domain *domain,
+ size_t size, dma_addr_t *dma_addr,
+ gfp_t flag, unsigned long attrs)
+{
+ struct iova_domain *iovad = &domain->consistent_iovad;
+ unsigned long limit = domain->iova_limit;
+ dma_addr_t iova = vduse_domain_alloc_iova(iovad, size, limit);
+ void *orig = alloc_pages_exact(size, flag);
+
+ if (!iova || !orig)
+ goto err;
+
+ spin_lock(&domain->iotlb_lock);
+ if (vduse_iotlb_add_range(domain, (u64)iova, (u64)iova + size - 1,
+ virt_to_phys(orig), VHOST_MAP_RW,
+ domain->file, (u64)iova)) {
+ spin_unlock(&domain->iotlb_lock);
+ goto err;
+ }
+ spin_unlock(&domain->iotlb_lock);
+
+ *dma_addr = iova;
+
+ return orig;
+err:
+ *dma_addr = DMA_MAPPING_ERROR;
+ if (orig)
+ free_pages_exact(orig, size);
+ if (iova)
+ vduse_domain_free_iova(iovad, iova, size);
+
+ return NULL;
+}
+
+void vduse_domain_free_coherent(struct vduse_iova_domain *domain, size_t size,
+ void *vaddr, dma_addr_t dma_addr,
+ unsigned long attrs)
+{
+ struct iova_domain *iovad = &domain->consistent_iovad;
+ struct vhost_iotlb_map *map;
+ struct vdpa_map_file *map_file;
+ phys_addr_t pa;
+
+ spin_lock(&domain->iotlb_lock);
+ map = vhost_iotlb_itree_first(domain->iotlb, (u64)dma_addr,
+ (u64)dma_addr + size - 1);
+ if (WARN_ON(!map)) {
+ spin_unlock(&domain->iotlb_lock);
+ return;
+ }
+ map_file = (struct vdpa_map_file *)map->opaque;
+ fput(map_file->file);
+ kfree(map_file);
+ pa = map->addr;
+ vhost_iotlb_map_free(domain->iotlb, map);
+ spin_unlock(&domain->iotlb_lock);
+
+ vduse_domain_free_iova(iovad, dma_addr, size);
+ free_pages_exact(phys_to_virt(pa), size);
+}
+
+static vm_fault_t vduse_domain_mmap_fault(struct vm_fault *vmf)
+{
+ struct vduse_iova_domain *domain = vmf->vma->vm_private_data;
+ unsigned long iova = vmf->pgoff << PAGE_SHIFT;
+ struct page *page;
+
+ if (!domain)
+ return VM_FAULT_SIGBUS;
+
+ if (iova < domain->bounce_size)
+ page = vduse_domain_get_bounce_page(domain, iova);
+ else
+ page = vduse_domain_get_coherent_page(domain, iova);
+
+ if (!page)
+ return VM_FAULT_SIGBUS;
+
+ vmf->page = page;
+
+ return 0;
+}
+
+static const struct vm_operations_struct vduse_domain_mmap_ops = {
+ .fault = vduse_domain_mmap_fault,
+};
+
+static int vduse_domain_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ struct vduse_iova_domain *domain = file->private_data;
+
+ vma->vm_flags |= VM_DONTDUMP | VM_DONTEXPAND;
+ vma->vm_private_data = domain;
+ vma->vm_ops = &vduse_domain_mmap_ops;
+
+ return 0;
+}
+
+static int vduse_domain_release(struct inode *inode, struct file *file)
+{
+ struct vduse_iova_domain *domain = file->private_data;
+
+ vduse_domain_reset_bounce_map(domain);
+ vduse_domain_free_bounce_pages(domain);
+ put_iova_domain(&domain->stream_iovad);
+ put_iova_domain(&domain->consistent_iovad);
+ vhost_iotlb_free(domain->iotlb);
+ vfree(domain->bounce_maps);
+ kfree(domain);
+
+ return 0;
+}
+
+static const struct file_operations vduse_domain_fops = {
+ .owner = THIS_MODULE,
+ .mmap = vduse_domain_mmap,
+ .release = vduse_domain_release,
+};
+
+void vduse_domain_destroy(struct vduse_iova_domain *domain)
+{
+ fput(domain->file);
+}
+
+struct vduse_iova_domain *
+vduse_domain_create(unsigned long iova_limit, size_t bounce_size)
+{
+ struct vduse_iova_domain *domain;
+ struct file *file;
+ struct vduse_bounce_map *map;
+ unsigned long pfn, bounce_pfns;
+
+ bounce_pfns = PAGE_ALIGN(bounce_size) >> PAGE_SHIFT;
+ if (iova_limit <= bounce_size)
+ return NULL;
+
+ domain = kzalloc(sizeof(*domain), GFP_KERNEL);
+ if (!domain)
+ return NULL;
+
+ domain->iotlb = vhost_iotlb_alloc(0, 0);
+ if (!domain->iotlb)
+ goto err_iotlb;
+
+ domain->iova_limit = iova_limit;
+ domain->bounce_size = PAGE_ALIGN(bounce_size);
+ domain->bounce_maps = vzalloc(bounce_pfns *
+ sizeof(struct vduse_bounce_map));
+ if (!domain->bounce_maps)
+ goto err_map;
+
+ for (pfn = 0; pfn < bounce_pfns; pfn++) {
+ map = &domain->bounce_maps[pfn];
+ map->orig_phys = INVALID_PHYS_ADDR;
+ }
+ file = anon_inode_getfile("[vduse-domain]", &vduse_domain_fops,
+ domain, O_RDWR);
+ if (IS_ERR(file))
+ goto err_file;
+
+ domain->file = file;
+ spin_lock_init(&domain->iotlb_lock);
+ init_iova_domain(&domain->stream_iovad,
+ PAGE_SIZE, IOVA_START_PFN);
+ init_iova_domain(&domain->consistent_iovad,
+ PAGE_SIZE, bounce_pfns);
+
+ return domain;
+err_file:
+ vfree(domain->bounce_maps);
+err_map:
+ vhost_iotlb_free(domain->iotlb);
+err_iotlb:
+ kfree(domain);
+ return NULL;
+}
+
+int vduse_domain_init(void)
+{
+ return iova_cache_get();
+}
+
+void vduse_domain_exit(void)
+{
+ iova_cache_put();
+}
diff --git a/drivers/vdpa/vdpa_user/iova_domain.h b/drivers/vdpa/vdpa_user/iova_domain.h
new file mode 100644
index 000000000000..31f822afa5f5
--- /dev/null
+++ b/drivers/vdpa/vdpa_user/iova_domain.h
@@ -0,0 +1,70 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * MMU-based IOMMU implementation
+ *
+ * Copyright (C) 2020-2021 Bytedance Inc. and/or its affiliates. All rights reserved.
+ *
+ * Author: Xie Yongji <xieyongji@bytedance.com>
+ *
+ */
+
+#ifndef _VDUSE_IOVA_DOMAIN_H
+#define _VDUSE_IOVA_DOMAIN_H
+
+#include <linux/iova.h>
+#include <linux/dma-mapping.h>
+#include <linux/vhost_iotlb.h>
+
+#define IOVA_START_PFN 1
+
+#define INVALID_PHYS_ADDR (~(phys_addr_t)0)
+
+struct vduse_bounce_map {
+ struct page *bounce_page;
+ u64 orig_phys;
+};
+
+struct vduse_iova_domain {
+ struct iova_domain stream_iovad;
+ struct iova_domain consistent_iovad;
+ struct vduse_bounce_map *bounce_maps;
+ size_t bounce_size;
+ unsigned long iova_limit;
+ int bounce_map;
+ struct vhost_iotlb *iotlb;
+ spinlock_t iotlb_lock;
+ struct file *file;
+};
+
+int vduse_domain_set_map(struct vduse_iova_domain *domain,
+ struct vhost_iotlb *iotlb);
+
+dma_addr_t vduse_domain_map_page(struct vduse_iova_domain *domain,
+ struct page *page, unsigned long offset,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs);
+
+void vduse_domain_unmap_page(struct vduse_iova_domain *domain,
+ dma_addr_t dma_addr, size_t size,
+ enum dma_data_direction dir, unsigned long attrs);
+
+void *vduse_domain_alloc_coherent(struct vduse_iova_domain *domain,
+ size_t size, dma_addr_t *dma_addr,
+ gfp_t flag, unsigned long attrs);
+
+void vduse_domain_free_coherent(struct vduse_iova_domain *domain, size_t size,
+ void *vaddr, dma_addr_t dma_addr,
+ unsigned long attrs);
+
+void vduse_domain_reset_bounce_map(struct vduse_iova_domain *domain);
+
+void vduse_domain_destroy(struct vduse_iova_domain *domain);
+
+struct vduse_iova_domain *vduse_domain_create(unsigned long iova_limit,
+ size_t bounce_size);
+
+int vduse_domain_init(void);
+
+void vduse_domain_exit(void);
+
+#endif /* _VDUSE_IOVA_DOMAIN_H */
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (9 preceding siblings ...)
2021-05-17 9:55 ` [PATCH v7 10/12] vduse: Implement an MMU-based IOMMU driver Xie Yongji
@ 2021-05-17 9:55 ` Xie Yongji
2021-05-20 6:28 ` Al Viro
` (2 more replies)
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
12 siblings, 3 replies; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
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, VDUSE_IOTLB_GET_FD ioctl will be used to get
the file descriptors referring to vDPA device's iova regions. Then
userspace can use mmap() to access those iova regions. Besides,
userspace can use ioctl() to inject interrupt and use the eventfd
mechanism to receive virtqueue kicks.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
drivers/vdpa/Kconfig | 10 +
drivers/vdpa/Makefile | 1 +
drivers/vdpa/vdpa_user/Makefile | 5 +
drivers/vdpa/vdpa_user/vduse_dev.c | 1453 ++++++++++++++++++++
include/uapi/linux/vduse.h | 178 +++
6 files changed, 1648 insertions(+)
create mode 100644 drivers/vdpa/vdpa_user/Makefile
create mode 100644 drivers/vdpa/vdpa_user/vduse_dev.c
create mode 100644 include/uapi/linux/vduse.h
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 599bd4493944..db44cdabed35 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -300,6 +300,7 @@ Code Seq# Include File Comments
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
'|' 00-7F linux/media.h
0x80 00-1F linux/fb.h
+0x81 00-1F linux/vduse.h
0x89 00-06 arch/x86/include/asm/sockios.h
0x89 0B-DF linux/sockios.h
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
index a503c1b2bfd9..6e23bce6433a 100644
--- a/drivers/vdpa/Kconfig
+++ b/drivers/vdpa/Kconfig
@@ -33,6 +33,16 @@ config VDPA_SIM_BLOCK
vDPA block device simulator which terminates IO request in a
memory buffer.
+config VDPA_USER
+ tristate "VDUSE (vDPA Device in Userspace) support"
+ depends on EVENTFD && MMU && HAS_DMA
+ select DMA_OPS
+ select VHOST_IOTLB
+ select IOMMU_IOVA
+ help
+ With VDUSE it is possible to emulate a vDPA Device
+ in a userspace program.
+
config IFCVF
tristate "Intel IFC VF vDPA driver"
depends on PCI_MSI
diff --git a/drivers/vdpa/Makefile b/drivers/vdpa/Makefile
index 67fe7f3d6943..f02ebed33f19 100644
--- a/drivers/vdpa/Makefile
+++ b/drivers/vdpa/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_VDPA) += vdpa.o
obj-$(CONFIG_VDPA_SIM) += vdpa_sim/
+obj-$(CONFIG_VDPA_USER) += vdpa_user/
obj-$(CONFIG_IFCVF) += ifcvf/
obj-$(CONFIG_MLX5_VDPA) += mlx5/
obj-$(CONFIG_VP_VDPA) += virtio_pci/
diff --git a/drivers/vdpa/vdpa_user/Makefile b/drivers/vdpa/vdpa_user/Makefile
new file mode 100644
index 000000000000..260e0b26af99
--- /dev/null
+++ b/drivers/vdpa/vdpa_user/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
+vduse-y := vduse_dev.o iova_domain.o
+
+obj-$(CONFIG_VDPA_USER) += vduse.o
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
new file mode 100644
index 000000000000..9ac4cf100ccd
--- /dev/null
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -0,0 +1,1453 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VDUSE: vDPA Device in Userspace
+ *
+ * Copyright (C) 2020-2021 Bytedance Inc. and/or its affiliates. All rights reserved.
+ *
+ * Author: Xie Yongji <xieyongji@bytedance.com>
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/miscdevice.h>
+#include <linux/cdev.h>
+#include <linux/device.h>
+#include <linux/eventfd.h>
+#include <linux/slab.h>
+#include <linux/wait.h>
+#include <linux/dma-map-ops.h>
+#include <linux/poll.h>
+#include <linux/file.h>
+#include <linux/uio.h>
+#include <linux/vdpa.h>
+#include <linux/nospec.h>
+#include <uapi/linux/vduse.h>
+#include <uapi/linux/vdpa.h>
+#include <uapi/linux/virtio_config.h>
+#include <uapi/linux/virtio_ids.h>
+#include <linux/mod_devicetable.h>
+
+#include "iova_domain.h"
+
+#define DRV_VERSION "1.0"
+#define DRV_AUTHOR "Yongji Xie <xieyongji@bytedance.com>"
+#define DRV_DESC "vDPA Device in Userspace"
+#define DRV_LICENSE "GPL v2"
+
+#define VDUSE_DEV_MAX (1U << MINORBITS)
+
+struct vduse_virtqueue {
+ u16 index;
+ bool ready;
+ spinlock_t kick_lock;
+ spinlock_t irq_lock;
+ struct eventfd_ctx *kickfd;
+ struct vdpa_callback cb;
+ struct work_struct inject;
+};
+
+struct vduse_dev;
+
+struct vduse_vdpa {
+ struct vdpa_device vdpa;
+ struct vduse_dev *dev;
+};
+
+struct vduse_dev {
+ struct vduse_vdpa *vdev;
+ struct device dev;
+ struct cdev cdev;
+ struct vduse_virtqueue *vqs;
+ struct vduse_iova_domain *domain;
+ char *name;
+ struct mutex lock;
+ spinlock_t msg_lock;
+ atomic64_t msg_unique;
+ 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;
+};
+
+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)");
+
+static DEFINE_MUTEX(vduse_lock);
+static LIST_HEAD(vduse_devs);
+static DEFINE_IDA(vduse_ida);
+
+static dev_t vduse_major;
+static struct class *vduse_class;
+static struct workqueue_struct *vduse_irq_wq;
+
+static unsigned int allowed_device_id[] = {
+ VIRTIO_ID_NET, VIRTIO_ID_BLOCK,
+ VIRTIO_ID_SCSI, VIRTIO_ID_FS,
+};
+
+static inline struct vduse_dev *vdpa_to_vduse(struct vdpa_device *vdpa)
+{
+ struct vduse_vdpa *vdev = container_of(vdpa, struct vduse_vdpa, vdpa);
+
+ return vdev->dev;
+}
+
+static inline struct vduse_dev *dev_to_vduse(struct device *dev)
+{
+ struct vdpa_device *vdpa = dev_to_vdpa(dev);
+
+ return vdpa_to_vduse(vdpa);
+}
+
+static struct vduse_dev_msg *vduse_find_msg(struct list_head *head,
+ uint32_t request_id)
+{
+ struct vduse_dev_msg *tmp, *msg = NULL;
+
+ list_for_each_entry(tmp, head, list) {
+ if (tmp->req.request_id == request_id) {
+ msg = tmp;
+ list_del(&tmp->list);
+ break;
+ }
+ }
+
+ return msg;
+}
+
+static struct vduse_dev_msg *vduse_dequeue_msg(struct list_head *head)
+{
+ struct vduse_dev_msg *msg = NULL;
+
+ if (!list_empty(head)) {
+ msg = list_first_entry(head, struct vduse_dev_msg, list);
+ list_del(&msg->list);
+ }
+
+ return msg;
+}
+
+static void vduse_enqueue_msg(struct list_head *head,
+ struct vduse_dev_msg *msg)
+{
+ list_add_tail(&msg->list, head);
+}
+
+static int vduse_dev_msg_sync(struct vduse_dev *dev,
+ struct vduse_dev_msg *msg)
+{
+ init_waitqueue_head(&msg->waitq);
+ spin_lock(&dev->msg_lock);
+ vduse_enqueue_msg(&dev->send_list, msg);
+ wake_up(&dev->waitq);
+ spin_unlock(&dev->msg_lock);
+ wait_event_killable(msg->waitq, msg->completed);
+ spin_lock(&dev->msg_lock);
+ if (!msg->completed) {
+ list_del(&msg->list);
+ msg->resp.result = VDUSE_REQUEST_FAILED;
+ }
+ spin_unlock(&dev->msg_lock);
+
+ return (msg->resp.result == VDUSE_REQUEST_OK) ? 0 : -1;
+}
+
+static u32 vduse_dev_get_request_id(struct vduse_dev *dev)
+{
+ return atomic64_fetch_inc(&dev->msg_unique);
+}
+
+static u64 vduse_dev_get_features(struct vduse_dev *dev)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ msg.req.type = VDUSE_GET_FEATURES;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+
+ if (WARN_ON(vduse_dev_msg_sync(dev, &msg) != 0))
+ return 0;
+
+ return msg.resp.f.features;
+}
+
+static int vduse_dev_set_features(struct vduse_dev *dev, u64 features)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ msg.req.type = VDUSE_SET_FEATURES;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.f.features = features;
+
+ return vduse_dev_msg_sync(dev, &msg);
+}
+
+static u8 vduse_dev_get_status(struct vduse_dev *dev)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ msg.req.type = VDUSE_GET_STATUS;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+
+ if (WARN_ON(vduse_dev_msg_sync(dev, &msg) != 0))
+ return 0;
+
+ return msg.resp.s.status;
+}
+
+static void vduse_dev_set_status(struct vduse_dev *dev, u8 status)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ msg.req.type = VDUSE_SET_STATUS;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.s.status = status;
+
+ WARN_ON(vduse_dev_msg_sync(dev, &msg) != 0);
+}
+
+static void vduse_dev_get_config(struct vduse_dev *dev, unsigned int offset,
+ void *buf, unsigned int len)
+{
+ struct vduse_dev_msg msg = { 0 };
+ unsigned int sz;
+
+ while (len) {
+ sz = min_t(unsigned int, len, sizeof(msg.req.config.data));
+ msg.req.type = VDUSE_GET_CONFIG;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.config.offset = offset;
+ msg.req.config.len = sz;
+ if (WARN_ON(vduse_dev_msg_sync(dev, &msg) != 0))
+ break;
+
+ memcpy(buf, msg.resp.config.data, sz);
+ buf += sz;
+ offset += sz;
+ len -= sz;
+ }
+}
+
+static void vduse_dev_set_config(struct vduse_dev *dev, unsigned int offset,
+ const void *buf, unsigned int len)
+{
+ struct vduse_dev_msg msg = { 0 };
+ unsigned int sz;
+
+ while (len) {
+ sz = min_t(unsigned int, len, sizeof(msg.req.config.data));
+ msg.req.type = VDUSE_SET_CONFIG;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.config.offset = offset;
+ msg.req.config.len = sz;
+ memcpy(msg.req.config.data, buf, sz);
+ if (WARN_ON(vduse_dev_msg_sync(dev, &msg) != 0))
+ break;
+
+ buf += sz;
+ offset += sz;
+ len -= sz;
+ }
+}
+
+static void vduse_dev_set_vq_num(struct vduse_dev *dev,
+ struct vduse_virtqueue *vq, u32 num)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ msg.req.type = VDUSE_SET_VQ_NUM;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.vq_num.index = vq->index;
+ msg.req.vq_num.num = num;
+
+ WARN_ON(vduse_dev_msg_sync(dev, &msg) != 0);
+}
+
+static int vduse_dev_set_vq_addr(struct vduse_dev *dev,
+ struct vduse_virtqueue *vq, u64 desc_addr,
+ u64 driver_addr, u64 device_addr)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ msg.req.type = VDUSE_SET_VQ_ADDR;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.vq_addr.index = vq->index;
+ msg.req.vq_addr.desc_addr = desc_addr;
+ msg.req.vq_addr.driver_addr = driver_addr;
+ msg.req.vq_addr.device_addr = device_addr;
+
+ return vduse_dev_msg_sync(dev, &msg);
+}
+
+static void vduse_dev_set_vq_ready(struct vduse_dev *dev,
+ struct vduse_virtqueue *vq, bool ready)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ msg.req.type = VDUSE_SET_VQ_READY;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.vq_ready.index = vq->index;
+ msg.req.vq_ready.ready = ready;
+
+ WARN_ON(vduse_dev_msg_sync(dev, &msg) != 0);
+}
+
+static bool vduse_dev_get_vq_ready(struct vduse_dev *dev,
+ struct vduse_virtqueue *vq)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ msg.req.type = VDUSE_GET_VQ_READY;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.vq_ready.index = vq->index;
+ if (WARN_ON(vduse_dev_msg_sync(dev, &msg)))
+ return false;
+
+ return msg.resp.vq_ready.ready;
+}
+
+static int vduse_dev_get_vq_state(struct vduse_dev *dev,
+ struct vduse_virtqueue *vq,
+ struct vdpa_vq_state *state)
+{
+ struct vduse_dev_msg msg = { 0 };
+ int ret;
+
+ msg.req.type = VDUSE_GET_VQ_STATE;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.vq_state.index = vq->index;
+
+ ret = vduse_dev_msg_sync(dev, &msg);
+ if (!ret)
+ state->avail_index = msg.resp.vq_state.avail_idx;
+
+ return ret;
+}
+
+static int vduse_dev_set_vq_state(struct vduse_dev *dev,
+ struct vduse_virtqueue *vq,
+ const struct vdpa_vq_state *state)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ msg.req.type = VDUSE_SET_VQ_STATE;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.vq_state.index = vq->index;
+ msg.req.vq_state.avail_idx = state->avail_index;
+
+ return vduse_dev_msg_sync(dev, &msg);
+}
+
+static int vduse_dev_update_iotlb(struct vduse_dev *dev,
+ u64 start, u64 last)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ if (last < start)
+ return -EINVAL;
+
+ msg.req.type = VDUSE_UPDATE_IOTLB;
+ msg.req.request_id = vduse_dev_get_request_id(dev);
+ msg.req.iova.start = start;
+ msg.req.iova.last = last;
+
+ return vduse_dev_msg_sync(dev, &msg);
+}
+
+static ssize_t vduse_dev_read_iter(struct kiocb *iocb, struct iov_iter *to)
+{
+ struct file *file = iocb->ki_filp;
+ struct vduse_dev *dev = file->private_data;
+ struct vduse_dev_msg *msg;
+ int size = sizeof(struct vduse_dev_request);
+ ssize_t ret;
+
+ if (iov_iter_count(to) < size)
+ return -EINVAL;
+
+ spin_lock(&dev->msg_lock);
+ while (1) {
+ msg = vduse_dequeue_msg(&dev->send_list);
+ if (msg)
+ break;
+
+ ret = -EAGAIN;
+ if (file->f_flags & O_NONBLOCK)
+ goto unlock;
+
+ spin_unlock(&dev->msg_lock);
+ ret = wait_event_interruptible_exclusive(dev->waitq,
+ !list_empty(&dev->send_list));
+ if (ret)
+ return ret;
+
+ spin_lock(&dev->msg_lock);
+ }
+ spin_unlock(&dev->msg_lock);
+ ret = copy_to_iter(&msg->req, size, to);
+ spin_lock(&dev->msg_lock);
+ if (ret != size) {
+ ret = -EFAULT;
+ vduse_enqueue_msg(&dev->send_list, msg);
+ goto unlock;
+ }
+ vduse_enqueue_msg(&dev->recv_list, msg);
+unlock:
+ spin_unlock(&dev->msg_lock);
+
+ return ret;
+}
+
+static ssize_t vduse_dev_write_iter(struct kiocb *iocb, struct iov_iter *from)
+{
+ struct file *file = iocb->ki_filp;
+ struct vduse_dev *dev = file->private_data;
+ struct vduse_dev_response resp;
+ struct vduse_dev_msg *msg;
+ size_t ret;
+
+ ret = copy_from_iter(&resp, sizeof(resp), from);
+ if (ret != sizeof(resp))
+ return -EINVAL;
+
+ spin_lock(&dev->msg_lock);
+ msg = vduse_find_msg(&dev->recv_list, resp.request_id);
+ if (!msg) {
+ ret = -ENOENT;
+ goto unlock;
+ }
+
+ memcpy(&msg->resp, &resp, sizeof(resp));
+ msg->completed = 1;
+ wake_up(&msg->waitq);
+unlock:
+ spin_unlock(&dev->msg_lock);
+
+ return ret;
+}
+
+static __poll_t vduse_dev_poll(struct file *file, poll_table *wait)
+{
+ struct vduse_dev *dev = file->private_data;
+ __poll_t mask = 0;
+
+ poll_wait(file, &dev->waitq, wait);
+
+ if (!list_empty(&dev->send_list))
+ mask |= EPOLLIN | EPOLLRDNORM;
+ if (!list_empty(&dev->recv_list))
+ mask |= EPOLLOUT | EPOLLWRNORM;
+
+ return mask;
+}
+
+static void vduse_dev_reset(struct vduse_dev *dev)
+{
+ int i;
+ struct vduse_iova_domain *domain = dev->domain;
+
+ /* The coherent mappings are handled in vduse_dev_free_coherent() */
+ if (domain->bounce_map) {
+ vduse_domain_reset_bounce_map(domain);
+ vduse_dev_update_iotlb(dev, 0ULL, domain->bounce_size - 1);
+ }
+
+ spin_lock(&dev->irq_lock);
+ dev->config_cb.callback = NULL;
+ dev->config_cb.private = NULL;
+ spin_unlock(&dev->irq_lock);
+
+ for (i = 0; i < dev->vq_num; i++) {
+ struct vduse_virtqueue *vq = &dev->vqs[i];
+
+ spin_lock(&vq->irq_lock);
+ vq->ready = false;
+ vq->cb.callback = NULL;
+ vq->cb.private = NULL;
+ spin_unlock(&vq->irq_lock);
+ }
+}
+
+static int vduse_vdpa_set_vq_address(struct vdpa_device *vdpa, u16 idx,
+ u64 desc_area, u64 driver_area,
+ u64 device_area)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ return vduse_dev_set_vq_addr(dev, vq, desc_area,
+ driver_area, device_area);
+}
+
+static void vduse_vdpa_kick_vq(struct vdpa_device *vdpa, u16 idx)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ spin_lock(&vq->kick_lock);
+ if (vq->ready && vq->kickfd)
+ eventfd_signal(vq->kickfd, 1);
+ spin_unlock(&vq->kick_lock);
+}
+
+static void vduse_vdpa_set_vq_cb(struct vdpa_device *vdpa, u16 idx,
+ struct vdpa_callback *cb)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ spin_lock(&vq->irq_lock);
+ vq->cb.callback = cb->callback;
+ vq->cb.private = cb->private;
+ spin_unlock(&vq->irq_lock);
+}
+
+static void vduse_vdpa_set_vq_num(struct vdpa_device *vdpa, u16 idx, u32 num)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ vduse_dev_set_vq_num(dev, vq, num);
+}
+
+static void vduse_vdpa_set_vq_ready(struct vdpa_device *vdpa,
+ u16 idx, bool ready)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ vduse_dev_set_vq_ready(dev, vq, ready);
+ vq->ready = ready;
+}
+
+static bool vduse_vdpa_get_vq_ready(struct vdpa_device *vdpa, u16 idx)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ vq->ready = vduse_dev_get_vq_ready(dev, vq);
+
+ return vq->ready;
+}
+
+static int vduse_vdpa_set_vq_state(struct vdpa_device *vdpa, u16 idx,
+ const struct vdpa_vq_state *state)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ return vduse_dev_set_vq_state(dev, vq, state);
+}
+
+static int vduse_vdpa_get_vq_state(struct vdpa_device *vdpa, u16 idx,
+ struct vdpa_vq_state *state)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ return vduse_dev_get_vq_state(dev, vq, state);
+}
+
+static u32 vduse_vdpa_get_vq_align(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->vq_align;
+}
+
+static u64 vduse_vdpa_get_features(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return vduse_dev_get_features(dev);
+}
+
+static int vduse_vdpa_set_features(struct vdpa_device *vdpa, u64 features)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
+ return -EINVAL;
+
+ return vduse_dev_set_features(dev, features);
+}
+
+static void vduse_vdpa_set_config_cb(struct vdpa_device *vdpa,
+ struct vdpa_callback *cb)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ spin_lock(&dev->irq_lock);
+ dev->config_cb.callback = cb->callback;
+ dev->config_cb.private = cb->private;
+ spin_unlock(&dev->irq_lock);
+}
+
+static u16 vduse_vdpa_get_vq_num_max(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->vq_size_max;
+}
+
+static u32 vduse_vdpa_get_device_id(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->device_id;
+}
+
+static u32 vduse_vdpa_get_vendor_id(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->vendor_id;
+}
+
+static u8 vduse_vdpa_get_status(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return vduse_dev_get_status(dev);
+}
+
+static void vduse_vdpa_set_status(struct vdpa_device *vdpa, u8 status)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ vduse_dev_set_status(dev, status);
+
+ if (status == 0)
+ vduse_dev_reset(dev);
+}
+
+static size_t vduse_vdpa_get_config_size(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->config_size;
+}
+
+static void vduse_vdpa_get_config(struct vdpa_device *vdpa, unsigned int offset,
+ void *buf, unsigned int len)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ vduse_dev_get_config(dev, offset, buf, len);
+}
+
+static void vduse_vdpa_set_config(struct vdpa_device *vdpa, unsigned int offset,
+ const void *buf, unsigned int len)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ vduse_dev_set_config(dev, offset, buf, len);
+}
+
+static int vduse_vdpa_set_map(struct vdpa_device *vdpa,
+ struct vhost_iotlb *iotlb)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ int ret;
+
+ ret = vduse_domain_set_map(dev->domain, iotlb);
+ vduse_dev_update_iotlb(dev, 0ULL, ULLONG_MAX);
+
+ return ret;
+}
+
+static void vduse_vdpa_free(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ WARN_ON(!list_empty(&dev->send_list));
+ WARN_ON(!list_empty(&dev->recv_list));
+ dev->vdev = NULL;
+}
+
+static const struct vdpa_config_ops vduse_vdpa_config_ops = {
+ .set_vq_address = vduse_vdpa_set_vq_address,
+ .kick_vq = vduse_vdpa_kick_vq,
+ .set_vq_cb = vduse_vdpa_set_vq_cb,
+ .set_vq_num = vduse_vdpa_set_vq_num,
+ .set_vq_ready = vduse_vdpa_set_vq_ready,
+ .get_vq_ready = vduse_vdpa_get_vq_ready,
+ .set_vq_state = vduse_vdpa_set_vq_state,
+ .get_vq_state = vduse_vdpa_get_vq_state,
+ .get_vq_align = vduse_vdpa_get_vq_align,
+ .get_features = vduse_vdpa_get_features,
+ .set_features = vduse_vdpa_set_features,
+ .set_config_cb = vduse_vdpa_set_config_cb,
+ .get_vq_num_max = vduse_vdpa_get_vq_num_max,
+ .get_device_id = vduse_vdpa_get_device_id,
+ .get_vendor_id = vduse_vdpa_get_vendor_id,
+ .get_status = vduse_vdpa_get_status,
+ .set_status = vduse_vdpa_set_status,
+ .get_config_size = vduse_vdpa_get_config_size,
+ .get_config = vduse_vdpa_get_config,
+ .set_config = vduse_vdpa_set_config,
+ .set_map = vduse_vdpa_set_map,
+ .free = vduse_vdpa_free,
+};
+
+static dma_addr_t vduse_dev_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct vduse_dev *vdev = dev_to_vduse(dev);
+ struct vduse_iova_domain *domain = vdev->domain;
+
+ return vduse_domain_map_page(domain, page, offset, size, dir, attrs);
+}
+
+static void vduse_dev_unmap_page(struct device *dev, dma_addr_t dma_addr,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct vduse_dev *vdev = dev_to_vduse(dev);
+ struct vduse_iova_domain *domain = vdev->domain;
+
+ return vduse_domain_unmap_page(domain, dma_addr, size, dir, attrs);
+}
+
+static void *vduse_dev_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_addr, gfp_t flag,
+ unsigned long attrs)
+{
+ struct vduse_dev *vdev = dev_to_vduse(dev);
+ struct vduse_iova_domain *domain = vdev->domain;
+ unsigned long iova;
+ void *addr;
+
+ *dma_addr = DMA_MAPPING_ERROR;
+ addr = vduse_domain_alloc_coherent(domain, size,
+ (dma_addr_t *)&iova, flag, attrs);
+ if (!addr)
+ return NULL;
+
+ *dma_addr = (dma_addr_t)iova;
+ vduse_dev_update_iotlb(vdev, iova, iova + size - 1);
+
+ return addr;
+}
+
+static void vduse_dev_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_addr,
+ unsigned long attrs)
+{
+ struct vduse_dev *vdev = dev_to_vduse(dev);
+ struct vduse_iova_domain *domain = vdev->domain;
+ unsigned long start = (unsigned long)dma_addr;
+ unsigned long last = start + size - 1;
+
+ vduse_domain_free_coherent(domain, size, vaddr, dma_addr, attrs);
+ vduse_dev_update_iotlb(vdev, start, last);
+}
+
+static size_t vduse_dev_max_mapping_size(struct device *dev)
+{
+ struct vduse_dev *vdev = dev_to_vduse(dev);
+ struct vduse_iova_domain *domain = vdev->domain;
+
+ return domain->bounce_size;
+}
+
+static const struct dma_map_ops vduse_dev_dma_ops = {
+ .map_page = vduse_dev_map_page,
+ .unmap_page = vduse_dev_unmap_page,
+ .alloc = vduse_dev_alloc_coherent,
+ .free = vduse_dev_free_coherent,
+ .max_mapping_size = vduse_dev_max_mapping_size,
+};
+
+static unsigned int perm_to_file_flags(u8 perm)
+{
+ unsigned int flags = 0;
+
+ switch (perm) {
+ case VDUSE_ACCESS_WO:
+ flags |= O_WRONLY;
+ break;
+ case VDUSE_ACCESS_RO:
+ flags |= O_RDONLY;
+ break;
+ case VDUSE_ACCESS_RW:
+ flags |= O_RDWR;
+ break;
+ default:
+ WARN(1, "invalidate vhost IOTLB permission\n");
+ break;
+ }
+
+ return flags;
+}
+
+static int vduse_kickfd_setup(struct vduse_dev *dev,
+ struct vduse_vq_eventfd *eventfd)
+{
+ struct eventfd_ctx *ctx = NULL;
+ struct vduse_virtqueue *vq;
+ u32 index;
+
+ if (eventfd->index >= dev->vq_num)
+ return -EINVAL;
+
+ index = array_index_nospec(eventfd->index, dev->vq_num);
+ vq = &dev->vqs[index];
+ if (eventfd->fd >= 0) {
+ ctx = eventfd_ctx_fdget(eventfd->fd);
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
+ } else if (eventfd->fd != VDUSE_EVENTFD_DEASSIGN)
+ return 0;
+
+ spin_lock(&vq->kick_lock);
+ if (vq->kickfd)
+ eventfd_ctx_put(vq->kickfd);
+ vq->kickfd = ctx;
+ spin_unlock(&vq->kick_lock);
+
+ return 0;
+}
+
+static void vduse_dev_irq_inject(struct work_struct *work)
+{
+ struct vduse_dev *dev = container_of(work, struct vduse_dev, inject);
+
+ spin_lock_irq(&dev->irq_lock);
+ if (dev->config_cb.callback)
+ dev->config_cb.callback(dev->config_cb.private);
+ spin_unlock_irq(&dev->irq_lock);
+}
+
+static void vduse_vq_irq_inject(struct work_struct *work)
+{
+ struct vduse_virtqueue *vq = container_of(work,
+ struct vduse_virtqueue, inject);
+
+ spin_lock_irq(&vq->irq_lock);
+ if (vq->ready && vq->cb.callback)
+ vq->cb.callback(vq->cb.private);
+ spin_unlock_irq(&vq->irq_lock);
+}
+
+static long vduse_dev_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ struct vduse_dev *dev = file->private_data;
+ void __user *argp = (void __user *)arg;
+ int ret;
+
+ switch (cmd) {
+ case VDUSE_IOTLB_GET_FD: {
+ struct vduse_iotlb_entry entry;
+ struct vhost_iotlb_map *map;
+ struct vdpa_map_file *map_file;
+ struct vduse_iova_domain *domain = dev->domain;
+ struct file *f = NULL;
+
+ ret = -EFAULT;
+ if (copy_from_user(&entry, argp, sizeof(entry)))
+ break;
+
+ ret = -EINVAL;
+ if (entry.start > entry.last)
+ break;
+
+ spin_lock(&domain->iotlb_lock);
+ map = vhost_iotlb_itree_first(domain->iotlb,
+ entry.start, entry.last);
+ if (map) {
+ map_file = (struct vdpa_map_file *)map->opaque;
+ f = get_file(map_file->file);
+ entry.offset = map_file->offset;
+ entry.start = map->start;
+ entry.last = map->last;
+ entry.perm = map->perm;
+ }
+ spin_unlock(&domain->iotlb_lock);
+ ret = -EINVAL;
+ if (!f)
+ break;
+
+ ret = -EFAULT;
+ if (copy_to_user(argp, &entry, sizeof(entry))) {
+ fput(f);
+ break;
+ }
+ ret = receive_fd(f, perm_to_file_flags(entry.perm));
+ fput(f);
+ break;
+ }
+ case VDUSE_VQ_SETUP_KICKFD: {
+ struct vduse_vq_eventfd eventfd;
+
+ ret = -EFAULT;
+ if (copy_from_user(&eventfd, argp, sizeof(eventfd)))
+ break;
+
+ ret = vduse_kickfd_setup(dev, &eventfd);
+ break;
+ }
+ case VDUSE_INJECT_VQ_IRQ: {
+ u32 vq_index;
+
+ ret = -EFAULT;
+ if (copy_from_user(&vq_index, argp, sizeof(u32)))
+ break;
+
+ ret = -EINVAL;
+ if (vq_index >= dev->vq_num)
+ break;
+
+ ret = 0;
+ vq_index = array_index_nospec(vq_index, dev->vq_num);
+ queue_work(vduse_irq_wq, &dev->vqs[vq_index].inject);
+ break;
+ }
+ case VDUSE_INJECT_CONFIG_IRQ:
+ ret = 0;
+ queue_work(vduse_irq_wq, &dev->inject);
+ break;
+ default:
+ ret = -ENOIOCTLCMD;
+ break;
+ }
+
+ return ret;
+}
+
+static int vduse_dev_release(struct inode *inode, struct file *file)
+{
+ struct vduse_dev *dev = file->private_data;
+ struct vduse_dev_msg *msg;
+ int i;
+
+ for (i = 0; i < dev->vq_num; i++) {
+ struct vduse_virtqueue *vq = &dev->vqs[i];
+
+ spin_lock(&vq->kick_lock);
+ if (vq->kickfd)
+ eventfd_ctx_put(vq->kickfd);
+ vq->kickfd = NULL;
+ spin_unlock(&vq->kick_lock);
+ }
+
+ spin_lock(&dev->msg_lock);
+ /* Make sure the inflight messages can processed after reconncection */
+ while ((msg = vduse_dequeue_msg(&dev->recv_list)))
+ vduse_enqueue_msg(&dev->send_list, msg);
+ spin_unlock(&dev->msg_lock);
+
+ dev->connected = false;
+
+ return 0;
+}
+
+static int vduse_dev_open(struct inode *inode, struct file *file)
+{
+ struct vduse_dev *dev = container_of(inode->i_cdev,
+ struct vduse_dev, cdev);
+ int ret = -EBUSY;
+
+ mutex_lock(&dev->lock);
+ if (dev->connected)
+ goto unlock;
+
+ ret = 0;
+ dev->connected = true;
+ file->private_data = dev;
+unlock:
+ mutex_unlock(&dev->lock);
+
+ return ret;
+}
+
+static const struct file_operations vduse_dev_fops = {
+ .owner = THIS_MODULE,
+ .open = vduse_dev_open,
+ .release = vduse_dev_release,
+ .read_iter = vduse_dev_read_iter,
+ .write_iter = vduse_dev_write_iter,
+ .poll = vduse_dev_poll,
+ .unlocked_ioctl = vduse_dev_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
+ .llseek = noop_llseek,
+};
+
+static struct vduse_dev *vduse_dev_create(void)
+{
+ struct vduse_dev *dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+
+ if (!dev)
+ return NULL;
+
+ mutex_init(&dev->lock);
+ spin_lock_init(&dev->msg_lock);
+ INIT_LIST_HEAD(&dev->send_list);
+ INIT_LIST_HEAD(&dev->recv_list);
+ atomic64_set(&dev->msg_unique, 0);
+ spin_lock_init(&dev->irq_lock);
+
+ INIT_WORK(&dev->inject, vduse_dev_irq_inject);
+ init_waitqueue_head(&dev->waitq);
+
+ return dev;
+}
+
+static void vduse_dev_destroy(struct vduse_dev *dev)
+{
+ kfree(dev);
+}
+
+static struct vduse_dev *vduse_find_dev(const char *name)
+{
+ struct vduse_dev *tmp, *dev = NULL;
+
+ list_for_each_entry(tmp, &vduse_devs, list) {
+ if (!strcmp(tmp->name, name)) {
+ dev = tmp;
+ break;
+ }
+ }
+ return dev;
+}
+
+static int vduse_destroy_dev(char *name)
+{
+ struct vduse_dev *dev = vduse_find_dev(name);
+
+ if (!dev)
+ return -EINVAL;
+
+ mutex_lock(&dev->lock);
+ if (dev->vdev || dev->connected) {
+ mutex_unlock(&dev->lock);
+ return -EBUSY;
+ }
+ dev->connected = true;
+ mutex_unlock(&dev->lock);
+
+ list_del(&dev->list);
+ cdev_device_del(&dev->cdev, &dev->dev);
+ put_device(&dev->dev);
+ module_put(THIS_MODULE);
+
+ return 0;
+}
+
+static void vduse_release_dev(struct device *device)
+{
+ struct vduse_dev *dev =
+ container_of(device, struct vduse_dev, dev);
+
+ ida_simple_remove(&vduse_ida, dev->minor);
+ kfree(dev->vqs);
+ vduse_domain_destroy(dev->domain);
+ kfree(dev->name);
+ vduse_dev_destroy(dev);
+}
+
+static bool device_is_allowed(unsigned int device_id)
+{
+ int i;
+
+ if (allow_unsafe_device_emulation)
+ return true;
+
+ for (i = 0; i < ARRAY_SIZE(allowed_device_id); i++) {
+ if (allowed_device_id[i] == device_id)
+ return true;
+ }
+ return false;
+}
+
+static int vduse_create_dev(struct vduse_dev_config *config,
+ unsigned long api_version)
+{
+ int i, ret = -ENOMEM;
+ struct vduse_dev *dev;
+
+ if (config->bounce_size > max_bounce_size)
+ return -EINVAL;
+
+ if (config->vq_align > PAGE_SIZE)
+ return -EINVAL;
+
+ if (!device_is_allowed(config->device_id))
+ return -EINVAL;
+
+ if (vduse_find_dev(config->name))
+ return -EEXIST;
+
+ dev = vduse_dev_create();
+ if (!dev)
+ return -ENOMEM;
+
+ dev->api_version = api_version;
+ dev->device_id = config->device_id;
+ dev->vendor_id = config->vendor_id;
+ dev->name = kstrdup(config->name, GFP_KERNEL);
+ if (!dev->name)
+ goto err_str;
+
+ dev->domain = vduse_domain_create(max_iova_size - 1,
+ config->bounce_size);
+ if (!dev->domain)
+ goto err_domain;
+
+ dev->config_size = config->config_size;
+ dev->vq_align = config->vq_align;
+ dev->vq_size_max = config->vq_size_max;
+ dev->vq_num = config->vq_num;
+ dev->vqs = kcalloc(dev->vq_num, sizeof(*dev->vqs), GFP_KERNEL);
+ if (!dev->vqs)
+ goto err_vqs;
+
+ for (i = 0; i < dev->vq_num; i++) {
+ dev->vqs[i].index = i;
+ INIT_WORK(&dev->vqs[i].inject, vduse_vq_irq_inject);
+ spin_lock_init(&dev->vqs[i].kick_lock);
+ spin_lock_init(&dev->vqs[i].irq_lock);
+ }
+
+ ret = ida_simple_get(&vduse_ida, 0, VDUSE_DEV_MAX, GFP_KERNEL);
+ if (ret < 0)
+ goto err_ida;
+
+ dev->minor = ret;
+ device_initialize(&dev->dev);
+ dev->dev.release = vduse_release_dev;
+ dev->dev.class = vduse_class;
+ dev->dev.devt = MKDEV(MAJOR(vduse_major), dev->minor);
+ ret = dev_set_name(&dev->dev, "%s", config->name);
+ if (ret)
+ goto err;
+
+ cdev_init(&dev->cdev, &vduse_dev_fops);
+ dev->cdev.owner = THIS_MODULE;
+
+ ret = cdev_device_add(&dev->cdev, &dev->dev);
+ if (ret)
+ goto err;
+
+ list_add(&dev->list, &vduse_devs);
+ __module_get(THIS_MODULE);
+
+ return 0;
+err_ida:
+ kfree(dev->vqs);
+err_vqs:
+ vduse_domain_destroy(dev->domain);
+err_domain:
+ kfree(dev->name);
+err_str:
+ vduse_dev_destroy(dev);
+ return ret;
+err:
+ put_device(&dev->dev);
+ return ret;
+}
+
+static long vduse_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ int ret;
+ void __user *argp = (void __user *)arg;
+ struct vduse_control *control = file->private_data;
+
+ mutex_lock(&vduse_lock);
+ switch (cmd) {
+ case VDUSE_GET_API_VERSION:
+ ret = control->api_version;
+ break;
+ case VDUSE_SET_API_VERSION:
+ ret = -EINVAL;
+ if (arg > VDUSE_API_VERSION)
+ break;
+
+ ret = 0;
+ control->api_version = arg;
+ break;
+ case VDUSE_CREATE_DEV: {
+ struct vduse_dev_config config;
+
+ ret = -EFAULT;
+ if (copy_from_user(&config, argp, sizeof(config)))
+ break;
+
+ ret = vduse_create_dev(&config, control->api_version);
+ break;
+ }
+ case VDUSE_DESTROY_DEV: {
+ char name[VDUSE_NAME_MAX];
+
+ ret = -EFAULT;
+ if (copy_from_user(name, argp, VDUSE_NAME_MAX))
+ break;
+
+ ret = vduse_destroy_dev(name);
+ break;
+ }
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ mutex_unlock(&vduse_lock);
+
+ return ret;
+}
+
+static int vduse_release(struct inode *inode, struct file *file)
+{
+ struct vduse_control *control = file->private_data;
+
+ kfree(control);
+ return 0;
+}
+
+static int vduse_open(struct inode *inode, struct file *file)
+{
+ struct vduse_control *control;
+
+ control = kmalloc(sizeof(struct vduse_control), GFP_KERNEL);
+ if (!control)
+ return -ENOMEM;
+
+ control->api_version = VDUSE_API_VERSION;
+ file->private_data = control;
+
+ return 0;
+}
+
+static const struct file_operations vduse_fops = {
+ .owner = THIS_MODULE,
+ .open = vduse_open,
+ .release = vduse_release,
+ .unlocked_ioctl = vduse_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
+ .llseek = noop_llseek,
+};
+
+static char *vduse_devnode(struct device *dev, umode_t *mode)
+{
+ return kasprintf(GFP_KERNEL, "vduse/%s", dev_name(dev));
+}
+
+static struct miscdevice vduse_misc = {
+ .fops = &vduse_fops,
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = "vduse",
+ .nodename = "vduse/control",
+};
+
+static void vduse_mgmtdev_release(struct device *dev)
+{
+}
+
+static struct device vduse_mgmtdev = {
+ .init_name = "vduse",
+ .release = vduse_mgmtdev_release,
+};
+
+static struct vdpa_mgmt_dev mgmt_dev;
+
+static int vduse_dev_init_vdpa(struct vduse_dev *dev, const char *name)
+{
+ struct vduse_vdpa *vdev;
+ int ret;
+
+ if (dev->vdev)
+ return -EEXIST;
+
+ vdev = vdpa_alloc_device(struct vduse_vdpa, vdpa, &dev->dev,
+ &vduse_vdpa_config_ops, name, true);
+ if (!vdev)
+ return -ENOMEM;
+
+ dev->vdev = vdev;
+ vdev->dev = dev;
+ vdev->vdpa.dev.dma_mask = &vdev->vdpa.dev.coherent_dma_mask;
+ ret = dma_set_mask_and_coherent(&vdev->vdpa.dev, DMA_BIT_MASK(64));
+ if (ret) {
+ put_device(&vdev->vdpa.dev);
+ return ret;
+ }
+ set_dma_ops(&vdev->vdpa.dev, &vduse_dev_dma_ops);
+ vdev->vdpa.dma_dev = &vdev->vdpa.dev;
+ vdev->vdpa.mdev = &mgmt_dev;
+
+ return 0;
+}
+
+static int vdpa_dev_add(struct vdpa_mgmt_dev *mdev, const char *name)
+{
+ struct vduse_dev *dev;
+ int ret;
+
+ mutex_lock(&vduse_lock);
+ dev = vduse_find_dev(name);
+ if (!dev) {
+ mutex_unlock(&vduse_lock);
+ return -EINVAL;
+ }
+ ret = vduse_dev_init_vdpa(dev, name);
+ mutex_unlock(&vduse_lock);
+ if (ret)
+ return ret;
+
+ ret = _vdpa_register_device(&dev->vdev->vdpa, dev->vq_num);
+ if (ret) {
+ put_device(&dev->vdev->vdpa.dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void vdpa_dev_del(struct vdpa_mgmt_dev *mdev, struct vdpa_device *dev)
+{
+ _vdpa_unregister_device(dev);
+}
+
+static const struct vdpa_mgmtdev_ops vdpa_dev_mgmtdev_ops = {
+ .dev_add = vdpa_dev_add,
+ .dev_del = vdpa_dev_del,
+};
+
+static struct virtio_device_id id_table[] = {
+ { VIRTIO_DEV_ANY_ID, VIRTIO_DEV_ANY_ID },
+ { 0 },
+};
+
+static struct vdpa_mgmt_dev mgmt_dev = {
+ .device = &vduse_mgmtdev,
+ .id_table = id_table,
+ .ops = &vdpa_dev_mgmtdev_ops,
+};
+
+static int vduse_mgmtdev_init(void)
+{
+ int ret;
+
+ ret = device_register(&vduse_mgmtdev);
+ if (ret)
+ return ret;
+
+ ret = vdpa_mgmtdev_register(&mgmt_dev);
+ if (ret)
+ goto err;
+
+ return 0;
+err:
+ device_unregister(&vduse_mgmtdev);
+ return ret;
+}
+
+static void vduse_mgmtdev_exit(void)
+{
+ vdpa_mgmtdev_unregister(&mgmt_dev);
+ device_unregister(&vduse_mgmtdev);
+}
+
+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 (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");
+ if (ret)
+ goto err_chardev;
+
+ vduse_irq_wq = alloc_workqueue("vduse-irq",
+ WQ_HIGHPRI | WQ_SYSFS | WQ_UNBOUND, 0);
+ if (!vduse_irq_wq)
+ goto err_wq;
+
+ ret = vduse_domain_init();
+ if (ret)
+ goto err_domain;
+
+ ret = vduse_mgmtdev_init();
+ if (ret)
+ goto err_mgmtdev;
+
+ return 0;
+err_mgmtdev:
+ vduse_domain_exit();
+err_domain:
+ destroy_workqueue(vduse_irq_wq);
+err_wq:
+ unregister_chrdev_region(vduse_major, VDUSE_DEV_MAX);
+err_chardev:
+ class_destroy(vduse_class);
+err_class:
+ misc_deregister(&vduse_misc);
+ return ret;
+}
+module_init(vduse_init);
+
+static void vduse_exit(void)
+{
+ misc_deregister(&vduse_misc);
+ class_destroy(vduse_class);
+ unregister_chrdev_region(vduse_major, VDUSE_DEV_MAX);
+ destroy_workqueue(vduse_irq_wq);
+ vduse_domain_exit();
+ vduse_mgmtdev_exit();
+}
+module_exit(vduse_exit);
+
+MODULE_VERSION(DRV_VERSION);
+MODULE_LICENSE(DRV_LICENSE);
+MODULE_AUTHOR(DRV_AUTHOR);
+MODULE_DESCRIPTION(DRV_DESC);
diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h
new file mode 100644
index 000000000000..2484b1f7d2ef
--- /dev/null
+++ b/include/uapi/linux/vduse.h
@@ -0,0 +1,178 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_VDUSE_H_
+#define _UAPI_VDUSE_H_
+
+#include <linux/types.h>
+
+#define VDUSE_API_VERSION 0
+
+#define VDUSE_MAX_TRANSFER_LEN 256
+#define VDUSE_NAME_MAX 256
+
+/* the control messages definition for read/write */
+
+enum vduse_req_type {
+ /* Set the vring address of virtqueue. */
+ VDUSE_SET_VQ_NUM,
+ /* Set the vring address of virtqueue. */
+ VDUSE_SET_VQ_ADDR,
+ /* Set ready status of virtqueue */
+ VDUSE_SET_VQ_READY,
+ /* Get ready status of virtqueue */
+ VDUSE_GET_VQ_READY,
+ /* Set the state for virtqueue */
+ VDUSE_SET_VQ_STATE,
+ /* Get the state for virtqueue */
+ VDUSE_GET_VQ_STATE,
+ /* Set virtio features supported by the driver */
+ VDUSE_SET_FEATURES,
+ /* Get virtio features supported by the device */
+ VDUSE_GET_FEATURES,
+ /* Set the device status */
+ VDUSE_SET_STATUS,
+ /* Get the device status */
+ VDUSE_GET_STATUS,
+ /* Write to device specific configuration space */
+ VDUSE_SET_CONFIG,
+ /* Read from device specific configuration space */
+ VDUSE_GET_CONFIG,
+ /* Notify userspace to update the memory mapping in device IOTLB */
+ VDUSE_UPDATE_IOTLB,
+};
+
+struct vduse_vq_num {
+ __u32 index; /* virtqueue index */
+ __u32 num; /* the size of virtqueue */
+};
+
+struct vduse_vq_addr {
+ __u32 index; /* virtqueue index */
+ __u32 padding; /* padding */
+ __u64 desc_addr; /* address of desc area */
+ __u64 driver_addr; /* address of driver area */
+ __u64 device_addr; /* address of device area */
+};
+
+struct vduse_vq_ready {
+ __u32 index; /* virtqueue index */
+ __u8 ready; /* ready status of virtqueue */
+};
+
+struct vduse_vq_state {
+ __u32 index; /* virtqueue index */
+ __u32 avail_idx; /* virtqueue state (last_avail_idx) */
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_MAX_TRANSFER_LEN]; /* data buffer used to read/write */
+};
+
+struct vduse_iova_range {
+ __u64 start; /* start of the IOVA range */
+ __u64 last; /* end of the IOVA range */
+};
+
+struct vduse_features {
+ __u64 features; /* virtio features */
+};
+
+struct vduse_status {
+ __u8 status; /* device status */
+};
+
+struct vduse_dev_request {
+ __u32 type; /* request type */
+ __u32 request_id; /* request id */
+ __u32 reserved[2]; /* for future use */
+ union {
+ struct vduse_vq_num vq_num; /* virtqueue num */
+ struct vduse_vq_addr vq_addr; /* virtqueue address */
+ struct vduse_vq_ready vq_ready; /* virtqueue ready status */
+ struct vduse_vq_state vq_state; /* virtqueue state */
+ struct vduse_dev_config_data config; /* virtio device config space */
+ struct vduse_iova_range iova; /* iova range for updating */
+ struct vduse_features f; /* virtio features */
+ struct vduse_status s; /* device status */
+ __u32 padding[128]; /* padding */
+ };
+};
+
+struct vduse_dev_response {
+ __u32 request_id; /* corresponding request id */
+#define VDUSE_REQUEST_OK 0x00
+#define VDUSE_REQUEST_FAILED 0x01
+ __u32 result; /* the result of request */
+ __u32 reserved[2]; /* for future use */
+ union {
+ struct vduse_vq_ready vq_ready; /* virtqueue ready status */
+ struct vduse_vq_state vq_state; /* virtqueue state */
+ struct vduse_dev_config_data config; /* virtio device config space */
+ struct vduse_features f; /* virtio features */
+ struct vduse_status s; /* device status */
+ __u32 padding[128]; /* padding */
+ };
+};
+
+/* ioctls */
+
+struct vduse_dev_config {
+ char name[VDUSE_NAME_MAX]; /* vduse device name */
+ __u32 vendor_id; /* virtio vendor id */
+ __u32 device_id; /* virtio device id */
+ __u64 bounce_size; /* bounce buffer size for iommu */
+ __u16 vq_size_max; /* the max size of virtqueue */
+ __u16 padding; /* padding */
+ __u32 vq_num; /* the number of virtqueues */
+ __u32 vq_align; /* the allocation alignment of virtqueue's metadata */
+ __u32 config_size; /* the size of the configuration space */
+ __u32 reserved[15]; /* for future use */
+};
+
+struct vduse_iotlb_entry {
+ __u64 offset; /* the mmap offset on fd */
+ __u64 start; /* start of the IOVA range */
+ __u64 last; /* last of the IOVA range */
+#define VDUSE_ACCESS_RO 0x1
+#define VDUSE_ACCESS_WO 0x2
+#define VDUSE_ACCESS_RW 0x3
+ __u8 perm; /* access permission of this range */
+};
+
+struct vduse_vq_eventfd {
+ __u32 index; /* virtqueue index */
+#define VDUSE_EVENTFD_DEASSIGN -1
+ int fd; /* eventfd, -1 means de-assigning the eventfd */
+};
+
+#define VDUSE_BASE 0x81
+
+/* Get the version of VDUSE API. This is used for future extension */
+#define VDUSE_GET_API_VERSION _IO(VDUSE_BASE, 0x00)
+
+/* Set the version of VDUSE API. */
+#define VDUSE_SET_API_VERSION _IO(VDUSE_BASE, 0x01)
+
+/* Create a vduse device which is represented by a char device (/dev/vduse/<name>) */
+#define VDUSE_CREATE_DEV _IOW(VDUSE_BASE, 0x02, struct vduse_dev_config)
+
+/* Destroy a vduse device. Make sure there are no references to the char device */
+#define VDUSE_DESTROY_DEV _IOW(VDUSE_BASE, 0x03, char[VDUSE_NAME_MAX])
+
+/*
+ * Get a file descriptor for the first overlapped iova region,
+ * -EINVAL means the iova region doesn't exist.
+ */
+#define VDUSE_IOTLB_GET_FD _IOWR(VDUSE_BASE, 0x04, struct vduse_iotlb_entry)
+
+/* Setup an eventfd to receive kick for virtqueue */
+#define VDUSE_VQ_SETUP_KICKFD _IOW(VDUSE_BASE, 0x05, struct vduse_vq_eventfd)
+
+/* Inject an interrupt for specific virtqueue */
+#define VDUSE_INJECT_VQ_IRQ _IOW(VDUSE_BASE, 0x06, __u32)
+
+/* Inject a config interrupt */
+#define VDUSE_INJECT_CONFIG_IRQ _IO(VDUSE_BASE, 0x07)
+
+#endif /* _UAPI_VDUSE_H_ */
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH v7 12/12] Documentation: Add documentation for VDUSE
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (10 preceding siblings ...)
2021-05-17 9:55 ` [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace Xie Yongji
@ 2021-05-17 9:55 ` Xie Yongji
2021-05-20 6:06 ` [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Michael S. Tsirkin
12 siblings, 0 replies; 51+ messages in thread
From: Xie Yongji @ 2021-05-17 9:55 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
VDUSE (vDPA Device in Userspace) is a framework to support
implementing software-emulated vDPA devices in userspace. This
document is intended to clarify the VDUSE design and usage.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 243 ++++++++++++++++++++++++++++++++++
2 files changed, 244 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst
index d29b020e5622..2dc25dd9f2aa 100644
--- a/Documentation/userspace-api/index.rst
+++ b/Documentation/userspace-api/index.rst
@@ -25,6 +25,7 @@ place where this information is gathered.
iommu
media/index
sysfs-platform_profile
+ vduse
.. only:: subproject and html
diff --git a/Documentation/userspace-api/vduse.rst b/Documentation/userspace-api/vduse.rst
new file mode 100644
index 000000000000..a804be347545
--- /dev/null
+++ b/Documentation/userspace-api/vduse.rst
@@ -0,0 +1,243 @@
+==================================
+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.
+
+In general, the userspace process that emulates the device is able to
+run unprivileged. And to reduce security risks, we only support emulating
+a few vDPA devices by default, including: virtio-net device, virtio-blk
+device, virtio-scsi device and virtio-fs device. Only when a sysadmin trusts
+the userspace process enough, it can relax the limitation with a
+'allow_unsafe_device_emulation' module parameter.
+
+How VDUSE works
+===============
+
+Start/Stop VDUSE devices
+------------------------
+
+VDUSE devices are started as follows:
+
+1. Create a new VDUSE instance with ioctl(VDUSE_CREATE_DEV) on
+ /dev/vduse/control.
+
+2. Begin processing VDUSE messages from /dev/vduse/$NAME. The first
+ messages will arrive while attaching the VDUSE instance to vDPA.
+
+3. Send the VDPA_CMD_DEV_NEW netlink message to attach the VDUSE
+ instance to vDPA.
+
+VDUSE devices are stopped as follows:
+
+1. Send the VDPA_CMD_DEV_DEL netlink message to detach the VDUSE
+ instance to vDPA.
+
+2. Close the file descriptor referring to /dev/vduse/$NAME
+
+3. Destroy the VDUSE instance with ioctl(VDUSE_DESTROY_DEV) on
+ /dev/vduse/control
+
+The netlink messages metioned above can be sent via vdpa tool in iproute2
+or use the below sample codes:
+
+.. code-block:: c
+
+ static int netlink_add_vduse(const char *name, enum vdpa_command cmd)
+ {
+ struct nl_sock *nlsock;
+ struct nl_msg *msg;
+ int famid;
+
+ nlsock = nl_socket_alloc();
+ if (!nlsock)
+ return -ENOMEM;
+
+ if (genl_connect(nlsock))
+ goto free_sock;
+
+ famid = genl_ctrl_resolve(nlsock, VDPA_GENL_NAME);
+ if (famid < 0)
+ goto close_sock;
+
+ msg = nlmsg_alloc();
+ if (!msg)
+ goto close_sock;
+
+ if (!genlmsg_put(msg, NL_AUTO_PORT, NL_AUTO_SEQ, famid, 0, 0, cmd, 0))
+ goto nla_put_failure;
+
+ NLA_PUT_STRING(msg, VDPA_ATTR_DEV_NAME, name);
+ if (cmd == VDPA_CMD_DEV_NEW)
+ NLA_PUT_STRING(msg, VDPA_ATTR_MGMTDEV_DEV_NAME, "vduse");
+
+ if (nl_send_sync(nlsock, msg))
+ goto close_sock;
+
+ nl_close(nlsock);
+ nl_socket_free(nlsock);
+
+ return 0;
+ nla_put_failure:
+ nlmsg_free(msg);
+ close_sock:
+ nl_close(nlsock);
+ free_sock:
+ nl_socket_free(nlsock);
+ return -1;
+ }
+
+Emulate VDUSE devices
+---------------------
+
+To emulate a VDUSE device, we always need to implement both control path
+and data path for it.
+
+To implement control path, a message-based communication protocol and some
+types of control messages are introduced in the VDUSE framework:
+
+- VDUSE_SET_VQ_ADDR: Set the vring address of virtqueue.
+
+- VDUSE_SET_VQ_NUM: Set the size of virtqueue
+
+- VDUSE_SET_VQ_READY: Set ready status of virtqueue
+
+- VDUSE_GET_VQ_READY: Get ready status of virtqueue
+
+- VDUSE_SET_VQ_STATE: Set the state for virtqueue
+
+- VDUSE_GET_VQ_STATE: Get the state for virtqueue
+
+- VDUSE_SET_FEATURES: Set virtio features supported by the driver
+
+- VDUSE_GET_FEATURES: Get virtio features supported by the device
+
+- VDUSE_SET_STATUS: Set the device status
+
+- VDUSE_GET_STATUS: Get the device status
+
+- VDUSE_SET_CONFIG: Write to device specific configuration space
+
+- VDUSE_GET_CONFIG: Read from device specific configuration space
+
+- VDUSE_UPDATE_IOTLB: Notify userspace to update the memory mapping in device IOTLB
+
+Those control messages are mostly based on the vdpa_config_ops in
+include/linux/vdpa.h which defines a unified interface to control
+different types of vdpa device. Userspace needs to read()/write()
+on /dev/vduse/$NAME to receive/reply those control messages
+from/to VDUSE kernel module as follows:
+
+.. code-block:: c
+
+ static int vduse_message_handler(int dev_fd)
+ {
+ int len;
+ struct vduse_dev_request req;
+ struct vduse_dev_response resp;
+
+ len = read(dev_fd, &req, sizeof(req));
+ if (len != sizeof(req))
+ return -1;
+
+ resp.request_id = req.request_id;
+
+ switch (req.type) {
+
+ /* handle different types of message */
+
+ }
+
+ len = write(dev_fd, &resp, sizeof(resp));
+ if (len != sizeof(resp))
+ return -1;
+
+ return 0;
+ }
+
+In the data path, vDPA device's iova regions will be mapped into userspace
+with the help of VDUSE_IOTLB_GET_FD ioctl on /dev/vduse/$NAME:
+
+- VDUSE_IOTLB_GET_FD: get the file descriptor to the first overlapped iova region.
+ Userspace can access this iova region by passing fd and corresponding size, offset,
+ perm to mmap(). For example:
+
+.. code-block:: c
+
+ static int perm_to_prot(uint8_t perm)
+ {
+ int prot = 0;
+
+ switch (perm) {
+ case VDUSE_ACCESS_WO:
+ prot |= PROT_WRITE;
+ break;
+ case VDUSE_ACCESS_RO:
+ prot |= PROT_READ;
+ break;
+ case VDUSE_ACCESS_RW:
+ prot |= PROT_READ | PROT_WRITE;
+ break;
+ }
+
+ return prot;
+ }
+
+ static void *iova_to_va(int dev_fd, uint64_t iova, uint64_t *len)
+ {
+ int fd;
+ void *addr;
+ size_t size;
+ struct vduse_iotlb_entry entry;
+
+ entry.start = iova;
+ entry.last = iova + 1;
+ fd = ioctl(dev_fd, VDUSE_IOTLB_GET_FD, &entry);
+ if (fd < 0)
+ return NULL;
+
+ size = entry.last - entry.start + 1;
+ *len = entry.last - iova + 1;
+ addr = mmap(0, size, perm_to_prot(entry.perm), MAP_SHARED,
+ fd, entry.offset);
+ close(fd);
+ if (addr == MAP_FAILED)
+ return NULL;
+
+ /* do something to cache this iova region */
+
+ return addr + iova - entry.start;
+ }
+
+Besides, the following ioctls on /dev/vduse/$NAME are provided to support
+interrupt injection and setting up eventfd for virtqueue kicks:
+
+- VDUSE_VQ_SETUP_KICKFD: set the kickfd for virtqueue, this eventfd is used
+ by VDUSE kernel module to notify userspace to consume the vring.
+
+- VDUSE_INJECT_VQ_IRQ: inject an interrupt for specific virtqueue
+
+- VDUSE_INJECT_CONFIG_IRQ: inject a config interrupt
+
+MMU-based IOMMU Driver
+======================
+
+VDUSE framework implements an MMU-based on-chip IOMMU driver to support
+mapping the kernel DMA buffer into the userspace iova region dynamically.
+This is mainly designed for virtio-vdpa case (kernel virtio drivers).
+
+The basic idea behind this driver is treating MMU (VA->PA) as IOMMU (IOVA->PA).
+The driver will set up MMU mapping instead of IOMMU mapping for the DMA transfer
+so that the userspace process is able to use its virtual address to access
+the DMA buffer in kernel.
+
+And to avoid security issue, a bounce-buffering mechanism is introduced to
+prevent userspace accessing the original buffer directly which may contain other
+kernel data. During the mapping, unmapping, the driver will copy the data from
+the original buffer to the bounce buffer and back, depending on the direction of
+the transfer. And the bounce-buffer addresses will be mapped into the user address
+space instead of the original one.
--
2.11.0
^ permalink raw reply related [flat|nested] 51+ messages in thread
* Re: [PATCH v7 04/12] virtio-blk: Add validation for block size in config space
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
0 siblings, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-19 13:39 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, Stefan Hajnoczi,
Stefano Garzarella, Parav Pandit, Christoph Hellwig,
Christian Brauner, Randy Dunlap, Matthew Wilcox, viro,
Jens Axboe, bcrl, Jonathan Corbet, Mika Penttilä,
Dan Carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
On Mon, May 17, 2021 at 5:56 PM Xie Yongji <xieyongji@bytedance.com> wrote:
>
> This ensures that we will not use an invalid block size
> in config space (might come from an untrusted device).
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> drivers/block/virtio_blk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index ebb4d3fe803f..c848aa36d49b 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -826,7 +826,7 @@ static int virtblk_probe(struct virtio_device *vdev)
> err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
> struct virtio_blk_config, blk_size,
> &blk_size);
> - if (!err)
> + if (!err && blk_size > 0 && blk_size <= max_size)
The check here is incorrect. I will use PAGE_SIZE as the maximum
boundary in the new version.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 04/12] virtio-blk: Add validation for block size in config space
2021-05-19 13:39 ` Yongji Xie
@ 2021-05-19 14:42 ` Dan Carpenter
2021-05-20 5:25 ` Yongji Xie
0 siblings, 1 reply; 51+ messages in thread
From: Dan Carpenter @ 2021-05-19 14:42 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Jason Wang, Stefan Hajnoczi,
Stefano Garzarella, Parav Pandit, Christoph Hellwig,
Christian Brauner, Randy Dunlap, Matthew Wilcox, viro,
Jens Axboe, bcrl, Jonathan Corbet, Mika Penttilä,
joro, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Wed, May 19, 2021 at 09:39:20PM +0800, Yongji Xie wrote:
> On Mon, May 17, 2021 at 5:56 PM Xie Yongji <xieyongji@bytedance.com> wrote:
> >
> > This ensures that we will not use an invalid block size
> > in config space (might come from an untrusted device).
I looked at if I should add this as an untrusted function so that Smatch
could find these sorts of bugs but this is reading data from the host so
there has to be some level of trust...
I should add some more untrusted data kvm functions to Smatch. Right
now I only have kvm_register_read() and I've added kvm_read_guest_virt()
just now.
> >
> > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > ---
> > drivers/block/virtio_blk.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> > index ebb4d3fe803f..c848aa36d49b 100644
> > --- a/drivers/block/virtio_blk.c
> > +++ b/drivers/block/virtio_blk.c
> > @@ -826,7 +826,7 @@ static int virtblk_probe(struct virtio_device *vdev)
> > err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
> > struct virtio_blk_config, blk_size,
> > &blk_size);
> > - if (!err)
> > + if (!err && blk_size > 0 && blk_size <= max_size)
>
> The check here is incorrect. I will use PAGE_SIZE as the maximum
> boundary in the new version.
What does this bug look like to the user? A minimum block size of 1
seems pretty crazy. Surely the minimum should be higher?
regards,
dan carpenter
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 04/12] virtio-blk: Add validation for block size in config space
2021-05-19 14:42 ` Dan Carpenter
@ 2021-05-20 5:25 ` Yongji Xie
2021-05-20 5:43 ` Michael S. Tsirkin
0 siblings, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-20 5:25 UTC (permalink / raw)
To: Dan Carpenter
Cc: Michael S. Tsirkin, Jason Wang, Stefan Hajnoczi,
Stefano Garzarella, Parav Pandit, Christoph Hellwig,
Christian Brauner, Randy Dunlap, Matthew Wilcox, viro,
Jens Axboe, bcrl, Jonathan Corbet, Mika Penttilä,
joro, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Wed, May 19, 2021 at 10:42 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> On Wed, May 19, 2021 at 09:39:20PM +0800, Yongji Xie wrote:
> > On Mon, May 17, 2021 at 5:56 PM Xie Yongji <xieyongji@bytedance.com> wrote:
> > >
> > > This ensures that we will not use an invalid block size
> > > in config space (might come from an untrusted device).
>
> I looked at if I should add this as an untrusted function so that Smatch
> could find these sorts of bugs but this is reading data from the host so
> there has to be some level of trust...
>
It would be great if Smatch could detect this case if possible. The
data might be trusted in traditional VM cases. But now the data can be
read from a userspace daemon when VDUSE is enabled.
> I should add some more untrusted data kvm functions to Smatch. Right
> now I only have kvm_register_read() and I've added kvm_read_guest_virt()
> just now.
>
> > >
> > > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > > ---
> > > drivers/block/virtio_blk.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> > > index ebb4d3fe803f..c848aa36d49b 100644
> > > --- a/drivers/block/virtio_blk.c
> > > +++ b/drivers/block/virtio_blk.c
> > > @@ -826,7 +826,7 @@ static int virtblk_probe(struct virtio_device *vdev)
> > > err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
> > > struct virtio_blk_config, blk_size,
> > > &blk_size);
> > > - if (!err)
> > > + if (!err && blk_size > 0 && blk_size <= max_size)
> >
> > The check here is incorrect. I will use PAGE_SIZE as the maximum
> > boundary in the new version.
>
> What does this bug look like to the user?
The kernel will panic if the block size is larger than PAGE_SIZE.
> A minimum block size of 1 seems pretty crazy. Surely the minimum should be > higher?
>
Yes, 512 is better here.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 04/12] virtio-blk: Add validation for block size in config space
2021-05-20 5:25 ` Yongji Xie
@ 2021-05-20 5:43 ` Michael S. Tsirkin
2021-05-20 7:08 ` Yongji Xie
0 siblings, 1 reply; 51+ messages in thread
From: Michael S. Tsirkin @ 2021-05-20 5:43 UTC (permalink / raw)
To: Yongji Xie
Cc: Dan Carpenter, Jason Wang, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
joro, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Thu, May 20, 2021 at 01:25:16PM +0800, Yongji Xie wrote:
> On Wed, May 19, 2021 at 10:42 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >
> > On Wed, May 19, 2021 at 09:39:20PM +0800, Yongji Xie wrote:
> > > On Mon, May 17, 2021 at 5:56 PM Xie Yongji <xieyongji@bytedance.com> wrote:
> > > >
> > > > This ensures that we will not use an invalid block size
> > > > in config space (might come from an untrusted device).
> >
> > I looked at if I should add this as an untrusted function so that Smatch
> > could find these sorts of bugs but this is reading data from the host so
> > there has to be some level of trust...
> >
>
> It would be great if Smatch could detect this case if possible. The
> data might be trusted in traditional VM cases. But now the data can be
> read from a userspace daemon when VDUSE is enabled.
>
> > I should add some more untrusted data kvm functions to Smatch. Right
> > now I only have kvm_register_read() and I've added kvm_read_guest_virt()
> > just now.
> >
> > > >
> > > > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > > > ---
> > > > drivers/block/virtio_blk.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> > > > index ebb4d3fe803f..c848aa36d49b 100644
> > > > --- a/drivers/block/virtio_blk.c
> > > > +++ b/drivers/block/virtio_blk.c
> > > > @@ -826,7 +826,7 @@ static int virtblk_probe(struct virtio_device *vdev)
> > > > err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
> > > > struct virtio_blk_config, blk_size,
> > > > &blk_size);
> > > > - if (!err)
> > > > + if (!err && blk_size > 0 && blk_size <= max_size)
> > >
> > > The check here is incorrect. I will use PAGE_SIZE as the maximum
> > > boundary in the new version.
> >
> > What does this bug look like to the user?
>
> The kernel will panic if the block size is larger than PAGE_SIZE.
Kernel panic at this point is par for the course IMHO.
Let's focus on eliminating data corruption for starters.
> > A minimum block size of 1 seems pretty crazy. Surely the minimum should be > higher?
> >
>
> Yes, 512 is better here.
>
> Thanks,
> Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace
2021-05-17 9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (11 preceding siblings ...)
2021-05-17 9:55 ` [PATCH v7 12/12] Documentation: Add documentation for VDUSE Xie Yongji
@ 2021-05-20 6:06 ` Michael S. Tsirkin
2021-05-20 9:06 ` Yongji Xie
12 siblings, 1 reply; 51+ messages in thread
From: Michael S. Tsirkin @ 2021-05-20 6:06 UTC (permalink / raw)
To: Xie Yongji
Cc: jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Mon, May 17, 2021 at 05:55:01PM +0800, Xie Yongji wrote:
> This series introduces a framework, which can be used to implement
> vDPA Devices in a userspace program. The work consist of two parts:
> control path forwarding and data path offloading.
>
> 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 core is mapping dma buffer into VDUSE
> daemon's address space, which can be implemented in different ways
> depending on the vdpa bus to which the vDPA device is attached.
>
> In virtio-vdpa case, we implements a MMU-based on-chip IOMMU driver with
> bounce-buffering mechanism to achieve that. And in vhost-vdpa case, the dma
> buffer is reside in a userspace memory region which can be shared to the
> VDUSE userspace processs via transferring the shmfd.
>
> The details and our user case is shown below:
>
> ------------------------ ------------------------- ----------------------------------------------
> | Container | | QEMU(VM) | | VDUSE daemon |
> | --------- | | ------------------- | | ------------------------- ---------------- |
> | |dev/vdx| | | |/dev/vhost-vdpa-x| | | | vDPA device emulation | | block driver | |
> ------------+----------- -----------+------------ -------------+----------------------+---------
> | | | |
> | | | |
> ------------+---------------------------+----------------------------+----------------------+---------
> | | block device | | vhost device | | vduse driver | | TCP/IP | |
> | -------+-------- --------+-------- -------+-------- -----+---- |
> | | | | | |
> | ----------+---------- ----------+----------- -------+------- | |
> | | virtio-blk driver | | vhost-vdpa driver | | vdpa device | | |
> | ----------+---------- ----------+----------- -------+------- | |
> | | virtio bus | | | |
> | --------+----+----------- | | | |
> | | | | | |
> | ----------+---------- | | | |
> | | virtio-blk device | | | | |
> | ----------+---------- | | | |
> | | | | | |
> | -----------+----------- | | | |
> | | virtio-vdpa driver | | | | |
> | -----------+----------- | | | |
> | | | | vdpa bus | |
> | -----------+----------------------+---------------------------+------------ | |
> | ---+--- |
> -----------------------------------------------------------------------------------------| NIC |------
> ---+---
> |
> ---------+---------
> | Remote Storages |
> -------------------
>
> We make use of it to implement a block device connecting to
> our distributed storage, which can be used both in containers and
> VMs. Thus, we can have an unified technology stack in this two cases.
>
> To test it with null-blk:
>
> $ qemu-storage-daemon \
> --chardev socket,id=charmonitor,path=/tmp/qmp.sock,server,nowait \
> --monitor chardev=charmonitor \
> --blockdev driver=host_device,cache.direct=on,aio=native,filename=/dev/nullb0,node-name=disk0 \
> --export type=vduse-blk,id=test,node-name=disk0,writable=on,name=vduse-null,num-queues=16,queue-size=128
>
> The qemu-storage-daemon can be found at https://github.com/bytedance/qemu/tree/vduse
>
> To make the userspace VDUSE processes such as qemu-storage-daemon able to
> run unprivileged. We did some works on virtio driver to avoid trusting
> device, including:
>
> - validating the device status:
>
> * https://lore.kernel.org/lkml/20210517093428.670-1-xieyongji@bytedance.com/
>
> - validating the used length:
>
> * https://lore.kernel.org/lkml/20210517090836.533-1-xieyongji@bytedance.com/
>
> - validating the device config:
>
> * patch 4 ("virtio-blk: Add validation for block size in config space")
>
> - validating the device response:
>
> * patch 5 ("virtio_scsi: Add validation for residual bytes from response")
>
> Since I'm not sure if I missing something during auditing, especially on some
> virtio device drivers that I'm not familiar with, now we only support emualting
> a few vDPA devices by default, including: virtio-net device, virtio-blk device,
> virtio-scsi device and virtio-fs device. This limitaion can help to reduce
> security risks.
I suspect there are a lot of assumptions even with these 4.
Just what are the security assumptions and guarantees here?
E.g. it seems pretty clear that exposing a malformed FS
to a random kernel config can cause untold mischief.
Things like virtnet_send_command are also an easy way for
the device to DOS the kernel. And before you try to add
an arbitrary timeout there - please don't,
the fix is moving things that must be guaranteed into kernel
and making things that are not guaranteed asynchronous.
Right now there are some things that happen with locks taken,
where if we don't wait for device we lose the ability to report failures
to userspace. E.g. all kind of netlink things are like this.
One can think of a bunch of ways to address this, this
needs to be discussed with the relevant subsystem maintainers.
If I were you I would start with one type of device, and as simple one
as possible.
> When a sysadmin trusts the userspace process enough, it can relax
> the limitation with a 'allow_unsafe_device_emulation' module parameter.
That's not a great security interface. It's a global module specific knob
that just allows any userspace to emulate anything at all.
Coming up with a reasonable interface isn't going to be easy.
For now maybe just have people patch their kernels if they want to
move fast and break things.
> Future work:
> - Improve performance
> - Userspace library (find a way to reuse device emulation code in qemu/rust-vmm)
>
> V6 to V7:
> - Export alloc_iova_fast()
> - Add get_config_size() callback
> - Add some patches to avoid trusting virtio devices
> - Add limited device emulation
> - Add some documents
> - Use workqueue to inject config irq
> - Add parameter on vq irq injecting
> - Rename vduse_domain_get_mapping_page() to vduse_domain_get_coherent_page()
> - Add WARN_ON() to catch message failure
> - Add some padding/reserved fields to uAPI structure
> - Fix some bugs
> - Rebase to vhost.git
>
> V5 to V6:
> - Export receive_fd() instead of __receive_fd()
> - Factor out the unmapping logic of pa and va separatedly
> - Remove the logic of bounce page allocation in page fault handler
> - Use PAGE_SIZE as IOVA allocation granule
> - Add EPOLLOUT support
> - Enable setting API version in userspace
> - Fix some bugs
>
> V4 to V5:
> - Remove the patch for irq binding
> - Use a single IOTLB for all types of mapping
> - Factor out vhost_vdpa_pa_map()
> - Add some sample codes in document
> - Use receice_fd_user() to pass file descriptor
> - Fix some bugs
>
> V3 to V4:
> - Rebase to vhost.git
> - Split some patches
> - Add some documents
> - Use ioctl to inject interrupt rather than eventfd
> - Enable config interrupt support
> - Support binding irq to the specified cpu
> - Add two module parameter to limit bounce/iova size
> - Create char device rather than anon inode per vduse
> - Reuse vhost IOTLB for iova domain
> - Rework the message mechnism in control path
>
> V2 to V3:
> - Rework the MMU-based IOMMU driver
> - Use the iova domain as iova allocator instead of genpool
> - Support transferring vma->vm_file in vhost-vdpa
> - Add SVA support in vhost-vdpa
> - Remove the patches on bounce pages reclaim
>
> V1 to V2:
> - Add vhost-vdpa support
> - Add some documents
> - Based on the vdpa management tool
> - Introduce a workqueue for irq injection
> - Replace interval tree with array map to store the iova_map
>
> Xie Yongji (12):
> iova: Export alloc_iova_fast()
> file: Export receive_fd() to modules
> eventfd: Increase the recursion depth of eventfd_signal()
> virtio-blk: Add validation for block size in config space
> virtio_scsi: Add validation for residual bytes from response
> vhost-iotlb: Add an opaque pointer for vhost IOTLB
> vdpa: Add an opaque pointer for vdpa_config_ops.dma_map()
> vdpa: factor out vhost_vdpa_pa_map() and vhost_vdpa_pa_unmap()
> vdpa: Support transferring virtual addressing during DMA mapping
> vduse: Implement an MMU-based IOMMU driver
> vduse: Introduce VDUSE - vDPA Device in Userspace
> Documentation: Add documentation for VDUSE
>
> Documentation/userspace-api/index.rst | 1 +
> Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
> Documentation/userspace-api/vduse.rst | 243 ++++
> drivers/block/virtio_blk.c | 2 +-
> drivers/iommu/iova.c | 1 +
> drivers/scsi/virtio_scsi.c | 2 +-
> drivers/vdpa/Kconfig | 10 +
> drivers/vdpa/Makefile | 1 +
> drivers/vdpa/ifcvf/ifcvf_main.c | 2 +-
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
> drivers/vdpa/vdpa.c | 9 +-
> drivers/vdpa/vdpa_sim/vdpa_sim.c | 8 +-
> drivers/vdpa/vdpa_user/Makefile | 5 +
> drivers/vdpa/vdpa_user/iova_domain.c | 531 +++++++
> drivers/vdpa/vdpa_user/iova_domain.h | 70 +
> drivers/vdpa/vdpa_user/vduse_dev.c | 1453 ++++++++++++++++++++
> drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +-
> drivers/vhost/iotlb.c | 20 +-
> drivers/vhost/vdpa.c | 148 +-
> fs/eventfd.c | 2 +-
> fs/file.c | 6 +
> include/linux/eventfd.h | 5 +-
> include/linux/file.h | 7 +-
> include/linux/vdpa.h | 21 +-
> include/linux/vhost_iotlb.h | 3 +
> include/uapi/linux/vduse.h | 178 +++
> 26 files changed, 2681 insertions(+), 52 deletions(-)
> create mode 100644 Documentation/userspace-api/vduse.rst
> create mode 100644 drivers/vdpa/vdpa_user/Makefile
> 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_dev.c
> create mode 100644 include/uapi/linux/vduse.h
>
> --
> 2.11.0
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 02/12] file: Export receive_fd() to modules
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
0 siblings, 1 reply; 51+ messages in thread
From: Al Viro @ 2021-05-20 6:18 UTC (permalink / raw)
To: Xie Yongji
Cc: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Mon, May 17, 2021 at 05:55:03PM +0800, Xie Yongji wrote:
> Export receive_fd() so that some modules can use
> it to pass file descriptor between processes without
> missing any security stuffs.
Which tree is that against? Because in mainline this won't even build, let
alone work.
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -1135,6 +1135,12 @@ int __receive_fd(int fd, struct file *file, int __user *ufd, unsigned int o_flag
> return new_fd;
> }
>
> +int receive_fd(struct file *file, unsigned int o_flags)
> +{
> + return __receive_fd(-1, file, NULL, o_flags);
> +}
> +EXPORT_SYMBOL_GPL(receive_fd);
fs/file.c:1097:int __receive_fd(struct file *file, int __user *ufd, unsigned int o_flags)
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
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-31 4:56 ` Greg KH
2 siblings, 1 reply; 51+ messages in thread
From: Al Viro @ 2021-05-20 6:28 UTC (permalink / raw)
To: Xie Yongji
Cc: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Mon, May 17, 2021 at 05:55:12PM +0800, Xie Yongji wrote:
> + case VDUSE_IOTLB_GET_FD: {
> + struct vduse_iotlb_entry entry;
> + struct vhost_iotlb_map *map;
> + struct vdpa_map_file *map_file;
> + struct vduse_iova_domain *domain = dev->domain;
> + struct file *f = NULL;
> +
> + ret = -EFAULT;
> + if (copy_from_user(&entry, argp, sizeof(entry)))
> + break;
return -EFAULT;
surely?
> +
> + ret = -EINVAL;
> + if (entry.start > entry.last)
> + break;
... and similar here, etc.
> + spin_lock(&domain->iotlb_lock);
> + map = vhost_iotlb_itree_first(domain->iotlb,
> + entry.start, entry.last);
> + if (map) {
> + map_file = (struct vdpa_map_file *)map->opaque;
> + f = get_file(map_file->file);
> + entry.offset = map_file->offset;
> + entry.start = map->start;
> + entry.last = map->last;
> + entry.perm = map->perm;
> + }
> + spin_unlock(&domain->iotlb_lock);
> + ret = -EINVAL;
> + if (!f)
> + break;
> +
> + ret = -EFAULT;
> + if (copy_to_user(argp, &entry, sizeof(entry))) {
> + fput(f);
> + break;
> + }
> + ret = receive_fd(f, perm_to_file_flags(entry.perm));
> + fput(f);
> + break;
IDGI. The main difference between receive_fd() and plain old
get_unused_fd_flags() + fd_install() is __receive_sock() call.
Which does nothing whatsoever in case of non-sockets. Can you
get a socket here?
IOW, why bother with that crap at all, nevermind exporting it?
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 02/12] file: Export receive_fd() to modules
2021-05-20 6:18 ` Al Viro
@ 2021-05-20 6:32 ` Yongji Xie
0 siblings, 0 replies; 51+ messages in thread
From: Yongji Xie @ 2021-05-20 6:32 UTC (permalink / raw)
To: Al Viro
Cc: Michael S. Tsirkin, Jason Wang, Stefan Hajnoczi,
Stefano Garzarella, Parav Pandit, Christoph Hellwig,
Christian Brauner, Randy Dunlap, Matthew Wilcox, Jens Axboe,
bcrl, Jonathan Corbet, Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Thu, May 20, 2021 at 2:18 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Mon, May 17, 2021 at 05:55:03PM +0800, Xie Yongji wrote:
> > Export receive_fd() so that some modules can use
> > it to pass file descriptor between processes without
> > missing any security stuffs.
>
> Which tree is that against? Because in mainline this won't even build, let
> alone work.
>
Oh, sorry for that. Now I'm based on vhost.git tree. But looks like I
miss Christoph's commit
42eb0d54c08 ("fs: split receive_fd_replace from __receive_fd"). Will
rebase on it in v8.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-20 6:28 ` Al Viro
@ 2021-05-20 7:03 ` Yongji Xie
0 siblings, 0 replies; 51+ messages in thread
From: Yongji Xie @ 2021-05-20 7:03 UTC (permalink / raw)
To: Al Viro
Cc: Michael S. Tsirkin, Jason Wang, Stefan Hajnoczi,
Stefano Garzarella, Parav Pandit, Christoph Hellwig,
Christian Brauner, Randy Dunlap, Matthew Wilcox, Jens Axboe,
bcrl, Jonathan Corbet, Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Thu, May 20, 2021 at 2:28 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Mon, May 17, 2021 at 05:55:12PM +0800, Xie Yongji wrote:
>
> > + case VDUSE_IOTLB_GET_FD: {
> > + struct vduse_iotlb_entry entry;
> > + struct vhost_iotlb_map *map;
> > + struct vdpa_map_file *map_file;
> > + struct vduse_iova_domain *domain = dev->domain;
> > + struct file *f = NULL;
> > +
> > + ret = -EFAULT;
> > + if (copy_from_user(&entry, argp, sizeof(entry)))
> > + break;
>
> return -EFAULT;
> surely?
> > +
> > + ret = -EINVAL;
> > + if (entry.start > entry.last)
> > + break;
>
> ... and similar here, etc.
>
OK.
> > + spin_lock(&domain->iotlb_lock);
> > + map = vhost_iotlb_itree_first(domain->iotlb,
> > + entry.start, entry.last);
> > + if (map) {
> > + map_file = (struct vdpa_map_file *)map->opaque;
> > + f = get_file(map_file->file);
> > + entry.offset = map_file->offset;
> > + entry.start = map->start;
> > + entry.last = map->last;
> > + entry.perm = map->perm;
> > + }
> > + spin_unlock(&domain->iotlb_lock);
> > + ret = -EINVAL;
> > + if (!f)
> > + break;
> > +
> > + ret = -EFAULT;
> > + if (copy_to_user(argp, &entry, sizeof(entry))) {
> > + fput(f);
> > + break;
> > + }
> > + ret = receive_fd(f, perm_to_file_flags(entry.perm));
> > + fput(f);
> > + break;
>
> IDGI. The main difference between receive_fd() and plain old
> get_unused_fd_flags() + fd_install() is __receive_sock() call.
> Which does nothing whatsoever in case of non-sockets. Can you
> get a socket here?
>
Actually what I want here is the security_file_receive() hook in receive_fd().
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: Re: [PATCH v7 04/12] virtio-blk: Add validation for block size in config space
2021-05-20 5:43 ` Michael S. Tsirkin
@ 2021-05-20 7:08 ` Yongji Xie
0 siblings, 0 replies; 51+ messages in thread
From: Yongji Xie @ 2021-05-20 7:08 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Dan Carpenter, Jason Wang, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
joro, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Thu, May 20, 2021 at 1:43 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Thu, May 20, 2021 at 01:25:16PM +0800, Yongji Xie wrote:
> > On Wed, May 19, 2021 at 10:42 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > >
> > > On Wed, May 19, 2021 at 09:39:20PM +0800, Yongji Xie wrote:
> > > > On Mon, May 17, 2021 at 5:56 PM Xie Yongji <xieyongji@bytedance.com> wrote:
> > > > >
> > > > > This ensures that we will not use an invalid block size
> > > > > in config space (might come from an untrusted device).
> > >
> > > I looked at if I should add this as an untrusted function so that Smatch
> > > could find these sorts of bugs but this is reading data from the host so
> > > there has to be some level of trust...
> > >
> >
> > It would be great if Smatch could detect this case if possible. The
> > data might be trusted in traditional VM cases. But now the data can be
> > read from a userspace daemon when VDUSE is enabled.
> >
> > > I should add some more untrusted data kvm functions to Smatch. Right
> > > now I only have kvm_register_read() and I've added kvm_read_guest_virt()
> > > just now.
> > >
> > > > >
> > > > > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > > > > ---
> > > > > drivers/block/virtio_blk.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> > > > > index ebb4d3fe803f..c848aa36d49b 100644
> > > > > --- a/drivers/block/virtio_blk.c
> > > > > +++ b/drivers/block/virtio_blk.c
> > > > > @@ -826,7 +826,7 @@ static int virtblk_probe(struct virtio_device *vdev)
> > > > > err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
> > > > > struct virtio_blk_config, blk_size,
> > > > > &blk_size);
> > > > > - if (!err)
> > > > > + if (!err && blk_size > 0 && blk_size <= max_size)
> > > >
> > > > The check here is incorrect. I will use PAGE_SIZE as the maximum
> > > > boundary in the new version.
> > >
> > > What does this bug look like to the user?
> >
> > The kernel will panic if the block size is larger than PAGE_SIZE.
>
> Kernel panic at this point is par for the course IMHO.
But it seems better if we can avoid this kind of panic. Because this
might also be triggered by a buggy VDUSE daemon.
> Let's focus on eliminating data corruption for starters.
OK, now the incorrect used length might cause data corruption in
virtio-net and virtio-console drivers as I mentioned in another mail.
I will send a fix ASAP.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace
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
0 siblings, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-20 9:06 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, Stefan Hajnoczi, Stefano Garzarella, Parav Pandit,
Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 8219 bytes --]
On Thu, May 20, 2021 at 2:06 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Mon, May 17, 2021 at 05:55:01PM +0800, Xie Yongji wrote:
> > This series introduces a framework, which can be used to implement
> > vDPA Devices in a userspace program. The work consist of two parts:
> > control path forwarding and data path offloading.
> >
> > 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 core is mapping dma buffer into VDUSE
> > daemon's address space, which can be implemented in different ways
> > depending on the vdpa bus to which the vDPA device is attached.
> >
> > In virtio-vdpa case, we implements a MMU-based on-chip IOMMU driver with
> > bounce-buffering mechanism to achieve that. And in vhost-vdpa case, the dma
> > buffer is reside in a userspace memory region which can be shared to the
> > VDUSE userspace processs via transferring the shmfd.
> >
> > The details and our user case is shown below:
> >
> > ------------------------ ------------------------- ----------------------------------------------
> > | Container | | QEMU(VM) | | VDUSE daemon |
> > | --------- | | ------------------- | | ------------------------- ---------------- |
> > | |dev/vdx| | | |/dev/vhost-vdpa-x| | | | vDPA device emulation | | block driver | |
> > ------------+----------- -----------+------------ -------------+----------------------+---------
> > | | | |
> > | | | |
> > ------------+---------------------------+----------------------------+----------------------+---------
> > | | block device | | vhost device | | vduse driver | | TCP/IP | |
> > | -------+-------- --------+-------- -------+-------- -----+---- |
> > | | | | | |
> > | ----------+---------- ----------+----------- -------+------- | |
> > | | virtio-blk driver | | vhost-vdpa driver | | vdpa device | | |
> > | ----------+---------- ----------+----------- -------+------- | |
> > | | virtio bus | | | |
> > | --------+----+----------- | | | |
> > | | | | | |
> > | ----------+---------- | | | |
> > | | virtio-blk device | | | | |
> > | ----------+---------- | | | |
> > | | | | | |
> > | -----------+----------- | | | |
> > | | virtio-vdpa driver | | | | |
> > | -----------+----------- | | | |
> > | | | | vdpa bus | |
> > | -----------+----------------------+---------------------------+------------ | |
> > | ---+--- |
> > -----------------------------------------------------------------------------------------| NIC |------
> > ---+---
> > |
> > ---------+---------
> > | Remote Storages |
> > -------------------
> >
> > We make use of it to implement a block device connecting to
> > our distributed storage, which can be used both in containers and
> > VMs. Thus, we can have an unified technology stack in this two cases.
> >
> > To test it with null-blk:
> >
> > $ qemu-storage-daemon \
> > --chardev socket,id=charmonitor,path=/tmp/qmp.sock,server,nowait \
> > --monitor chardev=charmonitor \
> > --blockdev driver=host_device,cache.direct=on,aio=native,filename=/dev/nullb0,node-name=disk0 \
> > --export type=vduse-blk,id=test,node-name=disk0,writable=on,name=vduse-null,num-queues=16,queue-size=128
> >
> > The qemu-storage-daemon can be found at https://github.com/bytedance/qemu/tree/vduse
> >
> > To make the userspace VDUSE processes such as qemu-storage-daemon able to
> > run unprivileged. We did some works on virtio driver to avoid trusting
> > device, including:
> >
> > - validating the device status:
> >
> > * https://lore.kernel.org/lkml/20210517093428.670-1-xieyongji@bytedance.com/
> >
> > - validating the used length:
> >
> > * https://lore.kernel.org/lkml/20210517090836.533-1-xieyongji@bytedance.com/
> >
> > - validating the device config:
> >
> > * patch 4 ("virtio-blk: Add validation for block size in config space")
> >
> > - validating the device response:
> >
> > * patch 5 ("virtio_scsi: Add validation for residual bytes from response")
> >
> > Since I'm not sure if I missing something during auditing, especially on some
> > virtio device drivers that I'm not familiar with, now we only support emualting
> > a few vDPA devices by default, including: virtio-net device, virtio-blk device,
> > virtio-scsi device and virtio-fs device. This limitation can help to reduce
> > security risks.
>
> I suspect there are a lot of assumptions even with these 4.
> Just what are the security assumptions and guarantees here?
The attack surface from a virtio device is limited with IOMMU enabled.
It should be able to avoid security risk if we can validate all data
such as config space and used length from device in device driver.
> E.g. it seems pretty clear that exposing a malformed FS
> to a random kernel config can cause untold mischief.
>
> Things like virtnet_send_command are also an easy way for
> the device to DOS the kernel. And before you try to add
> an arbitrary timeout there - please don't,
> the fix is moving things that must be guaranteed into kernel
> and making things that are not guaranteed asynchronous.
> Right now there are some things that happen with locks taken,
> where if we don't wait for device we lose the ability to report failures
> to userspace. E.g. all kind of netlink things are like this.
> One can think of a bunch of ways to address this, this
> needs to be discussed with the relevant subsystem maintainers.
>
>
> If I were you I would start with one type of device, and as simple one
> as possible.
>
Make sense to me. The virtio-blk device might be a good start. We
already have some existing interface like NBD to do similar things.
>
>
> > When a sysadmin trusts the userspace process enough, it can relax
> > the limitation with a 'allow_unsafe_device_emulation' module parameter.
>
> That's not a great security interface. It's a global module specific knob
> that just allows any userspace to emulate anything at all.
> Coming up with a reasonable interface isn't going to be easy.
> For now maybe just have people patch their kernels if they want to
> move fast and break things.
>
OK. A reasonable interface can be added if we need it in the future.
Thanks,
Yongji
[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 46427 bytes --]
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace
2021-05-20 9:06 ` Yongji Xie
@ 2021-05-25 6:40 ` Jason Wang
2021-05-25 6:48 ` Michael S. Tsirkin
0 siblings, 1 reply; 51+ messages in thread
From: Jason Wang @ 2021-05-25 6:40 UTC (permalink / raw)
To: Yongji Xie, Michael S. Tsirkin
Cc: Stefan Hajnoczi, Stefano Garzarella, Parav Pandit,
Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
在 2021/5/20 下午5:06, Yongji Xie 写道:
> On Thu, May 20, 2021 at 2:06 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>> On Mon, May 17, 2021 at 05:55:01PM +0800, Xie Yongji wrote:
>>> This series introduces a framework, which can be used to implement
>>> vDPA Devices in a userspace program. The work consist of two parts:
>>> control path forwarding and data path offloading.
>>>
>>> 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 core is mapping dma buffer into VDUSE
>>> daemon's address space, which can be implemented in different ways
>>> depending on the vdpa bus to which the vDPA device is attached.
>>>
>>> In virtio-vdpa case, we implements a MMU-based on-chip IOMMU driver with
>>> bounce-buffering mechanism to achieve that. And in vhost-vdpa case, the dma
>>> buffer is reside in a userspace memory region which can be shared to the
>>> VDUSE userspace processs via transferring the shmfd.
>>>
>>> The details and our user case is shown below:
>>>
>>> ------------------------ ------------------------- ----------------------------------------------
>>> | Container | | QEMU(VM) | | VDUSE daemon |
>>> | --------- | | ------------------- | | ------------------------- ---------------- |
>>> | |dev/vdx| | | |/dev/vhost-vdpa-x| | | | vDPA device emulation | | block driver | |
>>> ------------+----------- -----------+------------ -------------+----------------------+---------
>>> | | | |
>>> | | | |
>>> ------------+---------------------------+----------------------------+----------------------+---------
>>> | | block device | | vhost device | | vduse driver | | TCP/IP | |
>>> | -------+-------- --------+-------- -------+-------- -----+---- |
>>> | | | | | |
>>> | ----------+---------- ----------+----------- -------+------- | |
>>> | | virtio-blk driver | | vhost-vdpa driver | | vdpa device | | |
>>> | ----------+---------- ----------+----------- -------+------- | |
>>> | | virtio bus | | | |
>>> | --------+----+----------- | | | |
>>> | | | | | |
>>> | ----------+---------- | | | |
>>> | | virtio-blk device | | | | |
>>> | ----------+---------- | | | |
>>> | | | | | |
>>> | -----------+----------- | | | |
>>> | | virtio-vdpa driver | | | | |
>>> | -----------+----------- | | | |
>>> | | | | vdpa bus | |
>>> | -----------+----------------------+---------------------------+------------ | |
>>> | ---+--- |
>>> -----------------------------------------------------------------------------------------| NIC |------
>>> ---+---
>>> |
>>> ---------+---------
>>> | Remote Storages |
>>> -------------------
>>>
>>> We make use of it to implement a block device connecting to
>>> our distributed storage, which can be used both in containers and
>>> VMs. Thus, we can have an unified technology stack in this two cases.
>>>
>>> To test it with null-blk:
>>>
>>> $ qemu-storage-daemon \
>>> --chardev socket,id=charmonitor,path=/tmp/qmp.sock,server,nowait \
>>> --monitor chardev=charmonitor \
>>> --blockdev driver=host_device,cache.direct=on,aio=native,filename=/dev/nullb0,node-name=disk0 \
>>> --export type=vduse-blk,id=test,node-name=disk0,writable=on,name=vduse-null,num-queues=16,queue-size=128
>>>
>>> The qemu-storage-daemon can be found at https://github.com/bytedance/qemu/tree/vduse
>>>
>>> To make the userspace VDUSE processes such as qemu-storage-daemon able to
>>> run unprivileged. We did some works on virtio driver to avoid trusting
>>> device, including:
>>>
>>> - validating the device status:
>>>
>>> * https://lore.kernel.org/lkml/20210517093428.670-1-xieyongji@bytedance.com/
>>>
>>> - validating the used length:
>>>
>>> * https://lore.kernel.org/lkml/20210517090836.533-1-xieyongji@bytedance.com/
>>>
>>> - validating the device config:
>>>
>>> * patch 4 ("virtio-blk: Add validation for block size in config space")
>>>
>>> - validating the device response:
>>>
>>> * patch 5 ("virtio_scsi: Add validation for residual bytes from response")
>>>
>>> Since I'm not sure if I missing something during auditing, especially on some
>>> virtio device drivers that I'm not familiar with, now we only support emualting
>>> a few vDPA devices by default, including: virtio-net device, virtio-blk device,
>>> virtio-scsi device and virtio-fs device. This limitation can help to reduce
>>> security risks.
>> I suspect there are a lot of assumptions even with these 4.
>> Just what are the security assumptions and guarantees here?
Note that VDUSE is not the only device that may suffer from this,
here're two others:
1) Encrypted VM
2) Smart NICs
> The attack surface from a virtio device is limited with IOMMU enabled.
> It should be able to avoid security risk if we can validate all data
> such as config space and used length from device in device driver.
>
>> E.g. it seems pretty clear that exposing a malformed FS
>> to a random kernel config can cause untold mischief.
>>
>> Things like virtnet_send_command are also an easy way for
>> the device to DOS the kernel.
I think the virtnet_send_command() needs to use interrupt instead of
polling.
Thanks
>> And before you try to add
>> an arbitrary timeout there - please don't,
>> the fix is moving things that must be guaranteed into kernel
>> and making things that are not guaranteed asynchronous.
>> Right now there are some things that happen with locks taken,
>> where if we don't wait for device we lose the ability to report failures
>> to userspace. E.g. all kind of netlink things are like this.
>> One can think of a bunch of ways to address this, this
>> needs to be discussed with the relevant subsystem maintainers.
>>
>>
>> If I were you I would start with one type of device, and as simple one
>> as possible.
>>
> Make sense to me. The virtio-blk device might be a good start. We
> already have some existing interface like NBD to do similar things.
>
>>
>>> When a sysadmin trusts the userspace process enough, it can relax
>>> the limitation with a 'allow_unsafe_device_emulation' module parameter.
>> That's not a great security interface. It's a global module specific knob
>> that just allows any userspace to emulate anything at all.
>> Coming up with a reasonable interface isn't going to be easy.
>> For now maybe just have people patch their kernels if they want to
>> move fast and break things.
>>
> OK. A reasonable interface can be added if we need it in the future.
>
> Thanks,
> Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace
2021-05-25 6:40 ` Jason Wang
@ 2021-05-25 6:48 ` Michael S. Tsirkin
2021-05-25 7:11 ` Jason Wang
0 siblings, 1 reply; 51+ messages in thread
From: Michael S. Tsirkin @ 2021-05-25 6:48 UTC (permalink / raw)
To: Jason Wang
Cc: Yongji Xie, Stefan Hajnoczi, Stefano Garzarella, Parav Pandit,
Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Tue, May 25, 2021 at 02:40:57PM +0800, Jason Wang wrote:
>
> 在 2021/5/20 下午5:06, Yongji Xie 写道:
> > On Thu, May 20, 2021 at 2:06 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > On Mon, May 17, 2021 at 05:55:01PM +0800, Xie Yongji wrote:
> > > > This series introduces a framework, which can be used to implement
> > > > vDPA Devices in a userspace program. The work consist of two parts:
> > > > control path forwarding and data path offloading.
> > > >
> > > > 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 core is mapping dma buffer into VDUSE
> > > > daemon's address space, which can be implemented in different ways
> > > > depending on the vdpa bus to which the vDPA device is attached.
> > > >
> > > > In virtio-vdpa case, we implements a MMU-based on-chip IOMMU driver with
> > > > bounce-buffering mechanism to achieve that. And in vhost-vdpa case, the dma
> > > > buffer is reside in a userspace memory region which can be shared to the
> > > > VDUSE userspace processs via transferring the shmfd.
> > > >
> > > > The details and our user case is shown below:
> > > >
> > > > ------------------------ ------------------------- ----------------------------------------------
> > > > | Container | | QEMU(VM) | | VDUSE daemon |
> > > > | --------- | | ------------------- | | ------------------------- ---------------- |
> > > > | |dev/vdx| | | |/dev/vhost-vdpa-x| | | | vDPA device emulation | | block driver | |
> > > > ------------+----------- -----------+------------ -------------+----------------------+---------
> > > > | | | |
> > > > | | | |
> > > > ------------+---------------------------+----------------------------+----------------------+---------
> > > > | | block device | | vhost device | | vduse driver | | TCP/IP | |
> > > > | -------+-------- --------+-------- -------+-------- -----+---- |
> > > > | | | | | |
> > > > | ----------+---------- ----------+----------- -------+------- | |
> > > > | | virtio-blk driver | | vhost-vdpa driver | | vdpa device | | |
> > > > | ----------+---------- ----------+----------- -------+------- | |
> > > > | | virtio bus | | | |
> > > > | --------+----+----------- | | | |
> > > > | | | | | |
> > > > | ----------+---------- | | | |
> > > > | | virtio-blk device | | | | |
> > > > | ----------+---------- | | | |
> > > > | | | | | |
> > > > | -----------+----------- | | | |
> > > > | | virtio-vdpa driver | | | | |
> > > > | -----------+----------- | | | |
> > > > | | | | vdpa bus | |
> > > > | -----------+----------------------+---------------------------+------------ | |
> > > > | ---+--- |
> > > > -----------------------------------------------------------------------------------------| NIC |------
> > > > ---+---
> > > > |
> > > > ---------+---------
> > > > | Remote Storages |
> > > > -------------------
> > > >
> > > > We make use of it to implement a block device connecting to
> > > > our distributed storage, which can be used both in containers and
> > > > VMs. Thus, we can have an unified technology stack in this two cases.
> > > >
> > > > To test it with null-blk:
> > > >
> > > > $ qemu-storage-daemon \
> > > > --chardev socket,id=charmonitor,path=/tmp/qmp.sock,server,nowait \
> > > > --monitor chardev=charmonitor \
> > > > --blockdev driver=host_device,cache.direct=on,aio=native,filename=/dev/nullb0,node-name=disk0 \
> > > > --export type=vduse-blk,id=test,node-name=disk0,writable=on,name=vduse-null,num-queues=16,queue-size=128
> > > >
> > > > The qemu-storage-daemon can be found at https://github.com/bytedance/qemu/tree/vduse
> > > >
> > > > To make the userspace VDUSE processes such as qemu-storage-daemon able to
> > > > run unprivileged. We did some works on virtio driver to avoid trusting
> > > > device, including:
> > > >
> > > > - validating the device status:
> > > >
> > > > * https://lore.kernel.org/lkml/20210517093428.670-1-xieyongji@bytedance.com/
> > > >
> > > > - validating the used length:
> > > >
> > > > * https://lore.kernel.org/lkml/20210517090836.533-1-xieyongji@bytedance.com/
> > > >
> > > > - validating the device config:
> > > >
> > > > * patch 4 ("virtio-blk: Add validation for block size in config space")
> > > >
> > > > - validating the device response:
> > > >
> > > > * patch 5 ("virtio_scsi: Add validation for residual bytes from response")
> > > >
> > > > Since I'm not sure if I missing something during auditing, especially on some
> > > > virtio device drivers that I'm not familiar with, now we only support emualting
> > > > a few vDPA devices by default, including: virtio-net device, virtio-blk device,
> > > > virtio-scsi device and virtio-fs device. This limitation can help to reduce
> > > > security risks.
> > > I suspect there are a lot of assumptions even with these 4.
> > > Just what are the security assumptions and guarantees here?
>
>
> Note that VDUSE is not the only device that may suffer from this, here're
> two others:
>
> 1) Encrypted VM
Encrypted VMs are generally understood not to be fully
protected from attacks by a malicious hypervisor. For example
a DoS by a hypervisor is currently trivial.
> 2) Smart NICs
More or less the same thing.
>
> > The attack surface from a virtio device is limited with IOMMU enabled.
> > It should be able to avoid security risk if we can validate all data
> > such as config space and used length from device in device driver.
> >
> > > E.g. it seems pretty clear that exposing a malformed FS
> > > to a random kernel config can cause untold mischief.
> > >
> > > Things like virtnet_send_command are also an easy way for
> > > the device to DOS the kernel.
>
>
> I think the virtnet_send_command() needs to use interrupt instead of
> polling.
>
> Thanks
>
>
> > > And before you try to add
> > > an arbitrary timeout there - please don't,
> > > the fix is moving things that must be guaranteed into kernel
> > > and making things that are not guaranteed asynchronous.
> > > Right now there are some things that happen with locks taken,
> > > where if we don't wait for device we lose the ability to report failures
> > > to userspace. E.g. all kind of netlink things are like this.
> > > One can think of a bunch of ways to address this, this
> > > needs to be discussed with the relevant subsystem maintainers.
> > >
> > >
> > > If I were you I would start with one type of device, and as simple one
> > > as possible.
> > >
> > Make sense to me. The virtio-blk device might be a good start. We
> > already have some existing interface like NBD to do similar things.
> >
> > >
> > > > When a sysadmin trusts the userspace process enough, it can relax
> > > > the limitation with a 'allow_unsafe_device_emulation' module parameter.
> > > That's not a great security interface. It's a global module specific knob
> > > that just allows any userspace to emulate anything at all.
> > > Coming up with a reasonable interface isn't going to be easy.
> > > For now maybe just have people patch their kernels if they want to
> > > move fast and break things.
> > >
> > OK. A reasonable interface can be added if we need it in the future.
> >
> > Thanks,
> > Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace
2021-05-25 6:48 ` Michael S. Tsirkin
@ 2021-05-25 7:11 ` Jason Wang
0 siblings, 0 replies; 51+ messages in thread
From: Jason Wang @ 2021-05-25 7:11 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Yongji Xie, Stefan Hajnoczi, Stefano Garzarella, Parav Pandit,
Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Tue, May 25, 2021 at 2:48 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, May 25, 2021 at 02:40:57PM +0800, Jason Wang wrote:
> >
> > 在 2021/5/20 下午5:06, Yongji Xie 写道:
> > > On Thu, May 20, 2021 at 2:06 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > On Mon, May 17, 2021 at 05:55:01PM +0800, Xie Yongji wrote:
> > > > > This series introduces a framework, which can be used to implement
> > > > > vDPA Devices in a userspace program. The work consist of two parts:
> > > > > control path forwarding and data path offloading.
> > > > >
> > > > > 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 core is mapping dma buffer into VDUSE
> > > > > daemon's address space, which can be implemented in different ways
> > > > > depending on the vdpa bus to which the vDPA device is attached.
> > > > >
> > > > > In virtio-vdpa case, we implements a MMU-based on-chip IOMMU driver with
> > > > > bounce-buffering mechanism to achieve that. And in vhost-vdpa case, the dma
> > > > > buffer is reside in a userspace memory region which can be shared to the
> > > > > VDUSE userspace processs via transferring the shmfd.
> > > > >
> > > > > The details and our user case is shown below:
> > > > >
> > > > > ------------------------ ------------------------- ----------------------------------------------
> > > > > | Container | | QEMU(VM) | | VDUSE daemon |
> > > > > | --------- | | ------------------- | | ------------------------- ---------------- |
> > > > > | |dev/vdx| | | |/dev/vhost-vdpa-x| | | | vDPA device emulation | | block driver | |
> > > > > ------------+----------- -----------+------------ -------------+----------------------+---------
> > > > > | | | |
> > > > > | | | |
> > > > > ------------+---------------------------+----------------------------+----------------------+---------
> > > > > | | block device | | vhost device | | vduse driver | | TCP/IP | |
> > > > > | -------+-------- --------+-------- -------+-------- -----+---- |
> > > > > | | | | | |
> > > > > | ----------+---------- ----------+----------- -------+------- | |
> > > > > | | virtio-blk driver | | vhost-vdpa driver | | vdpa device | | |
> > > > > | ----------+---------- ----------+----------- -------+------- | |
> > > > > | | virtio bus | | | |
> > > > > | --------+----+----------- | | | |
> > > > > | | | | | |
> > > > > | ----------+---------- | | | |
> > > > > | | virtio-blk device | | | | |
> > > > > | ----------+---------- | | | |
> > > > > | | | | | |
> > > > > | -----------+----------- | | | |
> > > > > | | virtio-vdpa driver | | | | |
> > > > > | -----------+----------- | | | |
> > > > > | | | | vdpa bus | |
> > > > > | -----------+----------------------+---------------------------+------------ | |
> > > > > | ---+--- |
> > > > > -----------------------------------------------------------------------------------------| NIC |------
> > > > > ---+---
> > > > > |
> > > > > ---------+---------
> > > > > | Remote Storages |
> > > > > -------------------
> > > > >
> > > > > We make use of it to implement a block device connecting to
> > > > > our distributed storage, which can be used both in containers and
> > > > > VMs. Thus, we can have an unified technology stack in this two cases.
> > > > >
> > > > > To test it with null-blk:
> > > > >
> > > > > $ qemu-storage-daemon \
> > > > > --chardev socket,id=charmonitor,path=/tmp/qmp.sock,server,nowait \
> > > > > --monitor chardev=charmonitor \
> > > > > --blockdev driver=host_device,cache.direct=on,aio=native,filename=/dev/nullb0,node-name=disk0 \
> > > > > --export type=vduse-blk,id=test,node-name=disk0,writable=on,name=vduse-null,num-queues=16,queue-size=128
> > > > >
> > > > > The qemu-storage-daemon can be found at https://github.com/bytedance/qemu/tree/vduse
> > > > >
> > > > > To make the userspace VDUSE processes such as qemu-storage-daemon able to
> > > > > run unprivileged. We did some works on virtio driver to avoid trusting
> > > > > device, including:
> > > > >
> > > > > - validating the device status:
> > > > >
> > > > > * https://lore.kernel.org/lkml/20210517093428.670-1-xieyongji@bytedance.com/
> > > > >
> > > > > - validating the used length:
> > > > >
> > > > > * https://lore.kernel.org/lkml/20210517090836.533-1-xieyongji@bytedance.com/
> > > > >
> > > > > - validating the device config:
> > > > >
> > > > > * patch 4 ("virtio-blk: Add validation for block size in config space")
> > > > >
> > > > > - validating the device response:
> > > > >
> > > > > * patch 5 ("virtio_scsi: Add validation for residual bytes from response")
> > > > >
> > > > > Since I'm not sure if I missing something during auditing, especially on some
> > > > > virtio device drivers that I'm not familiar with, now we only support emualting
> > > > > a few vDPA devices by default, including: virtio-net device, virtio-blk device,
> > > > > virtio-scsi device and virtio-fs device. This limitation can help to reduce
> > > > > security risks.
> > > > I suspect there are a lot of assumptions even with these 4.
> > > > Just what are the security assumptions and guarantees here?
> >
> >
> > Note that VDUSE is not the only device that may suffer from this, here're
> > two others:
> >
> > 1) Encrypted VM
>
> Encrypted VMs are generally understood not to be fully
> protected from attacks by a malicious hypervisor. For example
> a DoS by a hypervisor is currently trivial.
Right, but I mainly meant the emulated virtio-net device in the case
of an encrypted VM. We should not leak information to the
device/hypervisor.
>
> > 2) Smart NICs
>
> More or less the same thing.
In my opinion, this is more similar to VDUSE. Without an encrypted VM,
we trust the hypervisor but not the device so DOS from a device should
be eliminated.
Thanks
>
>
> >
> > > The attack surface from a virtio device is limited with IOMMU enabled.
> > > It should be able to avoid security risk if we can validate all data
> > > such as config space and used length from device in device driver.
> > >
> > > > E.g. it seems pretty clear that exposing a malformed FS
> > > > to a random kernel config can cause untold mischief.
> > > >
> > > > Things like virtnet_send_command are also an easy way for
> > > > the device to DOS the kernel.
> >
> >
> > I think the virtnet_send_command() needs to use interrupt instead of
> > polling.
> >
> > Thanks
> >
> >
> > > > And before you try to add
> > > > an arbitrary timeout there - please don't,
> > > > the fix is moving things that must be guaranteed into kernel
> > > > and making things that are not guaranteed asynchronous.
> > > > Right now there are some things that happen with locks taken,
> > > > where if we don't wait for device we lose the ability to report failures
> > > > to userspace. E.g. all kind of netlink things are like this.
> > > > One can think of a bunch of ways to address this, this
> > > > needs to be discussed with the relevant subsystem maintainers.
> > > >
> > > >
> > > > If I were you I would start with one type of device, and as simple one
> > > > as possible.
> > > >
> > > Make sense to me. The virtio-blk device might be a good start. We
> > > already have some existing interface like NBD to do similar things.
> > >
> > > >
> > > > > When a sysadmin trusts the userspace process enough, it can relax
> > > > > the limitation with a 'allow_unsafe_device_emulation' module parameter.
> > > > That's not a great security interface. It's a global module specific knob
> > > > that just allows any userspace to emulate anything at all.
> > > > Coming up with a reasonable interface isn't going to be easy.
> > > > For now maybe just have people patch their kernels if they want to
> > > > move fast and break things.
> > > >
> > > OK. A reasonable interface can be added if we need it in the future.
> > >
> > > Thanks,
> > > Yongji
>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 01/12] iova: Export alloc_iova_fast()
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
0 siblings, 1 reply; 51+ messages in thread
From: Jason Wang @ 2021-05-26 2:36 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
在 2021/5/17 下午5:55, Xie Yongji 写道:
> Export alloc_iova_fast() so that some modules can use it
> to improve iova allocation efficiency.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> drivers/iommu/iova.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index e6e2fa85271c..317eef64ffef 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -450,6 +450,7 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long size,
>
> return new_iova->pfn_lo;
> }
> +EXPORT_SYMBOL_GPL(alloc_iova_fast);
>
> /**
> * free_iova_fast - free iova pfn range into rcache
Interesting, do we need export free_iova_fast() as well?
Thanks
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 05/12] virtio_scsi: Add validation for residual bytes from response
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
0 siblings, 0 replies; 51+ messages in thread
From: Jason Wang @ 2021-05-26 2:41 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
在 2021/5/17 下午5:55, Xie Yongji 写道:
> This ensures that the residual bytes in response (might come
> from an untrusted device) will not exceed the data buffer length.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> drivers/scsi/virtio_scsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index efcaf0674c8d..ad7d8cecec32 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -97,7 +97,7 @@ static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device *vdev)
> static void virtscsi_compute_resid(struct scsi_cmnd *sc, u32 resid)
> {
> if (resid)
> - scsi_set_resid(sc, resid);
> + scsi_set_resid(sc, min(resid, scsi_bufflen(sc)));
> }
>
> /*
Acked-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 01/12] iova: Export alloc_iova_fast()
2021-05-26 2:36 ` Jason Wang
@ 2021-05-26 2:43 ` Yongji Xie
0 siblings, 0 replies; 51+ messages in thread
From: Yongji Xie @ 2021-05-26 2:43 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Wed, May 26, 2021 at 10:36 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/5/17 下午5:55, Xie Yongji 写道:
> > Export alloc_iova_fast() so that some modules can use it
> > to improve iova allocation efficiency.
> >
> > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > ---
> > drivers/iommu/iova.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> > index e6e2fa85271c..317eef64ffef 100644
> > --- a/drivers/iommu/iova.c
> > +++ b/drivers/iommu/iova.c
> > @@ -450,6 +450,7 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long size,
> >
> > return new_iova->pfn_lo;
> > }
> > +EXPORT_SYMBOL_GPL(alloc_iova_fast);
> >
> > /**
> > * free_iova_fast - free iova pfn range into rcache
>
>
> Interesting, do we need export free_iova_fast() as well?
>
Oh, yes. I missed this commit 6e1ea50a06 ("iommu: Stop exporting
free_iova_fast()"). Will rebase on the newest kernel tree.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
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-27 4:12 ` Jason Wang
2021-05-27 4:57 ` Yongji Xie
2021-05-31 4:56 ` Greg KH
2 siblings, 1 reply; 51+ messages in thread
From: Jason Wang @ 2021-05-27 4:12 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro
Cc: virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
在 2021/5/17 下午5:55, Xie Yongji 写道:
> +
> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> + struct vduse_dev_msg *msg)
> +{
> + init_waitqueue_head(&msg->waitq);
> + spin_lock(&dev->msg_lock);
> + vduse_enqueue_msg(&dev->send_list, msg);
> + wake_up(&dev->waitq);
> + spin_unlock(&dev->msg_lock);
> + wait_event_killable(msg->waitq, msg->completed);
What happens if the userspace(malicous) doesn't give a response forever?
It looks like a DOS. If yes, we need to consider a way to fix that.
Thanks
> + spin_lock(&dev->msg_lock);
> + if (!msg->completed) {
> + list_del(&msg->list);
> + msg->resp.result = VDUSE_REQUEST_FAILED;
> + }
> + spin_unlock(&dev->msg_lock);
> +
> + return (msg->resp.result == VDUSE_REQUEST_OK) ? 0 : -1;
> +}
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 4:12 ` Jason Wang
@ 2021-05-27 4:57 ` Yongji Xie
2021-05-27 5:00 ` Jason Wang
0 siblings, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-27 4:57 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/5/17 下午5:55, Xie Yongji 写道:
> > +
> > +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> > + struct vduse_dev_msg *msg)
> > +{
> > + init_waitqueue_head(&msg->waitq);
> > + spin_lock(&dev->msg_lock);
> > + vduse_enqueue_msg(&dev->send_list, msg);
> > + wake_up(&dev->waitq);
> > + spin_unlock(&dev->msg_lock);
> > + wait_event_killable(msg->waitq, msg->completed);
>
>
> What happens if the userspace(malicous) doesn't give a response forever?
>
> It looks like a DOS. If yes, we need to consider a way to fix that.
>
How about using wait_event_killable_timeout() instead?
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 4:57 ` Yongji Xie
@ 2021-05-27 5:00 ` Jason Wang
2021-05-27 5:08 ` Yongji Xie
0 siblings, 1 reply; 51+ messages in thread
From: Jason Wang @ 2021-05-27 5:00 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
在 2021/5/27 下午12:57, Yongji Xie 写道:
> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
>>> +
>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
>>> + struct vduse_dev_msg *msg)
>>> +{
>>> + init_waitqueue_head(&msg->waitq);
>>> + spin_lock(&dev->msg_lock);
>>> + vduse_enqueue_msg(&dev->send_list, msg);
>>> + wake_up(&dev->waitq);
>>> + spin_unlock(&dev->msg_lock);
>>> + wait_event_killable(msg->waitq, msg->completed);
>>
>> What happens if the userspace(malicous) doesn't give a response forever?
>>
>> It looks like a DOS. If yes, we need to consider a way to fix that.
>>
> How about using wait_event_killable_timeout() instead?
Probably, and then we need choose a suitable timeout and more important,
need to report the failure to virtio.
Thanks
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 5:00 ` Jason Wang
@ 2021-05-27 5:08 ` Yongji Xie
2021-05-27 5:40 ` Jason Wang
0 siblings, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-27 5:08 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/5/27 下午12:57, Yongji Xie 写道:
> > On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >> 在 2021/5/17 下午5:55, Xie Yongji 写道:
> >>> +
> >>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> >>> + struct vduse_dev_msg *msg)
> >>> +{
> >>> + init_waitqueue_head(&msg->waitq);
> >>> + spin_lock(&dev->msg_lock);
> >>> + vduse_enqueue_msg(&dev->send_list, msg);
> >>> + wake_up(&dev->waitq);
> >>> + spin_unlock(&dev->msg_lock);
> >>> + wait_event_killable(msg->waitq, msg->completed);
> >>
> >> What happens if the userspace(malicous) doesn't give a response forever?
> >>
> >> It looks like a DOS. If yes, we need to consider a way to fix that.
> >>
> > How about using wait_event_killable_timeout() instead?
>
>
> Probably, and then we need choose a suitable timeout and more important,
> need to report the failure to virtio.
>
Makes sense to me. But it looks like some
vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
return value. Now I add a WARN_ON() for the failure. Do you mean we
need to add some change for virtio core to handle the failure?
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 5:08 ` Yongji Xie
@ 2021-05-27 5:40 ` Jason Wang
2021-05-27 7:34 ` Yongji Xie
0 siblings, 1 reply; 51+ messages in thread
From: Jason Wang @ 2021-05-27 5:40 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
在 2021/5/27 下午1:08, Yongji Xie 写道:
> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
>>>>> +
>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
>>>>> + struct vduse_dev_msg *msg)
>>>>> +{
>>>>> + init_waitqueue_head(&msg->waitq);
>>>>> + spin_lock(&dev->msg_lock);
>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
>>>>> + wake_up(&dev->waitq);
>>>>> + spin_unlock(&dev->msg_lock);
>>>>> + wait_event_killable(msg->waitq, msg->completed);
>>>> What happens if the userspace(malicous) doesn't give a response forever?
>>>>
>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
>>>>
>>> How about using wait_event_killable_timeout() instead?
>>
>> Probably, and then we need choose a suitable timeout and more important,
>> need to report the failure to virtio.
>>
> Makes sense to me. But it looks like some
> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
> return value. Now I add a WARN_ON() for the failure. Do you mean we
> need to add some change for virtio core to handle the failure?
Maybe, but I'm not sure how hard we can do that.
We had NEEDS_RESET but it looks we don't implement it.
Or a rough idea is that maybe need some relaxing to be coupled loosely
with userspace. E.g the device (control path) is implemented in the
kernel but the datapath is implemented in the userspace like TUN/TAP.
Thanks
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 5:40 ` Jason Wang
@ 2021-05-27 7:34 ` Yongji Xie
2021-05-27 8:41 ` Jason Wang
0 siblings, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-27 7:34 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/5/27 下午1:08, Yongji Xie 写道:
> > On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >> 在 2021/5/27 下午12:57, Yongji Xie 写道:
> >>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
> >>>>> +
> >>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> >>>>> + struct vduse_dev_msg *msg)
> >>>>> +{
> >>>>> + init_waitqueue_head(&msg->waitq);
> >>>>> + spin_lock(&dev->msg_lock);
> >>>>> + vduse_enqueue_msg(&dev->send_list, msg);
> >>>>> + wake_up(&dev->waitq);
> >>>>> + spin_unlock(&dev->msg_lock);
> >>>>> + wait_event_killable(msg->waitq, msg->completed);
> >>>> What happens if the userspace(malicous) doesn't give a response forever?
> >>>>
> >>>> It looks like a DOS. If yes, we need to consider a way to fix that.
> >>>>
> >>> How about using wait_event_killable_timeout() instead?
> >>
> >> Probably, and then we need choose a suitable timeout and more important,
> >> need to report the failure to virtio.
> >>
> > Makes sense to me. But it looks like some
> > vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
> > return value. Now I add a WARN_ON() for the failure. Do you mean we
> > need to add some change for virtio core to handle the failure?
>
>
> Maybe, but I'm not sure how hard we can do that.
>
We need to change all virtio device drivers in this way.
> We had NEEDS_RESET but it looks we don't implement it.
>
Could it handle the failure of get_feature() and get/set_config()?
> Or a rough idea is that maybe need some relaxing to be coupled loosely
> with userspace. E.g the device (control path) is implemented in the
> kernel but the datapath is implemented in the userspace like TUN/TAP.
>
I think it can work for most cases. One problem is that the set_config
might change the behavior of the data path at runtime, e.g.
virtnet_set_mac_address() in the virtio-net driver and
cache_type_store() in the virtio-blk driver. Not sure if this path is
able to return before the datapath is aware of this change.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 7:34 ` Yongji Xie
@ 2021-05-27 8:41 ` Jason Wang
2021-05-27 8:43 ` Jason Wang
2021-05-27 13:17 ` Yongji Xie
0 siblings, 2 replies; 51+ messages in thread
From: Jason Wang @ 2021-05-27 8:41 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
在 2021/5/27 下午3:34, Yongji Xie 写道:
> On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/5/27 下午1:08, Yongji Xie 写道:
>>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com> wrote:
>>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
>>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
>>>>>>> +
>>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
>>>>>>> + struct vduse_dev_msg *msg)
>>>>>>> +{
>>>>>>> + init_waitqueue_head(&msg->waitq);
>>>>>>> + spin_lock(&dev->msg_lock);
>>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
>>>>>>> + wake_up(&dev->waitq);
>>>>>>> + spin_unlock(&dev->msg_lock);
>>>>>>> + wait_event_killable(msg->waitq, msg->completed);
>>>>>> What happens if the userspace(malicous) doesn't give a response forever?
>>>>>>
>>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
>>>>>>
>>>>> How about using wait_event_killable_timeout() instead?
>>>> Probably, and then we need choose a suitable timeout and more important,
>>>> need to report the failure to virtio.
>>>>
>>> Makes sense to me. But it looks like some
>>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
>>> return value. Now I add a WARN_ON() for the failure. Do you mean we
>>> need to add some change for virtio core to handle the failure?
>>
>> Maybe, but I'm not sure how hard we can do that.
>>
> We need to change all virtio device drivers in this way.
Probably.
>
>> We had NEEDS_RESET but it looks we don't implement it.
>>
> Could it handle the failure of get_feature() and get/set_config()?
Looks not:
"
The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
that a reset is needed. If DRIVER_OK is set, after it sets
DEVICE_NEEDS_RESET, the device MUST send a device configuration change
notification to the driver.
"
This looks implies that NEEDS_RESET may only work after device is
probed. But in the current design, even the reset() is not reliable.
>
>> Or a rough idea is that maybe need some relaxing to be coupled loosely
>> with userspace. E.g the device (control path) is implemented in the
>> kernel but the datapath is implemented in the userspace like TUN/TAP.
>>
> I think it can work for most cases. One problem is that the set_config
> might change the behavior of the data path at runtime, e.g.
> virtnet_set_mac_address() in the virtio-net driver and
> cache_type_store() in the virtio-blk driver. Not sure if this path is
> able to return before the datapath is aware of this change.
Good point.
But set_config() should be rare:
E.g in the case of virtio-net with VERSION_1, config space is read only,
and it was set via control vq.
For block, we can
1) start from without WCE or
2) we add a config change notification to userspace or
3) extend the spec to use vq instead of config space
Thanks
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 8:41 ` Jason Wang
@ 2021-05-27 8:43 ` Jason Wang
2021-05-27 10:14 ` Yongji Xie
2021-05-27 13:17 ` Yongji Xie
1 sibling, 1 reply; 51+ messages in thread
From: Jason Wang @ 2021-05-27 8:43 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
在 2021/5/27 下午4:41, Jason Wang 写道:
>
> 在 2021/5/27 下午3:34, Yongji Xie 写道:
>> On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
>>>
>>> 在 2021/5/27 下午1:08, Yongji Xie 写道:
>>>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com>
>>>> wrote:
>>>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
>>>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com>
>>>>>> wrote:
>>>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
>>>>>>>> +
>>>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
>>>>>>>> + struct vduse_dev_msg *msg)
>>>>>>>> +{
>>>>>>>> + init_waitqueue_head(&msg->waitq);
>>>>>>>> + spin_lock(&dev->msg_lock);
>>>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
>>>>>>>> + wake_up(&dev->waitq);
>>>>>>>> + spin_unlock(&dev->msg_lock);
>>>>>>>> + wait_event_killable(msg->waitq, msg->completed);
>>>>>>> What happens if the userspace(malicous) doesn't give a response
>>>>>>> forever?
>>>>>>>
>>>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
>>>>>>>
>>>>>> How about using wait_event_killable_timeout() instead?
>>>>> Probably, and then we need choose a suitable timeout and more
>>>>> important,
>>>>> need to report the failure to virtio.
>>>>>
>>>> Makes sense to me. But it looks like some
>>>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
>>>> return value. Now I add a WARN_ON() for the failure. Do you mean we
>>>> need to add some change for virtio core to handle the failure?
>>>
>>> Maybe, but I'm not sure how hard we can do that.
>>>
>> We need to change all virtio device drivers in this way.
>
>
> Probably.
>
>
>>
>>> We had NEEDS_RESET but it looks we don't implement it.
>>>
>> Could it handle the failure of get_feature() and get/set_config()?
>
>
> Looks not:
>
> "
>
> The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
> that a reset is needed. If DRIVER_OK is set, after it sets
> DEVICE_NEEDS_RESET, the device MUST send a device configuration change
> notification to the driver.
>
> "
>
> This looks implies that NEEDS_RESET may only work after device is
> probed. But in the current design, even the reset() is not reliable.
>
>
>>
>>> Or a rough idea is that maybe need some relaxing to be coupled loosely
>>> with userspace. E.g the device (control path) is implemented in the
>>> kernel but the datapath is implemented in the userspace like TUN/TAP.
>>>
>> I think it can work for most cases. One problem is that the set_config
>> might change the behavior of the data path at runtime, e.g.
>> virtnet_set_mac_address() in the virtio-net driver and
>> cache_type_store() in the virtio-blk driver. Not sure if this path is
>> able to return before the datapath is aware of this change.
>
>
> Good point.
>
> But set_config() should be rare:
>
> E.g in the case of virtio-net with VERSION_1, config space is read
> only, and it was set via control vq.
>
> For block, we can
>
> 1) start from without WCE or
> 2) we add a config change notification to userspace or
> 3) extend the spec to use vq instead of config space
>
> Thanks
Another thing if we want to go this way:
We need find a way to terminate the data path from the kernel side, to
implement to reset semantic.
Thanks
>
>
>>
>> Thanks,
>> Yongji
>>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 8:43 ` Jason Wang
@ 2021-05-27 10:14 ` Yongji Xie
2021-05-28 1:33 ` Jason Wang
0 siblings, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-27 10:14 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Thu, May 27, 2021 at 4:43 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/5/27 下午4:41, Jason Wang 写道:
> >
> > 在 2021/5/27 下午3:34, Yongji Xie 写道:
> >> On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>
> >>> 在 2021/5/27 下午1:08, Yongji Xie 写道:
> >>>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com>
> >>>> wrote:
> >>>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
> >>>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com>
> >>>>>> wrote:
> >>>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
> >>>>>>>> +
> >>>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> >>>>>>>> + struct vduse_dev_msg *msg)
> >>>>>>>> +{
> >>>>>>>> + init_waitqueue_head(&msg->waitq);
> >>>>>>>> + spin_lock(&dev->msg_lock);
> >>>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
> >>>>>>>> + wake_up(&dev->waitq);
> >>>>>>>> + spin_unlock(&dev->msg_lock);
> >>>>>>>> + wait_event_killable(msg->waitq, msg->completed);
> >>>>>>> What happens if the userspace(malicous) doesn't give a response
> >>>>>>> forever?
> >>>>>>>
> >>>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
> >>>>>>>
> >>>>>> How about using wait_event_killable_timeout() instead?
> >>>>> Probably, and then we need choose a suitable timeout and more
> >>>>> important,
> >>>>> need to report the failure to virtio.
> >>>>>
> >>>> Makes sense to me. But it looks like some
> >>>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
> >>>> return value. Now I add a WARN_ON() for the failure. Do you mean we
> >>>> need to add some change for virtio core to handle the failure?
> >>>
> >>> Maybe, but I'm not sure how hard we can do that.
> >>>
> >> We need to change all virtio device drivers in this way.
> >
> >
> > Probably.
> >
> >
> >>
> >>> We had NEEDS_RESET but it looks we don't implement it.
> >>>
> >> Could it handle the failure of get_feature() and get/set_config()?
> >
> >
> > Looks not:
> >
> > "
> >
> > The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
> > that a reset is needed. If DRIVER_OK is set, after it sets
> > DEVICE_NEEDS_RESET, the device MUST send a device configuration change
> > notification to the driver.
> >
> > "
> >
> > This looks implies that NEEDS_RESET may only work after device is
> > probed. But in the current design, even the reset() is not reliable.
> >
> >
> >>
> >>> Or a rough idea is that maybe need some relaxing to be coupled loosely
> >>> with userspace. E.g the device (control path) is implemented in the
> >>> kernel but the datapath is implemented in the userspace like TUN/TAP.
> >>>
> >> I think it can work for most cases. One problem is that the set_config
> >> might change the behavior of the data path at runtime, e.g.
> >> virtnet_set_mac_address() in the virtio-net driver and
> >> cache_type_store() in the virtio-blk driver. Not sure if this path is
> >> able to return before the datapath is aware of this change.
> >
> >
> > Good point.
> >
> > But set_config() should be rare:
> >
> > E.g in the case of virtio-net with VERSION_1, config space is read
> > only, and it was set via control vq.
> >
> > For block, we can
> >
> > 1) start from without WCE or
> > 2) we add a config change notification to userspace or
> > 3) extend the spec to use vq instead of config space
> >
> > Thanks
>
>
> Another thing if we want to go this way:
>
> We need find a way to terminate the data path from the kernel side, to
> implement to reset semantic.
>
Do you mean terminate the data path in vdpa_reset(). Is it ok to just
notify userspace to stop data path asynchronously? Userspace should
not be able to do any I/O at that time because the iotlb mapping is
already removed.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 8:41 ` Jason Wang
2021-05-27 8:43 ` Jason Wang
@ 2021-05-27 13:17 ` Yongji Xie
2021-05-28 2:31 ` Jason Wang
1 sibling, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-27 13:17 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Thu, May 27, 2021 at 4:41 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/5/27 下午3:34, Yongji Xie 写道:
> > On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >> 在 2021/5/27 下午1:08, Yongji Xie 写道:
> >>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
> >>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
> >>>>>>> +
> >>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> >>>>>>> + struct vduse_dev_msg *msg)
> >>>>>>> +{
> >>>>>>> + init_waitqueue_head(&msg->waitq);
> >>>>>>> + spin_lock(&dev->msg_lock);
> >>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
> >>>>>>> + wake_up(&dev->waitq);
> >>>>>>> + spin_unlock(&dev->msg_lock);
> >>>>>>> + wait_event_killable(msg->waitq, msg->completed);
> >>>>>> What happens if the userspace(malicous) doesn't give a response forever?
> >>>>>>
> >>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
> >>>>>>
> >>>>> How about using wait_event_killable_timeout() instead?
> >>>> Probably, and then we need choose a suitable timeout and more important,
> >>>> need to report the failure to virtio.
> >>>>
> >>> Makes sense to me. But it looks like some
> >>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
> >>> return value. Now I add a WARN_ON() for the failure. Do you mean we
> >>> need to add some change for virtio core to handle the failure?
> >>
> >> Maybe, but I'm not sure how hard we can do that.
> >>
> > We need to change all virtio device drivers in this way.
>
>
> Probably.
>
>
> >
> >> We had NEEDS_RESET but it looks we don't implement it.
> >>
> > Could it handle the failure of get_feature() and get/set_config()?
>
>
> Looks not:
>
> "
>
> The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
> that a reset is needed. If DRIVER_OK is set, after it sets
> DEVICE_NEEDS_RESET, the device MUST send a device configuration change
> notification to the driver.
>
> "
>
> This looks implies that NEEDS_RESET may only work after device is
> probed. But in the current design, even the reset() is not reliable.
>
>
> >
> >> Or a rough idea is that maybe need some relaxing to be coupled loosely
> >> with userspace. E.g the device (control path) is implemented in the
> >> kernel but the datapath is implemented in the userspace like TUN/TAP.
> >>
> > I think it can work for most cases. One problem is that the set_config
> > might change the behavior of the data path at runtime, e.g.
> > virtnet_set_mac_address() in the virtio-net driver and
> > cache_type_store() in the virtio-blk driver. Not sure if this path is
> > able to return before the datapath is aware of this change.
>
>
> Good point.
>
> But set_config() should be rare:
>
> E.g in the case of virtio-net with VERSION_1, config space is read only,
> and it was set via control vq.
>
> For block, we can
>
> 1) start from without WCE or
> 2) we add a config change notification to userspace or
I prefer this way. And I think we also need to do similar things for
set/get_vq_state().
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 10:14 ` Yongji Xie
@ 2021-05-28 1:33 ` Jason Wang
2021-05-28 3:54 ` Yongji Xie
0 siblings, 1 reply; 51+ messages in thread
From: Jason Wang @ 2021-05-28 1:33 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
在 2021/5/27 下午6:14, Yongji Xie 写道:
> On Thu, May 27, 2021 at 4:43 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/5/27 下午4:41, Jason Wang 写道:
>>> 在 2021/5/27 下午3:34, Yongji Xie 写道:
>>>> On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>> 在 2021/5/27 下午1:08, Yongji Xie 写道:
>>>>>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com>
>>>>>> wrote:
>>>>>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
>>>>>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com>
>>>>>>>> wrote:
>>>>>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
>>>>>>>>>> +
>>>>>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
>>>>>>>>>> + struct vduse_dev_msg *msg)
>>>>>>>>>> +{
>>>>>>>>>> + init_waitqueue_head(&msg->waitq);
>>>>>>>>>> + spin_lock(&dev->msg_lock);
>>>>>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
>>>>>>>>>> + wake_up(&dev->waitq);
>>>>>>>>>> + spin_unlock(&dev->msg_lock);
>>>>>>>>>> + wait_event_killable(msg->waitq, msg->completed);
>>>>>>>>> What happens if the userspace(malicous) doesn't give a response
>>>>>>>>> forever?
>>>>>>>>>
>>>>>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
>>>>>>>>>
>>>>>>>> How about using wait_event_killable_timeout() instead?
>>>>>>> Probably, and then we need choose a suitable timeout and more
>>>>>>> important,
>>>>>>> need to report the failure to virtio.
>>>>>>>
>>>>>> Makes sense to me. But it looks like some
>>>>>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
>>>>>> return value. Now I add a WARN_ON() for the failure. Do you mean we
>>>>>> need to add some change for virtio core to handle the failure?
>>>>> Maybe, but I'm not sure how hard we can do that.
>>>>>
>>>> We need to change all virtio device drivers in this way.
>>>
>>> Probably.
>>>
>>>
>>>>> We had NEEDS_RESET but it looks we don't implement it.
>>>>>
>>>> Could it handle the failure of get_feature() and get/set_config()?
>>>
>>> Looks not:
>>>
>>> "
>>>
>>> The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
>>> that a reset is needed. If DRIVER_OK is set, after it sets
>>> DEVICE_NEEDS_RESET, the device MUST send a device configuration change
>>> notification to the driver.
>>>
>>> "
>>>
>>> This looks implies that NEEDS_RESET may only work after device is
>>> probed. But in the current design, even the reset() is not reliable.
>>>
>>>
>>>>> Or a rough idea is that maybe need some relaxing to be coupled loosely
>>>>> with userspace. E.g the device (control path) is implemented in the
>>>>> kernel but the datapath is implemented in the userspace like TUN/TAP.
>>>>>
>>>> I think it can work for most cases. One problem is that the set_config
>>>> might change the behavior of the data path at runtime, e.g.
>>>> virtnet_set_mac_address() in the virtio-net driver and
>>>> cache_type_store() in the virtio-blk driver. Not sure if this path is
>>>> able to return before the datapath is aware of this change.
>>>
>>> Good point.
>>>
>>> But set_config() should be rare:
>>>
>>> E.g in the case of virtio-net with VERSION_1, config space is read
>>> only, and it was set via control vq.
>>>
>>> For block, we can
>>>
>>> 1) start from without WCE or
>>> 2) we add a config change notification to userspace or
>>> 3) extend the spec to use vq instead of config space
>>>
>>> Thanks
>>
>> Another thing if we want to go this way:
>>
>> We need find a way to terminate the data path from the kernel side, to
>> implement to reset semantic.
>>
> Do you mean terminate the data path in vdpa_reset().
Yes.
> Is it ok to just
> notify userspace to stop data path asynchronously?
For well-behaved userspace, yes but no for buggy or malicious ones.
I had an idea, how about terminate IOTLB in this case? Then we're in
fact turn datapath off.
Thanks
> Userspace should
> not be able to do any I/O at that time because the iotlb mapping is
> already removed.
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-27 13:17 ` Yongji Xie
@ 2021-05-28 2:31 ` Jason Wang
2021-05-31 4:27 ` Yongji Xie
0 siblings, 1 reply; 51+ messages in thread
From: Jason Wang @ 2021-05-28 2:31 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
在 2021/5/27 下午9:17, Yongji Xie 写道:
> On Thu, May 27, 2021 at 4:41 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/5/27 下午3:34, Yongji Xie 写道:
>>> On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
>>>> 在 2021/5/27 下午1:08, Yongji Xie 写道:
>>>>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
>>>>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
>>>>>>>>> +
>>>>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
>>>>>>>>> + struct vduse_dev_msg *msg)
>>>>>>>>> +{
>>>>>>>>> + init_waitqueue_head(&msg->waitq);
>>>>>>>>> + spin_lock(&dev->msg_lock);
>>>>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
>>>>>>>>> + wake_up(&dev->waitq);
>>>>>>>>> + spin_unlock(&dev->msg_lock);
>>>>>>>>> + wait_event_killable(msg->waitq, msg->completed);
>>>>>>>> What happens if the userspace(malicous) doesn't give a response forever?
>>>>>>>>
>>>>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
>>>>>>>>
>>>>>>> How about using wait_event_killable_timeout() instead?
>>>>>> Probably, and then we need choose a suitable timeout and more important,
>>>>>> need to report the failure to virtio.
>>>>>>
>>>>> Makes sense to me. But it looks like some
>>>>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
>>>>> return value. Now I add a WARN_ON() for the failure. Do you mean we
>>>>> need to add some change for virtio core to handle the failure?
>>>> Maybe, but I'm not sure how hard we can do that.
>>>>
>>> We need to change all virtio device drivers in this way.
>>
>> Probably.
>>
>>
>>>> We had NEEDS_RESET but it looks we don't implement it.
>>>>
>>> Could it handle the failure of get_feature() and get/set_config()?
>>
>> Looks not:
>>
>> "
>>
>> The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
>> that a reset is needed. If DRIVER_OK is set, after it sets
>> DEVICE_NEEDS_RESET, the device MUST send a device configuration change
>> notification to the driver.
>>
>> "
>>
>> This looks implies that NEEDS_RESET may only work after device is
>> probed. But in the current design, even the reset() is not reliable.
>>
>>
>>>> Or a rough idea is that maybe need some relaxing to be coupled loosely
>>>> with userspace. E.g the device (control path) is implemented in the
>>>> kernel but the datapath is implemented in the userspace like TUN/TAP.
>>>>
>>> I think it can work for most cases. One problem is that the set_config
>>> might change the behavior of the data path at runtime, e.g.
>>> virtnet_set_mac_address() in the virtio-net driver and
>>> cache_type_store() in the virtio-blk driver. Not sure if this path is
>>> able to return before the datapath is aware of this change.
>>
>> Good point.
>>
>> But set_config() should be rare:
>>
>> E.g in the case of virtio-net with VERSION_1, config space is read only,
>> and it was set via control vq.
>>
>> For block, we can
>>
>> 1) start from without WCE or
>> 2) we add a config change notification to userspace or
> I prefer this way. And I think we also need to do similar things for
> set/get_vq_state().
Yes, I agree.
Thanks
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-28 1:33 ` Jason Wang
@ 2021-05-28 3:54 ` Yongji Xie
2021-05-28 6:38 ` Jason Wang
0 siblings, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-28 3:54 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Fri, May 28, 2021 at 9:33 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/5/27 下午6:14, Yongji Xie 写道:
> > On Thu, May 27, 2021 at 4:43 PM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >> 在 2021/5/27 下午4:41, Jason Wang 写道:
> >>> 在 2021/5/27 下午3:34, Yongji Xie 写道:
> >>>> On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>>> 在 2021/5/27 下午1:08, Yongji Xie 写道:
> >>>>>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com>
> >>>>>> wrote:
> >>>>>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
> >>>>>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com>
> >>>>>>>> wrote:
> >>>>>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
> >>>>>>>>>> +
> >>>>>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> >>>>>>>>>> + struct vduse_dev_msg *msg)
> >>>>>>>>>> +{
> >>>>>>>>>> + init_waitqueue_head(&msg->waitq);
> >>>>>>>>>> + spin_lock(&dev->msg_lock);
> >>>>>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
> >>>>>>>>>> + wake_up(&dev->waitq);
> >>>>>>>>>> + spin_unlock(&dev->msg_lock);
> >>>>>>>>>> + wait_event_killable(msg->waitq, msg->completed);
> >>>>>>>>> What happens if the userspace(malicous) doesn't give a response
> >>>>>>>>> forever?
> >>>>>>>>>
> >>>>>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
> >>>>>>>>>
> >>>>>>>> How about using wait_event_killable_timeout() instead?
> >>>>>>> Probably, and then we need choose a suitable timeout and more
> >>>>>>> important,
> >>>>>>> need to report the failure to virtio.
> >>>>>>>
> >>>>>> Makes sense to me. But it looks like some
> >>>>>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
> >>>>>> return value. Now I add a WARN_ON() for the failure. Do you mean we
> >>>>>> need to add some change for virtio core to handle the failure?
> >>>>> Maybe, but I'm not sure how hard we can do that.
> >>>>>
> >>>> We need to change all virtio device drivers in this way.
> >>>
> >>> Probably.
> >>>
> >>>
> >>>>> We had NEEDS_RESET but it looks we don't implement it.
> >>>>>
> >>>> Could it handle the failure of get_feature() and get/set_config()?
> >>>
> >>> Looks not:
> >>>
> >>> "
> >>>
> >>> The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
> >>> that a reset is needed. If DRIVER_OK is set, after it sets
> >>> DEVICE_NEEDS_RESET, the device MUST send a device configuration change
> >>> notification to the driver.
> >>>
> >>> "
> >>>
> >>> This looks implies that NEEDS_RESET may only work after device is
> >>> probed. But in the current design, even the reset() is not reliable.
> >>>
> >>>
> >>>>> Or a rough idea is that maybe need some relaxing to be coupled loosely
> >>>>> with userspace. E.g the device (control path) is implemented in the
> >>>>> kernel but the datapath is implemented in the userspace like TUN/TAP.
> >>>>>
> >>>> I think it can work for most cases. One problem is that the set_config
> >>>> might change the behavior of the data path at runtime, e.g.
> >>>> virtnet_set_mac_address() in the virtio-net driver and
> >>>> cache_type_store() in the virtio-blk driver. Not sure if this path is
> >>>> able to return before the datapath is aware of this change.
> >>>
> >>> Good point.
> >>>
> >>> But set_config() should be rare:
> >>>
> >>> E.g in the case of virtio-net with VERSION_1, config space is read
> >>> only, and it was set via control vq.
> >>>
> >>> For block, we can
> >>>
> >>> 1) start from without WCE or
> >>> 2) we add a config change notification to userspace or
> >>> 3) extend the spec to use vq instead of config space
> >>>
> >>> Thanks
> >>
> >> Another thing if we want to go this way:
> >>
> >> We need find a way to terminate the data path from the kernel side, to
> >> implement to reset semantic.
> >>
> > Do you mean terminate the data path in vdpa_reset().
>
>
> Yes.
>
>
> > Is it ok to just
> > notify userspace to stop data path asynchronously?
>
>
> For well-behaved userspace, yes but no for buggy or malicious ones.
>
But the buggy or malicious daemons can't do anything if my
understanding is correct.
> I had an idea, how about terminate IOTLB in this case? Then we're in
> fact turn datapath off.
>
Sorry, I didn't get your point here. What do you mean by terminating
IOTLB? Remove iotlb mapping? But userspace can still access the mapped
region.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-28 3:54 ` Yongji Xie
@ 2021-05-28 6:38 ` Jason Wang
0 siblings, 0 replies; 51+ messages in thread
From: Jason Wang @ 2021-05-28 6:38 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
在 2021/5/28 上午11:54, Yongji Xie 写道:
> On Fri, May 28, 2021 at 9:33 AM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/5/27 下午6:14, Yongji Xie 写道:
>>> On Thu, May 27, 2021 at 4:43 PM Jason Wang <jasowang@redhat.com> wrote:
>>>> 在 2021/5/27 下午4:41, Jason Wang 写道:
>>>>> 在 2021/5/27 下午3:34, Yongji Xie 写道:
>>>>>> On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>>> 在 2021/5/27 下午1:08, Yongji Xie 写道:
>>>>>>>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com>
>>>>>>>> wrote:
>>>>>>>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
>>>>>>>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
>>>>>>>>>>>> +
>>>>>>>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
>>>>>>>>>>>> + struct vduse_dev_msg *msg)
>>>>>>>>>>>> +{
>>>>>>>>>>>> + init_waitqueue_head(&msg->waitq);
>>>>>>>>>>>> + spin_lock(&dev->msg_lock);
>>>>>>>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
>>>>>>>>>>>> + wake_up(&dev->waitq);
>>>>>>>>>>>> + spin_unlock(&dev->msg_lock);
>>>>>>>>>>>> + wait_event_killable(msg->waitq, msg->completed);
>>>>>>>>>>> What happens if the userspace(malicous) doesn't give a response
>>>>>>>>>>> forever?
>>>>>>>>>>>
>>>>>>>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
>>>>>>>>>>>
>>>>>>>>>> How about using wait_event_killable_timeout() instead?
>>>>>>>>> Probably, and then we need choose a suitable timeout and more
>>>>>>>>> important,
>>>>>>>>> need to report the failure to virtio.
>>>>>>>>>
>>>>>>>> Makes sense to me. But it looks like some
>>>>>>>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
>>>>>>>> return value. Now I add a WARN_ON() for the failure. Do you mean we
>>>>>>>> need to add some change for virtio core to handle the failure?
>>>>>>> Maybe, but I'm not sure how hard we can do that.
>>>>>>>
>>>>>> We need to change all virtio device drivers in this way.
>>>>> Probably.
>>>>>
>>>>>
>>>>>>> We had NEEDS_RESET but it looks we don't implement it.
>>>>>>>
>>>>>> Could it handle the failure of get_feature() and get/set_config()?
>>>>> Looks not:
>>>>>
>>>>> "
>>>>>
>>>>> The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
>>>>> that a reset is needed. If DRIVER_OK is set, after it sets
>>>>> DEVICE_NEEDS_RESET, the device MUST send a device configuration change
>>>>> notification to the driver.
>>>>>
>>>>> "
>>>>>
>>>>> This looks implies that NEEDS_RESET may only work after device is
>>>>> probed. But in the current design, even the reset() is not reliable.
>>>>>
>>>>>
>>>>>>> Or a rough idea is that maybe need some relaxing to be coupled loosely
>>>>>>> with userspace. E.g the device (control path) is implemented in the
>>>>>>> kernel but the datapath is implemented in the userspace like TUN/TAP.
>>>>>>>
>>>>>> I think it can work for most cases. One problem is that the set_config
>>>>>> might change the behavior of the data path at runtime, e.g.
>>>>>> virtnet_set_mac_address() in the virtio-net driver and
>>>>>> cache_type_store() in the virtio-blk driver. Not sure if this path is
>>>>>> able to return before the datapath is aware of this change.
>>>>> Good point.
>>>>>
>>>>> But set_config() should be rare:
>>>>>
>>>>> E.g in the case of virtio-net with VERSION_1, config space is read
>>>>> only, and it was set via control vq.
>>>>>
>>>>> For block, we can
>>>>>
>>>>> 1) start from without WCE or
>>>>> 2) we add a config change notification to userspace or
>>>>> 3) extend the spec to use vq instead of config space
>>>>>
>>>>> Thanks
>>>> Another thing if we want to go this way:
>>>>
>>>> We need find a way to terminate the data path from the kernel side, to
>>>> implement to reset semantic.
>>>>
>>> Do you mean terminate the data path in vdpa_reset().
>>
>> Yes.
>>
>>
>>> Is it ok to just
>>> notify userspace to stop data path asynchronously?
>>
>> For well-behaved userspace, yes but no for buggy or malicious ones.
>>
> But the buggy or malicious daemons can't do anything if my
> understanding is correct.
You're right. I originally thought there can still have bouncing. But
consider we don't do that during fault.
It should be safe.
>
>> I had an idea, how about terminate IOTLB in this case? Then we're in
>> fact turn datapath off.
>>
> Sorry, I didn't get your point here. What do you mean by terminating
> IOTLB?
I meant terminate the bouncing but it looks safe after a second thought :)
Thanks
> Remove iotlb mapping? But userspace can still access the mapped
> region.
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-28 2:31 ` Jason Wang
@ 2021-05-31 4:27 ` Yongji Xie
2021-05-31 4:38 ` Jason Wang
0 siblings, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-31 4:27 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Fri, May 28, 2021 at 10:31 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/5/27 下午9:17, Yongji Xie 写道:
> > On Thu, May 27, 2021 at 4:41 PM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >> 在 2021/5/27 下午3:34, Yongji Xie 写道:
> >>> On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>> 在 2021/5/27 下午1:08, Yongji Xie 写道:
> >>>>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
> >>>>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
> >>>>>>>>> +
> >>>>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> >>>>>>>>> + struct vduse_dev_msg *msg)
> >>>>>>>>> +{
> >>>>>>>>> + init_waitqueue_head(&msg->waitq);
> >>>>>>>>> + spin_lock(&dev->msg_lock);
> >>>>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
> >>>>>>>>> + wake_up(&dev->waitq);
> >>>>>>>>> + spin_unlock(&dev->msg_lock);
> >>>>>>>>> + wait_event_killable(msg->waitq, msg->completed);
> >>>>>>>> What happens if the userspace(malicous) doesn't give a response forever?
> >>>>>>>>
> >>>>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
> >>>>>>>>
> >>>>>>> How about using wait_event_killable_timeout() instead?
> >>>>>> Probably, and then we need choose a suitable timeout and more important,
> >>>>>> need to report the failure to virtio.
> >>>>>>
> >>>>> Makes sense to me. But it looks like some
> >>>>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
> >>>>> return value. Now I add a WARN_ON() for the failure. Do you mean we
> >>>>> need to add some change for virtio core to handle the failure?
> >>>> Maybe, but I'm not sure how hard we can do that.
> >>>>
> >>> We need to change all virtio device drivers in this way.
> >>
> >> Probably.
> >>
> >>
> >>>> We had NEEDS_RESET but it looks we don't implement it.
> >>>>
> >>> Could it handle the failure of get_feature() and get/set_config()?
> >>
> >> Looks not:
> >>
> >> "
> >>
> >> The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
> >> that a reset is needed. If DRIVER_OK is set, after it sets
> >> DEVICE_NEEDS_RESET, the device MUST send a device configuration change
> >> notification to the driver.
> >>
> >> "
> >>
> >> This looks implies that NEEDS_RESET may only work after device is
> >> probed. But in the current design, even the reset() is not reliable.
> >>
> >>
> >>>> Or a rough idea is that maybe need some relaxing to be coupled loosely
> >>>> with userspace. E.g the device (control path) is implemented in the
> >>>> kernel but the datapath is implemented in the userspace like TUN/TAP.
> >>>>
> >>> I think it can work for most cases. One problem is that the set_config
> >>> might change the behavior of the data path at runtime, e.g.
> >>> virtnet_set_mac_address() in the virtio-net driver and
> >>> cache_type_store() in the virtio-blk driver. Not sure if this path is
> >>> able to return before the datapath is aware of this change.
> >>
> >> Good point.
> >>
> >> But set_config() should be rare:
> >>
> >> E.g in the case of virtio-net with VERSION_1, config space is read only,
> >> and it was set via control vq.
> >>
> >> For block, we can
> >>
> >> 1) start from without WCE or
> >> 2) we add a config change notification to userspace or
> > I prefer this way. And I think we also need to do similar things for
> > set/get_vq_state().
>
>
> Yes, I agree.
>
Hi Jason,
Now I'm working on this. But I found the config change notification
must be synchronous in the virtio-blk case, which means the kernel
still needs to wait for the response from userspace in set_config().
Otherwise, some I/Os might still run the old way after we change the
cache_type in sysfs.
The simple ways to solve this problem are:
1. Only support read-only config space, disable WCE as you suggested
2. Add a return value to set_config() and handle the failure only in
virtio-blk driver
3. Print some warnings after timeout since it only affects the
dataplane which is under userspace's control
Any suggestions?
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-31 4:27 ` Yongji Xie
@ 2021-05-31 4:38 ` Jason Wang
2021-05-31 6:24 ` Yongji Xie
0 siblings, 1 reply; 51+ messages in thread
From: Jason Wang @ 2021-05-31 4:38 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
在 2021/5/31 下午12:27, Yongji Xie 写道:
> On Fri, May 28, 2021 at 10:31 AM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/5/27 下午9:17, Yongji Xie 写道:
>>> On Thu, May 27, 2021 at 4:41 PM Jason Wang <jasowang@redhat.com> wrote:
>>>> 在 2021/5/27 下午3:34, Yongji Xie 写道:
>>>>> On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>> 在 2021/5/27 下午1:08, Yongji Xie 写道:
>>>>>>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
>>>>>>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
>>>>>>>>>>> +
>>>>>>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
>>>>>>>>>>> + struct vduse_dev_msg *msg)
>>>>>>>>>>> +{
>>>>>>>>>>> + init_waitqueue_head(&msg->waitq);
>>>>>>>>>>> + spin_lock(&dev->msg_lock);
>>>>>>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
>>>>>>>>>>> + wake_up(&dev->waitq);
>>>>>>>>>>> + spin_unlock(&dev->msg_lock);
>>>>>>>>>>> + wait_event_killable(msg->waitq, msg->completed);
>>>>>>>>>> What happens if the userspace(malicous) doesn't give a response forever?
>>>>>>>>>>
>>>>>>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
>>>>>>>>>>
>>>>>>>>> How about using wait_event_killable_timeout() instead?
>>>>>>>> Probably, and then we need choose a suitable timeout and more important,
>>>>>>>> need to report the failure to virtio.
>>>>>>>>
>>>>>>> Makes sense to me. But it looks like some
>>>>>>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
>>>>>>> return value. Now I add a WARN_ON() for the failure. Do you mean we
>>>>>>> need to add some change for virtio core to handle the failure?
>>>>>> Maybe, but I'm not sure how hard we can do that.
>>>>>>
>>>>> We need to change all virtio device drivers in this way.
>>>> Probably.
>>>>
>>>>
>>>>>> We had NEEDS_RESET but it looks we don't implement it.
>>>>>>
>>>>> Could it handle the failure of get_feature() and get/set_config()?
>>>> Looks not:
>>>>
>>>> "
>>>>
>>>> The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
>>>> that a reset is needed. If DRIVER_OK is set, after it sets
>>>> DEVICE_NEEDS_RESET, the device MUST send a device configuration change
>>>> notification to the driver.
>>>>
>>>> "
>>>>
>>>> This looks implies that NEEDS_RESET may only work after device is
>>>> probed. But in the current design, even the reset() is not reliable.
>>>>
>>>>
>>>>>> Or a rough idea is that maybe need some relaxing to be coupled loosely
>>>>>> with userspace. E.g the device (control path) is implemented in the
>>>>>> kernel but the datapath is implemented in the userspace like TUN/TAP.
>>>>>>
>>>>> I think it can work for most cases. One problem is that the set_config
>>>>> might change the behavior of the data path at runtime, e.g.
>>>>> virtnet_set_mac_address() in the virtio-net driver and
>>>>> cache_type_store() in the virtio-blk driver. Not sure if this path is
>>>>> able to return before the datapath is aware of this change.
>>>> Good point.
>>>>
>>>> But set_config() should be rare:
>>>>
>>>> E.g in the case of virtio-net with VERSION_1, config space is read only,
>>>> and it was set via control vq.
>>>>
>>>> For block, we can
>>>>
>>>> 1) start from without WCE or
>>>> 2) we add a config change notification to userspace or
>>> I prefer this way. And I think we also need to do similar things for
>>> set/get_vq_state().
>>
>> Yes, I agree.
>>
> Hi Jason,
>
> Now I'm working on this. But I found the config change notification
> must be synchronous in the virtio-blk case, which means the kernel
> still needs to wait for the response from userspace in set_config().
> Otherwise, some I/Os might still run the old way after we change the
> cache_type in sysfs.
>
> The simple ways to solve this problem are:
>
> 1. Only support read-only config space, disable WCE as you suggested
> 2. Add a return value to set_config() and handle the failure only in
> virtio-blk driver
> 3. Print some warnings after timeout since it only affects the
> dataplane which is under userspace's control
>
> Any suggestions?
Let's go without WCE first and make VDUSE work first. We can then think
of a solution for WCE on top.
Thanks
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
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-27 4:12 ` Jason Wang
@ 2021-05-31 4:56 ` Greg KH
2021-05-31 6:19 ` Yongji Xie
2 siblings, 1 reply; 51+ messages in thread
From: Greg KH @ 2021-05-31 4:56 UTC (permalink / raw)
To: Xie Yongji
Cc: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
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.
> + 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?
> + 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?
> +};
> +
> +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.
> +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.
> + 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?
> +MODULE_VERSION(DRV_VERSION);
MODULE_VERSION() makes no sense when the code is merged into the kernel
tree, so you can just drop that.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-31 4:56 ` Greg KH
@ 2021-05-31 6:19 ` Yongji Xie
2021-05-31 6:32 ` Greg KH
0 siblings, 1 reply; 51+ messages in thread
From: Yongji Xie @ 2021-05-31 6:19 UTC (permalink / raw)
To: Greg KH
Cc: Michael S. Tsirkin, Jason Wang, Stefan Hajnoczi,
Stefano Garzarella, Parav Pandit, Christoph Hellwig,
Christian Brauner, Randy Dunlap, Matthew Wilcox, Al Viro,
Jens Axboe, bcrl, Jonathan Corbet, Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
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
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-31 4:38 ` Jason Wang
@ 2021-05-31 6:24 ` Yongji Xie
0 siblings, 0 replies; 51+ messages in thread
From: Yongji Xie @ 2021-05-31 6:24 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Mon, May 31, 2021 at 12:39 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/5/31 下午12:27, Yongji Xie 写道:
> > On Fri, May 28, 2021 at 10:31 AM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >> 在 2021/5/27 下午9:17, Yongji Xie 写道:
> >>> On Thu, May 27, 2021 at 4:41 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>> 在 2021/5/27 下午3:34, Yongji Xie 写道:
> >>>>> On Thu, May 27, 2021 at 1:40 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>>>> 在 2021/5/27 下午1:08, Yongji Xie 写道:
> >>>>>>> On Thu, May 27, 2021 at 1:00 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>>>>>> 在 2021/5/27 下午12:57, Yongji Xie 写道:
> >>>>>>>>> On Thu, May 27, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>>>>>>>> 在 2021/5/17 下午5:55, Xie Yongji 写道:
> >>>>>>>>>>> +
> >>>>>>>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> >>>>>>>>>>> + struct vduse_dev_msg *msg)
> >>>>>>>>>>> +{
> >>>>>>>>>>> + init_waitqueue_head(&msg->waitq);
> >>>>>>>>>>> + spin_lock(&dev->msg_lock);
> >>>>>>>>>>> + vduse_enqueue_msg(&dev->send_list, msg);
> >>>>>>>>>>> + wake_up(&dev->waitq);
> >>>>>>>>>>> + spin_unlock(&dev->msg_lock);
> >>>>>>>>>>> + wait_event_killable(msg->waitq, msg->completed);
> >>>>>>>>>> What happens if the userspace(malicous) doesn't give a response forever?
> >>>>>>>>>>
> >>>>>>>>>> It looks like a DOS. If yes, we need to consider a way to fix that.
> >>>>>>>>>>
> >>>>>>>>> How about using wait_event_killable_timeout() instead?
> >>>>>>>> Probably, and then we need choose a suitable timeout and more important,
> >>>>>>>> need to report the failure to virtio.
> >>>>>>>>
> >>>>>>> Makes sense to me. But it looks like some
> >>>>>>> vdpa_config_ops/virtio_config_ops such as set_status() didn't have a
> >>>>>>> return value. Now I add a WARN_ON() for the failure. Do you mean we
> >>>>>>> need to add some change for virtio core to handle the failure?
> >>>>>> Maybe, but I'm not sure how hard we can do that.
> >>>>>>
> >>>>> We need to change all virtio device drivers in this way.
> >>>> Probably.
> >>>>
> >>>>
> >>>>>> We had NEEDS_RESET but it looks we don't implement it.
> >>>>>>
> >>>>> Could it handle the failure of get_feature() and get/set_config()?
> >>>> Looks not:
> >>>>
> >>>> "
> >>>>
> >>>> The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
> >>>> that a reset is needed. If DRIVER_OK is set, after it sets
> >>>> DEVICE_NEEDS_RESET, the device MUST send a device configuration change
> >>>> notification to the driver.
> >>>>
> >>>> "
> >>>>
> >>>> This looks implies that NEEDS_RESET may only work after device is
> >>>> probed. But in the current design, even the reset() is not reliable.
> >>>>
> >>>>
> >>>>>> Or a rough idea is that maybe need some relaxing to be coupled loosely
> >>>>>> with userspace. E.g the device (control path) is implemented in the
> >>>>>> kernel but the datapath is implemented in the userspace like TUN/TAP.
> >>>>>>
> >>>>> I think it can work for most cases. One problem is that the set_config
> >>>>> might change the behavior of the data path at runtime, e.g.
> >>>>> virtnet_set_mac_address() in the virtio-net driver and
> >>>>> cache_type_store() in the virtio-blk driver. Not sure if this path is
> >>>>> able to return before the datapath is aware of this change.
> >>>> Good point.
> >>>>
> >>>> But set_config() should be rare:
> >>>>
> >>>> E.g in the case of virtio-net with VERSION_1, config space is read only,
> >>>> and it was set via control vq.
> >>>>
> >>>> For block, we can
> >>>>
> >>>> 1) start from without WCE or
> >>>> 2) we add a config change notification to userspace or
> >>> I prefer this way. And I think we also need to do similar things for
> >>> set/get_vq_state().
> >>
> >> Yes, I agree.
> >>
> > Hi Jason,
> >
> > Now I'm working on this. But I found the config change notification
> > must be synchronous in the virtio-blk case, which means the kernel
> > still needs to wait for the response from userspace in set_config().
> > Otherwise, some I/Os might still run the old way after we change the
> > cache_type in sysfs.
> >
> > The simple ways to solve this problem are:
> >
> > 1. Only support read-only config space, disable WCE as you suggested
> > 2. Add a return value to set_config() and handle the failure only in
> > virtio-blk driver
> > 3. Print some warnings after timeout since it only affects the
> > dataplane which is under userspace's control
> >
> > Any suggestions?
>
>
> Let's go without WCE first and make VDUSE work first. We can then think
> of a solution for WCE on top.
>
It's fine with me.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-31 6:19 ` Yongji Xie
@ 2021-05-31 6:32 ` Greg KH
2021-05-31 7:13 ` Yongji Xie
0 siblings, 1 reply; 51+ messages in thread
From: Greg KH @ 2021-05-31 6:32 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Jason Wang, Stefan Hajnoczi,
Stefano Garzarella, Parav Pandit, Christoph Hellwig,
Christian Brauner, Randy Dunlap, Matthew Wilcox, Al Viro,
Jens Axboe, bcrl, Jonathan Corbet, Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Mon, May 31, 2021 at 02:19:37PM +0800, Yongji Xie wrote:
> 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?
Make one of these dynamic and do not have them both control the lifespan
of the structure.
> > > + 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?
You need to do something, as no one can mess with a module parameter
easily. Why do you need them at all, shouldn't it "just work" properly
with no need for userspace interaction?
> > > +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.
Ah. Then how about using the same MAJOR for all of these, and just have
the first minor (0) be your control? That happens for other device
types (raw, loop, etc.). Or just document this really well please, as
it was not obvious what you were doing here.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Re: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-05-31 6:32 ` Greg KH
@ 2021-05-31 7:13 ` Yongji Xie
0 siblings, 0 replies; 51+ messages in thread
From: Yongji Xie @ 2021-05-31 7:13 UTC (permalink / raw)
To: Greg KH
Cc: Michael S. Tsirkin, Jason Wang, Stefan Hajnoczi,
Stefano Garzarella, Parav Pandit, Christoph Hellwig,
Christian Brauner, Randy Dunlap, Matthew Wilcox, Al Viro,
Jens Axboe, bcrl, Jonathan Corbet, Mika Penttilä,
Dan Carpenter, joro, virtualization, netdev, kvm, linux-fsdevel,
iommu, linux-kernel
On Mon, May 31, 2021 at 2:32 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, May 31, 2021 at 02:19:37PM +0800, Yongji Xie wrote:
> > 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?
>
> Make one of these dynamic and do not have them both control the lifespan
> of the structure.
>
I see some comments in cdev_device_add():
"This function should be used whenever the struct cdev and the struct
device are members of the same structure whose lifetime is managed by
the struct device."
So it seems to be ok here?
> > > > + 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?
>
> You need to do something, as no one can mess with a module parameter
> easily. Why do you need them at all, shouldn't it "just work" properly
> with no need for userspace interaction?
>
OK, I get you. It works fine with the default value. So I think it
should be ok to remove these parameters before we find a situation
that really needs them.
> > > > +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.
>
> Ah. Then how about using the same MAJOR for all of these, and just have
> the first minor (0) be your control? That happens for other device
> types (raw, loop, etc.). Or just document this really well please, as
> it was not obvious what you were doing here.
>
OK, I will reserve the first minor (0) for the control device instead.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2021-05-31 7:13 UTC | newest]
Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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).