- 15 7月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
This function was private to the QEMU driver and was, accordingly, called qemuDomainPCIBusFullyReserved(). However the function is really not QEMU-specific at all, so it makes sense to move it closer to the virDomainPCIAddressBus struct it operates on. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NLaine Stump <laine@laine.org>
-
- 28 4月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438682Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NAndrea Bolognani <abologna@redhat.com>
-
- 13 4月, 2017 1 次提交
-
-
由 Ján Tomko 提交于
Properly error out when the user requests a port from a bus that does not have a controller present in the domain XML. https://bugzilla.redhat.com/show_bug.cgi?id=1441589
-
- 23 2月, 2017 2 次提交
-
-
由 Andrea Bolognani 提交于
When switching over the values in the virDomainControllerModelPCI enumeration, make sure the proper cast is in place so that the compiler can warn us when the coverage is not exaustive. For the same reason, remove the 'default' case from one of the existing switch statements.
-
由 Andrea Bolognani 提交于
The switch in virDomainPCIControllerModelToConnectType() had some code that, while techically part of the _PCIE_SWITCH_DOWNSTREAM_PORT case, was in fact dead due to the early return. Get rid of the dead code, and fix the inaccurate function description while at it.
-
- 13 2月, 2017 1 次提交
-
-
由 Ján Tomko 提交于
Move the range check introduced by commit 2650d5e1 into virDomainUSBAddressFindPort. That way both virDomainUSBAddressRelease and virDomainUSBAddressSetAddHub can benefit from it. Reported-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 31 1月, 2017 1 次提交
-
-
由 Ján Tomko 提交于
For reusing in qemu_domain_address.c.
-
- 11 1月, 2017 15 次提交
-
-
由 Laine Stump 提交于
Surprisingly there was a virDomainPCIAddressReleaseAddr() function already, but it was completely unused. Since we don't reserve entire slots at once any more, there is no need to release entire slots either, so we just replace the single call to virDomainPCIAddressReleaseSlot() with a call to virDomainPCIAddressReleaseAddr() and remove the now unused function. The keen observer may be concerned that ...Addr() doesn't call virDomainPCIAddressValidate(), as ...Slot() did. But really the validation was pointless anyway - if the device hadn't been suitable to be connected at that address, it would have failed validation before every being reserved in the first place, so by definition it will pass validation when it is being unplugged. (And anyway, even if something "bad" happened and we managed to have a device incorrectly at the given address, we would still want to be able to free it up for use by a device that *did* validate properly).
-
由 Laine Stump 提交于
This function doesn't actually reserve an entire slot any more, it reserves a single PCI address, so this name is more appropriate.
-
由 Laine Stump 提交于
This is in preparation for renaming virDomainPCIAddressReserveSlot() to virDomainPCIAddressReserveAddr(), which is a better description of what it does.
-
由 Laine Stump 提交于
It is now only used in domain_addr.c.
-
由 Laine Stump 提交于
Since we don't actually reserve an entire slot at a time anymore, the name of this function is just confusing, and it's almost identical in operation to virDomainPCIAddressReserveNextAddr() anyway, so remove the *Slot() function and replace calls to it with calls to *Addr(..., -1).
-
由 Laine Stump 提交于
With the advent of VIR_PCI_CONNECT_AGGREGATE_SLOT, the new name is more appropriate, since the address returned may be another address on the same slot as last time, not necessarily a new slot.
-
由 Laine Stump 提交于
fromConfig should be true if the caller wants virDomainPCIAddressValidate() to loosen restrictions on its interpretation of the pciConnectFlags. In particular, either PCI_DEVICE or PCIE_DEVICE will be counted as equivalent to both, and HOTPLUG will be ignored. In a few cases where libvirt was manually overriding automatic address assignment, it was setting fromConfig to false when validating the hardcoded manual override. This patch changes those to fromConfig=true as a preemptive strike against any future bugs that might otherwise surface.
-
由 Laine Stump 提交于
Although setting virDomainPCIAddressReserveAddr()'s fromConfig=true is correct when a PCI addres is coming from a domain's config, the *true* purpose of the fromConfig argument is to lower restrictions on what kind of device can plug into what kind of controller - if fromConfig is true, then a PCIE_DEVICE can plug into a slot that is marked as only compatible with PCI_DEVICE (and vice versa), and the HOTPLUG flag is ignored. For a long time there have been several calls to virDomainPCIAddressReserveAddr() that have fromConfig incorrectly set to false - it's correct that the addresses aren't coming from user config, but they are coming from hardcoded exceptions in libvirt that should, if anything, pay *even less* attention to following the pciConnectFlags (under the assumption that the libvirt programmer knew what they were doing). See commit b87703cf for an example of an actual bug caused by the incorrect setting of the "fromConfig" argument to virDomainPCIAddressReserveAddr(). Although they haven't resulted in any reported bugs, this patch corrects all the other incorrect settings of fromConfig in calls to virDomainPCIAddressReserveAddr().
-
由 Laine Stump 提交于
Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
-
由 Laine Stump 提交于
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.
-
由 Laine Stump 提交于
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.
-
由 Laine Stump 提交于
There is a very slight time advantage to beginning the search for the next unused PCI address at the slot *after* the previous find (which is now used), but if we do that, we will miss allocating the other functions of the same slot (when we implement a VIR_PCI_CONNECT_AGGREGATE_SLOT flag to support that).
-
由 Laine Stump 提交于
virDomainPCIAddressGetNextSlot() starts searching from the last allocated address and goes to the end of all the buses, then goes back to the first bus and searches from there up to the starting point (in case any address has been freed since the last time an address was allocated. The loops for these two are almost, but not exactly, the same, so they have remained as separate loops with the same code inside the loop. To lessen maintenance headaches, the identical code has been moved out into the function virDomainPCIAddressFindUnusedFunctionOnBus(), which is called in place of the loop contents.
-
由 Laine Stump 提交于
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".
-
由 Laine Stump 提交于
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".
-
- 30 11月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
My overly sophisticated address reservation code forgot to add an error message for user-requested ports out of range. https://bugzilla.redhat.com/show_bug.cgi?id=1399260
-
- 15 11月, 2016 3 次提交
-
-
由 Laine Stump 提交于
Previously libvirt would only add pci-bridge devices automatically when an address was requested for a device that required a legacy PCI slot and none was available. This patch expands that support to dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a machine with a pcie-root), and pcie-root-port (which is needed to add a hotpluggable PCIe device). It does *not* automatically add pcie-switch-upstream-ports or pcie-switch-downstream-ports (and currently there are no plans for that). Given the existing code to auto-add pci-bridge devices, automatically adding pcie-root-ports is fairly straightforward. The dmi-to-pci-bridge support is a bit tricky though, for a few reasons: 1) Although the only reason to add a dmi-to-pci-bridge is so that there is a reasonable place to plug in a pci-bridge controller, most of the time it's not the presence of a pci-bridge *in the config* that triggers the requirement to add a dmi-to-pci-bridge. Rather, it is the presence of a legacy-PCI device in the config, which triggers auto-add of a pci-bridge, which triggers auto-add of a dmi-to-pci-bridge (this is handled in virDomainPCIAddressSetGrow() - if there's a request to add a pci-bridge we'll check if there is a suitable bus to plug it into; if not, we first add a dmi-to-pci-bridge). 2) Once there is already a single dmi-to-pci-bridge on the system, there won't be a need for any more, even if it's full, as long as there is a pci-bridge with an open slot - you can also plug pci-bridges into existing pci-bridges. So we have to make sure we don't add a dmi-to-pci-bridge unless there aren't any dmi-to-pci-bridges *or* any pci-bridges. 3) Although it is strongly discouraged, it is legal for a pci-bridge to be directly plugged into pcie-root, and we don't want to auto-add a dmi-to-pci-bridge if there is already a pci-bridge that's been forced directly into pcie-root. Although libvirt will now automatically create a dmi-to-pci-bridge when it's needed, the code still remains for now that forces a dmi-to-pci-bridge on all domains with pcie-root (in qemuDomainDefAddDefaultDevices()). That will be removed in a future patch. For now, the pcie-root-ports are added one to a slot, which is a bit wasteful and means it will fail after 31 total PCIe devices (30 if there are also some PCI devices), but helps keep the changeset down for this patch. A future patch will have 8 pcie-root-ports sharing the functions on a single slot.
-
由 Laine Stump 提交于
This patch cleans up the connect flags for certain types/models of devices that aren't PCI to return 0. In the future that may be used as an indicator to the caller about whether or not a device needs a PCI address. For now it's just ignored, except for in virDomainPCIAddressEnsureAddr() - called during device hotplug - (and in some cases actually needs to be re-set to PCI|HOTPLUGGABLE just in case someone (in some old config) has manually set a PCI address for a device that isn't PCI.
-
由 Laine Stump 提交于
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.
-
- 27 10月, 2016 3 次提交
-
-
由 Ján Tomko 提交于
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
-
由 Ján Tomko 提交于
Commit 19a148b7 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.
-
- 25 10月, 2016 2 次提交
-
-
由 Laine Stump 提交于
This function is no longer needed outside of domain_addr.c.
-
由 Laine Stump 提交于
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).
-
- 17 10月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
The code is entirely correct, but it still managed to trip me up when I first ran into it because I did not realize right away that VIR_PCI_CONNECT_TYPES_ENDPOINT was not a single flag, but rather a mask including both VIR_PCI_CONNECT_TYPE_PCI_DEVICE and VIR_PCI_CONNECT_TYPE_PCIE_DEVICE. In order to save the next distracted traveler in PCI Address Land some time, document this fact with a comment. Add a test case for the behavior as well.
-
- 15 10月, 2016 1 次提交
-
-
由 Laine Stump 提交于
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.)
-
- 06 10月, 2016 1 次提交
-
-
由 Laine Stump 提交于
When I added support for the pcie-expander-bus controller in commit bc07251f, I incorrectly thought that it only had a single slot available. Actually it has 32 slots, just like the root complex aka pcie-root (the part that I *did* get correct is that unlike pcie-root a pcie-expander-bus doesn't allow any integrated endpoint devices - only pcie-root-ports and dmi-to-pci-controllers are allowed).
-
- 13 9月, 2016 1 次提交
-
-
由 Laine Stump 提交于
In a full domain config, libvirt allows overriding the normal PCI vs. PCI Express rules when a device address is explicitly provided (so, e.g., you can force a legacy PCI device to plug into a PCIe port, although libvirt would never do that on its own). However, due to a bug libvirt doesn't give this same leeway when hotplugging devices. On top of that, current libvirt assumes that *all* devices are legacy PCI. The result of all this is that it's impossible to hotplug a device into a PCIe port, even if you manually add the PCI address. This can all be traced to the function virDomainPCIAddressEnsureAddr(), and the fact that it calls virDomainPCIaddressReserveSlot() for manually set addresses, and that function hardcodes the argument "fromConfig" to false (meaning "this address was auto-assigned, so it should be subject to stricter validation"). Since virDomainPCIAddressReserveSlot() is just a one line simple wrapper around virDomainPCIAddressReserveAddr() (adding in a hardcoded reserveEntireSlot = true and fromConfig = false), all that's needed to solve the problem with no unwanted side effects is to replace that call for virDomainPCIAddressReserveSlot() with a direct call to virDomainPCIAddressReserveAddr(), but with reserveEntireSlot = true, fromConfig = true. That's what this patch does. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1337490
-
- 02 9月, 2016 1 次提交
-
-
由 Xian Han Yu 提交于
The 'multi' element in PCI address struct used as 'virTristateSwitch', and its default value is 'VIR_TRISTATE_SWITCH_ABSENT'. Current PCI process use 'false' to initialization 'multi', which is ambiguously for assignment or comparison. This patch use '{0}' to initialize the whole PCI address struct, which fix the 'multi' initialization and makes code more simplify and explicitly. Signed-off-by: NXian Han Yu <xhyubj@linux.vnet.ibm.com>
-
- 16 8月, 2016 2 次提交
-
-
由 Ján Tomko 提交于
If any of the devices referenced a USB hub that does not exist, defining the domain would either fail with: error: An error occurred, but the cause is unknown (if only the last hub in the path is missing) or crash. Return a proper error instead of crashing. https://bugzilla.redhat.com/show_bug.cgi?id=1367130
-
由 Ján Tomko 提交于
The array needs to be freed too, not just its members. https://bugzilla.redhat.com/show_bug.cgi?id=1366097
-
- 10 8月, 2016 2 次提交
-
-
由 Laine Stump 提交于
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
-
由 Laine Stump 提交于
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
-