On Wed, Mar 17, 2021 at 09:10:51AM +0000, Dr. David Alan Gilbert wrote: > * Gerd Hoffmann (kra...@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
