From: Lorenzo Stoakes (Oracle) <[email protected]> Sent: Friday, March 20, 2026 3:40 PM > > The f_op->mmap interface is deprecated, so update the vmbus driver to use > its successor, mmap_prepare. > > This updates all callbacks which referenced the function pointer > hv_mmap_ring_buffer to instead reference hv_mmap_prepare_ring_buffer, > utilising the newly introduced compat_set_desc_from_vma() and > __compat_vma_mmap() to be able to implement this change. > > The UIO HV generic driver is the only user of hv_create_ring_sysfs(), > which is the only function which references > vmbus_channel->mmap_prepare_ring_buffer which, in turn, is the only > external interface to hv_mmap_prepare_ring_buffer. > > This patch therefore updates this caller to use mmap_prepare instead, > which also previously used vm_iomap_memory(), so this change replaces it > with its mmap_prepare equivalent, mmap_action_simple_ioremap(). > > Signed-off-by: Lorenzo Stoakes (Oracle) <[email protected]> > --- > drivers/hv/hyperv_vmbus.h | 4 ++-- > drivers/hv/vmbus_drv.c | 31 +++++++++++++++++++------------ > drivers/uio/uio_hv_generic.c | 11 ++++++----- > include/linux/hyperv.h | 4 ++-- > 4 files changed, 29 insertions(+), 21 deletions(-) >
There are two mmap() code paths in the Hyper-V UIO code. One path is to mmap() the file descriptor for /dev/uio<n>, and the other is to mmap() the "ring" entry under /sys/devices/vmbus/devices/<uuid>. The former is done by uio_mmap(), and the latter by hv_uio_ring_mmap_prepare(). I tested both these paths using a combination of two methods in a x86/x64 VM on Hyper-V: 1) Using the fcopy daemon, which maps the ring buffer for the primary channel and sends/receives messages with the Hyper-V host. This method tests only the 1st path because the fcopy daemon doesn't create any subchannels that would use the "ring" entry. 2) Using a custom-built test program. This program doesn't communicate with the Hyper-V host, but allows mostly verifying both code paths for the primary channel. As a sanity check, it verifies that the two mmaps are mapping the same memory, as expected. As such, Reviewed-by: Michael Kelley <[email protected]> Tested-by: Michael Kelley <[email protected]> The most robust test would be to run DPDK networking against UIO, as it would communicate with the Hyper-V host and use multiple subchannels that resulting in mmap'ing the "ring" entry under /sys. @Long Li -- I'll leave it to your discretion as to whether you want to test DPDK against these mmap() changes. I've noted one minor issue below. [snip] --- a/include/linux/hyperv.h +++ b/include/linux/hyperv.h @@ -1015,8 +1015,8 @@ struct vmbus_channel { /* The max size of a packet on this channel */ u32 max_pkt_size; - /* function to mmap ring buffer memory to the channel's sysfs ring attribute */ - int (*mmap_ring_buffer)(struct vmbus_channel *channel, struct vm_area_struct *vma); + /* function to mmap_prepare ring buffer memory to the channel's sysfs ring attribute */ Changing the comment from "mmap ring buffer" to "mmap_prepare ring buffer" produces awkward wording since "mmap" is used here as a verb. It might be better to just leave the comment unchanged. Michael + int (*mmap_prepare_ring_buffer)(struct vmbus_channel *channel, struct vm_area_desc *desc); /* boolean to control visibility of sysfs for ring buffer */ bool ring_sysfs_visible;
