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"
|
2021-10-20 08:30:32 +00:00
|
|
|
#include "virpcivpd.h"
|
2009-03-02 16:18:11 +00:00
|
|
|
|
2013-01-14 22:11:44 +00:00
|
|
|
typedef struct _virPCIDevice virPCIDevice;
|
|
|
|
typedef struct _virPCIDeviceAddress virPCIDeviceAddress;
|
|
|
|
typedef struct _virPCIDeviceList virPCIDeviceList;
|
|
|
|
|
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;
|
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
|
|
|
|
util: Add phys_port_name support on virPCIGetNetName
virPCIGetNetName is used to get the name of the netdev associated with
a particular PCI device. This is used when we have a VF name, but need
the PF name in order to send a netlink command (e.g. in order to
get/set the MAC address of the VF).
In simple cases there is a single netdev associated with any PCI
device, so it is easy to figure out the PF netdev for a VF - just look
for the PCI device that has the VF listed in its "virtfns" directory;
the only name in the "net" subdirectory of that PCI device's sysfs
directory is the PF netdev that is upstream of the VF in question.
In some cases there can be more than one netdev in a PCI device's net
directory though. In the past, the only case of this was for SR-IOV
NICs that could have multiple PF's per PCI device. In this case, all
PF netdevs associated with a PCI address would be listed in the "net"
subdirectory of the PCI device's directory in sysfs. At the same time,
all VF netdevs and all PF netdevs have a phys_port_id in their sysfs,
so the way to learn the correct PF netdev for a particular VF netdev
is to search through the list of devices in the net subdirectory of
the PF's PCI device, looking for the one netdev with a "phys_port_id"
matching that of the VF netdev.
But starting in kernel 5.8, the NVIDIA Mellanox driver began linking
the VFs' representor netdevs to the PF PCI address [1], and so the VF
representor netdevs would also show up in the net
subdirectory. However, all of the devices that do so also only have a
single PF netdev for any given PCI address.
This means that the net directory of the PCI device can still hold
multiple net devices, but only one of them will be the PF netdev (the
others are VF representors):
$ ls '/sys/bus/pci/devices/0000:82:00.0/net'
ens1f0 eth0 eth1
In this case the way to find the PF device is to look at the
"phys_port_name" attribute of each netdev in sysfs. All PF devices
have a phys_port_name matching a particular regex
(p[0-9]+$)|(p[0-9]+s[0-9]+$)
Since there can only be one PF in the entire list of devices, once we
match that regex, we've found the PF netdev.
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/
commit/?id=123f0f53dd64b67e34142485fe866a8a581f12f1
Co-Authored-by: Moshe Levi <moshele@nvidia.com>
Signed-off-by: Dmytro Linkin <dlinkin@nvidia.com>
Reviewed-by: Adrian Chiris <adrianc@nvidia.com>
Reviewed-by: Laine Stump <laine@redhat.com>
2021-01-21 12:15:22 +00:00
|
|
|
/* Represents format of PF's phys_port_name in switchdev mode:
|
2021-04-15 08:12:12 +00:00
|
|
|
* 'p%u' or 'p%us%u'. New line checked since value is read from sysfs file.
|
util: Add phys_port_name support on virPCIGetNetName
virPCIGetNetName is used to get the name of the netdev associated with
a particular PCI device. This is used when we have a VF name, but need
the PF name in order to send a netlink command (e.g. in order to
get/set the MAC address of the VF).
In simple cases there is a single netdev associated with any PCI
device, so it is easy to figure out the PF netdev for a VF - just look
for the PCI device that has the VF listed in its "virtfns" directory;
the only name in the "net" subdirectory of that PCI device's sysfs
directory is the PF netdev that is upstream of the VF in question.
In some cases there can be more than one netdev in a PCI device's net
directory though. In the past, the only case of this was for SR-IOV
NICs that could have multiple PF's per PCI device. In this case, all
PF netdevs associated with a PCI address would be listed in the "net"
subdirectory of the PCI device's directory in sysfs. At the same time,
all VF netdevs and all PF netdevs have a phys_port_id in their sysfs,
so the way to learn the correct PF netdev for a particular VF netdev
is to search through the list of devices in the net subdirectory of
the PF's PCI device, looking for the one netdev with a "phys_port_id"
matching that of the VF netdev.
But starting in kernel 5.8, the NVIDIA Mellanox driver began linking
the VFs' representor netdevs to the PF PCI address [1], and so the VF
representor netdevs would also show up in the net
subdirectory. However, all of the devices that do so also only have a
single PF netdev for any given PCI address.
This means that the net directory of the PCI device can still hold
multiple net devices, but only one of them will be the PF netdev (the
others are VF representors):
$ ls '/sys/bus/pci/devices/0000:82:00.0/net'
ens1f0 eth0 eth1
In this case the way to find the PF device is to look at the
"phys_port_name" attribute of each netdev in sysfs. All PF devices
have a phys_port_name matching a particular regex
(p[0-9]+$)|(p[0-9]+s[0-9]+$)
Since there can only be one PF in the entire list of devices, once we
match that regex, we've found the PF netdev.
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/
commit/?id=123f0f53dd64b67e34142485fe866a8a581f12f1
Co-Authored-by: Moshe Levi <moshele@nvidia.com>
Signed-off-by: Dmytro Linkin <dlinkin@nvidia.com>
Reviewed-by: Adrian Chiris <adrianc@nvidia.com>
Reviewed-by: Laine Stump <laine@redhat.com>
2021-01-21 12:15:22 +00:00
|
|
|
*/
|
|
|
|
#define VIR_PF_PHYS_PORT_NAME_REGEX "(p[0-9]+$)|(p[0-9]+s[0-9]+$)"
|
|
|
|
|
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;
|
2021-04-07 11:48:41 +00:00
|
|
|
virTristateSwitch multi;
|
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;
|
|
|
|
struct _virPCIELink {
|
|
|
|
int port;
|
|
|
|
virPCIELinkSpeed speed;
|
|
|
|
unsigned int width;
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef struct _virPCIEDeviceInfo virPCIEDeviceInfo;
|
|
|
|
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 */
|
|
|
|
};
|
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
virPCIDevice *virPCIDeviceNew(const virPCIDeviceAddress *address);
|
|
|
|
virPCIDevice *virPCIDeviceCopy(virPCIDevice *dev);
|
|
|
|
void virPCIDeviceFree(virPCIDevice *dev);
|
|
|
|
const char *virPCIDeviceGetName(virPCIDevice *dev);
|
|
|
|
const char *virPCIDeviceGetConfigPath(virPCIDevice *dev);
|
|
|
|
|
|
|
|
int virPCIDeviceDetach(virPCIDevice *dev,
|
|
|
|
virPCIDeviceList *activeDevs,
|
|
|
|
virPCIDeviceList *inactiveDevs);
|
|
|
|
int virPCIDeviceReattach(virPCIDevice *dev,
|
|
|
|
virPCIDeviceList *activeDevs,
|
|
|
|
virPCIDeviceList *inactiveDevs);
|
|
|
|
int virPCIDeviceReset(virPCIDevice *dev,
|
|
|
|
virPCIDeviceList *activeDevs,
|
|
|
|
virPCIDeviceList *inactiveDevs);
|
2013-01-14 22:11:44 +00:00
|
|
|
|
|
|
|
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);
|
2021-03-11 07:16:13 +00:00
|
|
|
void virPCIDeviceSetStubDriver(virPCIDevice *dev,
|
2015-10-23 09:54:07 +00:00
|
|
|
virPCIStubDriver driver);
|
2021-03-11 07:16:13 +00:00
|
|
|
virPCIStubDriver virPCIDeviceGetStubDriver(virPCIDevice *dev);
|
|
|
|
virPCIDeviceAddress *virPCIDeviceGetAddress(virPCIDevice *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);
|
2021-03-11 07:16:13 +00:00
|
|
|
bool virPCIDeviceGetUnbindFromStub(virPCIDevice *dev);
|
2013-01-14 22:11:44 +00:00
|
|
|
void virPCIDeviceSetUnbindFromStub(virPCIDevice *dev,
|
2013-04-10 10:44:41 +00:00
|
|
|
bool unbind);
|
2021-03-11 07:16:13 +00:00
|
|
|
bool virPCIDeviceGetRemoveSlot(virPCIDevice *dev);
|
2013-01-14 22:11:44 +00:00
|
|
|
void virPCIDeviceSetRemoveSlot(virPCIDevice *dev,
|
2013-04-10 10:44:41 +00:00
|
|
|
bool remove_slot);
|
2021-03-11 07:16:13 +00:00
|
|
|
bool virPCIDeviceGetReprobe(virPCIDevice *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
|
|
|
|
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
virPCIDeviceList *virPCIDeviceListNew(void);
|
|
|
|
int virPCIDeviceListAdd(virPCIDeviceList *list,
|
|
|
|
virPCIDevice *dev);
|
|
|
|
int virPCIDeviceListAddCopy(virPCIDeviceList *list, virPCIDevice *dev);
|
|
|
|
virPCIDevice *virPCIDeviceListGet(virPCIDeviceList *list,
|
2013-01-14 22:11:44 +00:00
|
|
|
int idx);
|
2021-03-11 07:16:13 +00:00
|
|
|
size_t virPCIDeviceListCount(virPCIDeviceList *list);
|
|
|
|
virPCIDevice *virPCIDeviceListSteal(virPCIDeviceList *list,
|
|
|
|
virPCIDeviceAddress *devAddr);
|
|
|
|
virPCIDevice *virPCIDeviceListStealIndex(virPCIDeviceList *list,
|
2013-01-14 22:11:44 +00:00
|
|
|
int idx);
|
2021-03-11 07:16:13 +00:00
|
|
|
void virPCIDeviceListDel(virPCIDeviceList *list,
|
|
|
|
virPCIDeviceAddress *devAddr);
|
|
|
|
virPCIDevice *virPCIDeviceListFind(virPCIDeviceList *list,
|
|
|
|
virPCIDeviceAddress *devAddr);
|
|
|
|
virPCIDevice *
|
|
|
|
virPCIDeviceListFindByIDs(virPCIDeviceList *list,
|
2013-05-31 15:06:32 +00:00
|
|
|
unsigned int domain,
|
|
|
|
unsigned int bus,
|
|
|
|
unsigned int slot,
|
|
|
|
unsigned int function);
|
2021-03-11 07:16:13 +00:00
|
|
|
int virPCIDeviceListFindIndex(virPCIDeviceList *list,
|
|
|
|
virPCIDeviceAddress *devAddr);
|
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
|
|
|
|
*/
|
2021-03-11 07:16:13 +00:00
|
|
|
typedef int (*virPCIDeviceFileActor)(virPCIDevice *dev,
|
2013-01-14 22:11:44 +00:00
|
|
|
const char *path, void *opaque);
|
2021-03-11 07:16:13 +00:00
|
|
|
int virPCIDeviceFileIterate(virPCIDevice *dev,
|
2013-01-14 22:11:44 +00:00
|
|
|
virPCIDeviceFileActor actor,
|
|
|
|
void *opaque);
|
2013-06-23 18:47:57 +00:00
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
typedef int (*virPCIDeviceAddressActor)(virPCIDeviceAddress *addr,
|
2013-06-23 18:47:57 +00:00
|
|
|
void *opaque);
|
2021-03-11 07:16:13 +00:00
|
|
|
int virPCIDeviceAddressIOMMUGroupIterate(virPCIDeviceAddress *orig,
|
2013-06-23 18:47:57 +00:00
|
|
|
virPCIDeviceAddressActor actor,
|
|
|
|
void *opaque);
|
2021-03-11 07:16:13 +00:00
|
|
|
virPCIDeviceList *virPCIDeviceGetIOMMUGroupList(virPCIDevice *dev);
|
|
|
|
int virPCIDeviceAddressGetIOMMUGroupAddresses(virPCIDeviceAddress *devAddr,
|
|
|
|
virPCIDeviceAddress ***iommuGroupDevices,
|
2013-06-23 18:47:57 +00:00
|
|
|
size_t *nIommuGroupDevices);
|
2021-03-11 07:16:13 +00:00
|
|
|
int virPCIDeviceAddressGetIOMMUGroupNum(virPCIDeviceAddress *addr);
|
2019-09-19 12:43:13 +00:00
|
|
|
char *virPCIDeviceAddressGetIOMMUGroupDev(const virPCIDeviceAddress *devAddr);
|
2021-01-04 12:54:29 +00:00
|
|
|
bool virPCIDeviceExists(const virPCIDeviceAddress *addr);
|
2021-03-11 07:16:13 +00:00
|
|
|
char *virPCIDeviceGetIOMMUGroupDev(virPCIDevice *dev);
|
2009-08-14 13:20:40 +00:00
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
int virPCIDeviceIsAssignable(virPCIDevice *dev,
|
2013-01-14 22:11:44 +00:00
|
|
|
int strict_acs_check);
|
2009-12-22 17:21:15 +00:00
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
virPCIDeviceAddress *
|
2017-03-07 19:23:01 +00:00
|
|
|
virPCIGetDeviceAddressFromSysfsLink(const char *device_link);
|
|
|
|
|
2015-12-20 22:58:58 +00:00
|
|
|
int virPCIGetPhysicalFunction(const char *vf_sysfs_path,
|
2021-03-11 07:16:13 +00:00
|
|
|
virPCIDeviceAddress **pf);
|
2011-08-16 04:28:43 +00:00
|
|
|
|
2021-08-03 14:45:36 +00:00
|
|
|
struct virPCIVirtualFunction {
|
|
|
|
virPCIDeviceAddress *addr;
|
2021-08-04 15:37:44 +00:00
|
|
|
char *ifname;
|
2021-08-03 14:45:36 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct _virPCIVirtualFunctionList {
|
|
|
|
struct virPCIVirtualFunction *functions;
|
|
|
|
size_t nfunctions;
|
|
|
|
size_t maxfunctions;
|
|
|
|
};
|
|
|
|
typedef struct _virPCIVirtualFunctionList virPCIVirtualFunctionList;
|
|
|
|
|
|
|
|
void virPCIVirtualFunctionListFree(virPCIVirtualFunctionList *list);
|
|
|
|
G_DEFINE_AUTOPTR_CLEANUP_FUNC(virPCIVirtualFunctionList, virPCIVirtualFunctionListFree);
|
|
|
|
|
2021-08-04 15:37:44 +00:00
|
|
|
int virPCIGetVirtualFunctionsFull(const char *sysfs_path,
|
|
|
|
virPCIVirtualFunctionList **vfs,
|
2021-12-02 19:13:18 +00:00
|
|
|
const char *pfNetDevName);
|
2013-01-14 22:11:44 +00:00
|
|
|
int virPCIGetVirtualFunctions(const char *sysfs_path,
|
2021-08-03 14:45:36 +00:00
|
|
|
virPCIVirtualFunctionList **vfs);
|
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
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
int virPCIDeviceAddressGetSysfsFile(virPCIDeviceAddress *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,
|
2021-12-02 18:52:48 +00:00
|
|
|
const char *physPortNetDevName,
|
2017-07-31 04:21:45 +00:00
|
|
|
char **netname);
|
2011-08-16 04:28:48 +00:00
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
bool virPCIDeviceAddressIsValid(virPCIDeviceAddress *addr,
|
2018-09-13 14:36:25 +00:00
|
|
|
bool report);
|
|
|
|
bool virPCIDeviceAddressIsEmpty(const virPCIDeviceAddress *addr);
|
|
|
|
|
2019-06-04 08:43:40 +00:00
|
|
|
bool virPCIDeviceAddressEqual(const virPCIDeviceAddress *addr1,
|
|
|
|
const virPCIDeviceAddress *addr2);
|
2021-03-11 07:16:13 +00:00
|
|
|
void virPCIDeviceAddressCopy(virPCIDeviceAddress *dst,
|
2019-06-07 14:32:37 +00:00
|
|
|
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);
|
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
int virPCIDeviceAddressParse(char *address, virPCIDeviceAddress *bdf);
|
2013-06-17 15:57:19 +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
|
|
|
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
|
|
|
|
2021-10-20 08:30:32 +00:00
|
|
|
bool virPCIDeviceHasVPD(virPCIDevice *dev);
|
|
|
|
virPCIVPDResource * virPCIDeviceGetVPD(virPCIDevice *dev);
|
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
int virPCIDeviceUnbind(virPCIDevice *dev);
|
|
|
|
int virPCIDeviceRebind(virPCIDevice *dev);
|
|
|
|
int virPCIDeviceGetDriverPathAndName(virPCIDevice *dev,
|
2014-01-16 11:27:23 +00:00
|
|
|
char **path,
|
|
|
|
char **name);
|
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
int virPCIDeviceIsPCIExpress(virPCIDevice *dev);
|
|
|
|
int virPCIDeviceHasPCIExpressLink(virPCIDevice *dev);
|
|
|
|
int virPCIDeviceGetLinkCapSta(virPCIDevice *dev,
|
2014-05-15 08:04:28 +00:00
|
|
|
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
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
int virPCIGetHeaderType(virPCIDevice *dev, int *hdrType);
|
2016-03-15 11:22:03 +00:00
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
void virPCIEDeviceInfoFree(virPCIEDeviceInfo *dev);
|
2014-07-23 04:38:30 +00:00
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
void virPCIDeviceAddressFree(virPCIDeviceAddress *address);
|
2018-07-24 15:52:20 +00:00
|
|
|
|
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);
|