[PATCH v3 0/4] misc: vmw_zerocopy: VMware zero-copy buffer sharing driver

[Rishi Chhibber <rishi.chhibber@broadcom.com>]

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/

Transport choice, discussed in the v2 thread:
https://lore.kernel.org/lkml/CABJwUKKCwGxYB0is-U84EgAm6Co9_bfxbkZi56jZNLkzihDRyw@mail.gmail.com/

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