From: Naman Jain <[email protected]> Sent: Tuesday, May 26, 2026 3:10 AM > > On 5/26/2026 1:59 PM, Ben Hutchings wrote: > > On Tue, 2026-05-26 at 12:15 +0530, Naman Jain wrote: > >> > >> On 5/25/2026 5:34 PM, Ben Hutchings wrote: > >>> The Hyper-V kernel-mode fcopy driver was removed in 6.10 and the new > >>> fcopy daemon requires this uio driver to function. However, by > >>> default the driver does not bind to any devices, and must be > >>> configured through the sysfs "new_id" file. > >>> > >>> Since the FCopy device is now only usable through this driver, add its > >>> ID to the driver's ID table so that the daemon will work "out of the > >>> box". > >>> > >>> Signed-off-by: Ben Hutchings <[email protected]> > >>> Fixes: ec314f61e4fc ("Drivers: hv: Remove fcopy driver") > >>> --- > >>> --- a/drivers/uio/uio_hv_generic.c > >>> +++ b/drivers/uio/uio_hv_generic.c > >>> @@ -395,9 +395,15 @@ hv_uio_remove(struct hv_device *dev) > >>> vmbus_free_ring(dev->channel); > >>> } > >>> > >>> +static const struct hv_vmbus_device_id hv_uio_id_table[] = { > >>> + { HV_FCOPY_GUID }, > >>> + {} > >>> +}; > >>> +MODULE_DEVICE_TABLE(vmbus, hv_uio_id_table); > >>> + > >>> static struct hv_driver hv_uio_drv = { > >>> .name = "uio_hv_generic", > >>> - .id_table = NULL, /* only dynamic id's */ > >>> + .id_table = hv_uio_id_table, > >>> .probe = hv_uio_probe, > >>> .remove = hv_uio_remove, > >>> }; > >> > > ++ recipients, assuming you mistakenly clicked reply instead of reply all.
Ben -- Regarding recipients, please include the full LKML ([email protected]) on the original patch posting, even though it is about a narrow Hyper-V issue. I dabble in areas beyond just Hyper-V so subscribe to the full LKML instead of the linux-hyperv mailing list. I miss patches like this one unless I happen to be looking through the lore.kernel.org archives for linux-hyperv. Thx, Michael > > > >> Two things worth considering before applying: > >> > >> 1. Please add Cc: [email protected] or is it that we do not want > >> this to be ported to older kernels? > >> > >> 2. Every Hyper-V guest (with UIO_HV_GENERIC enabled) will now have an > >> additional auto-bound /dev/uio0 node for FCopy. > > > > I don't think that's quite true. I tested with a Windows 11 host and > > needed to enable "Guest services" for the VM, which was disabled by > > default. But if that includes other features besides FCopy it might be > > enabled for other reasons. > > > > Yes, meaning if these two conditions are satisfied (enabling guest > services is also one time step for a Hyper-V VM), we would see uio0 by > default for fcopy. > > >> Anything that hardcodes > >> /dev/uio0 (e.g. ad-hoc DPDK scripts that bind a NetVSC NIC via > >> uio_hv_generic + new_id) may see its index shift, since FCopy now wins > >> uio0 at boot. > > > > OK, so maybe I should implement the new_id dance in the fcopy service > > startup, to avoid that? I did already looked at doing it in a systemd > > unit, but it's hard to do right because adding the same ID twice is an > > error. Maybe the daemon itself ould do it? > > Implementing it in uio daemon can introduce race conditions with sysfs > creation. I guess it's OK then to implement it here, in kernel. > > > > >> The fix for such consumers is the same thing DPDK and the > >> in-tree daemon already do: resolve uio via > >> /sys/bus/vmbus/devices/<guid>/uio/ rather than by number. This is not a > >> regression in the patch, but it's a behavior change worth calling out. > > > > It would be a good reason *not* to make this change in stable. > > > > Ben. > > > > What issues are you fixing with this patch exactly? Is there any > particular sequence of events you are targeting where traditional > approach does not work? > > Regards, > Naman
