From 3b6959506831193f37cc830c8e111b437c0d1380 Mon Sep 17 00:00:00 2001 From: Peter Feiner Date: Fri, 16 May 2014 10:40:47 -0400 Subject: [PATCH 1/3] doc: add "setup" to list of migration states On a slow VM (e.g., nested), you see the "setup" state when you query the migration status. Signed-off-by: Peter Feiner Reviewed-by: Eric Blake Signed-off-by: Luiz Capitulino --- qapi-schema.json | 2 +- qmp-commands.hx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/qapi-schema.json b/qapi-schema.json index 36cb964dfd..f4ffedef9f 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -691,7 +691,7 @@ # Information about current migration process. # # @status: #optional string describing the current migration status. -# As of 0.14.0 this can be 'active', 'completed', 'failed' or +# As of 0.14.0 this can be 'setup', 'active', 'completed', 'failed' or # 'cancelled'. If this field is not returned, no migration process # has been initiated # diff --git a/qmp-commands.hx b/qmp-commands.hx index cae890ee5d..408ae9c07b 100644 --- a/qmp-commands.hx +++ b/qmp-commands.hx @@ -2937,7 +2937,7 @@ block migration status. The main json-object contains the following: - "status": migration status (json-string) - - Possible values: "active", "completed", "failed", "cancelled" + - Possible values: "setup", "active", "completed", "failed", "cancelled" - "total-time": total amount of ms since migration started. If migration has ended, it returns the total migration time (json-int) From 347888113020e874027cb200bb38aa0852e42839 Mon Sep 17 00:00:00 2001 From: Luiz Capitulino Date: Tue, 20 May 2014 13:50:19 -0400 Subject: [PATCH 2/3] scripts/qapi.py: Avoid syntax not supported by Python 2.4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Python "except Foo as x" syntax was only introduced in Python 2.6, but we aim to support Python 2.4 and later. Use the old-style "except Foo, x" syntax instead, thus fixing configure/compile on systems with older Python. Reported-by: Peter Maydell Tested-by: Andreas Färber Signed-off-by: Luiz Capitulino --- scripts/qapi.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/qapi.py b/scripts/qapi.py index 0265b404dd..86e96089af 100644 --- a/scripts/qapi.py +++ b/scripts/qapi.py @@ -116,7 +116,7 @@ def __init__(self, fp, input_relname=None, include_hist=[], continue try: fobj = open(include_path, 'r') - except IOError as e: + except IOError, e: raise QAPIExprError(expr_info, '%s: %s' % (e.strerror, include)) exprs_include = QAPISchema(fobj, include, self.include_hist, From fc13d937269c1cd01a4b7720c1dcce01722727a2 Mon Sep 17 00:00:00 2001 From: Michael Roth Date: Tue, 20 May 2014 12:20:39 -0500 Subject: [PATCH 3/3] qapi: zero-initialize all QMP command parameters In general QMP command parameter values are specified by consumers of the QMP/HMP interface, but in the case of optional parameters these values may be left uninitialized. It is considered a bug for code to make use of optional parameters that have not been flagged as being present by the marshalling code (via corresponding has_ parameter), however our marshalling code will still pass these uninitialized values on to the corresponding QMP function (to then be ignored). Some compilers (clang in particular) consider this unsafe however, and generate warnings as a result. As reported by Peter Maydell: This is something clang's -fsanitize=undefined spotted. The code generated by qapi-commands.py in qmp-marshal.c for qmp_marshal_* functions where there are some optional arguments looks like this: bool has_force = false; bool force; mi = qmp_input_visitor_new_strict(QOBJECT(args)); v = qmp_input_get_visitor(mi); visit_type_str(v, &device, "device", errp); visit_start_optional(v, &has_force, "force", errp); if (has_force) { visit_type_bool(v, &force, "force", errp); } visit_end_optional(v, errp); qmp_input_visitor_cleanup(mi); if (error_is_set(errp)) { goto out; } qmp_eject(device, has_force, force, errp); In the case where has_force is false, we never initialize force, but then we use it by passing it to qmp_eject. I imagine we don't then actually use the value, but clang complains in particular for 'bool' variables because the value that ends up being loaded from memory for 'force' is not either 0 or 1 (being uninitialized stack contents). Fix this by initializing all QMP command parameters to {0} in the marshalling code prior to passing them on to the QMP functions. Signed-off-by: Michael Roth Reported-by: Peter Maydell Tested-by: Peter Maydell Reviewed-by: Eric Blake Reviewed-by: Markus Armbruster Signed-off-by: Luiz Capitulino --- scripts/qapi-commands.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/qapi-commands.py b/scripts/qapi-commands.py index 386f17ef44..7d93d01ed2 100644 --- a/scripts/qapi-commands.py +++ b/scripts/qapi-commands.py @@ -111,7 +111,7 @@ def gen_visitor_input_vars_decl(args): argname=c_var(argname), argtype=c_type(argtype)) else: ret += mcgen(''' -%(argtype)s %(argname)s; +%(argtype)s %(argname)s = {0}; ''', argname=c_var(argname), argtype=c_type(argtype))