External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-10-07 06:45:45 +00:00
Code Issues Packages Projects Releases Wiki Activity
ae01530cb4
libvirt/src/conf/domain_addr.h

333 lines
13 KiB
C
Raw Normal View History

qemu: extract PCI handling structs Introduce new files (domain_addr.[ch]) to provide an API for domain device handling that could be shared across the drivers. A list of data types were extracted and moved there: qemuDomainPCIAddressBus -> virDomainPCIAddressBus qemuDomainPCIAddressBusPtr -> virDomainPCIAddressBusPtr _qemuDomainPCIAddressSet -> virDomainPCIAddressSet qemuDomainPCIAddressSetPtr -> virDomainPCIAddressSetPtr qemuDomainPCIConnectFlags -> virDomainPCIConnectFlags Also, move the related definitions and macros.
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.
qemu: extract PCI handling structs Introduce new files (domain_addr.[ch]) to provide an API for domain device handling that could be shared across the drivers. A list of data types were extracted and moved there: qemuDomainPCIAddressBus -> virDomainPCIAddressBus qemuDomainPCIAddressBusPtr -> virDomainPCIAddressBusPtr _qemuDomainPCIAddressSet -> virDomainPCIAddressSet qemuDomainPCIAddressSetPtr -> virDomainPCIAddressSetPtr qemuDomainPCIConnectFlags -> virDomainPCIConnectFlags Also, move the related definitions and macros.
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/>.
*
* Author: Daniel P. Berrange <berrange@redhat.com>
*/
#ifndef __DOMAIN_ADDR_H__
# define __DOMAIN_ADDR_H__
# include "domain_conf.h"
# define VIR_PCI_ADDRESS_SLOT_LAST 31
# define VIR_PCI_ADDRESS_FUNCTION_LAST 7
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 */
qemu: extract PCI handling structs Introduce new files (domain_addr.[ch]) to provide an API for domain device handling that could be shared across the drivers. A list of data types were extracted and moved there: qemuDomainPCIAddressBus -> virDomainPCIAddressBus qemuDomainPCIAddressBusPtr -> virDomainPCIAddressBusPtr _qemuDomainPCIAddressSet -> virDomainPCIAddressSet qemuDomainPCIAddressSetPtr -> virDomainPCIAddressSetPtr qemuDomainPCIConnectFlags -> virDomainPCIConnectFlags Also, move the related definitions and macros.
2014-05-10 16:35:24 +00:00
conf: aggregate multiple devices on a slot when assigning PCI addresses If a PCI device has VIR_PCI_CONNECT_AGGREGATE_SLOT set in its pciConnectFlags, then during address assignment we allow multiple instances of this type of device to be auto-assigned to multiple functions on the same device. A slot is used for aggregating multiple devices only if the first device assigned to that slot had VIR_PCI_CONNECT_AGGREGATE_SLOT set. but any device types that have AGGREGATE_SLOT set might be mix/matched on the same slot. (NB: libvirt should never set the AGGREGATE_SLOT flag for a device type that might need to be hotplugged. Currently it is only planned for pcie-root-port and possibly other PCI controller types, and none of those are hotpluggable anyway) There aren't yet any devices that use this flag. That will be in a later patch.
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)
conf: new pci controller model "pcie-switch-upstream-port" This controller can be connected only to a pcie-root-port or a pcie-switch-downstream-port (which will be added in a later patch), which is the reason for the new connect type VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides 32 ports (slot=0 to slot=31) on the downstream side, which can only have pci controllers of model "pcie-switch-downstream-port" plugged into them, which is the reason for the other new connect type VIR_PCI_CONNECT_TYPE_PCIE_SWITCH.
2015-06-16 19:00:44 +00:00
*/
conf: aggregate multiple devices on a slot when assigning PCI addresses If a PCI device has VIR_PCI_CONNECT_AGGREGATE_SLOT set in its pciConnectFlags, then during address assignment we allow multiple instances of this type of device to be auto-assigned to multiple functions on the same device. A slot is used for aggregating multiple devices only if the first device assigned to that slot had VIR_PCI_CONNECT_AGGREGATE_SLOT set. but any device types that have AGGREGATE_SLOT set might be mix/matched on the same slot. (NB: libvirt should never set the AGGREGATE_SLOT flag for a device type that might need to be hotplugged. Currently it is only planned for pcie-root-port and possibly other PCI controller types, and none of those are hotpluggable anyway) There aren't yet any devices that use this flag. That will be in a later patch.
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,
qemu: extract PCI handling structs Introduce new files (domain_addr.[ch]) to provide an API for domain device handling that could be shared across the drivers. A list of data types were extracted and moved there: qemuDomainPCIAddressBus -> virDomainPCIAddressBus qemuDomainPCIAddressBusPtr -> virDomainPCIAddressBusPtr _qemuDomainPCIAddressSet -> virDomainPCIAddressSet qemuDomainPCIAddressSetPtr -> virDomainPCIAddressSetPtr qemuDomainPCIConnectFlags -> virDomainPCIConnectFlags Also, move the related definitions and macros.
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
*/
# define VIR_PCI_CONNECT_TYPES_MASK \
(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 | \
conf: restrict where dmi-to-pci-bridge can be connected libvirt had allowed a dmi-to-pci-bridge to be plugged in anywhere a normal PCIe endpoint can be connected, but this is wrong - it will only work if it's plugged into pcie-root (the PCIe root complex) or a pcie-expander-bus (the qemu device pxb-pcie). This patch adjusts the connection flags accordingly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363648
2016-08-05 19:01:08 +00:00
VIR_PCI_CONNECT_TYPE_PCIE_ROOT_PORT | \
conf: restrict expander buses to connect only to a root bus More misunderstanding/mistaken assumptions on my part - I had thought that a pci-expander-bus could be plugged into any legacy PCI slot, and that pcie-expander-bus could be plugged into any PCIe slot. This isn't correct - they can both be plugged ontly into their respective root buses. This patch adds that restriction. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358712
2016-08-06 23:03:31 +00:00
VIR_PCI_CONNECT_TYPE_DMI_TO_PCI_BRIDGE | \
VIR_PCI_CONNECT_TYPE_PCI_EXPANDER_BUS | \
conf: restrict what type of buses will accept a pci-bridge A pci-bridge has *almost* the same rules as a legacy PCI endpoint device for where it can be automatically connected, and until now both had been considered identical. There is one pairing that is okay when specifically requested by the user (i.e. manual assignment), but we want to avoid it when auto-assigning addresses - plugging a pci-bridge directly into pcie-root (it is cleaner to plug in a dmi-to-pci-bridge, then plug the pci-bridge into that). In order to allow that difference, this patch makes a separate CONNECT_TYPE for pci-bridge, and uses it to restrict auto-assigned addresses for pci-bridges to be only on pci-root, pci-expander-bus, dmi-to-pci-bridge, or on another pci-bridge. NB: As with other discouraged-but-seem-to-work configurations (e.g. plugging a legacy PCI device into a pcie-root-port) if someone *really* wants to, they can still force a pci-bridge to be plugged into pcie-root (by manually specifying its PCI address.)
2016-08-07 21:13:58 +00:00
VIR_PCI_CONNECT_TYPE_PCIE_EXPANDER_BUS | \
VIR_PCI_CONNECT_TYPE_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)
*/
# define VIR_PCI_CONNECT_TYPES_ENDPOINT \
(VIR_PCI_CONNECT_TYPE_PCI_DEVICE | VIR_PCI_CONNECT_TYPE_PCIE_DEVICE)
conf: utility function to convert PCI controller model into connect type There are two places in qemu_domain_address.c where we have a switch statement to convert PCI controller models (VIR_DOMAIN_CONTROLLER_MODEL_PCI*) into the connection type flag that is matched when looking for an upstream connection for that model of controller (VIR_PCI_CONNECT_TYPE_*). This patch makes a utility function in conf/domain_addr.c to do that, so that when a new PCI controller is added, we only need to add the new model-->connect-type in a single place.
2016-03-16 18:20:52 +00:00
virDomainPCIConnectFlags
virDomainPCIControllerModelToConnectType(virDomainControllerModelPCI model);
conf: use struct instead of int for each slot in virDomainPCIAddressBus When keeping track of which functions of which slots are allocated, we will need to have more information than just the current bitmap with a bit for each function that is currently stored for each slot in a virDomainPCIAddressBus. To prepare for adding more per-slot info, this patch changes "uint8_t slots" into "virDomainPCIAddressSlot slot", which currently has a single member named "functions" that serves the same purpose previously served directly by "slots".
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;
conf: aggregate multiple devices on a slot when assigning PCI addresses If a PCI device has VIR_PCI_CONNECT_AGGREGATE_SLOT set in its pciConnectFlags, then during address assignment we allow multiple instances of this type of device to be auto-assigned to multiple functions on the same device. A slot is used for aggregating multiple devices only if the first device assigned to that slot had VIR_PCI_CONNECT_AGGREGATE_SLOT set. but any device types that have AGGREGATE_SLOT set might be mix/matched on the same slot. (NB: libvirt should never set the AGGREGATE_SLOT flag for a device type that might need to be hotplugged. Currently it is only planned for pcie-root-port and possibly other PCI controller types, and none of those are hotpluggable anyway) There aren't yet any devices that use this flag. That will be in a later patch.
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;
conf: use struct instead of int for each slot in virDomainPCIAddressBus When keeping track of which functions of which slots are allocated, we will need to have more information than just the current bitmap with a bit for each function that is currently stored for each slot in a virDomainPCIAddressBus. To prepare for adding more per-slot info, this patch changes "uint8_t slots" into "virDomainPCIAddressSlot slot", which currently has a single member named "functions" that serves the same purpose previously served directly by "slots".
2016-10-16 21:14:25 +00:00
} virDomainPCIAddressSlot;
qemu: extract PCI handling structs Introduce new files (domain_addr.[ch]) to provide an API for domain device handling that could be shared across the drivers. A list of data types were extracted and moved there: qemuDomainPCIAddressBus -> virDomainPCIAddressBus qemuDomainPCIAddressBusPtr -> virDomainPCIAddressBusPtr _qemuDomainPCIAddressSet -> virDomainPCIAddressSet qemuDomainPCIAddressSetPtr -> virDomainPCIAddressSetPtr qemuDomainPCIConnectFlags -> virDomainPCIConnectFlags Also, move the related definitions and macros.
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
qemu: extract PCI handling structs Introduce new files (domain_addr.[ch]) to provide an API for domain device handling that could be shared across the drivers. A list of data types were extracted and moved there: qemuDomainPCIAddressBus -> virDomainPCIAddressBus qemuDomainPCIAddressBusPtr -> virDomainPCIAddressBusPtr _qemuDomainPCIAddressSet -> virDomainPCIAddressSet qemuDomainPCIAddressSetPtr -> virDomainPCIAddressSetPtr qemuDomainPCIConnectFlags -> virDomainPCIConnectFlags Also, move the related definitions and macros.
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 */
qemu: extract PCI handling structs Introduce new files (domain_addr.[ch]) to provide an API for domain device handling that could be shared across the drivers. A list of data types were extracted and moved there: qemuDomainPCIAddressBus -> virDomainPCIAddressBus qemuDomainPCIAddressBusPtr -> virDomainPCIAddressBusPtr _qemuDomainPCIAddressSet -> virDomainPCIAddressSet qemuDomainPCIAddressSetPtr -> virDomainPCIAddressSetPtr qemuDomainPCIConnectFlags -> virDomainPCIConnectFlags Also, move the related definitions and macros.
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.
*/
conf: use struct instead of int for each slot in virDomainPCIAddressBus When keeping track of which functions of which slots are allocated, we will need to have more information than just the current bitmap with a bit for each function that is currently stored for each slot in a virDomainPCIAddressBus. To prepare for adding more per-slot info, this patch changes "uint8_t slots" into "virDomainPCIAddressSlot slot", which currently has a single member named "functions" that serves the same purpose previously served directly by "slots".
2016-10-16 21:14:25 +00:00
virDomainPCIAddressSlot slot[VIR_PCI_ADDRESS_SLOT_LAST + 1];
qemu: extract PCI handling structs Introduce new files (domain_addr.[ch]) to provide an API for domain device handling that could be shared across the drivers. A list of data types were extracted and moved there: qemuDomainPCIAddressBus -> virDomainPCIAddressBus qemuDomainPCIAddressBusPtr -> virDomainPCIAddressBusPtr _qemuDomainPCIAddressSet -> virDomainPCIAddressSet qemuDomainPCIAddressSetPtr -> virDomainPCIAddressSetPtr qemuDomainPCIConnectFlags -> virDomainPCIConnectFlags Also, move the related definitions and macros.
2014-05-10 16:35:24 +00:00
} virDomainPCIAddressBus;
typedef virDomainPCIAddressBus *virDomainPCIAddressBusPtr;
struct _virDomainPCIAddressSet {
virDomainPCIAddressBus *buses;
size_t nbuses;
Change virDevicePCIAddress to virPCIDeviceAddress 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: Martin Kletzander <mkletzan@redhat.com>
2016-04-03 18:16:51 +00:00
virPCIDeviceAddress lastaddr;
qemu: extract PCI handling structs Introduce new files (domain_addr.[ch]) to provide an API for domain device handling that could be shared across the drivers. A list of data types were extracted and moved there: qemuDomainPCIAddressBus -> virDomainPCIAddressBus qemuDomainPCIAddressBusPtr -> virDomainPCIAddressBusPtr _qemuDomainPCIAddressSet -> virDomainPCIAddressSet qemuDomainPCIAddressSetPtr -> virDomainPCIAddressSetPtr qemuDomainPCIConnectFlags -> virDomainPCIConnectFlags Also, move the related definitions and macros.
2014-05-10 16:35:24 +00:00
virDomainPCIConnectFlags lastFlags;
bool dryRun; /* on a dry run, new buses are auto-added
and addresses aren't saved in device infos */
};
typedef struct _virDomainPCIAddressSet virDomainPCIAddressSet;
typedef virDomainPCIAddressSet *virDomainPCIAddressSetPtr;
Change virDevicePCIAddress to virPCIDeviceAddress 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: Martin Kletzander <mkletzan@redhat.com>
2016-04-03 18:16:51 +00:00
char *virDomainPCIAddressAsString(virPCIDeviceAddressPtr addr)
qemu: extract common PCI handling functions Move sharable PCI handling functions to domain_addr.[ch], and change theirs prefix from 'qemu' to 'vir': - virDomainPCIAddressAsString; - virDomainPCIAddressBusSetModel; - virDomainPCIAddressEnsureAddr; - virDomainPCIAddressFlagsCompatible; - virDomainPCIAddressGetNextSlot; - virDomainPCIAddressReleaseSlot; - virDomainPCIAddressReserveAddr; - virDomainPCIAddressReserveNextSlot; - virDomainPCIAddressReserveSlot; - virDomainPCIAddressSetFree; - virDomainPCIAddressSetGrow; - virDomainPCIAddressSlotInUse; - virDomainPCIAddressValidate; The only change here is function names, the implementation itself stays untouched. Extract common allocation code from DomainPCIAddressSetCreate into virDomainPCIAddressSetAlloc.
2014-05-13 16:10:40 +00:00
ATTRIBUTE_NONNULL(1);
virDomainPCIAddressSetPtr virDomainPCIAddressSetAlloc(unsigned int nbuses);
void virDomainPCIAddressSetFree(virDomainPCIAddressSetPtr addrs);
Change virDevicePCIAddress to virPCIDeviceAddress 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: Martin Kletzander <mkletzan@redhat.com>
2016-04-03 18:16:51 +00:00
bool virDomainPCIAddressFlagsCompatible(virPCIDeviceAddressPtr addr,
qemu: extract common PCI handling functions Move sharable PCI handling functions to domain_addr.[ch], and change theirs prefix from 'qemu' to 'vir': - virDomainPCIAddressAsString; - virDomainPCIAddressBusSetModel; - virDomainPCIAddressEnsureAddr; - virDomainPCIAddressFlagsCompatible; - virDomainPCIAddressGetNextSlot; - virDomainPCIAddressReleaseSlot; - virDomainPCIAddressReserveAddr; - virDomainPCIAddressReserveNextSlot; - virDomainPCIAddressReserveSlot; - virDomainPCIAddressSetFree; - virDomainPCIAddressSetGrow; - virDomainPCIAddressSlotInUse; - virDomainPCIAddressValidate; The only change here is function names, the implementation itself stays untouched. Extract common allocation code from DomainPCIAddressSetCreate into virDomainPCIAddressSetAlloc.
2014-05-13 16:10:40 +00:00
const char *addrStr,
virDomainPCIConnectFlags busFlags,
virDomainPCIConnectFlags devFlags,
bool reportError,
bool fromConfig)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
bool virDomainPCIAddressValidate(virDomainPCIAddressSetPtr addrs,
Change virDevicePCIAddress to virPCIDeviceAddress 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: Martin Kletzander <mkletzan@redhat.com>
2016-04-03 18:16:51 +00:00
virPCIDeviceAddressPtr addr,
qemu: extract common PCI handling functions Move sharable PCI handling functions to domain_addr.[ch], and change theirs prefix from 'qemu' to 'vir': - virDomainPCIAddressAsString; - virDomainPCIAddressBusSetModel; - virDomainPCIAddressEnsureAddr; - virDomainPCIAddressFlagsCompatible; - virDomainPCIAddressGetNextSlot; - virDomainPCIAddressReleaseSlot; - virDomainPCIAddressReserveAddr; - virDomainPCIAddressReserveNextSlot; - virDomainPCIAddressReserveSlot; - virDomainPCIAddressSetFree; - virDomainPCIAddressSetGrow; - virDomainPCIAddressSlotInUse; - virDomainPCIAddressValidate; The only change here is function names, the implementation itself stays untouched. Extract common allocation code from DomainPCIAddressSetCreate into virDomainPCIAddressSetAlloc.
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);
bool virDomainPCIAddressSlotInUse(virDomainPCIAddressSetPtr addrs,
Change virDevicePCIAddress to virPCIDeviceAddress 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: Martin Kletzander <mkletzan@redhat.com>
2016-04-03 18:16:51 +00:00
virPCIDeviceAddressPtr addr)
qemu: extract common PCI handling functions Move sharable PCI handling functions to domain_addr.[ch], and change theirs prefix from 'qemu' to 'vir': - virDomainPCIAddressAsString; - virDomainPCIAddressBusSetModel; - virDomainPCIAddressEnsureAddr; - virDomainPCIAddressFlagsCompatible; - virDomainPCIAddressGetNextSlot; - virDomainPCIAddressReleaseSlot; - virDomainPCIAddressReserveAddr; - virDomainPCIAddressReserveNextSlot; - virDomainPCIAddressReserveSlot; - virDomainPCIAddressSetFree; - virDomainPCIAddressSetGrow; - virDomainPCIAddressSlotInUse; - virDomainPCIAddressValidate; The only change here is function names, the implementation itself stays untouched. Extract common allocation code from DomainPCIAddressSetCreate into virDomainPCIAddressSetAlloc.
2014-05-13 16:10:40 +00:00
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
int virDomainPCIAddressSetGrow(virDomainPCIAddressSetPtr addrs,
Change virDevicePCIAddress to virPCIDeviceAddress 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: Martin Kletzander <mkletzan@redhat.com>
2016-04-03 18:16:51 +00:00
virPCIDeviceAddressPtr addr,
qemu: extract common PCI handling functions Move sharable PCI handling functions to domain_addr.[ch], and change theirs prefix from 'qemu' to 'vir': - virDomainPCIAddressAsString; - virDomainPCIAddressBusSetModel; - virDomainPCIAddressEnsureAddr; - virDomainPCIAddressFlagsCompatible; - virDomainPCIAddressGetNextSlot; - virDomainPCIAddressReleaseSlot; - virDomainPCIAddressReserveAddr; - virDomainPCIAddressReserveNextSlot; - virDomainPCIAddressReserveSlot; - virDomainPCIAddressSetFree; - virDomainPCIAddressSetGrow; - virDomainPCIAddressSlotInUse; - virDomainPCIAddressValidate; The only change here is function names, the implementation itself stays untouched. Extract common allocation code from DomainPCIAddressSetCreate into virDomainPCIAddressSetAlloc.
2014-05-13 16:10:40 +00:00
virDomainPCIConnectFlags flags)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
conf: rename virDomainPCIAddressReserveSlot() to ...Addr() This function doesn't actually reserve an entire slot any more, it reserves a single PCI address, so this name is more appropriate.
2016-10-23 16:14:16 +00:00
int virDomainPCIAddressReserveAddr(virDomainPCIAddressSetPtr addrs,
Change virDevicePCIAddress to virPCIDeviceAddress 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: Martin Kletzander <mkletzan@redhat.com>
2016-04-03 18:16:51 +00:00
virPCIDeviceAddressPtr addr,
qemu: extract common PCI handling functions Move sharable PCI handling functions to domain_addr.[ch], and change theirs prefix from 'qemu' to 'vir': - virDomainPCIAddressAsString; - virDomainPCIAddressBusSetModel; - virDomainPCIAddressEnsureAddr; - virDomainPCIAddressFlagsCompatible; - virDomainPCIAddressGetNextSlot; - virDomainPCIAddressReleaseSlot; - virDomainPCIAddressReserveAddr; - virDomainPCIAddressReserveNextSlot; - virDomainPCIAddressReserveSlot; - virDomainPCIAddressSetFree; - virDomainPCIAddressSetGrow; - virDomainPCIAddressSlotInUse; - virDomainPCIAddressValidate; The only change here is function names, the implementation itself stays untouched. Extract common allocation code from DomainPCIAddressSetCreate into virDomainPCIAddressSetAlloc.
2014-05-13 16:10:40 +00:00
virDomainPCIConnectFlags flags)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
int virDomainPCIAddressEnsureAddr(virDomainPCIAddressSetPtr addrs,
qemu: set/use proper pciConnectFlags during hotplug Before now, all the qemu hotplug functions assumed that all devices to be hotplugged were legacy PCI endpoint devices (VIR_PCI_CONNECT_TYPE_PCI_DEVICE). This worked out "okay", because all devices *are* legacy PCI endpoint devices on x86/440fx machinetypes, and hotplug didn't work properly on machinetypes using PCIe anyway (hotplugging onto a legacy PCI slot doesn't work, and until commit b87703cf any attempt to manually specify a PCIe address for a hotplugged device would be erroneously rejected). This patch makes all qemu hotplug operations honor the pciConnectFlags set by the single all-knowing function qemuDomainDeviceCalculatePCIConnectFlags(). This is done in 3 steps, but in a single commit since we would have to touch the other points at each step anyway: 1) add a flags argument to the hypervisor-agnostic virDomainPCIAddressEnsureAddr() (previously it hardcoded ..._PCI_DEVICE) 2) add a new qemu-specific function qemuDomainEnsurePCIAddress() which gets the correct pciConnectFlags for the device from qemuDomainDeviceConnectFlags(), then calls virDomainPCIAddressEnsureAddr(). 3) in qemu_hotplug.c replace all calls to virDomainPCIAddressEnsureAddr() with calls to qemuDomainEnsurePCIAddress() So in effect, we're putting a "shim" on top of all calls to virDomainPCIAddressEnsureAddr() that sets the right pciConnectFlags.
2016-09-07 16:29:30 +00:00
virDomainDeviceInfoPtr dev,
virDomainPCIConnectFlags flags)
qemu: extract common PCI handling functions Move sharable PCI handling functions to domain_addr.[ch], and change theirs prefix from 'qemu' to 'vir': - virDomainPCIAddressAsString; - virDomainPCIAddressBusSetModel; - virDomainPCIAddressEnsureAddr; - virDomainPCIAddressFlagsCompatible; - virDomainPCIAddressGetNextSlot; - virDomainPCIAddressReleaseSlot; - virDomainPCIAddressReserveAddr; - virDomainPCIAddressReserveNextSlot; - virDomainPCIAddressReserveSlot; - virDomainPCIAddressSetFree; - virDomainPCIAddressSetGrow; - virDomainPCIAddressSlotInUse; - virDomainPCIAddressValidate; The only change here is function names, the implementation itself stays untouched. Extract common allocation code from DomainPCIAddressSetCreate into virDomainPCIAddressSetAlloc.
2014-05-13 16:10:40 +00:00
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
int virDomainPCIAddressReleaseAddr(virDomainPCIAddressSetPtr addrs,
Change virDevicePCIAddress to virPCIDeviceAddress 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: Martin Kletzander <mkletzan@redhat.com>
2016-04-03 18:16:51 +00:00
virPCIDeviceAddressPtr addr)
qemu: extract common PCI handling functions Move sharable PCI handling functions to domain_addr.[ch], and change theirs prefix from 'qemu' to 'vir': - virDomainPCIAddressAsString; - virDomainPCIAddressBusSetModel; - virDomainPCIAddressEnsureAddr; - virDomainPCIAddressFlagsCompatible; - virDomainPCIAddressGetNextSlot; - virDomainPCIAddressReleaseSlot; - virDomainPCIAddressReserveAddr; - virDomainPCIAddressReserveNextSlot; - virDomainPCIAddressReserveSlot; - virDomainPCIAddressSetFree; - virDomainPCIAddressSetGrow; - virDomainPCIAddressSlotInUse; - virDomainPCIAddressValidate; The only change here is function names, the implementation itself stays untouched. Extract common allocation code from DomainPCIAddressSetCreate into virDomainPCIAddressSetAlloc.
2014-05-13 16:10:40 +00:00
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
conf: new function virDomainPCIAddressReserveNextAddr() There is an existing virDomainPCIAddressReserveNextSlot() which will reserve all functions of the next available PCI slot. One place in the qemu PCI address assignment code requires reserving a *single* function of the next available PCI slot. This patch modifies and renames virDomainPCIAddressReserveNextSlot() so that it can fulfill both the original purpose and the need to reserve a single function. (This is being done so that the abovementioned code in qemu can have its "kind of open coded" solution replaced with a call to this new function).
2016-09-01 13:29:01 +00:00
int virDomainPCIAddressReserveNextAddr(virDomainPCIAddressSetPtr addrs,
virDomainDeviceInfoPtr dev,
virDomainPCIConnectFlags flags,
conf: eliminate concept of "reserveEntireSlot" setting reserveEntireSlot really accomplishes nothing - instead of going to the trouble of computing the value for reserveEntireSlot and then possibly setting *all* functions of the slot as in-use, we can just set the in-use bit only for the specific function being used by a device. Later we will know from the context (the PCI connect flags, and whether we are reserving a specific address or asking for "the next available") whether or not it is okay to allocate other functions on the same slot. Although it's not used yet, we allow specifying "-1" for the function number when looking for the "next available slot" - this is going to end up meaning "return the lowest available function in the slot, but since we currently only provide a function from an otherwise unused slot, "-1" ends up meaning "0".
2016-10-19 16:43:04 +00:00
int function)
conf: new function virDomainPCIAddressReserveNextAddr() There is an existing virDomainPCIAddressReserveNextSlot() which will reserve all functions of the next available PCI slot. One place in the qemu PCI address assignment code requires reserving a *single* function of the next available PCI slot. This patch modifies and renames virDomainPCIAddressReserveNextSlot() so that it can fulfill both the original purpose and the need to reserve a single function. (This is being done so that the abovementioned code in qemu can have its "kind of open coded" solution replaced with a call to this new function).
2016-09-01 13:29:01 +00:00
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
qemu: extract common PCI handling functions Move sharable PCI handling functions to domain_addr.[ch], and change theirs prefix from 'qemu' to 'vir': - virDomainPCIAddressAsString; - virDomainPCIAddressBusSetModel; - virDomainPCIAddressEnsureAddr; - virDomainPCIAddressFlagsCompatible; - virDomainPCIAddressGetNextSlot; - virDomainPCIAddressReleaseSlot; - virDomainPCIAddressReserveAddr; - virDomainPCIAddressReserveNextSlot; - virDomainPCIAddressReserveSlot; - virDomainPCIAddressSetFree; - virDomainPCIAddressSetGrow; - virDomainPCIAddressSlotInUse; - virDomainPCIAddressValidate; The only change here is function names, the implementation itself stays untouched. Extract common allocation code from DomainPCIAddressSetCreate into virDomainPCIAddressSetAlloc.
2014-05-13 16:10:40 +00:00
conf: new function virDomainPCIAddressSetAllMulti() This utility function iterates through all devices looking for any with a PCI address that has function != 0 (which implies that multiple functions are in use on that slot), then uses an inner iterator to find the device that's on function 0 of that same slot and sets the "multi" in its virDomainDeviceInfo (as long as it hasn't already been set explicitly by someone who presumably has better information than we do). It isn't yet called from anywhere, so will have no functional effect.
2017-01-10 05:02:40 +00:00
void virDomainPCIAddressSetAllMulti(virDomainDefPtr def)
ATTRIBUTE_NONNULL(1);
Split out CCW address allocation Just code movement and rename.
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);
int virDomainCCWAddressAllocate(virDomainDefPtr def,
virDomainDeviceDefPtr dev,
virDomainDeviceInfoPtr info,
void *data)
ATTRIBUTE_NONNULL(3) ATTRIBUTE_NONNULL(4);
int virDomainCCWAddressValidate(virDomainDefPtr def,
virDomainDeviceDefPtr dev,
virDomainDeviceInfoPtr info,
void *data)
ATTRIBUTE_NONNULL(3) ATTRIBUTE_NONNULL(4);
int virDomainCCWAddressReleaseAddr(virDomainCCWAddressSetPtr addrs,
virDomainDeviceInfoPtr dev)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
virDomainCCWAddressSetPtr virDomainCCWAddressSetCreate(void);
Add functions to track virtio-serial addresses Create a sorted array of virtio-serial controllers. Each of the elements contains the controller index and a bitmap of available ports. Buses are not tracked, because they aren't supported by QEMU.
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;
virDomainVirtioSerialAddrSetPtr
virDomainVirtioSerialAddrSetCreate(void);
int
virDomainVirtioSerialAddrSetAddControllers(virDomainVirtioSerialAddrSetPtr addrs,
virDomainDefPtr def)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
void
virDomainVirtioSerialAddrSetFree(virDomainVirtioSerialAddrSetPtr addrs);
add virDomainVirtioSerialAddrSetCreateFromDomain The address sets (pci, ccw, virtio serial) are currently cached in qemu private data, but all the information required to recreate these sets is in the domain definition. Therefore I am removing the redundant data and adding a way to recalculate these sets. Add a function that calculates the virtio serial address set from the domain definition. Credit goes to Cole Robinson.
2016-07-23 01:47:06 +00:00
virDomainVirtioSerialAddrSetPtr
virDomainVirtioSerialAddrSetCreateFromDomain(virDomainDefPtr def)
ATTRIBUTE_NONNULL(1);
Add functions to track virtio-serial addresses Create a sorted array of virtio-serial controllers. Each of the elements contains the controller index and a bitmap of available ports. Buses are not tracked, because they aren't supported by QEMU.
2015-03-02 09:57:51 +00:00
bool
virDomainVirtioSerialAddrIsComplete(virDomainDeviceInfoPtr info);
int
Add 'FromCache' to virDomainVirtioSerialAddrAutoAssign Commit 19a148b dropped the cache from QEMU's private domain object. Assume the callers do not have the cache by default and use a longer name for the internal ones that do. This makes the shorter 'virDomainVirtioSerialAddrAutoAssign' name availabe for a function that will not require the cache.
2016-10-21 10:58:54 +00:00
virDomainVirtioSerialAddrAutoAssignFromCache(virDomainDefPtr def,
virDomainVirtioSerialAddrSetPtr addrs,
virDomainDeviceInfoPtr info,
bool allowZero)
Auto add virtio-serial controllers In virDomainVirtioSerialAddrNext, add another controller if we've exhausted all ports of the existing controllers. https://bugzilla.redhat.com/show_bug.cgi?id=1076708
2015-03-24 14:23:46 +00:00
ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3);
Add functions to track virtio-serial addresses Create a sorted array of virtio-serial controllers. Each of the elements contains the controller index and a bitmap of available ports. Buses are not tracked, because they aren't supported by QEMU.
2015-03-02 09:57:51 +00:00
Introduce virDomainVirtioSerialAddrAutoAssign again This time do not require an address cache as a parameter. Simplify qemuDomainAttachChrDeviceAssignAddr to not generate the virtio serial address cache for devices of other types. Partially reverts commit 925fa4b.
2016-10-21 11:09:36 +00:00
int
virDomainVirtioSerialAddrAutoAssign(virDomainDefPtr def,
virDomainDeviceInfoPtr info,
bool allowZero)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
Add functions to track virtio-serial addresses Create a sorted array of virtio-serial controllers. Each of the elements contains the controller index and a bitmap of available ports. Buses are not tracked, because they aren't supported by QEMU.
2015-03-02 09:57:51 +00:00
int
Auto add virtio-serial controllers In virDomainVirtioSerialAddrNext, add another controller if we've exhausted all ports of the existing controllers. https://bugzilla.redhat.com/show_bug.cgi?id=1076708
2015-03-24 14:23:46 +00:00
virDomainVirtioSerialAddrAssign(virDomainDefPtr def,
virDomainVirtioSerialAddrSetPtr addrs,
Add functions to track virtio-serial addresses Create a sorted array of virtio-serial controllers. Each of the elements contains the controller index and a bitmap of available ports. Buses are not tracked, because they aren't supported by QEMU.
2015-03-02 09:57:51 +00:00
virDomainDeviceInfoPtr info,
bool allowZero,
bool portOnly)
Auto add virtio-serial controllers In virDomainVirtioSerialAddrNext, add another controller if we've exhausted all ports of the existing controllers. https://bugzilla.redhat.com/show_bug.cgi?id=1076708
2015-03-24 14:23:46 +00:00
ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3);
Add functions to track virtio-serial addresses Create a sorted array of virtio-serial controllers. Each of the elements contains the controller index and a bitmap of available ports. Buses are not tracked, because they aren't supported by QEMU.
2015-03-02 09:57:51 +00:00
int
virDomainVirtioSerialAddrReserve(virDomainDefPtr def,
virDomainDeviceDefPtr dev,
virDomainDeviceInfoPtr info,
void *data)
ATTRIBUTE_NONNULL(3) ATTRIBUTE_NONNULL(4);
int
virDomainVirtioSerialAddrRelease(virDomainVirtioSerialAddrSetPtr addrs,
virDomainDeviceInfoPtr info)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
Store USB port path as an array of integers In preparation to tracking which USB addresses are occupied. Introduce two helper functions for printing the port path as a string and appending it to a virBuffer.
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);
char *
virDomainUSBAddressPortFormat(unsigned int *port)
ATTRIBUTE_NONNULL(1);
Introduce virDomainUSBAddressSet A new type to track USB addresses. Every <controller type='usb' index='i'/> is represented by an object of type virDomainUSBAddressHub located at buses[i]. Each of these hubs has up to 'nports' ports. If a port is occupied, it has the corresponding bit set in the 'ports' bitmap, e.g. port 1 would have the 0th bit set. If there is a hub on this port, then hubs[i] will point to this hub.
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);
Add functions for adding USB controllers to addrs Walk through all the usb controllers in the domain definition and create the corresponding structures in the virDomainUSBAddressSet.
2015-08-12 14:52:16 +00:00
int virDomainUSBAddressSetAddControllers(virDomainUSBAddressSetPtr addrs,
virDomainDefPtr def)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
Assign addresses to USB devices Automatically assign addresses to USB devices. Just like reserving, this is only done for newly defined domains. https://bugzilla.redhat.com/show_bug.cgi?id=1215968
2015-08-12 14:52:18 +00:00
int
virDomainUSBAddressSetAddHub(virDomainUSBAddressSetPtr addrs,
virDomainHubDefPtr hub)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
Auto-add one hub if there are too many USB devices When parsing a command line with USB devices that have no address specified, QEMU automatically adds a USB hub if the device would fill up all the available USB ports. To help most of the users, add one hub if there are more USB devices than available ports. For wilder configurations, expect the user to provide us with more hubs and/or controllers.
2016-06-17 07:49:54 +00:00
size_t
virDomainUSBAddressCountAllPorts(virDomainDefPtr def);
Introduce virDomainUSBAddressSet A new type to track USB addresses. Every <controller type='usb' index='i'/> is represented by an object of type virDomainUSBAddressHub located at buses[i]. Each of these hubs has up to 'nports' ports. If a port is occupied, it has the corresponding bit set in the 'ports' bitmap, e.g. port 1 would have the 0th bit set. If there is a hub on this port, then hubs[i] will point to this hub.
2015-08-12 14:52:15 +00:00
void virDomainUSBAddressSetFree(virDomainUSBAddressSetPtr addrs);
Recreate the USB address cache at reconnect When starting a new domain, we allocate the USB addresses and keep an address cache in the domain object's private data. However this data is lost on libvirtd restart. Also generate the address cache if all the addresses have been specified, so that devices hotplugged after libvirtd restart also get theirs assigned. https://bugzilla.redhat.com/show_bug.cgi?id=1387666
2016-10-21 11:09:04 +00:00
int
virDomainUSBAddressPresent(virDomainDeviceInfoPtr info,
void *data)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
Reserve existing USB addresses Check if they fit on the USB controllers the domain has, and error out if two devices try to use the same address.
2015-08-12 14:52:17 +00:00
int
virDomainUSBAddressReserve(virDomainDeviceInfoPtr info,
void *data)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
Assign addresses to USB devices Automatically assign addresses to USB devices. Just like reserving, this is only done for newly defined domains. https://bugzilla.redhat.com/show_bug.cgi?id=1215968
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)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
Assign addresses on USB device hotplug USB disks, redirected devices, host devices and serial devices are supported.
2015-08-12 14:52:19 +00:00
int
virDomainUSBAddressRelease(virDomainUSBAddressSetPtr addrs,
virDomainDeviceInfoPtr info)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
qemu: extract PCI handling structs Introduce new files (domain_addr.[ch]) to provide an API for domain device handling that could be shared across the drivers. A list of data types were extracted and moved there: qemuDomainPCIAddressBus -> virDomainPCIAddressBus qemuDomainPCIAddressBusPtr -> virDomainPCIAddressBusPtr _qemuDomainPCIAddressSet -> virDomainPCIAddressSet qemuDomainPCIAddressSetPtr -> virDomainPCIAddressSetPtr qemuDomainPCIConnectFlags -> virDomainPCIConnectFlags Also, move the related definitions and macros.
2014-05-10 16:35:24 +00:00
#endif /* __DOMAIN_ADDR_H__ */
Reference in New Issue Copy Permalink