All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: victortoso@redhat.com, berrange@redhat.com, kraxel@redhat.com,
	qemu-devel@nongnu.org
Subject: Re: Half a usb-redir idea
Date: Tue, 16 Mar 2021 18:44:41 +0000	[thread overview]
Message-ID: <YFD8mXa4P/fVIZd6@work-vm> (raw)
In-Reply-To: <630f4307-20ed-8834-4df9-ed90c22ee018@redhat.com>

* 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



  reply	other threads:[~2021-03-16 19:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YFD8mXa4P/fVIZd6@work-vm \
    --to=dgilbert@redhat.com \
    --cc=berrange@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=victortoso@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.