Patch created mechanically by rerunning:

    $ spatch --in-place --sp-file scripts/coccinelle/use-error_fatal.cocci \
             --macro-file scripts/cocci-macro-file.h vl.c
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NLaurent Vivier <laurent@vivier.eu>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20181213175807.12039-1-armbru@redhat.com>
Signed-off-by: NLaurent Vivier <laurent@vivier.eu>

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>

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>

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>

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>

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>

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>

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 ]

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>

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>

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>

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>

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>

-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>

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>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181017082702.5581-35-armbru@redhat.com>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

List the user creatable objects.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>

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>

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>

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>