- 26 9月, 2013 10 次提交
-
-
由 Daniel P. Berrange 提交于
The vmx2xmltest test would print all errors to stderr, which is not helpful when running OOM tests, and differs from the behaviour of other tests. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The code parsing comments in config files called virConfAddEntry but did not check for failure. This caused the comment string to leak on OOM. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The virVMXFormatConfig called virVMXEscapeHexPipe but forgot to check for OOM. This caused data to silently be lost. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The virStoragePoolDefParseSource method would set def->nhosts before allocating def->hosts. If the allocation failed due to OOM, the cleanup code would crash accessing out of bounds. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If xenParseSxprPCI failed to expand the def->hostdevs array due to OOM, it would free the hostdev instance twice. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The testCompareXMLToXMLHelper method clobbered the 'ret' variable in several places leading to a failure to report OOM errors from the test suite. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The virDomainSnapshotDefParse method assigned to def->ndisks before allocating def->disks. Thus if an OOM occurred, the cleanup code would access out of bounds. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Several places in virInterfaceDefParseProtoIPv6 clobber the default 'ret' return value. So when jumping to cleanup on error, 'ret' may mistakenly be set to 0 instead of -1. This caused failure to report OOM errors, meaning data was silently lost during parsing. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The methods for obtaining the Xen dom ID cannot distinguish between returning -1 due to an error and returning -1 due to the domain being shutoff. Change them to return the dom ID via an output parameter. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The xenParseSxpr method sets def->nconsoles to 1 before allocating the def->consoles array. If the allocation fails due to OOM the cleanup code will thus crash accessing out of bounds. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 25 9月, 2013 30 次提交
-
-
由 Hongwei Bi 提交于
Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrange 提交于
If an OOM occurs in xenFormatXM when formatting to the serial device value, the value is leaked. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If an OOM occurs when xenFormatXM is setting the 'hpet' variable it is silently ignored. Fix it to propagate to the callers. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The xenParseXM sets def->nconsoles to 1 before claling VIR_REALLOC_N on def->consoles. So if the alloc fails due to OOM, the cleanup code will crash accessing a console that does not exist. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If an OOM occurs in xenParseXM, a virDomainChrDef may be leaked. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If qemuParseCommandLine finds an arg it does not understand it adds it to the QEMU passthrough custom arg list. If the qemuParseCommandLine method hits an error for any reason though, it just does 'VIR_FREE(cmd)' on the custom arg list. This means all actual args / env vars are leaked. Introduce a qemuDomainCmdlineDefFree method to be used for cleanup. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If the call to virDomainControllerInsert fails in qemuParseCommandLine, the controller struct is leaked. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The 'qemuStringToArgvEnv' method splits up a string of command line env/args to an 'arglist' array. It then copies env vars to a 'progenv' array and args to a 'progargv' array. When copyin the env vars, it NULL-ifies the element in 'arglist' that is copied. Upon OOM the 'virStringListFree' is called on progenv and arglist. Unfortunately, because the elements in 'arglist' related to env vars have been set to NULL, the call to virStringListFree(arglist) doesn't free anything, even though some non-NULL args vars still exist later in the array. To fix this leak, stop NULL-ifying the 'arglist' elements, and change the cleanup code to only free elements in the 'arglist' array, not 'progenv'. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
In a number of places in qemuParseCommandLineDisk, an error is reported, but no 'goto error' jump is used. This causes failure to report OOM conditions to the caller. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If OOM occurs in qemuParseCommandLineDisk some intermediate variables will be leaked when parsing Sheepdog or RBD disks. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The qemuBuildCommandLine code for parsing sound cards will leak an intermediate variable if an OOM occurs. Move the free'ing of the variable earlier to avoid the leak. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
In qemuParseNBDString, if the virURIParse fails, the error is not reported to the caller. Instead execution falls through to the non-URI codepath causing memory leaks later on. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If qemuAddRBDHost fails due to parsing problems or OOM, then qemuParseRBDString cleanup is skipped causing a memory leak. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
qemuDomainPCIAddressGetNextSlot has a loop for finding compatible PCI buses. In the loop body it creates a PCI address string, but never frees this. This causes a leak if the loop executes more than one iteration, or if a call in the loop body fails. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If virBitmapNew fails due to OOM, the 'vcpupin' variable is leaked. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If the virBitmapParse method fails due to OOM, we leak the 'tmp' variable string. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If virDomainSoundCodecDefParseXML returns an error (eg due to OOM), then the xml nodeset codecNodes is leaked. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If virDomainVcpuPinDefArrayFree is called with def != NULL, but nvcpupin == 0, then it leaks memory for 'def'. This is an unusual scenario, but it hits when cleaning up after an OOM during parsing of XML. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Laine Stump 提交于
This resolves one of the issues listed in: https://bugzilla.redhat.com/show_bug.cgi?id=1003983 00:1E.0 is the location of this controller on at least some actual Q35 hardware, so we try to replicate the placement. The bridge should work just as well in any other location though, so if 00:1E.0 isn't available, just allow it to be auto-assigned anywhere appropriate.
-
由 Laine Stump 提交于
This will make it simpler to add checks for other types of controllers. This is a prerequisite for patches to resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1003983
-
由 Laine Stump 提交于
This resolves one of the issues in: https://bugzilla.redhat.com/show_bug.cgi?id=1003983 This device is identical to qemu's "intel-hda" device (known as "ich6" in libvirt), but has a different PCI device ID (which matches the ID of the hda audio built into the ich9 chipset, of course). It's not supported in earlier versions of qemu, so it requires a capability bit.
-
由 Laine Stump 提交于
I'm not sure why this code was written to compare the strings that it had just retrieved from an enum->string conversion, rather than just look at the original enum values, but this yields the same results, and is much more efficient (especially as you add more devices). This is a prerequisite for patches to resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1003983
-
由 Laine Stump 提交于
Part of the resolution to: https://bugzilla.redhat.com/show_bug.cgi?id=1003983 Although most devices available in qemu area defined as PCI devices, and strictly speaking should only be attached via a PCI slot, in practice qemu allows them to be attached to a PCIe slot and sometimes this makes sense. For example, The UHCI and EHCI USB controllers are usually attached directly to the PCIe "root complex" (i.e. PCIe slots) on real hardware, so that should be possible for a Q35-based qemu virtual machine as well. We still want to prefer a standard PCI slot when auto-assigning addresses, though, and in general to disallow attaching PCI devices via PCIe slots. This patch makes that possible by adding a new QEMU_PCI_CONNECT_TYPE_EITHER_IF_CONFIG flag. Three things are done with this flag: 1) It is set for the "pcie-root" controller 2) qemuCollectPCIAddress() now has a set of nested switches that set this "EITHER" flag for devices that we want to allow connecting to pcie-root when specifically requested in the config. 3) qemuDomainPCIAddressFlagsCompatible() adds this new flag to the "flagsMatchMask" if the address being checked came from config rather than being newly auto-allocated by libvirt (this knowledge is conveniently already available in the "fromConfig" arg). Now any device having the EITHER flag set can be connected to pcie-root if explicitly requested, but auto-allocated addresses for those devices will still be standard PCI slots instead. This patch only loosens the restrictions on devices that have been specifically requested, but the setup is such that it should be fairly easy to add new devices.
-
由 Laine Stump 提交于
Replace them with switch cases. This will make it more efficient when we add exceptions for more controller types, and other device types. This is a prerequisite for patches to resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1003983
-
由 Laszlo Ersek 提交于
Packets sent by guests on virbrN, *or* by dnsmasq on the same, to - 255.255.255.255/32 (netmask-independent local network broadcast address), or to - 224.0.0.0/24 (local subnetwork multicast range) are never forwarded, hence it is not necessary to masquerade them. In fact we must not masquerade them: translating their source addresses or source ports (where applicable) may confuse receivers on virbrN. One example is the DHCP client in OVMF (= UEFI firmware for virtual machines): http://thread.gmane.org/gmane.comp.bios.tianocore.devel/1506/focus=2640 It expects DHCP replies to arrive from remote source port 67. Even though dnsmasq conforms to that, the destination address (255.255.255.255) and the source address (eg. 192.168.122.1) in the reply allow the UDP masquerading rule to match, which rewrites the source port to or above 1024. This prevents the DHCP client in OVMF from accepting the packet. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=709418Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
-
由 Laszlo Ersek 提交于
The functions - iptablesAddForwardDontMasquerade(), - iptablesRemoveForwardDontMasquerade handle exceptions in the masquerading implemented in the POSTROUTING chain of the "nat" table. Such exceptions should be added as chronologically latest, logically top-most rules. The bridge driver will call these functions beginning with the next patch: some special destination IP addresses always refer to the local subnetwork, even though they don't match any practical subnetwork's netmask. Packets from virbrN targeting such IP addresses are never routed outwards, but the current rules treat them as non-virbrN-destined packets and masquerade them. This causes problems for some receivers on virbrN. Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
-
由 Peter Krempa 提交于
The previous patches added infrastructure to report better errors from monitor in some cases. This patch finalizes this "feature" by enabling this enhanced error reporting on early phases of VM startup. In these phases the possibility of qemu producing a useful error message is really high compared to running it during the whole life cycle. After the start up is complete, the feature is disabled to provide the usual error messages so that users are not confused by possibly irrelevant messages that may be in the domain log. The original motivation to do this enhancement is to capture errors when using VFIO device passthrough, where qemu reports errors after the monitor is initialized and the existing error catching code couldn't catch this producing a unhelpful message: # virsh start test error: Failed to start domain test error: Unable to read from monitor: Connection reset by peer With this change, the message is changed to: # virsh start test error: Failed to start domain test error: internal error: early end of file from monitor: possible problem: qemu-system-x86_64: -device vfio-pci,host=00:1a.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: error, group 8 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver. qemu-system-x86_64: -device vfio-pci,host=00:1a.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to get group 8 qemu-system-x86_64: -device vfio-pci,host=00:1a.0,id=hostdev0,bus=pci.0,addr=0x5: Device 'vfio-pci' could not be initialized
-
由 Peter Krempa 提交于
Change the monitor error code to add the ability to access the qemu log file using a file descriptor so that we can dig in it for a more useful error message. The error is now logged on monitor hangups and overwrites a possible lesser error. A hangup on the monitor usualy means that qemu has crashed and there's a significant chance it produced a useful error message. The functionality will be latent until the next patch.
-
由 Peter Krempa 提交于
Early VM startup errors usually produce a better error message in the machine log file. Currently we were accessing it only when the process exited during certain phases of startup. This will help adding a more comprehensive error extraction for early qemu startup phases. This patch adds infrastructure to keep a file descriptor for the machine log file that will be used in case an error happens.
-
由 Peter Krempa 提交于
Teach the function to skip character device definitions printed by qemu at startup in addition to libvirt log messages and make it usable from outside of qemu_process.c. Also add documentation about the func.
-