Re: Supporting native USB in oVirt

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

 



Hi Oved,

I think it will help if you can re-formulate things into
a question for the libvirt developers. e.g. something along
the lines of: "is it possible to add composite PCI devices
to a vm while using automatic address assignment" ?

Regards,

Hans


On 05/09/2012 03:46 PM, Oved Ourfalli wrote:
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"<iheim@xxxxxxxxxx>
To: "Michal Privoznik"<mprivozn@xxxxxxxxxx>
Cc: "Oved Ourfalli"<ovedo@xxxxxxxxxx>, "Dave Allan"<dallan@xxxxxxxxxx>, "Jiri Denemark"<jdenemar@xxxxxxxxxx>, "Igor Lvovsky"<ilvovsky@xxxxxxxxxx>, "Eli Mesika"<emesika@xxxxxxxxxx>, "Hans de Goede"<hdegoede@xxxxxxxxxx>, "Dan Kenigsberg"<danken@xxxxxxxxxx>, "Andrew Cathrow"<acathrow@xxxxxxxxxx>
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 (libvirt-list@xxxxxxxxxx). Many
developers are there so if there's anything libvirt can do, we should
agree on concept there.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]