* Half a usb-redir idea @ 2021-03-16 17:21 Dr. David Alan Gilbert 2021-03-16 18:40 ` Philippe Mathieu-Daudé 2021-03-17 6:24 ` Gerd Hoffmann 0 siblings, 2 replies; 9+ messages in thread From: Dr. David Alan Gilbert @ 2021-03-16 17:21 UTC (permalink / raw) To: berrange, kraxel, victortoso; +Cc: qemu-devel 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. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Half a usb-redir idea 2021-03-16 17:21 Half a usb-redir idea Dr. David Alan Gilbert @ 2021-03-16 18:40 ` Philippe Mathieu-Daudé 2021-03-16 18:44 ` Dr. David Alan Gilbert 2021-03-17 6:24 ` Gerd Hoffmann 1 sibling, 1 reply; 9+ messages in thread From: Philippe Mathieu-Daudé @ 2021-03-16 18:40 UTC (permalink / raw) To: Dr. David Alan Gilbert, berrange, kraxel, victortoso; +Cc: qemu-devel 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)? What about DMA accesses? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Half a usb-redir idea 2021-03-16 18:40 ` Philippe Mathieu-Daudé @ 2021-03-16 18:44 ` Dr. David Alan Gilbert 2021-03-16 21:06 ` Marc-André Lureau 2021-03-17 6:30 ` Gerd Hoffmann 0 siblings, 2 replies; 9+ messages in thread From: Dr. David Alan Gilbert @ 2021-03-16 18:44 UTC (permalink / raw) To: Philippe Mathieu-Daudé; +Cc: victortoso, berrange, kraxel, qemu-devel * 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. > What about DMA accesses? I was assuming it was wired to the other half of usbredir than the current qemu client side code, so it would handle it. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Half a usb-redir idea 2021-03-16 18:44 ` Dr. David Alan Gilbert @ 2021-03-16 21:06 ` Marc-André Lureau 2021-03-17 6:30 ` Gerd Hoffmann 1 sibling, 0 replies; 9+ messages in thread From: Marc-André Lureau @ 2021-03-16 21:06 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: QEMU, Victor Toso, Philippe Mathieu-Daudé, Daniel P. Berrange, Gerd Hoffmann [-- Attachment #1: Type: text/plain, Size: 2128 bytes --] Hi On Tue, Mar 16, 2021 at 11:33 PM Dr. David Alan Gilbert <dgilbert@redhat.com> wrote: > * 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. [-- Attachment #2: Type: text/html, Size: 2720 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Half a usb-redir idea 2021-03-16 18:44 ` Dr. David Alan Gilbert 2021-03-16 21:06 ` Marc-André Lureau @ 2021-03-17 6:30 ` Gerd Hoffmann 1 sibling, 0 replies; 9+ messages in thread From: Gerd Hoffmann @ 2021-03-17 6:30 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: berrange, Philippe Mathieu-Daudé, victortoso, qemu-devel Hi, > > What about DMA accesses? > > I was assuming it was wired to the other half of usbredir than > the current qemu client side code, so it would handle it. Yep, that is for the most part handled by the host adapter emulation. The usb device emulation will see an USBPacket struct with an iovec, typically pointing to guest ram, but you can easily have the usbredir server bits point to network packet content instead and the device emulation code wouldn't notice the difference. take care, Gerd ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Half a usb-redir idea 2021-03-16 17:21 Half a usb-redir idea Dr. David Alan Gilbert 2021-03-16 18:40 ` Philippe Mathieu-Daudé @ 2021-03-17 6:24 ` Gerd Hoffmann 2021-03-17 9:10 ` Dr. David Alan Gilbert 1 sibling, 1 reply; 9+ messages in thread From: Gerd Hoffmann @ 2021-03-17 6:24 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: victortoso, berrange, qemu-devel 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), ... 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. take care, Gerd ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Half a usb-redir idea 2021-03-17 6:24 ` Gerd Hoffmann @ 2021-03-17 9:10 ` Dr. David Alan Gilbert 2021-03-17 10:16 ` Gerd Hoffmann 0 siblings, 1 reply; 9+ messages in thread From: Dr. David Alan Gilbert @ 2021-03-17 9:10 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: victortoso, berrange, qemu-devel * 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? > 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? Dave > take care, > Gerd > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Half a usb-redir idea 2021-03-17 9:10 ` Dr. David Alan Gilbert @ 2021-03-17 10:16 ` Gerd Hoffmann 2021-03-17 10:41 ` Thanos Makatos 0 siblings, 1 reply; 9+ messages in thread From: Gerd Hoffmann @ 2021-03-17 10:16 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: victortoso, berrange, qemu-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Half a usb-redir idea 2021-03-17 10:16 ` Gerd Hoffmann @ 2021-03-17 10:41 ` Thanos Makatos 0 siblings, 0 replies; 9+ messages in thread From: Thanos Makatos @ 2021-03-17 10:41 UTC (permalink / raw) To: Gerd Hoffmann, Dr. David Alan Gilbert; +Cc: berrange, victortoso, qemu-devel > -----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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-03-17 10:43 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-16 17:21 Half a usb-redir idea Dr. David Alan Gilbert 2021-03-16 18:40 ` Philippe Mathieu-Daudé 2021-03-16 18:44 ` Dr. David Alan Gilbert 2021-03-16 21:06 ` Marc-André Lureau 2021-03-17 6:30 ` Gerd Hoffmann 2021-03-17 6:24 ` Gerd Hoffmann 2021-03-17 9:10 ` Dr. David Alan Gilbert 2021-03-17 10:16 ` Gerd Hoffmann 2021-03-17 10:41 ` Thanos Makatos
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.