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

Re: [libvirt] [Engine-devel] Supporting native USB in oVirt


On 05/10/2012 01:39 PM, Oved Ourfalli wrote:
Rephrasing my question a bit, to make it more clear.
We are now working on adding the support for native USB devices on oVirt.

This requires adding composite PCI devices to a VM (details below), requiring specific set of restrictions on the addresses of these devices, and the connections between them.
Is it possible to add such a composite set of devices to a VM while using automatic address assignment, as we do today on the other PCI devices?

To be clear, what the ovirt-engine people want to do (AFAIK), is add an EHCI controller
with UHCI companion controllers to a vm, which would normally be done in the xml file
like this:

    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x7'/>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x1'/>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x2'/>

Without manually specifying the addresses, ie they want to be able to write
something like:

    <controller type='usb' index='0' model='ich9-ehci1'>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>

Which currently does not work, and even if it would work
libvirt does not seem to know that all devices here should
share one pci slot using different functions of that slot
(and the EHCI controller must have the highest function)

I can imagine a syntax like this:

    <controller type='usb' index='0' model='ich9-ehci1'>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master id='usb' startport='0'/>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master id='usb' startport='2'/>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master id='usb' startport='4'/>

Where the id='usb' tells libvirt which master usb controller
the companions belong to, and that libvirt would then
automatically assign them all the same pci-slot, with different
function number, ensuring the EHCI device gets the highest
function nr.



More details below...

Thank you,

----- Original Message -----
From: "Hans de Goede"<hdegoede redhat com>
To: "Oved Ourfalli"<ovedo redhat com>
Cc: "engine-devel"<engine-devel ovirt org>, libvirt-list redhat com
Sent: Thursday, May 10, 2012 11:32:15 AM
Subject: Re: [Engine-devel] [libvirt]Supporting native USB in oVirt

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" ?



On 05/09/2012 03:46 PM, Oved Ourfalli wrote:

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,

----- Forwarded Message -----
From: "Itamar Heim"<iheim redhat com>
To: "Michal Privoznik"<mprivozn redhat com>
Cc: "Oved Ourfalli"<ovedo redhat com>, "Dave
Allan"<dallan redhat com>, "Jiri Denemark"<jdenemar redhat com>,
"Igor Lvovsky"<ilvovsky redhat com>, "Eli
Mesika"<emesika redhat com>, "Hans de Goede"<hdegoede redhat com>,
"Dan Kenigsberg"<danken redhat com>, "Andrew
Cathrow"<acathrow redhat com>
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:

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.


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.


3. USB redirect devices (according to the needed number of USB
slots, maximum 6) on the same bus, each one having a different


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

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 redhat com).
developers are there so if there's anything libvirt can do, we
agree on concept there.

libvir-list mailing list
libvir-list redhat com
Engine-devel mailing list
Engine-devel ovirt org

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