mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Rishi Chhibber <rishi.chhibber@broadcom.com>
Cc: arnd@arndb.de, linux-kernel@vger.kernel.org,
	ajay.kaher@broadcom.com, alexey.makhalov@broadcom.com,
	vamsi-krishna.brahmajosyula@broadcom.com, yin.ding@broadcom.com,
	tapas.kundu@broadcom.com
Subject: Re: [PATCH] misc: vmw_zerocopy: Add VMware zero-copy buffer sharing driver
Date: Thu, 18 Jun 2026 12:26:03 +0200	[thread overview]
Message-ID: <2026061818-slot-foster-bdf0@gregkh> (raw)
In-Reply-To: <20260617203125.397427-1-rishi.chhibber@broadcom.com>

On Wed, Jun 17, 2026 at 01:31:25PM -0700, Rishi Chhibber wrote:
> This driver implements a 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.

Why is this a new char device, don't we already have virtio apis for
this type of thing?

> 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.
> 
> Signed-off-by: Rishi Chhibber <rishi.chhibber@broadcom.com>
> ---
>  MAINTAINERS                                   |   8 +
>  drivers/misc/Kconfig                          |   1 +
>  drivers/misc/Makefile                         |   1 +
>  drivers/misc/vmw_zerocopy/Kconfig             |  16 +
>  drivers/misc/vmw_zerocopy/Makefile            |  17 +
>  .../misc/vmw_zerocopy/vmw_zerocopy_driver.c   | 490 ++++++++++++++++++
>  .../misc/vmw_zerocopy/vmw_zerocopy_driver.h   |  51 ++
>  .../uapi/linux/vmw_zerocopy_ioctl_common.h    |  66 +++
>  8 files changed, 650 insertions(+)
>  create mode 100644 drivers/misc/vmw_zerocopy/Kconfig
>  create mode 100644 drivers/misc/vmw_zerocopy/Makefile
>  create mode 100644 drivers/misc/vmw_zerocopy/vmw_zerocopy_driver.c
>  create mode 100644 drivers/misc/vmw_zerocopy/vmw_zerocopy_driver.h
>  create mode 100644 include/uapi/linux/vmw_zerocopy_ioctl_common.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index efd1fa7d66f0..59ee66158486 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -24790,6 +24790,14 @@ L:	linux-kernel@vger.kernel.org
>  S:	Supported
>  F:	net/vmw_vsock/vmci_transport*
>  
> +VMWARE ZEROCOPY DRIVER
> +M:	Rishi Chhibber <rishi.chhibber@broadcom.com>
> +R:	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>

Please don't put closed lists in the MAINTAINERS file, that just causes
bounces.

> +static int vmw_zc_release(struct inode *inode, struct file *file)
> +{
> +	pr_debug(LGPFX "release\n");
> +	return 0;
> +}

If you do nothing in a function, no need to have it at all, right?

> +static int __init vmw_zc_init(void)
> +{
> +	dev_t dev;
> +	int ret;
> +	struct device *mydev;
> +
> +	pr_info(LGPFX "loading\n");

When drivers work properly, they are quiet.

> +
> +	ret = alloc_chrdev_region(&dev, 0, 1, VMW_ZC_DEVICE_NAME);

As you only want one char device, why not use miscdev instead?


> +	if (ret) {
> +		pr_err(LGPFX "alloc_chrdev_region failed: %d\n", ret);

No need for the LGPFX stuff everywhere, you all do know about pr_fmt(),
right?

> --- /dev/null
> +++ b/drivers/misc/vmw_zerocopy/vmw_zerocopy_driver.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */

I have to ask, are you sure about "or later"?

> +/*
> + * Copyright (c) 2026 Broadcom. All Rights Reserved. The term
> + * "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
> + *
> + * Wire-format messages sent to the peer over VMCI (driver private).
> + * Limits and raw size must stay in sync with include/uapi/linux/vmw_zerocopy_ioctl_common.h

How is that going to happen?  Why not just keep everything in one file?



> + */
> +
> +#ifndef _VMW_ZC_HOST_H
> +#define _VMW_ZC_HOST_H
> +
> +#include <linux/mm.h>
> +#include <linux/types.h>
> +
> +#include <linux/vmw_zerocopy_ioctl_common.h>
> +
> +#define VMW_ZC_MAX_METADATA_SIZE	1024
> +#define VMW_ZC_MAX_BUFFER_SIZE		(64 * 1024UL)
> +#define VMW_ZC_MAX_PAGES \
> +	(((VMW_ZC_MAX_BUFFER_SIZE) + (PAGE_SIZE - 1)) / PAGE_SIZE + 1)
> +
> +struct vmw_zc_msg_unit {
> +	__u32 offset;
> +	__u32 length;
> +	__u32 num_pages;
> +	__u32 padding1;
> +	__u64 page_pfns[VMW_ZC_MAX_PAGES];

Why do you have an internal structure defined with __u32 and the like?
That's only a type that crosses the user/kernel boundry, and it would be
implied this would be defined in the uapi .h file, right?

thanks,

greg k-h

  reply	other threads:[~2026-06-18 10:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17 20:31 Rishi Chhibber
2026-06-18 10:26 ` Greg KH [this message]
2026-06-18 18:10 ` [PATCH v2] " Rishi Chhibber
2026-06-19  5:08   ` Greg KH
2026-06-19  5:10   ` Greg KH
2026-06-19 15:12     ` David Laight
2026-07-17 13:43   ` Greg KH
2026-07-17 13:44   ` Greg KH
2026-06-19 18:27 ` [PATCH] " Rishi Chhibber
2026-06-20  5:04   ` Greg KH
2026-06-20  5:06     ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2026-06-17 20:27 Rishi Chhibber
2026-06-17 20:45 ` Rishi Chhibber
2026-06-17 20:26 Rishi Chhibber
2026-06-17 20:45 ` Rishi Chhibber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026061818-slot-foster-bdf0@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=ajay.kaher@broadcom.com \
    --cc=alexey.makhalov@broadcom.com \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rishi.chhibber@broadcom.com \
    --cc=tapas.kundu@broadcom.com \
    --cc=vamsi-krishna.brahmajosyula@broadcom.com \
    --cc=yin.ding@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome