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_lin@ > > 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. 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 <[email protected]>
