[PATCH] uio_hv_generic: Bind to FCopy device by default

[PATCH] uio_hv_generic: Bind to FCopy device by default

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

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 <benh@debian.org>
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,
 };

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] uio_hv_generic: Bind to FCopy device by default

[Naman Jain]

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 <benh@debian.org>
> 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: stable@vger.kernel.org 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

Re: [PATCH] uio_hv_generic: Bind to FCopy device by default

[Naman Jain]

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 <benh@debian.org>
>>> 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: stable@vger.kernel.org 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

RE: [PATCH] uio_hv_generic: Bind to FCopy device by default

[Michael Kelley]

From: Naman Jain <namjain@linux.microsoft.com> 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 <benh@debian.org>
> >>> 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
(linux-kernel@vger.kernel.org) 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: stable@vger.kernel.org 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

Re: [PATCH] uio_hv_generic: Bind to FCopy device by default

[Naman Jain]

On 5/26/2026 8:45 PM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> 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 <benh@debian.org>
>>>>> 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
> (linux-kernel@vger.kernel.org) 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
> 
Sashiko also misses out on such patches if linux-kernel@vger.kernel.org 
is not included. I could not find this in https://sashiko.dev/#/.

Regards,
Naman