* Philippe Mathieu-Daudé (philmd@redhat.com) wrote:
> On 3/16/21 6:21 PM, Dr. David Alan Gilbert wrote:
> > Hi,
> > I've got a half-baked idea, which I thought might be worth mentioning.
> >
> > How hard would it be to give qemu a usbredir server rather than client?
> > It would have nothing guest visible but would look logically like the
> > front (?) half of a usb interface; then you could use all of the
> > existing qemu emulated and passthrough device code, to build a usb
> > hierarchy and present it to a remote qemu.
> >
> > You'd get the ability to do emulated USB CDROM/storage, audio, network
> > and the glue for host USB connection (and smart cards??) - all in one
> > client that you can then use for connecting to a remote qemu.
> >
> > The next step of that is to make something analogous to a
> > qemu-storage-daemon, but for USB, so you have something that can
> > do all that USB stuff without actually having any processors.
> >
> > The even crazier step would then be to add a VNC client, and then you
> > have an almost complete remote client.
>
> Similarly to the out-of-process feature (on the same host)?
> Are you also interested in remote use (different host)?
I was mainly interested in it for remote access; but potentially this
provides a clean break point to move all of the USB device emulation
into one separate process.
It's an idea I suggested a few times too, once at least during 2017 KVM Forum multi-process talk, & when it was decided to implement usb CD emulation in spice-gtk (which I wish would use existing qemu code instead, or the NBD server I implemented initially, long time ago..). So yup, I'd like to see this happen too eventually. However it's not so attractive imho, you rather want virtio/vhost-user and for other devices you don't have a choice I'd focus on vfio-user. At some point hopefully, qemu should be able to provide a usb controller via vfio-user if you need it.