- 15 4月, 2016 25 次提交
-
-
由 Erik Skultety 提交于
The reason for this is to fix the automatic rebuild of libvirt-common.h.in. All *.in files should be automatically rebuilt each time they're modified. It works well for makefiles and pkgconfig files, since they do have a valid dependency in the top-level Makefile. However, with libvirt-common.h.in there is no dependency in the top-level Makefile and there's no need for it either, so this rule include/libvirt/libvirt-common.h: $(top_builddir)/config.status \ $(top_srcdir)/include/libvirt/libvirt-common.h.in cd $(top_builddir) && $(SHELL) ./config.status $@ is never hit and should be moved to include/Makefile, but that's automake's job. According to GNU automake docs: "Files created by AC_CONFIG_FILES, be they Automake Makefiles or not, are all removed by ‘make distclean’. Their inputs are automatically distributed, unless they are the output of prior AC_CONFIG_FILES commands. Finally, rebuild rules are generated in the Automake Makefile existing in the subdirectory of the output file, if there is one, or in the top-level Makefile otherwise." Which means that if we want to have the rule for libvirt-common.h automatically generated by automake, the include/Makefile.am needs to be moved into libvirt/ subdirectory and $SUBDIRS in the top-level Makefile need to be adjusted as well. This patch moves Makefile.am from include/ to include/libvirt, adjusting the prefixes accordingly as well as updates the top-level Makefile $SUBDIRS to properly hint automake to generate all rules at proper places. Best way to see the changes, use -M with 'git show'. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Maxim Nestratov 提交于
Since vz driver is now lives as a part of daemon we can benefit from this fact and allow vz clients to use shared drivers API like storage, network, nwfilter etc. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 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 提交于
The pxb device is a PCIe expander bus that can be added to any Q35-based machinetype. A single PCIe port (*not* hotpluggable) is provided; if more than one device is desired, or if hotplug support is needed, either a pcie-root-port, or some combination of pcie-switch-upstream-port and pcie-swith-downstream-ports must be added to it. It can have a NUMA node number associated with it, as well as a bus number.
-
由 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.
-
由 Laine Stump 提交于
This is a standard PCI root bus (not a bridge) that can be added to a 440fx-based domain. Although it uses a PCI slot, this is *not* how it is connected into the PCI bus hierarchy, but is only used for control. Each pci-expander-bus provides 32 slots (0-31) that can accept hotplug of standard PCI devices. The usefulness of pci-expander-bus relative to a pci-bridge is that the NUMA node of the bus can be specified with the <node> subelement of <target>. This gives guest-side visibility to the NUMA node of attached devices (presuming that management apps only assign a device to a bus that has a NUMA node number matching the node number of the device on the host). Each pci-expander-bus also has a "busNr" attribute. The expander-bus itself will take the busNr specified, and all buses that are connected to this bus (including the pci-bridge that is automatically added to any expander bus of model "pxb" (see the next commit)) will use busNr+1, busNr+2, etc, and the pci-root (or the expander-bus with next lower busNr) will use bus numbers lower than busNr.
-
由 Laine Stump 提交于
The pxb device is a PCI expander bus that can be added to any 440fx-based machinetype. The PCI bus that is created has 32 standard PCI slots (hotpluggable). It can have a NUMA node number associated with it, as well as a bus number.
-
由 Laine Stump 提交于
Since every PCI controller model has to have a default model name set, put it in a separate function to clean up qemuDomainAssignPCIAddresses a bit.
-
由 Laine Stump 提交于
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.
-
由 Laine Stump 提交于
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.
-
由 Laine Stump 提交于
When support for dmi-to-pci-bridge was added, it was assumed that, just as with the pci-root bus, slot 0 was reserved. This is not the case - it can be used to connect a device just like any other slot, so remove the restriction and update the test cases that auto-assign an address on a dmi-to-pci-bridge.
-
由 Laine Stump 提交于
Every other maxSlot was either set to 0 or to VIR_PCI_ADDRESS_SLOT_LAST, but this one was for some reason set to the literal value 31 (which is the same as VIR_PCI_ADDRESS_SLOT_LAST). This makes them all consistent.
-
由 Laine Stump 提交于
This is especially useful for "bus", since the bus of a device's pci address is matched to the "index" of a controller to determine which bus it will be connected to, and "index" is always specified in decimal - being able to specify both in decimal at least makes it easier to assure a device is being assigned to the correct bus when it is added. For the other attributes, it is just a convenience. (MB: the parser already allows for any of these attributes to be given in decimal, and there are even examples floating around on the internet that give them in decimal rather than hex (written in the days before virsh did schema validation on all XML). This only updates the schema to match the parser.)
-
由 Laine Stump 提交于
This is a number between 0 and 65535 (or 0x0000 - 0xffff if specified in hexadecimal).
-
由 Laine Stump 提交于
nwfilter.rng defines uint16range and uint32range, but in a different manner (it also allows a variable name as the value, rather than just a decimal or hex number). I wanted to add uint16range to basictypes.rng, but my desired definition was parallel to those for uint8range and uint24range which are defined in basictypes.rng - they *don't* allow a variable name for the value. The simplest path to make everyone happy is to make the "plain" versions in basictypes.rng have simpler names - "uint8", "uint16", and "uint24". This patch renames uint8range and uint24range to uint8 and uint24, while the next patch will add uint16.
-
由 Laine Stump 提交于
The pcie-switch-downstream-port and pcie-root-port controllers have only a single slot, numbered 0, and the greate majority of all guest PCI devices are plugged into function 0 of whatever slot they're using. The parser makes these optional, setting them to 0 when not specified, and it's logical for the schema to also make them optional.
-
由 Cole Robinson 提交于
Take setlocale/gettext error handling pattern from tools/virsh-* and use it for all standalone binaries via a new shared virGettextInitialize routine. The virsh* pattern differed slightly from other callers. All users now consistently: * Ignore setlocale errors. virsh has done this forever, presumably for good reason. This has been partially responsible for some bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=1312688 https://bugzilla.redhat.com/show_bug.cgi?id=1026514 https://bugzilla.redhat.com/show_bug.cgi?id=1016158 * Report the failed function name * Report strerror
-
-
由 Cole Robinson 提交于
clarify what version initial support was added, and when libvirt started supporting it for the qemu driver https://bugzilla.redhat.com/show_bug.cgi?id=657931
-
由 Cole Robinson 提交于
Added with commit 3b431929 in v1.2.2 but never documented https://bugzilla.redhat.com/show_bug.cgi?id=1313613
-
由 Cole Robinson 提交于
We use device-mapper to enumerate all dm devices, and filter out the list of multipath devices by checking the target_type string name. The code however cancels all scanning if we encounter target_type=NULL I don't know how to reproduce that situation, but a user was hitting it in their setup, and inspecting the lvm2/device-mapper code shows many places where !target_type is explicitly ignored and processing continues on to the next device. So I think we should do the same https://bugzilla.redhat.com/show_bug.cgi?id=1069317
-
由 Cole Robinson 提交于
The watchdog cli refactoring in 4666b762 dropped the temporary variable we use to convert to action=dump to action=pause for the qemu cli, and stored the converted value in the domain structure. Our other watchdog handling code then treated it as though the user requested action=pause, which broke action=dump handling. Revive the temporary variable to fix things.
-
由 Cole Robinson 提交于
* Add a test for listen=XXX and <listen address=YYY/> collision error * Add an explicit test for listen=XXX duplicated to <listen address=XXX/> We implicitly test it elsewhere but I figure it's better to be explicit, and this test case can be extended in the future for additional listen back compat if/when we support <listen type='socket'/> syntax
-
由 Cole Robinson 提交于
This allows tests to check for specific failure scenarios
-
- 14 4月, 2016 11 次提交
-
-
由 Ján Tomko 提交于
In qemuHotplugCreateObjects, the ret variable was filled by the value returned by qemuTestCapsCacheInsert. If any of the functions after this assignment failed, we would still return success. Also adjust testCompareXMLToArgvHelper, where this change is just cosmetic, because the value was overwritten right away.
-
由 ShaoHe Feng 提交于
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Eli Qiao 提交于
Signed-off-by: NEli Qiao <liyong.qiao@intel.com> Signed-off-by: NShaoHe Feng <shaohe.feng@intel.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 ShaoHe Feng 提交于
Signed-off-by: NShaoHe Feng <shaohe.feng@intel.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
Upcoming compression options for migration command patch series hits current limit of 32 possible options for a command. Lets take one step further and support 64 possible options. And all it takes is moving from 32 bit integers to 64 bit ones. The only less then trivial change i found is moving from 'ffs' to 'ffsl'. Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Martin Kletzander 提交于
I tried compiling libvirt with older gcc and probably because I used different configure options I got some shadowed declarations. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Chunyan Liu 提交于
Add codes to support creating domain with network defition of assigning SRIOV VF from a pool. Signed-off-by: NChunyan Liu <cyliu@suse.com> Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Maxim Nestratov 提交于
commit 30c61901 added new functions to libvirt_private.syms not alpabetically sorted and erroneously added vz sources to STATEFUL_DRIVER_SOURCE_FILES, which triggered check-aclrules running while vz driver isn't ready for it yet. Pushing under build-breaker rule. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
SDK does not allocate memory when getting strings thus we need to call every function that returns string twice. First to obtain string length, second to obtain string itself. It is tedious so let's create helper functions for cases when we know length of the result beforehand and we are not. Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
- 13 4月, 2016 4 次提交
-
-
由 Maxim Nestratov 提交于
remove unnecessary vzConnectClose prototype and make local structure vzDomainDefParserConfig be static Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
We don't need them anymore as all pointers within vzDriver structure are not changed during the time it exists. Where we still need to synchronize we use virObjectLock/Unlock as far as vzDriver is lockable object. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
Lock driver when a new domain is created in prlsdkNewDomainByHandle and try to find it in the list under lock again because it can race with vzDomainDefineXMLFlags when a domain with the same uuid is added via vz dispatcher directly and libvirt define. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-