- 21 10月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
When running setuid, we must be careful about what env vars we allow commands to inherit from us. Replace the virCommandAddEnvPass function with two new ones which do filtering virCommandAddEnvPassAllowSUID virCommandAddEnvPassBlockSUID And make virCommandAddEnvPassCommon use the appropriate ones Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 17 10月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
QEMU has support for SASL auth for SPICE guests, but libvirt has no way to enable it. Following the example from VNC where it is globally enabled via qemu.conf Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 15 10月, 2013 4 次提交
-
-
由 Peter Krempa 提交于
-
由 Ján Tomko 提交于
Introduced by 1fa7946f. https://bugzilla.redhat.com/show_bug.cgi?id=1019023
-
由 Eric Blake 提交于
'const fooPtr' is the same as 'foo * const' (the pointer won't change, but it's contents can). But in general, if an interface is trying to be const-correct, it should be using 'const foo *' (the pointer is to data that can't be changed). Fix up offenders in src/qemu. * src/qemu/qemu_bridge_filter.h (networkAllowMacOnPort) (networkDisallowMacOnPort): Use intended type. * src/qemu/qemu_bridge_filter.c (networkAllowMacOnPort) (networkDisallowMacOnPort): Likewise. * src/qemu/qemu_command.c (qemuBuildTPMBackendStr) (qemuBuildTPMDevStr, qemuBuildCpuArgStr) (qemuBuildObsoleteAccelArg, qemuBuildMachineArgStr) (qemuBuildSmpArgStr, qemuBuildNumaArgStr): Likewise. * src/qemu/qemu_conf.c (qemuSharedDeviceEntryCopy): Likewise. * src/qemu/qemu_driver.c (qemuDomainSaveImageStartVM): Likewise. * src/qemu/qemu_hostdev.c (qemuDomainHostdevNetConfigVirtPortProfile): Likewise. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONAttachCharDevCommand): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
virDomainChrGetDomainPtrs() required 4 levels of pointers (taking a parameter that will be used as an output variable to return the address of another variable that contains an array of pointers). This is rather complex to reason about, especially when outside of the domain_conf file, no other caller should be modifying the resulting array of pointers directly. Changing the public signature gives something is easier to reason with, and actually make const-correct; which is important as it was the only function that was blocking virDomainDeviceDefCopy from treating its source as const. * src/conf/domain_conf.h (virDomainChrGetDomainPtrs): Use simpler types, and make const-correct for external users. * src/conf/domain_conf.c (virDomainChrGetDomainPtrs): Split... (virDomainChrGetDomainPtrsInternal): ...into an internal version that lets us modify terms, vs. external form that is read-only. (virDomainDeviceDefPostParseInternal, virDomainChrFind) (virDomainChrInsert): Adjust callers. * src/qemu/qemu_command.c (qemuGetNextChrDevIndex): Adjust caller. (qemuDomainDeviceAliasIndex): Make const-correct. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 10 10月, 2013 1 次提交
-
-
由 Peter Krempa 提交于
Prefer using VFIO (if available) to the legacy KVM device passthrough. With this patch a PCI passthrough device without the driver configured will be started with VFIO if it's available on the host. If not legacy KVM passthrough is checked and error is reported if it's not available.
-
- 08 10月, 2013 1 次提交
-
-
由 Peter Krempa 提交于
To simplify future patches dealing with this code, simplify and refactor some conditions to switch statements.
-
- 03 10月, 2013 1 次提交
-
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1012824 https://bugzilla.redhat.com/show_bug.cgi?id=1012834 Note that a similar problem was reported in: https://bugzilla.redhat.com/show_bug.cgi?id=827519 but the fix only worked for <interface type='hostdev'>, *not* for <interface type='network'> where the network itself was a pool of hostdevs. The symptom in both cases was this error message: internal error: Unable to determine device index for network device In both cases the cause was lack of proper handling for netdevs (<interface>) of type='hostdev' when scanning the netdev list looking for alias names in qemuAssignDeviceNetAlias() - those that aren't type='hostdev' have an alias of the form "net%d", while those that are hostdev use "hostdev%d". This special handling was completely lacking prior to the fix for Bug 827519 which was: When searching for the highest alias index, libvirt looks at the alias for each netdev and if it is type='hostdev' it ignores the entry. If the type is not hostdev, then it expects the "net%d" form; if it doesn't find that, it fails and logs the above error message. That fix works except in the case of <interface type='network'> where the network uses hostdev (i.e. the network is a pool of VFs to be assigned to the guests via PCI passthrough). In this case, the check for type='hostdev' would fail because it was done as: def->net[i]->type == VIR_DOMAIN_NET_TYPE_HOSTDEV (which compares what was written in the config) when it actually should have been: virDomainNetGetActualType(def->net[i]) == VIR_DOMAIN_NET_TYPE_HOSTDEV (which compares the type of netdev that was actually allocated from the network at runtime). Of course the latter wouldn't be of any use if the netdevs of type='network' hadn't already acquired their actual network connection yet, but manual examination of the code showed that this is never the case. While looking through qemu_command.c, two other places were found to directly compare the net[i]->type field rather than getting actualType: * qemuAssignDeviceAliases() - in this case, the incorrect comparison would cause us to create a "net%d" alias for a netdev with type='network' but actualType='hostdev'. This alias would be subsequently overwritten by the proper "hostdev%d" form, so everything would operate properly, but a string would be leaked. This patch also fixes this problem. * qemuAssignDevicePCISlots() - would defer assigning a PCI address to a netdev if it was type='hostdev', but not for type='network + actualType='hostdev'. In this case, the actual device usually hasn't been acquired yet anyway, and even in the case that it has, there is no practical difference between assigning a PCI address while traversing the netdev list or while traversing the hostdev list. Because changing it would be an effective NOP (but potentially cause some unexpected regression), this usage was left unchanged.
-
- 25 9月, 2013 15 次提交
-
-
由 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>
-
由 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
-
- 24 9月, 2013 8 次提交
-
-
由 Daniel P. Berrange 提交于
The parsing of '-usb' did not check for failure of the virDomainControllerInsert method. As a result on OOM, the parser mistakenly attached USB disks to the IDE controller. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The code formatting NUMA args was ignoring the return value of virBitmapFormat, so on OOM, it would silently drop the NUMA cpumask arg. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When building boot menu args, if OOM occurred the CLI args would end up containing 'order=(null)' due to a missing call to 'virBufferError'. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The qemuParseCommandLine method did not check the return value of virStringSplit to see if OOM had occurred. This lead to dereference of a NULL pointer on OOM. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Most callers of qemuParseKeywords were assigning its return value to a 'size_t' variable. Then then also checked '< 0' for error condition, but this will never be true with the unsigned size_t variable. Rather than using 'ssize_t', change qemuParseKeywords so that the element count is returned via an output parameter, leaving the return value solely as an error indicator. This avoids a crash accessing beyond the end of an error upon OOM. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
In commit 41b55056 Author: Eric Blake <eblake@redhat.com> Date: Wed Aug 28 15:01:23 2013 -0600 qemu: simplify list cleanup The qemuStringToArgvEnv method was changed to use virStringFreeList to free the 'arglist' array. This method assumes the string list array is NULL terminated, however, qemuStringToArgvEnv was not ensuring this when populating 'arglist'. This caused an out of bounds access by virStringFreeList when OOM occured in the initial loop of qemuStringToArgvEnv Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When parsing the RBD hosts, it increments the 'nhosts' counter before increasing the 'hosts' array allocation. If an OOM then occurs when increasing the array allocation, the cleanup block will attempt to access beyond the end of the array. Switch to using VIR_EXPAND_N instead of VIR_REALLOC_N to protect against this mistake Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If OOM occurs in qemuDomainCCWAddressSetCreate, it jumps to a cleanup block and frees the partially initialized object. It then mistakenly returns the address of the just free'd pointer instead of NULL. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 20 9月, 2013 1 次提交
-
-
由 Laine Stump 提交于
This resolves https://bugzilla.redhat.com/show_bug.cgi?id=1008903 The Q35 machinetype has an implicit SATA controller at 00:1F.2 which isn't given the "expected" id of ahci0 by qemu when it's created. The original suggested solution to this problem was to not specify any controller for the disks that use the default controller and just specify "unit=n" instead; qemu should then use the first IDE or SATA controller for the disk. Unfortunately, this "solution" is ignorant of the fact that in the case of SATA disks, the "unit" attribute in the disk XML is actually *not* being used for the unit, but is instead used to specify the "bus" number; each SATA controller has 6 buses, and each bus only allows a single unit. This makes it nonsensical to specify unit='n' where n is anything other than 0. It also means that the only way to connect more than a single device to the implicit SATA controller is to explicitly give the bus names, which happen to be "ide.$n", where $n can be replaced by the disk's "unit" number.
-
- 17 9月, 2013 3 次提交
-
-
由 Aline Manera 提交于
qemu/KVM also supports a tftp URL while specifying the cdrom ISO image. The xml should be as following: <disk type='network' device='cdrom'> <source protocol='tftp' name='/url/path'> <host name='host.name' port='69'/> </source> </disk> Signed-off-by: NAline Manera <alinefm@br.ibm.com>
-
由 Aline Manera 提交于
The ftps protocol is another protocol supported by qemu/KVM while specifying the cdrom ISO image. The xml should be as following: <disk type='network' device='cdrom'> <source protocol='ftps' name='/url/path'> <host name='host.name' port='990'/> </source> </disk> Signed-off-by: NAline Manera <alinefm@br.ibm.com>
-
由 Aline Manera 提交于
The https protocol is also accepted by qemu/KVM when specifying the cdrom ISO image. The xml should be as following: <disk type='network' device='cdrom'> <source protocol='https' name='/url/path'> <host name='host.name' port='443'/> </source> </disk> Signed-off-by: NAline Manera <alinefm@br.ibm.com>
-
- 09 9月, 2013 1 次提交
-
-
由 Li Zhang 提交于
Currently, only X86 provides users CPU features with CPUID instruction. If users specify the features for non-x86, it should tell users to remove them. This patch is to report one error if features are specified by users for non-x86 platform. Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
-
- 06 9月, 2013 2 次提交
-
-
由 Eric Blake 提交于
In Fedora 19, 'qemu-kvm' is a simple wrapper that calls 'qemu-system-x86_64 -machine accel=kvm'. Attempting to use 'virsh qemu-attach $pid' to a machine started as: qemu-kvm -cdrom /var/lib/libvirt/images/foo.img \ -monitor unix:/tmp/demo,server,nowait -name foo \ --uuid cece4f9f-dff0-575d-0e8e-01fe380f12ea was failing with: error: XML error: No PCI buses available because we did not see 'kvm' in the executable name read from /proc/$pid/cmdline, and tried to assign os.machine as "accel=kvm" instead of "pc"; this in turn led to refusal to recognize the pci bus. Noticed while investigating https://bugzilla.redhat.com/995312 although there are still other issues to fix before that bug will be completely solved. I've concluded that the existing parser code for native-to-xml is a horrendous hodge-podge of ad-hoc approaches; I basically rewrote the -machine section to be a bit saner. * src/qemu/qemu_command.c (qemuParseCommandLine): Don't assume -machine argument is always appropriate for os.machine; set virtType if accel is present. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
'virsh domxml-from-native' and 'virsh qemu-attach' could misbehave for an emulator installed in (a somewhat unlikely) location such as /usr/local/qemu-1.6/qemu-system-x86_64 or (an even less likely) /opt/notxen/qemu-system-x86_64. Limit the strstr seach to just the basename of the file where we are assuming details about the binary based on its name. While testing, I accidentally triggered a core dump during strcmp when I forgot to set os.type on one of my code paths; this patch changes such a coding error to raise a nicer internal error instead. * src/qemu/qemu_command.c (qemuParseCommandLine): Compute basename earlier. * src/conf/domain_conf.c (virDomainDefPostParseInternal): Avoid NULL deref. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 05 9月, 2013 1 次提交
-
-
由 Li Zhang 提交于
CPU features are not supported on non-x86 and hasFeatures will be NULL. This patch is to remove CPU features functions calling to avoid errors. Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
-