1==================================
2VDUSE - "vDPA Device in Userspace"
3==================================
4
5vDPA (virtio data path acceleration) device is a device that uses a
6datapath which complies with the virtio specifications with vendor
7specific control path. vDPA devices can be both physically located on
8the hardware or emulated by software. VDUSE is a framework that makes it
9possible to implement software-emulated vDPA devices in userspace. And
10to make the device emulation more secure, the emulated vDPA device's
11control path is handled in the kernel and only the data path is
12implemented in the userspace.
13
14Note that only virtio block device is supported by VDUSE framework now,
15which can reduce security risks when the userspace process that implements
16the data path is run by an unprivileged user. The support for other device
17types can be added after the security issue of corresponding device driver
18is clarified or fixed in the future.
19
20Create/Destroy VDUSE devices
21------------------------
22
23VDUSE devices are created as follows:
24
251. Create a new VDUSE instance with ioctl(VDUSE_CREATE_DEV) on
26   /dev/vduse/control.
27
282. Setup each virtqueue with ioctl(VDUSE_VQ_SETUP) on /dev/vduse/$NAME.
29
303. Begin processing VDUSE messages from /dev/vduse/$NAME. The first
31   messages will arrive while attaching the VDUSE instance to vDPA bus.
32
334. Send the VDPA_CMD_DEV_NEW netlink message to attach the VDUSE
34   instance to vDPA bus.
35
36VDUSE devices are destroyed as follows:
37
381. Send the VDPA_CMD_DEV_DEL netlink message to detach the VDUSE
39   instance from vDPA bus.
40
412. Close the file descriptor referring to /dev/vduse/$NAME.
42
433. Destroy the VDUSE instance with ioctl(VDUSE_DESTROY_DEV) on
44   /dev/vduse/control.
45
46The netlink messages can be sent via vdpa tool in iproute2 or use the
47below sample codes:
48
49.. code-block:: c
50
51	static int netlink_add_vduse(const char *name, enum vdpa_command cmd)
52	{
53		struct nl_sock *nlsock;
54		struct nl_msg *msg;
55		int famid;
56
57		nlsock = nl_socket_alloc();
58		if (!nlsock)
59			return -ENOMEM;
60
61		if (genl_connect(nlsock))
62			goto free_sock;
63
64		famid = genl_ctrl_resolve(nlsock, VDPA_GENL_NAME);
65		if (famid < 0)
66			goto close_sock;
67
68		msg = nlmsg_alloc();
69		if (!msg)
70			goto close_sock;
71
72		if (!genlmsg_put(msg, NL_AUTO_PORT, NL_AUTO_SEQ, famid, 0, 0, cmd, 0))
73			goto nla_put_failure;
74
75		NLA_PUT_STRING(msg, VDPA_ATTR_DEV_NAME, name);
76		if (cmd == VDPA_CMD_DEV_NEW)
77			NLA_PUT_STRING(msg, VDPA_ATTR_MGMTDEV_DEV_NAME, "vduse");
78
79		if (nl_send_sync(nlsock, msg))
80			goto close_sock;
81
82		nl_close(nlsock);
83		nl_socket_free(nlsock);
84
85		return 0;
86	nla_put_failure:
87		nlmsg_free(msg);
88	close_sock:
89		nl_close(nlsock);
90	free_sock:
91		nl_socket_free(nlsock);
92		return -1;
93	}
94
95How VDUSE works
96---------------
97
98As mentioned above, a VDUSE device is created by ioctl(VDUSE_CREATE_DEV) on
99/dev/vduse/control. With this ioctl, userspace can specify some basic configuration
100such as device name (uniquely identify a VDUSE device), virtio features, virtio
101configuration space, the number of virtqueues and so on for this emulated device.
102Then a char device interface (/dev/vduse/$NAME) is exported to userspace for device
103emulation. Userspace can use the VDUSE_VQ_SETUP ioctl on /dev/vduse/$NAME to
104add per-virtqueue configuration such as the max size of virtqueue to the device.
105
106After the initialization, the VDUSE device can be attached to vDPA bus via
107the VDPA_CMD_DEV_NEW netlink message. Userspace needs to read()/write() on
108/dev/vduse/$NAME to receive/reply some control messages from/to VDUSE kernel
109module as follows:
110
111.. code-block:: c
112
113	static int vduse_message_handler(int dev_fd)
114	{
115		int len;
116		struct vduse_dev_request req;
117		struct vduse_dev_response resp;
118
119		len = read(dev_fd, &req, sizeof(req));
120		if (len != sizeof(req))
121			return -1;
122
123		resp.request_id = req.request_id;
124
125		switch (req.type) {
126
127		/* handle different types of messages */
128
129		}
130
131		len = write(dev_fd, &resp, sizeof(resp));
132		if (len != sizeof(resp))
133			return -1;
134
135		return 0;
136	}
137
138There are now three types of messages introduced by VDUSE framework:
139
140- VDUSE_GET_VQ_STATE: Get the state for virtqueue, userspace should return
141  avail index for split virtqueue or the device/driver ring wrap counters and
142  the avail and used index for packed virtqueue.
143
144- VDUSE_SET_STATUS: Set the device status, userspace should follow
145  the virtio spec: https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.html
146  to process this message. For example, fail to set the FEATURES_OK device
147  status bit if the device can not accept the negotiated virtio features
148  get from the VDUSE_DEV_GET_FEATURES ioctl.
149
150- VDUSE_UPDATE_IOTLB: Notify userspace to update the memory mapping for specified
151  IOVA range, userspace should firstly remove the old mapping, then setup the new
152  mapping via the VDUSE_IOTLB_GET_FD ioctl.
153
154After DRIVER_OK status bit is set via the VDUSE_SET_STATUS message, userspace is
155able to start the dataplane processing as follows:
156
1571. Get the specified virtqueue's information with the VDUSE_VQ_GET_INFO ioctl,
158   including the size, the IOVAs of descriptor table, available ring and used ring,
159   the state and the ready status.
160
1612. Pass the above IOVAs to the VDUSE_IOTLB_GET_FD ioctl so that those IOVA regions
162   can be mapped into userspace. Some sample codes is shown below:
163
164.. code-block:: c
165
166	static int perm_to_prot(uint8_t perm)
167	{
168		int prot = 0;
169
170		switch (perm) {
171		case VDUSE_ACCESS_WO:
172			prot |= PROT_WRITE;
173			break;
174		case VDUSE_ACCESS_RO:
175			prot |= PROT_READ;
176			break;
177		case VDUSE_ACCESS_RW:
178			prot |= PROT_READ | PROT_WRITE;
179			break;
180		}
181
182		return prot;
183	}
184
185	static void *iova_to_va(int dev_fd, uint64_t iova, uint64_t *len)
186	{
187		int fd;
188		void *addr;
189		size_t size;
190		struct vduse_iotlb_entry entry;
191
192		entry.start = iova;
193		entry.last = iova;
194
195		/*
196		 * Find the first IOVA region that overlaps with the specified
197		 * range [start, last] and return the corresponding file descriptor.
198		 */
199		fd = ioctl(dev_fd, VDUSE_IOTLB_GET_FD, &entry);
200		if (fd < 0)
201			return NULL;
202
203		size = entry.last - entry.start + 1;
204		*len = entry.last - iova + 1;
205		addr = mmap(0, size, perm_to_prot(entry.perm), MAP_SHARED,
206			    fd, entry.offset);
207		close(fd);
208		if (addr == MAP_FAILED)
209			return NULL;
210
211		/*
212		 * Using some data structures such as linked list to store
213		 * the iotlb mapping. The munmap(2) should be called for the
214		 * cached mapping when the corresponding VDUSE_UPDATE_IOTLB
215		 * message is received or the device is reset.
216		 */
217
218		return addr + iova - entry.start;
219	}
220
2213. Setup the kick eventfd for the specified virtqueues with the VDUSE_VQ_SETUP_KICKFD
222   ioctl. The kick eventfd is used by VDUSE kernel module to notify userspace to
223   consume the available ring. This is optional since userspace can choose to poll the
224   available ring instead.
225
2264. Listen to the kick eventfd (optional) and consume the available ring. The buffer
227   described by the descriptors in the descriptor table should be also mapped into
228   userspace via the VDUSE_IOTLB_GET_FD ioctl before accessing.
229
2305. Inject an interrupt for specific virtqueue with the VDUSE_INJECT_VQ_IRQ ioctl
231   after the used ring is filled.
232
233For more details on the uAPI, please see include/uapi/linux/vduse.h.
234