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 <[email protected]>
> > > > > > ---
> > > > > > 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 <[email protected]>
> > > > >
> > > > >
> > >
> > >
>
>
