Half a usb-redir idea

Half a usb-redir idea

[Dr. David Alan Gilbert]

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

Re: Half a usb-redir idea

[Philippe Mathieu-Daudé]

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?

Re: Half a usb-redir idea

[Dr. David Alan Gilbert]

* 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

Re: Half a usb-redir idea

[Marc-André Lureau]

[-- 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 --]

Re: Half a usb-redir idea

[Gerd Hoffmann]

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

Re: Half a usb-redir idea

[Gerd Hoffmann]

  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

Re: Half a usb-redir idea

[Dr. David Alan Gilbert]

* 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

Re: Half a usb-redir idea

[Gerd Hoffmann]

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

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
>