From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15A6C38B7AA for ; Thu, 18 Jun 2026 10:25:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781778352; cv=none; b=lHT7e6hqstNQtleoycJmu+2NUsZOlquOR2l4LPIl0zJlL/kloQIU+2Tj/f9MFMrCLij1pDcCkC6bYSZAYPf6MnFTBJWegCoZNkxdzm4qpwJzjqmpzi9PQsRmDdtvhEC1cm3v4qN1OF7ggGoUbmsS5yldLdralX3b7RT9fj1YP3o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781778352; c=relaxed/simple; bh=r+dK8wIKgi7zlIxZFvBcFvSy8e4q259EUuGVcp5hH4M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kfTWIulXgl76jxNCkwt3fs021jbp6o/4bQ8ioprP1Bfs4RPjwqR+kdWStBYZxqnrCbehwQ0IeHgZjYCbxFjFJkfUclbggga+glPw3li39/jcnpIpjDBQPIF90/jC8y9pcd4TmXf1NSO7wn4oGYeMpdd2iG8/BcelcR9cgrLNkdI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=qmdwoqbF; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="qmdwoqbF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A4B71F000E9; Thu, 18 Jun 2026 10:25:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1781778350; bh=bejN+qL6pMKFG98+YE0anh/UR61NU8zL2PhbGWV+cDI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=qmdwoqbFLCW03ZyTqMvi5aj1Q6DQqAt2rqthTeNaQgBql/OuNGeCQ60IwLSyZVkAm U2eRm8Mw+eF3uSt7I9blXEKkqHCu9bISP+iztNgp1ucVW19HN55MMz58EuxF8aHDzp d1UaX/AFxMde76Y4+77AaRJoXSqApH4QyweqT2A4= Date: Thu, 18 Jun 2026 12:26:03 +0200 From: Greg KH To: Rishi Chhibber 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 Message-ID: <2026061818-slot-foster-bdf0@gregkh> References: <20260617203125.397427-1-rishi.chhibber@broadcom.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 > --- > 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 > +R: Broadcom internal kernel review list 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 > +#include > + > +#include > + > +#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