[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