> Subject: RE: [PATCH v2 0/8] hw/usb: Add a usbredir server transport
> 
> Hi Marc-André Lureau
> 
> > Subject: Re: [PATCH v2 0/8] hw/usb: Add a usbredir server transport
> >
> > Hi
> >
> > > This series adds a usbredir server transport to redirect a USB
> > > device emulated in one QEMU instance to a USB host controller
> > > emulated in another one over the usbredir protocol.
> > >
> > > The v1 series included both the usbredir server transport and the
> > > ASPEED
> > > AST1030 USB Device Controller (UDC) support. Following review
> > > feedback, this series contains only the usbredir server transport.
> > > The ASPEED
> > > AST1030 UDC support will be sent separately.
> > >
> > > This work is part of a larger plan to model USB device-side support
> > > on ASPEED BMC/BIC SoCs, which has three goals:
> > >
> > > 1. Model the ASPEED UDC (AST2600 / AST1030). The AST2600 also has
> > > USB
> > host
> > >    (EHCI) controllers, so that work targets the AST2600 UDC: its gadget
> can
> > >    be attached to the SoC's own EHCI bus, letting the guest enumerate its
> > >    own gadget and exercise the UDC end-to-end.  [Done]
> > >
> > > https://lore.kernel.org/qemu-devel/20260902021542.3194812-1-jamin_li
> > > n@
> > > aspeedtech.com/
> > >
> > > 2. AST1030 UDC. The AST1030 has no USB host controller, so testing its
> UDC
> > >    needs a second QEMU instance. The UDC gadget is redirected out of
> the
> > >    guest with libusbredir and attached to another QEMU that runs a
> > > USB
> > host
> > >    (a VMM, or an AST2600 / AST2700 guest).  [this series]
> > >
> > > 3. ASPEED vHub, as a longer-term goal towards BMC KVM / Virtual Media
> > >    support in QEMU.  [future]
> > >
> > > This series implements goal 2.
> > >
> > > The transport
> > > =============
> > >
> > > usb-redir-server exports a locally emulated USB device to a remote
> > > USB host over the usbredir protocol, so a device emulated in one
> > > QEMU instance can be enumerated by a host controller emulated in
> another one.
> > >
> > > The left column is a request going to the device. The right column
> > > is the answer coming back. The middle hop carries usbredir messages
> > > over a socket. The top and bottom hops carry USBPackets inside QEMU.
> > >
> > >     remote QEMU: guest driver -> EHCI/XHCI
> > >              |                     ^
> > >    USBPacket |                     | USBPacket
> > >              v                     |
> > >     "usb-redir" (the client)
> > >              |                     ^
> > >     usbredir |   chardev socket    | usbredir
> > >              v                     |
> > >     usb-redir-server (the server, this series)
> > >              |                     ^
> > >    USBPacket |                     | USBPacket
> > >              v                     |
> > >     any USBDevice, "-device <dev>,bus=<id>.0"
> > >
> > > "usb-redir" (hw/usb/redirect.c) is the client:
> > >   - it takes a USBPacket from the remote guest and writes it to the socket
> > >     as a usbredir message
> > >   - it reads the answer from the socket and completes the USBPacket
> > >
> > > usb-redir-server is the server. It does the same thing, but backwards:
> > >   - it reads a usbredir message from the socket and runs it as a USBPacket
> > >     on the bus below
> > >   - it takes the result of that USBPacket and writes it back to the same
> > >     socket as a usbredir message, for the client to read
> > >
> > > A USB device has to sit on a USB bus, and in QEMU a USB bus is
> > > always made by a host controller. So usb-redir-server makes one and
> > > acts as the host
> >
> > That's a bit awkward, but makes sense. However I am not sure it sure
> > it should also require a machine and sit on the sysbus. We may also
> > want to build a specialized binary that doesn't cary any of the
> > machine code etc and is target-free. something like "qemu-usb", not
> > necessarily with this series though
> >
> 
> I do not know yet how a "qemu-usb" binary would work, so v3 keeps the sysbus
> design. I also did not find any other way to fix "Bus not found"
> for "-device <dev>,bus=<id>.0". The lookup starts at the sysbus, so a device
> that does not sit there cannot offer a bus.
> 
Sorry to come back to this. I looked at the qemu-usb idea again, and
there is one more thing worth mentioning.

There are two kinds of USB device here.

1. A self-contained device, like usb-storage or usb-kbd, is emulated by
QEMU on its own. It needs no CPU and no machine, so a target-free binary
would host it well.

2. A SoC-backed device is different. Its behavior comes from the guest
firmware driving a UDC through MMIO, interrupts and DMA, so it needs a
CPU, a machine and guest memory. The ASPEED UDC gadget is one of these, and
it is what this series is for: 
https://patchwork.kernel.org/project/qemu-devel/cover/20261005064418.3060881-1-jamin_lin@aspeedtech.com/


      QEMU #1  -M ast1030-evb              QEMU #2  -M ast2700a2-evb
  +-----------------------------+      +-----------------------------+
  | Zephyr   usb_dc_aspeed      |      | Linux    ehci-platform      |
  +--------------+--------------+      +--------------+--------------+
                 | MMIO, IRQ, DMA                     | MMIO
  +--------------v--------------+      +--------------v--------------+
  | aspeed.udc                  |      | EHCI3        (usb-bus.3)    |
  +--------------+--------------+      +--------------+--------------+
                 | UDC registers, IRQ, DMA            | USBPacket
  +--------------v--------------+      +--------------v--------------+
  | aspeed.udc-gadget           |      | usb-redir                   |
  +--------------+--------------+      +--------------+--------------+
                 | USBPacket                          |
  +--------------v--------------+                     |
  | x-usb-redir-server          |                     |
  +--------------+--------------+                     |
                 |                                    |
                 +=========== unix socket ============+
                           usbredir protocol

A target-free binary would help the first kind. It would not help the
second, which is why this device still needs a machine.

Jamin

> Because of that I will mark the device experimental and rename the type to
> "x-usb-redir-server". The file name stays redirect-server.c, like the other x-
> types in the tree.
> 
> If you have a better idea, I am happy to try it.
> 
> > Patch 4 already works around firmware initialization.. I don't whether
> > this is acceptable.. Perhaps we can accept it for now, but I'd mark
> > the device "experimental" at this point.
> >
> 
> 
> That part is solved in v3, see my reply to patch 4
> 
> Thanks,
> Jamin
> 
> > > controller on this side. It models no real chip: its cable is the
> > > chardev socket. The real host is in the other QEMU.
> > >
> > > usbredir carries one device, not a bus. A hub cannot be exported:
> > > the protocol has no device address field. To export several devices,
> > > run one usb-redir-server per device, each with its own chardev.
> > >
> > > Testing
> > > =======
> > > A plain usb-storage device was used to test the transport. The
> > > storage device is attached to usb-redir-server and exported over a Unix
> socket:
> > >
> > > $ qemu-system-aarch64 ...
> > > -chardev
> > > socket,id=usbredir0,path=/tmp/usbredir0.sock,server=on,wait=off
> > > -device usb-redir-server,id=usbredir0,chardev=usbredir0
> > > -drive id=usbdisk,if=none,file=image0.ext4,format=raw
> > > -device usb-storage,bus=usbredir0.0,id=mystorage,drive=usbdisk
> > >
> > > The exported device can then be attached to EHCI bus 3 of an AST2700
> > > guest using the existing usb-redir client:
> > >
> > >     -chardev
> > socket,id=storage,path=/tmp/usbredir0.sock,reconnect-ms=1000 \
> > >     -device usb-redir,chardev=storage,bus=usb-bus.3
> > >
> > > The AST2700 Linux guest enumerates the redirected USB storage device:
> > >
> > > root@ast2700-default:~# lsusb
> > > unable to initialize usb spec
> > > Bus 001 Device 001: ID 1d6b:0001 Linux
> > > 6.18.36-v00.08.03-gaf2f426c5786 uhci_hcd Generic UHCI Host
> > > Controller Bus 002 Device 001: ID 1d6b:0002 Linux
> > > 6.18.36-v00.08.03-gaf2f426c5786 ehci_hcd EHCI Host Controller Bus
> > > 002 Device 002: ID 46f4:0001 QEMU QEMU USB HARDDRIVE
> > >
> > > This also demonstrates that usb-redir-server is not specific to the
> > > ASPEED UDC. Any USBDevice can be attached to its USB bus and
> > > exported to a host controller in another QEMU instance.
> >
> > something I have long wished for, pretty nice
> >
> > --
> > Marc-André Lureau <marcandre.lureau@redhat.com>