On Wed, Dec 15, 2010 at 01:15:58PM +0100, Hans de Goede wrote: > Hi, > > Thanks for taking the time to read all that! > > On 12/13/2010 12:21 PM, Gerd Hoffmann wrote: > >>Basic packet structure / communication > >>-------------------------------------- > >> > >>Each packet exchanged between the vm-host and the usb-host starts > >>with a usb_redir_header, followed by an optional command specific > >>header follow by optional additional data. > >> > >>The usb_redir_header each packet starts with looks as follows: > >> > >>struct usb_redir_header { uint32_t command; uint32_t length; } > > > >uint32_t id; ? A reply would then carry the id of the request ... > > > > That sounds like a good idea (all though for iso streams the packets > will be only send in one direction). > > >>Given that everything is done over a potentially slow transport in > >>practice the diferentiating between synchroneous and asynchroneous > >>commands may seem odd. The difference is how the usb-host will handle > >>them once received. For synchroneous commands the usb-host will hand > >>the request over to the host os and then *wait* for a response. This > >>means that the vm-host is guaranteed to get an "immediate" response. > >>Where as for asynchroneous commands to usb-host hands the request > >>over to the host os with the request to let the usb-host process know > >>when the request is done. > > > >Hmm. Looks like you are planning for one tcp stream and one thread (on the > >usb-host side) for each usb device. That will not work very good for > >usb-over-vnc because there is a single tcp stream only. We could of course > >multiplex multiple logical usb connections over vnc, but even then blocking > >on the usb-host side looks bad as this could disrupt other usb devices > >forwarded over the same connection. > > The idea is for this protocol to be transport independent (*) so it > could be one stream, or it could be multiplexed into another transport. > > Assuring that there are not too large latencies, and handling things > like not blocking for too long when handling multiple devices from the > same thread are left to the implementation. > > It could be that the implementation decides to not handle synchroneous > commands synchroneous at all. The main difference I'm trying to make > here is between commands which do things to end points which cannot > be done while other packets are in flight (like setting configuration, > or interface alt setting) and commands (normal packets) of which there > can be multiple in flight. I'm open to using a different term then > synchroneous and async here. > > *) Assuming a reliable, ordered transport > > > > >>usb_redir_report_descriptor --------------------------- > >> > >>usb_redir_header.command: usb_redir_report_desciptor > >>usb_redir_header.length: <sizeof usb device descriptors> > >> > >>No command specific header. > >> > >>The command specific additional data contains the entire descriptors > >>for the usb device. > >> > >>A packet of this type is send by the usb-host directly after the > >>hello packet it contains the usb descriptor tables for the usb > >>device. > > > >Device addressing isn't done at all in the protocol, i.e. there is a fixed > >device <-> connection relation ship? > > > > The idea is there is a fixed device <-> transport pipe relation ship, yes. > For the simple tcp server usb-host I plan to implement as first usb-host, > the device would be specified on the cmdline while starting the server. > > When one wants to use multiple devices, this means starting one usb-server > per device. > > For things like vnc and spice I assume there will be some sort of control > channel where usb device management is done. To be more precise I expect > the vnc client / spice client to have some UI which allows selecting a usb > device to plug into the virtual machine. And then the client will setup a > transport for this (reserve a channel within its existing stream) and tell > the server that it has an usb device at sub channel id #, at which point > the server will add a new usb redir device to qemu, passing in a transport > "object" which is connected to this channel. > > >>Please let me know what you think of this. > > > >Do you know whenever certain low-level usb ops can work with this? > > > > I expect most usb devices to work with this, I don't know about > really weird ones. > > >Specifically iphone firmware flashing was mentioned on the list. > > > > I think that should work, but that is an interesting case about which > I don't know enough yet. > > >Also I remember somewhere in the ehci (or xhci?) specs was mentioned > > with some devices it can be needed to talk to them *before* an bus address > > is assigned ... > > If some devices need this, and the setup done there cannot be done > by the client machines os, we loose, as device enumeration and address > assignment is done at the OS level, and at least under Linux we won't > get a chance to talk to the device till after it has been assigned an > address. >
I know of devices that will enumerate twice, first as one device, then after a certain setup exchange as another. But that seems to be covered by the suggestion here, it will just be identicle to two completely different transports. > Regards, > > Hans >