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.
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
