On Thu, Aug 18, 2011 at 05:18:46PM +0200, Marc-André Lureau wrote: I'm not actively doing any work on it, merely experimenting with QEMU to understand how everything fits together. There are some key observations I have - A guest can have multiple USB controllers, either USB1 or USB2. The USB1 controller may be a function on the PIIX, or it may be a dedicate card - Since the companion controllers have associated PCI addresses, we must represent them explicitly in the XML, so it is clear to apps what PCI slots/functions are used. - Historically QEMU would auto-create hubs. For migration stability we must not let it do this. We must create any neccessary hubs ourself. - QEMU does not currently have any USB2 hub, and when it does, it will likely be USB2 only, no USB1 support. This makes hubs less desirable than multiple controllers, since you'd need to choose between USB1 or USB2 when creating the hub, while a controller can dynamically switch between USB1 & 2 thanks to the companion controllers. - Since there can be multiple controllers, we need a way specify physical addressing for USB devices, to ensure stablility across migration and hotplug/unplug. This needs to include the controller index, and the port number. The control index needs to span across USB1 and USB2 controllers. What all this means.... 1. Add a new controller type 'usb' <controller type='usb' index='0' /> 2. Add a 'model' for the usb controller type, allowing things like piix3-uhci, uhci, ich9-ehci, etc. If none is specified, then we need to auto-fill the basic default (piix3-uchi). <controller type='usb' index='0' model='ich9-ehci'/> 3. A USB controller will have a PCI address child element. <controller type='usb' index='0' model='ich9-ehci'> <address type='pci' domain='0' bus='0' slot='4' function='7'/> </controller> 4. All USB devices will gain a new USB address child element. <input type='tablet' bus='usb'> <address type='usb' bus='0' port='4'/> </input> 5. USB companion controllers use type='usb' too, but with an extra 'master' attribute to associate them <controller type='usb' index='0' model='ich9-ehci'> <address type='pci' domain='0' bus='0' slot='4' function='7'/> </controller> <controller type='usb' index='0' model='ich9-ehci1'> <master startport='0'/> <address type='pci' domain='0' bus='0' slot='4' function='1'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0' bus='0' slot='4' function='2'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0' bus='0' slot='4' function='2'/> </controller> 6. A USB hub should appear as a normal device <hub type='usb'> <address type='usb' bus='0' port='1'/> </hub> 7. A USB device address port should include the hub path eg. Plug a hub into port 1 of the first USB bus <hub type='usb'> <address type='usb' bus='0' port='1'/> </hub> then put a device and another hub into that hub: <input type='mouse' type='usb'> <address type='usb' bus='0' port='1.1'/> </hub> <hub type='usb'> <address type='usb' bus='0' port='1.2'/> </hub> Finally add 2 more devices into the second hub <input type='mouse' type='usb'> <address type='usb' bus='0' port='1.2.1'/> </hub> <input type='mouse' type='usb'> <address type='usb' bus='0' port='1.2.2'/> </hub> 7. If no USB controller is in the XML, we need to prefill the default PIIX3 controller 8. If no USB addresses are specified, we should autoassign addrs starting against the first controller. A complex example. We create the default USB1 controllers, and two USB2 controllers. We put a USB tablet on the USB1 controller, and then create a USB smartcards on one of the USB2 controllers, and assign two host devices to the other USB2 controller: <controller type='usb' index='0' model='piix3-uhci'> <address type='pci' domain='0' bus='0' slot='1' function='3'/> </controller> <controller type='usb' index='1' model='ich9-ehci'> <address type='pci' domain='0' bus='0' slot='4' function='7'/> </controller> <controller type='usb' index='0' model='ich9-ehci1'> <master startport='0'/> <address type='pci' domain='0' bus='0' slot='4' function='1'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0' bus='0' slot='4' function='2'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0' bus='0' slot='4' function='3'/> </controller> <controller type='usb' index='2' model='ich9-ehci'> <address type='pci' domain='0' bus='0' slot='5' function='7'/> </controller> <controller type='usb' index='2' model='ich9-ehci1'> <master startport='0'/> <address type='pci' domain='0' bus='0' slot='5' function='1'/> </controller> <controller type='usb' index='2' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0' bus='0' slot='5' function='2'/> </controller> <controller type='usb' index='2' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0' bus='0' slot='5' function='3'/> </controller> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='4'/> </input> <smartcard> <address type='usb' bus='1' port='1'/> </input> <hostdev mode=subsys type=usb> <source> <address bus='14' device='6'/> </source> <address type='usb' bus='2' port='1'/> </input> <hostdev mode=subsys type=usb> <source> <address bus='14' device='6'/> </source> <address type='usb' bus='2' port='2'/> </input> Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

Hi, On 08/19/2011 06:13 AM, Marc-André Lureau wrote: No, this is why the companion controllers have the masterbus option. Each port on the ehci has a mux (in the real hardware which we emulate), it looks something like this: physical port | mux /\ / \ / \ ehci companion port And the uhci companion controller plugs into 2 of the companion ports, starting at the startport number, the ehci has 6 ports like the above diagram, hence 3 companions, to cover the 6 companion ports. These 6 ports together form a bus, ie the ehci.0 bus. So adding companion controllers does not add more physical busses (they will show up as logical busses in the guest, but that is of little concern to qemu). The bus sitation does not really change with / without companion controllers as soon as you've an ehci, you get a bus belonging to it with 6 ports. The companion controllers just add usb 1 compatiblity to the otherwise usb 2 only ports, so that you can plug in any usb device without needing to think about the speed of it (qemu has port_speed / device_speed masks for usb ports resp devices, and refuses to connect (*) a device if there is no overlap). *) This means in practice that if you do things wrong, like create an ehci without companions and plug in a usb-tablet, the usb-tablet will be there in qemu's device tree, but it will be in disconnected state. IOW it is lying next to the computer with its plug not inserted into the computer. Regards, Hans

于 2011年08月18日 23:18, Marc-André Lureau 写道: I started to do the work, but then quited to do other work. And I just started to do the work again from yesterday.

Hi Osier, On Fri, Aug 19, 2011 at 8:31 AM, Osier Yang <jyang(a)redhat.com&gt; wrote: I am now more or less at 5 in Daniel plan. Did you go further? 22 files changed, 512 insertions(+), 23 deletions(-) -- Marc-André Lureau