Message ID | 1708193020-14740-1-git-send-email-ssengar@linux.microsoft.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-69994-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp443871dyc; Sat, 17 Feb 2024 10:05:25 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVW/twrbtBHaqgziC7OewhbCg07t6FgCctiLDofVXzWOg7hUV2M4s/0+O2psB+2FEX7QupOjRCvybfGp8fBi61ZOgrCrA== X-Google-Smtp-Source: AGHT+IFN8vaRxzmFFFf9shqIAn3Mu8oG/kLdFQuZV3UFddMe/XUQb5ay62qlm+8jhehbo8P+agP9 X-Received: by 2002:a05:6402:528c:b0:55f:d6b9:245f with SMTP id en12-20020a056402528c00b0055fd6b9245fmr10790112edb.6.1708193125644; Sat, 17 Feb 2024 10:05:25 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708193125; cv=pass; d=google.com; s=arc-20160816; b=WDCofOKSk7A2kkwV2o3I4FF2hqIwfJJBfjJ9RnyLKzfQtFnE+P18dRDoV8VSy871b7 Ir7POOwpNfQvgz9DkhvJZZ7stijiO4d117Yeqn6VcnHE/nRsK9a5hGyABNmU5KKO7D50 8HoOL8S1voDc9xiJizCuD09ixIBF+APx+pCeUl92iidPZqKMo0Dtz68xSeqgNb4VGZNd 8nFEIFKyUt9SocORjG409BTuIgq37dgfK4hAhLjUI8HRPOiWF/649UYslYSivvlCTW6G haUEnGSu96eYf+o900l8YbDSY6+dRJyprLCXFOc/du2JQ4Fg6o78OiCqeRJDgdMHPQ3M txhQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-id:precedence:message-id:date :subject:cc:to:from:dkim-signature:dkim-filter; bh=/mwh7BUNN6hVP+Q7Cbl+W954u6dPawCLv2iDZVI1u+I=; fh=/g2YaKiPj+3FPE7qve5VOLtb1iRxoth7NZi+8r+O0Q0=; b=vXMwi7fWXGYJ4gS4BAsZqDbwbIApjNaPpGiMXL+KjVzNldFZmH3fXITFuMSO/arQ50 l85+kQaLopet3kWIn/xVYNQFFOuBvQ8eCZx2d4ho3bC5ScUk+YBwcM4Fdq+RkLjVaZOU bmMdwilOwAiidGzKfogF3wf9elY8cCPvL/vGBBGaO7fHTTi9J5Q1lVUYUfZX2+X33pvD E3aW8XiW2N0dYFAbou6dk4l0Xx74omTdwtZSIIjyLEUNLgYd8X7+/+61IKH+ai7fBStf uoMqnkjmfFOlCfMWM1Qssk18dFM+MavUOblBkuy5j8m9s+uw6yzN84VQ25uDsoK1sLgd ierw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=BQtdT+8h; arc=pass (i=1 spf=pass spfdomain=linux.microsoft.com dkim=pass dkdomain=linux.microsoft.com dmarc=pass fromdomain=linux.microsoft.com); spf=pass (google.com: domain of linux-kernel+bounces-69994-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69994-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id e21-20020a056402149500b00564266593b2si600704edv.629.2024.02.17.10.05.25 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Feb 2024 10:05:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-69994-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=BQtdT+8h; arc=pass (i=1 spf=pass spfdomain=linux.microsoft.com dkim=pass dkdomain=linux.microsoft.com dmarc=pass fromdomain=linux.microsoft.com); spf=pass (google.com: domain of linux-kernel+bounces-69994-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69994-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 472331F2158B for <ouuuleilei@gmail.com>; Sat, 17 Feb 2024 18:05:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D033A7E770; Sat, 17 Feb 2024 18:04:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="BQtdT+8h" Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AA8057D414; Sat, 17 Feb 2024 18:04:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708193075; cv=none; b=Mh9jnz/sVc532wUz2FNOsptzhb3XQSmA3pnfv17FfqKYL6ffv9CQmCKigqANyE36CjUqmNErRYG95Y0maZ4SO2NSWJXnbjBZea7zufieKJNuJ80aU0pHh1zQdRTHG/Xji9EskChar+kxh4m4QX6AKhbbyxphUUWdbh40PThkTjY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708193075; c=relaxed/simple; bh=fklp+eyYWX9Fo/GEKVCDaXngLiUmi5JBAtthR4Q1kP4=; h=From:To:Cc:Subject:Date:Message-Id; b=JhHoghN7uksaqB9/IsC+r2rQ0Kx9HqwnF0eSWXI0kKMB8bROpHJBbw3qjlCPr/LKr8tdRKjw/lJY5Y1INyoyWXtI/1HRGeXw5lYBXJvNwK1dCsqHmio+67P8oVH5z5lndN6avSRm8O+eYwGvMRCrvkWOe3lK6Od7arz9prl2xP0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=BQtdT+8h; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Received: from linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net (linux.microsoft.com [13.77.154.182]) by linux.microsoft.com (Postfix) with ESMTPSA id 536BC207FD29; Sat, 17 Feb 2024 10:04:27 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 536BC207FD29 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1708193067; bh=/mwh7BUNN6hVP+Q7Cbl+W954u6dPawCLv2iDZVI1u+I=; h=From:To:Cc:Subject:Date:From; b=BQtdT+8hwyc6VxrbOrCRcE/lUMlBDTjDF7Abn3UHikJxOmR1mmDmYnFs7stVAYvoV u0NTTGhsgSI/Ql7s2fB23QFTI8PoiKKW2wBm7OJ/67Yu4gE1c/iRMgqyCr2u5jcA9Z SzCn5hqzpVSgXiHMHYug+ACisQ+uV3dzfGJgx6Vc= From: Saurabh Sengar <ssengar@linux.microsoft.com> To: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, gregkh@linuxfoundation.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Cc: ssengar@microsoft.com Subject: [PATCH 0/6] Low speed Hyper-V devices support Date: Sat, 17 Feb 2024 10:03:34 -0800 Message-Id: <1708193020-14740-1-git-send-email-ssengar@linux.microsoft.com> X-Mailer: git-send-email 1.8.3.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791170315080540771 X-GMAIL-MSGID: 1791170315080540771 |
Series |
Low speed Hyper-V devices support
|
|
Message
Saurabh Singh Sengar
Feb. 17, 2024, 6:03 p.m. UTC
Hyper-V is adding multiple low speed "speciality" synthetic devices. Instead of writing a new kernel-level VMBus driver for each device, make the devices accessible to user space through UIO-based uio_hv_generic driver. Each device can then be supported by a user space driver. This approach optimizes the development process and provides flexibility to user space applications to control the key interactions with the VMBus ring buffer. The new synthetic devices are low speed devices that don't support VMBus monitor bits, and so they must use vmbus_setevent() to notify the host of ring buffer updates. These new devices also have smaller ring buffer sizes which requires to add support for variable ring buffer sizes. Moreover, this patch series adds a new implementation of the fcopy application that uses the new UIO driver. The older fcopy driver and application will be phased out gradually. Development of other similar userspace drivers is still underway. Efforts have been made previously to implement this solution earlier. Here are the discussions related to those attempts: https://lore.kernel.org/lkml/1691132996-11706-1-git-send-email-ssengar@linux.microsoft.com/ https://lore.kernel.org/lkml/1665575806-27990-1-git-send-email-ssengar@linux.microsoft.com/ https://lore.kernel.org/lkml/1665685754-13971-1-git-send-email-ssengar@linux.microsoft.com/ Saurabh Sengar (6): Drivers: hv: vmbus: Add utility function for querying ring size uio_hv_generic: Query the ringbuffer size for device uio_hv_generic: Enable interrupt for low speed VMBus devices tools: hv: Add vmbus_bufring tools: hv: Add new fcopy application based on uio driver Drivers: hv: Remove fcopy driver drivers/hv/Makefile | 2 +- drivers/hv/channel_mgmt.c | 7 +- drivers/hv/hv_fcopy.c | 427 ----------------------------- drivers/hv/hv_util.c | 12 - drivers/hv/hyperv_vmbus.h | 5 + drivers/uio/uio_hv_generic.c | 14 +- include/linux/hyperv.h | 1 + tools/hv/Build | 3 +- tools/hv/Makefile | 10 +- tools/hv/hv_fcopy_daemon.c | 266 ------------------ tools/hv/hv_fcopy_uio_daemon.c | 488 +++++++++++++++++++++++++++++++++ tools/hv/vmbus_bufring.c | 316 +++++++++++++++++++++ tools/hv/vmbus_bufring.h | 158 +++++++++++ 13 files changed, 988 insertions(+), 721 deletions(-) delete mode 100644 drivers/hv/hv_fcopy.c delete mode 100644 tools/hv/hv_fcopy_daemon.c create mode 100644 tools/hv/hv_fcopy_uio_daemon.c create mode 100644 tools/hv/vmbus_bufring.c create mode 100644 tools/hv/vmbus_bufring.h
Comments
On Sat, Feb 17, 2024 at 10:03:34AM -0800, Saurabh Sengar wrote: > Hyper-V is adding multiple low speed "speciality" synthetic devices. > Instead of writing a new kernel-level VMBus driver for each device, > make the devices accessible to user space through UIO-based > uio_hv_generic driver. Each device can then be supported by a user > space driver. This approach optimizes the development process and > provides flexibility to user space applications to control the key > interactions with the VMBus ring buffer. > > The new synthetic devices are low speed devices that don't support > VMBus monitor bits, and so they must use vmbus_setevent() to notify > the host of ring buffer updates. These new devices also have smaller > ring buffer sizes which requires to add support for variable ring buffer > sizes. > > Moreover, this patch series adds a new implementation of the fcopy > application that uses the new UIO driver. The older fcopy driver and > application will be phased out gradually. Development of other similar > userspace drivers is still underway. > > > Efforts have been made previously to implement this solution earlier. > Here are the discussions related to those attempts: > https://lore.kernel.org/lkml/1691132996-11706-1-git-send-email-ssengar@linux.microsoft.com/ > https://lore.kernel.org/lkml/1665575806-27990-1-git-send-email-ssengar@linux.microsoft.com/ > https://lore.kernel.org/lkml/1665685754-13971-1-git-send-email-ssengar@linux.microsoft.com/ So is this a v4 of the patch series? What has changed from those previous submissions? thanks, greg k-h
On Sun, Feb 18, 2024 at 08:10:36AM +0100, Greg KH wrote: > On Sat, Feb 17, 2024 at 10:03:34AM -0800, Saurabh Sengar wrote: > > Hyper-V is adding multiple low speed "speciality" synthetic devices. > > Instead of writing a new kernel-level VMBus driver for each device, > > make the devices accessible to user space through UIO-based > > uio_hv_generic driver. Each device can then be supported by a user > > space driver. This approach optimizes the development process and > > provides flexibility to user space applications to control the key > > interactions with the VMBus ring buffer. > > > > The new synthetic devices are low speed devices that don't support > > VMBus monitor bits, and so they must use vmbus_setevent() to notify > > the host of ring buffer updates. These new devices also have smaller > > ring buffer sizes which requires to add support for variable ring buffer > > sizes. > > > > Moreover, this patch series adds a new implementation of the fcopy > > application that uses the new UIO driver. The older fcopy driver and > > application will be phased out gradually. Development of other similar > > userspace drivers is still underway. > > > > > > Efforts have been made previously to implement this solution earlier. > > Here are the discussions related to those attempts: > > https://lore.kernel.org/lkml/1691132996-11706-1-git-send-email-ssengar@linux.microsoft.com/ > > https://lore.kernel.org/lkml/1665575806-27990-1-git-send-email-ssengar@linux.microsoft.com/ > > https://lore.kernel.org/lkml/1665685754-13971-1-git-send-email-ssengar@linux.microsoft.com/ > > So is this a v4 of the patch series? What has changed from those > previous submissions? In the most recent attempt we introduced a new driver uio_hv_vmbus_client for slow devices, where as in this new approach we are making use of existing uio_hv_generic driver. We also introduced the function to query ring buffer sizes, this is an attempt to address your comment on earlier series to avoid kernel params. Comment ref: https://lore.kernel.org/lkml/Y0bipdisMbTNMYOq@kroah.com/ We later tried to have ring buffer sizes via sysfs for which we wrote a new driver uio_hv_vmbus_client as explained above. This is the next approach in an attempt to address all of the concerns with all the previous series. - Saurabh > > thanks, > > greg k-h
On Sat, Feb 17, 2024 at 11:51:14PM -0800, Saurabh Singh Sengar wrote: > On Sun, Feb 18, 2024 at 08:10:36AM +0100, Greg KH wrote: > > On Sat, Feb 17, 2024 at 10:03:34AM -0800, Saurabh Sengar wrote: > > > Hyper-V is adding multiple low speed "speciality" synthetic devices. > > > Instead of writing a new kernel-level VMBus driver for each device, > > > make the devices accessible to user space through UIO-based > > > uio_hv_generic driver. Each device can then be supported by a user > > > space driver. This approach optimizes the development process and > > > provides flexibility to user space applications to control the key > > > interactions with the VMBus ring buffer. > > > > > > The new synthetic devices are low speed devices that don't support > > > VMBus monitor bits, and so they must use vmbus_setevent() to notify > > > the host of ring buffer updates. These new devices also have smaller > > > ring buffer sizes which requires to add support for variable ring buffer > > > sizes. > > > > > > Moreover, this patch series adds a new implementation of the fcopy > > > application that uses the new UIO driver. The older fcopy driver and > > > application will be phased out gradually. Development of other similar > > > userspace drivers is still underway. > > > > > > > > > Efforts have been made previously to implement this solution earlier. > > > Here are the discussions related to those attempts: > > > https://lore.kernel.org/lkml/1691132996-11706-1-git-send-email-ssengar@linux.microsoft.com/ > > > https://lore.kernel.org/lkml/1665575806-27990-1-git-send-email-ssengar@linux.microsoft.com/ > > > https://lore.kernel.org/lkml/1665685754-13971-1-git-send-email-ssengar@linux.microsoft.com/ > > > > So is this a v4 of the patch series? What has changed from those > > previous submissions? > > In the most recent attempt we introduced a new driver uio_hv_vmbus_client > for slow devices, where as in this new approach we are making use of > existing uio_hv_generic driver. > > We also introduced the function to query ring buffer sizes, this is an > attempt to address your comment on earlier series to avoid kernel params. > Comment ref: https://lore.kernel.org/lkml/Y0bipdisMbTNMYOq@kroah.com/ > > We later tried to have ring buffer sizes via sysfs for which we wrote a > new driver uio_hv_vmbus_client as explained above. > > This is the next approach in an attempt to address all of the concerns > with all the previous series. Then you need to say that somewhere, what differs from the previous submissions and why this is better. Remember, some of us get 1000+ emails a day to do something with, and trying to remember a review comment from last week, let alone months ago, is impossible. Make this easy for us please... And as this is a "next approach", it should be versioned properly. What would you want to see if you had to review this? thanks, greg k-h