[PATCH 0/6] Low speed Hyper-V devices support

Saurabh Sengar posted 6 patches 1 year, 11 months ago
There is a newer version of this series
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
[PATCH 0/6] Low speed Hyper-V devices support
Posted by Saurabh Sengar 1 year, 11 months ago
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

-- 
2.34.1
Re: [PATCH 0/6] Low speed Hyper-V devices support
Posted by Greg KH 1 year, 11 months ago
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
Re: [PATCH 0/6] Low speed Hyper-V devices support
Posted by Saurabh Singh Sengar 1 year, 11 months ago
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
Re: [PATCH 0/6] Low speed Hyper-V devices support
Posted by Greg KH 1 year, 11 months ago
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