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
Future work:
- Improve performance
- Userspace library (find a way to reuse device emulation code in qemu/rust-vmm)
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 (10):
file: Export receive_fd() to modules
eventfd: Increase the recursion depth of eventfd_signal()
vhost-vdpa: protect concurrent access to vhost device iotlb
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 | 212 +++
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 | 521 ++++++++
drivers/vdpa/vdpa_user/iova_domain.h | 70 +
drivers/vdpa/vdpa_user/vduse_dev.c | 1362 ++++++++++++++++++++
drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +-
drivers/vhost/iotlb.c | 20 +-
drivers/vhost/vdpa.c | 154 ++-
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 | 175 +++
23 files changed, 2548 insertions(+), 51 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
Add an opaque pointer for vhost IOTLB. And introduce
vhost_iotlb_add_range_ctx() to accept it.
Suggested-by: Jason Wang <redacted>
Signed-off-by: Xie Yongji <redacted>
Acked-by: Jason Wang <redacted>
---
drivers/vhost/iotlb.c | 20 ++++++++++++++++----
include/linux/vhost_iotlb.h | 3 +++
2 files changed, 19 insertions(+), 4 deletions(-)
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 <redacted>
Acked-by: Jason Wang <redacted>
---
fs/eventfd.c | 2 +-
include/linux/eventfd.h | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)
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 <redacted>
Signed-off-by: Xie Yongji <redacted>
Acked-by: Jason Wang <redacted>
---
drivers/vhost/vdpa.c | 53 +++++++++++++++++++++++++++++++++-------------------
1 file changed, 34 insertions(+), 19 deletions(-)
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 <redacted>
Signed-off-by: Xie Yongji <redacted>
---
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(-)
@@ -91,6 +93,10 @@ struct vdpa_device *__vdpa_alloc_device(struct device *parent,if(!!config->dma_map!=!!config->dma_unmap)gotoerr;+/* It should only work for the device that use on-chip IOMMU */+if(use_va&&!(config->dma_map||config->set_map))+gotoerr;+err=-ENOMEM;vdev=kzalloc(size,GFP_KERNEL);if(!vdev)
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 <redacted>
---
fs/file.c | 6 ++++++
include/linux/file.h | 7 +++----
2 files changed, 9 insertions(+), 4 deletions(-)
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 <redacted>
---
drivers/vdpa/vdpa_user/iova_domain.c | 521 +++++++++++++++++++++++++++++++++++
drivers/vdpa/vdpa_user/iova_domain.h | 70 +++++
2 files changed, 591 insertions(+)
create mode 100644 drivers/vdpa/vdpa_user/iova_domain.c
create mode 100644 drivers/vdpa/vdpa_user/iova_domain.h
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 <redacted>
---
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 | 1362 ++++++++++++++++++++
include/uapi/linux/vduse.h | 175 +++
6 files changed, 1554 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
@@ -0,0 +1,175 @@+/* 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_CONFIG_DATA_LEN 256+#define VDUSE_NAME_MAX 256++/* the control messages definition for read/write */++enumvduse_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,+};++structvduse_vq_num{+__u32index;/* virtqueue index */+__u32num;/* the size of virtqueue */+};++structvduse_vq_addr{+__u32index;/* virtqueue index */+__u64desc_addr;/* address of desc area */+__u64driver_addr;/* address of driver area */+__u64device_addr;/* address of device area */+};++structvduse_vq_ready{+__u32index;/* virtqueue index */+__u8ready;/* ready status of virtqueue */+};++structvduse_vq_state{+__u32index;/* virtqueue index */+__u16avail_idx;/* virtqueue state (last_avail_idx) */+};++structvduse_dev_config_data{+__u32offset;/* offset from the beginning of config space */+__u32len;/* the length to read/write */+__u8data[VDUSE_CONFIG_DATA_LEN];/* data buffer used to read/write */+};++structvduse_iova_range{+__u64start;/* start of the IOVA range */+__u64last;/* end of the IOVA range */+};++structvduse_features{+__u64features;/* virtio features */+};++structvduse_status{+__u8status;/* device status */+};++structvduse_dev_request{+__u32type;/* request type */+__u32request_id;/* request id */+__u32reserved[2];/* for future use */+union{+structvduse_vq_numvq_num;/* virtqueue num */+structvduse_vq_addrvq_addr;/* virtqueue address */+structvduse_vq_readyvq_ready;/* virtqueue ready status */+structvduse_vq_statevq_state;/* virtqueue state */+structvduse_dev_config_dataconfig;/* virtio device config space */+structvduse_iova_rangeiova;/* iova range for updating */+structvduse_featuresf;/* virtio features */+structvduse_statuss;/* device status */+__u32padding[16];/* padding */+};+};++structvduse_dev_response{+__u32request_id;/* corresponding request id */+#define VDUSE_REQUEST_OK 0x00+#define VDUSE_REQUEST_FAILED 0x01+__u32result;/* the result of request */+__u32reserved[2];/* for future use */+union{+structvduse_vq_readyvq_ready;/* virtqueue ready status */+structvduse_vq_statevq_state;/* virtqueue state */+structvduse_dev_config_dataconfig;/* virtio device config space */+structvduse_featuresf;/* virtio features */+structvduse_statuss;/* device status */+__u32padding[16];/* padding */+};+};++/* ioctls */++structvduse_dev_config{+charname[VDUSE_NAME_MAX];/* vduse device name */+__u32vendor_id;/* virtio vendor id */+__u32device_id;/* virtio device id */+__u64bounce_size;/* bounce buffer size for iommu */+__u16vq_num;/* the number of virtqueues */+__u16vq_size_max;/* the max size of virtqueue */+__u32vq_align;/* the allocation alignment of virtqueue's metadata */+__u32reserved[8];/* for future use */+};++structvduse_iotlb_entry{+__u64offset;/* the mmap offset on fd */+__u64start;/* start of the IOVA range */+__u64last;/* last of the IOVA range */+#define VDUSE_ACCESS_RO 0x1+#define VDUSE_ACCESS_WO 0x2+#define VDUSE_ACCESS_RW 0x3+__u8perm;/* access permission of this range */+};++structvduse_vq_eventfd{+__u32index;/* virtqueue index */+#define VDUSE_EVENTFD_DEASSIGN -1+intfd;/* 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])++/*+*Getafiledescriptorforthefirstoverlappediovaregion,+*-EINVALmeanstheiovaregiondoesn'texist.+*/+#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 _IO(VDUSE_BASE, 0x06)++/* Inject a config interrupt */+#define VDUSE_INJECT_CONFIG_IRQ _IO(VDUSE_BASE, 0x07)++#endif /* _UAPI_VDUSE_H_ */
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
@@ -0,0 +1,212 @@+==================================+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.++How VDUSE works+------------+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on+the character device (/dev/vduse/control). Then a device file with the+specified name (/dev/vduse/$NAME) will appear, which can be used to+implement the userspace vDPA device's control path and data path.++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 the VDUSE device file 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 the VDUSE device file:++- 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 the VDUSE device file 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++Register VDUSE device on vDPA bus+---------------------------------+In order to make the VDUSE device work, administrator needs to use the management+API (netlink) to register it on vDPA bus. Some sample codes are show below:++..code-block:: c++ static int netlink_add_vduse(const char *name, int device_id)+ {+ 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,+ VDPA_CMD_DEV_NEW, 0))+ goto nla_put_failure;++ NLA_PUT_STRING(msg, VDPA_ATTR_DEV_NAME, name);+ NLA_PUT_STRING(msg, VDPA_ATTR_MGMTDEV_DEV_NAME, "vduse");+ NLA_PUT_U32(msg, VDPA_ATTR_DEV_ID, device_id);++ 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;+ }++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.
From: Christian Brauner <hidden> Date: 2021-03-31 09:16:40
On Wed, Mar 31, 2021 at 04:05:10PM +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.
Signed-off-by: Xie Yongji <redacted>
---
Yeah, as I said in the other mail I'd be comfortable with exposing just
this variant of the helper.
Maybe this should be a separate patch bundled together with Christoph's
patch to split parts of receive_fd() into a separate helper.
This would also allow us to simplify a few other codepaths in drivers as
well btw. I just took a hasty stab at two of them:
From: Dan Carpenter <hidden> Date: 2021-03-31 09:27:57
On Wed, Mar 31, 2021 at 11:15:45AM +0200, Christian Brauner wrote:
quoted hunk
On Wed, Mar 31, 2021 at 04:05:10PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Yeah, as I said in the other mail I'd be comfortable with exposing just
this variant of the helper.
Maybe this should be a separate patch bundled together with Christoph's
patch to split parts of receive_fd() into a separate helper.
This would also allow us to simplify a few other codepaths in drivers as
well btw. I just took a hasty stab at two of them:
From: Christian Brauner <hidden> Date: 2021-03-31 09:29:34
On Wed, Mar 31, 2021 at 12:26:24PM +0300, Dan Carpenter wrote:
On Wed, Mar 31, 2021 at 11:15:45AM +0200, Christian Brauner wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:10PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Yeah, as I said in the other mail I'd be comfortable with exposing just
this variant of the helper.
Maybe this should be a separate patch bundled together with Christoph's
patch to split parts of receive_fd() into a separate helper.
This would also allow us to simplify a few other codepaths in drivers as
well btw. I just took a hasty stab at two of them:
On Wed, Mar 31, 2021 at 5:15 PM Christian Brauner
[off-list ref] wrote:
On Wed, Mar 31, 2021 at 04:05:10PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Yeah, as I said in the other mail I'd be comfortable with exposing just
this variant of the helper.
Thanks, I got it now.
Maybe this should be a separate patch bundled together with Christoph's
patch to split parts of receive_fd() into a separate helper.
Do we need to add the seccomp notifier into the separate helper? In
our case, the file passed to the separate helper is from another
process.
Thanks,
Yongji
From: Christian Brauner <hidden> Date: 2021-03-31 12:24:28
On Wed, Mar 31, 2021 at 07:32:33PM +0800, Yongji Xie wrote:
On Wed, Mar 31, 2021 at 5:15 PM Christian Brauner
[off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:10PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Yeah, as I said in the other mail I'd be comfortable with exposing just
this variant of the helper.
Thanks, I got it now.
quoted
Maybe this should be a separate patch bundled together with Christoph's
patch to split parts of receive_fd() into a separate helper.
Do we need to add the seccomp notifier into the separate helper? In
our case, the file passed to the separate helper is from another
process.
Not sure what you mean. Christoph has proposed
https://lore.kernel.org/linux-fsdevel/20210325082209.1067987-2-hch@lst.de
I was just saying that if we think this patch is useful we might bundle
it together with the
EXPORT_SYMBOL(receive_fd)
part here, convert all drivers that currently open-code get_unused_fd()
+ fd_install() to use receive_fd(), and make this a separate patchset.
I don't think that needs to hinder reviewing your series though.
Christian
On Wed, Mar 31, 2021 at 8:23 PM Christian Brauner
[off-list ref] wrote:
On Wed, Mar 31, 2021 at 07:32:33PM +0800, Yongji Xie wrote:
quoted
On Wed, Mar 31, 2021 at 5:15 PM Christian Brauner
[off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:10PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Yeah, as I said in the other mail I'd be comfortable with exposing just
this variant of the helper.
Thanks, I got it now.
quoted
Maybe this should be a separate patch bundled together with Christoph's
patch to split parts of receive_fd() into a separate helper.
Do we need to add the seccomp notifier into the separate helper? In
our case, the file passed to the separate helper is from another
process.
Not sure what you mean. Christoph has proposed
https://lore.kernel.org/linux-fsdevel/20210325082209.1067987-2-hch@lst.de
I was just saying that if we think this patch is useful we might bundle
it together with the
EXPORT_SYMBOL(receive_fd)
part here, convert all drivers that currently open-code get_unused_fd()
+ fd_install() to use receive_fd(), and make this a separate patchset.
Yes, I see. We can split the parts (get_unused_fd() + fd_install()) of
receive_fd() into a separate helper and convert all drivers to use
that. What I mean is that I also would like to use
security_file_receive() in my modules. So I'm not sure if it's ok to
add security_file_receive() into the separate helper. Or do I need to
export security_file_receive() separately?
Thanks,
Yongji
From: Christian Brauner <hidden> Date: 2021-03-31 14:09:09
On Wed, Mar 31, 2021 at 09:59:07PM +0800, Yongji Xie wrote:
On Wed, Mar 31, 2021 at 8:23 PM Christian Brauner
[off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 07:32:33PM +0800, Yongji Xie wrote:
quoted
On Wed, Mar 31, 2021 at 5:15 PM Christian Brauner
[off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:10PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Yeah, as I said in the other mail I'd be comfortable with exposing just
this variant of the helper.
Thanks, I got it now.
quoted
Maybe this should be a separate patch bundled together with Christoph's
patch to split parts of receive_fd() into a separate helper.
Do we need to add the seccomp notifier into the separate helper? In
our case, the file passed to the separate helper is from another
process.
Not sure what you mean. Christoph has proposed
https://lore.kernel.org/linux-fsdevel/20210325082209.1067987-2-hch@lst.de
I was just saying that if we think this patch is useful we might bundle
it together with the
EXPORT_SYMBOL(receive_fd)
part here, convert all drivers that currently open-code get_unused_fd()
+ fd_install() to use receive_fd(), and make this a separate patchset.
Yes, I see. We can split the parts (get_unused_fd() + fd_install()) of
receive_fd() into a separate helper and convert all drivers to use
that. What I mean is that I also would like to use
security_file_receive() in my modules. So I'm not sure if it's ok to
add security_file_receive() into the separate helper. Or do I need to
export security_file_receive() separately?
I think I confused you which is my bad. What you do here is - in my
opinion - correct.
I'm just saying that exporting receive_fd() allows further cleanups and
your export here could go on top of Christoph's change in a separate
series.
Christian
On Wed, Mar 31, 2021 at 10:08 PM Christian Brauner
[off-list ref] wrote:
On Wed, Mar 31, 2021 at 09:59:07PM +0800, Yongji Xie wrote:
quoted
On Wed, Mar 31, 2021 at 8:23 PM Christian Brauner
[off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 07:32:33PM +0800, Yongji Xie wrote:
quoted
On Wed, Mar 31, 2021 at 5:15 PM Christian Brauner
[off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:10PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Yeah, as I said in the other mail I'd be comfortable with exposing just
this variant of the helper.
Thanks, I got it now.
quoted
Maybe this should be a separate patch bundled together with Christoph's
patch to split parts of receive_fd() into a separate helper.
Do we need to add the seccomp notifier into the separate helper? In
our case, the file passed to the separate helper is from another
process.
Not sure what you mean. Christoph has proposed
https://lore.kernel.org/linux-fsdevel/20210325082209.1067987-2-hch@lst.de
I was just saying that if we think this patch is useful we might bundle
it together with the
EXPORT_SYMBOL(receive_fd)
part here, convert all drivers that currently open-code get_unused_fd()
+ fd_install() to use receive_fd(), and make this a separate patchset.
Yes, I see. We can split the parts (get_unused_fd() + fd_install()) of
receive_fd() into a separate helper and convert all drivers to use
that. What I mean is that I also would like to use
security_file_receive() in my modules. So I'm not sure if it's ok to
add security_file_receive() into the separate helper. Or do I need to
export security_file_receive() separately?
I think I confused you which is my bad. What you do here is - in my
opinion - correct.
I'm just saying that exporting receive_fd() allows further cleanups and
your export here could go on top of Christoph's change in a separate
series.
Oh, I get you now! I'm glad to do that.
Thanks,
Yongji
From: Jason Wang <hidden> Date: 2021-04-08 02:36:53
在 2021/3/31 下午4:05, Xie Yongji 写道:
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 <redacted>
Signed-off-by: Xie Yongji <redacted>
@@ -91,6 +93,10 @@ struct vdpa_device *__vdpa_alloc_device(struct device *parent,if(!!config->dma_map!=!!config->dma_unmap)gotoerr;+/* It should only work for the device that use on-chip IOMMU */+if(use_va&&!(config->dma_map||config->set_map))+gotoerr;+err=-ENOMEM;vdev=kzalloc(size,GFP_KERNEL);if(!vdev)
From: Jason Wang <hidden> Date: 2021-04-08 03:26:26
在 2021/3/31 下午4:05, Xie Yongji 写道:
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 <redacted>
On Thu, Apr 8, 2021 at 11:26 AM Jason Wang [off-list ref] wrote:
在 2021/3/31 下午4:05, Xie Yongji 写道:
quoted
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 <redacted>
From: Jason Wang <hidden> Date: 2021-04-08 06:57:31
在 2021/3/31 下午4:05, Xie Yongji 写道:
quoted hunk
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 <redacted>
---
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 | 1362 ++++++++++++++++++++
include/uapi/linux/vduse.h | 175 +++
6 files changed, 1554 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
@@ -0,0 +1,175 @@+/* 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_CONFIG_DATA_LEN 256+#define VDUSE_NAME_MAX 256++/* the control messages definition for read/write */++enumvduse_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,+};++structvduse_vq_num{+__u32index;/* virtqueue index */
I think it's better to have a consistent style of the doc/comment. If
yes, let's move those comment above the field.
+ __u32 num; /* the size of virtqueue */
+};
+
+struct vduse_vq_addr {
+ __u32 index; /* virtqueue index */
+ __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 */
+ __u16 avail_idx; /* virtqueue state (last_avail_idx) */
Let's use __u64 here to be consistent with get_vq_state(). The idea is
to support packed virtqueue.
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
+};
+
+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[16]; /* 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[16]; /* padding */
So it looks to me this padding doesn't work since vduse_dev_config_data
is larger than it.
+ };
+};
+
+/* 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_num; /* the number of virtqueues */
+ __u16 vq_size_max; /* the max size of virtqueue */
+ __u32 vq_align; /* the allocation alignment of virtqueue's metadata */
+ __u32 reserved[8]; /* for future use */
Is there a hole before reserved?
+};
+
+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 _IO(VDUSE_BASE, 0x06)
From: Jason Wang <hidden> Date: 2021-04-08 07:18:37
在 2021/3/31 下午4:05, Xie Yongji 写道:
quoted hunk
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
@@ -0,0 +1,212 @@+==================================+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.++How VDUSE works+------------+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on+the character device (/dev/vduse/control). Then a device file with the+specified name (/dev/vduse/$NAME) will appear, which can be used to+implement the userspace vDPA device's control path and data path.++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 the VDUSE device file 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 the VDUSE device file:++- 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 the VDUSE device file 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++Register VDUSE device on vDPA bus+---------------------------------+In order to make the VDUSE device work, administrator needs to use the management+API (netlink) to register it on vDPA bus. Some sample codes are show below:++..code-block:: c++ static int netlink_add_vduse(const char *name, int device_id)+ {+ 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,+ VDPA_CMD_DEV_NEW, 0))+ goto nla_put_failure;++ NLA_PUT_STRING(msg, VDPA_ATTR_DEV_NAME, name);+ NLA_PUT_STRING(msg, VDPA_ATTR_MGMTDEV_DEV_NAME, "vduse");+ NLA_PUT_U32(msg, VDPA_ATTR_DEV_ID, device_id);++ 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;+ }
Let's also explain this can be done via vdpa tool in iproute2 as well.
Otherwise
Acked-by: Jason Wang <redacted>
+
+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.
On Thu, Apr 8, 2021 at 3:18 PM Jason Wang [off-list ref] wrote:
在 2021/3/31 下午4:05, Xie Yongji 写道:
quoted
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
@@ -0,0 +1,212 @@+==================================+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.++How VDUSE works+------------+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on+the character device (/dev/vduse/control). Then a device file with the+specified name (/dev/vduse/$NAME) will appear, which can be used to+implement the userspace vDPA device's control path and data path.++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 the VDUSE device file 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 the VDUSE device file:++- 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 the VDUSE device file 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++Register VDUSE device on vDPA bus+---------------------------------+In order to make the VDUSE device work, administrator needs to use the management+API (netlink) to register it on vDPA bus. Some sample codes are show below:++..code-block:: c++ static int netlink_add_vduse(const char *name, int device_id)+ {+ 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,+ VDPA_CMD_DEV_NEW, 0))+ goto nla_put_failure;++ NLA_PUT_STRING(msg, VDPA_ATTR_DEV_NAME, name);+ NLA_PUT_STRING(msg, VDPA_ATTR_MGMTDEV_DEV_NAME, "vduse");+ NLA_PUT_U32(msg, VDPA_ATTR_DEV_ID, device_id);++ 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;+ }
Let's also explain this can be done via vdpa tool in iproute2 as well.
On Thu, Apr 8, 2021 at 2:57 PM Jason Wang [off-list ref] wrote:
在 2021/3/31 下午4:05, Xie Yongji 写道:
quoted
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 <redacted>
---
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 | 1362 ++++++++++++++++++++
include/uapi/linux/vduse.h | 175 +++
6 files changed, 1554 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
@@ -0,0 +1,175 @@+/* 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_CONFIG_DATA_LEN 256+#define VDUSE_NAME_MAX 256++/* the control messages definition for read/write */++enumvduse_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,+};++structvduse_vq_num{+__u32index;/* virtqueue index */
I think it's better to have a consistent style of the doc/comment. If
yes, let's move those comment above the field.
Fine.
quoted
+ __u32 num; /* the size of virtqueue */
+};
+
+struct vduse_vq_addr {
+ __u32 index; /* virtqueue index */
+ __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 */
+ __u16 avail_idx; /* virtqueue state (last_avail_idx) */
Let's use __u64 here to be consistent with get_vq_state(). The idea is
to support packed virtqueue.
OK. But looks like sizeof(struct vdpa_vq_state) is still equal to 2.
Do you mean we will extend it in the future?
quoted
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
Do you mean 256 is no enough here？
quoted
+};
+
+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[16]; /* 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[16]; /* padding */
So it looks to me this padding doesn't work since vduse_dev_config_data
is larger than it.
Oh, my bad. Will fix it.
quoted
+ };
+};
+
+/* 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_num; /* the number of virtqueues */
+ __u16 vq_size_max; /* the max size of virtqueue */
+ __u32 vq_align; /* the allocation alignment of virtqueue's metadata */
+ __u32 reserved[8]; /* for future use */
Is there a hole before reserved?
But I don't find the hole in below layout:
| 256 | 4 | 4 | 8 | 2 | 2 | 4 | 32 |
quoted
+};
+
+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 _IO(VDUSE_BASE, 0x06)
Missing parameter?
We use the argp to store the virtqueue index here. Is it OK?
Thanks,
Yongji
From: Jason Wang <hidden> Date: 2021-04-09 05:36:53
在 2021/4/8 下午5:36, Yongji Xie 写道:
On Thu, Apr 8, 2021 at 2:57 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/3/31 下午4:05, Xie Yongji 写道:
quoted
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 <redacted>
---
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 | 1362 ++++++++++++++++++++
include/uapi/linux/vduse.h | 175 +++
6 files changed, 1554 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
@@ -0,0 +1,175 @@+/* 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_CONFIG_DATA_LEN 256+#define VDUSE_NAME_MAX 256++/* the control messages definition for read/write */++enumvduse_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,+};++structvduse_vq_num{+__u32index;/* virtqueue index */
I think it's better to have a consistent style of the doc/comment. If
yes, let's move those comment above the field.
Fine.
quoted
quoted
+ __u32 num; /* the size of virtqueue */
+};
+
+struct vduse_vq_addr {
+ __u32 index; /* virtqueue index */
+ __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 */
+ __u16 avail_idx; /* virtqueue state (last_avail_idx) */
Let's use __u64 here to be consistent with get_vq_state().
__u32 actually:
struct vhost_vring_state {
unsigned int index;
unsigned int num;
};
quoted
The idea is
to support packed virtqueue.
OK. But looks like sizeof(struct vdpa_vq_state) is still equal to 2.
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
Do you mean 256 is no enough here？
Yes.
quoted
quoted
+};
+
+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[16]; /* 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[16]; /* padding */
So it looks to me this padding doesn't work since vduse_dev_config_data
is larger than it.
Oh, my bad. Will fix it.
quoted
quoted
+ };
+};
+
+/* 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_num; /* the number of virtqueues */
+ __u16 vq_size_max; /* the max size of virtqueue */
+ __u32 vq_align; /* the allocation alignment of virtqueue's metadata */
+ __u32 reserved[8]; /* for future use */
Is there a hole before reserved?
But I don't find the hole in below layout:
| 256 | 4 | 4 | 8 | 2 | 2 | 4 | 32 |
Looks correct, better to check with pahole to double confirm.
quoted
quoted
+};
+
+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 _IO(VDUSE_BASE, 0x06)
Missing parameter?
We use the argp to store the virtqueue index here. Is it OK?
So I meant it should be something like:
#define VDUSE_INJECT_VQ_IRQ _IOW(VDUSE_BASE, 0x06, unsigned int)
?
Thanks
On Fri, Apr 9, 2021 at 1:36 PM Jason Wang [off-list ref] wrote:
在 2021/4/8 下午5:36, Yongji Xie 写道:
quoted
On Thu, Apr 8, 2021 at 2:57 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/3/31 下午4:05, Xie Yongji 写道:
quoted
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 <redacted>
---
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 | 1362 ++++++++++++++++++++
include/uapi/linux/vduse.h | 175 +++
6 files changed, 1554 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
@@ -0,0 +1,175 @@+/* 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_CONFIG_DATA_LEN 256+#define VDUSE_NAME_MAX 256++/* the control messages definition for read/write */++enumvduse_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,+};++structvduse_vq_num{+__u32index;/* virtqueue index */
I think it's better to have a consistent style of the doc/comment. If
yes, let's move those comment above the field.
Fine.
quoted
quoted
+ __u32 num; /* the size of virtqueue */
+};
+
+struct vduse_vq_addr {
+ __u32 index; /* virtqueue index */
+ __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 */
+ __u16 avail_idx; /* virtqueue state (last_avail_idx) */
Let's use __u64 here to be consistent with get_vq_state().
__u32 actually:
struct vhost_vring_state {
unsigned int index;
unsigned int num;
};
OK.
quoted
quoted
The idea is
to support packed virtqueue.
OK. But looks like sizeof(struct vdpa_vq_state) is still equal to 2.
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
Do you mean 256 is no enough here？
Yes.
But this request will be submitted multiple times if config lengh is
larger than 256. So do you think whether we need to extent the size to
512 or larger?
quoted
quoted
quoted
+};
+
+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[16]; /* 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[16]; /* padding */
So it looks to me this padding doesn't work since vduse_dev_config_data
is larger than it.
Oh, my bad. Will fix it.
quoted
quoted
+ };
+};
+
+/* 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_num; /* the number of virtqueues */
+ __u16 vq_size_max; /* the max size of virtqueue */
+ __u32 vq_align; /* the allocation alignment of virtqueue's metadata */
+ __u32 reserved[8]; /* for future use */
Is there a hole before reserved?
But I don't find the hole in below layout:
| 256 | 4 | 4 | 8 | 2 | 2 | 4 | 32 |
Looks correct, better to check with pahole to double confirm.
OK. Sure.
quoted
quoted
quoted
+};
+
+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 _IO(VDUSE_BASE, 0x06)
Missing parameter?
We use the argp to store the virtqueue index here. Is it OK?
So I meant it should be something like:
#define VDUSE_INJECT_VQ_IRQ _IOW(VDUSE_BASE, 0x06, unsigned int)
From: Jason Wang <hidden> Date: 2021-04-12 07:16:29
在 2021/4/9 下午4:02, Yongji Xie 写道:
quoted
quoted
quoted
quoted
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
Do you mean 256 is no enough here？
Yes.
But this request will be submitted multiple times if config lengh is
larger than 256. So do you think whether we need to extent the size to
512 or larger?
So I think you'd better either:
1) document the limitation (256) in somewhere, (better both uapi and doc)
or
2) make it variable
Thanks
On Mon, Apr 12, 2021 at 3:16 PM Jason Wang [off-list ref] wrote:
在 2021/4/9 下午4:02, Yongji Xie 写道:
quoted
quoted
quoted
quoted
quoted
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
Do you mean 256 is no enough here？
Yes.
But this request will be submitted multiple times if config lengh is
larger than 256. So do you think whether we need to extent the size to
512 or larger?
So I think you'd better either:
1) document the limitation (256) in somewhere, (better both uapi and doc)
But the VDUSE_CONFIG_DATA_LEN doesn't mean the limitation of
configuration space. It only means the maximum size of one data
transfer for configuration space. Do you mean document this?
Thanks,
Yongji
From: Jason Wang <hidden> Date: 2021-04-12 09:45:21
在 2021/4/12 下午4:02, Yongji Xie 写道:
On Mon, Apr 12, 2021 at 3:16 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/9 下午4:02, Yongji Xie 写道:
quoted
quoted
quoted
quoted
quoted
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
Do you mean 256 is no enough here？
Yes.
But this request will be submitted multiple times if config lengh is
larger than 256. So do you think whether we need to extent the size to
512 or larger?
So I think you'd better either:
1) document the limitation (256) in somewhere, (better both uapi and doc)
But the VDUSE_CONFIG_DATA_LEN doesn't mean the limitation of
configuration space. It only means the maximum size of one data
transfer for configuration space. Do you mean document this?
Yes, and another thing is that since you're using
data[VDUSE_CONFIG_DATA_LEN] in the uapi, it implies the length is always
256 which seems not good and not what the code is wrote.
Thanks
On Mon, Apr 12, 2021 at 5:37 PM Jason Wang [off-list ref] wrote:
在 2021/4/12 下午4:02, Yongji Xie 写道:
quoted
On Mon, Apr 12, 2021 at 3:16 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/9 下午4:02, Yongji Xie 写道:
quoted
quoted
quoted
quoted
quoted
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
Do you mean 256 is no enough here？
Yes.
But this request will be submitted multiple times if config lengh is
larger than 256. So do you think whether we need to extent the size to
512 or larger?
So I think you'd better either:
1) document the limitation (256) in somewhere, (better both uapi and doc)
But the VDUSE_CONFIG_DATA_LEN doesn't mean the limitation of
configuration space. It only means the maximum size of one data
transfer for configuration space. Do you mean document this?
Yes, and another thing is that since you're using
data[VDUSE_CONFIG_DATA_LEN] in the uapi, it implies the length is always
256 which seems not good and not what the code is wrote.
How about renaming VDUSE_CONFIG_DATA_LEN to VDUSE_MAX_TRANSFER_LEN?
Thanks,
Yongji
From: Jason Wang <hidden> Date: 2021-04-13 03:35:26
在 2021/4/12 下午5:59, Yongji Xie 写道:
On Mon, Apr 12, 2021 at 5:37 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/12 下午4:02, Yongji Xie 写道:
quoted
On Mon, Apr 12, 2021 at 3:16 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/9 下午4:02, Yongji Xie 写道:
quoted
quoted
quoted
quoted
quoted
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
Do you mean 256 is no enough here？
Yes.
But this request will be submitted multiple times if config lengh is
larger than 256. So do you think whether we need to extent the size to
512 or larger?
So I think you'd better either:
1) document the limitation (256) in somewhere, (better both uapi and doc)
But the VDUSE_CONFIG_DATA_LEN doesn't mean the limitation of
configuration space. It only means the maximum size of one data
transfer for configuration space. Do you mean document this?
Yes, and another thing is that since you're using
data[VDUSE_CONFIG_DATA_LEN] in the uapi, it implies the length is always
256 which seems not good and not what the code is wrote.
How about renaming VDUSE_CONFIG_DATA_LEN to VDUSE_MAX_TRANSFER_LEN?
Thanks,
Yongji
So a question is the reason to have a limitation of this in the uAPI?
Note that in vhost-vdpa we don't have such:
struct vhost_vdpa_config {
__u32 off;
__u32 len;
__u8 buf[0];
};
Thanks
On Tue, Apr 13, 2021 at 11:35 AM Jason Wang [off-list ref] wrote:
在 2021/4/12 下午5:59, Yongji Xie 写道:
quoted
On Mon, Apr 12, 2021 at 5:37 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/12 下午4:02, Yongji Xie 写道:
quoted
On Mon, Apr 12, 2021 at 3:16 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/9 下午4:02, Yongji Xie 写道:
quoted
quoted
quoted
quoted
quoted
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
Do you mean 256 is no enough here？
Yes.
But this request will be submitted multiple times if config lengh is
larger than 256. So do you think whether we need to extent the size to
512 or larger?
So I think you'd better either:
1) document the limitation (256) in somewhere, (better both uapi and doc)
But the VDUSE_CONFIG_DATA_LEN doesn't mean the limitation of
configuration space. It only means the maximum size of one data
transfer for configuration space. Do you mean document this?
Yes, and another thing is that since you're using
data[VDUSE_CONFIG_DATA_LEN] in the uapi, it implies the length is always
256 which seems not good and not what the code is wrote.
How about renaming VDUSE_CONFIG_DATA_LEN to VDUSE_MAX_TRANSFER_LEN?
Thanks,
Yongji
So a question is the reason to have a limitation of this in the uAPI?
Note that in vhost-vdpa we don't have such:
struct vhost_vdpa_config {
__u32 off;
__u32 len;
__u8 buf[0];
};
If so, we need to call read()/write() multiple times each time
receiving/sending one request or response in userspace and kernel. For
example,
1. read and check request/response type
2. read and check config length if type is VDUSE_SET_CONFIG or VDUSE_GET_CONFIG
3. read the payload
Not sure if it's worth it.
Thanks,
Yongji
From: "Michael S. Tsirkin" <mst@redhat.com> Date: 2021-04-14 07:34:54
On Wed, Mar 31, 2021 at 04:05:09PM +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 |
-------------------
This all looks quite similar to vhost-user-block except that one
does not need any kernel support at all.
So I am still scratching my head about its advantages over
vhost-user-block.
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.
Maybe the container part is the answer. How does that stack look?
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
Future work:
- Improve performance
- Userspace library (find a way to reuse device emulation code in qemu/rust-vmm)
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 (10):
file: Export receive_fd() to modules
eventfd: Increase the recursion depth of eventfd_signal()
vhost-vdpa: protect concurrent access to vhost device iotlb
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 | 212 +++
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 | 521 ++++++++
drivers/vdpa/vdpa_user/iova_domain.h | 70 +
drivers/vdpa/vdpa_user/vduse_dev.c | 1362 ++++++++++++++++++++
drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +-
drivers/vhost/iotlb.c | 20 +-
drivers/vhost/vdpa.c | 154 ++-
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 | 175 +++
23 files changed, 2548 insertions(+), 51 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
From: Jason Wang <hidden> Date: 2021-04-14 07:50:09
在 2021/4/14 下午3:34, Michael S. Tsirkin 写道:
On Wed, Mar 31, 2021 at 04:05:09PM +0800, Xie Yongji wrote:
quoted
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 |
-------------------
This all looks quite similar to vhost-user-block except that one
does not need any kernel support at all.
So I am still scratching my head about its advantages over
vhost-user-block.
quoted
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.
Maybe the container part is the answer. How does that stack look?
Yong Ji may add more and I think this has been demonstrated in the above
figure: the userspace vDPA device can provide a kenrel virito-blk device
via virtio_vdpa driver.
Thanks
quoted
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
Future work:
- Improve performance
- Userspace library (find a way to reuse device emulation code in qemu/rust-vmm)
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 (10):
file: Export receive_fd() to modules
eventfd: Increase the recursion depth of eventfd_signal()
vhost-vdpa: protect concurrent access to vhost device iotlb
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 | 212 +++
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 | 521 ++++++++
drivers/vdpa/vdpa_user/iova_domain.h | 70 +
drivers/vdpa/vdpa_user/vduse_dev.c | 1362 ++++++++++++++++++++
drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +-
drivers/vhost/iotlb.c | 20 +-
drivers/vhost/vdpa.c | 154 ++-
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 | 175 +++
23 files changed, 2548 insertions(+), 51 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
On Wed, Apr 14, 2021 at 3:35 PM Michael S. Tsirkin [off-list ref] wrote:
On Wed, Mar 31, 2021 at 04:05:09PM +0800, Xie Yongji wrote:
quoted
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 |
-------------------
This all looks quite similar to vhost-user-block except that one
does not need any kernel support at all.
So I am still scratching my head about its advantages over
vhost-user-block.
It plays the same role as vhost-user-block in VM user cases.
quoted
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.
Maybe the container part is the answer. How does that stack look?
Yes, it enables containers to reuse virtio software stack. We can have
one daemon that provides service to both containers and virtual
machines.
Thanks，
Yongji
From: Jason Wang <hidden> Date: 2021-04-14 08:18:38
在 2021/4/13 下午12:28, Yongji Xie 写道:
On Tue, Apr 13, 2021 at 11:35 AM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/12 下午5:59, Yongji Xie 写道:
quoted
On Mon, Apr 12, 2021 at 5:37 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/12 下午4:02, Yongji Xie 写道:
quoted
On Mon, Apr 12, 2021 at 3:16 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/9 下午4:02, Yongji Xie 写道:
quoted
quoted
quoted
quoted
quoted
+};
+
+struct vduse_dev_config_data {
+ __u32 offset; /* offset from the beginning of config space */
+ __u32 len; /* the length to read/write */
+ __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */
Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can
not change it in the future.
So this might suffcient for future features or all type of virtio devices.
Do you mean 256 is no enough here？
Yes.
But this request will be submitted multiple times if config lengh is
larger than 256. So do you think whether we need to extent the size to
512 or larger?
So I think you'd better either:
1) document the limitation (256) in somewhere, (better both uapi and doc)
But the VDUSE_CONFIG_DATA_LEN doesn't mean the limitation of
configuration space. It only means the maximum size of one data
transfer for configuration space. Do you mean document this?
Yes, and another thing is that since you're using
data[VDUSE_CONFIG_DATA_LEN] in the uapi, it implies the length is always
256 which seems not good and not what the code is wrote.
How about renaming VDUSE_CONFIG_DATA_LEN to VDUSE_MAX_TRANSFER_LEN?
Thanks,
Yongji
So a question is the reason to have a limitation of this in the uAPI?
Note that in vhost-vdpa we don't have such:
struct vhost_vdpa_config {
__u32 off;
__u32 len;
__u8 buf[0];
};
If so, we need to call read()/write() multiple times each time
receiving/sending one request or response in userspace and kernel. For
example,
1. read and check request/response type
2. read and check config length if type is VDUSE_SET_CONFIG or VDUSE_GET_CONFIG
3. read the payload
Not sure if it's worth it.
Thanks,
Yongji
Right, I see.
So I'm fine with current approach.
Thanks
From: Stefan Hajnoczi <stefanha@redhat.com> Date: 2021-04-14 14:15:10
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
Just looking over the documentation briefly (I haven't studied the code
yet)...
+How VDUSE works
+------------
+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
+the character device (/dev/vduse/control). Then a device file with the
+specified name (/dev/vduse/$NAME) will appear, which can be used to
+implement the userspace vDPA device's control path and data path.
These steps are taken after sending the VDPA_CMD_DEV_NEW netlink
message? (Please consider reordering the documentation to make it clear
what the sequence of steps are.)
What are the permission/capability requirements for VDUSE?
How does VDUSE interact with namespaces?
What is the meaning of VDPA_ATTR_DEV_ID? I don't see it in Linux
v5.12-rc6 drivers/vdpa/vdpa.c:vdpa_nl_cmd_dev_add_set_doit().
+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.
Is mmap(2) the right interface if memory is not actually shared, why not
just use pread(2)/pwrite(2) to make the copy explicit? That way the copy
semantics are clear. For example, don't expect to be able to busy wait
on the memory because changes will not be visible to the other side.
(I guess I'm missing something here and that mmap(2) is the right
approach, but maybe this documentation section can be clarified.)
On Wed, Apr 14, 2021 at 10:15 PM Stefan Hajnoczi [off-list ref] wrote:
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
Just looking over the documentation briefly (I haven't studied the code
yet)...
Thank you!
quoted
+How VDUSE works
+------------
+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
+the character device (/dev/vduse/control). Then a device file with the
+specified name (/dev/vduse/$NAME) will appear, which can be used to
+implement the userspace vDPA device's control path and data path.
These steps are taken after sending the VDPA_CMD_DEV_NEW netlink
message? (Please consider reordering the documentation to make it clear
what the sequence of steps are.)
No, VDUSE devices should be created before sending the
VDPA_CMD_DEV_NEW netlink messages which might produce I/Os to VDUSE.
What are the permission/capability requirements for VDUSE?
Now I think we need privileged permission (root user). Because
userspace daemon is able to access avail vring, used vring, descriptor
table in kernel driver directly.
How does VDUSE interact with namespaces?
Not sure I get your point here. Do you mean how the emulated vDPA
device interact with namespaces? This should work like hardware vDPA
devices do. VDUSE daemon can reside outside the namespace of a
container which uses the vDPA device.
What is the meaning of VDPA_ATTR_DEV_ID? I don't see it in Linux
v5.12-rc6 drivers/vdpa/vdpa.c:vdpa_nl_cmd_dev_add_set_doit().
It means the device id (e.g. VIRTIO_ID_BLOCK) of the vDPA device and
can be found in include/uapi/linux/vdpa.h.
quoted
+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.
Is mmap(2) the right interface if memory is not actually shared, why not
just use pread(2)/pwrite(2) to make the copy explicit? That way the copy
semantics are clear. For example, don't expect to be able to busy wait
on the memory because changes will not be visible to the other side.
(I guess I'm missing something here and that mmap(2) is the right
approach, but maybe this documentation section can be clarified.)
It's for performance considerations on the one hand. We might need to
call pread(2)/pwrite(2) multiple times for each request. On the other
hand, we can handle the virtqueue in a unified way for both vhost-vdpa
case and virtio-vdpa case. Otherwise, userspace daemon needs to know
which iova ranges need to be accessed with pread(2)/pwrite(2). And in
the future, we might be able to avoid bouncing in some cases.
Thanks,
Yongji
From: Stefan Hajnoczi <stefanha@redhat.com> Date: 2021-04-15 07:19:28
On Thu, Apr 15, 2021 at 01:38:37PM +0800, Yongji Xie wrote:
On Wed, Apr 14, 2021 at 10:15 PM Stefan Hajnoczi [off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
Just looking over the documentation briefly (I haven't studied the code
yet)...
Thank you!
quoted
quoted
+How VDUSE works
+------------
+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
+the character device (/dev/vduse/control). Then a device file with the
+specified name (/dev/vduse/$NAME) will appear, which can be used to
+implement the userspace vDPA device's control path and data path.
These steps are taken after sending the VDPA_CMD_DEV_NEW netlink
message? (Please consider reordering the documentation to make it clear
what the sequence of steps are.)
No, VDUSE devices should be created before sending the
VDPA_CMD_DEV_NEW netlink messages which might produce I/Os to VDUSE.
I see. Please include an overview of the steps before going into detail.
Something like:
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:
...
What are the permission/capability requirements for VDUSE?
Now I think we need privileged permission (root user). Because
userspace daemon is able to access avail vring, used vring, descriptor
table in kernel driver directly.
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace. Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Is the security situation different with vhost-vdpa? In that case it
seems more likely that the host kernel doesn't need to trust the
userspace VDUSE device.
Regarding privileges in general: userspace VDUSE processes shouldn't
need to run as root. The VDUSE device lifecycle will require privileges
to attach vhost-vdpa and virtio-vdpa devices, but the actual userspace
process that emulates the device should be able to run unprivileged.
Emulated devices are an attack surface and even if you are comfortable
with running them as root in your specific use case, it will be an issue
as soon as other people want to use VDUSE and could give VDUSE a
reputation for poor security.
quoted
How does VDUSE interact with namespaces?
Not sure I get your point here. Do you mean how the emulated vDPA
device interact with namespaces? This should work like hardware vDPA
devices do. VDUSE daemon can reside outside the namespace of a
container which uses the vDPA device.
Can VDUSE devices run inside containers? Are /dev/vduse/$NAME and vDPA
device names global?
quoted
What is the meaning of VDPA_ATTR_DEV_ID? I don't see it in Linux
v5.12-rc6 drivers/vdpa/vdpa.c:vdpa_nl_cmd_dev_add_set_doit().
It means the device id (e.g. VIRTIO_ID_BLOCK) of the vDPA device and
can be found in include/uapi/linux/vdpa.h.
VDPA_ATTR_DEV_ID is only used by VDPA_CMD_DEV_GET in Linux v5.12-rc6,
not by VDPA_CMD_DEV_NEW.
The example in this document uses VDPA_ATTR_DEV_ID with
VDPA_CMD_DEV_NEW. Is the example outdated?
quoted
quoted
+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.
Is mmap(2) the right interface if memory is not actually shared, why not
just use pread(2)/pwrite(2) to make the copy explicit? That way the copy
semantics are clear. For example, don't expect to be able to busy wait
on the memory because changes will not be visible to the other side.
(I guess I'm missing something here and that mmap(2) is the right
approach, but maybe this documentation section can be clarified.)
It's for performance considerations on the one hand. We might need to
call pread(2)/pwrite(2) multiple times for each request.
Userspace can keep page-sized pread() buffers around to avoid additional
syscalls during a request.
mmap() access does reduce the number of syscalls, but it also introduces
page faults (effectively doing the page-sized pread() I mentioned
above).
It's not obvious to me that there is a fundamental difference between
the two approaches in terms of performance.
On the other
hand, we can handle the virtqueue in a unified way for both vhost-vdpa
case and virtio-vdpa case. Otherwise, userspace daemon needs to know
which iova ranges need to be accessed with pread(2)/pwrite(2). And in
the future, we might be able to avoid bouncing in some cases.
Ah, I see. So bounce buffers are not used for vhost-vdpa?
Stefan
On Thu, Apr 15, 2021 at 3:19 PM Stefan Hajnoczi [off-list ref] wrote:
On Thu, Apr 15, 2021 at 01:38:37PM +0800, Yongji Xie wrote:
quoted
On Wed, Apr 14, 2021 at 10:15 PM Stefan Hajnoczi [off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
Just looking over the documentation briefly (I haven't studied the code
yet)...
Thank you!
quoted
quoted
+How VDUSE works
+------------
+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
+the character device (/dev/vduse/control). Then a device file with the
+specified name (/dev/vduse/$NAME) will appear, which can be used to
+implement the userspace vDPA device's control path and data path.
These steps are taken after sending the VDPA_CMD_DEV_NEW netlink
message? (Please consider reordering the documentation to make it clear
what the sequence of steps are.)
No, VDUSE devices should be created before sending the
VDPA_CMD_DEV_NEW netlink messages which might produce I/Os to VDUSE.
I see. Please include an overview of the steps before going into detail.
Something like:
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:
...
What are the permission/capability requirements for VDUSE?
Now I think we need privileged permission (root user). Because
userspace daemon is able to access avail vring, used vring, descriptor
table in kernel driver directly.
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace. Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Is the security situation different with vhost-vdpa? In that case it
seems more likely that the host kernel doesn't need to trust the
userspace VDUSE device.
Yes.
Regarding privileges in general: userspace VDUSE processes shouldn't
need to run as root. The VDUSE device lifecycle will require privileges
to attach vhost-vdpa and virtio-vdpa devices, but the actual userspace
process that emulates the device should be able to run unprivileged.
Emulated devices are an attack surface and even if you are comfortable
with running them as root in your specific use case, it will be an issue
as soon as other people want to use VDUSE and could give VDUSE a
reputation for poor security.
Agreed. Rethink about the virtio-vdpa case. The security risks mainly
come from the untrusted user being able to rewrite the content of
avail vring, used vring, descriptor table. But it seems that the worst
result of doing this is getting a broken virtqueue. Not sure if it's
acceptable to kernel.
quoted
quoted
How does VDUSE interact with namespaces?
Not sure I get your point here. Do you mean how the emulated vDPA
device interact with namespaces? This should work like hardware vDPA
devices do. VDUSE daemon can reside outside the namespace of a
container which uses the vDPA device.
Can VDUSE devices run inside containers? Are /dev/vduse/$NAME and vDPA
device names global?
I think we can run it inside containers. But there might be some
limitations. As you mentioned, the device name is global. So we need
to make sure the VDUSE daemons in different containers don't use the
same name to create vDPA devices.
quoted
quoted
What is the meaning of VDPA_ATTR_DEV_ID? I don't see it in Linux
v5.12-rc6 drivers/vdpa/vdpa.c:vdpa_nl_cmd_dev_add_set_doit().
It means the device id (e.g. VIRTIO_ID_BLOCK) of the vDPA device and
can be found in include/uapi/linux/vdpa.h.
VDPA_ATTR_DEV_ID is only used by VDPA_CMD_DEV_GET in Linux v5.12-rc6,
not by VDPA_CMD_DEV_NEW.
The example in this document uses VDPA_ATTR_DEV_ID with
VDPA_CMD_DEV_NEW. Is the example outdated?
Oh, you are right. Will update it.
quoted
quoted
quoted
+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.
Is mmap(2) the right interface if memory is not actually shared, why not
just use pread(2)/pwrite(2) to make the copy explicit? That way the copy
semantics are clear. For example, don't expect to be able to busy wait
on the memory because changes will not be visible to the other side.
(I guess I'm missing something here and that mmap(2) is the right
approach, but maybe this documentation section can be clarified.)
It's for performance considerations on the one hand. We might need to
call pread(2)/pwrite(2) multiple times for each request.
Userspace can keep page-sized pread() buffers around to avoid additional
syscalls during a request.
In the indirect descriptors case , it looks like we can't use one
pread() to get all buffers?
mmap() access does reduce the number of syscalls, but it also introduces
page faults (effectively doing the page-sized pread() I mentioned
above).
Yes, but only on the first access.
It's not obvious to me that there is a fundamental difference between
the two approaches in terms of performance.
quoted
On the other
hand, we can handle the virtqueue in a unified way for both vhost-vdpa
case and virtio-vdpa case. Otherwise, userspace daemon needs to know
which iova ranges need to be accessed with pread(2)/pwrite(2). And in
the future, we might be able to avoid bouncing in some cases.
Ah, I see. So bounce buffers are not used for vhost-vdpa?
From: Jason Wang <hidden> Date: 2021-04-15 08:37:00
在 2021/4/15 下午3:19, Stefan Hajnoczi 写道:
On Thu, Apr 15, 2021 at 01:38:37PM +0800, Yongji Xie wrote:
quoted
On Wed, Apr 14, 2021 at 10:15 PM Stefan Hajnoczi [off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
Just looking over the documentation briefly (I haven't studied the code
yet)...
Thank you!
quoted
quoted
+How VDUSE works
+------------
+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
+the character device (/dev/vduse/control). Then a device file with the
+specified name (/dev/vduse/$NAME) will appear, which can be used to
+implement the userspace vDPA device's control path and data path.
These steps are taken after sending the VDPA_CMD_DEV_NEW netlink
message? (Please consider reordering the documentation to make it clear
what the sequence of steps are.)
No, VDUSE devices should be created before sending the
VDPA_CMD_DEV_NEW netlink messages which might produce I/Os to VDUSE.
I see. Please include an overview of the steps before going into detail.
Something like:
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:
...
What are the permission/capability requirements for VDUSE?
Now I think we need privileged permission (root user). Because
userspace daemon is able to access avail vring, used vring, descriptor
table in kernel driver directly.
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel
which means IOMMU is probably the only thing to prevent a malicous device.
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the coherent
area, if we want to enforce stronger isolation we need to use shadow
virtqueue (which is proposed in earlier version by me) in this case. But
I'm not sure it's worth to do that.
Is the security situation different with vhost-vdpa? In that case it
seems more likely that the host kernel doesn't need to trust the
userspace VDUSE device.
Regarding privileges in general: userspace VDUSE processes shouldn't
need to run as root. The VDUSE device lifecycle will require privileges
to attach vhost-vdpa and virtio-vdpa devices, but the actual userspace
process that emulates the device should be able to run unprivileged.
Emulated devices are an attack surface and even if you are comfortable
with running them as root in your specific use case, it will be an issue
as soon as other people want to use VDUSE and could give VDUSE a
reputation for poor security.
In this case, I think it works as other char device:
- privilleged process to create and destroy the VDUSE
- fd is passed via SCM_RIGHTS to unprivilleged process that implements
the device
quoted
quoted
How does VDUSE interact with namespaces?
Not sure I get your point here. Do you mean how the emulated vDPA
device interact with namespaces? This should work like hardware vDPA
devices do. VDUSE daemon can reside outside the namespace of a
container which uses the vDPA device.
Can VDUSE devices run inside containers? Are /dev/vduse/$NAME and vDPA
device names global?
I think it's a global one, we can add namespace on top.
quoted
quoted
What is the meaning of VDPA_ATTR_DEV_ID? I don't see it in Linux
v5.12-rc6 drivers/vdpa/vdpa.c:vdpa_nl_cmd_dev_add_set_doit().
It means the device id (e.g. VIRTIO_ID_BLOCK) of the vDPA device and
can be found in include/uapi/linux/vdpa.h.
VDPA_ATTR_DEV_ID is only used by VDPA_CMD_DEV_GET in Linux v5.12-rc6,
not by VDPA_CMD_DEV_NEW.
The example in this document uses VDPA_ATTR_DEV_ID with
VDPA_CMD_DEV_NEW. Is the example outdated?
quoted
quoted
quoted
+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.
Is mmap(2) the right interface if memory is not actually shared, why not
just use pread(2)/pwrite(2) to make the copy explicit? That way the copy
semantics are clear. For example, don't expect to be able to busy wait
on the memory because changes will not be visible to the other side.
(I guess I'm missing something here and that mmap(2) is the right
approach, but maybe this documentation section can be clarified.)
It's for performance considerations on the one hand. We might need to
call pread(2)/pwrite(2) multiple times for each request.
Userspace can keep page-sized pread() buffers around to avoid additional
syscalls during a request.
I'm not sure I get here. But the length of the request is not
necessarily PAGE_SIZE.
mmap() access does reduce the number of syscalls, but it also introduces
page faults (effectively doing the page-sized pread() I mentioned
above).
You can access the data directly if there's already a page fault. So
mmap() should be much faster in this case.
It's not obvious to me that there is a fundamental difference between
the two approaches in terms of performance.
quoted
On the other
hand, we can handle the virtqueue in a unified way for both vhost-vdpa
case and virtio-vdpa case. Otherwise, userspace daemon needs to know
which iova ranges need to be accessed with pread(2)/pwrite(2). And in
the future, we might be able to avoid bouncing in some cases.
Ah, I see. So bounce buffers are not used for vhost-vdpa?
Yes, VDUSE can pass different fds to usersapce for mmap().
Thanks
From: Jason Wang <hidden> Date: 2021-04-15 09:05:22
在 2021/4/15 下午4:36, Jason Wang 写道:
quoted
quoted
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel
which means IOMMU is probably the only thing to prevent a malicous
device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the
coherent area, if we want to enforce stronger isolation we need to use
shadow virtqueue (which is proposed in earlier version by me) in this
case. But I'm not sure it's worth to do that.
Is the security situation different with vhost-vdpa? In that case it
seems more likely that the host kernel doesn't need to trust the
userspace VDUSE device.
On Thu, Apr 15, 2021 at 5:05 PM Jason Wang [off-list ref] wrote:
在 2021/4/15 下午4:36, Jason Wang 写道:
quoted
quoted
quoted
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel
which means IOMMU is probably the only thing to prevent a malicous
device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the
coherent area, if we want to enforce stronger isolation we need to use
shadow virtqueue (which is proposed in earlier version by me) in this
case. But I'm not sure it's worth to do that.
I might miss something. But VDUSE has recorded the dma address during
dma mapping, so we would not do bouncing if the addr/length is invalid
during dma unmapping. Is it enough?
Thanks,
Yongji
From: Stefan Hajnoczi <stefanha@redhat.com> Date: 2021-04-15 14:18:01
On Thu, Apr 15, 2021 at 04:33:27PM +0800, Yongji Xie wrote:
On Thu, Apr 15, 2021 at 3:19 PM Stefan Hajnoczi [off-list ref] wrote:
quoted
On Thu, Apr 15, 2021 at 01:38:37PM +0800, Yongji Xie wrote:
quoted
On Wed, Apr 14, 2021 at 10:15 PM Stefan Hajnoczi [off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
It's not obvious to me that there is a fundamental difference between
the two approaches in terms of performance.
quoted
On the other
hand, we can handle the virtqueue in a unified way for both vhost-vdpa
case and virtio-vdpa case. Otherwise, userspace daemon needs to know
which iova ranges need to be accessed with pread(2)/pwrite(2). And in
the future, we might be able to avoid bouncing in some cases.
Ah, I see. So bounce buffers are not used for vhost-vdpa?
Yes.
Okay, in that case I understand why mmap is used and it's nice to keep
virtio-vpda and vhost-vdpa unified. Thanks!
Stefan
From: Stefan Hajnoczi <stefanha@redhat.com> Date: 2021-04-15 14:38:44
On Thu, Apr 15, 2021 at 04:36:35PM +0800, Jason Wang wrote:
在 2021/4/15 下午3:19, Stefan Hajnoczi 写道:
quoted
On Thu, Apr 15, 2021 at 01:38:37PM +0800, Yongji Xie wrote:
quoted
On Wed, Apr 14, 2021 at 10:15 PM Stefan Hajnoczi [off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
Just looking over the documentation briefly (I haven't studied the code
yet)...
Thank you!
quoted
quoted
+How VDUSE works
+------------
+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
+the character device (/dev/vduse/control). Then a device file with the
+specified name (/dev/vduse/$NAME) will appear, which can be used to
+implement the userspace vDPA device's control path and data path.
These steps are taken after sending the VDPA_CMD_DEV_NEW netlink
message? (Please consider reordering the documentation to make it clear
what the sequence of steps are.)
No, VDUSE devices should be created before sending the
VDPA_CMD_DEV_NEW netlink messages which might produce I/Os to VDUSE.
I see. Please include an overview of the steps before going into detail.
Something like:
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:
...
What are the permission/capability requirements for VDUSE?
Now I think we need privileged permission (root user). Because
userspace daemon is able to access avail vring, used vring, descriptor
table in kernel driver directly.
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel which
means IOMMU is probably the only thing to prevent a malicous device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the coherent
area, if we want to enforce stronger isolation we need to use shadow
virtqueue (which is proposed in earlier version by me) in this case. But I'm
not sure it's worth to do that.
The security situation needs to be clear before merging this feature.
I think the IOMMU and vring can be made secure. What is more concerning
is the kernel code that runs on top: VIRTIO device drivers, network
stack, file systems, etc. They trust devices to an extent.
Since virtio-vdpa is a big reason for doing VDUSE in the first place I
don't think it makes sense to disable virtio-vdpa with VDUSE. A solution
is needed.
I'm going to be offline for a week and don't want to be a bottleneck.
I'll catch up when I'm back.
Stefan
From: Jason Wang <hidden> Date: 2021-04-16 02:20:47
在 2021/4/15 下午7:17, Yongji Xie 写道:
On Thu, Apr 15, 2021 at 5:05 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/15 下午4:36, Jason Wang 写道:
quoted
quoted
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel
which means IOMMU is probably the only thing to prevent a malicous
device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the
coherent area, if we want to enforce stronger isolation we need to use
shadow virtqueue (which is proposed in earlier version by me) in this
case. But I'm not sure it's worth to do that.
I might miss something. But VDUSE has recorded the dma address during
dma mapping, so we would not do bouncing if the addr/length is invalid
during dma unmapping. Is it enough?
E.g malicous device write a buggy dma address in the descriptor ring, so
we had:
vring_unmap_one_split(desc->addr, desc->len)
dma_unmap_single()
vduse_dev_unmap_page()
vduse_domain_bounce()
And in vduse_domain_bounce() we had:
while (size) {
map = &domain->bounce_maps[iova >> PAGE_SHIFT];
offset = offset_in_page(iova);
sz = min_t(size_t, PAGE_SIZE - offset, size);
This means we trust the iova which is dangerous and exacly the issue
mentioned in the above link.
From VDUSE level need to make sure iova is legal.
From virtio level, we should not truse desc->addr.
Thanks
From: Jason Wang <hidden> Date: 2021-04-16 02:24:18
在 2021/4/15 下午10:38, Stefan Hajnoczi 写道:
On Thu, Apr 15, 2021 at 04:36:35PM +0800, Jason Wang wrote:
quoted
在 2021/4/15 下午3:19, Stefan Hajnoczi 写道:
quoted
On Thu, Apr 15, 2021 at 01:38:37PM +0800, Yongji Xie wrote:
quoted
On Wed, Apr 14, 2021 at 10:15 PM Stefan Hajnoczi [off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
Just looking over the documentation briefly (I haven't studied the code
yet)...
Thank you!
quoted
quoted
+How VDUSE works
+------------
+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
+the character device (/dev/vduse/control). Then a device file with the
+specified name (/dev/vduse/$NAME) will appear, which can be used to
+implement the userspace vDPA device's control path and data path.
These steps are taken after sending the VDPA_CMD_DEV_NEW netlink
message? (Please consider reordering the documentation to make it clear
what the sequence of steps are.)
No, VDUSE devices should be created before sending the
VDPA_CMD_DEV_NEW netlink messages which might produce I/Os to VDUSE.
I see. Please include an overview of the steps before going into detail.
Something like:
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:
...
What are the permission/capability requirements for VDUSE?
Now I think we need privileged permission (root user). Because
userspace daemon is able to access avail vring, used vring, descriptor
table in kernel driver directly.
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel which
means IOMMU is probably the only thing to prevent a malicous device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the coherent
area, if we want to enforce stronger isolation we need to use shadow
virtqueue (which is proposed in earlier version by me) in this case. But I'm
not sure it's worth to do that.
The security situation needs to be clear before merging this feature.
+1
I think the IOMMU and vring can be made secure. What is more concerning
is the kernel code that runs on top: VIRTIO device drivers, network
stack, file systems, etc. They trust devices to an extent.
Since virtio-vdpa is a big reason for doing VDUSE in the first place I
don't think it makes sense to disable virtio-vdpa with VDUSE. A solution
is needed.
Yes, so the case of VDUSE is something similar to the case of e.g SEV.
Both cases won't trust device and use some kind of software IOTLB.
That means we need to protect at both IOTLB and virtio drivers.
Let me post patches for virtio first.
I'm going to be offline for a week and don't want to be a bottleneck.
I'll catch up when I'm back.
Thanks a lot for comments and I think we had sufficent time to make
VDUSE safe before merging.
On Fri, Apr 16, 2021 at 10:20 AM Jason Wang [off-list ref] wrote:
在 2021/4/15 下午7:17, Yongji Xie 写道:
quoted
On Thu, Apr 15, 2021 at 5:05 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/15 下午4:36, Jason Wang 写道:
quoted
quoted
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel
which means IOMMU is probably the only thing to prevent a malicous
device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the
coherent area, if we want to enforce stronger isolation we need to use
shadow virtqueue (which is proposed in earlier version by me) in this
case. But I'm not sure it's worth to do that.
I might miss something. But VDUSE has recorded the dma address during
dma mapping, so we would not do bouncing if the addr/length is invalid
during dma unmapping. Is it enough?
E.g malicous device write a buggy dma address in the descriptor ring, so
we had:
vring_unmap_one_split(desc->addr, desc->len)
dma_unmap_single()
vduse_dev_unmap_page()
vduse_domain_bounce()
And in vduse_domain_bounce() we had:
while (size) {
map = &domain->bounce_maps[iova >> PAGE_SHIFT];
offset = offset_in_page(iova);
sz = min_t(size_t, PAGE_SIZE - offset, size);
This means we trust the iova which is dangerous and exacly the issue
mentioned in the above link.
From VDUSE level need to make sure iova is legal.
I think we already do that in vduse_domain_bounce():
while (size) {
map = &domain->bounce_maps[iova >> PAGE_SHIFT];
if (WARN_ON(!map->bounce_page ||
map->orig_phys == INVALID_PHYS_ADDR))
return;
From virtio level, we should not truse desc->addr.
We would not touch desc->addr after vring_unmap_one_split(). So I'm
not sure what we need to do at the virtio level.
Thanks,
Yongji
From: Jason Wang <hidden> Date: 2021-04-16 03:03:23
在 2021/4/16 上午10:58, Yongji Xie 写道:
On Fri, Apr 16, 2021 at 10:20 AM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/15 下午7:17, Yongji Xie 写道:
quoted
On Thu, Apr 15, 2021 at 5:05 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/15 下午4:36, Jason Wang 写道:
quoted
quoted
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel
which means IOMMU is probably the only thing to prevent a malicous
device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the
coherent area, if we want to enforce stronger isolation we need to use
shadow virtqueue (which is proposed in earlier version by me) in this
case. But I'm not sure it's worth to do that.
I might miss something. But VDUSE has recorded the dma address during
dma mapping, so we would not do bouncing if the addr/length is invalid
during dma unmapping. Is it enough?
E.g malicous device write a buggy dma address in the descriptor ring, so
we had:
vring_unmap_one_split(desc->addr, desc->len)
dma_unmap_single()
vduse_dev_unmap_page()
vduse_domain_bounce()
And in vduse_domain_bounce() we had:
while (size) {
map = &domain->bounce_maps[iova >> PAGE_SHIFT];
offset = offset_in_page(iova);
sz = min_t(size_t, PAGE_SIZE - offset, size);
This means we trust the iova which is dangerous and exacly the issue
mentioned in the above link.
From VDUSE level need to make sure iova is legal.
I think we already do that in vduse_domain_bounce():
while (size) {
map = &domain->bounce_maps[iova >> PAGE_SHIFT];
if (WARN_ON(!map->bounce_page ||
map->orig_phys == INVALID_PHYS_ADDR))
return;
So you don't check whether iova is legal before using it, so it's at
least a possible out of bound access of the bounce_maps[] isn't it? (e.g
what happens if iova is ULLONG_MAX).
quoted
From virtio level, we should not truse desc->addr.
We would not touch desc->addr after vring_unmap_one_split(). So I'm
not sure what we need to do at the virtio level.
I think the point is to record the dma addres/len somewhere instead of
reading them from descriptor ring.
Thanks
On Thu, Apr 15, 2021 at 10:38 PM Stefan Hajnoczi [off-list ref] wrote:
On Thu, Apr 15, 2021 at 04:36:35PM +0800, Jason Wang wrote:
quoted
在 2021/4/15 下午3:19, Stefan Hajnoczi 写道:
quoted
On Thu, Apr 15, 2021 at 01:38:37PM +0800, Yongji Xie wrote:
quoted
On Wed, Apr 14, 2021 at 10:15 PM Stefan Hajnoczi [off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
Just looking over the documentation briefly (I haven't studied the code
yet)...
Thank you!
quoted
quoted
+How VDUSE works
+------------
+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
+the character device (/dev/vduse/control). Then a device file with the
+specified name (/dev/vduse/$NAME) will appear, which can be used to
+implement the userspace vDPA device's control path and data path.
These steps are taken after sending the VDPA_CMD_DEV_NEW netlink
message? (Please consider reordering the documentation to make it clear
what the sequence of steps are.)
No, VDUSE devices should be created before sending the
VDPA_CMD_DEV_NEW netlink messages which might produce I/Os to VDUSE.
I see. Please include an overview of the steps before going into detail.
Something like:
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:
...
What are the permission/capability requirements for VDUSE?
Now I think we need privileged permission (root user). Because
userspace daemon is able to access avail vring, used vring, descriptor
table in kernel driver directly.
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel which
means IOMMU is probably the only thing to prevent a malicous device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the coherent
area, if we want to enforce stronger isolation we need to use shadow
virtqueue (which is proposed in earlier version by me) in this case. But I'm
not sure it's worth to do that.
The security situation needs to be clear before merging this feature.
I think the IOMMU and vring can be made secure. What is more concerning
is the kernel code that runs on top: VIRTIO device drivers, network
stack, file systems, etc. They trust devices to an extent.
I will dig into it to see if there is any security issue.
Since virtio-vdpa is a big reason for doing VDUSE in the first place I
don't think it makes sense to disable virtio-vdpa with VDUSE. A solution
is needed.
I'm going to be offline for a week and don't want to be a bottleneck.
I'll catch up when I'm back.
On Fri, Apr 16, 2021 at 11:03 AM Jason Wang [off-list ref] wrote:
在 2021/4/16 上午10:58, Yongji Xie 写道:
quoted
On Fri, Apr 16, 2021 at 10:20 AM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/15 下午7:17, Yongji Xie 写道:
quoted
On Thu, Apr 15, 2021 at 5:05 PM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/15 下午4:36, Jason Wang 写道:
quoted
quoted
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel
which means IOMMU is probably the only thing to prevent a malicous
device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the
coherent area, if we want to enforce stronger isolation we need to use
shadow virtqueue (which is proposed in earlier version by me) in this
case. But I'm not sure it's worth to do that.
I might miss something. But VDUSE has recorded the dma address during
dma mapping, so we would not do bouncing if the addr/length is invalid
during dma unmapping. Is it enough?
E.g malicous device write a buggy dma address in the descriptor ring, so
we had:
vring_unmap_one_split(desc->addr, desc->len)
dma_unmap_single()
vduse_dev_unmap_page()
vduse_domain_bounce()
And in vduse_domain_bounce() we had:
while (size) {
map = &domain->bounce_maps[iova >> PAGE_SHIFT];
offset = offset_in_page(iova);
sz = min_t(size_t, PAGE_SIZE - offset, size);
This means we trust the iova which is dangerous and exacly the issue
mentioned in the above link.
From VDUSE level need to make sure iova is legal.
I think we already do that in vduse_domain_bounce():
while (size) {
map = &domain->bounce_maps[iova >> PAGE_SHIFT];
if (WARN_ON(!map->bounce_page ||
map->orig_phys == INVALID_PHYS_ADDR))
return;
So you don't check whether iova is legal before using it, so it's at
least a possible out of bound access of the bounce_maps[] isn't it? (e.g
what happens if iova is ULLONG_MAX).
Oh, yes. Will do it!
quoted
quoted
From virtio level, we should not truse desc->addr.
We would not touch desc->addr after vring_unmap_one_split(). So I'm
not sure what we need to do at the virtio level.
I think the point is to record the dma addres/len somewhere instead of
reading them from descriptor ring.
On Fri, Apr 16, 2021 at 10:24 AM Jason Wang [off-list ref] wrote:
在 2021/4/15 下午10:38, Stefan Hajnoczi 写道:
quoted
On Thu, Apr 15, 2021 at 04:36:35PM +0800, Jason Wang wrote:
quoted
在 2021/4/15 下午3:19, Stefan Hajnoczi 写道:
quoted
On Thu, Apr 15, 2021 at 01:38:37PM +0800, Yongji Xie wrote:
quoted
On Wed, Apr 14, 2021 at 10:15 PM Stefan Hajnoczi [off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
Just looking over the documentation briefly (I haven't studied the code
yet)...
Thank you!
quoted
quoted
+How VDUSE works
+------------
+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
+the character device (/dev/vduse/control). Then a device file with the
+specified name (/dev/vduse/$NAME) will appear, which can be used to
+implement the userspace vDPA device's control path and data path.
These steps are taken after sending the VDPA_CMD_DEV_NEW netlink
message? (Please consider reordering the documentation to make it clear
what the sequence of steps are.)
No, VDUSE devices should be created before sending the
VDPA_CMD_DEV_NEW netlink messages which might produce I/Os to VDUSE.
I see. Please include an overview of the steps before going into detail.
Something like:
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:
...
What are the permission/capability requirements for VDUSE?
Now I think we need privileged permission (root user). Because
userspace daemon is able to access avail vring, used vring, descriptor
table in kernel driver directly.
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel which
means IOMMU is probably the only thing to prevent a malicous device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the coherent
area, if we want to enforce stronger isolation we need to use shadow
virtqueue (which is proposed in earlier version by me) in this case. But I'm
not sure it's worth to do that.
The security situation needs to be clear before merging this feature.
+1
quoted
I think the IOMMU and vring can be made secure. What is more concerning
is the kernel code that runs on top: VIRTIO device drivers, network
stack, file systems, etc. They trust devices to an extent.
Since virtio-vdpa is a big reason for doing VDUSE in the first place I
don't think it makes sense to disable virtio-vdpa with VDUSE. A solution
is needed.
Yes, so the case of VDUSE is something similar to the case of e.g SEV.
Both cases won't trust device and use some kind of software IOTLB.
That means we need to protect at both IOTLB and virtio drivers.
Let me post patches for virtio first.
From: Jason Wang <hidden> Date: 2021-04-16 03:24:42
在 2021/3/31 下午4:05, Xie Yongji 写道:
+ }
+ case VDUSE_INJECT_VQ_IRQ:
+ ret = -EINVAL;
+ if (arg >= dev->vq_num)
+ break;
+
+ ret = 0;
+ queue_work(vduse_irq_wq, &dev->vqs[arg].inject);
+ break;
One additional note:
Please use array_index_nospec() for all vqs[idx] access where idx is
under the control of userspace to avoid potential spectre exploitation.
Thanks
From: Jason Wang <hidden> Date: 2021-04-16 05:40:03
在 2021/4/16 上午11:19, Yongji Xie 写道:
On Fri, Apr 16, 2021 at 10:24 AM Jason Wang [off-list ref] wrote:
quoted
在 2021/4/15 下午10:38, Stefan Hajnoczi 写道:
quoted
On Thu, Apr 15, 2021 at 04:36:35PM +0800, Jason Wang wrote:
quoted
在 2021/4/15 下午3:19, Stefan Hajnoczi 写道:
quoted
On Thu, Apr 15, 2021 at 01:38:37PM +0800, Yongji Xie wrote:
quoted
On Wed, Apr 14, 2021 at 10:15 PM Stefan Hajnoczi [off-list ref] wrote:
quoted
On Wed, Mar 31, 2021 at 04:05:19PM +0800, Xie Yongji wrote:
quoted
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 <redacted>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 212 ++++++++++++++++++++++++++++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
Just looking over the documentation briefly (I haven't studied the code
yet)...
Thank you!
quoted
quoted
+How VDUSE works
+------------
+Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
+the character device (/dev/vduse/control). Then a device file with the
+specified name (/dev/vduse/$NAME) will appear, which can be used to
+implement the userspace vDPA device's control path and data path.
These steps are taken after sending the VDPA_CMD_DEV_NEW netlink
message? (Please consider reordering the documentation to make it clear
what the sequence of steps are.)
No, VDUSE devices should be created before sending the
VDPA_CMD_DEV_NEW netlink messages which might produce I/Os to VDUSE.
I see. Please include an overview of the steps before going into detail.
Something like:
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:
...
What are the permission/capability requirements for VDUSE?
Now I think we need privileged permission (root user). Because
userspace daemon is able to access avail vring, used vring, descriptor
table in kernel driver directly.
Please state this explicitly at the start of the document. Existing
interfaces like FUSE are designed to avoid trusting userspace.
There're some subtle difference here. VDUSE present a device to kernel which
means IOMMU is probably the only thing to prevent a malicous device.
quoted
Therefore
people might think the same is the case here. It's critical that people
are aware of this before deploying VDUSE with virtio-vdpa.
We should probably pause here and think about whether it's possible to
avoid trusting userspace. Even if it takes some effort and costs some
performance it would probably be worthwhile.
Since the bounce buffer is used the only attack surface is the coherent
area, if we want to enforce stronger isolation we need to use shadow
virtqueue (which is proposed in earlier version by me) in this case. But I'm
not sure it's worth to do that.
The security situation needs to be clear before merging this feature.
+1
quoted
I think the IOMMU and vring can be made secure. What is more concerning
is the kernel code that runs on top: VIRTIO device drivers, network
stack, file systems, etc. They trust devices to an extent.
Since virtio-vdpa is a big reason for doing VDUSE in the first place I
don't think it makes sense to disable virtio-vdpa with VDUSE. A solution
is needed.
Yes, so the case of VDUSE is something similar to the case of e.g SEV.
Both cases won't trust device and use some kind of software IOTLB.
That means we need to protect at both IOTLB and virtio drivers.
Let me post patches for virtio first.
Looking forward your patches.
Thanks.
Yongji
Fortuantely, packed ring has already did this since the descriptor talbe
is expected to be re-wrote by the device. I just need to conver the
split ring.
Thanks
On Fri, Apr 16, 2021 at 11:24 AM Jason Wang [off-list ref] wrote:
在 2021/3/31 下午4:05, Xie Yongji 写道:
quoted
+ }
+ case VDUSE_INJECT_VQ_IRQ:
+ ret = -EINVAL;
+ if (arg >= dev->vq_num)
+ break;
+
+ ret = 0;
+ queue_work(vduse_irq_wq, &dev->vqs[arg].inject);
+ break;
One additional note:
Please use array_index_nospec() for all vqs[idx] access where idx is
under the control of userspace to avoid potential spectre exploitation.