- 25 5月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
Extract whether a given drive has a tray and whether there is no image inserted. Negative logic for the image insertion is chosen so that the flag is set only if we are certain of the fact.
-
- 20 5月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
It was only called for QEMUs without QEMU_CAPS_DEVICE, which we no longer support.
-
- 17 5月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Recent adjustments to the code produced a litany of coverity false positives, but only because the "standard" procedure of setting a variable to NULL after it was assigned to something else and keeping the *Free/*FREE call in the cleanup path wasn't kept. So this patch makes those adjustments (assign variable to NULL and remove the if 'ret < 0' condition to clean it up). Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 09 5月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
In 7884d089 I've started to refactor qemu_monitor_json.c. Thing is, it's current structure is nothing like the rest of our code. The @ret variable is rewritten all the time, if()-s are nested instead of using goto and so on. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 05 5月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 03 5月, 2016 4 次提交
-
-
由 Michal Privoznik 提交于
In majority of our functions we have this variable @ret that is overwritten a lot. In other areas of the code we use 'goto cleanup;' just so that this wouldn't happen. But here. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
In these functions I'm fixing here, we do call qemuMonitorJSONCheckError() followed by another check if qemu reply contains 'return' object. If it wouldn't, the former CheckError() function would error out and the flow would not even get to the latter. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Usually, the flow in this area of the code is as follows: qemuMonitorJSONMakeCommand() qemuMonitorJSONCommand() qemuMonitorJSONCheckError() parseReply() But in this function, for some reasons, the last two steps were swapped. This makes no sense. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 02 5月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Code was obsoleted by using -device.
-
- 20 4月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
QEMU introduced the query-gic-capabilities QMP command with commit 4468d4e0f383: use the command, if available, to probe available GIC capabilities. The information obtained is stored in a virQEMUCaps instance, and will be later used to fill in a virDomainCaps instance.
-
- 14 4月, 2016 1 次提交
-
-
由 ShaoHe Feng 提交于
Signed-off-by: NShaoHe Feng <shaohe.feng@intel.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
- 13 4月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
The event is emitted on ACPI OSPM Status Indication events. ACPI standard documentation describes the method as: This object is an optional control method that is invoked by OSPM to indicate processing status to the platform. During device ejection, device hot add, or other event processing, OSPM may need to perform specific handshaking with the platform. OSPM may also need to indicate to the platform its inability to complete a requested operation; for example, when a user presses an ejection button for a device that is currently in use or is otherwise currently incapable of being ejected. In this case, the processing of the ACPI Eject Request notification by OSPM fails. OSPM may indicate this failure to the platform through the invocation of the _OST control method. As a result of the status notification indicating ejection failure, the platform may take certain action including reissuing the notification or perhaps turning on an appropriate indicator light to signal the failure to the user.
-
- 29 3月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
qemu won't ever add those functions directly to QMP. They will be replaced with 'blockdev-add' and 'blockdev-del' eventually. At this time there's no need to keep the stubs around. Additionally the drive_del stub in JSON contained dead code in the attempt to report errors. (VIR_ERR_OPERATION_UNSUPPORTED was never reported). Since the text impl does have the same message it is reported anyways.
-
- 22 3月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
QEMU changed the error message to: "Tray of device 'drive-sata0-0-1' is not open" and they may change the error massage in the future. This updates the code to not depend on the text from the error message but only on error itself. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 21 3月, 2016 2 次提交
-
-
由 Cristian Klein 提交于
Signed-off-by: NCristian Klein <cristiklein@gmail.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Migration enters "postcopy-active" state after QEMU switches to post-copy and pauses guest CPUs. From libvirt's point of view this state is similar to "completed" because we need to transfer guest execution to the destination host. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 01 3月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
This attribute is used to extend secondary PCI bar and expose it to the guest as 64bit memory. It works like this: attribute vram is there to set size of secondary PCI bar and guest sees it as 32bit memory, attribute vram64 can extend this secondary PCI bar. If both attributes are used, guest sees two memory bars, both address the same memory, with the difference that the 32bit bar can address only the first part of the whole memory. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260749Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 11 2月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Extract out the qemuParseCommandLine{String|Pid} into their own separate module - taking with it all the various static functions. Causes a ripple effect with a few other modules to include the new qemu_parse_command.h. Narrowed down the list of #include's in the split out module to those that are necessary for build.
-
- 21 1月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
The corresponding event in QEMU is called MIGRATION_PASS. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 09 1月, 2016 3 次提交
-
-
由 Jiri Denemark 提交于
memory_dirty_rate corresponds to dirty-pages-rate in QEMU and memory_iteration is what QEMU reports in dirty-sync-count. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The enum will be called qemuMonitorMigrationStatus. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The structure actually contains migration statistics rather than just the status as the name suggests. Renaming it as qemuMonitorMigrationStats removes the confusion. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 15 12月, 2015 2 次提交
-
-
由 Pavel Hrdina 提交于
Commit 256496e1 introduced a detection if "is locked" in error replay from qemu monitor. Commit c4073657 fixed a memory leak, but it was pointed out by Peter, that this could be done cleaner without stringifing the replay. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Michal Privoznik 提交于
The return value of virJSONValueToString() should be freed when no longer needed. This is not the case after 256496e1. ==26902== 138 bytes in 2 blocks are definitely lost in loss record 1,051 of 1,239 ==26902== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26902== by 0xAA5F599: strdup (in /lib64/libc-2.21.so) ==26902== by 0x552BAD9: virStrdup (virstring.c:726) ==26902== by 0x54F60A7: virJSONValueToString (virjson.c:1790) ==26902== by 0x1DF6EBB9: qemuMonitorJSONEjectMedia (qemu_monitor_json.c:2225) ==26902== by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985) ==26902== by 0x1DF1EF2D: qemuDomainChangeEjectableMedia (qemu_hotplug.c:199) ==26902== by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985) ==26902== by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030) ==26902== by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677) ==26902== by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559) ==26902== by 0x134210: remoteDispatchDomainUpdateDeviceFlags (remote_dispatch.h:10966) ==26902== 106 bytes in 1 blocks are definitely lost in loss record 1,033 of 1,239 ==26902== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26902== by 0xAA5F599: strdup (in /lib64/libc-2.21.so) ==26902== by 0x552BAD9: virStrdup (virstring.c:726) ==26902== by 0x54F60A7: virJSONValueToString (virjson.c:1790) ==26902== by 0x1DF6EC0C: qemuMonitorJSONEjectMedia (qemu_monitor_json.c:2227) ==26902== by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985) ==26902== by 0x1DF1EF2D: qemuDomainChangeEjectableMedia (qemu_hotplug.c:199) ==26902== by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985) ==26902== by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030) ==26902== by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677) ==26902== by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559) ==26902== by 0x134210: remoteDispatchDomainUpdateDeviceFlags (remote_dispatch.h:10966) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 09 12月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
Let the function report errors internally and change it to return standard return codes.
-
- 19 11月, 2015 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 09 10月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
The internal representation of a JSON array counts the items in size_t. However, for some reason, when asking for the count it's reported as int. Firstly, we need the function to return a signed type as it's returning -1 on an error. But, not every system has integer the same size as size_t. Therefore, lets return ssize_t. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 26 9月, 2015 1 次提交
-
-
由 Shivangi Dhir 提交于
Earlier virtType was of type int. After, introducing the enum VIR_DOMAIN_VIRT_NONE, the type of virtType is modified to virDomainVirtType.
-
- 21 7月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
Few parts of the code looked at the current progress of and assumed that a two phase blockjob is in the _READY state as soon as the progress reached 100% (info.cur == info.end). In current versions of qemu this assumption is invalid and qemu exposes a new flag 'ready' in the query-block-jobs output that is set to true if the job is actually finished. This patch adds internal data handling for reading the 'ready' flag and acting appropriately as long as the flag is present. While this still doesn't fix the virsh client problem with two phase block jobs and the --pivot option, it at least improves the error message: $ virsh blockcommit --wait --verbose vm vda --base vda[1] --active --pivot Block commit: [100 %]error: failed to pivot job for disk vda error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed to $ virsh blockcommit --wait --verbose VM vda --base vda[1] --active --pivot Block commit: [100 %]error: failed to pivot job for disk vda error: block copy still active: disk 'vda' not ready for pivot yet
-
- 10 7月, 2015 2 次提交
-
-
由 Jiri Denemark 提交于
Thanks to Juan's work QEMU finally emits an event whenever migration state changes. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Pavel Hrdina 提交于
Modify the eject monitor functions to parse the return code and detect, whether the error contains "is locked" to report this type of failure to upper layers. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 30 6月, 2015 2 次提交
-
-
由 Peter Krempa 提交于
Get rid of spice specific stuff from the handler func and save a few lines by reflowing the conditions.
-
由 Peter Krempa 提交于
Spice events have mostly similar information present in the event JSON but they differ in the name of the element containing the port. The JSON event also provides connection ID which might be useful in the future. This patch splits up the event parser code into two functions and the SPICE reimplements the event parsing with correct names and drops the VNC only stuff. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1236585
-
- 26 6月, 2015 3 次提交
-
-
由 Peter Krempa 提交于
Now that qemuMonitorGetAllBlockStatsInfo collects also wr_highest_offset the whole function can be killed.
-
由 Peter Krempa 提交于
Instead of using qemuMonitorJSONDevGetBlockExtent (which I plan to remove later) extract the data in place. Additionally add a flag that will be set when the wr_highest_offset was extracted correctly so that callers can act according to that. The test case addition should help make sure that everything works.
-
由 Peter Krempa 提交于
-
- 24 6月, 2015 1 次提交
-
-
由 Boris Fiuczynski 提交于
This patch provides support for a new watchdog action "inject-nmi" which allows to define an inject of a non-maskable interrupt into a guest. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com> Reviewed-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com>
-
- 23 6月, 2015 1 次提交
-
-
由 Eric Blake 提交于
Rather than grabbing an arbitrary JSON value and then checking if it has the right type, we might as well request the correct type to begin with. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONIOProcessEvent) (qemuMonitorJSONCommandWithFd, qemuMonitorJSONHandleGraphics) (qemuMonitorJSONGetStatus, qemuMonitorJSONExtractCPUInfo) (qemuMonitorJSONGetVirtType, qemuMonitorJSONGetBalloonInfo) (qemuMonitorJSONGetMemoryStats) (qemuMonitorJSONDevGetBlockExtent) (qemuMonitorJSONGetOneBlockStatsInfo) (qemuMonitorJSONGetAllBlockStatsInfo) (qemuMonitorJSONBlockStatsUpdateCapacityOne) (qemuMonitorJSONBlockStatsUpdateCapacity) (qemuMonitorJSONGetBlockExtent) (qemuMonitorJSONGetMigrationStatusReply) (qemuMonitorJSONGetDumpGuestMemoryCapability) (qemuMonitorJSONAddFd, qemuMonitorJSONQueryRxFilterParse) (qemuMonitorJSONExtractChardevInfo) (qemuMonitorJSONDiskNameLookupOne) (qemuMonitorJSONDiskNameLookup) (qemuMonitorJSONGetAllBlockJobInfo) (qemuMonitorJSONBlockIoThrottleInfo, qemuMonitorJSONGetVersion) (qemuMonitorJSONGetMachines, qemuMonitorJSONGetCPUDefinitions) (qemuMonitorJSONGetCommands, qemuMonitorJSONGetEvents) (qemuMonitorJSONGetKVMState, qemuMonitorJSONGetObjectTypes) (qemuMonitorJSONGetObjectListPaths) (qemuMonitorJSONGetObjectProps, qemuMonitorJSONGetTargetArch) (qemuMonitorJSONGetMigrationCapabilities) (qemuMonitorJSONGetStringArray, qemuMonitorJSONAttachCharDev) (qemuMonitorJSONGetCPUx86Data, qemuMonitorJSONGetIOThreads) (qemuMonitorJSONGetMemoryDeviceInfo): Use shorter idioms. Signed-off-by: NEric Blake <eblake@redhat.com>
-