[libvirt] [PATCHv2 04/12] pci: new iommu_group functions

[Laine Stump]

On 06/25/2013 06:34 AM, Daniel P. Berrange wrote:
> On Mon, Jun 24, 2013 at 11:05:30PM -0400, Laine Stump wrote:
>> Any device which belongs to an "IOMMU group" (used by vfio) will
>> have links to all devices of its group listed in
>> /sys/bus/pci/$device/iommu_group/devices;
>> /sys/bus/pci/$device/iommu_group is actually a link to
>> /sys/kernel/iommu_groups/$n, where $n is the group number (there
>> will be a corresponding device node at /dev/vfio/$n once the
>> devices are bound to the vfio-pci driver)
>>
>> The following functions are added:
> Naming convention is normally <object><action>, which I would
> interpret here as 'virPCIDeviceIOMMUGroup' as the object,
> since you're passing a 'virPCIDevice' or 'virPCIDeviceAddress'
> type as parameter.
>
>
>> virPCIDeviceGetIOMMUGroupList
>>
>>   Gets a virPCIDeviceList with one virPCIDeviceList for each device
>>   in the same IOMMU group as the provided virPCIDevice (a copy of the
>>   original device object is included in the list.
> ack to this name
>
>> virPCIIOMMUGroupIterate
>>
>>   Calls the function @actor once for each device in the group that
>>   contains the given virPCIDeviceAddress.
> virPCIDeviceIOMMUGroupIterate

Well, actually it would be virPCIDeviceAddressIOMMUGroupIterate, which
is really quite a mouthful (and leads to very long lines). Due to the
extreme length, and based on seeing some other function that had just a
"virPCI" prefix, I chose the shorter name (although I secretly wondered
if you would raise an objection).

I definitely see the advantage of consistent naming, even if it's not
(yet) done consistently across all functions, so I'll change these names.


>
>> virPCIGetIOMMUGroupAddresses
>>
>>   Fills in a virPCIDeviceAddressPtr * with an array of
>>   virPCIDeviceAddress, one for each device in the iommu group of the
>>   provided virPCIDeviceAddress (including a copy of the original).
> virPCIDeviceGetIOMMUGroupAddresses


virPCIDeviceAddressGetIOMMUGroupAddresses


>
>> virPCIGetIOMMUGroupNum
>>
>>   Returns the group number as an int (a valid group number will always
>>   be 0 or greater).  If there is no iommu_group link in the device's
>>   directory (usually indicating that vfio isn't loaded), -2 will be
>>   returned. On any real error, -1 will be returned.
> virPCIDeviceGetIOMMUGroupNum

virPCIDeviceAddressGetIOMMUGroupNum

Going through all this, I've noticed that we *still* have multiple "pci
address" objects. For example virDevicePCIAddress (defined in /conf,
includes a "multifunction" attribute) and virPCIDeviceAddress (defined
in /util, no "multifunction"), and that many larger objects that include
a PCI address just define the individual attributes instead of using one
of the predefined objects. This leads to code that constructs one flavor
of PCI address/device from another just to call a function that requires
the other flavor. That *really* needs cleaning up...