- 28 1月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
The name is confusing, and there are just two uses: one is a test case, and the other will be removed as part of an upcoming refactoring of the hostdev code.
-
- 05 1月, 2016 1 次提交
-
-
由 Laine Stump 提交于
Due to debug logs like this: virPCIGetDeviceAddressFromSysfsLink:2432 : Attempting to resolve device path from device link '/sys/class/net/eth1/device/virtfn6' logStrToLong_ui:2369 : Converted '0000:07:00.7' to unsigned int 0 logStrToLong_ui:2369 : Converted '07:00.7' to unsigned int 7 logStrToLong_ui:2369 : Converted '00.7' to unsigned int 0 logStrToLong_ui:2369 : Converted '7' to unsigned int 7 virPCIGetDeviceAddressFromSysfs:1947 : virPCIDeviceAddress 0000:07:00.7 virPCIGetVirtualFunctions:2554 : Found virtual function 7 printed *once for each SR-IOV Virtual Function* of a Physical Function each time libvirt retrieved the list of VFs (so if the system has 128 VFs, there would be 900 lines of log for each call), the debug logs on any system with a large number of VFs was dominated by "information" that was possibly useful for debugging when the code was being written, but is now useless for debugging of any problem on a running system, and only serves to obscure the real useful information. This overkill has no place in production code, so this patch removes it.
-
- 21 12月, 2015 2 次提交
-
-
由 Andrea Bolognani 提交于
This replaces the virPCIKnownStubs string array that was used internally for stub driver validation. Advantages: * possible values are well-defined * typos in driver names will be detected at compile time * avoids having several copies of the same string around * no error checking required when setting / getting value The names used mirror those in the virDomainHostdevSubsysPCIBackendType enumeration.
-
由 Andrea Bolognani 提交于
The value is not inspected inside the function, so it makes more sense for the caller to change the device's setting explicitly.
-
- 15 12月, 2015 1 次提交
-
-
由 Andrea Bolognani 提交于
The name 'dev' is more appropriate for virPCIDevicePtr.
-
- 25 11月, 2015 1 次提交
-
-
由 Laine Stump 提交于
A PCI device may have the capability to setup virtual functions (VFs) but have them currently all disabled. Prior to this patch, if that was the case the the node device XML for the device wouldn't report any virtual_functions capability. With this patch, if a file called "sriov_totalvfs" is found in the device's sysfs directory, its contents will be interpreted as a decimal number, and that value will be reported as "maxCount" in a capability element of the device's XML, e.g.: <capability type='virtual_functions' maxCount='7'/> This will be reported regardless of whether or not any VFs are currently enabled for the device. NB: sriov_numvfs (the number of VFs currently active) is also available in sysfs, but that value is implied by the number of items in the list that is inside the capability element, so there is no reason to explicitly provide it as an attribute. sriov_totalvfs and sriov_numvfs are available in kernels at least as far back as the 2.6.32 that is in RHEL6.7, but in the case that they simply aren't there, libvirt will behave as it did prior to this patch - no maxCount will be displayed, and the virtual_functions capability will be absent from the device's XML when 0 VFs are enabled.
-
- 15 1月, 2015 1 次提交
-
-
由 Shivaprasad G Bhat 提交于
Basically a getter function which is implemented for accessing the address fields in virPCIDevice. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 29 7月, 2014 2 次提交
-
-
由 Eric Blake 提交于
Leak introduced in commit 16ebf10f (v1.2.6), detected by valgrind: ==9816== 216 (96 direct, 120 indirect) bytes in 6 blocks are definitely lost in loss record 665 of 821 ==9816== at 0x4A081D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==9816== by 0x50836FB: virAlloc (viralloc.c:144) ==9816== by 0x1DBDBE27: udevProcessPCI (node_device_udev.c:546) ==9816== by 0x1DBDD79D: udevGetDeviceDetails (node_device_udev.c:1293) * src/util/virpci.h (virPCIEDeviceInfoFree): New prototype. * src/util/virpci.c (virPCIEDeviceInfoFree): New function. * src/conf/node_device_conf.c (virNodeDevCapsDefFree): Clear pci_express under pci case. (virNodeDevCapPCIDevParseXML): Avoid leak. * src/node_device/node_device_udev.c (udevProcessPCI): Likewise. * src/libvirt_private.syms (virpci.h): Export it. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Finding virPCIE* code is more intuitive if located in virpci.h instead of node_device_conf.h. * src/conf/node_device_conf.h (virPCIELinkSpeed, virPCIELink) (virPCIEDeviceInfo): Move... * src/util/virpci.h: ...here. * src/conf/node_device_conf.c (virPCIELinkSpeed): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 16 6月, 2014 1 次提交
-
-
由 Michal Privoznik 提交于
These functions will handle PCIe devices and their link capabilities to query some info about it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 04 3月, 2014 1 次提交
-
-
由 Chunyan Liu 提交于
Specify which driver and which domain in used_by area to avoid conflict among different drivers. Signed-off-by: NChunyan Liu <cyliu@suse.com>
-
- 07 2月, 2014 1 次提交
-
-
由 John Ferlan 提交于
Coverity complains about "USE_AFTER_FREE" due to how virPCIDeviceSetStubDriver "could" return either -1, 0, or 1 from the VIR_STRDUP() and then possibly makes a call to virPCIDeviceDetach(). The only way this could happen is if NULL were passed as the "driver" name and virStrdup() returned 0. Since the calling functions check < 0 on the initial function call, the 0 possibility causes Coverity to complain. To fix this - enforce that the second parameter is not NULL using ATTRIBUTE_NONNULL(2) for the function prototype, then in virPCIDeviceDetach add an sa_assert(dev->stubDriver). This will result in Coverity not complaining any more.
-
- 20 1月, 2014 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 08 1月, 2014 1 次提交
-
-
由 Osier Yang 提交于
Like commit 94a26c7e from Eric Blake, the old fuzzy code should be replaced by the new array management macros now. And the type of scsi->count should be changed into "size_t", and thus virSCSIDeviceListCount should return size_t instead, similar for vir{PCI,USB}DeviceListCount.
-
- 08 11月, 2013 1 次提交
-
-
由 Laine Stump 提交于
This is a prerequisite to the fix for the fix to: https://bugzilla.redhat.com/show_bug.cgi?id=1025397 num_virtual_functions needs to be size_t in order to use the VIR_APPEND_ELEMENT macro.
-
- 27 6月, 2013 1 次提交
-
-
由 Laine Stump 提交于
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: 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. virPCIDeviceAddressIOMMUGroupIterate Calls the function @actor once for each device in the group that contains the given virPCIDeviceAddress. virPCIDeviceAddressGetIOMMUGroupAddresses 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). virPCIDeviceAddressGetIOMMUGroupNum 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.
-
- 26 6月, 2013 4 次提交
-
-
由 Laine Stump 提交于
Make a copy of the device and add the copy to the list. (virPCIDeviceListAdd() adds the original object to the list instead).
-
由 Laine Stump 提交于
This function has utility outside of virpci.c, so make it public. Also the name didn't fit convention, so change it to virPCIDeviceAddressParse.
-
由 Laine Stump 提交于
I realized after the fact that it's probably better in the long run to give this function a name that matches the name of the link used in sysfs to hold the group (iommu_group). I'm changing it now because I'm about to add several more functions that deal with iommu groups.
-
由 Laine Stump 提交于
The driver arg to virPCIDeviceDetach is no longer used (the name of the stub driver is now set in the virPCIDevice object, and virPCIDeviceDetach retrieves it from there). Remove it.
-
- 25 6月, 2013 2 次提交
-
-
由 Laine Stump 提交于
* virPCIDeviceFindByIDs - find a device on a list w/o creating an object This makes searching for an existing device on a list lighter weight. * virPCIDeviceCopy - make a copy of an existing virPCIDevice object. * virPCIDeviceGetDriverPathAndName - construct new strings containing 1) the name of the driver bound to this device. 2) the full path to the sysfs config for that driver. (This code was lifted from virPCIDeviceUnbindFromStub, and replaced there with a call to this new function).
-
由 Laine Stump 提交于
Previously stubDriver was always set from a string literal, so it was okay to use a const char * that wasn't freed when the virPCIDevice was freed. This will not be the case in the near future, so it is now a char* that is allocated in virPCIDeviceSetStubDriver() and freed during virPCIDeviceFree().
-
- 02 5月, 2013 1 次提交
-
-
由 Laine Stump 提交于
virPCIDeviceReattach and virPCIDeviceUnbindFromStub (called by virPCIDeviceReattach) had previously required the name of the stub driver as input. This is unnecessary, because the name of the driver the device is currently bound to can be found by looking at the link: /sys/bus/pci/dddd:bb:ss.ff/driver Instead of requiring that the name of the expected stub driver name and only unbinding if that one name is matched, we no longer take a driver name in the arglist for either of these functions. virPCIDeviceUnbindFromStub just compares the name of the currently bound driver to a list of "well known" stubs (right now contains "pci-stub" and "vfio-pci" for qemu, and "pciback" for xen), and only performs the unbind if it's one of those devices. This allows virsh nodedevice-reattach to work properly across a libvirtd restart, and fixes a couple of cases where we were erroneously still hard-coding "pci-stub" as the drive name. For some unknown reason, virPCIDeviceReattach had been calling modprobe on the stub driver prior to unbinding the device. This was problematic because we no longer know the name of the stub driver in that function. However, it is pointless to probe for the stub driver at that time anyway - because the device is bound to the stub driver, we are guaranteed that it is already loaded, and so that call to modprobe has been removed.
-
- 26 4月, 2013 2 次提交
-
-
由 Laine Stump 提交于
Given a virPCIDevice, this function returns the path for the device that controls the vfio group the device belongs to, e.g. "/dev/vfio/15".
-
由 Laine Stump 提交于
This can be set when the virPCIDevice is created and placed on a list, then used later when traversing the list to determine which stub driver to bind/unbind for managed devices. The existing Detach and Attach functions' signatures haven't been changed (they still accept a stub driver name in the arg list), but if the arg list has NULL for stub driver and one is available in the device's object, that will be used. (we may later deprecate and remove the arg from those functions).
-
- 15 4月, 2013 1 次提交
-
-
由 Osier Yang 提交于
Though they are the same thing, mixed use of them is uncomfortable. "unsigned" is used a lot in old codes, this just tries to change the ones in utils.
-
- 11 4月, 2013 2 次提交
-
-
由 Osier Yang 提交于
Members of struct virPCIDevice are changed together.
-
由 Osier Yang 提交于
-
- 06 2月, 2013 2 次提交
-
-
由 Daniel P. Berrange 提交于
To allow modifications to the lists to be synchronized, convert virPCIDeviceList and virUSBDeviceList into virObjectLockable classes. The locking, however, will not be self-contained. The users of these classes will have to call virObjectLock/Unlock in the critical regions. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Rename all the pciDeviceXXX and pciXXXDevice APIs to have a fixed virPCIDevice name prefix
-
- 11 1月, 2013 1 次提交
-
-
由 Chunyan Liu 提交于
Pass stub driver name directly to pciDettachDevice and pciReAttachDevice to fit for different libvirt drivers. For example, qemu driver prefers pci-stub, but Xen prefers pciback. Signed-off-by: NChunyan Liu <cyliu@suse.com>
-
- 21 12月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
-
- 05 12月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
In order to be able to steal PCI device by its index in the list.
-
- 21 9月, 2012 1 次提交
-
-
由 Eric Blake 提交于
https://www.gnu.org/licenses/gpl-howto.html recommends that the 'If not, see <url>.' phrase be a separate sentence. * tests/securityselinuxhelper.c: Remove doubled line. * tests/securityselinuxtest.c: Likewise. * globally: s/; If/. If/
-
- 23 7月, 2012 1 次提交
-
-
由 Osier Yang 提交于
Per the FSF address could be changed from time to time, and GNU recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html) You should have received a copy of the GNU General Public License along with Foobar. If not, see <http://www.gnu.org/licenses/>. This patch removes the explicit FSF address, and uses above instead (of course, with inserting 'Lesser' before 'General'). Except a bunch of files for security driver, all others are changed automatically, the copyright for securify files are not complete, that's why to do it manually: src/security/security_selinux.h src/security/security_driver.h src/security/security_selinux.c src/security/security_apparmor.h src/security/security_apparmor.c src/security/security_driver.c
-
- 06 3月, 2012 1 次提交
-
-
由 Roopa Prabhu 提交于
pciDeviceGetVirtualFunctionInfo returns pf netdevice name and virtual function index for a given vf. This is just a wrapper around existing functions to return vf's pf and vf_index with one api call pciConfigAddressToSysfsfile returns the sysfile pci device link from a 'struct pci_config_address' Signed-off-by: NRoopa Prabhu <roprabhu@cisco.com>
-
- 18 1月, 2012 1 次提交
-
-
由 Osier Yang 提交于
pciTrySecondaryBusReset checks if there is active device on the same bus, however, qemu driver doesn't maintain an effective list for the inactive devices, and it passes meaningless argument for parameter "inactiveDevs". e.g. (qemuPrepareHostdevPCIDevices) if (!(pcidevs = qemuGetPciHostDeviceList(hostdevs, nhostdevs))) return -1; ..skipped... if (pciResetDevice(dev, driver->activePciHostdevs, pcidevs) < 0) goto reattachdevs; NB, the "pcidevs" used above are extracted from domain def, and thus one won't be able to attach a device of which bus has other device even detached from host (nodedev-detach). To see more details of the problem: RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=773667 This patch is to resolve the problem by introducing an inactive PCI device list (just like qemu_driver->activePciHostdevs), and the whole logic is: * Add the device to inactive list during nodedev-dettach * Remove the device from inactive list during nodedev-reattach * Remove the device from inactive list during attach-device (for non-managed device) * Add the device to inactive list after detach-device, only if the device is not managed With the above, we have a sufficient inactive PCI device list, and thus we can use it for pciResetDevice. e.g.(qemuPrepareHostdevPCIDevices) if (pciResetDevice(dev, driver->activePciHostdevs, driver->inactivePciHostdevs) < 0) goto reattachdevs;
-
- 12 1月, 2012 2 次提交
-
-
由 Shradha Shah 提交于
This functions enables us to get the Virtual Functions attached to a Physical function given the name of a SR-IOV physical functio. In order to accomplish the task, added a getter function pciGetDeviceAddrString to get the BDF of the Virtual Function in a char array.
-
由 Shradha Shah 提交于
-
- 30 10月, 2011 1 次提交
-
-
由 Osier Yang 提交于
To support "managed" mode of host PCI device, we record the original states (unbind_from_stub, remove_slot, and reprobe) so that could reattach the device to host with original driver. But there is no XML for theses attrs, and thus after daemon is restarted, we lose the original states. It's easy to reproduce: 1) virsh start domain 2) virsh attach-device dom hostpci.xml (in 'managed' mode) 3) service libvirtd restart 4) virsh destroy domain You will see the device won't be bound to the original driver if there was one. This patch is to solve the problem by introducing internal XML (won't be dumped to user, only dumped to status XML). The XML is: <origstates> <unbind/> <remove_slot/> <reprobe/> </origstates> Which will be child node of <hostdev><source>...</souce></hostdev>. (only for PCI device). A new struct "virDomainHostdevOrigStates" is introduced for the XML, and the according members are updated when preparing the PCI device. And function "qemuUpdateActivePciHostdevs" is modified to honor the original states. Use of qemuGetPciHostDeviceList is removed in function "qemuUpdateActivePciHostdevs", and the "managed" value of the device config is honored by the change. This fixes another problem alongside: qemuGetPciHostDeviceList set the device as "managed" force regardless of whether the device is configured as "managed='yes'" or not in XML, which is not right.
-