2009-03-02 16:18:11 +00:00
|
|
|
/*
|
2012-12-13 14:52:25 +00:00
|
|
|
* virpci.h: helper APIs for managing host PCI devices
|
|
|
|
*
|
nodedev: report maxCount for virtual_functions capability
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.
2015-11-23 19:19:13 +00:00
|
|
|
* Copyright (C) 2009, 2011-2015 Red Hat, Inc.
|
2009-03-02 16:18:11 +00:00
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2012-09-20 22:30:55 +00:00
|
|
|
* License along with this library. If not, see
|
2012-07-21 10:06:23 +00:00
|
|
|
* <http://www.gnu.org/licenses/>.
|
2009-03-02 16:18:11 +00:00
|
|
|
*/
|
|
|
|
|
2019-06-18 16:13:08 +00:00
|
|
|
#pragma once
|
2009-03-02 16:18:11 +00:00
|
|
|
|
2019-06-18 16:13:08 +00:00
|
|
|
#include "internal.h"
|
|
|
|
#include "virmdev.h"
|
|
|
|
#include "virobject.h"
|
|
|
|
#include "virenum.h"
|
2009-03-02 16:18:11 +00:00
|
|
|
|
2013-01-14 22:11:44 +00:00
|
|
|
typedef struct _virPCIDevice virPCIDevice;
|
|
|
|
typedef virPCIDevice *virPCIDevicePtr;
|
|
|
|
typedef struct _virPCIDeviceAddress virPCIDeviceAddress;
|
|
|
|
typedef virPCIDeviceAddress *virPCIDeviceAddressPtr;
|
|
|
|
typedef struct _virPCIDeviceList virPCIDeviceList;
|
|
|
|
typedef virPCIDeviceList *virPCIDeviceListPtr;
|
|
|
|
|
2019-10-04 16:14:10 +00:00
|
|
|
G_DEFINE_AUTOPTR_CLEANUP_FUNC(virPCIDeviceList, virObjectUnref);
|
|
|
|
|
|
|
|
|
2019-06-18 16:13:08 +00:00
|
|
|
#define VIR_DOMAIN_DEVICE_ZPCI_MAX_UID UINT16_MAX
|
|
|
|
#define VIR_DOMAIN_DEVICE_ZPCI_MAX_FID UINT32_MAX
|
2018-11-08 11:00:26 +00:00
|
|
|
|
conf: fix zPCI address auto-generation on s390
Let us fix the issues with zPCI address validation and auto-generation
on s390.
Currently, there are two issues with handling the ZPCI address
extension. Firstly, when the uid is to be auto-generated with a
specified fid, .i.e.:
...
<address type='pci'>
<zpci fid='0x0000001f'/>
</address>
...
we expect uid='0x0001' (or the next available uid for the domain).
However, we get a parsing error:
$ virsh define zpci.xml
error: XML error: Invalid PCI address uid='0x0000', must be > 0x0000
and <= 0xffff
Secondly, when the uid is specified explicitly with the invalid
numerical value '0x0000', we actually expect the parsing error above.
However, the domain is being defined and the uid value is silently
changed to a valid value.
The first issue is a bug and the second one is undesired behaviour, and
both issues are related to how we (in-band) signal invalid values for
uid and fid. So let's fix the XML parsing to do validation based on what
is actually specified in the XML.
The first issue is also related to the current code behaviour, which
is, if either uid or fid is specified by the user, it is incorrectly
assumed that both uid and fid are specified. This bug is fixed by
identifying when the user specified ZPCI address is incomplete and
auto-generating the missing ZPCI address.
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-06-18 08:25:15 +00:00
|
|
|
typedef struct _virZPCIDeviceAddressID virZPCIDeviceAddressID;
|
2018-11-08 11:00:19 +00:00
|
|
|
typedef struct _virZPCIDeviceAddress virZPCIDeviceAddress;
|
|
|
|
typedef virZPCIDeviceAddress *virZPCIDeviceAddressPtr;
|
conf: fix zPCI address auto-generation on s390
Let us fix the issues with zPCI address validation and auto-generation
on s390.
Currently, there are two issues with handling the ZPCI address
extension. Firstly, when the uid is to be auto-generated with a
specified fid, .i.e.:
...
<address type='pci'>
<zpci fid='0x0000001f'/>
</address>
...
we expect uid='0x0001' (or the next available uid for the domain).
However, we get a parsing error:
$ virsh define zpci.xml
error: XML error: Invalid PCI address uid='0x0000', must be > 0x0000
and <= 0xffff
Secondly, when the uid is specified explicitly with the invalid
numerical value '0x0000', we actually expect the parsing error above.
However, the domain is being defined and the uid value is silently
changed to a valid value.
The first issue is a bug and the second one is undesired behaviour, and
both issues are related to how we (in-band) signal invalid values for
uid and fid. So let's fix the XML parsing to do validation based on what
is actually specified in the XML.
The first issue is also related to the current code behaviour, which
is, if either uid or fid is specified by the user, it is incorrectly
assumed that both uid and fid are specified. This bug is fixed by
identifying when the user specified ZPCI address is incomplete and
auto-generating the missing ZPCI address.
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-06-18 08:25:15 +00:00
|
|
|
|
|
|
|
struct _virZPCIDeviceAddressID {
|
|
|
|
unsigned int value;
|
|
|
|
bool isSet;
|
|
|
|
};
|
|
|
|
|
2018-11-08 11:00:19 +00:00
|
|
|
struct _virZPCIDeviceAddress {
|
conf: fix zPCI address auto-generation on s390
Let us fix the issues with zPCI address validation and auto-generation
on s390.
Currently, there are two issues with handling the ZPCI address
extension. Firstly, when the uid is to be auto-generated with a
specified fid, .i.e.:
...
<address type='pci'>
<zpci fid='0x0000001f'/>
</address>
...
we expect uid='0x0001' (or the next available uid for the domain).
However, we get a parsing error:
$ virsh define zpci.xml
error: XML error: Invalid PCI address uid='0x0000', must be > 0x0000
and <= 0xffff
Secondly, when the uid is specified explicitly with the invalid
numerical value '0x0000', we actually expect the parsing error above.
However, the domain is being defined and the uid value is silently
changed to a valid value.
The first issue is a bug and the second one is undesired behaviour, and
both issues are related to how we (in-band) signal invalid values for
uid and fid. So let's fix the XML parsing to do validation based on what
is actually specified in the XML.
The first issue is also related to the current code behaviour, which
is, if either uid or fid is specified by the user, it is incorrectly
assumed that both uid and fid are specified. This bug is fixed by
identifying when the user specified ZPCI address is incomplete and
auto-generating the missing ZPCI address.
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-06-18 08:25:15 +00:00
|
|
|
virZPCIDeviceAddressID uid; /* exempt from syntax-check */
|
|
|
|
virZPCIDeviceAddressID fid;
|
2019-06-07 14:32:37 +00:00
|
|
|
/* Don't forget to update virPCIDeviceAddressCopy if needed. */
|
2018-11-08 11:00:19 +00:00
|
|
|
};
|
|
|
|
|
2019-07-30 14:24:39 +00:00
|
|
|
#define VIR_PCI_DEVICE_ADDRESS_FMT "%04x:%02x:%02x.%d"
|
2019-07-30 12:43:44 +00:00
|
|
|
|
2013-01-14 22:11:44 +00:00
|
|
|
struct _virPCIDeviceAddress {
|
2011-08-16 04:28:43 +00:00
|
|
|
unsigned int domain;
|
|
|
|
unsigned int bus;
|
|
|
|
unsigned int slot;
|
|
|
|
unsigned int function;
|
2016-04-03 18:16:51 +00:00
|
|
|
int multi; /* virTristateSwitch */
|
2018-11-08 11:00:21 +00:00
|
|
|
int extFlags; /* enum virPCIDeviceAddressExtensionFlags */
|
|
|
|
virZPCIDeviceAddress zpci;
|
2019-06-07 14:32:37 +00:00
|
|
|
/* Don't forget to update virPCIDeviceAddressCopy if needed. */
|
2011-08-16 04:28:43 +00:00
|
|
|
};
|
|
|
|
|
2015-10-23 09:54:07 +00:00
|
|
|
typedef enum {
|
|
|
|
VIR_PCI_STUB_DRIVER_NONE = 0,
|
|
|
|
VIR_PCI_STUB_DRIVER_XEN,
|
|
|
|
VIR_PCI_STUB_DRIVER_VFIO,
|
|
|
|
VIR_PCI_STUB_DRIVER_LAST
|
|
|
|
} virPCIStubDriver;
|
|
|
|
|
|
|
|
VIR_ENUM_DECL(virPCIStubDriver);
|
|
|
|
|
2014-07-24 01:52:22 +00:00
|
|
|
typedef enum {
|
|
|
|
VIR_PCIE_LINK_SPEED_NA = 0,
|
|
|
|
VIR_PCIE_LINK_SPEED_25,
|
|
|
|
VIR_PCIE_LINK_SPEED_5,
|
|
|
|
VIR_PCIE_LINK_SPEED_8,
|
2017-03-01 09:55:58 +00:00
|
|
|
VIR_PCIE_LINK_SPEED_16,
|
2014-07-24 01:52:22 +00:00
|
|
|
VIR_PCIE_LINK_SPEED_LAST
|
|
|
|
} virPCIELinkSpeed;
|
|
|
|
|
2019-01-20 16:04:56 +00:00
|
|
|
VIR_ENUM_DECL(virPCIELinkSpeed);
|
2014-07-24 01:52:22 +00:00
|
|
|
|
2016-03-15 11:22:03 +00:00
|
|
|
typedef enum {
|
|
|
|
VIR_PCI_HEADER_ENDPOINT = 0,
|
|
|
|
VIR_PCI_HEADER_PCI_BRIDGE,
|
|
|
|
VIR_PCI_HEADER_CARDBUS_BRIDGE,
|
|
|
|
|
|
|
|
VIR_PCI_HEADER_LAST
|
|
|
|
} virPCIHeaderType;
|
|
|
|
|
2019-01-20 16:04:56 +00:00
|
|
|
VIR_ENUM_DECL(virPCIHeader);
|
2016-03-15 11:22:03 +00:00
|
|
|
|
2014-07-24 01:52:22 +00:00
|
|
|
typedef struct _virPCIELink virPCIELink;
|
|
|
|
typedef virPCIELink *virPCIELinkPtr;
|
|
|
|
struct _virPCIELink {
|
|
|
|
int port;
|
|
|
|
virPCIELinkSpeed speed;
|
|
|
|
unsigned int width;
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef struct _virPCIEDeviceInfo virPCIEDeviceInfo;
|
|
|
|
typedef virPCIEDeviceInfo *virPCIEDeviceInfoPtr;
|
|
|
|
struct _virPCIEDeviceInfo {
|
|
|
|
/* Not all PCI Express devices have link. For example this 'Root Complex
|
|
|
|
* Integrated Endpoint' and 'Root Complex Event Collector' don't have it. */
|
|
|
|
virPCIELink *link_cap; /* PCIe device link capabilities */
|
|
|
|
virPCIELink *link_sta; /* Actually negotiated capabilities */
|
|
|
|
};
|
|
|
|
|
2013-04-15 10:29:23 +00:00
|
|
|
virPCIDevicePtr virPCIDeviceNew(unsigned int domain,
|
|
|
|
unsigned int bus,
|
|
|
|
unsigned int slot,
|
|
|
|
unsigned int function);
|
2013-05-31 15:06:32 +00:00
|
|
|
virPCIDevicePtr virPCIDeviceCopy(virPCIDevicePtr dev);
|
2013-01-14 22:11:44 +00:00
|
|
|
void virPCIDeviceFree(virPCIDevicePtr dev);
|
|
|
|
const char *virPCIDeviceGetName(virPCIDevicePtr dev);
|
2016-11-19 19:30:03 +00:00
|
|
|
const char *virPCIDeviceGetConfigPath(virPCIDevicePtr dev);
|
2013-01-14 22:11:44 +00:00
|
|
|
|
|
|
|
int virPCIDeviceDetach(virPCIDevicePtr dev,
|
|
|
|
virPCIDeviceListPtr activeDevs,
|
2013-05-30 18:14:46 +00:00
|
|
|
virPCIDeviceListPtr inactiveDevs);
|
2013-01-14 22:11:44 +00:00
|
|
|
int virPCIDeviceReattach(virPCIDevicePtr dev,
|
|
|
|
virPCIDeviceListPtr activeDevs,
|
pci: autolearn name of stub driver, remove from arglist
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.
2013-05-01 18:44:10 +00:00
|
|
|
virPCIDeviceListPtr inactiveDevs);
|
2013-01-14 22:11:44 +00:00
|
|
|
int virPCIDeviceReset(virPCIDevicePtr dev,
|
|
|
|
virPCIDeviceListPtr activeDevs,
|
|
|
|
virPCIDeviceListPtr inactiveDevs);
|
|
|
|
|
|
|
|
void virPCIDeviceSetManaged(virPCIDevice *dev,
|
2013-04-10 10:09:23 +00:00
|
|
|
bool managed);
|
2016-01-28 08:21:43 +00:00
|
|
|
bool virPCIDeviceGetManaged(virPCIDevice *dev);
|
2015-10-23 09:54:07 +00:00
|
|
|
void virPCIDeviceSetStubDriver(virPCIDevicePtr dev,
|
|
|
|
virPCIStubDriver driver);
|
|
|
|
virPCIStubDriver virPCIDeviceGetStubDriver(virPCIDevicePtr dev);
|
2015-01-14 11:02:40 +00:00
|
|
|
virPCIDeviceAddressPtr virPCIDeviceGetAddress(virPCIDevicePtr dev);
|
2014-03-01 06:28:56 +00:00
|
|
|
int virPCIDeviceSetUsedBy(virPCIDevice *dev,
|
|
|
|
const char *drv_name,
|
|
|
|
const char *dom_name);
|
|
|
|
void virPCIDeviceGetUsedBy(virPCIDevice *dev,
|
|
|
|
const char **drv_name,
|
|
|
|
const char **dom_name);
|
2016-01-28 08:21:43 +00:00
|
|
|
bool virPCIDeviceGetUnbindFromStub(virPCIDevicePtr dev);
|
2013-01-14 22:11:44 +00:00
|
|
|
void virPCIDeviceSetUnbindFromStub(virPCIDevice *dev,
|
2013-04-10 10:44:41 +00:00
|
|
|
bool unbind);
|
2016-01-28 08:21:43 +00:00
|
|
|
bool virPCIDeviceGetRemoveSlot(virPCIDevicePtr dev);
|
2013-01-14 22:11:44 +00:00
|
|
|
void virPCIDeviceSetRemoveSlot(virPCIDevice *dev,
|
2013-04-10 10:44:41 +00:00
|
|
|
bool remove_slot);
|
2016-01-28 08:21:43 +00:00
|
|
|
bool virPCIDeviceGetReprobe(virPCIDevicePtr dev);
|
2013-01-14 22:11:44 +00:00
|
|
|
void virPCIDeviceSetReprobe(virPCIDevice *dev,
|
2013-04-10 10:44:41 +00:00
|
|
|
bool reprobe);
|
2013-01-14 22:11:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
virPCIDeviceListPtr virPCIDeviceListNew(void);
|
|
|
|
int virPCIDeviceListAdd(virPCIDeviceListPtr list,
|
|
|
|
virPCIDevicePtr dev);
|
2013-06-25 01:27:52 +00:00
|
|
|
int virPCIDeviceListAddCopy(virPCIDeviceListPtr list, virPCIDevicePtr dev);
|
2013-01-14 22:11:44 +00:00
|
|
|
virPCIDevicePtr virPCIDeviceListGet(virPCIDeviceListPtr list,
|
|
|
|
int idx);
|
2014-01-07 14:44:27 +00:00
|
|
|
size_t virPCIDeviceListCount(virPCIDeviceListPtr list);
|
2013-01-14 22:11:44 +00:00
|
|
|
virPCIDevicePtr virPCIDeviceListSteal(virPCIDeviceListPtr list,
|
|
|
|
virPCIDevicePtr dev);
|
|
|
|
virPCIDevicePtr virPCIDeviceListStealIndex(virPCIDeviceListPtr list,
|
|
|
|
int idx);
|
|
|
|
void virPCIDeviceListDel(virPCIDeviceListPtr list,
|
|
|
|
virPCIDevicePtr dev);
|
|
|
|
virPCIDevicePtr virPCIDeviceListFind(virPCIDeviceListPtr list,
|
|
|
|
virPCIDevicePtr dev);
|
2013-05-31 15:06:32 +00:00
|
|
|
virPCIDevicePtr
|
|
|
|
virPCIDeviceListFindByIDs(virPCIDeviceListPtr list,
|
|
|
|
unsigned int domain,
|
|
|
|
unsigned int bus,
|
|
|
|
unsigned int slot,
|
|
|
|
unsigned int function);
|
2013-01-14 22:11:44 +00:00
|
|
|
int virPCIDeviceListFindIndex(virPCIDeviceListPtr list,
|
|
|
|
virPCIDevicePtr dev);
|
2009-08-14 07:31:11 +00:00
|
|
|
|
2009-08-14 13:20:40 +00:00
|
|
|
/*
|
|
|
|
* Callback that will be invoked once for each file
|
|
|
|
* associated with / used for PCI host device access.
|
|
|
|
*
|
|
|
|
* Should return 0 if successfully processed, or
|
|
|
|
* -1 to indicate error and abort iteration
|
|
|
|
*/
|
2013-01-14 22:11:44 +00:00
|
|
|
typedef int (*virPCIDeviceFileActor)(virPCIDevicePtr dev,
|
|
|
|
const char *path, void *opaque);
|
|
|
|
int virPCIDeviceFileIterate(virPCIDevicePtr dev,
|
|
|
|
virPCIDeviceFileActor actor,
|
|
|
|
void *opaque);
|
2013-06-23 18:47:57 +00:00
|
|
|
|
2016-04-03 18:16:51 +00:00
|
|
|
typedef int (*virPCIDeviceAddressActor)(virPCIDeviceAddressPtr addr,
|
2013-06-23 18:47:57 +00:00
|
|
|
void *opaque);
|
|
|
|
int virPCIDeviceAddressIOMMUGroupIterate(virPCIDeviceAddressPtr orig,
|
|
|
|
virPCIDeviceAddressActor actor,
|
|
|
|
void *opaque);
|
|
|
|
virPCIDeviceListPtr virPCIDeviceGetIOMMUGroupList(virPCIDevicePtr dev);
|
|
|
|
int virPCIDeviceAddressGetIOMMUGroupAddresses(virPCIDeviceAddressPtr devAddr,
|
|
|
|
virPCIDeviceAddressPtr **iommuGroupDevices,
|
|
|
|
size_t *nIommuGroupDevices);
|
2015-12-15 08:53:31 +00:00
|
|
|
int virPCIDeviceAddressGetIOMMUGroupNum(virPCIDeviceAddressPtr addr);
|
2019-09-19 12:43:13 +00:00
|
|
|
char *virPCIDeviceAddressGetIOMMUGroupDev(const virPCIDeviceAddress *devAddr);
|
2013-06-23 18:47:57 +00:00
|
|
|
char *virPCIDeviceGetIOMMUGroupDev(virPCIDevicePtr dev);
|
2009-08-14 13:20:40 +00:00
|
|
|
|
2013-01-14 22:11:44 +00:00
|
|
|
int virPCIDeviceIsAssignable(virPCIDevicePtr dev,
|
|
|
|
int strict_acs_check);
|
2009-12-22 17:21:15 +00:00
|
|
|
|
2017-03-07 19:23:01 +00:00
|
|
|
virPCIDeviceAddressPtr
|
|
|
|
virPCIGetDeviceAddressFromSysfsLink(const char *device_link);
|
|
|
|
|
2015-12-20 22:58:58 +00:00
|
|
|
int virPCIGetPhysicalFunction(const char *vf_sysfs_path,
|
|
|
|
virPCIDeviceAddressPtr *pf);
|
2011-08-16 04:28:43 +00:00
|
|
|
|
2013-01-14 22:11:44 +00:00
|
|
|
int virPCIGetVirtualFunctions(const char *sysfs_path,
|
|
|
|
virPCIDeviceAddressPtr **virtual_functions,
|
nodedev: report maxCount for virtual_functions capability
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.
2015-11-23 19:19:13 +00:00
|
|
|
size_t *num_virtual_functions,
|
|
|
|
unsigned int *max_virtual_functions);
|
2011-08-16 04:28:43 +00:00
|
|
|
|
2013-01-14 22:11:44 +00:00
|
|
|
int virPCIIsVirtualFunction(const char *vf_sysfs_device_link);
|
2011-08-16 04:28:48 +00:00
|
|
|
|
2013-01-14 22:11:44 +00:00
|
|
|
int virPCIGetVirtualFunctionIndex(const char *pf_sysfs_device_link,
|
|
|
|
const char *vf_sysfs_device_link,
|
|
|
|
int *vf_index);
|
2011-08-16 04:28:48 +00:00
|
|
|
|
2015-12-15 08:53:31 +00:00
|
|
|
int virPCIDeviceAddressGetSysfsFile(virPCIDeviceAddressPtr addr,
|
2013-01-14 22:11:44 +00:00
|
|
|
char **pci_sysfs_device_link);
|
2012-03-06 01:12:23 +00:00
|
|
|
|
2017-07-31 04:21:45 +00:00
|
|
|
int virPCIGetNetName(const char *device_link_sysfs_path,
|
|
|
|
size_t idx,
|
|
|
|
char *physPortID,
|
|
|
|
char **netname);
|
2011-08-16 04:28:48 +00:00
|
|
|
|
2018-09-13 14:36:25 +00:00
|
|
|
bool virPCIDeviceAddressIsValid(virPCIDeviceAddressPtr addr,
|
|
|
|
bool report);
|
|
|
|
bool virPCIDeviceAddressIsEmpty(const virPCIDeviceAddress *addr);
|
|
|
|
|
2019-06-04 08:43:40 +00:00
|
|
|
bool virPCIDeviceAddressEqual(const virPCIDeviceAddress *addr1,
|
|
|
|
const virPCIDeviceAddress *addr2);
|
2019-06-07 14:32:37 +00:00
|
|
|
void virPCIDeviceAddressCopy(virPCIDeviceAddressPtr dst,
|
|
|
|
const virPCIDeviceAddress *src);
|
2018-09-13 14:36:25 +00:00
|
|
|
|
2019-06-06 15:02:11 +00:00
|
|
|
char *virPCIDeviceAddressAsString(const virPCIDeviceAddress *addr)
|
2018-09-04 16:32:38 +00:00
|
|
|
ATTRIBUTE_NONNULL(1);
|
|
|
|
|
2013-06-17 15:57:19 +00:00
|
|
|
int virPCIDeviceAddressParse(char *address, virPCIDeviceAddressPtr bdf);
|
|
|
|
|
conf: fix zPCI address auto-generation on s390
Let us fix the issues with zPCI address validation and auto-generation
on s390.
Currently, there are two issues with handling the ZPCI address
extension. Firstly, when the uid is to be auto-generated with a
specified fid, .i.e.:
...
<address type='pci'>
<zpci fid='0x0000001f'/>
</address>
...
we expect uid='0x0001' (or the next available uid for the domain).
However, we get a parsing error:
$ virsh define zpci.xml
error: XML error: Invalid PCI address uid='0x0000', must be > 0x0000
and <= 0xffff
Secondly, when the uid is specified explicitly with the invalid
numerical value '0x0000', we actually expect the parsing error above.
However, the domain is being defined and the uid value is silently
changed to a valid value.
The first issue is a bug and the second one is undesired behaviour, and
both issues are related to how we (in-band) signal invalid values for
uid and fid. So let's fix the XML parsing to do validation based on what
is actually specified in the XML.
The first issue is also related to the current code behaviour, which
is, if either uid or fid is specified by the user, it is incorrectly
assumed that both uid and fid are specified. This bug is fixed by
identifying when the user specified ZPCI address is incomplete and
auto-generating the missing ZPCI address.
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-06-18 08:25:15 +00:00
|
|
|
bool virZPCIDeviceAddressIsIncomplete(const virZPCIDeviceAddress *addr);
|
|
|
|
bool virZPCIDeviceAddressIsPresent(const virZPCIDeviceAddress *addr);
|
2018-11-08 11:00:26 +00:00
|
|
|
|
2013-01-14 22:11:44 +00:00
|
|
|
int virPCIGetVirtualFunctionInfo(const char *vf_sysfs_device_path,
|
util: save the correct VF's info when using a dual port SRIOV NIC in single port mode
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)
2017-08-08 00:25:57 +00:00
|
|
|
int pfNetDevIdx,
|
|
|
|
char **pfname,
|
|
|
|
int *vf_index);
|
2012-03-06 01:12:23 +00:00
|
|
|
|
2015-10-29 15:09:54 +00:00
|
|
|
int virPCIDeviceUnbind(virPCIDevicePtr dev);
|
2017-03-07 17:58:15 +00:00
|
|
|
int virPCIDeviceRebind(virPCIDevicePtr dev);
|
2014-01-16 11:27:23 +00:00
|
|
|
int virPCIDeviceGetDriverPathAndName(virPCIDevicePtr dev,
|
|
|
|
char **path,
|
|
|
|
char **name);
|
|
|
|
|
2014-05-15 08:04:28 +00:00
|
|
|
int virPCIDeviceIsPCIExpress(virPCIDevicePtr dev);
|
|
|
|
int virPCIDeviceHasPCIExpressLink(virPCIDevicePtr dev);
|
|
|
|
int virPCIDeviceGetLinkCapSta(virPCIDevicePtr dev,
|
|
|
|
int *ca_port,
|
|
|
|
unsigned int *cap_speed,
|
|
|
|
unsigned int *cap_width,
|
|
|
|
unsigned int *sta_speed,
|
|
|
|
unsigned int *sta_width);
|
2014-07-23 04:38:30 +00:00
|
|
|
|
2016-03-15 11:22:03 +00:00
|
|
|
int virPCIGetHeaderType(virPCIDevicePtr dev, int *hdrType);
|
|
|
|
|
2014-07-23 04:38:30 +00:00
|
|
|
void virPCIEDeviceInfoFree(virPCIEDeviceInfoPtr dev);
|
|
|
|
|
2018-07-24 15:52:20 +00:00
|
|
|
void virPCIDeviceAddressFree(virPCIDeviceAddressPtr address);
|
|
|
|
|
2019-10-15 12:47:50 +00:00
|
|
|
G_DEFINE_AUTOPTR_CLEANUP_FUNC(virPCIDevice, virPCIDeviceFree);
|
|
|
|
G_DEFINE_AUTOPTR_CLEANUP_FUNC(virPCIDeviceAddress, virPCIDeviceAddressFree);
|
|
|
|
G_DEFINE_AUTOPTR_CLEANUP_FUNC(virPCIEDeviceInfo, virPCIEDeviceInfoFree);
|