- 20 2月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
Some functions were using virDomainDeviceInfo where virDevicePCIAddress would suffice. Some were only using integers for slots and functions, assuming the bus numbers are always 0. Switch from virDomainDeviceInfoPtr to virDevicePCIAddressPtr: qemuPCIAddressAsString qemuDomainPCIAddressCheckSlot qemuDomainPCIAddressReserveAddr qemuDomainPCIAddressReleaseAddr Switch from int slot to virDevicePCIAddressPtr: qemuDomainPCIAddressReserveSlot qemuDomainPCIAddressReleaseSlot qemuDomainPCIAddressGetNextSlot Deleted functions (they would take the same parameters as ReserveAddr/ReleaseAddr do now.) qemuDomainPCIAddressReserveFunction qemuDomainPCIAddressReleaseFunction
-
由 Jiri Denemark 提交于
-
- 19 2月, 2013 2 次提交
-
-
由 Guido Günther 提交于
so we don't try to change uid/git to 0 when probing capabilities.
-
由 Doug Goldstein 提交于
The conversion to qemuCaps dropped the ability with qemu{,-kvm} 1.2 and newer to set the lost tick policy for the PIT. While the -no-kvm-pit-reinjection option is depreacated, it is still supported at least through 1.4, it is better to not lose the functionality.
-
- 14 2月, 2013 2 次提交
-
-
由 Laine Stump 提交于
The qemu driver had been calling virSecurityManagerSetProcessLabel() from a "pre-exec hook" function that is run after the child is forked, but before exec'ing qemu. This is problematic because the uid and gid of the child are set by the security driver, but capabilities are dropped by virCommand - such separation doesn't work; the two operations must be done together or the capabilities do not transfer properly to the child process. This patch switches to using virSecurityManagerSetChildProcessLabel(), which is called prior to virCommandRun() (rather than being called *during* virCommandrun() by the hook function), and doesn't set the UID/GID/security label directly, but instead merely informs virCommand what it should set them all to when the time is appropriate. This lets virCommand choose to do the uid/gid and caps dropping all at the same time if it wants (it does *want* to, but isn't doing so yet; that's for an upcoming patch).
-
由 Laine Stump 提交于
Setting the uid/gid of the child process was the only thing done by the hook function in this case, and that can now be done more simply with virCommandSetUID/GID.
-
- 13 2月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
With the majority of fields in the virQEMUDriverPtr struct now immutable or self-locking, there is no need for practically any methods to be using the QEMU driver lock. Only a handful of helper APIs in qemu_conf.c now need it
-
- 12 2月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The hook scripts used by virCommand must be careful wrt accessing any mutexes that may have been held by other threads in the parent process. With the recent refactoring there are 2 potential flaws lurking, which will become real deadlock bugs once the global QEMU driver lock is removed. Remove use of the QEMU driver lock from the hook function by passing in the 'virQEMUDriverConfigPtr' instance directly. Add functions to the virSecurityManager to be invoked before and after fork, to ensure the mutex is held by the current thread. This allows it to be safely used in the hook script in the child process. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 11 2月, 2013 3 次提交
-
-
由 Daniel P. Berrange 提交于
Currently the APIs for managing the shared disk list take a virHashTablePtr as the primary argument. This is bad because it requires the caller to deal with locking of the QEMU driver. Switch the APIs to take the full virQEMUDriverPtr instance Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Add locking to virSecurityManagerXXX APIs, so that use of the security drivers is internally serialized. This avoids the need to rely on the global driver locks to achieve serialization Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
To enable locking to be introduced to the security manager objects later, turn virSecurityManager into a virObjectLockable class Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 09 2月, 2013 1 次提交
-
-
由 Laine Stump 提交于
From qemu's point of view these are still just tap devices, so there's no reason they shouldn't work with vhost-net; as a matter of fact, Raja Sivaramakrishnan <srajag00@yahoo.com> verified on libvir-list that at least the qemu_command.c part of this patch works: https://www.redhat.com/archives/libvir-list/2012-December/msg01314.html (the hotplug case is extrapolation on my part).
-
- 08 2月, 2013 7 次提交
-
-
由 Daniel P. Berrange 提交于
The 'driver->caps' pointer can be changed on the fly. Accessing it currently requires the global driver lock. Isolate this access in a single helper, so a future patch can relax the locking constraints. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
To enable virCapabilities instances to be reference counted, turn it into a virObject. All cases of virCapabilitiesFree turn into virObjectUnref Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The virCgroupPtr instance APIs are safe to use without locking in the QEMU driver, since all internal state they rely on is immutable. Update the comment to reflect this. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Michal Privoznik 提交于
We are wrapping it in ignore_value() anyway.
-
由 Michal Privoznik 提交于
We are requesting for stderr catching for all cases in virFileWrapperFdNew(). There is no need to have a separate function just to report an error, esp. when we can do it in virFileWrapperFdClose().
-
由 John Ferlan 提交于
The qemuParseGlusterString() replaced dst->src without a VIR_FREE() of what was in there before. The qemuBuildCommandLine() did not properly free the boot_buf depending on various usages. The qemuParseCommandLineDisk() had numerous paths that didn't clean up the virDomainDiskDefPtr def properly. Adjust the logic to go through an error: label before cleanup in order to free the resource.
-
- 06 2月, 2013 12 次提交
-
-
由 John Ferlan 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
Annotate the fields in virQEMUDriverPtr to indicate the locking rules for their use Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Currently the activePciHostdevs, inactivePciHostdevsd and activeUsbHostdevs lists are all implicitly protected by the QEMU driver lock. Now that the lists all inherit from the virObjectLockable, we can make the locking explicit, removing the dependency on the QEMU driver lock for correctness. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
To allow modifications to the lists to be synchronized, convert virPCIDeviceList and virUSBDeviceList into virObjectLockable classes. The locking, however, will not be self-contained. The users of these classes will have to call virObjectLock/Unlock in the critical regions. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Rename all the usbDeviceXXX and usbXXXDevice APIs to have a fixed virUSBDevice name prefix
-
由 Daniel P. Berrange 提交于
When iterating over USB host devices to setup cgroups, the usbDevice object was leaked in both LXC and QEMU driers Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Rename all the pciDeviceXXX and pciXXXDevice APIs to have a fixed virPCIDevice name prefix
-
由 Daniel P. Berrange 提交于
The QEMU driver struct has a 'qemuVersion' field that was previously used to cache the version lookup from capabilities. With the recent QEMU capabilities rewrite the caching happens at a lower level so this field is pointless. Removing it avoids worries about locking when updating it. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Use atomic ops to increment nextvmid and encapsulate it in a method to prevent accidental non-atomic access
-
由 Daniel P. Berrange 提交于
The duplicate VM checking should be done atomically with virDomainObjListAdd, so shoud not be a separate function. Instead just use flags to indicate what kind of checks are required. This pair, used in virDomainCreateXML: if (virDomainObjListIsDuplicate(privconn->domains, def, 1) < 0) goto cleanup; if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, false))) goto cleanup; Changes to if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, VIR_DOMAIN_OBJ_LIST_ADD_CHECK_LIVE, NULL))) goto cleanup; This pair, used in virDomainRestoreFlags: if (virDomainObjListIsDuplicate(privconn->domains, def, 1) < 0) goto cleanup; if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, true))) goto cleanup; Changes to if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, VIR_DOMAIN_OBJ_LIST_ADD_LIVE | VIR_DOMAIN_OBJ_LIST_ADD_CHECK_LIVE, NULL))) goto cleanup; This pair, used in virDomainDefineXML: if (virDomainObjListIsDuplicate(privconn->domains, def, 0) < 0) goto cleanup; if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, false))) goto cleanup; Changes to if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, 0, NULL))) goto cleanup;
-
由 Eric Blake 提交于
Otherwise, we get a lot of scary (but harmless) noise in the logs: 2013-02-05 15:35:48.555+0000: 8637: error : qemuMonitorJSONCheckError:353 : internal error unable to execute QEMU command 'add-fd': Parameter 'fdset-id' expects an existing fdset-id one for every qemu 1.2 binary that we probe. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONAddFd): During probe, avoid logging failures.
-
- 05 2月, 2013 5 次提交
-
-
由 Daniel P. Berrange 提交于
As a step towards making virDomainObjList thread-safe turn it into an opaque virObject, preventing any direct access to its internals. As part of this a new method virDomainObjListForEach is introduced to replace all existing usage of virHashForEach
-
由 Daniel P. Berrange 提交于
The APIs names for accessing the domain list object are very inconsistent. Rename them all to have a standard virDomainObjList prefix.
-
由 Daniel P. Berrange 提交于
Currently the virQEMUDriverPtr struct contains an wide variety of data with varying access needs. Move all the static config data into a dedicated virQEMUDriverConfigPtr object. The only locking requirement is to hold the driver lock, while obtaining an instance of virQEMUDriverConfigPtr. Once a reference is held on the config object, it can be used completely lockless since it is immutable. NB, not all APIs correctly hold the driver lock while getting a reference to the config object in this patch. This is safe for now since the config is never updated on the fly. Later patches will address this fully. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Michal Privoznik 提交于
If a compression binary prints something to stderr, currently it is discarded. However, it can contain useful data from debugging POV, so we should catch it.
-
由 Michal Privoznik 提交于
If a decompression binary prints something to stderr, currently it is discarded. However, it can contain useful data from debugging POV, so we should catch it.
-
- 01 2月, 2013 2 次提交
-
-
由 Stefan Berger 提交于
Add support for QEMU -add-fd command line parameter detection. This intentionally rejects qemu 1.2, where 'add-fd' QMP did not allow full control of set ids, and where there was no command line counterpart, but accepts qemu 1.3. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Add entry points for calling the qemu 'add-fd' and 'remove-fd' monitor commands. There is no entry point for 'query-fdsets'; the assumption is that a developer can use virsh qemu-monitor-command domain '{"execute":"query-fdsets"}' when debugging issues, and that meanwhile, libvirt is responsible enough to remember what fds it associated with what fdsets. Likewise, on the 'add-fd' command, it is assumed that libvirt will always pass a set id, rather than letting qemu autogenerate the next available id number. * src/qemu/qemu_monitor.c (qemuMonitorAddFd, qemuMonitorRemoveFd): New functions. * src/qemu/qemu_monitor.h (qemuMonitorAddFd, qemuMonitorRemoveFd): New prototypes. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONAddFd) (qemuMonitorJSONRemoveFd): New functions. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONAddFd) (qemuMonitorJSONRemoveFd): New prototypes.
-
- 29 1月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=894723 Currently, if qemuProcessStart() succeeds, but it's decompression binary that returns nonzero status, we don't kill the qemu process, but remove it from internal domain list, leaving the qemu process hanging around totally uncontrolled.
-
- 27 1月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=892289 It seems like with new udev within guest OS, the tray is locked, so we need to: - 'eject' - wait for tray to open - 'change' Moreover, even when doing bare 'eject', we should check for 'tray_open' as guest may have locked the tray. However, the waiting phase shouldn't be unbounded, so I've chosen 10 retries maximum, each per 500ms. This should give enough time for guest to eject a media and open the tray.
-