[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] Auto-assignment of USB devices and auto-creation of USB hubs



Hello,

I've been helping a customer out this week with assigning specific devices to specific USB controllers inside his KVM VMs. He's got USB1 devices which need a UHCI controller (because of rubbishy Windows device drivers) and USB2 devices which need a EHCI controller ("speed mismatch" on a UHCI hub).

I've suggested config similar to this:

    <controller type='usb' index='0' model='ehci'>
    </controller>
    <controller type='usb' index='1' model='piix3-uhci'>
    </controller>

    <input type='tablet' bus='usb'/>

    <hub type='usb'>
      <address type='usb' bus='1' port='2'/>
    </hub>

    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0xAAAA'/>
        <product id='0xAAAA'/>
      </source>
      <address type='usb' bus='1' port='2.1'/>
    </hostdev>

    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0xBBBB'/>
        <product id='0xBBBB'/>
      </source>
      <address type='usb' bus='1' port='2.2'/>
    </hostdev>

and I explained the concept to him with diagrams like these:

 UHCI --+-- Tablet (port 1)
        +-- HUB (port 2) --.
                           +-- Device (port 2.1)
                           +-- Device (port 2.2)

 UHCI --+-- Tablet (port 1)
        +-- HUB (port 2) --.
                           +-- HUB (port 2.1) --.
                           |                    +-- Device (port 2.1.1)
                           |                    +-- Device (port 2.1.2)
                           |
                           +-- HUB (port 2.2) --.
                                                +-- Device (port 2.2.1)

(then imagine extending this example out to also include EHCI controller and devices)

He's very happy so far and I've just been working it all out through trial and error and reading the libvirt domain specification.

My observation is that you can either:

 a) let libvirt plug everything into the UHCI controller, regardless of what other controllers are there and what order they appear in
 or
 b) find out how many ports a controller/hub has through trial and error, manually create USB hubs, and map every single device and port out manually

with no middle ground in between.

I think it would be way better if users could just assign a USB hostdev to a controller, then let libvirt do all the heavy lifting in regards to hubs and ports.

For example, :

    <controller type='usb' index='0' model='ehci'>
    </controller>
    <controller type='usb' index='1' model='piix3-uhci'>
    </controller>

    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x0529'/>
        <product id='0x0001'/>
      </source>
      <address type='usb' bus='1'/>
    </hostdev>

    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x3923'/>
        <product id='0x709b'/>
      </source>
      <address type='usb' bus='1'/>
    </hostdev>

I can see it's already been discussed that we couldn't just implement "port=auto" because we need migration stability:

 http://www.redhat.com/archives/libvir-list/2011-August/msg00816.html

but much like how you add:

    <controller type='usb' index='0' model='ehci'>
    </controller>

then save the XML, and go "virsh edit" and the controller automagically has a PCI address assigned, we could enter this into the XML:

    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        whatever
      </source>
      <address type='usb' bus='1'/>
    </hostdev>

then save the XML, and "virsh edit" again, and all the port/hub stuff would already be there pre-made as required.

Any thoughts? Is this worth logging an RFE for?

Cheers,
Jamie


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]