- 29 1月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
The affected functions are: virPCIDeviceGetManaged() virPCIDeviceGetUnbindFromStub() virPCIDeviceGetRemoveSlot() virPCIDeviceGetReprobe() Change their return type from unsigned int to bool: the corresponding members in struct _virPCIDevice are defined as bool, and even the corresponding virPCIDeviceSet*() functions take a bool value as input so there's no point in these functions having unsigned int as return type. Suggested-by: NJohn Ferlan <jferlan@redhat.com>
-
- 28 1月, 2016 2 次提交
-
-
由 Andrea Bolognani 提交于
Unbinding a PCI device from the stub driver can require several steps, and it can be useful for debugging to be able to trace which of these steps are performed and which are skipped for each device.
-
由 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.
-
- 08 1月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
Most of the changes to the list of active and inactive PCI devices happen in virHostdev, where they are properly logged. virPCIDeviceDetach() and virPCIDeviceReattach(), however, change the inactive list as well, so they should be logging similar messages.
-
- 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 3 次提交
-
-
由 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.
-
由 Andrea Bolognani 提交于
This internal function supports, in theory, binding to a different stub driver than the one the PCI device has been configured to use. In practice, it is only ever called like virPCIDeviceBindToStub(dev, dev->stubDriver); which makes its second parameter redundant. Get rid of it, along with the extra string copy required to support it.
-
- 16 12月, 2015 1 次提交
-
-
由 Andrea Bolognani 提交于
Instead of replicating the information (domain, bus, slot, function) inside the virPCIDevice structure, use the already-existing virPCIDeviceAddress structure. For users of the module, this means that the object returned by virPCIDeviceGetAddress() can no longer be NULL and must no longer be freed by the caller.
-
- 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.
-
- 02 7月, 2015 3 次提交
-
-
由 John Ferlan 提交于
Convert virPCIDriverDir to return the buffer allocated (or not) and make the appropriate check in the caller. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Convert virPCIDriverFile to return the buffer allocated (or not) and make the appropriate check in the caller. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Convert virPCIFile to return the buffer allocated (or not) and make the appropriate check in the caller. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 24 4月, 2015 1 次提交
-
-
由 Cédric Bosdonnat 提交于
For some devices, the $PCIDIR/vendor and $PCIDIR/device need to be read. Iterate over them to get them as well in the the generated apparmor profile.
-
- 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>
-
- 19 11月, 2014 1 次提交
-
-
由 Eric Blake 提交于
I noticed this while working on qemuDomainGetBlockInfo. Assigning a bool value to an int variable compiles fine, but raises red flags on the maintenance front as it becomes too easy to assign -1 or 2 or any other non-bool value to the same variable. * cfg.mk (sc_prohibit_int_assign_bool): New rule. * src/conf/snapshot_conf.c (virDomainSnapshotRedefinePrep): Fix offenders. * src/qemu/qemu_driver.c (qemuDomainGetBlockInfo) (qemuDomainSnapshotCreateXML): Likewise. * src/test/test_driver.c (testDomainSnapshotAlignDisks): Likewise. * src/util/vircgroup.c (virCgroupSupportsCpuBW): Likewise. * src/util/virpci.c (virPCIDeviceBindToStub): Likewise. * src/util/virutil.c (virIsCapableVport): Likewise. * tools/virsh-domain-monitor.c (cmdDomMemStat): Likewise. * tools/virsh-domain.c (cmdBlockResize, cmdScreenshot) (cmdInjectNMI, cmdSendKey, cmdSendProcessSignal) (cmdDetachInterface): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 15 11月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 05 9月, 2014 1 次提交
-
-
由 Eric Blake 提交于
I'm about to add a syntax check that enforces our documented HACKING style of always using matching {} on if-else statements. This patch focuses on all remaining problems, where there weren't enough issues to warrant splitting it further. * src/remote/remote_driver.c (doRemoteOpen): Correct use of {}. * src/security/virt-aa-helper.c (vah_add_path, valid_path, main): Likewise. * src/rpc/virnetsocket.c (virNetSocketNewConnectLibSSH2): Likewise. * src/esx/esx_vi_types.c (esxVI_Type_FromString): Likewise. * src/uml/uml_driver.c (umlDomainDetachDevice): Likewise. * src/util/viralloc.c (virShrinkN): Likewise. * src/util/virbuffer.c (virBufferURIEncodeString): Likewise. * src/util/virdbus.c (virDBusCall): Likewise. * src/util/virnetdev.c (virNetDevValidateConfig): Likewise. * src/util/virnetdevvportprofile.c (virNetDevVPortProfileGetNthParent): Likewise. * src/util/virpci.c (virPCIDeviceIterDevices) (virPCIDeviceWaitForCleanup) (virPCIDeviceIsBehindSwitchLackingACS): Likewise. * src/util/virsocketaddr.c (virSocketAddrGetNumNetmaskBits): Likewise. * src/util/viruri.c (virURIParseParams): Likewise. * daemon/stream.c (daemonStreamHandleAbort): Likewise. * tests/testutils.c (virtTestResult): Likewise. * tests/cputest.c (cpuTestBaseline): Likewise. * tools/virsh-domain.c (cmdDomPMSuspend): Likewise. * tools/virsh-host.c (cmdNodeSuspend): Likewise. * src/esx/esx_vi_generator.py (Type.generate_typefromstring): Tweak generated code. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 28 8月, 2014 1 次提交
-
-
由 Wang Rui 提交于
Coverity determined that 'conflict' would be leaked. Signed-off-by: NWang Rui <moon.wangrui@huawei.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>
-
- 29 4月, 2014 1 次提交
-
-
由 Eric Blake 提交于
In making the conversion to the new API, I fixed a couple bugs: virSCSIDeviceGetSgName would leak memory if a directory unexpectedly contained multiple entries; virNetDevTapGetRealDeviceName could report a spurious error from a stale errno inherited before starting the readdir search. The decision on whether to store the result of virDirRead into a variable is based on whether the end of the loop falls through to cleanup code automatically. In some cases, we have loops that are documented to return NULL on failure, and which raise an error on most failure paths but not in the case where the directory was unexpectedly empty; it may be worth a followup patch to explicitly report an error if readdir was successful but the directory was empty, so that a NULL return always has an error set. * src/util/vircgroup.c (virCgroupRemoveRecursively): Use new interface. (virCgroupKillRecursiveInternal, virCgroupSetOwner): Report readdir failures. * src/util/virfile.c (virFileLoopDeviceOpenSearch) (virFileNBDDeviceFindUnused, virFileDeleteTree): Use new interface. * src/util/virnetdevtap.c (virNetDevTapGetRealDeviceName): Properly check readdir errors. * src/util/virpci.c (virPCIDeviceIterDevices) (virPCIDeviceFileIterate, virPCIGetNetName): Report readdir failures. (virPCIDeviceAddressIOMMUGroupIterate): Use new interface. * src/util/virscsi.c (virSCSIDeviceGetSgName): Report readdir failures, and avoid memory leak. (virSCSIDeviceGetDevName): Report readdir failures. * src/util/virusb.c (virUSBDeviceSearch): Report readdir failures. * src/util/virutil.c (virGetFCHostNameByWWN) (virFindFCHostCapableVport): Report readdir failures. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 25 3月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
-
- 18 3月, 2014 1 次提交
-
-
由 Daniel P. Berrange 提交于
Any source file which calls the logging APIs now needs to have a VIR_LOG_INIT("source.name") declaration at the start of the file. This provides a static variable of the virLogSource type. Signed-off-by: NDaniel P. Berrange <berrange@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.
-
- 04 2月, 2014 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1045124 When loading modules, libvirt does not honor the modprobe blacklist. Use the new virKModLoad() API in order to attempt load with blacklist check. Use the new virKModIsBlacklisted() API to check if the failure to load was due to the blacklist Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 20 1月, 2014 3 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1046919 Since commit v0.9.0-47-g4e8969eb (released in 0.9.1) some failures during device detach were reported to callers of virPCIDeviceBindToStub as success. For example, even though a device seemed to be detached virsh # nodedev-detach pci_0000_07_05_0 --driver vfio Device pci_0000_07_05_0 detached one could find similar message in libvirt logs: Failed to bind PCI device '0000:07:05.0' to vfio-pci: No such device This patch fixes these paths and also avoids overwriting real errors with errors encountered during a cleanup phase.
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1046919 When a PCI device is not bound to any driver, reattach should just trigger driver probe rather than failing with Invalid device 0000:00:19.0 driver file /sys/bus/pci/devices/0000:00:19.0/driver is not a symlink While virPCIDeviceGetDriverPathAndName was documented to return success and NULL driver and path when a device is not attached to any driver but didn't do so. Thus callers could not distinguish unbound devices from failures. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 08 1月, 2014 2 次提交
-
-
由 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.
-
When determining if a device is behind a PCI bridge, the PCI device class is checked by reading the config space. However, there are some devices which have the wrong class on the config space, but the class is initialized by Linux correctly as a PCI BRIDGE. This class can be read by the sysfs file '/sys/bus/pci/devices/xxxx:xx:xx.x/class'. One example of such bridge is IBM PCI Bridge 1014:03b9, which is identified as a Host Bridge when reading the config space. Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
-
- 21 11月, 2013 1 次提交
-
-
由 Eric Blake 提交于
Most of our code base uses space after comma but not before; fix the remaining uses before adding a syntax check. * src/util/vircommand.c: Consistently use commas. * src/util/virlog.c: Likewise. * src/util/virnetdevbandwidth.c: Likewise. * src/util/virnetdevmacvlan.c: Likewise. * src/util/virnetdevvportprofile.c: Likewise. * src/util/virnetlink.c: Likewise. * src/util/virpci.c: Likewise. * src/util/virsysinfo.c: Likewise. * src/util/virusb.c: Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 15 11月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
These two chunks had to be part of df4283a5. But for some unclear reason, the weren't. Anyway, these two variables are not used anywhere within function. They're initialized to NULL and then VIR_FREE()-d. And there's no reason do do two NOPs, right? Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 08 11月, 2013 2 次提交
-
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1025397 When virPCIGetVirtualFunctions created the list of an SRIOV Physical Function's (PF) Virtual Functions (VF), it had assumed that the order of "virtfn*" links returned by readdir() from the PF's sysfs directory was already in the correct order. Experience has shown that this is not always the case - it can be in alphabetical order (which would e.g. place virtfn11 before virtfn2) or even some seemingly random order (see the example in the bugzilla report) This results in 1) incorrect assumptions made by consumers of the output of the virt_functions list of virsh nodedev-dumpxml, and 2) setting MAC address and vlan tag on the wrong VF (since libvirt uses netlink to set mac address and vlan tag, netlink requires the VF#, and the function virPCIGetVirtualFunctionIndex() returns the wrong index due to the improperly ordered VF list). The solution provided by this patch is for virPCIGetVirtualFunctions to no longer scan the entire device directory in its natural order, but instead to check for links individually by name "virtfn%d" where %d starts at 0 and increases with each success. Since VFs are created contiguously by the kernel, this will guarantee that all VFs are found, and placed in the arry in the correct order. One note of use to the uninitiated is that VIR_APPEND_ELEMENT always either increments *num_virtual_functions or fails, so no this isn't an endless loop. (NB: the SRIOV_* defines at the top of virpci.c were removed because they are unnecessary and/or not used.)
-
由 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.
-
- 05 11月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1018897 If a PCI deivce is not binded to any driver (e.g. there's yet no PCI driver in the linux kernel) but still users want to passthru the device we fail the whole operation as we fail to resolve the 'driver' link under the PCI device sysfs tree. Obviously, this is not a fatal error and it shouldn't be error at all. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 16 9月, 2013 1 次提交
-
-
由 Peter Krempa 提交于
Semantics of the libvirt helper are more clear. This change also allows to clean up some pieces of code.
-