- 18 12月, 2018 3 次提交
-
-
由 Daniel Henrique Barboza 提交于
The qmp/hmp command 'system_wakeup' is simply a direct call to 'qemu_system_wakeup_request' from vl.c. This function verifies if runstate is SUSPENDED and if the wake up reason is valid before proceeding. However, no error or warning is thrown if any of those pre-requirements isn't met. There is no way for the caller to differentiate between a successful wakeup or an error state caused when trying to wake up a guest that wasn't suspended. This means that system_wakeup is silently failing, which can be considered a bug. Adding error handling isn't an API break in this case - applications that didn't check the result will remain broken, the ones that check it will have a chance to deal with it. Adding to that, the commit before previous created a new QMP API called query-current-machine, with a new flag called wakeup-suspend-support, that indicates if the guest has the capability of waking up from suspended state. Although such guest will never reach SUSPENDED state and erroring it out in this scenario would suffice, it is more informative for the user to differentiate between a failure because the guest isn't suspended versus a failure because the guest does not have support for wake up at all. All this considered, this patch changes qmp_system_wakeup to check if the guest is capable of waking up from suspend, and if it is suspended. After this patch, this is the output of system_wakeup in a guest that does not have wake-up from suspend support (ppc64): (qemu) system_wakeup wake-up from suspend is not supported by this guest (qemu) And this is the output of system_wakeup in a x86 guest that has the support but isn't suspended: (qemu) system_wakeup Unable to wake up: guest is not in suspended state (qemu) Reported-by: NBalamuruhan S <bala24@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20181205194701.17836-4-danielhb413@gmail.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Daniel Henrique Barboza 提交于
When issuing the qmp/hmp 'system_wakeup' command, what happens in a nutshell is: - qmp_system_wakeup_request set runstate to RUNNING, sets a wakeup_reason and notify the event - in the main_loop, all vcpus are paused, a system reset is issued, all subscribers of wakeup_notifiers receives a notification, vcpus are then resumed and the wake up QAPI event is fired Note that this procedure alone doesn't ensure that the guest will awake from SUSPENDED state - the subscribers of the wake up event must take action to resume the guest, otherwise the guest will simply reboot. At this moment, only the ACPI machines via acpi_pm1_cnt_init and xen_hvm_init have wake-up from suspend support. However, only the presence of 'system_wakeup' is required for QGA to support 'guest-suspend-ram' and 'guest-suspend-hybrid' at this moment. This means that the user/management will expect to suspend the guest using one of those suspend commands and then resume execution using system_wakeup, regardless of the support offered in system_wakeup in the first place. This patch creates a new API called query-current-machine [1], that holds a new flag called 'wakeup-suspend-support' that indicates if the guest supports wake up from suspend via system_wakeup. The machine is considered to implement wake-up support if a call to a new 'qemu_register_wakeup_support' is made during its init, as it is now being done inside acpi_pm1_cnt_init and xen_hvm_init. This allows for any other machine type to declare wake-up support regardless of ACPI state or wakeup_notifiers subscription, making easier for newer implementations that might have their own mechanisms in the future. This is the expected output of query-current-machine when running a x86 guest: {"execute" : "query-current-machine"} {"return": {"wakeup-suspend-support": true}} Running the same x86 guest, but with the --no-acpi option: {"execute" : "query-current-machine"} {"return": {"wakeup-suspend-support": false}} This is the output when running a pseries guest: {"execute" : "query-current-machine"} {"return": {"wakeup-suspend-support": false}} With this extra tool, management can avoid situations where a guest that does not have proper suspend/wake capabilities ends up in inconsistent state (e.g. https://github.com/open-power-host-os/qemu/issues/31). [1] the decision of creating the query-current-machine API is based on discussions in the QEMU mailing list where it was decided that query-target wasn't a proper place to store the wake-up flag, neither was query-machines because this isn't a static property of the machine object. This new API can then be used to store other dynamic machine properties that are scattered around the code ATM. More info at: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04235.htmlReported-by: NBalamuruhan S <bala24@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20181205194701.17836-2-danielhb413@gmail.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Dominik Csapak 提交于
This makes it possible to determine what the exact reason was for a RESET or a SHUTDOWN. A management layer might need the specific reason of those events to determine which cleanups or other actions it needs to do. This patch also updates the iotests to the new expected output that includes the reason. Signed-off-by: NDominik Csapak <d.csapak@proxmox.com> Message-Id: <20181205110131.23049-3-d.csapak@proxmox.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> [Commit message tweaked] Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
- 12 12月, 2018 1 次提交
-
-
由 Peter Xu 提交于
Out-of-band command execution was introduced in commit cf869d53. Unfortunately, we ran into a regression, and had to turn it into an experimental option for 2.12 (commit be933ffc). http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg06231.html The regression has since been fixed (commit 951702f3 "monitor: bind dispatch bh to iohandler context"). A thorough re-review of OOB commands led to a few more issues, which have also been addressed. This patch partly reverts be933ffc (monitor: new parameter "x-oob"), and makes QMP monitors again offer capability "oob" whenever they can provide it, i.e. when the monitor's character device is capable of running in an I/O thread. Some trivial touch-up in the test code is required to make sure qmp-test won't break. Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <20181009062718.1914-4-peterx@redhat.com> [Conflict with "monitor: check if chardev can switch gcontext for OOB" resolved, commit message updated] Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
- 27 11月, 2018 3 次提交
-
-
由 Li Qiang 提交于
Cc: qemu-trivial@nongnu.org Signed-off-by: NLi Qiang <liq3ea@gmail.com> Message-Id: <1542276385-7638-1-git-send-email-liq3ea@gmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Li Qiang 提交于
parse_fw_cfg() reports "can't load" without further details. Get the details from g_file_get_contents(), and include them in the error message. Signed-off-by: NLi Qiang <liq3ea@gmail.com> Message-Id: <1541051971-28584-1-git-send-email-liq3ea@gmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Gerd Hoffmann 提交于
Add query-display-options command, which allows querying the qemu display configuration. This isn't particularly useful, except it exposes QAPI type DisplayOptions in query-qmp-schema, so that libvirt can discover recently added -display parameter rendernode (commit d4dc4ab1). Works around lack of sufficiently powerful command line introspection. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Tested-by: NEric Blake <eblake@redhat.com> Tested-by: NErik Skultety <eskultet@redhat.com> Message-id: 20181122071613.2889-1-kraxel@redhat.com [ kraxel: reworded commit message as suggested by armbru ]
-
- 12 11月, 2018 1 次提交
-
-
由 Thomas Huth 提交于
It has been unmaintained since years, and there were only trivial or tree-wide changes to the related files since many years, so the code is likely very bitrotten and broken. For example the following segfaults as soon as as you press a key: qemu-system-x86_64 -usb -device usb-bt-dongle -bt hci -bt device:keyboard Since we are not aware of anybody using bluetooth with the current version of QEMU, let's mark the subsystem as deprecated, with a special request for the users to write to the qemu-devel mailing list in case they still use it (so we could revert the deprecation status in that case). Signed-off-by: NThomas Huth <thuth@redhat.com> Message-id: 1542016830-19189-1-git-send-email-thuth@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 07 11月, 2018 1 次提交
-
-
由 Eric Blake 提交于
A quick coredump on an incomplete command line: ./x86_64-softmmu/qemu-system-x86_64 -mon mode=control,pretty=on #0 0x00007ffff723d9e4 in g_str_hash () at /lib64/libglib-2.0.so.0 #1 0x00007ffff723ce38 in g_hash_table_lookup () at /lib64/libglib-2.0.so.0 #2 0x0000555555cc0073 in object_class_property_find (klass=0x5555566a94b0, name=0x0, errp=0x0) at qom/object.c:1135 #3 0x0000555555cc004b in object_class_property_find (klass=0x5555566a9440, name=0x0, errp=0x0) at qom/object.c:1129 #4 0x0000555555cbfe6e in object_property_find (obj=0x5555568348c0, name=0x0, errp=0x0) at qom/object.c:1080 #5 0x0000555555cc183d in object_resolve_path_component (parent=0x5555568348c0, part=0x0) at qom/object.c:1762 #6 0x0000555555d82071 in qemu_chr_find (name=0x0) at chardev/char.c:802 #7 0x00005555559d77cb in mon_init_func (opaque=0x0, opts=0x5555566b65a0, errp=0x0) at vl.c:2291 Fix it to instead fail gracefully. Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20181023213600.364086-1-eblake@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NPeter Xu <peterx@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
- 05 11月, 2018 2 次提交
-
-
由 Max Reitz 提交于
There is no good reason why there should be a newline in this description, so remove it. Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Max Reitz 提交于
Just like in qemu_opts_print_help(), print the object name as a caption instead of on every single line, indent all options, add angle brackets around types, and align the descriptions after 24 characters. Also, indent every object name in the list of available objects. Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 24 10月, 2018 2 次提交
-
-
由 Igor Mammedov 提交于
commit (5cdc9b76 vl.c: Remove dead assignment) removed sockets calculation when 'sockets' weren't provided on CLI since there wasn't any users for it back then. Exiting checks are neither reachable } else if (sockets * cores * threads < cpus) { or nor triggerable if (sockets * cores * threads > max_cpus) so we weren't noticing wrong topology since then, since users recalculate sockets adhoc on their own. However with deprecation check it becomes noticable, for example -smp 2 will start printing warning: "warning: Invalid CPU topology deprecated: sockets (1) * cores (1) * threads (1) != maxcpus (2)" calculating sockets if they weren't specified. Fix it by returning back sockets calculation if it's omitted on CLI. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Message-Id: <1536836762-273036-3-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
-smp [cpus],sockets/cores/threads[,maxcpus] should describe topology so that total number of logical CPUs [sockets * cores * threads] would be equal to [maxcpus], however historically we didn't have such check in QEMU and it is possible to start VM with an invalid topology. Deprecate invalid options combination so we can make sure that the topology VM started with is always correct in the future. Users with an invalid sockets/cores/threads/maxcpus values should fix their CLI to make sure that [sockets * cores * threads] == [maxcpus] Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <1536836762-273036-2-git-send-email-imammedo@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> [ehabkost: squashed unit test fix] Message-Id: <20181019215345.521d58d7@igors-macbook-pro.local> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 19 10月, 2018 21 次提交
-
-
由 Markus Armbruster 提交于
main() checks for parse_name() failure even though it can't actually fail. That's okay. Simplify it to check by passing &error_fatal, like the other users of qemu_opts_foreach(). Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20181017082702.5581-36-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20181017082702.5581-35-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() from within a function that takes an Error ** argument is suspicious. drive_new() calls error_report() even though it can run within drive_init_func(), which takes an Error ** argument. drive_init_func()'s caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway: * Convert drive_new() to Error * Update add_init_drive() to report the error received from drive_new() * Make main() pass &error_fatal through qemu_opts_foreach(), drive_init_func() to drive_new() * Make default_drive() pass &error_abort through qemu_opts_foreach(), drive_init_func() to drive_new() Cc: Kevin Wolf <kwolf@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20181017082702.5581-34-armbru@redhat.com>
-
由 Markus Armbruster 提交于
If creating (empty) default drives fails, it's a bug. Therefore, assert() is more appropriate than exit(1). Cc: Kevin Wolf <kwolf@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Message-Id: <20181017082702.5581-33-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() from within a function that takes an Error ** argument is suspicious. qemu_fsdev_add() does that, and its caller fsdev_init_func() then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. Cc: Greg Kurz <groug@kaod.org> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Acked-by: NGreg Kurz <groug@kaod.org> Message-Id: <20181017082702.5581-32-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() in a function that takes an Error ** argument is suspicious. tpm_init_tpmdev() does that, and then fails without setting an error. Its caller main(), via tpm_init() and qemu_opts_foreach(), is fine with it, but clean it up anyway. Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NStefan Berger <stefanb@linux.ibm.com> Message-Id: <20181017082702.5581-30-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() in a function that takes an Error ** argument is suspicious. vnc_init_func() does that, and then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. While there, drop a "Failed to start VNC server: " error message prefix that doesn't really add value. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20181017082702.5581-28-armbru@redhat.com> Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() in a function that takes an Error ** argument is suspicious. device_init_func() does that, and then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20181017082702.5581-25-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() in a function that takes an Error ** argument is suspicious. parse_fw_cfg() does that, and then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181017082702.5581-24-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() in a function that takes an Error ** argument is suspicious. mon_init_func() does that, and then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181017082702.5581-23-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() in a function that takes an Error ** argument is suspicious. machine_set_property() does that, and then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181017082702.5581-22-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() in a function that takes an Error ** argument is suspicious. chardev_init_func() does that, and then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181017082702.5581-21-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() in a function that takes an Error ** argument is suspicious. user_creatable_add_opts_foreach() does that, and then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. Cc: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181017082702.5581-20-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() in a function that takes an Error ** argument is suspicious. parse_add_fd() does that, and then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. Also change call of cleanup_add_fd(), which can't fail, for symmetry. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181017082702.5581-19-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Calling error_report() in a function that takes an Error ** argument is suspicious. parse_sandbox() does that, and then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. Cc: Eduardo Otubo <otubo@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Acked-by: NEduardo Otubo <otubo@redhat.com> Message-Id: <20181017082702.5581-18-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Add a slight improvement of the Coccinelle semantic patch from commit 007b0657, and use it to clean up. It leaves dead Error * variables behind, cleaned up manually. Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Alexander Graf <agraf@suse.de> Cc: Eric Blake <eblake@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-Id: <20181017082702.5581-3-armbru@redhat.com>
-
由 Philippe Mathieu-Daudé 提交于
When using an incorrect backend for the debugcon, QEMU exits silently without any error indication, which is confusing. Add a message that the character backend is invalid. Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20181011171254.32428-1-philmd@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Artem Pisarenko 提交于
Return value of qemu_timedate_diff(), used for calculation offset in QAPI 'RTC_CHANGE' event, restored to keep compatibility. Since it wasn't documented that difference is relative to host clock advancement, this change also adds important note to 'RTC_CHANGE' event description to highlight established implementation specifics. Signed-off-by: NArtem Pisarenko <artem.k.pisarenko@gmail.com> Message-Id: <1fc12c77e8b7115d3842919a8b586d9cbe4efca6.1539846575.git.artem.k.pisarenko@gmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Artem Pisarenko 提交于
This makes all current "-rtc" option parameters combinations produce fixed/unambiguous RTC timedate reference for hardware emulation frontends. It restores determinism of guest execution when used with clock=vm and specified base <datetime> value. Buglink: https://bugs.launchpad.net/qemu/+bug/1797033Signed-off-by: NArtem Pisarenko <artem.k.pisarenko@gmail.com> Message-Id: <1d963c3e013dfedafa1f6edb9fb219b7e49e39da.1539846575.git.artem.k.pisarenko@gmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Artem Pisarenko 提交于
Improve code readability and prepare for fixing bug #1797033 Signed-off-by: NArtem Pisarenko <artem.k.pisarenko@gmail.com> Message-Id: <9330a48899f997431a34460014886d118a7c0960.1539846575.git.artem.k.pisarenko@gmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Zhang Chen 提交于
We need to know if migration is going into COLO state for incoming side before start normal migration. Instead by using the VMStateDescription to send colo_state from source side to destination side, we use MIG_CMD_ENABLE_COLO to indicate whether COLO is enabled or not. Signed-off-by: Nzhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: NZhang Chen <zhangckid@gmail.com> Signed-off-by: NZhang Chen <chen.zhang@intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
- 05 10月, 2018 2 次提交
-
-
由 Marc-André Lureau 提交于
Iterate over the writable class properties, sort and print them out with the description if available. Ex: qemu -object memory-backend-file,help memory-backend-file.align=int memory-backend-file.discard-data=bool memory-backend-file.dump=bool - Set to 'off' to exclude from core dump memory-backend-file.host-nodes=int - Binds memory to the list of NUMA host nodes memory-backend-file.mem-path=string memory-backend-file.merge=bool - Mark memory as mergeable memory-backend-file.pmem=bool memory-backend-file.policy=HostMemPolicy - Set the NUMA policy memory-backend-file.prealloc=bool - Preallocate memory memory-backend-file.share=bool - Mark the memory as private to QEMU or shared memory-backend-file.size=int - Size of the memory region (ex: 500M) Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Marc-André Lureau 提交于
List the user creatable objects. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 03 10月, 2018 4 次提交
-
-
由 Marc-André Lureau 提交于
This is mostly for readability of the code. Let's make it clear which callers can create an implicit monitor when the chardev is muxed. This will also enforce a safer behaviour, as we don't really support creating monitor anywhere/anytime at the moment. Add an assert() to make sure the programmer explicitely wanted that behaviour. There are documented cases, such as: -serial/-parallel/-virtioconsole and to less extent -debugcon. Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen console. Add a FIXME note for those, but keep the support for now. Other qemu_chr_new() callers either have a fixed parameter/filename string or do not need it, such as -qtest: * qtest.c: qtest_init() Afaik, only used by tests/libqtest.c, without mux. I don't think we support it outside of qemu testing: drop support for implicit mux monitor (qemu_chr_new() call: no implicit mux now). * hw/ All with literal @filename argument that doesn't enable mux monitor. * tests/ All with @filename argument that doesn't enable mux monitor. On a related note, the list of monitor creation places: - the chardev creators listed above: all from command line (except perhaps Xen console?) - -gdb & hmp gdbserver will create a "GDB monitor command" chardev that is wired to an HMP monitor. - -mon command line option From this short study, I would like to think that a monitor may only be created in the main thread today, though I remain skeptical :) Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
-
由 Pavel Dovgalyuk 提交于
This patch enables using -loadvm in recording mode to allow starting the execution recording from any of the available snapshots. It also fixes loading of the record/replay state, therefore snapshots created in replay mode may also be used for starting the new recording. Signed-off-by: NPavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Message-Id: <20180912081939.3228.56131.stgit@pasha-VirtualBox> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Marc-André Lureau 提交于
Register an exit notifier to remove the PID file. By the time atexit() is called, qemu_write_pidfile() guarantees QEMU owns the PID file, thus we could safely remove it when exiting. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20180907121319.8607-4-marcandre.lureau@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Marc-André Lureau 提交于
There are variants of qemu_create_pidfile() in qemu-pr-helper and qemu-ga. Let's have a common implementation in libqemuutil. The code is initially based from pr-helper write_pidfile(), with various improvements and suggestions from Daniel Berrangé: QEMU will leave the pidfile existing on disk when it exits which initially made me think it avoids the deletion race. The app managing QEMU, however, may well delete the pidfile after it has seen QEMU exit, and even if the app locks the pidfile before deleting it, there is still a race. eg consider the following sequence QEMU 1 libvirtd QEMU 2 1. lock(pidfile) 2. exit() 3. open(pidfile) 4. lock(pidfile) 5. open(pidfile) 6. unlink(pidfile) 7. close(pidfile) 8. lock(pidfile) IOW, at step 8 the new QEMU has successfully acquired the lock, but the pidfile no longer exists on disk because it was deleted after the original QEMU exited. While we could just say no external app should ever delete the pidfile, I don't think that is satisfactory as people don't read docs, and admins don't like stale pidfiles being left around on disk. To make this robust, I think we might want to copy libvirt's approach to pidfile acquisition which runs in a loop and checks that the file on disk /after/ acquiring the lock matches the file that was locked. Then we could in fact safely let QEMU delete its own pidfiles on clean exit.. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20180831145314.14736-2-marcandre.lureau@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-