qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Half a usb-redir idea


From: Gerd Hoffmann
Subject: Re: Half a usb-redir idea
Date: Wed, 17 Mar 2021 11:16:50 +0100

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.

take care,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]