2014-05-10 16:35:24 +00:00
|
|
|
/*
|
|
|
|
* domain_addr.h: helper APIs for managing domain device addresses
|
|
|
|
*
|
conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.
The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device). Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).
With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.
2016-03-15 19:49:22 +00:00
|
|
|
* Copyright (C) 2006-2016 Red Hat, Inc.
|
2014-05-10 16:35:24 +00:00
|
|
|
* Copyright (C) 2006 Daniel P. Berrange
|
|
|
|
*
|
|
|
|
* 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
|
|
|
|
* License along with this library. If not, see
|
|
|
|
* <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
2019-06-07 20:20:16 +00:00
|
|
|
#pragma once
|
2014-05-10 16:35:24 +00:00
|
|
|
|
2019-06-07 20:20:16 +00:00
|
|
|
#include "domain_conf.h"
|
2014-05-10 16:35:24 +00:00
|
|
|
|
2019-06-07 20:20:16 +00:00
|
|
|
#define VIR_PCI_ADDRESS_SLOT_LAST 31
|
|
|
|
#define VIR_PCI_ADDRESS_FUNCTION_LAST 7
|
2014-05-10 16:35:24 +00:00
|
|
|
|
2018-11-08 11:00:21 +00:00
|
|
|
typedef enum {
|
|
|
|
VIR_PCI_ADDRESS_EXTENSION_NONE = 0, /* no extension */
|
|
|
|
VIR_PCI_ADDRESS_EXTENSION_ZPCI = 1 << 0, /* zPCI support */
|
|
|
|
} virPCIDeviceAddressExtensionFlags;
|
|
|
|
|
2014-05-10 16:35:24 +00:00
|
|
|
typedef enum {
|
conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.
The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device). Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).
With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.
2016-03-15 19:49:22 +00:00
|
|
|
VIR_PCI_CONNECT_HOTPLUGGABLE = 1 << 0, /* is hotplug needed/supported */
|
2014-05-10 16:35:24 +00:00
|
|
|
|
2016-10-19 18:15:01 +00:00
|
|
|
/* set for devices that can share a single slot in auto-assignment
|
|
|
|
* (by assigning one device to each of the 8 functions on the slot)
|
|
|
|
*/
|
|
|
|
VIR_PCI_CONNECT_AGGREGATE_SLOT = 1 << 1,
|
|
|
|
|
conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.
The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device). Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).
With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.
2016-03-15 19:49:22 +00:00
|
|
|
/* kinds of devices as a bitmap so they can be combined (some PCI
|
|
|
|
* controllers permit connecting multiple types of devices)
|
2015-06-16 19:00:44 +00:00
|
|
|
*/
|
2016-10-19 18:15:01 +00:00
|
|
|
VIR_PCI_CONNECT_TYPE_PCI_DEVICE = 1 << 2,
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_DEVICE = 1 << 3,
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_ROOT_PORT = 1 << 4,
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_SWITCH_UPSTREAM_PORT = 1 << 5,
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_SWITCH_DOWNSTREAM_PORT = 1 << 6,
|
|
|
|
VIR_PCI_CONNECT_TYPE_DMI_TO_PCI_BRIDGE = 1 << 7,
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCI_EXPANDER_BUS = 1 << 8,
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_EXPANDER_BUS = 1 << 9,
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCI_BRIDGE = 1 << 10,
|
2018-01-11 16:28:43 +00:00
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_TO_PCI_BRIDGE = 1 << 11,
|
2014-05-10 16:35:24 +00:00
|
|
|
} virDomainPCIConnectFlags;
|
|
|
|
|
conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.
The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device). Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).
With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.
2016-03-15 19:49:22 +00:00
|
|
|
/* a combination of all bits that describe the type of connections
|
|
|
|
* allowed, e.g. PCI, PCIe, switch
|
|
|
|
*/
|
2019-06-07 20:20:16 +00:00
|
|
|
#define VIR_PCI_CONNECT_TYPES_MASK \
|
conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.
The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device). Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).
With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.
2016-03-15 19:49:22 +00:00
|
|
|
(VIR_PCI_CONNECT_TYPE_PCI_DEVICE | VIR_PCI_CONNECT_TYPE_PCIE_DEVICE | \
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_SWITCH_UPSTREAM_PORT | \
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_SWITCH_DOWNSTREAM_PORT | \
|
2016-08-05 19:01:08 +00:00
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_ROOT_PORT | \
|
2016-08-06 23:03:31 +00:00
|
|
|
VIR_PCI_CONNECT_TYPE_DMI_TO_PCI_BRIDGE | \
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCI_EXPANDER_BUS | \
|
2016-08-07 21:13:58 +00:00
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_EXPANDER_BUS | \
|
2018-01-11 16:28:43 +00:00
|
|
|
VIR_PCI_CONNECT_TYPE_PCI_BRIDGE | \
|
|
|
|
VIR_PCI_CONNECT_TYPE_PCIE_TO_PCI_BRIDGE)
|
conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.
The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device). Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).
With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.
2016-03-15 19:49:22 +00:00
|
|
|
|
|
|
|
/* combination of all bits that could be used to connect a normal
|
|
|
|
* endpoint device (i.e. excluding the connection possible between an
|
|
|
|
* upstream and downstream switch port, or a PCIe root port and a PCIe
|
|
|
|
* port)
|
|
|
|
*/
|
2019-06-07 20:20:16 +00:00
|
|
|
#define VIR_PCI_CONNECT_TYPES_ENDPOINT \
|
conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.
The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device). Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).
With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.
2016-03-15 19:49:22 +00:00
|
|
|
(VIR_PCI_CONNECT_TYPE_PCI_DEVICE | VIR_PCI_CONNECT_TYPE_PCIE_DEVICE)
|
|
|
|
|
2016-03-16 18:20:52 +00:00
|
|
|
virDomainPCIConnectFlags
|
|
|
|
virDomainPCIControllerModelToConnectType(virDomainControllerModelPCI model);
|
|
|
|
|
2016-10-16 21:14:25 +00:00
|
|
|
typedef struct {
|
|
|
|
/* each function is represented by one bit, set if that function is
|
|
|
|
* in use by a device, or clear if it isn't.
|
|
|
|
*/
|
|
|
|
uint8_t functions;
|
2016-10-19 18:15:01 +00:00
|
|
|
|
|
|
|
/* aggregate is true if this slot has only devices with
|
|
|
|
* VIR_PCI_CONNECT_AGGREGATE assigned to its functions (meaning
|
|
|
|
* that other devices with the same flags could also be
|
|
|
|
* auto-assigned to the other functions)
|
|
|
|
*/
|
|
|
|
bool aggregate;
|
2016-10-16 21:14:25 +00:00
|
|
|
} virDomainPCIAddressSlot;
|
|
|
|
|
2014-05-10 16:35:24 +00:00
|
|
|
typedef struct {
|
|
|
|
virDomainControllerModelPCI model;
|
conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.
The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device). Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).
With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.
2016-03-15 19:49:22 +00:00
|
|
|
/* flags and min/max can be computed from model, but
|
2014-05-10 16:35:24 +00:00
|
|
|
* having them ready makes life easier.
|
|
|
|
*/
|
|
|
|
virDomainPCIConnectFlags flags;
|
conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.
The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device). Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).
With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.
2016-03-15 19:49:22 +00:00
|
|
|
size_t minSlot, maxSlot; /* usually 0,0 or 0,31, or 1,31 */
|
2014-05-10 16:35:24 +00:00
|
|
|
/* Each bit in a slot represents one function on that slot. If the
|
|
|
|
* bit is set, that function is in use by a device.
|
|
|
|
*/
|
2016-10-16 21:14:25 +00:00
|
|
|
virDomainPCIAddressSlot slot[VIR_PCI_ADDRESS_SLOT_LAST + 1];
|
2017-06-15 08:38:33 +00:00
|
|
|
|
|
|
|
/* See virDomainDeviceInfo::isolationGroup */
|
|
|
|
unsigned int isolationGroup;
|
|
|
|
|
|
|
|
/* See virDomainDeviceInfo::isolationGroupLocked */
|
|
|
|
bool isolationGroupLocked;
|
2014-05-10 16:35:24 +00:00
|
|
|
} virDomainPCIAddressBus;
|
|
|
|
typedef virDomainPCIAddressBus *virDomainPCIAddressBusPtr;
|
|
|
|
|
2018-11-08 11:00:24 +00:00
|
|
|
typedef struct {
|
|
|
|
virHashTablePtr uids;
|
|
|
|
virHashTablePtr fids;
|
|
|
|
} virDomainZPCIAddressIds;
|
|
|
|
typedef virDomainZPCIAddressIds *virDomainZPCIAddressIdsPtr;
|
|
|
|
|
2014-05-10 16:35:24 +00:00
|
|
|
struct _virDomainPCIAddressSet {
|
|
|
|
virDomainPCIAddressBus *buses;
|
|
|
|
size_t nbuses;
|
|
|
|
bool dryRun; /* on a dry run, new buses are auto-added
|
|
|
|
and addresses aren't saved in device infos */
|
2017-05-29 15:18:35 +00:00
|
|
|
/* If true, the guest can have multiple pci-root controllers */
|
2018-03-28 10:28:38 +00:00
|
|
|
bool areMultipleRootsSupported;
|
2018-03-23 17:52:22 +00:00
|
|
|
/* If true, the guest can use the pcie-to-pci-bridge controller */
|
|
|
|
bool isPCIeToPCIBridgeSupported;
|
2018-11-08 11:00:24 +00:00
|
|
|
virDomainZPCIAddressIdsPtr zpciIds;
|
2014-05-10 16:35:24 +00:00
|
|
|
};
|
|
|
|
typedef struct _virDomainPCIAddressSet virDomainPCIAddressSet;
|
|
|
|
typedef virDomainPCIAddressSet *virDomainPCIAddressSetPtr;
|
|
|
|
|
2018-11-08 11:00:24 +00:00
|
|
|
virDomainPCIAddressSetPtr virDomainPCIAddressSetAlloc(unsigned int nbuses,
|
|
|
|
virPCIDeviceAddressExtensionFlags extFlags);
|
2014-05-13 16:10:40 +00:00
|
|
|
|
|
|
|
void virDomainPCIAddressSetFree(virDomainPCIAddressSetPtr addrs);
|
|
|
|
|
|
|
|
bool virDomainPCIAddressValidate(virDomainPCIAddressSetPtr addrs,
|
2016-04-03 18:16:51 +00:00
|
|
|
virPCIDeviceAddressPtr addr,
|
2014-05-13 16:10:40 +00:00
|
|
|
const char *addrStr,
|
|
|
|
virDomainPCIConnectFlags flags,
|
|
|
|
bool fromConfig)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3);
|
|
|
|
|
|
|
|
|
|
|
|
int virDomainPCIAddressBusSetModel(virDomainPCIAddressBusPtr bus,
|
|
|
|
virDomainControllerModelPCI model)
|
|
|
|
ATTRIBUTE_NONNULL(1);
|
|
|
|
|
2017-06-29 14:13:02 +00:00
|
|
|
bool virDomainPCIAddressBusIsFullyReserved(virDomainPCIAddressBusPtr bus)
|
|
|
|
ATTRIBUTE_NONNULL(1);
|
|
|
|
|
2014-05-13 16:10:40 +00:00
|
|
|
bool virDomainPCIAddressSlotInUse(virDomainPCIAddressSetPtr addrs,
|
2016-04-03 18:16:51 +00:00
|
|
|
virPCIDeviceAddressPtr addr)
|
2014-05-13 16:10:40 +00:00
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
2018-11-08 11:00:28 +00:00
|
|
|
int virDomainPCIAddressExtensionReserveAddr(virDomainPCIAddressSetPtr addrs,
|
|
|
|
virPCIDeviceAddressPtr addr)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
|
|
|
int virDomainPCIAddressExtensionReserveNextAddr(virDomainPCIAddressSetPtr addrs,
|
|
|
|
virPCIDeviceAddressPtr addr)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
2016-10-23 16:14:16 +00:00
|
|
|
int virDomainPCIAddressReserveAddr(virDomainPCIAddressSetPtr addrs,
|
2016-04-03 18:16:51 +00:00
|
|
|
virPCIDeviceAddressPtr addr,
|
2017-06-15 08:38:33 +00:00
|
|
|
virDomainPCIConnectFlags flags,
|
|
|
|
unsigned int isolationGroup)
|
2014-05-13 16:10:40 +00:00
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
2017-05-29 12:05:54 +00:00
|
|
|
int virDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
|
|
|
|
virDomainDeviceInfoPtr dev,
|
|
|
|
virDomainPCIConnectFlags flags,
|
|
|
|
int function)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
2014-05-13 16:10:40 +00:00
|
|
|
int virDomainPCIAddressEnsureAddr(virDomainPCIAddressSetPtr addrs,
|
2016-09-07 16:29:30 +00:00
|
|
|
virDomainDeviceInfoPtr dev,
|
|
|
|
virDomainPCIConnectFlags flags)
|
2014-05-13 16:10:40 +00:00
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
2017-10-18 14:12:53 +00:00
|
|
|
void virDomainPCIAddressReleaseAddr(virDomainPCIAddressSetPtr addrs,
|
|
|
|
virPCIDeviceAddressPtr addr)
|
2014-05-13 16:10:40 +00:00
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
2018-11-08 11:00:28 +00:00
|
|
|
void virDomainPCIAddressExtensionReleaseAddr(virDomainPCIAddressSetPtr addrs,
|
|
|
|
virPCIDeviceAddressPtr addr)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
2017-01-10 05:02:40 +00:00
|
|
|
void virDomainPCIAddressSetAllMulti(virDomainDefPtr def)
|
|
|
|
ATTRIBUTE_NONNULL(1);
|
|
|
|
|
2014-06-17 14:17:41 +00:00
|
|
|
struct _virDomainCCWAddressSet {
|
|
|
|
virHashTablePtr defined;
|
|
|
|
virDomainDeviceCCWAddress next;
|
|
|
|
};
|
|
|
|
typedef struct _virDomainCCWAddressSet virDomainCCWAddressSet;
|
|
|
|
typedef virDomainCCWAddressSet *virDomainCCWAddressSetPtr;
|
|
|
|
|
|
|
|
int virDomainCCWAddressAssign(virDomainDeviceInfoPtr dev,
|
|
|
|
virDomainCCWAddressSetPtr addrs,
|
|
|
|
bool autoassign)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
void virDomainCCWAddressSetFree(virDomainCCWAddressSetPtr addrs);
|
2015-03-02 09:57:51 +00:00
|
|
|
|
2018-07-03 15:25:28 +00:00
|
|
|
virDomainCCWAddressSetPtr
|
|
|
|
virDomainCCWAddressSetCreateFromDomain(virDomainDefPtr def)
|
|
|
|
ATTRIBUTE_NONNULL(1);
|
|
|
|
|
2015-03-02 09:57:51 +00:00
|
|
|
struct _virDomainVirtioSerialController {
|
|
|
|
unsigned int idx;
|
|
|
|
virBitmapPtr ports;
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef struct _virDomainVirtioSerialController virDomainVirtioSerialController;
|
|
|
|
typedef virDomainVirtioSerialController *virDomainVirtioSerialControllerPtr;
|
|
|
|
|
|
|
|
struct _virDomainVirtioSerialAddrSet {
|
|
|
|
virDomainVirtioSerialControllerPtr *controllers;
|
|
|
|
size_t ncontrollers;
|
|
|
|
};
|
|
|
|
typedef struct _virDomainVirtioSerialAddrSet virDomainVirtioSerialAddrSet;
|
|
|
|
typedef virDomainVirtioSerialAddrSet *virDomainVirtioSerialAddrSetPtr;
|
|
|
|
|
|
|
|
void
|
|
|
|
virDomainVirtioSerialAddrSetFree(virDomainVirtioSerialAddrSetPtr addrs);
|
2016-07-23 01:47:06 +00:00
|
|
|
virDomainVirtioSerialAddrSetPtr
|
|
|
|
virDomainVirtioSerialAddrSetCreateFromDomain(virDomainDefPtr def)
|
|
|
|
ATTRIBUTE_NONNULL(1);
|
2015-03-02 09:57:51 +00:00
|
|
|
bool
|
|
|
|
virDomainVirtioSerialAddrIsComplete(virDomainDeviceInfoPtr info);
|
|
|
|
int
|
2016-10-21 10:58:54 +00:00
|
|
|
virDomainVirtioSerialAddrAutoAssignFromCache(virDomainDefPtr def,
|
|
|
|
virDomainVirtioSerialAddrSetPtr addrs,
|
|
|
|
virDomainDeviceInfoPtr info,
|
|
|
|
bool allowZero)
|
2015-03-24 14:23:46 +00:00
|
|
|
ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3);
|
2015-03-02 09:57:51 +00:00
|
|
|
|
2016-10-21 11:09:36 +00:00
|
|
|
int
|
|
|
|
virDomainVirtioSerialAddrAutoAssign(virDomainDefPtr def,
|
|
|
|
virDomainDeviceInfoPtr info,
|
|
|
|
bool allowZero)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
2015-08-12 14:52:13 +00:00
|
|
|
bool
|
|
|
|
virDomainUSBAddressPortIsValid(unsigned int *port)
|
|
|
|
ATTRIBUTE_NONNULL(1);
|
|
|
|
|
|
|
|
void
|
|
|
|
virDomainUSBAddressPortFormatBuf(virBufferPtr buf,
|
|
|
|
unsigned int *port)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
2019-06-07 20:20:16 +00:00
|
|
|
#define VIR_DOMAIN_USB_HUB_PORTS 8
|
2017-01-27 12:58:15 +00:00
|
|
|
|
2015-08-12 14:52:15 +00:00
|
|
|
typedef struct _virDomainUSBAddressHub virDomainUSBAddressHub;
|
|
|
|
typedef virDomainUSBAddressHub *virDomainUSBAddressHubPtr;
|
|
|
|
struct _virDomainUSBAddressHub {
|
|
|
|
/* indexes are shifted by one:
|
|
|
|
* ports[0] represents port 1, because ports are numbered from 1 */
|
|
|
|
virBitmapPtr portmap;
|
|
|
|
size_t nports;
|
|
|
|
virDomainUSBAddressHubPtr *ports;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct _virDomainUSBAddressSet {
|
|
|
|
/* every <controller type='usb' index='i'> is represented
|
|
|
|
* as a hub at buses[i] */
|
|
|
|
virDomainUSBAddressHubPtr *buses;
|
|
|
|
size_t nbuses;
|
|
|
|
};
|
|
|
|
typedef struct _virDomainUSBAddressSet virDomainUSBAddressSet;
|
|
|
|
typedef virDomainUSBAddressSet *virDomainUSBAddressSetPtr;
|
|
|
|
|
|
|
|
virDomainUSBAddressSetPtr virDomainUSBAddressSetCreate(void);
|
2015-08-12 14:52:16 +00:00
|
|
|
|
|
|
|
int virDomainUSBAddressSetAddControllers(virDomainUSBAddressSetPtr addrs,
|
|
|
|
virDomainDefPtr def)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
2015-08-12 14:52:18 +00:00
|
|
|
int
|
|
|
|
virDomainUSBAddressSetAddHub(virDomainUSBAddressSetPtr addrs,
|
|
|
|
virDomainHubDefPtr hub)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
2016-06-17 07:49:54 +00:00
|
|
|
size_t
|
|
|
|
virDomainUSBAddressCountAllPorts(virDomainDefPtr def);
|
2015-08-12 14:52:15 +00:00
|
|
|
void virDomainUSBAddressSetFree(virDomainUSBAddressSetPtr addrs);
|
|
|
|
|
2016-10-21 11:09:04 +00:00
|
|
|
int
|
|
|
|
virDomainUSBAddressPresent(virDomainDeviceInfoPtr info,
|
|
|
|
void *data)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
2015-08-12 14:52:17 +00:00
|
|
|
int
|
|
|
|
virDomainUSBAddressReserve(virDomainDeviceInfoPtr info,
|
|
|
|
void *data)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
2015-08-12 14:52:18 +00:00
|
|
|
|
|
|
|
int
|
|
|
|
virDomainUSBAddressAssign(virDomainUSBAddressSetPtr addrs,
|
|
|
|
virDomainDeviceInfoPtr info)
|
|
|
|
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
|
|
|
|
|
|
|
|
int
|
|
|
|
virDomainUSBAddressEnsure(virDomainUSBAddressSetPtr addrs,
|
|
|
|
virDomainDeviceInfoPtr info)
|
2017-10-20 11:28:21 +00:00
|
|
|
ATTRIBUTE_NONNULL(2);
|
2015-08-12 14:52:19 +00:00
|
|
|
|
|
|
|
int
|
|
|
|
virDomainUSBAddressRelease(virDomainUSBAddressSetPtr addrs,
|
|
|
|
virDomainDeviceInfoPtr info)
|
2017-10-20 11:24:49 +00:00
|
|
|
ATTRIBUTE_NONNULL(2);
|