Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Documentation: Add documentation for VDUSE Address Space IDs

Address Space IDs allows the VDUSE framework to support devices able to
expose different virtqueues to different part of the drivers. For
example, to let QEMU handle the net device control virtqueue, so QEMU
always knows the state of the device like mac address or number of
queues enabled, while leaving the dataplane passthrough to the guest
intact. This enables live migration.

Expands the VDUSE documentation to explain how to use the new ioctls or
the new struct members of old ioctls.

Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260119143306.1818855-14-eperezma@redhat.com>

authored by

Eugenio Pérez and committed by
Michael S. Tsirkin
7a9dc249 12e0043d

+53
+53
Documentation/userspace-api/vduse.rst
··· 230 230 5. Inject an interrupt for specific virtqueue with the VDUSE_INJECT_VQ_IRQ ioctl 231 231 after the used ring is filled. 232 232 233 + Enabling ASID (API version 1) 234 + ------------------------------ 235 + 236 + VDUSE supports per-address-space identifiers (ASIDs) starting with API 237 + version 1. Set it up with ioctl(VDUSE_SET_API_VERSION) on `/dev/vduse/control` 238 + and pass `VDUSE_API_VERSION_1` before creating a new VDUSE instance with 239 + ioctl(VDUSE_CREATE_DEV). 240 + 241 + Afterwards, you can use the member asid of ioctl(VDUSE_VQ_SETUP) argument to 242 + select the address space of the IOTLB you are querying. The driver could 243 + change the address space of any virtqueue group by using the 244 + VDUSE_SET_VQ_GROUP_ASID VDUSE message type, and the VDUSE instance needs to 245 + reply with VDUSE_REQ_RESULT_OK if it was possible to change it. 246 + 247 + Similarly, you can use ioctl(VDUSE_IOTLB_GET_FD2) to obtain the file descriptor 248 + describing an IOVA region of a specific ASID. Example usage: 249 + 250 + .. code-block:: c 251 + 252 + static void *iova_to_va(int dev_fd, uint32_t asid, uint64_t iova, 253 + uint64_t *len) 254 + { 255 + int fd; 256 + void *addr; 257 + size_t size; 258 + struct vduse_iotlb_entry_v2 entry = { 0 }; 259 + 260 + entry.v1.start = iova; 261 + entry.v1.last = iova; 262 + entry.asid = asid; 263 + 264 + fd = ioctl(dev_fd, VDUSE_IOTLB_GET_FD2, &entry); 265 + if (fd < 0) 266 + return NULL; 267 + 268 + size = entry.v1.last - entry.v1.start + 1; 269 + *len = entry.v1.last - iova + 1; 270 + addr = mmap(0, size, perm_to_prot(entry.v1.perm), MAP_SHARED, 271 + fd, entry.v1.offset); 272 + close(fd); 273 + if (addr == MAP_FAILED) 274 + return NULL; 275 + 276 + /* 277 + * Using some data structures such as linked list to store 278 + * the iotlb mapping. The munmap(2) should be called for the 279 + * cached mapping when the corresponding VDUSE_UPDATE_IOTLB 280 + * message is received or the device is reset. 281 + */ 282 + 283 + return addr + iova - entry.v1.start; 284 + } 285 + 233 286 For more details on the uAPI, please see include/uapi/linux/vduse.h.