RE: Half a usb-redir idea

[Thanos Makatos]

> -----Original Message-----
> From: Qemu-devel <qemu-devel-
> bounces+thanos.makatos=nutanix.com@nongnu.org> On Behalf Of Gerd
> Hoffmann
> Sent: 17 March 2021 10:17
> To: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Cc: victortoso@redhat.com; berrange@redhat.com; qemu-
> devel@nongnu.org
> Subject: Re: Half a usb-redir idea
> 
> On Wed, Mar 17, 2021 at 09:10:51AM +0000, Dr. David Alan Gilbert wrote:
> > * Gerd Hoffmann (kraxel@redhat.com) wrote:
> > > On Tue, Mar 16, 2021 at 05:21:02PM +0000, 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?
> > >
> > > The usb part is probably not that hard.  The devices are not
> > > standalone though.  Tricky is the integration with the rest of qemu,
> > > with the input subsystem (hid devices), chardevs (usb-serial),
> > > network (usb-net), sound (usb-audio), block (usb-storage), ...
> >
> > As long as this was still the qemu binary would that be a problem?
> 
> Well, depends a bit on where you are heading to ...
> 
> If you just want move usb emulation to a separate process (using the multi-
> process qemu infrastructure, or using something like "qemu -machine none -
> device usbredirserver") then no, for the most part it wouldn't be a problem.
> You can just add chardevs, netdevs and blockdevs to the usbredirserver
> qemu process then.  input + hid devices are still a bit tricky though.
> 
> If you want refactor usb emulation to move it into a library and allow reuse
> outside qemu (see vncviewer idea elsewhere in the thread) it would be
> more of a problem of course.
> 
> > > ccid and u2f are probably easierst.
> > > mtp should not be hard too.
> > > maybe storage when limiting support to storage daemon.
> > > then it'll be tricky.
> > > maybe the multi-process qemu effort solves (some of) these problems.
> >
> > It doesn't handle remote does it?
> 
> Not fully sure, but I think vfio-user depends on a shared mapping of guest
> ram, so no remote support.

The vfio-user spec allows for remote support, but it will be over a socket so 
not particularly fast.

> 
> take care,
>   Gerd
>