- 27 7月, 2018 1 次提交
-
-
由 Sukrit Bhatnagar 提交于
Using the new VIR_DEFINE_AUTOPTR_FUNC macro defined in src/util/viralloc.h, define a new wrapper around an existing cleanup function which will be called when a variable declared with VIR_AUTOPTR macro goes out of scope. Also, drop the redundant viralloc.h include, since that has moved from the source module into the header. When variables of types virPCIDevicePtr, virPCIDeviceAddressPtr and virPCIEDeviceInfoPtr are declared using VIR_AUTOPTR, the functions virPCIDeviceFree, virPCIDeviceAddressFree and virPCIEDeviceInfoFree, respectively, will be run automatically on them when they go out of scope. Signed-off-by: NSukrit Bhatnagar <skrtbhtngr@gmail.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 29 1月, 2018 1 次提交
-
-
由 Erik Skultety 提交于
This is a replacement for the existing udevPCIGetMdevTypesCap which is static to the udev backend. This simple helper constructs the sysfs path from the device's base path for each mdev type and queries the corresponding attributes of that type. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 12 8月, 2017 3 次提交
-
-
由 Laine Stump 提交于
Mellanox ConnectX-3 dual port SRIOV NICs present a bit of a challenge when assigning one of their VFs to a guest using VFIO device assignment. These NICs have only a single PCI PF device, and that single PF has two netdevs sharing the single PCI address - one for port 1 and one for port 2. When a VF is created it can also have 2 netdevs, or it can be setup in "single port" mode, where the VF has only a single netdev, and that netdev is connected either to port 1 or to port 2. When the VF is created in dual port mode, you get/set the MAC address/vlan tag for the port 1 VF by sending a netlink message to the PF's port1 netdev, and you get/set the MAC address/vlan tag for the port 2 VF by sending a netlink message to the PF's port 2 netdev. (Of course libvirt doesn't have any way to describe MAC/vlan info for 2 ports in a single hostdev interface, so that's a bit of a moot point) When the VF is created in single port mode, you can *set* the MAC/vlan info by sending a netlink message to *either* PF netdev - the driver is smart enough to understand that there's only a single netdev, and set the MAC/vlan for that netdev. When you want to *get* it, however, the driver is more accurate - it will return 00:00:00:00:00:00 for the MAC if you request it from the port 1 PF netdev when the VF was configured to be single port on port 2, or if you request if from the port 2 PF netdev when the VF was configured to be single port on port 1. Based on this information, when *getting* the MAC/vlan info (to save the original setting prior to assignment), we determine the correct PF netdev by matching phys_port_id between VF and PF. (IMPORTANT NOTE: this implies that to do PCI device assignment of the VFs on dual port Mellanox cards using <interface type='hostdev'> (i.e. if you want the MAC address/vlan tag to be set), not only must the VFs be configured in single port mode, but also the VFs *must* be bound to the host VF net driver, and libvirt must use managed='yes') By the time libvirt is ready to set the new MAC/vlan tag, the VF has already been unbound from the host net driver and bound to vfio-pci. This isn't problematic though because, as stated earlier, when a VF is created in single port mode, commands to configure it can be sent to either the port 1 PF netdev or the port 2 PF netdev. When it is time to restore the original MAC/vlan tag, again the VF will *not* be bound to a host net driver, so it won't be possible to learn from sysfs whether to use the port 1 or port 2 PF netdev for the netlink commands. And again, it doesn't matter which netdev you use. However, we must keep in mind that we saved the original settings to a file called "${PF}_${VFNUM}". To solve this problem, we just check for the existence of ${PF1}_${VFNUM} and ${PF2}_${VFNUM}, and use whichever one we find (since we know that only one can be there)
-
由 Laine Stump 提交于
A single PCI device may have multiple netdevs associated with it. Each of those netdevs will have a different phys_port_id entry in sysfs. This patch modifies virPCIGetNetName() to allow selecting one of the potential many netdevs in two different ways: 1) by setting the "idx" argument, the caller can select the 1st (0), 2nd (1), etc. netdev from the PCI device's net subdirectory. 2) If the physPortID arg is set (to a null-terminated string) then virPCIGetNetName() returns the netdev that has that phys_port_id in the sysfs file of the same name in the netdev's directory.
-
由 Laine Stump 提交于
The first arg isn't modified in the function, so it should be const.
-
- 14 4月, 2017 1 次提交
-
-
由 Shivaprasad G Bhat 提交于
Without this added enum value, nodedev-dumpxml of a GEN4 (PCIe 4.0) card will fail (due to the unrecognized link speed), and since nodedev-detach and nodedev-reattach internally do a dumpxml+parse, they will also fail. With this patch, all those operations succeed. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
-
- 24 3月, 2017 2 次提交
-
-
由 Laine Stump 提交于
This function unbinds a device from its driver, then immediately rebinds it to its driver again. The code for this new function is just the 2nd half of virPCIDeviceBindWithDriverOverride(), so that function's 2nd half is replaced with a call to virPCIDeviceRebind().
-
由 Laine Stump 提交于
This function will be useful in virnetdev.c, so promote it from static.
-
- 01 12月, 2016 1 次提交
-
-
由 Laine Stump 提交于
The path to the config file for a PCI device is conventiently stored in a virPCIDevice object, but that object's contents aren't directly visible outside of virpci.c, so we need to have an accessor function for it if anyone needs to look at it.
-
- 02 5月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
We had both and the only difference was that the latter also included information about multifunction setting. The problem with that was that we couldn't use functions made for only one of the structs (e.g. parsing). To consolidate those two structs, use the one in virpci.h, include that in domain_conf.h and add the multifunction member in it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 19 3月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
If we expose this information, which is one byte in every PCI config file, we let all mgmt apps know whether the device itself is an endpoint or not so it's easier for them to decide whether such device can be passed through into a VM (endpoint) or not (*-bridge). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1317531Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 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 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 提交于
-