- 15 11月, 2016 2 次提交
-
-
由 Laine Stump 提交于
Set pciConnectFlags in each device's DeviceInfo and then use those flags later when validating existing addresses in qemuDomainCollectPCIAddress() and when assigning new addresses with qemuDomainPCIAddressReserveNextAddr() (rather than scattering the logic about which devices need which type of slot all over the place). Note that the exact flags set by qemuDomainDeviceCalculatePCIConnectFlags() are different from the flags previously set manually in qemuDomainCollectPCIAddress(), but this doesn't matter because all validation of addresses in that case ignores the setting of the HOTPLUGGABLE flag, and treats PCIE_DEVICE and PCI_DEVICE the same (this lax checking was done on purpose, because there are some things that we want to allow the user to specify manually, e.g. assigning a PCIe device to a PCI slot, that we *don't* ever want libvirt to do automatically. The flag settings that we *really* want to match are 1) the old flag settings in qemuDomainAssignDevicePCISlots() (which is HOTPLUGGABLE | PCI_DEVICE for everything except PCI controllers) and 2) the new flag settings done by qemuDomainDeviceCalculatePCIConnectFlags() (which are currently exactly that - HOTPLUGGABLE | PCI_DEVICE for everything except PCI controllers).
-
由 Laine Stump 提交于
The lowest level function of this trio (qemuDomainDeviceCalculatePCIConnectFlags()) aims to be the single authority for the virDomainPCIConnectFlags to use for any given device using a particular arch/machinetype/qemu-binary. qemuDomainFillDevicePCIConnectFlags() sets info->pciConnectFlags in a single device (unless it has no virDomainDeviceInfo, in which case it's a NOP). qemuDomainFillAllPCIConnectFlags() sets info->pciConnectFlags in all devices that have a virDomainDeviceInfo The latter two functions aren't called anywhere yet. This commit is just making them available. Later patches will replace all the current hodge-podge of flag settings with calls to this single authority.
-
- 11 11月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
As with other devices assign the slot number right away when adding the device. This will make the slot numbers static as we do with other addressing elements and it will ultimately simplify allocation of the alias in a static way which does not break with qemu.
-
- 27 10月, 2016 2 次提交
-
-
由 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 提交于
An upcoming commit will remove the "flag" argument from all the calls to reserve the next available address|slot, but I don't want to change the arguments in the hypervisor-agnostic virDomainPCIAddressReserveNext*() functions, so this patch places a simple qemu-specific wrapper around those functions - the new functions don't take a flags arg, but grab it from the device's info->pciConnectFlags.
-
由 Laine Stump 提交于
instead of calling virDomainPCIAddressGetNextSlot() (which I want to turn into a local static in domain_addr.c).
-
- 24 10月, 2016 4 次提交
-
-
由 Laine Stump 提交于
This error should only ever be seen by a developer anyway, but the existing message made even less sense that this new version.
-
由 Laine Stump 提交于
This is already set by virDomainPCIAddressSetAlloc().
-
由 Laine Stump 提交于
More occurences of repeatedly dereferencing the same pointer stored in an array are replaced with the definition of a temporary pointer that is then used directly. No functional change.
-
由 Laine Stump 提交于
There's no functional change here. This pointer was just used so many times that the extra long lines became annoying.
-
- 12 10月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
All definition validation that doesn't depend on qemu capabilities and was allowed previously as valid definition should be placed into qemuDomainDefValidate. The check whether video type is supported or not was based on an enum that translates type into model. Use switch to ensure that if new video type is added, it will be properly handled. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 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>
-
- 26 7月, 2016 4 次提交
-
-
由 Tomasz Flendrich 提交于
Dropping the caching of ccw address set. The cached set is not required anymore, because the set is now being recalculated from the domain definition on demand, so the cache can be deleted.
-
由 Tomasz Flendrich 提交于
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 ccw address set from the domain definition.
-
由 Tomasz Flendrich 提交于
Dropping the caching of virtio serial address set. The cached set is not required anymore, because the set is now being recalculated from the domain definition on demand, so the cache can be deleted. Credit goes to Cole Robinson.
-
由 Tomasz Flendrich 提交于
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.
-
- 21 7月, 2016 4 次提交
-
-
由 Ján Tomko 提交于
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.
-
由 Ján Tomko 提交于
USB disks, redirected devices, host devices and serial devices are supported.
-
由 Ján Tomko 提交于
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
-
由 Ján Tomko 提交于
Check if they fit on the USB controllers the domain has, and error out if two devices try to use the same address.
-
- 24 6月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
This new function checks for both the architecture and the machine type, so we can use it instead of writing the same checks over and over again.
-
- 23 6月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Pass 'true' if we are not dealing with a migration.
-
- 21 6月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
-
- 18 6月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
There has been some progress lately in enabling virtio-pci on aarch64 guests; however, guest OS support is still spotty at best, so most guests are going to be using virtio-mmio instead. Currently, mach-virt guests are closely modeled after q35 guests, and that includes always adding a dmi-to-pci-bridge that's just impossible to get rid of. While that's acceptable (if suboptimal) for q35, where you will always need some kind of PCI device anyway, mach-virt guests should be allowed to avoid it.
-
- 26 5月, 2016 2 次提交
-
-
由 Andrea Bolognani 提交于
Commit ff212622 changed the error message to be more detailed about the failure at hand; however, while the new error message claims that "bus must be <= index", the error message is displayed if "idx <= addr->bus", ie. when bus is larger than or *equal to* index. Change the error message to report the correct constraint, and format it in a way that mirrors the check exactly to make it clearer to people reading the code. The new error message reads "index must be larger than bus". Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1339900
-
由 Laine Stump 提交于
IS_USB2_CONTROLLER() is useful in more places aside from just when assigning PCI addresses in QEMU, and is checking for enum values that are all defined in conf/domain_conf.h anyway, so define it there instead.
-
- 25 5月, 2016 2 次提交
-
-
由 John Ferlan 提交于
Based on some digital archaeology performed by jtomko, it's been determined that the persistentAddrs variable is no longer necessary... The variable was added by: commit 141dea6b CommitDate: 2010-02-12 17:25:52 +0000 Add persistence of PCI addresses to QEMU Where it was set to 0 on domain startup if qemu did not support the QEMUD_CMD_FLAG_DEVICE capability, to clear the addresses at shutdown, because QEMU might make up different ones next time. As of commit f5dd58a6 CommitDate: 2012-07-11 11:19:05 +0200 qemu: Extended qemuDomainAssignAddresses to be callable from everywhere. this was broken, when the persistentAddrs = 0 assignment was moved inside qemuDomainAssignPCIAddresses and while it pretends to check for !QEMU_CAPS_DEVICE, its parent qemuDomainAssignAddresses is only called if QEMU_CAPS_DEVICE is present.
-
由 John Ferlan 提交于
Since commit id '20a0fa8e' removed the QEMU_CAPS_DEVICE, Coverity notes that it's no longer possible to have 'addrs' be NULL when checking for a live domain since qemuDomainPCIAddressSetCreate would have jumped to cleanup if addrs was NULL.
-
- 21 5月, 2016 1 次提交
-
-
由 Laine Stump 提交于
Rather than only assigning a PCI address when no address is given at all, also do it when the config says that the address type is 'pci', but it gives no address (virDeviceInfoPCIAddressWanted()). There are also several places after parsing but prior to address assignment where code previously expected that any info with address type='pci' would have a *valid* PCI address, which isn't always the case - now we check not only for type='pci', but also for a valid address (virDeviceInfoPCIAddressPresent()). The test case added in this patch was directly copied from Cole's patch titled: qemu: Wire up address type=pci auto_allocate
-
- 19 5月, 2016 1 次提交
-
-
由 Cole Robinson 提交于
All qemu versions we support have QEMU_CAPS_DEVICE, so checking for it is redundant. Remove the usage. The code diff isn't clear, but all that code is just inindented with no other change. Test cases that hit qemuDomainAssignAddresses but don't have infrastructure for specifying qemuCaps values see lots of churn, since now PCI addresses are in the XML output.
-
- 03 5月, 2016 4 次提交
-
-
由 Ján Tomko 提交于
Use it everywhere except for virQEMUCapsFillDomainFeatureGICCaps.
-
由 Ján Tomko 提交于
It was not indented correctly.
-
由 Ján Tomko 提交于
We do not need to propagate the exact return values and the only possible ones are 0 and -1 anyway. Remove the temporary variable and use the usual pattern: if (f() < 0) return -1;
-
由 Ján Tomko 提交于
This function does not fail and it does not need to return anything.
-
- 02 5月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
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: NMartin Kletzander <mkletzan@redhat.com>
-
- 25 4月, 2016 1 次提交
-
-
由 Laine Stump 提交于
This error message was too specific, based on the incorrect assumption that any error was cause by auto-added bridges: failed to create PCI bridge on bus 2: too many devices with fixed addresses In practice you can't know if a bridge with an index <= the bus it's connecting to was added automatically, or if it was a mistake in explicit config, and the auto-add problem is going to be dealt with in a different way in an upcoming patch. The new message is this: PCI Controller at index 1 (0x01) has " bus='0x02', but bus must be <= index (note that index is given in both decimal and hex because it is formatted as decimal in the XML, but bus is formatted as hex, and displaying the hex value of index makes it easier to see the problem when index > 9 (which will often be the case with PCIe, since most controllers only have a single port, not 32 slots as with standard PCI)). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004593
-
- 15 4月, 2016 3 次提交
-
-
由 Laine Stump 提交于
This is backed by the qemu device pxb-pcie, which will be available in qemu 2.6.0. As with pci-expander-bus (which uses qemu's pxb device), the busNr attribute and <node> subelement of <target> are used to set the bus_nr and numa_node options. During post-parse we validate that the domain's machinetype is q35-based (since the device shows up for 440fx-based machinetypes, but is unusable), as well as checking that <node> specifies a node that is actually configured on the guest.
-
由 Laine Stump 提交于
This controller provides a single PCIe port on a new root. It is similar to pci-expander-bus, intended to provide a bus that can be associated with a guest-identifiable NUMA node, but is for machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes). Aside from PCIe vs. PCI, the other main difference is that a pci-expander-bus has a companion pci-bridge that is automatically attached along with it, but pcie-expander-bus has only a single port, and that port will only connect to a pcie-root-port, or to a pcie-switch-upstream-port. In order for the bus to be of any use in the guest, it must have either a pcie-root-port or a pcie-switch-upstream-port attached (and one or more pcie-switch-downstream-ports attached to the pcie-switch-upstream-port).
-
由 Laine Stump 提交于
This is backed by the qemu device "pxb". The pxb device always includes a pci-bridge that is at the bus number of the pxb + 1. busNr and <node> from the <target> subelement are used to set the bus_nr and numa_node options for pxb. During post-parse we validate that the domain's machinetype is 440fx-based (since the pxb device only works on 440fx-based machines), and <node> also gets a sanity check to assure that the NUMA node specified for the pxb (if any - it's optional) actually exists on the guest.
-