Hey,

We are now working on adding the support for native USB devices on oVirt, and 
we have some difficulties.
Please see the details/discussion below.

Thank you for your help,
Oved

----- Forwarded Message -----
From: "Itamar Heim" <[email protected]>
To: "Michal Privoznik" <[email protected]>
Cc: "Oved Ourfalli" <[email protected]>, "Dave Allan" <[email protected]>, "Jiri 
Denemark" <[email protected]>, "Igor Lvovsky" <[email protected]>, "Eli 
Mesika" <[email protected]>, "Hans de Goede" <[email protected]>, "Dan 
Kenigsberg" <[email protected]>, "Andrew Cathrow" <[email protected]>
Sent: Wednesday, May 9, 2012 1:18:40 PM
Subject: Re: Supporting native USB in oVirt

On 05/09/2012 01:12 PM, Michal Privoznik wrote:
> On 08.05.2012 09:19, Oved Ourfalli wrote:
>> Hi,
>>
>> We are now working on adding the support for native USB devices on oVirt.
>> As far as we understand, in order to use it we need to pass the following 
>> devices with the following restrictions (according to the EHCI spec):
>> 1. EHCI USB controller - with the highest function number, #7.
>>
>> devices='{type:controller,device:usb,model:ich9-ehci1,address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x7}}'
>>
>> 2. 3 UHCI USB controllers, on the same bus and PCI slot as the EHCI 
>> controller. Set the multifunction bit to on, on the controller with function 
>> #0.
>>
>> devices='{type:controller,device:usb,model:ich9-uhci1,master:{startport:0},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x0,multifunction:on}}'
>> devices='{type:controller,device:usb,model:ich9-uhci2,master:{startport:2},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x1}}'
>> devices='{type:controller,device:usb,model:ich9-uhci3,master:{startport:4},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x2}}'
>>
>> 3. USB redirect devices (according to the needed number of USB slots, 
>> maximum 6) on the same bus, each one having a different port.
>>
>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:1}}'
>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:2}}'
>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:3}}'
>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:4}}'
>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:5}}'
>> devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:6}}'
>>
>> 4. If we want more than 6 USB slots, we need to have 2 EHCI controllers, and 
>> 6 UHCI controllers, that are consistent with the restrictions above, on 
>> different bus.
>> (we need them to be on different bus, since the connection between the 
>> redirect devices and the controllers is the bus).
>>
>> According to Hans (cc-ed), if we let libvirt pick its own addresses, it will 
>> put each controller of the composite USB controller device on its own pci 
>> slot, which is a violation of the EHCI spec.
>
>>
>> The problem is that the oVirt engine is not aware of addresses. They aren't 
>> managed by it.
>> They are chosen automatically by libvirt, returned to the engine, and they 
>> saved in the engine database in order to provide the ability to retain the 
>> same PCI addresses after VM restart.
>>
>> So, in order to support the EHCI spec, oVirt will have to be aware of 
>> addresses, manage them (allocate them, check for collisions, update on every 
>> libvirt change regarding that, etc...). Obviously, it doesn't feel right, 
>> and in fact it is also not feasible, to manage these addresses in the oVirt 
>> domain.
>>
>> Is all the above correct, or are we missing something?
>> If so, can you address the issues above, and provide the ability to manage 
>> these devices in libvirt?
>
> Let's have this conversation upstream ([email protected]). Many
> developers are there so if there's anything libvirt can do, we should
> agree on concept there.

_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel

Reply via email to