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,
};
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. 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. 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.
Regards,
Naman
