[PATCH v3 0/4] misc: vmw_zerocopy: VMware zero-copy buffer sharing driver
From: Rishi Chhibber <hidden>
Date: 2026-09-14 20:24:15
Also in:
linux-kselftest, lkml
Summary of changes: - 1/4 reserves a VMCI datagram resource id for the hypervisor-side zero-copy service - 2/4 adds the vmw_zerocopy driver: /dev/vmw_zc, a single ioctl, page pinning and the VMCI datagram transport - 3/4 documents the userspace interface - 4/4 adds a kselftest covering the ioctl input-validation paths This series adds a misc character device, /dev/vmw_zc, that lets guest userspace hand a buffer to a VMware hypervisor-side peer without copying it. The driver pins the user pages, collects their guest physical frame numbers and sends that list over a VMCI datagram; the hypervisor then reads the buffer directly out of guest memory. An optional metadata buffer is pinned writable so the peer can return a result through the same mechanism. Why not vsock or virtio: this is not paravirtual I/O. The guest is not sending data to a virtual device; it hands page frame numbers to the hypervisor and reads the results back inline in those same pages, with no copy and no ring buffer. Two properties have no mapping onto an existing virtio device type: - PFN-level zero copy without ownership transfer. virtio-vsock copies through the virtqueue ring. virtio-mem and virtio-balloon transfer page ownership to the host; here the guest keeps its pages and unpins them when the ioctl returns. - Per-ioctl synchronous feedback. The metadata pages are pinned writable and the peer stores status directly into them, so userspace reads the result on ioctl return. storvsc and hv_balloon return status in a separate ring packet instead; Xen gntdev's writable grants and UNMAP_NOTIFY_CLEAR_BYTE serve persistent ring lifecycles, not per-call results. The established upstream shape for this is a thin guest driver over the vendor's native transport: Hyper-V builds a PFN list for the host with vmbus_establish_gpadl(), Xen shares frames through the grant table and exposes that to userspace in gntdev, and VMware already has vmxnet3, vmw_pvscsi and vmw_balloon on its own protocols. This driver is the VMCI equivalent. Discussed in full in the v2 thread (linked below); 2/4 carries the short form. v2 was posted as a single patch and is split here into a reviewable series along file boundaries: every file belongs entirely to one patch, so each commit builds on its own. 1/4 comes first because 2/4 sends to the resource id it reserves, and because it has a different maintainer set. vmw_zerocopy_core.c and vmw_zerocopy_vmci.c stay in one patch as they form a single module and reference each other. Changes since v2: - Split the single patch into this four-patch series - The destination is now owned by the kernel: the userspace-supplied peer_id is gone, and that word is a reserved field that must be zero - Dropped VMW_ZC_MSG_INIT and struct vmw_zc_ioctl_config; the device needs no configuration step - Release metadata pages with unpin_user_pages_dirty_lock(..., true); the peer stores through the physical frame, so nothing else marks those pages dirty - Split the VMCI transport out behind a small transport ops struct - Dropped the out-of-tree KBUILD_EXTMOD build logic from drivers/misc/Makefile (Greg Kroah-Hartman) - Removed __user from struct vmw_zc_guest_raw_buffer; it has no place in an ioctl structure (Greg Kroah-Hartman) - Registered ioctl magic 0xDC in ioctl-number.rst - Added driver documentation (3/4) and a selftest (4/4) - Rebased onto v7.3-rc3 Userspace built against the v2 header must be rebuilt: the peer_id field and the configuration ioctl it used no longer exist. Nothing is merged upstream, so no stable ABI is affected. Testing: - Every commit builds on x86_64 with CONFIG_VMW_ZC=m, and make headers_install succeeds at each one - checkpatch.pl --strict reports nothing on 1/4 and 2/4; on 3/4 and 4/4 only the MAINTAINERS advisory for newly added files - The selftest builds, and skips cleanly when /dev/vmw_zc is absent Link to v2: https://lore.kernel.org/lkml/20260619182710.2498154-1-rishi.chhibber@broadcom.com/ (local) Transport choice, discussed in the v2 thread: https://lore.kernel.org/lkml/CABJwUKKCwGxYB0is-U84EgAm6Co9_bfxbkZi56jZNLkzihDRyw@mail.gmail.com/ (local) Rishi Chhibber (4): misc: vmw_vmci: Reserve a datagram resource id for zero-copy buffer sharing misc: vmw_zerocopy: Add VMware zero-copy buffer sharing driver Documentation: misc: Add vmw_zerocopy driver documentation selftests: misc: Add vmw_zerocopy selftest Documentation/misc-devices/index.rst | 1 + Documentation/misc-devices/vmw_zerocopy.rst | 278 ++++++++++++++++++ .../userspace-api/ioctl/ioctl-number.rst | 1 + MAINTAINERS | 10 + drivers/misc/Kconfig | 23 ++ drivers/misc/Makefile | 2 + drivers/misc/vmw_zerocopy_core.c | 267 +++++++++++++++++ drivers/misc/vmw_zerocopy_priv.h | 66 +++++ drivers/misc/vmw_zerocopy_vmci.c | 132 +++++++++ include/linux/vmw_vmci_defs.h | 3 +- include/uapi/linux/vmw_zerocopy.h | 67 +++++ tools/testing/selftests/Makefile | 1 + .../drivers/misc/vmw_zerocopy/.gitignore | 1 + .../drivers/misc/vmw_zerocopy/Makefile | 20 ++ .../drivers/misc/vmw_zerocopy/config | 2 + .../misc/vmw_zerocopy/test_vmw_zerocopy.c | 276 +++++++++++++++++ 16 files changed, 1149 insertions(+), 1 deletion(-) create mode 100644 Documentation/misc-devices/vmw_zerocopy.rst create mode 100644 drivers/misc/vmw_zerocopy_core.c create mode 100644 drivers/misc/vmw_zerocopy_priv.h create mode 100644 drivers/misc/vmw_zerocopy_vmci.c create mode 100644 include/uapi/linux/vmw_zerocopy.h create mode 100644 tools/testing/selftests/drivers/misc/vmw_zerocopy/.gitignore create mode 100644 tools/testing/selftests/drivers/misc/vmw_zerocopy/Makefile create mode 100644 tools/testing/selftests/drivers/misc/vmw_zerocopy/config create mode 100644 tools/testing/selftests/drivers/misc/vmw_zerocopy/test_vmw_zerocopy.c base-commit: fd73f4a6659897191fa0d40695fe370925dd3780 -- 2.52.0