[PATCH] virtio: vhost-user-device: Make user creatable again

[PATCH] virtio: vhost-user-device: Make user creatable again

[Christian Speich]

This removes the change introduced in [1] that prevents the use of
vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.

[1]: 6275989647efb708f126eb4f880e593792301ed4

Signed-off-by: Christian Speich <c.speich@avm.de>
---
vhost-user-device and vhost-user-device-pci started out as user
creatable devices. This was changed in [1] when the vhost-user-base was
introduced.

The reason given is to prevent user confusion. Searching qemu-discuss or
google for "vhost-user-device" I've seen no confused users.

Our use case is to provide wifi emulation using "vhost-user-device-pci",
which currently is working fine with the QEMU 9.0.2 present in Ubuntu
24.04. With newer QEMU versions we now need to patch, distribute and
maintain our own QEMU packages, which is non-trivial.

So I want to propose lifting this restriction to make this feature
usable without a custom QEMU.

[1]: 6275989647efb708f126eb4f880e593792301ed4
---
 docs/system/devices/vhost-user.rst | 10 ----------
 hw/virtio/vhost-user-device-pci.c  |  3 ---
 hw/virtio/vhost-user-device.c      |  3 ---
 3 files changed, 16 deletions(-)

diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
index 35259d8ec7c666aa0c56497b8261f48d77216ad5..2d130f9767dbb1cbb85cef43c63dc9a8d7b30d4a 100644
--- a/docs/system/devices/vhost-user.rst
+++ b/docs/system/devices/vhost-user.rst
@@ -73,16 +73,6 @@ all the required parameters including:
   - The ``num_vqs`` it needs and their ``vq_size``
   - The ``config_size`` if needed
 
-.. note::
-  To prevent user confusion you cannot currently instantiate
-  vhost-user-device without first patching out::
-
-    /* Reason: stop inexperienced users confusing themselves */
-    dc->user_creatable = false;
-
-  in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
-  rebuilding.
-
 vhost-user daemon
 =================
 
diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
index f10bac874e78429c633752a4ce9db28385b3bb07..c76a856c9b9a67d941a93929244216658ff2a156 100644
--- a/hw/virtio/vhost-user-device-pci.c
+++ b/hw/virtio/vhost-user-device-pci.c
@@ -38,9 +38,6 @@ static void vhost_user_device_pci_class_init(ObjectClass *klass,
     VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
     PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
 
-    /* Reason: stop users confusing themselves */
-    dc->user_creatable = false;
-
     k->realize = vhost_user_device_pci_realize;
     set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
     pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
diff --git a/hw/virtio/vhost-user-device.c b/hw/virtio/vhost-user-device.c
index 3939bdf755222a281da8ca22243d7d4f16990a66..1bea496afd0137ba9b42009f6252acf6800528d1 100644
--- a/hw/virtio/vhost-user-device.c
+++ b/hw/virtio/vhost-user-device.c
@@ -41,9 +41,6 @@ static void vud_class_init(ObjectClass *klass, const void *data)
 {
     DeviceClass *dc = DEVICE_CLASS(klass);
 
-    /* Reason: stop inexperienced users confusing themselves */
-    dc->user_creatable = false;
-
     device_class_set_props(dc, vud_properties);
     dc->vmsd = &vud_vmstate;
     set_bit(DEVICE_CATEGORY_INPUT, dc->categories);

---
base-commit: e7c1e8043a69c5a8efa39d4f9d111f7c72c076e6
change-id: 20250919-vhost-user-device-creatable-b7f9b7b5bfb2

Best regards,
-- 
Christian Speich <c.speich@avm.de>

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Stefano Garzarella]

On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
>This removes the change introduced in [1] that prevents the use of
>vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
>
>[1]: 6275989647efb708f126eb4f880e593792301ed4
>
>Signed-off-by: Christian Speich <c.speich@avm.de>
>---
>vhost-user-device and vhost-user-device-pci started out as user
>creatable devices. This was changed in [1] when the vhost-user-base was
>introduced.
>
>The reason given is to prevent user confusion. Searching qemu-discuss or
>google for "vhost-user-device" I've seen no confused users.
>
>Our use case is to provide wifi emulation using "vhost-user-device-pci",
>which currently is working fine with the QEMU 9.0.2 present in Ubuntu
>24.04. With newer QEMU versions we now need to patch, distribute and
>maintain our own QEMU packages, which is non-trivial.
>
>So I want to propose lifting this restriction to make this feature
>usable without a custom QEMU.

Alex already proposed something similar:

https://lore.kernel.org/qemu-devel/20250901105948.982583-1-alex.bennee@linaro.org/

Thanks,
Stefano

>
>[1]: 6275989647efb708f126eb4f880e593792301ed4
>---
> docs/system/devices/vhost-user.rst | 10 ----------
> hw/virtio/vhost-user-device-pci.c  |  3 ---
> hw/virtio/vhost-user-device.c      |  3 ---
> 3 files changed, 16 deletions(-)
>
>diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
>index 35259d8ec7c666aa0c56497b8261f48d77216ad5..2d130f9767dbb1cbb85cef43c63dc9a8d7b30d4a 100644
>--- a/docs/system/devices/vhost-user.rst
>+++ b/docs/system/devices/vhost-user.rst
>@@ -73,16 +73,6 @@ all the required parameters including:
>   - The ``num_vqs`` it needs and their ``vq_size``
>   - The ``config_size`` if needed
>
>-.. note::
>-  To prevent user confusion you cannot currently instantiate
>-  vhost-user-device without first patching out::
>-
>-    /* Reason: stop inexperienced users confusing themselves */
>-    dc->user_creatable = false;
>-
>-  in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
>-  rebuilding.
>-
> vhost-user daemon
> =================
>
>diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
>index f10bac874e78429c633752a4ce9db28385b3bb07..c76a856c9b9a67d941a93929244216658ff2a156 100644
>--- a/hw/virtio/vhost-user-device-pci.c
>+++ b/hw/virtio/vhost-user-device-pci.c
>@@ -38,9 +38,6 @@ static void vhost_user_device_pci_class_init(ObjectClass *klass,
>     VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
>     PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
>
>-    /* Reason: stop users confusing themselves */
>-    dc->user_creatable = false;
>-
>     k->realize = vhost_user_device_pci_realize;
>     set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
>     pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
>diff --git a/hw/virtio/vhost-user-device.c b/hw/virtio/vhost-user-device.c
>index 3939bdf755222a281da8ca22243d7d4f16990a66..1bea496afd0137ba9b42009f6252acf6800528d1 100644
>--- a/hw/virtio/vhost-user-device.c
>+++ b/hw/virtio/vhost-user-device.c
>@@ -41,9 +41,6 @@ static void vud_class_init(ObjectClass *klass, const void *data)
> {
>     DeviceClass *dc = DEVICE_CLASS(klass);
>
>-    /* Reason: stop inexperienced users confusing themselves */
>-    dc->user_creatable = false;
>-
>     device_class_set_props(dc, vud_properties);
>     dc->vmsd = &vud_vmstate;
>     set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
>
>---
>base-commit: e7c1e8043a69c5a8efa39d4f9d111f7c72c076e6
>change-id: 20250919-vhost-user-device-creatable-b7f9b7b5bfb2
>
>Best regards,
>-- 
>Christian Speich <c.speich@avm.de>
>
>

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Michael S. Tsirkin]

On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> This removes the change introduced in [1] that prevents the use of
> vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> 
> [1]: 6275989647efb708f126eb4f880e593792301ed4
> 
> Signed-off-by: Christian Speich <c.speich@avm.de>
> ---
> vhost-user-device and vhost-user-device-pci started out as user
> creatable devices. This was changed in [1] when the vhost-user-base was
> introduced.
> 
> The reason given is to prevent user confusion. Searching qemu-discuss or
> google for "vhost-user-device" I've seen no confused users.
> 
> Our use case is to provide wifi emulation using "vhost-user-device-pci",
> which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> 24.04. With newer QEMU versions we now need to patch, distribute and
> maintain our own QEMU packages, which is non-trivial.
> 
> So I want to propose lifting this restriction to make this feature
> usable without a custom QEMU.
> 
> [1]: 6275989647efb708f126eb4f880e593792301ed4

The confusion is after someone reuses the ID you are claiming without
telling anyone and then linux guests will start binding that driver to
your device.


We want people doing this kind of thing to *at a minimum*
go ahead and register a device id with the virtio TC,
but really to write and publish a spec.


> ---
>  docs/system/devices/vhost-user.rst | 10 ----------
>  hw/virtio/vhost-user-device-pci.c  |  3 ---
>  hw/virtio/vhost-user-device.c      |  3 ---
>  3 files changed, 16 deletions(-)
> 
> diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
> index 35259d8ec7c666aa0c56497b8261f48d77216ad5..2d130f9767dbb1cbb85cef43c63dc9a8d7b30d4a 100644
> --- a/docs/system/devices/vhost-user.rst
> +++ b/docs/system/devices/vhost-user.rst
> @@ -73,16 +73,6 @@ all the required parameters including:
>    - The ``num_vqs`` it needs and their ``vq_size``
>    - The ``config_size`` if needed
>  
> -.. note::
> -  To prevent user confusion you cannot currently instantiate
> -  vhost-user-device without first patching out::
> -
> -    /* Reason: stop inexperienced users confusing themselves */
> -    dc->user_creatable = false;
> -
> -  in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
> -  rebuilding.
> -
>  vhost-user daemon
>  =================
>  
> diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
> index f10bac874e78429c633752a4ce9db28385b3bb07..c76a856c9b9a67d941a93929244216658ff2a156 100644
> --- a/hw/virtio/vhost-user-device-pci.c
> +++ b/hw/virtio/vhost-user-device-pci.c
> @@ -38,9 +38,6 @@ static void vhost_user_device_pci_class_init(ObjectClass *klass,
>      VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
>      PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
>  
> -    /* Reason: stop users confusing themselves */
> -    dc->user_creatable = false;
> -
>      k->realize = vhost_user_device_pci_realize;
>      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
>      pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> diff --git a/hw/virtio/vhost-user-device.c b/hw/virtio/vhost-user-device.c
> index 3939bdf755222a281da8ca22243d7d4f16990a66..1bea496afd0137ba9b42009f6252acf6800528d1 100644
> --- a/hw/virtio/vhost-user-device.c
> +++ b/hw/virtio/vhost-user-device.c
> @@ -41,9 +41,6 @@ static void vud_class_init(ObjectClass *klass, const void *data)
>  {
>      DeviceClass *dc = DEVICE_CLASS(klass);
>  
> -    /* Reason: stop inexperienced users confusing themselves */
> -    dc->user_creatable = false;
> -
>      device_class_set_props(dc, vud_properties);
>      dc->vmsd = &vud_vmstate;
>      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> 
> ---
> base-commit: e7c1e8043a69c5a8efa39d4f9d111f7c72c076e6
> change-id: 20250919-vhost-user-device-creatable-b7f9b7b5bfb2
> 
> Best regards,
> -- 
> Christian Speich <c.speich@avm.de>

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Christian Speich via]

On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > This removes the change introduced in [1] that prevents the use of
> > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > 
> > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > 
> > Signed-off-by: Christian Speich <c.speich@avm.de>
> > ---
> > vhost-user-device and vhost-user-device-pci started out as user
> > creatable devices. This was changed in [1] when the vhost-user-base was
> > introduced.
> > 
> > The reason given is to prevent user confusion. Searching qemu-discuss or
> > google for "vhost-user-device" I've seen no confused users.
> > 
> > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > 24.04. With newer QEMU versions we now need to patch, distribute and
> > maintain our own QEMU packages, which is non-trivial.
> > 
> > So I want to propose lifting this restriction to make this feature
> > usable without a custom QEMU.
> > 
> > [1]: 6275989647efb708f126eb4f880e593792301ed4
> 
> The confusion is after someone reuses the ID you are claiming without
> telling anyone and then linux guests will start binding that driver to
> your device.

Thanks for clarifciation, In our use-case we use mac80211_hwsim which is
in linux upstream (with the ID 29). So I think a potential reuse here
is something that linux upstream already deals with.

> 
> 
> We want people doing this kind of thing to *at a minimum*
> go ahead and register a device id with the virtio TC,
> but really to write and publish a spec.

I understand this desire, I'm not sure how this relates with the ability
to let a user create a vhost-user-device or not.

Kind Regards,
Christian

> 
> 
> > ---
> >  docs/system/devices/vhost-user.rst | 10 ----------
> >  hw/virtio/vhost-user-device-pci.c  |  3 ---
> >  hw/virtio/vhost-user-device.c      |  3 ---
> >  3 files changed, 16 deletions(-)
> > 
> > diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
> > index 35259d8ec7c666aa0c56497b8261f48d77216ad5..2d130f9767dbb1cbb85cef43c63dc9a8d7b30d4a 100644
> > --- a/docs/system/devices/vhost-user.rst
> > +++ b/docs/system/devices/vhost-user.rst
> > @@ -73,16 +73,6 @@ all the required parameters including:
> >    - The ``num_vqs`` it needs and their ``vq_size``
> >    - The ``config_size`` if needed
> >  
> > -.. note::
> > -  To prevent user confusion you cannot currently instantiate
> > -  vhost-user-device without first patching out::
> > -
> > -    /* Reason: stop inexperienced users confusing themselves */
> > -    dc->user_creatable = false;
> > -
> > -  in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
> > -  rebuilding.
> > -
> >  vhost-user daemon
> >  =================
> >  
> > diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
> > index f10bac874e78429c633752a4ce9db28385b3bb07..c76a856c9b9a67d941a93929244216658ff2a156 100644
> > --- a/hw/virtio/vhost-user-device-pci.c
> > +++ b/hw/virtio/vhost-user-device-pci.c
> > @@ -38,9 +38,6 @@ static void vhost_user_device_pci_class_init(ObjectClass *klass,
> >      VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> >      PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> >  
> > -    /* Reason: stop users confusing themselves */
> > -    dc->user_creatable = false;
> > -
> >      k->realize = vhost_user_device_pci_realize;
> >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> >      pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > diff --git a/hw/virtio/vhost-user-device.c b/hw/virtio/vhost-user-device.c
> > index 3939bdf755222a281da8ca22243d7d4f16990a66..1bea496afd0137ba9b42009f6252acf6800528d1 100644
> > --- a/hw/virtio/vhost-user-device.c
> > +++ b/hw/virtio/vhost-user-device.c
> > @@ -41,9 +41,6 @@ static void vud_class_init(ObjectClass *klass, const void *data)
> >  {
> >      DeviceClass *dc = DEVICE_CLASS(klass);
> >  
> > -    /* Reason: stop inexperienced users confusing themselves */
> > -    dc->user_creatable = false;
> > -
> >      device_class_set_props(dc, vud_properties);
> >      dc->vmsd = &vud_vmstate;
> >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > 
> > ---
> > base-commit: e7c1e8043a69c5a8efa39d4f9d111f7c72c076e6
> > change-id: 20250919-vhost-user-device-creatable-b7f9b7b5bfb2
> > 
> > Best regards,
> > -- 
> > Christian Speich <c.speich@avm.de>
> 
> 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Michael S. Tsirkin]

On Mon, Sep 22, 2025 at 12:40:33PM +0200, Christian Speich wrote:
> On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > This removes the change introduced in [1] that prevents the use of
> > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > 
> > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > 
> > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > ---
> > > vhost-user-device and vhost-user-device-pci started out as user
> > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > introduced.
> > > 
> > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > google for "vhost-user-device" I've seen no confused users.
> > > 
> > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > maintain our own QEMU packages, which is non-trivial.
> > > 
> > > So I want to propose lifting this restriction to make this feature
> > > usable without a custom QEMU.
> > > 
> > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > 
> > The confusion is after someone reuses the ID you are claiming without
> > telling anyone and then linux guests will start binding that driver to
> > your device.
> 
> Thanks for clarifciation, In our use-case we use mac80211_hwsim which is
> in linux upstream (with the ID 29). So I think a potential reuse here
> is something that linux upstream already deals with.

So just allow that one?

> > 
> > 
> > We want people doing this kind of thing to *at a minimum*
> > go ahead and register a device id with the virtio TC,
> > but really to write and publish a spec.
> 
> I understand this desire, I'm not sure how this relates with the ability
> to let a user create a vhost-user-device or not.
> 
> Kind Regards,
> Christian
> 
> > 
> > 
> > > ---
> > >  docs/system/devices/vhost-user.rst | 10 ----------
> > >  hw/virtio/vhost-user-device-pci.c  |  3 ---
> > >  hw/virtio/vhost-user-device.c      |  3 ---
> > >  3 files changed, 16 deletions(-)
> > > 
> > > diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
> > > index 35259d8ec7c666aa0c56497b8261f48d77216ad5..2d130f9767dbb1cbb85cef43c63dc9a8d7b30d4a 100644
> > > --- a/docs/system/devices/vhost-user.rst
> > > +++ b/docs/system/devices/vhost-user.rst
> > > @@ -73,16 +73,6 @@ all the required parameters including:
> > >    - The ``num_vqs`` it needs and their ``vq_size``
> > >    - The ``config_size`` if needed
> > >  
> > > -.. note::
> > > -  To prevent user confusion you cannot currently instantiate
> > > -  vhost-user-device without first patching out::
> > > -
> > > -    /* Reason: stop inexperienced users confusing themselves */
> > > -    dc->user_creatable = false;
> > > -
> > > -  in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
> > > -  rebuilding.
> > > -
> > >  vhost-user daemon
> > >  =================
> > >  
> > > diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
> > > index f10bac874e78429c633752a4ce9db28385b3bb07..c76a856c9b9a67d941a93929244216658ff2a156 100644
> > > --- a/hw/virtio/vhost-user-device-pci.c
> > > +++ b/hw/virtio/vhost-user-device-pci.c
> > > @@ -38,9 +38,6 @@ static void vhost_user_device_pci_class_init(ObjectClass *klass,
> > >      VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> > >      PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> > >  
> > > -    /* Reason: stop users confusing themselves */
> > > -    dc->user_creatable = false;
> > > -
> > >      k->realize = vhost_user_device_pci_realize;
> > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > >      pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > > diff --git a/hw/virtio/vhost-user-device.c b/hw/virtio/vhost-user-device.c
> > > index 3939bdf755222a281da8ca22243d7d4f16990a66..1bea496afd0137ba9b42009f6252acf6800528d1 100644
> > > --- a/hw/virtio/vhost-user-device.c
> > > +++ b/hw/virtio/vhost-user-device.c
> > > @@ -41,9 +41,6 @@ static void vud_class_init(ObjectClass *klass, const void *data)
> > >  {
> > >      DeviceClass *dc = DEVICE_CLASS(klass);
> > >  
> > > -    /* Reason: stop inexperienced users confusing themselves */
> > > -    dc->user_creatable = false;
> > > -
> > >      device_class_set_props(dc, vud_properties);
> > >      dc->vmsd = &vud_vmstate;
> > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > 
> > > ---
> > > base-commit: e7c1e8043a69c5a8efa39d4f9d111f7c72c076e6
> > > change-id: 20250919-vhost-user-device-creatable-b7f9b7b5bfb2
> > > 
> > > Best regards,
> > > -- 
> > > Christian Speich <c.speich@avm.de>
> > 
> > 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Christian Speich via]

On Mon, Sep 22, 2025 at 06:56:31AM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 22, 2025 at 12:40:33PM +0200, Christian Speich wrote:
> > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > This removes the change introduced in [1] that prevents the use of
> > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > 
> > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > 
> > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > ---
> > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > introduced.
> > > > 
> > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > google for "vhost-user-device" I've seen no confused users.
> > > > 
> > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > maintain our own QEMU packages, which is non-trivial.
> > > > 
> > > > So I want to propose lifting this restriction to make this feature
> > > > usable without a custom QEMU.
> > > > 
> > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > 
> > > The confusion is after someone reuses the ID you are claiming without
> > > telling anyone and then linux guests will start binding that driver to
> > > your device.
> > 
> > Thanks for clarifciation, In our use-case we use mac80211_hwsim which is
> > in linux upstream (with the ID 29). So I think a potential reuse here
> > is something that linux upstream already deals with.
> 
> So just allow that one?

That would solve our problem.

However, I'm finding it somwhat odd to artifically force the user only use
QEMU it the "allowed way". I'd much rather see that virtio-user-device is
usuable as is (and mac80211_hwsim is not a special case and just works).

Regards,
Christian

> 
> > > 
> > > 
> > > We want people doing this kind of thing to *at a minimum*
> > > go ahead and register a device id with the virtio TC,
> > > but really to write and publish a spec.
> > 
> > I understand this desire, I'm not sure how this relates with the ability
> > to let a user create a vhost-user-device or not.
> > 
> > Kind Regards,
> > Christian
> > 
> > > 
> > > 
> > > > ---
> > > >  docs/system/devices/vhost-user.rst | 10 ----------
> > > >  hw/virtio/vhost-user-device-pci.c  |  3 ---
> > > >  hw/virtio/vhost-user-device.c      |  3 ---
> > > >  3 files changed, 16 deletions(-)
> > > > 
> > > > diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
> > > > index 35259d8ec7c666aa0c56497b8261f48d77216ad5..2d130f9767dbb1cbb85cef43c63dc9a8d7b30d4a 100644
> > > > --- a/docs/system/devices/vhost-user.rst
> > > > +++ b/docs/system/devices/vhost-user.rst
> > > > @@ -73,16 +73,6 @@ all the required parameters including:
> > > >    - The ``num_vqs`` it needs and their ``vq_size``
> > > >    - The ``config_size`` if needed
> > > >  
> > > > -.. note::
> > > > -  To prevent user confusion you cannot currently instantiate
> > > > -  vhost-user-device without first patching out::
> > > > -
> > > > -    /* Reason: stop inexperienced users confusing themselves */
> > > > -    dc->user_creatable = false;
> > > > -
> > > > -  in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
> > > > -  rebuilding.
> > > > -
> > > >  vhost-user daemon
> > > >  =================
> > > >  
> > > > diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
> > > > index f10bac874e78429c633752a4ce9db28385b3bb07..c76a856c9b9a67d941a93929244216658ff2a156 100644
> > > > --- a/hw/virtio/vhost-user-device-pci.c
> > > > +++ b/hw/virtio/vhost-user-device-pci.c
> > > > @@ -38,9 +38,6 @@ static void vhost_user_device_pci_class_init(ObjectClass *klass,
> > > >      VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> > > >      PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> > > >  
> > > > -    /* Reason: stop users confusing themselves */
> > > > -    dc->user_creatable = false;
> > > > -
> > > >      k->realize = vhost_user_device_pci_realize;
> > > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > >      pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > > > diff --git a/hw/virtio/vhost-user-device.c b/hw/virtio/vhost-user-device.c
> > > > index 3939bdf755222a281da8ca22243d7d4f16990a66..1bea496afd0137ba9b42009f6252acf6800528d1 100644
> > > > --- a/hw/virtio/vhost-user-device.c
> > > > +++ b/hw/virtio/vhost-user-device.c
> > > > @@ -41,9 +41,6 @@ static void vud_class_init(ObjectClass *klass, const void *data)
> > > >  {
> > > >      DeviceClass *dc = DEVICE_CLASS(klass);
> > > >  
> > > > -    /* Reason: stop inexperienced users confusing themselves */
> > > > -    dc->user_creatable = false;
> > > > -
> > > >      device_class_set_props(dc, vud_properties);
> > > >      dc->vmsd = &vud_vmstate;
> > > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > > 
> > > > ---
> > > > base-commit: e7c1e8043a69c5a8efa39d4f9d111f7c72c076e6
> > > > change-id: 20250919-vhost-user-device-creatable-b7f9b7b5bfb2
> > > > 
> > > > Best regards,
> > > > -- 
> > > > Christian Speich <c.speich@avm.de>
> > > 
> > > 
> 
> 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Daniel P. Berrangé]

On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > This removes the change introduced in [1] that prevents the use of
> > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > 
> > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > 
> > Signed-off-by: Christian Speich <c.speich@avm.de>
> > ---
> > vhost-user-device and vhost-user-device-pci started out as user
> > creatable devices. This was changed in [1] when the vhost-user-base was
> > introduced.
> > 
> > The reason given is to prevent user confusion. Searching qemu-discuss or
> > google for "vhost-user-device" I've seen no confused users.
> > 
> > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > 24.04. With newer QEMU versions we now need to patch, distribute and
> > maintain our own QEMU packages, which is non-trivial.
> > 
> > So I want to propose lifting this restriction to make this feature
> > usable without a custom QEMU.
> > 
> > [1]: 6275989647efb708f126eb4f880e593792301ed4
> 
> The confusion is after someone reuses the ID you are claiming without
> telling anyone and then linux guests will start binding that driver to
> your device.
> 
> 
> We want people doing this kind of thing to *at a minimum*
> go ahead and register a device id with the virtio TC,
> but really to write and publish a spec.

Wanting people to register a device ID is a social problem and
we're trying to apply a technical hammer to it, which is rarely
an productive approach.

If we want to demonstrate that vhost-user-device is "risky", then
how about we rename it to have an 'x-' prefix and thus disclaim
any support for it, but none the less allow its use. Document it
as an experimental device, and if it breaks, users get to keep
both pieces.

It seems like it would be useful before any virtio spec submission
as a mechanism by which users can experiment to finese their ideas
prior to getting to the point of needing to make a spec proposal.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Michael S. Tsirkin]

On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > This removes the change introduced in [1] that prevents the use of
> > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > 
> > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > 
> > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > ---
> > > vhost-user-device and vhost-user-device-pci started out as user
> > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > introduced.
> > > 
> > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > google for "vhost-user-device" I've seen no confused users.
> > > 
> > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > maintain our own QEMU packages, which is non-trivial.
> > > 
> > > So I want to propose lifting this restriction to make this feature
> > > usable without a custom QEMU.
> > > 
> > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > 
> > The confusion is after someone reuses the ID you are claiming without
> > telling anyone and then linux guests will start binding that driver to
> > your device.
> > 
> > 
> > We want people doing this kind of thing to *at a minimum*
> > go ahead and register a device id with the virtio TC,
> > but really to write and publish a spec.
> 
> Wanting people to register a device ID is a social problem and
> we're trying to apply a technical hammer to it, which is rarely
> an productive approach.
> 
> If we want to demonstrate that vhost-user-device is "risky", then
> how about we rename it to have an 'x-' prefix and thus disclaim
> any support for it, but none the less allow its use. Document it
> as an experimental device, and if it breaks, users get to keep
> both pieces.

Maybe with the insecure tag you are working on?
And disable in the default config?


> It seems like it would be useful before any virtio spec submission
> as a mechanism by which users can experiment to finese their ideas
> prior to getting to the point of needing to make a spec proposal.
> 
> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Daniel P. Berrangé]

On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > This removes the change introduced in [1] that prevents the use of
> > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > 
> > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > 
> > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > ---
> > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > introduced.
> > > > 
> > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > google for "vhost-user-device" I've seen no confused users.
> > > > 
> > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > maintain our own QEMU packages, which is non-trivial.
> > > > 
> > > > So I want to propose lifting this restriction to make this feature
> > > > usable without a custom QEMU.
> > > > 
> > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > 
> > > The confusion is after someone reuses the ID you are claiming without
> > > telling anyone and then linux guests will start binding that driver to
> > > your device.
> > > 
> > > 
> > > We want people doing this kind of thing to *at a minimum*
> > > go ahead and register a device id with the virtio TC,
> > > but really to write and publish a spec.
> > 
> > Wanting people to register a device ID is a social problem and
> > we're trying to apply a technical hammer to it, which is rarely
> > an productive approach.
> > 
> > If we want to demonstrate that vhost-user-device is "risky", then
> > how about we rename it to have an 'x-' prefix and thus disclaim
> > any support for it, but none the less allow its use. Document it
> > as an experimental device, and if it breaks, users get to keep
> > both pieces.
> 
> Maybe with the insecure tag you are working on?

Sure.

> And disable in the default config?

Disabling in default config would retain the very problem that Christian
is trying to solve - that no distro would have the functionality available
for users.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Alex Bennée]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
>> On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
>> > This removes the change introduced in [1] that prevents the use of
>> > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
>> > 
>> > [1]: 6275989647efb708f126eb4f880e593792301ed4
>> > 
>> > Signed-off-by: Christian Speich <c.speich@avm.de>
>> > ---
>> > vhost-user-device and vhost-user-device-pci started out as user
>> > creatable devices. This was changed in [1] when the vhost-user-base was
>> > introduced.
>> > 
>> > The reason given is to prevent user confusion. Searching qemu-discuss or
>> > google for "vhost-user-device" I've seen no confused users.
>> > 
>> > Our use case is to provide wifi emulation using "vhost-user-device-pci",
>> > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
>> > 24.04. With newer QEMU versions we now need to patch, distribute and
>> > maintain our own QEMU packages, which is non-trivial.
>> > 
>> > So I want to propose lifting this restriction to make this feature
>> > usable without a custom QEMU.
>> > 
>> > [1]: 6275989647efb708f126eb4f880e593792301ed4
>> 
>> The confusion is after someone reuses the ID you are claiming without
>> telling anyone and then linux guests will start binding that driver to
>> your device.
>> 
>> 
>> We want people doing this kind of thing to *at a minimum*
>> go ahead and register a device id with the virtio TC,
>> but really to write and publish a spec.
>
> Wanting people to register a device ID is a social problem and
> we're trying to apply a technical hammer to it, which is rarely
> an productive approach.
>
> If we want to demonstrate that vhost-user-device is "risky", then
> how about we rename it to have an 'x-' prefix and thus disclaim
> any support for it, but none the less allow its use. Document it
> as an experimental device, and if it breaks, users get to keep
> both pieces.
>
> It seems like it would be useful before any virtio spec submission
> as a mechanism by which users can experiment to finese their ideas
> prior to getting to the point of needing to make a spec proposal.

That's basically it. Adding the stubs is fairly trivial for vhost-user
backends that implement the config space but you can't add stubs for
things that are currently RFC specs. Also you are forcing a delay for
the spec to be updated and then wait for the next QEMU with the stub
added.

>
> With regards,
> Daniel

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Michael S. Tsirkin]

On Mon, Sep 22, 2025 at 01:49:55PM +0100, Daniel P. Berrangé wrote:
> On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > > This removes the change introduced in [1] that prevents the use of
> > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > > 
> > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > 
> > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > > ---
> > > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > > introduced.
> > > > > 
> > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > > google for "vhost-user-device" I've seen no confused users.
> > > > > 
> > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > > maintain our own QEMU packages, which is non-trivial.
> > > > > 
> > > > > So I want to propose lifting this restriction to make this feature
> > > > > usable without a custom QEMU.
> > > > > 
> > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > 
> > > > The confusion is after someone reuses the ID you are claiming without
> > > > telling anyone and then linux guests will start binding that driver to
> > > > your device.
> > > > 
> > > > 
> > > > We want people doing this kind of thing to *at a minimum*
> > > > go ahead and register a device id with the virtio TC,
> > > > but really to write and publish a spec.
> > > 
> > > Wanting people to register a device ID is a social problem and
> > > we're trying to apply a technical hammer to it, which is rarely
> > > an productive approach.
> > > 
> > > If we want to demonstrate that vhost-user-device is "risky", then
> > > how about we rename it to have an 'x-' prefix and thus disclaim
> > > any support for it, but none the less allow its use. Document it
> > > as an experimental device, and if it breaks, users get to keep
> > > both pieces.
> > 
> > Maybe with the insecure tag you are working on?
> 
> Sure.
> 
> > And disable in the default config?
> 
> Disabling in default config would retain the very problem that Christian
> is trying to solve - that no distro would have the functionality available
> for users.

I think his problem is that he has to patch qemu.

As described, this is a developer option not an end user one.


I know Red Hat will disable it anyway - we support what we ship.


> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Christian Speich via]

On Mon, Sep 22, 2025 at 09:08:47AM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 22, 2025 at 01:49:55PM +0100, Daniel P. Berrangé wrote:
> > On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > > > This removes the change introduced in [1] that prevents the use of
> > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > > > 
> > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > > 
> > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > > > ---
> > > > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > > > introduced.
> > > > > > 
> > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > > > google for "vhost-user-device" I've seen no confused users.
> > > > > > 
> > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > > > maintain our own QEMU packages, which is non-trivial.
> > > > > > 
> > > > > > So I want to propose lifting this restriction to make this feature
> > > > > > usable without a custom QEMU.
> > > > > > 
> > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > 
> > > > > The confusion is after someone reuses the ID you are claiming without
> > > > > telling anyone and then linux guests will start binding that driver to
> > > > > your device.
> > > > > 
> > > > > 
> > > > > We want people doing this kind of thing to *at a minimum*
> > > > > go ahead and register a device id with the virtio TC,
> > > > > but really to write and publish a spec.
> > > > 
> > > > Wanting people to register a device ID is a social problem and
> > > > we're trying to apply a technical hammer to it, which is rarely
> > > > an productive approach.
> > > > 
> > > > If we want to demonstrate that vhost-user-device is "risky", then
> > > > how about we rename it to have an 'x-' prefix and thus disclaim
> > > > any support for it, but none the less allow its use. Document it
> > > > as an experimental device, and if it breaks, users get to keep
> > > > both pieces.
> > > 
> > > Maybe with the insecure tag you are working on?
> > 
> > Sure.
> > 
> > > And disable in the default config?
> > 
> > Disabling in default config would retain the very problem that Christian
> > is trying to solve - that no distro would have the functionality available
> > for users.
> 
> I think his problem is that he has to patch qemu.

Yes I'm trying to avoid that. Patching qemu also involes providing updates
(and security patches!) for it. This is a very high burden to turn this
simple flag on.

> 
> As described, this is a developer option not an end user one.

I don't really get the distintion between developer and end user here.

As a developer I'm an end user too, I'm concerned with the linux kernel
and the additional host tooling for mac80211_hwsim support but QEMU
I'm just using as an user.

Greetings,
Christian

> 
> 
> I know Red Hat will disable it anyway - we support what we ship.
> 
> 
> > With regards,
> > Daniel
> > -- 
> > |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> > |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> > |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 
> 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Michael S. Tsirkin]

On Mon, Sep 22, 2025 at 03:26:23PM +0200, Christian Speich wrote:
> On Mon, Sep 22, 2025 at 09:08:47AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Sep 22, 2025 at 01:49:55PM +0100, Daniel P. Berrangé wrote:
> > > On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
> > > > On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> > > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > > > > This removes the change introduced in [1] that prevents the use of
> > > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > > > > 
> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > > > 
> > > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > > > > ---
> > > > > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > > > > introduced.
> > > > > > > 
> > > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > > > > google for "vhost-user-device" I've seen no confused users.
> > > > > > > 
> > > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > > > > maintain our own QEMU packages, which is non-trivial.
> > > > > > > 
> > > > > > > So I want to propose lifting this restriction to make this feature
> > > > > > > usable without a custom QEMU.
> > > > > > > 
> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > > 
> > > > > > The confusion is after someone reuses the ID you are claiming without
> > > > > > telling anyone and then linux guests will start binding that driver to
> > > > > > your device.
> > > > > > 
> > > > > > 
> > > > > > We want people doing this kind of thing to *at a minimum*
> > > > > > go ahead and register a device id with the virtio TC,
> > > > > > but really to write and publish a spec.
> > > > > 
> > > > > Wanting people to register a device ID is a social problem and
> > > > > we're trying to apply a technical hammer to it, which is rarely
> > > > > an productive approach.
> > > > > 
> > > > > If we want to demonstrate that vhost-user-device is "risky", then
> > > > > how about we rename it to have an 'x-' prefix and thus disclaim
> > > > > any support for it, but none the less allow its use. Document it
> > > > > as an experimental device, and if it breaks, users get to keep
> > > > > both pieces.
> > > > 
> > > > Maybe with the insecure tag you are working on?
> > > 
> > > Sure.
> > > 
> > > > And disable in the default config?
> > > 
> > > Disabling in default config would retain the very problem that Christian
> > > is trying to solve - that no distro would have the functionality available
> > > for users.
> > 
> > I think his problem is that he has to patch qemu.
> 
> Yes I'm trying to avoid that. Patching qemu also involes providing updates
> (and security patches!) for it. This is a very high burden to turn this
> simple flag on.
> 
> > 
> > As described, this is a developer option not an end user one.
> 
> I don't really get the distintion between developer and end user here.
> 
> As a developer I'm an end user too, I'm concerned with the linux kernel
> and the additional host tooling for mac80211_hwsim support but QEMU
> I'm just using as an user.
> 
> Greetings,
> Christian

Are you ok with building qemu with an extra config flag?



> > 
> > 
> > I know Red Hat will disable it anyway - we support what we ship.
> > 
> > 
> > > With regards,
> > > Daniel
> > > -- 
> > > |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> > > |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> > > |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> > 
> > 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Christian Speich]

On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > This removes the change introduced in [1] that prevents the use of
> > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > 
> > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > 
> > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > ---
> > > vhost-user-device and vhost-user-device-pci started out as user
> > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > introduced.
> > > 
> > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > google for "vhost-user-device" I've seen no confused users.
> > > 
> > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > maintain our own QEMU packages, which is non-trivial.
> > > 
> > > So I want to propose lifting this restriction to make this feature
> > > usable without a custom QEMU.
> > > 
> > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > 
> > The confusion is after someone reuses the ID you are claiming without
> > telling anyone and then linux guests will start binding that driver to
> > your device.
> > 
> > 
> > We want people doing this kind of thing to *at a minimum*
> > go ahead and register a device id with the virtio TC,
> > but really to write and publish a spec.
> 
> Wanting people to register a device ID is a social problem and
> we're trying to apply a technical hammer to it, which is rarely
> an productive approach.
> 
> If we want to demonstrate that vhost-user-device is "risky", then
> how about we rename it to have an 'x-' prefix and thus disclaim
> any support for it, but none the less allow its use. Document it
> as an experimental device, and if it breaks, users get to keep
> both pieces.

I don't mind the 'x-'. And if that makes it clear, that this is used
without any warrenty, sure!

However I'm not sure where the "risky" comes from. Initially confusion
was given as reason.

Initially I thought about some kind of '--i-really-want-to-do-this'
flag, but somehow I don't really see this device to bethis harmful
to to warrent that big of a deterrent.

Kind regards,
Christian

> 
> It seems like it would be useful before any virtio spec submission
> as a mechanism by which users can experiment to finese their ideas
> prior to getting to the point of needing to make a spec proposal.
> 
> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 
> 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Christian Speich]

On Mon, Sep 22, 2025 at 09:30:33AM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 22, 2025 at 03:26:23PM +0200, Christian Speich wrote:
> > On Mon, Sep 22, 2025 at 09:08:47AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Sep 22, 2025 at 01:49:55PM +0100, Daniel P. Berrangé wrote:
> > > > On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
> > > > > On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> > > > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > > > > > This removes the change introduced in [1] that prevents the use of
> > > > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > > > > > 
> > > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > > > > 
> > > > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > > > > > ---
> > > > > > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > > > > > introduced.
> > > > > > > > 
> > > > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > > > > > google for "vhost-user-device" I've seen no confused users.
> > > > > > > > 
> > > > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > > > > > maintain our own QEMU packages, which is non-trivial.
> > > > > > > > 
> > > > > > > > So I want to propose lifting this restriction to make this feature
> > > > > > > > usable without a custom QEMU.
> > > > > > > > 
> > > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > > > 
> > > > > > > The confusion is after someone reuses the ID you are claiming without
> > > > > > > telling anyone and then linux guests will start binding that driver to
> > > > > > > your device.
> > > > > > > 
> > > > > > > 
> > > > > > > We want people doing this kind of thing to *at a minimum*
> > > > > > > go ahead and register a device id with the virtio TC,
> > > > > > > but really to write and publish a spec.
> > > > > > 
> > > > > > Wanting people to register a device ID is a social problem and
> > > > > > we're trying to apply a technical hammer to it, which is rarely
> > > > > > an productive approach.
> > > > > > 
> > > > > > If we want to demonstrate that vhost-user-device is "risky", then
> > > > > > how about we rename it to have an 'x-' prefix and thus disclaim
> > > > > > any support for it, but none the less allow its use. Document it
> > > > > > as an experimental device, and if it breaks, users get to keep
> > > > > > both pieces.
> > > > > 
> > > > > Maybe with the insecure tag you are working on?
> > > > 
> > > > Sure.
> > > > 
> > > > > And disable in the default config?
> > > > 
> > > > Disabling in default config would retain the very problem that Christian
> > > > is trying to solve - that no distro would have the functionality available
> > > > for users.
> > > 
> > > I think his problem is that he has to patch qemu.
> > 
> > Yes I'm trying to avoid that. Patching qemu also involes providing updates
> > (and security patches!) for it. This is a very high burden to turn this
> > simple flag on.
> > 
> > > 
> > > As described, this is a developer option not an end user one.
> > 
> > I don't really get the distintion between developer and end user here.
> > 
> > As a developer I'm an end user too, I'm concerned with the linux kernel
> > and the additional host tooling for mac80211_hwsim support but QEMU
> > I'm just using as an user.
> > 
> > Greetings,
> > Christian
> 
> Are you ok with building qemu with an extra config flag?

No, this has the same downsides as patching does.

I myself don't mind building it, I prefer not to. And we have internal end users
which we would need to distribute the patched (or config enabled) QEMU to. This
part I really don't want to do, as it is quite involved.

Greetings,
Christian

> 
> 
> 
> > > 
> > > 
> > > I know Red Hat will disable it anyway - we support what we ship.
> > > 
> > > 
> > > > With regards,
> > > > Daniel
> > > > -- 
> > > > |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> > > > |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> > > > |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> > > 
> > > 
> 
> 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Michael S. Tsirkin]

On Mon, Sep 22, 2025 at 01:11:33PM +0200, Christian Speich wrote:
> On Mon, Sep 22, 2025 at 06:56:31AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Sep 22, 2025 at 12:40:33PM +0200, Christian Speich wrote:
> > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > > This removes the change introduced in [1] that prevents the use of
> > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > > 
> > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > 
> > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > > ---
> > > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > > introduced.
> > > > > 
> > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > > google for "vhost-user-device" I've seen no confused users.
> > > > > 
> > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > > maintain our own QEMU packages, which is non-trivial.
> > > > > 
> > > > > So I want to propose lifting this restriction to make this feature
> > > > > usable without a custom QEMU.
> > > > > 
> > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > 
> > > > The confusion is after someone reuses the ID you are claiming without
> > > > telling anyone and then linux guests will start binding that driver to
> > > > your device.
> > > 
> > > Thanks for clarifciation, In our use-case we use mac80211_hwsim which is
> > > in linux upstream (with the ID 29). So I think a potential reuse here
> > > is something that linux upstream already deals with.
> > 
> > So just allow that one?
> 
> That would solve our problem.
> 
> However, I'm finding it somwhat odd to artifically force the user only use
> QEMU it the "allowed way". I'd much rather see that virtio-user-device is
> usuable as is (and mac80211_hwsim is not a special case and just works).
> 
> Regards,
> Christian

We can combine both. Want to try?


> > 
> > > > 
> > > > 
> > > > We want people doing this kind of thing to *at a minimum*
> > > > go ahead and register a device id with the virtio TC,
> > > > but really to write and publish a spec.
> > > 
> > > I understand this desire, I'm not sure how this relates with the ability
> > > to let a user create a vhost-user-device or not.
> > > 
> > > Kind Regards,
> > > Christian
> > > 
> > > > 
> > > > 
> > > > > ---
> > > > >  docs/system/devices/vhost-user.rst | 10 ----------
> > > > >  hw/virtio/vhost-user-device-pci.c  |  3 ---
> > > > >  hw/virtio/vhost-user-device.c      |  3 ---
> > > > >  3 files changed, 16 deletions(-)
> > > > > 
> > > > > diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
> > > > > index 35259d8ec7c666aa0c56497b8261f48d77216ad5..2d130f9767dbb1cbb85cef43c63dc9a8d7b30d4a 100644
> > > > > --- a/docs/system/devices/vhost-user.rst
> > > > > +++ b/docs/system/devices/vhost-user.rst
> > > > > @@ -73,16 +73,6 @@ all the required parameters including:
> > > > >    - The ``num_vqs`` it needs and their ``vq_size``
> > > > >    - The ``config_size`` if needed
> > > > >  
> > > > > -.. note::
> > > > > -  To prevent user confusion you cannot currently instantiate
> > > > > -  vhost-user-device without first patching out::
> > > > > -
> > > > > -    /* Reason: stop inexperienced users confusing themselves */
> > > > > -    dc->user_creatable = false;
> > > > > -
> > > > > -  in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
> > > > > -  rebuilding.
> > > > > -
> > > > >  vhost-user daemon
> > > > >  =================
> > > > >  
> > > > > diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
> > > > > index f10bac874e78429c633752a4ce9db28385b3bb07..c76a856c9b9a67d941a93929244216658ff2a156 100644
> > > > > --- a/hw/virtio/vhost-user-device-pci.c
> > > > > +++ b/hw/virtio/vhost-user-device-pci.c
> > > > > @@ -38,9 +38,6 @@ static void vhost_user_device_pci_class_init(ObjectClass *klass,
> > > > >      VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> > > > >      PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> > > > >  
> > > > > -    /* Reason: stop users confusing themselves */
> > > > > -    dc->user_creatable = false;
> > > > > -
> > > > >      k->realize = vhost_user_device_pci_realize;
> > > > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > > >      pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > > > > diff --git a/hw/virtio/vhost-user-device.c b/hw/virtio/vhost-user-device.c
> > > > > index 3939bdf755222a281da8ca22243d7d4f16990a66..1bea496afd0137ba9b42009f6252acf6800528d1 100644
> > > > > --- a/hw/virtio/vhost-user-device.c
> > > > > +++ b/hw/virtio/vhost-user-device.c
> > > > > @@ -41,9 +41,6 @@ static void vud_class_init(ObjectClass *klass, const void *data)
> > > > >  {
> > > > >      DeviceClass *dc = DEVICE_CLASS(klass);
> > > > >  
> > > > > -    /* Reason: stop inexperienced users confusing themselves */
> > > > > -    dc->user_creatable = false;
> > > > > -
> > > > >      device_class_set_props(dc, vud_properties);
> > > > >      dc->vmsd = &vud_vmstate;
> > > > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > > > 
> > > > > ---
> > > > > base-commit: e7c1e8043a69c5a8efa39d4f9d111f7c72c076e6
> > > > > change-id: 20250919-vhost-user-device-creatable-b7f9b7b5bfb2
> > > > > 
> > > > > Best regards,
> > > > > -- 
> > > > > Christian Speich <c.speich@avm.de>
> > > > 
> > > > 
> > 
> > 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Daniel P. Berrangé]

On Mon, Sep 22, 2025 at 03:33:59PM +0200, Christian Speich wrote:
> On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > This removes the change introduced in [1] that prevents the use of
> > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > 
> > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > 
> > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > ---
> > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > introduced.
> > > > 
> > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > google for "vhost-user-device" I've seen no confused users.
> > > > 
> > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > maintain our own QEMU packages, which is non-trivial.
> > > > 
> > > > So I want to propose lifting this restriction to make this feature
> > > > usable without a custom QEMU.
> > > > 
> > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > 
> > > The confusion is after someone reuses the ID you are claiming without
> > > telling anyone and then linux guests will start binding that driver to
> > > your device.
> > > 
> > > 
> > > We want people doing this kind of thing to *at a minimum*
> > > go ahead and register a device id with the virtio TC,
> > > but really to write and publish a spec.
> > 
> > Wanting people to register a device ID is a social problem and
> > we're trying to apply a technical hammer to it, which is rarely
> > an productive approach.
> > 
> > If we want to demonstrate that vhost-user-device is "risky", then
> > how about we rename it to have an 'x-' prefix and thus disclaim
> > any support for it, but none the less allow its use. Document it
> > as an experimental device, and if it breaks, users get to keep
> > both pieces.
> 
> I don't mind the 'x-'. And if that makes it clear, that this is used
> without any warrenty, sure!
> 
> However I'm not sure where the "risky" comes from. Initially confusion
> was given as reason.

I view it as "risky" in two ways

 - this device makes it very easy for a user to shoot themselves in
   the foot
 - we dont want to have to think about compatibility across QEMU
   releases in case there is something peculiar about a particular
   device type.

IMHO, adding the 'x-' prefix and disclaiming full support is sufficient
mitigation.

> Initially I thought about some kind of '--i-really-want-to-do-this'
> flag, but somehow I don't really see this device to bethis harmful
> to to warrent that big of a deterrent.

I agree.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Alex Bennée]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Mon, Sep 22, 2025 at 03:26:23PM +0200, Christian Speich wrote:
>> On Mon, Sep 22, 2025 at 09:08:47AM -0400, Michael S. Tsirkin wrote:
>> > On Mon, Sep 22, 2025 at 01:49:55PM +0100, Daniel P. Berrangé wrote:
>> > > On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
>> > > > On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
>> > > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
>> > > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
>> > > > > > > This removes the change introduced in [1] that prevents the use of
>> > > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
>> > > > > > > 
>> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
>> > > > > > > 
>> > > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
>> > > > > > > ---
>> > > > > > > vhost-user-device and vhost-user-device-pci started out as user
>> > > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
>> > > > > > > introduced.
>> > > > > > > 
>> > > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
>> > > > > > > google for "vhost-user-device" I've seen no confused users.
>> > > > > > > 
>> > > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
>> > > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
>> > > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
>> > > > > > > maintain our own QEMU packages, which is non-trivial.
>> > > > > > > 
>> > > > > > > So I want to propose lifting this restriction to make this feature
>> > > > > > > usable without a custom QEMU.
>> > > > > > > 
>> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
>> > > > > > 
>> > > > > > The confusion is after someone reuses the ID you are claiming without
>> > > > > > telling anyone and then linux guests will start binding that driver to
>> > > > > > your device.
>> > > > > > 
>> > > > > > 
>> > > > > > We want people doing this kind of thing to *at a minimum*
>> > > > > > go ahead and register a device id with the virtio TC,
>> > > > > > but really to write and publish a spec.
>> > > > > 
>> > > > > Wanting people to register a device ID is a social problem and
>> > > > > we're trying to apply a technical hammer to it, which is rarely
>> > > > > an productive approach.
>> > > > > 
>> > > > > If we want to demonstrate that vhost-user-device is "risky", then
>> > > > > how about we rename it to have an 'x-' prefix and thus disclaim
>> > > > > any support for it, but none the less allow its use. Document it
>> > > > > as an experimental device, and if it breaks, users get to keep
>> > > > > both pieces.
>> > > > 
>> > > > Maybe with the insecure tag you are working on?
>> > > 
>> > > Sure.
>> > > 
>> > > > And disable in the default config?
>> > > 
>> > > Disabling in default config would retain the very problem that Christian
>> > > is trying to solve - that no distro would have the functionality available
>> > > for users.
>> > 
>> > I think his problem is that he has to patch qemu.
>> 
>> Yes I'm trying to avoid that. Patching qemu also involes providing updates
>> (and security patches!) for it. This is a very high burden to turn this
>> simple flag on.
>> 
>> > 
>> > As described, this is a developer option not an end user one.
>> 
>> I don't really get the distintion between developer and end user here.
>> 
>> As a developer I'm an end user too, I'm concerned with the linux kernel
>> and the additional host tooling for mac80211_hwsim support but QEMU
>> I'm just using as an user.
>> 
>> Greetings,
>> Christian
>
> Are you ok with building qemu with an extra config flag?

In my patch I gated the feature on:

  VHOST_USER_TEST

so it's easy to patch out of the default config.

>
>
>
>> > 
>> > 
>> > I know Red Hat will disable it anyway - we support what we ship.
>> > 
>> > 
>> > > With regards,
>> > > Daniel
>> > > -- 
>> > > |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
>> > > |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
>> > > |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
>> > 
>> > 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Christian Speich]

On Mon, Sep 22, 2025 at 10:37:40AM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 22, 2025 at 01:11:33PM +0200, Christian Speich wrote:
> > On Mon, Sep 22, 2025 at 06:56:31AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Sep 22, 2025 at 12:40:33PM +0200, Christian Speich wrote:
> > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > > > This removes the change introduced in [1] that prevents the use of
> > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > > > 
> > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > > 
> > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > > > ---
> > > > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > > > introduced.
> > > > > > 
> > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > > > google for "vhost-user-device" I've seen no confused users.
> > > > > > 
> > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > > > maintain our own QEMU packages, which is non-trivial.
> > > > > > 
> > > > > > So I want to propose lifting this restriction to make this feature
> > > > > > usable without a custom QEMU.
> > > > > > 
> > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > 
> > > > > The confusion is after someone reuses the ID you are claiming without
> > > > > telling anyone and then linux guests will start binding that driver to
> > > > > your device.
> > > > 
> > > > Thanks for clarifciation, In our use-case we use mac80211_hwsim which is
> > > > in linux upstream (with the ID 29). So I think a potential reuse here
> > > > is something that linux upstream already deals with.
> > > 
> > > So just allow that one?
> > 
> > That would solve our problem.
> > 
> > However, I'm finding it somwhat odd to artifically force the user only use
> > QEMU it the "allowed way". I'd much rather see that virtio-user-device is
> > usuable as is (and mac80211_hwsim is not a special case and just works).
> > 
> > Regards,
> > Christian
> 
> We can combine both. Want to try?

I'm not sure what both means here?

Greetings,
Christian

> 
> 
> > > 
> > > > > 
> > > > > 
> > > > > We want people doing this kind of thing to *at a minimum*
> > > > > go ahead and register a device id with the virtio TC,
> > > > > but really to write and publish a spec.
> > > > 
> > > > I understand this desire, I'm not sure how this relates with the ability
> > > > to let a user create a vhost-user-device or not.
> > > > 
> > > > Kind Regards,
> > > > Christian
> > > > 
> > > > > 
> > > > > 
> > > > > > ---
> > > > > >  docs/system/devices/vhost-user.rst | 10 ----------
> > > > > >  hw/virtio/vhost-user-device-pci.c  |  3 ---
> > > > > >  hw/virtio/vhost-user-device.c      |  3 ---
> > > > > >  3 files changed, 16 deletions(-)
> > > > > > 
> > > > > > diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
> > > > > > index 35259d8ec7c666aa0c56497b8261f48d77216ad5..2d130f9767dbb1cbb85cef43c63dc9a8d7b30d4a 100644
> > > > > > --- a/docs/system/devices/vhost-user.rst
> > > > > > +++ b/docs/system/devices/vhost-user.rst
> > > > > > @@ -73,16 +73,6 @@ all the required parameters including:
> > > > > >    - The ``num_vqs`` it needs and their ``vq_size``
> > > > > >    - The ``config_size`` if needed
> > > > > >  
> > > > > > -.. note::
> > > > > > -  To prevent user confusion you cannot currently instantiate
> > > > > > -  vhost-user-device without first patching out::
> > > > > > -
> > > > > > -    /* Reason: stop inexperienced users confusing themselves */
> > > > > > -    dc->user_creatable = false;
> > > > > > -
> > > > > > -  in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
> > > > > > -  rebuilding.
> > > > > > -
> > > > > >  vhost-user daemon
> > > > > >  =================
> > > > > >  
> > > > > > diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
> > > > > > index f10bac874e78429c633752a4ce9db28385b3bb07..c76a856c9b9a67d941a93929244216658ff2a156 100644
> > > > > > --- a/hw/virtio/vhost-user-device-pci.c
> > > > > > +++ b/hw/virtio/vhost-user-device-pci.c
> > > > > > @@ -38,9 +38,6 @@ static void vhost_user_device_pci_class_init(ObjectClass *klass,
> > > > > >      VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> > > > > >      PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> > > > > >  
> > > > > > -    /* Reason: stop users confusing themselves */
> > > > > > -    dc->user_creatable = false;
> > > > > > -
> > > > > >      k->realize = vhost_user_device_pci_realize;
> > > > > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > > > >      pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > > > > > diff --git a/hw/virtio/vhost-user-device.c b/hw/virtio/vhost-user-device.c
> > > > > > index 3939bdf755222a281da8ca22243d7d4f16990a66..1bea496afd0137ba9b42009f6252acf6800528d1 100644
> > > > > > --- a/hw/virtio/vhost-user-device.c
> > > > > > +++ b/hw/virtio/vhost-user-device.c
> > > > > > @@ -41,9 +41,6 @@ static void vud_class_init(ObjectClass *klass, const void *data)
> > > > > >  {
> > > > > >      DeviceClass *dc = DEVICE_CLASS(klass);
> > > > > >  
> > > > > > -    /* Reason: stop inexperienced users confusing themselves */
> > > > > > -    dc->user_creatable = false;
> > > > > > -
> > > > > >      device_class_set_props(dc, vud_properties);
> > > > > >      dc->vmsd = &vud_vmstate;
> > > > > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > > > > 
> > > > > > ---
> > > > > > base-commit: e7c1e8043a69c5a8efa39d4f9d111f7c72c076e6
> > > > > > change-id: 20250919-vhost-user-device-creatable-b7f9b7b5bfb2
> > > > > > 
> > > > > > Best regards,
> > > > > > -- 
> > > > > > Christian Speich <c.speich@avm.de>
> > > > > 
> > > > > 
> > > 
> > > 
> 
> 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Michael S. Tsirkin]

On Thu, Sep 25, 2025 at 09:56:02AM +0200, Christian Speich wrote:
> On Mon, Sep 22, 2025 at 10:37:40AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Sep 22, 2025 at 01:11:33PM +0200, Christian Speich wrote:
> > > On Mon, Sep 22, 2025 at 06:56:31AM -0400, Michael S. Tsirkin wrote:
> > > > On Mon, Sep 22, 2025 at 12:40:33PM +0200, Christian Speich wrote:
> > > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > > > > This removes the change introduced in [1] that prevents the use of
> > > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > > > > 
> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > > > 
> > > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > > > > ---
> > > > > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > > > > introduced.
> > > > > > > 
> > > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > > > > google for "vhost-user-device" I've seen no confused users.
> > > > > > > 
> > > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > > > > maintain our own QEMU packages, which is non-trivial.
> > > > > > > 
> > > > > > > So I want to propose lifting this restriction to make this feature
> > > > > > > usable without a custom QEMU.
> > > > > > > 
> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > > 
> > > > > > The confusion is after someone reuses the ID you are claiming without
> > > > > > telling anyone and then linux guests will start binding that driver to
> > > > > > your device.
> > > > > 
> > > > > Thanks for clarifciation, In our use-case we use mac80211_hwsim which is
> > > > > in linux upstream (with the ID 29). So I think a potential reuse here
> > > > > is something that linux upstream already deals with.
> > > > 
> > > > So just allow that one?
> > > 
> > > That would solve our problem.
> > > 
> > > However, I'm finding it somwhat odd to artifically force the user only use
> > > QEMU it the "allowed way". I'd much rather see that virtio-user-device is
> > > usuable as is (and mac80211_hwsim is not a special case and just works).
> > > 
> > > Regards,
> > > Christian
> > 
> > We can combine both. Want to try?
> 
> I'm not sure what both means here?
> 
> Greetings,
> Christian

Both add a generic device with a declaration that
it is unsupported and maybe "x-" name prefix, for developers,
and a supported mac80211_hwsim device, for users.


> > 
> > 
> > > > 
> > > > > > 
> > > > > > 
> > > > > > We want people doing this kind of thing to *at a minimum*
> > > > > > go ahead and register a device id with the virtio TC,
> > > > > > but really to write and publish a spec.
> > > > > 
> > > > > I understand this desire, I'm not sure how this relates with the ability
> > > > > to let a user create a vhost-user-device or not.
> > > > > 
> > > > > Kind Regards,
> > > > > Christian
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > ---
> > > > > > >  docs/system/devices/vhost-user.rst | 10 ----------
> > > > > > >  hw/virtio/vhost-user-device-pci.c  |  3 ---
> > > > > > >  hw/virtio/vhost-user-device.c      |  3 ---
> > > > > > >  3 files changed, 16 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
> > > > > > > index 35259d8ec7c666aa0c56497b8261f48d77216ad5..2d130f9767dbb1cbb85cef43c63dc9a8d7b30d4a 100644
> > > > > > > --- a/docs/system/devices/vhost-user.rst
> > > > > > > +++ b/docs/system/devices/vhost-user.rst
> > > > > > > @@ -73,16 +73,6 @@ all the required parameters including:
> > > > > > >    - The ``num_vqs`` it needs and their ``vq_size``
> > > > > > >    - The ``config_size`` if needed
> > > > > > >  
> > > > > > > -.. note::
> > > > > > > -  To prevent user confusion you cannot currently instantiate
> > > > > > > -  vhost-user-device without first patching out::
> > > > > > > -
> > > > > > > -    /* Reason: stop inexperienced users confusing themselves */
> > > > > > > -    dc->user_creatable = false;
> > > > > > > -
> > > > > > > -  in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
> > > > > > > -  rebuilding.
> > > > > > > -
> > > > > > >  vhost-user daemon
> > > > > > >  =================
> > > > > > >  
> > > > > > > diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
> > > > > > > index f10bac874e78429c633752a4ce9db28385b3bb07..c76a856c9b9a67d941a93929244216658ff2a156 100644
> > > > > > > --- a/hw/virtio/vhost-user-device-pci.c
> > > > > > > +++ b/hw/virtio/vhost-user-device-pci.c
> > > > > > > @@ -38,9 +38,6 @@ static void vhost_user_device_pci_class_init(ObjectClass *klass,
> > > > > > >      VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> > > > > > >      PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> > > > > > >  
> > > > > > > -    /* Reason: stop users confusing themselves */
> > > > > > > -    dc->user_creatable = false;
> > > > > > > -
> > > > > > >      k->realize = vhost_user_device_pci_realize;
> > > > > > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > > > > >      pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > > > > > > diff --git a/hw/virtio/vhost-user-device.c b/hw/virtio/vhost-user-device.c
> > > > > > > index 3939bdf755222a281da8ca22243d7d4f16990a66..1bea496afd0137ba9b42009f6252acf6800528d1 100644
> > > > > > > --- a/hw/virtio/vhost-user-device.c
> > > > > > > +++ b/hw/virtio/vhost-user-device.c
> > > > > > > @@ -41,9 +41,6 @@ static void vud_class_init(ObjectClass *klass, const void *data)
> > > > > > >  {
> > > > > > >      DeviceClass *dc = DEVICE_CLASS(klass);
> > > > > > >  
> > > > > > > -    /* Reason: stop inexperienced users confusing themselves */
> > > > > > > -    dc->user_creatable = false;
> > > > > > > -
> > > > > > >      device_class_set_props(dc, vud_properties);
> > > > > > >      dc->vmsd = &vud_vmstate;
> > > > > > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > > > > > 
> > > > > > > ---
> > > > > > > base-commit: e7c1e8043a69c5a8efa39d4f9d111f7c72c076e6
> > > > > > > change-id: 20250919-vhost-user-device-creatable-b7f9b7b5bfb2
> > > > > > > 
> > > > > > > Best regards,
> > > > > > > -- 
> > > > > > > Christian Speich <c.speich@avm.de>
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > 
> > 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Christian Speich]

On Thu, Sep 25, 2025 at 05:33:12AM -0400, Michael S. Tsirkin wrote:
> On Thu, Sep 25, 2025 at 09:56:02AM +0200, Christian Speich wrote:
> > On Mon, Sep 22, 2025 at 10:37:40AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Sep 22, 2025 at 01:11:33PM +0200, Christian Speich wrote:
> > > > On Mon, Sep 22, 2025 at 06:56:31AM -0400, Michael S. Tsirkin wrote:
> > > > > On Mon, Sep 22, 2025 at 12:40:33PM +0200, Christian Speich wrote:
> > > > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > > > > > > This removes the change introduced in [1] that prevents the use of
> > > > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > > > > > > 
> > > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > > > > 
> > > > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > > > > > > ---
> > > > > > > > vhost-user-device and vhost-user-device-pci started out as user
> > > > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > > > > > > introduced.
> > > > > > > > 
> > > > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > > > > > > google for "vhost-user-device" I've seen no confused users.
> > > > > > > > 
> > > > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > > > > > > maintain our own QEMU packages, which is non-trivial.
> > > > > > > > 
> > > > > > > > So I want to propose lifting this restriction to make this feature
> > > > > > > > usable without a custom QEMU.
> > > > > > > > 
> > > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > > > > > 
> > > > > > > The confusion is after someone reuses the ID you are claiming without
> > > > > > > telling anyone and then linux guests will start binding that driver to
> > > > > > > your device.
> > > > > > 
> > > > > > Thanks for clarifciation, In our use-case we use mac80211_hwsim which is
> > > > > > in linux upstream (with the ID 29). So I think a potential reuse here
> > > > > > is something that linux upstream already deals with.
> > > > > 
> > > > > So just allow that one?
> > > > 
> > > > That would solve our problem.
> > > > 
> > > > However, I'm finding it somwhat odd to artifically force the user only use
> > > > QEMU it the "allowed way". I'd much rather see that virtio-user-device is
> > > > usuable as is (and mac80211_hwsim is not a special case and just works).
> > > > 
> > > > Regards,
> > > > Christian
> > > 
> > > We can combine both. Want to try?
> > 
> > I'm not sure what both means here?
> > 
> > Greetings,
> > Christian
> 
> Both add a generic device with a declaration that
> it is unsupported and maybe "x-" name prefix, for developers,
> and a supported mac80211_hwsim device, for users.

Ah, okay, but Alexs mail from 22.9 14:52 states that stubs require a spec:

> [...] Adding the stubs is fairly trivial for vhost-user backends that implement
> the config space but you can't add stubs for things that are currently RFC
> specs. [...]

So I don't think adding a stub for mac80211_hwsim seems appropiated?

Greetings,
Christian

> 
> 
> > > 
> > > 
> > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > We want people doing this kind of thing to *at a minimum*
> > > > > > > go ahead and register a device id with the virtio TC,
> > > > > > > but really to write and publish a spec.
> > > > > > 
> > > > > > I understand this desire, I'm not sure how this relates with the ability
> > > > > > to let a user create a vhost-user-device or not.
> > > > > > 
> > > > > > Kind Regards,
> > > > > > Christian
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > ---
> > > > > > > >  docs/system/devices/vhost-user.rst | 10 ----------
> > > > > > > >  hw/virtio/vhost-user-device-pci.c  |  3 ---
> > > > > > > >  hw/virtio/vhost-user-device.c      |  3 ---
> > > > > > > >  3 files changed, 16 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/docs/system/devices/vhost-user.rst b/docs/system/devices/vhost-user.rst
> > > > > > > > index 35259d8ec7c666aa0c56497b8261f48d77216ad5..2d130f9767dbb1cbb85cef43c63dc9a8d7b30d4a 100644
> > > > > > > > --- a/docs/system/devices/vhost-user.rst
> > > > > > > > +++ b/docs/system/devices/vhost-user.rst
> > > > > > > > @@ -73,16 +73,6 @@ all the required parameters including:
> > > > > > > >    - The ``num_vqs`` it needs and their ``vq_size``
> > > > > > > >    - The ``config_size`` if needed
> > > > > > > >  
> > > > > > > > -.. note::
> > > > > > > > -  To prevent user confusion you cannot currently instantiate
> > > > > > > > -  vhost-user-device without first patching out::
> > > > > > > > -
> > > > > > > > -    /* Reason: stop inexperienced users confusing themselves */
> > > > > > > > -    dc->user_creatable = false;
> > > > > > > > -
> > > > > > > > -  in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
> > > > > > > > -  rebuilding.
> > > > > > > > -
> > > > > > > >  vhost-user daemon
> > > > > > > >  =================
> > > > > > > >  
> > > > > > > > diff --git a/hw/virtio/vhost-user-device-pci.c b/hw/virtio/vhost-user-device-pci.c
> > > > > > > > index f10bac874e78429c633752a4ce9db28385b3bb07..c76a856c9b9a67d941a93929244216658ff2a156 100644
> > > > > > > > --- a/hw/virtio/vhost-user-device-pci.c
> > > > > > > > +++ b/hw/virtio/vhost-user-device-pci.c
> > > > > > > > @@ -38,9 +38,6 @@ static void vhost_user_device_pci_class_init(ObjectClass *klass,
> > > > > > > >      VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> > > > > > > >      PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> > > > > > > >  
> > > > > > > > -    /* Reason: stop users confusing themselves */
> > > > > > > > -    dc->user_creatable = false;
> > > > > > > > -
> > > > > > > >      k->realize = vhost_user_device_pci_realize;
> > > > > > > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > > > > > >      pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > > > > > > > diff --git a/hw/virtio/vhost-user-device.c b/hw/virtio/vhost-user-device.c
> > > > > > > > index 3939bdf755222a281da8ca22243d7d4f16990a66..1bea496afd0137ba9b42009f6252acf6800528d1 100644
> > > > > > > > --- a/hw/virtio/vhost-user-device.c
> > > > > > > > +++ b/hw/virtio/vhost-user-device.c
> > > > > > > > @@ -41,9 +41,6 @@ static void vud_class_init(ObjectClass *klass, const void *data)
> > > > > > > >  {
> > > > > > > >      DeviceClass *dc = DEVICE_CLASS(klass);
> > > > > > > >  
> > > > > > > > -    /* Reason: stop inexperienced users confusing themselves */
> > > > > > > > -    dc->user_creatable = false;
> > > > > > > > -
> > > > > > > >      device_class_set_props(dc, vud_properties);
> > > > > > > >      dc->vmsd = &vud_vmstate;
> > > > > > > >      set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
> > > > > > > > 
> > > > > > > > ---
> > > > > > > > base-commit: e7c1e8043a69c5a8efa39d4f9d111f7c72c076e6
> > > > > > > > change-id: 20250919-vhost-user-device-creatable-b7f9b7b5bfb2
> > > > > > > > 
> > > > > > > > Best regards,
> > > > > > > > -- 
> > > > > > > > Christian Speich <c.speich@avm.de>
> > > > > > > 
> > > > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> 
> 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Christian Speich]

On Mon, Sep 22, 2025 at 04:14:55PM +0100, Alex Bennée wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Mon, Sep 22, 2025 at 03:26:23PM +0200, Christian Speich wrote:
> >> On Mon, Sep 22, 2025 at 09:08:47AM -0400, Michael S. Tsirkin wrote:
> >> > On Mon, Sep 22, 2025 at 01:49:55PM +0100, Daniel P. Berrangé wrote:
> >> > > On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
> >> > > > On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> >> > > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> >> > > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> >> > > > > > > This removes the change introduced in [1] that prevents the use of
> >> > > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> >> > > > > > > 
> >> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> >> > > > > > > 
> >> > > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> >> > > > > > > ---
> >> > > > > > > vhost-user-device and vhost-user-device-pci started out as user
> >> > > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> >> > > > > > > introduced.
> >> > > > > > > 
> >> > > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> >> > > > > > > google for "vhost-user-device" I've seen no confused users.
> >> > > > > > > 
> >> > > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> >> > > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> >> > > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> >> > > > > > > maintain our own QEMU packages, which is non-trivial.
> >> > > > > > > 
> >> > > > > > > So I want to propose lifting this restriction to make this feature
> >> > > > > > > usable without a custom QEMU.
> >> > > > > > > 
> >> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> >> > > > > > 
> >> > > > > > The confusion is after someone reuses the ID you are claiming without
> >> > > > > > telling anyone and then linux guests will start binding that driver to
> >> > > > > > your device.
> >> > > > > > 
> >> > > > > > 
> >> > > > > > We want people doing this kind of thing to *at a minimum*
> >> > > > > > go ahead and register a device id with the virtio TC,
> >> > > > > > but really to write and publish a spec.
> >> > > > > 
> >> > > > > Wanting people to register a device ID is a social problem and
> >> > > > > we're trying to apply a technical hammer to it, which is rarely
> >> > > > > an productive approach.
> >> > > > > 
> >> > > > > If we want to demonstrate that vhost-user-device is "risky", then
> >> > > > > how about we rename it to have an 'x-' prefix and thus disclaim
> >> > > > > any support for it, but none the less allow its use. Document it
> >> > > > > as an experimental device, and if it breaks, users get to keep
> >> > > > > both pieces.
> >> > > > 
> >> > > > Maybe with the insecure tag you are working on?
> >> > > 
> >> > > Sure.
> >> > > 
> >> > > > And disable in the default config?
> >> > > 
> >> > > Disabling in default config would retain the very problem that Christian
> >> > > is trying to solve - that no distro would have the functionality available
> >> > > for users.
> >> > 
> >> > I think his problem is that he has to patch qemu.
> >> 
> >> Yes I'm trying to avoid that. Patching qemu also involes providing updates
> >> (and security patches!) for it. This is a very high burden to turn this
> >> simple flag on.
> >> 
> >> > 
> >> > As described, this is a developer option not an end user one.
> >> 
> >> I don't really get the distintion between developer and end user here.
> >> 
> >> As a developer I'm an end user too, I'm concerned with the linux kernel
> >> and the additional host tooling for mac80211_hwsim support but QEMU
> >> I'm just using as an user.
> >> 
> >> Greetings,
> >> Christian
> >
> > Are you ok with building qemu with an extra config flag?
> 
> In my patch I gated the feature on:
> 
>   VHOST_USER_TEST
> 
> so it's easy to patch out of the default config.

Do you want to move forward with your patch? Or should I update this one with a config
flag and an x- prefix?(which then should look a lot like yours anyway)

Greetings,
Christian

> 
> >
> >
> >
> >> > 
> >> > 
> >> > I know Red Hat will disable it anyway - we support what we ship.
> >> > 
> >> > 
> >> > > With regards,
> >> > > Daniel
> >> > > -- 
> >> > > |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> >> > > |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> >> > > |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> >> > 
> >> > 
> 
> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
> 

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Daniel P. Berrangé]

On Mon, Sep 22, 2025 at 04:14:55PM +0100, Alex Bennée wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Mon, Sep 22, 2025 at 03:26:23PM +0200, Christian Speich wrote:
> >> On Mon, Sep 22, 2025 at 09:08:47AM -0400, Michael S. Tsirkin wrote:
> >> > On Mon, Sep 22, 2025 at 01:49:55PM +0100, Daniel P. Berrangé wrote:
> >> > > On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
> >> > > > On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> >> > > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> >> > > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> >> > > > > > > This removes the change introduced in [1] that prevents the use of
> >> > > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> >> > > > > > > 
> >> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> >> > > > > > > 
> >> > > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> >> > > > > > > ---
> >> > > > > > > vhost-user-device and vhost-user-device-pci started out as user
> >> > > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> >> > > > > > > introduced.
> >> > > > > > > 
> >> > > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> >> > > > > > > google for "vhost-user-device" I've seen no confused users.
> >> > > > > > > 
> >> > > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> >> > > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> >> > > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> >> > > > > > > maintain our own QEMU packages, which is non-trivial.
> >> > > > > > > 
> >> > > > > > > So I want to propose lifting this restriction to make this feature
> >> > > > > > > usable without a custom QEMU.
> >> > > > > > > 
> >> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> >> > > > > > 
> >> > > > > > The confusion is after someone reuses the ID you are claiming without
> >> > > > > > telling anyone and then linux guests will start binding that driver to
> >> > > > > > your device.
> >> > > > > > 
> >> > > > > > 
> >> > > > > > We want people doing this kind of thing to *at a minimum*
> >> > > > > > go ahead and register a device id with the virtio TC,
> >> > > > > > but really to write and publish a spec.
> >> > > > > 
> >> > > > > Wanting people to register a device ID is a social problem and
> >> > > > > we're trying to apply a technical hammer to it, which is rarely
> >> > > > > an productive approach.
> >> > > > > 
> >> > > > > If we want to demonstrate that vhost-user-device is "risky", then
> >> > > > > how about we rename it to have an 'x-' prefix and thus disclaim
> >> > > > > any support for it, but none the less allow its use. Document it
> >> > > > > as an experimental device, and if it breaks, users get to keep
> >> > > > > both pieces.
> >> > > > 
> >> > > > Maybe with the insecure tag you are working on?
> >> > > 
> >> > > Sure.
> >> > > 
> >> > > > And disable in the default config?
> >> > > 
> >> > > Disabling in default config would retain the very problem that Christian
> >> > > is trying to solve - that no distro would have the functionality available
> >> > > for users.
> >> > 
> >> > I think his problem is that he has to patch qemu.
> >> 
> >> Yes I'm trying to avoid that. Patching qemu also involes providing updates
> >> (and security patches!) for it. This is a very high burden to turn this
> >> simple flag on.
> >> 
> >> > 
> >> > As described, this is a developer option not an end user one.
> >> 
> >> I don't really get the distintion between developer and end user here.
> >> 
> >> As a developer I'm an end user too, I'm concerned with the linux kernel
> >> and the additional host tooling for mac80211_hwsim support but QEMU
> >> I'm just using as an user.
> >> 
> > Are you ok with building qemu with an extra config flag?
> 
> In my patch I gated the feature on:
> 
>   VHOST_USER_TEST
> 
> so it's easy to patch out of the default config.

FWIW, we have multiple other test devices that we don't gate behind KConfig
build flags - hyperv-testdev, pc-testdev, pci-testdev & edu.  IMHO the
vhost user device is more compelling to have enabled by default as it can
actually be used todo something useful.

IMHO the rationale for disabling it is more fitting to downstreams like
RHEL.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Michael S. Tsirkin]

On Mon, Sep 29, 2025 at 09:22:02AM +0100, Daniel P. Berrangé wrote:
> On Mon, Sep 22, 2025 at 04:14:55PM +0100, Alex Bennée wrote:
> > "Michael S. Tsirkin" <mst@redhat.com> writes:
> > 
> > > On Mon, Sep 22, 2025 at 03:26:23PM +0200, Christian Speich wrote:
> > >> On Mon, Sep 22, 2025 at 09:08:47AM -0400, Michael S. Tsirkin wrote:
> > >> > On Mon, Sep 22, 2025 at 01:49:55PM +0100, Daniel P. Berrangé wrote:
> > >> > > On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
> > >> > > > On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> > >> > > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > >> > > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > >> > > > > > > This removes the change introduced in [1] that prevents the use of
> > >> > > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > >> > > > > > > 
> > >> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > >> > > > > > > 
> > >> > > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > >> > > > > > > ---
> > >> > > > > > > vhost-user-device and vhost-user-device-pci started out as user
> > >> > > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > >> > > > > > > introduced.
> > >> > > > > > > 
> > >> > > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > >> > > > > > > google for "vhost-user-device" I've seen no confused users.
> > >> > > > > > > 
> > >> > > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > >> > > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > >> > > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > >> > > > > > > maintain our own QEMU packages, which is non-trivial.
> > >> > > > > > > 
> > >> > > > > > > So I want to propose lifting this restriction to make this feature
> > >> > > > > > > usable without a custom QEMU.
> > >> > > > > > > 
> > >> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > >> > > > > > 
> > >> > > > > > The confusion is after someone reuses the ID you are claiming without
> > >> > > > > > telling anyone and then linux guests will start binding that driver to
> > >> > > > > > your device.
> > >> > > > > > 
> > >> > > > > > 
> > >> > > > > > We want people doing this kind of thing to *at a minimum*
> > >> > > > > > go ahead and register a device id with the virtio TC,
> > >> > > > > > but really to write and publish a spec.
> > >> > > > > 
> > >> > > > > Wanting people to register a device ID is a social problem and
> > >> > > > > we're trying to apply a technical hammer to it, which is rarely
> > >> > > > > an productive approach.
> > >> > > > > 
> > >> > > > > If we want to demonstrate that vhost-user-device is "risky", then
> > >> > > > > how about we rename it to have an 'x-' prefix and thus disclaim
> > >> > > > > any support for it, but none the less allow its use. Document it
> > >> > > > > as an experimental device, and if it breaks, users get to keep
> > >> > > > > both pieces.
> > >> > > > 
> > >> > > > Maybe with the insecure tag you are working on?
> > >> > > 
> > >> > > Sure.
> > >> > > 
> > >> > > > And disable in the default config?
> > >> > > 
> > >> > > Disabling in default config would retain the very problem that Christian
> > >> > > is trying to solve - that no distro would have the functionality available
> > >> > > for users.
> > >> > 
> > >> > I think his problem is that he has to patch qemu.
> > >> 
> > >> Yes I'm trying to avoid that. Patching qemu also involes providing updates
> > >> (and security patches!) for it. This is a very high burden to turn this
> > >> simple flag on.
> > >> 
> > >> > 
> > >> > As described, this is a developer option not an end user one.
> > >> 
> > >> I don't really get the distintion between developer and end user here.
> > >> 
> > >> As a developer I'm an end user too, I'm concerned with the linux kernel
> > >> and the additional host tooling for mac80211_hwsim support but QEMU
> > >> I'm just using as an user.
> > >> 
> > > Are you ok with building qemu with an extra config flag?
> > 
> > In my patch I gated the feature on:
> > 
> >   VHOST_USER_TEST
> > 
> > so it's easy to patch out of the default config.
> 
> FWIW, we have multiple other test devices that we don't gate behind KConfig
> build flags - hyperv-testdev, pc-testdev, pci-testdev & edu.

Well that's because e.g. kvmtest actually depends on pci-testdev.
IOW it's actually supported.

>  IMHO the
> vhost user device is more compelling to have enabled by default as it can
> actually be used todo something useful.
> 
> IMHO the rationale for disabling it is more fitting to downstreams like
> RHEL.
> 
> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Alex Bennée]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Mon, Sep 29, 2025 at 09:22:02AM +0100, Daniel P. Berrangé wrote:
>> On Mon, Sep 22, 2025 at 04:14:55PM +0100, Alex Bennée wrote:
>> > "Michael S. Tsirkin" <mst@redhat.com> writes:
>> > 
>> > > On Mon, Sep 22, 2025 at 03:26:23PM +0200, Christian Speich wrote:
>> > >> On Mon, Sep 22, 2025 at 09:08:47AM -0400, Michael S. Tsirkin wrote:
>> > >> > On Mon, Sep 22, 2025 at 01:49:55PM +0100, Daniel P. Berrangé wrote:
>> > >> > > On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
>> > >> > > > On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
>> > >> > > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
>> > >> > > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
>> > >> > > > > > > This removes the change introduced in [1] that prevents the use of
>> > >> > > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
>> > >> > > > > > > 
>> > >> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
>> > >> > > > > > > 
>> > >> > > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
>> > >> > > > > > > ---
>> > >> > > > > > > vhost-user-device and vhost-user-device-pci started out as user
>> > >> > > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
>> > >> > > > > > > introduced.
>> > >> > > > > > > 
>> > >> > > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
>> > >> > > > > > > google for "vhost-user-device" I've seen no confused users.
>> > >> > > > > > > 
>> > >> > > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
>> > >> > > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
>> > >> > > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
>> > >> > > > > > > maintain our own QEMU packages, which is non-trivial.
>> > >> > > > > > > 
>> > >> > > > > > > So I want to propose lifting this restriction to make this feature
>> > >> > > > > > > usable without a custom QEMU.
>> > >> > > > > > > 
>> > >> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
>> > >> > > > > > 
>> > >> > > > > > The confusion is after someone reuses the ID you are claiming without
>> > >> > > > > > telling anyone and then linux guests will start binding that driver to
>> > >> > > > > > your device.
>> > >> > > > > > 
>> > >> > > > > > 
>> > >> > > > > > We want people doing this kind of thing to *at a minimum*
>> > >> > > > > > go ahead and register a device id with the virtio TC,
>> > >> > > > > > but really to write and publish a spec.
>> > >> > > > > 
>> > >> > > > > Wanting people to register a device ID is a social problem and
>> > >> > > > > we're trying to apply a technical hammer to it, which is rarely
>> > >> > > > > an productive approach.
>> > >> > > > > 
>> > >> > > > > If we want to demonstrate that vhost-user-device is "risky", then
>> > >> > > > > how about we rename it to have an 'x-' prefix and thus disclaim
>> > >> > > > > any support for it, but none the less allow its use. Document it
>> > >> > > > > as an experimental device, and if it breaks, users get to keep
>> > >> > > > > both pieces.
>> > >> > > > 
>> > >> > > > Maybe with the insecure tag you are working on?
>> > >> > > 
>> > >> > > Sure.
>> > >> > > 
>> > >> > > > And disable in the default config?
>> > >> > > 
>> > >> > > Disabling in default config would retain the very problem that Christian
>> > >> > > is trying to solve - that no distro would have the functionality available
>> > >> > > for users.
>> > >> > 
>> > >> > I think his problem is that he has to patch qemu.
>> > >> 
>> > >> Yes I'm trying to avoid that. Patching qemu also involes providing updates
>> > >> (and security patches!) for it. This is a very high burden to turn this
>> > >> simple flag on.
>> > >> 
>> > >> > 
>> > >> > As described, this is a developer option not an end user one.
>> > >> 
>> > >> I don't really get the distintion between developer and end user here.
>> > >> 
>> > >> As a developer I'm an end user too, I'm concerned with the linux kernel
>> > >> and the additional host tooling for mac80211_hwsim support but QEMU
>> > >> I'm just using as an user.
>> > >> 
>> > > Are you ok with building qemu with an extra config flag?
>> > 
>> > In my patch I gated the feature on:
>> > 
>> >   VHOST_USER_TEST
>> > 
>> > so it's easy to patch out of the default config.
>> 
>> FWIW, we have multiple other test devices that we don't gate behind KConfig
>> build flags - hyperv-testdev, pc-testdev, pci-testdev & edu.
>
> Well that's because e.g. kvmtest actually depends on pci-testdev.
> IOW it's actually supported.

Isn't this solved by having an entry in MAINTAINERS?

Its not like the device isn't useful to developers working on vhost-user
daemons who have yet to acquire a stub. Indeed if the numbers are
correct it should work for any daemon which takes full responsibility
for the config space.

>
>>  IMHO the
>> vhost user device is more compelling to have enabled by default as it can
>> actually be used todo something useful.
>> 
>> IMHO the rationale for disabling it is more fitting to downstreams like
>> RHEL.

Makes sense to me.

>> 
>> With regards,
>> Daniel
>> -- 
>> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
>> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
>> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Daniel P. Berrangé]

On Mon, Sep 29, 2025 at 04:24:44AM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 29, 2025 at 09:22:02AM +0100, Daniel P. Berrangé wrote:
> > On Mon, Sep 22, 2025 at 04:14:55PM +0100, Alex Bennée wrote:
> > > "Michael S. Tsirkin" <mst@redhat.com> writes:
> > > 
> > > > On Mon, Sep 22, 2025 at 03:26:23PM +0200, Christian Speich wrote:
> > > >> On Mon, Sep 22, 2025 at 09:08:47AM -0400, Michael S. Tsirkin wrote:
> > > >> > On Mon, Sep 22, 2025 at 01:49:55PM +0100, Daniel P. Berrangé wrote:
> > > >> > > On Mon, Sep 22, 2025 at 08:15:20AM -0400, Michael S. Tsirkin wrote:
> > > >> > > > On Mon, Sep 22, 2025 at 12:33:26PM +0100, Daniel P. Berrangé wrote:
> > > >> > > > > On Fri, Sep 19, 2025 at 04:07:19PM -0400, Michael S. Tsirkin wrote:
> > > >> > > > > > On Fri, Sep 19, 2025 at 04:30:53PM +0200, Christian Speich wrote:
> > > >> > > > > > > This removes the change introduced in [1] that prevents the use of
> > > >> > > > > > > vhost-user-device and vhost-user-device-pci on unpatched QEMU builds.
> > > >> > > > > > > 
> > > >> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > >> > > > > > > 
> > > >> > > > > > > Signed-off-by: Christian Speich <c.speich@avm.de>
> > > >> > > > > > > ---
> > > >> > > > > > > vhost-user-device and vhost-user-device-pci started out as user
> > > >> > > > > > > creatable devices. This was changed in [1] when the vhost-user-base was
> > > >> > > > > > > introduced.
> > > >> > > > > > > 
> > > >> > > > > > > The reason given is to prevent user confusion. Searching qemu-discuss or
> > > >> > > > > > > google for "vhost-user-device" I've seen no confused users.
> > > >> > > > > > > 
> > > >> > > > > > > Our use case is to provide wifi emulation using "vhost-user-device-pci",
> > > >> > > > > > > which currently is working fine with the QEMU 9.0.2 present in Ubuntu
> > > >> > > > > > > 24.04. With newer QEMU versions we now need to patch, distribute and
> > > >> > > > > > > maintain our own QEMU packages, which is non-trivial.
> > > >> > > > > > > 
> > > >> > > > > > > So I want to propose lifting this restriction to make this feature
> > > >> > > > > > > usable without a custom QEMU.
> > > >> > > > > > > 
> > > >> > > > > > > [1]: 6275989647efb708f126eb4f880e593792301ed4
> > > >> > > > > > 
> > > >> > > > > > The confusion is after someone reuses the ID you are claiming without
> > > >> > > > > > telling anyone and then linux guests will start binding that driver to
> > > >> > > > > > your device.
> > > >> > > > > > 
> > > >> > > > > > 
> > > >> > > > > > We want people doing this kind of thing to *at a minimum*
> > > >> > > > > > go ahead and register a device id with the virtio TC,
> > > >> > > > > > but really to write and publish a spec.
> > > >> > > > > 
> > > >> > > > > Wanting people to register a device ID is a social problem and
> > > >> > > > > we're trying to apply a technical hammer to it, which is rarely
> > > >> > > > > an productive approach.
> > > >> > > > > 
> > > >> > > > > If we want to demonstrate that vhost-user-device is "risky", then
> > > >> > > > > how about we rename it to have an 'x-' prefix and thus disclaim
> > > >> > > > > any support for it, but none the less allow its use. Document it
> > > >> > > > > as an experimental device, and if it breaks, users get to keep
> > > >> > > > > both pieces.
> > > >> > > > 
> > > >> > > > Maybe with the insecure tag you are working on?
> > > >> > > 
> > > >> > > Sure.
> > > >> > > 
> > > >> > > > And disable in the default config?
> > > >> > > 
> > > >> > > Disabling in default config would retain the very problem that Christian
> > > >> > > is trying to solve - that no distro would have the functionality available
> > > >> > > for users.
> > > >> > 
> > > >> > I think his problem is that he has to patch qemu.
> > > >> 
> > > >> Yes I'm trying to avoid that. Patching qemu also involes providing updates
> > > >> (and security patches!) for it. This is a very high burden to turn this
> > > >> simple flag on.
> > > >> 
> > > >> > 
> > > >> > As described, this is a developer option not an end user one.
> > > >> 
> > > >> I don't really get the distintion between developer and end user here.
> > > >> 
> > > >> As a developer I'm an end user too, I'm concerned with the linux kernel
> > > >> and the additional host tooling for mac80211_hwsim support but QEMU
> > > >> I'm just using as an user.
> > > >> 
> > > > Are you ok with building qemu with an extra config flag?
> > > 
> > > In my patch I gated the feature on:
> > > 
> > >   VHOST_USER_TEST
> > > 
> > > so it's easy to patch out of the default config.
> > 
> > FWIW, we have multiple other test devices that we don't gate behind KConfig
> > build flags - hyperv-testdev, pc-testdev, pci-testdev & edu.
> 
> Well that's because e.g. kvmtest actually depends on pci-testdev.
> IOW it's actually supported.

This again just sounds like a downstream 'support' rationalization.
I'm still not seeing a compelling reason why the vhost user generic
device should be disabled by default in upstream, especially if we
mark it as an experimental device with an x- prefix. 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Michael S. Tsirkin]

On Mon, Sep 29, 2025 at 11:07:06AM +0100, Daniel P. Berrangé wrote:
> > Well that's because e.g. kvmtest actually depends on pci-testdev.
> > IOW it's actually supported.
> 
> This again just sounds like a downstream 'support' rationalization.
> I'm still not seeing a compelling reason why the vhost user generic
> device should be disabled by default in upstream, especially if we
> mark it as an experimental device with an x- prefix. 
> 
> With regards,
> Daniel

We can do that. I am still somewhat puzzled by whether making
it unsupported/experimental addresses the actual need, which
seems to be to expose it to end users?

Once something is used in the field, we can't take it back
whether we added x- to the name or not.

What are your thoughts if it's not marked as experimental?

-- 
MST

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Daniel P. Berrangé]

On Sat, Oct 04, 2025 at 01:33:48PM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 29, 2025 at 11:07:06AM +0100, Daniel P. Berrangé wrote:
> > > Well that's because e.g. kvmtest actually depends on pci-testdev.
> > > IOW it's actually supported.
> > 
> > This again just sounds like a downstream 'support' rationalization.
> > I'm still not seeing a compelling reason why the vhost user generic
> > device should be disabled by default in upstream, especially if we
> > mark it as an experimental device with an x- prefix. 
> 
> We can do that. I am still somewhat puzzled by whether making
> it unsupported/experimental addresses the actual need, which
> seems to be to expose it to end users?

My interpretation is that simply having the device exist by default
in QEMU builds is the minimum bar. If we declare it supported, then
that is a "nice to have"  guarantee for long term.

> Once something is used in the field, we can't take it back
> whether we added x- to the name or not.
> 
> What are your thoughts if it's not marked as experimental?

In general my view is that we can't protect against user foolishness.
If they provide inappropriate configuration options to this device
and get broken behaviour, so be it.  If they file bugs against QEMU
our assistance will be very minimal - they get to do the debugging.

On our side as maintainers, the important question is whether exposing
this device ties our hands for future code development.

eg would it unacceptably limit our ability to refactor things in future,
while keeping compat for this exposed device ?

If it would be an undue burden, then it would be worth marking it as
experimental to give us the freedom to make incompatible changes.

If exposing the device has minimal burden anticipated on future work,
then no need to mark it experimental

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virtio: vhost-user-device: Make user creatable again

[Alex Bennée]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Sat, Oct 04, 2025 at 01:33:48PM -0400, Michael S. Tsirkin wrote:
>> On Mon, Sep 29, 2025 at 11:07:06AM +0100, Daniel P. Berrangé wrote:
>> > > Well that's because e.g. kvmtest actually depends on pci-testdev.
>> > > IOW it's actually supported.
>> > 
>> > This again just sounds like a downstream 'support' rationalization.
>> > I'm still not seeing a compelling reason why the vhost user generic
>> > device should be disabled by default in upstream, especially if we
>> > mark it as an experimental device with an x- prefix. 
>> 
>> We can do that. I am still somewhat puzzled by whether making
>> it unsupported/experimental addresses the actual need, which
>> seems to be to expose it to end users?
>
> My interpretation is that simply having the device exist by default
> in QEMU builds is the minimum bar. If we declare it supported, then
> that is a "nice to have"  guarantee for long term.
>
>> Once something is used in the field, we can't take it back
>> whether we added x- to the name or not.
>> 
>> What are your thoughts if it's not marked as experimental?
>
> In general my view is that we can't protect against user foolishness.
> If they provide inappropriate configuration options to this device
> and get broken behaviour, so be it.  If they file bugs against QEMU
> our assistance will be very minimal - they get to do the debugging.
>
> On our side as maintainers, the important question is whether exposing
> this device ties our hands for future code development.
>
> eg would it unacceptably limit our ability to refactor things in future,
> while keeping compat for this exposed device ?

The arguments it exposes aren't really going to change. All it does is
allow you simulate what the boilerplate sets in stone.

> If it would be an undue burden, then it would be worth marking it as
> experimental to give us the freedom to make incompatible changes.

IMHO no I don't think it would be a burden.

>
> If exposing the device has minimal burden anticipated on future work,
> then no need to mark it experimental
>
> With regards,
> Daniel

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro