Return a QDict, which may contain up to more two QDicts, depending
on the type of migration we're performing.

IMPORTANT: as a QInt stores a int64_t integer, RAM values are going
to be stored as int64_t and not as uint64_t as they are today. If
this is a problem QInt will have to be changed.

This commit should not change user output.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Each mouse is represented by a QDict, the returned QObject is a QList of
all mice.

This commit should not change user output.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

snprintf() is used because the UUID_FMT is too complex for
qobject_from_jsonf().
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

All 'info' commands should use QDict, this commit also kills
monitor_print_qobject() as do_info_version() doesn't use it
anymore (and no handler will).
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

While there update the documentation as well.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Should return a QDict and should not print the user protocol bits
(eg. "c|cont").
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Monitor commands should always return values in bytes and info
commands should always return a QDict.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This reverts commit adcb181a.

Conflicts:

	monitor.h
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Also affects do_change(), because the two share eject_device().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The do_cont() function will ask the user to enter a password if a
device is encrypted.

This is invalid under QMP, so we raise a QERR_DEVICE_ENCRYPTED
error.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

When using encrypted disk images, QEMU will prompt the user
for passwords when started.

This makes sense for the user protocol, but doesn't for QMP.

The solution is to have Monitor command which allows the user
or a Client to set passwords in advance, so that we avoid
the prompt completely.

This is what block_passwd does, for example:

(QEMU) block_passwd ide0-hd0 foobar
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Fix mingw32 build.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Partially fixes mingw32 build.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

We still have handlers which will call monitor print functions
in several places. Usually to report errors.

If they do this when we are in control mode, we will be emitting
garbage to our clients.

To avoid this problem, this commit adds a way to disable those
functions. If any of them is called when in control mode, we will
emit a generic error.

Although this is far from the perfect solution, it guarantees
that only JSON is sent to Clients.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Debug, shutdown, reset, powerdown and stop are all basic events,
as they are very simple they can be added in the same commit.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Asynchronous events are generated with a call to
monitor_protocol_event().

This function builds the right data-type and emit the event
right away. The emitted data is always a JSON object and its
format is as follows:

{ "event": json-string,
  "timestamp": { "seconds": json-number, "microseconds": json-number },
  "data": json-value }

This design is based on ideas by Amit Shah <amit.shah@redhat.com>.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The 'info' command makes sense for the user protocol, but for QMP
it doesn't, as its return data is not well defined. That is, it
can return anything.

To fix this Avi proposes having 'query-' commands when in protocol
mode. For example, 'info balloon' would become 'query-balloon'.

The right way of supporting this would probably be to move all
info handlers to qemu-monitor.hx, add a flags field to mon_cmd_t
to identify them and then modify do_info() to do its search based
on that flag.

Unfortunately, this would require a big change in the Monitor.

To make things simpler for now, this commit takes a different
approach: a check for commands starting with "query-" is added to
toplevel QMP code, if it's true we setup things so that do_info()
is called with the appropriate arguments.

This is a hack, but is a temporary one and guarantees that query-
commands will work from the first day.

Also note that 'info' is not allowed in protocol mode.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The JSON stream parser is used to do QMP input. When there
are enough characters to be parsed it calls Monitor's
handle_qmp_command() function to handle the input.

This function's job is to check if the input is correct and
call the appropriate handler. In other words, it does for QMP
what handle_user_command() does for the user protocol.

This means that handle_qmp_command() also has to parse the
(ugly) "args_type" format to able to get the arguments names
and types expected by the handler.

The format to input commands in QMP is as follows:

{ "execute": json-string,
  "id": json-value, "arguments": json-object }

Please, note that this commit also adds "id" support.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This commit adds specific QMP checks to do_info(), so that
it behaves as expected in QMP mode.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

In the new Monitor output is always performed by only two
functions: do_info() and monitor_call_handler().

To support QMP output, we modify those functions to check if we
are in control mode. If so, we call monitor_protocol_emitter()
to emit QMP output, otherwise we do regular output.

QMP has two types of responses to issued commands: success and
error. The outputed data is always a JSON object.

Success responses have the following format:

{ "return": json-value, "id": json-value }

Error responses have the following format:

{ "error": { "class": json-string,
             "desc": json-string,
             "data": json-value } "id": json-value }

Please, note that the "id" key is part of the input code, and
thus is not added in this commit.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This commit adds initial QMP support in QEMU. It's important
to notice that most QMP code will be part of the Monitor.

Input will be read by monitor_control_read(). Currently it
does nothing but next patches will add proper input support.

The function monitor_json_emitter(), as its name implies, is
used by the Monitor to emit JSON output. In this commit it's
used by monitor_control_event() to print our greeting message.

Finally, control mode support is also added to monitor_init(),
allowing QMP to be really enabled.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

List QMP available commands. Only valid in control mode, where
has to be used as 'query-commands.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

As this series will add a new kind of Monitor command, it's better
to rename monitor_handle_command() to what it really is:
handle_user_command().

This will avoid confusion.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This commit moves the loop which searches for the command
entry corresponding to a command name to its own function.

It will be used by QMP code as well.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This commit moves the code which calls Monitor handlers to
its own function, as it will be used by QMP code as well.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This commit adds a flag called 'control' to the '-monitor'
command-line option. This flag enables control mode.

The syntax is:

qemu [...] -monitor control,<device>

Where <device> is a chardev (excluding 'vc', for obvious reasons).

For example:

$ qemu [...] -monitor control,tcp:localhost:4444,server

Will run QEMU in control mode, waiting for a client TCP connection
on localhost port 4444.

NOTE: I've tried using QemuOpts for this, but turns out that it
will try to parse the device part, which should be untouched.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This flag will be set when Monitor enters "control mode", in
which the output will be defined by the QEMU Monitor Protocol.

This also introduces a macro to check if the flag is set.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This commit adds QError support in the Monitor.

A QError member is added to the Monitor struct. This new member
stores error information and is also used to check if an error
has occurred when the called handler returns.

Additionally, a new macro called qemu_error_new() is introduced.
It builds on top of the QemuErrorSink API and should be used in
place of qemu_error().

When all conversion to qemu_error_new() is done, qemu_error() can
be turned private.

Basically, Monitor's error flow is something like this:

1. An error occurs in the handler, it calls qemu_error_new()
2. qemu_error_new() builds a new QError object and stores it in
   the Monitor struct
3. The handler returns
4. Top level Monitor code checks the Monitor struct and calls
   qerror_print() to print the error
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>