Re: [PATCH v2] misc: vmw_zerocopy: Add VMware zero-copy buffer sharing driver

[Rishi Chhibber]

Hi Greg,

That is a fair question - virtio is the correct choice for paravirtual I/O.

The reason we need a new driver is that this driver belongs

to a different category from I/O: the guest is not sending data to a

virtual device; it is handing page frame numbers to the hypervisor for

quick and direct processing, and reading back the results in (one of) 

those same pages inline - with no copy and no ring buffer.

No existing virtio device type provides this, independent of the transport 

the hypervisor peer happens to use.

There are two fundamental features in the current driver that have

no mapping onto existing virtio interfaces:

1. PFN-level zero copy without ownership transfer.

   This driver calls pin_user_pages_fast(), collects the page frame

   numbers, and sends them to the host in a VMCI datagram.  The host

   maps those frames directly and processes them.

   virtio-vsock copies data through the virtqueue ring buffer.

   virtio-mem/balloon transfer page *ownership* to the host; the guest

   loses the pages.  Here the guest retains the pages and unpins them

   after the ioctl returns.

   This is useful when the guest needs to know the hypervisor has

   finished processing the buffer before reusing or freeing it.

2. Per-ioctl synchronous feedback via writable pinned pages.

   The driver allows pinning two sets of pages per call:

     - data buffer:     pinned read-only  (host reads the payload)

     - metadata buffer: pinned writable   (host writes results back)

   After the datagram is sent, the hypervisor processes the data buffer

   paired with the metadata, then writes per-operation status *directly

   into the pinned metadata pages*.  Userspace reads the metadata buffer

   synchronously on ioctl return and can perform an informed follow-up

   operation immediately.

   The existing comparable drivers do not do this.

   storvsc and hv_balloon send a separate response packet over the VMBus

   ring and block on wait_for_completion_timeout() to receive it - the result

   travels through the ring buffer, not back into the original request

   pages.

   Xen gntdev supports writable grant mappings and UNMAP_NOTIFY_CLEAR_BYTE

   (a single byte written into the page on unmap), but those serve persistent

   ring buffer lifecycles, not per-ioctl synchronous result delivery.

## How other hypervisors handle this:

The pattern across every major hypervisor in the kernel is a thin

guest driver over the vendor's native transport.

Some Examples:

Hyper-V:

netvsc_drv ("Microsoft Hyper-V network driver") and storvsc_drv

("Microsoft Hyper-V virtual storage driver") run over VMBus.

hv_balloon runs over VMBus rather than virtio-balloon.  For direct

memory sharing, Hyper-V uses GPADL (Guest Physical Address Descriptor

List): the guest builds a list of page frame numbers and hands it to the

host with vmbus_establish_gpadl() so the host can map those frames directly.

The same primitive this driver uses over VMCI.

Xen:

xen-netfront and xen-blkfront run over XenBus via

xenbus_register_frontend().  xen-netfront calls gnttab_grant_foreign at

25 sites to share guest page frames with the backend - Xen's equivalent of

GPADL.  gntdev ("User-space granted page access driver") goes further and

exposes Xen's grant-table page-sharing mechanism directly to userspace as a

misc character device - the closest structural precedent to this driver already

present in the tree.

vmxnet3:

VMware already has vmxnet3 (custom network), vmw_pvscsi (custom SCSI)

and vmw_balloon (custom ballooning), all using VMware's own protocols

rather than their virtio equivalents.

The established upstream approach for a hypervisor-specific interface

- especially one involving direct host access to guest pages - is a

thin guest driver over the vendor's native transport.

In conclusion, this driver provides a minimal design for inline page

passing and synchronous feedback, with no additional kernel

infrastructure, separate ring buffers, or polling mechanisms required.

I continue to get the changes reviewed and approved internally and will share the

updated patch soon.

Regards,

- Rishi

On Fri, Jul 17, 2026 at 6:44 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:

On Thu, Jun 18, 2026 at 11:10:34AM -0700, Rishi Chhibber wrote:
> This driver implements a misc character device (/dev/vmw_zc) that allows
> guest userspace applications to share pinned memory buffers with a
> VMware hypervisor-side peer using the VMCI datagram interface.
>
> The driver pins user pages via get_user_pages_fast(), transmits their
> physical page frame numbers to the hypervisor peer over VMCI, and avoids
> an intermediate copy between the guest workload VM and the hypervisor.
>
> The hypervisor-side peer for this interface only speaks VMCI; there is no
> virtio backend implemented on the VMware host for it. The closest
> existing upstream transport, vsock (virtio-vsock), provides a socket
> bytestream/datagram abstraction and does not expose a way to hand a set
> of pinned guest page frame numbers to the host for true zero-copy
> access; it would still require copying the payload through the socket.
> This driver's purpose is specifically to pin guest pages and pass their
> PFNs to the host so the payload is never copied. It also supports
> bundling multiple buffers in a single request, which is required for the
> all-or-none semantics of page-level zero-copy transfers.

Ah, wait, i see why this is needed.  Why not just add the needed
functionality to virtio instead?  Surely other hypervisors (like hyperv)
need/want to do this same thing?  How do they do it?  Through custom
drivers like this or through something else?

thanks,

greg k-h

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature