All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Christian Speich <c.speich@avm.de>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, "Stefano Garzarella" <sgarzare@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH] virtio: vhost-user-device: Make user creatable again
Date: Mon, 22 Sep 2025 15:38:24 +0100	[thread overview]
Message-ID: <aNFfYLX2V4Kz9eZy@redhat.com> (raw)
In-Reply-To: <yw2dep327wpykp2p2losnkidw3kjv5dg3q6ji7dbnymosf5q6b@dgb3dfwsvxia>

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



      reply	other threads:[~2025-09-22 14:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-19 14:30 [PATCH] virtio: vhost-user-device: Make user creatable again Christian Speich
2025-09-19 14:46 ` Stefano Garzarella
2025-09-19 20:07 ` Michael S. Tsirkin
2025-09-22 10:40   ` Christian Speich via
2025-09-22 10:56     ` Michael S. Tsirkin
2025-09-22 11:11       ` Christian Speich via
2025-09-22 14:37         ` Michael S. Tsirkin
2025-09-25  7:56           ` Christian Speich
2025-09-25  9:33             ` Michael S. Tsirkin
2025-09-25 10:14               ` Christian Speich
2025-09-22 11:33   ` Daniel P. Berrangé
2025-09-22 12:15     ` Michael S. Tsirkin
2025-09-22 12:49       ` Daniel P. Berrangé
2025-09-22 13:08         ` Michael S. Tsirkin
2025-09-22 13:26           ` Christian Speich via
2025-09-22 13:30             ` Michael S. Tsirkin
2025-09-22 13:42               ` Christian Speich
2025-09-22 15:14               ` Alex Bennée
2025-09-29  8:12                 ` Christian Speich
2025-09-29  8:22                 ` Daniel P. Berrangé
2025-09-29  8:24                   ` Michael S. Tsirkin
2025-09-29  9:52                     ` Alex Bennée
2025-09-29 10:07                     ` Daniel P. Berrangé
2025-10-04 17:33                       ` Michael S. Tsirkin
2025-10-09 10:20                         ` Daniel P. Berrangé
2025-10-09 16:49                           ` Alex Bennée
2025-09-22 12:51     ` Alex Bennée
2025-09-22 13:33     ` Christian Speich
2025-09-22 14:38       ` Daniel P. Berrangé [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aNFfYLX2V4Kz9eZy@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=c.speich@avm.de \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sgarzare@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.