[Qemu-devel] [PATCH v2 1/6] pci: Use struct instead of QDict to pass back parameters

2017-01-18 Thread Eric Blake
It's simpler to just use a C struct than it is to bundle things
into a QDict in one function just to pull them back out in the
caller.  Plus, doing this gets rid of one more user of dynamic
JSON through qobject_from_jsonf().

Signed-off-by: Eric Blake 
Acked-by: Michael S. Tsirkin 
---
 hw/pci/pcie_aer.c | 36 +---
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index daf1f65..78fd2c3 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -44,6 +44,13 @@
 #define PCI_ERR_SRC_COR_OFFS0
 #define PCI_ERR_SRC_UNCOR_OFFS  2

+typedef struct PCIEErrorInject {
+const char *id;
+const char *root_bus;
+int bus;
+int devfn;
+} PCIEErrorInject;
+
 /* From 6.2.7 Error Listing and Rules. Table 6-2, 6-3 and 6-4 */
 static uint32_t pcie_aer_uncor_default_severity(uint32_t status)
 {
@@ -943,7 +950,8 @@ static int pcie_aer_parse_error_string(const char 
*error_name,
 }

 static int do_pcie_aer_inject_error(Monitor *mon,
-const QDict *qdict, QObject **ret_data)
+const QDict *qdict,
+PCIEErrorInject *ret_data)
 {
 const char *id = qdict_get_str(qdict, "id");
 const char *error_name;
@@ -1004,34 +1012,24 @@ static int do_pcie_aer_inject_error(Monitor *mon,
 err.prefix[2] = qdict_get_try_int(qdict, "prefix2", 0);
 err.prefix[3] = qdict_get_try_int(qdict, "prefix3", 0);

-ret = pcie_aer_inject_error(dev, );
-*ret_data = qobject_from_jsonf("{'id': %s, "
-   "'root_bus': %s, 'bus': %d, 'devfn': %d, "
-   "'ret': %d}",
-   id, pci_root_bus_path(dev),
-   pci_bus_num(dev->bus), dev->devfn,
-   ret);
-assert(*ret_data);
+pcie_aer_inject_error(dev, );
+ret_data->id = id;
+ret_data->root_bus = pci_root_bus_path(dev);
+ret_data->bus = pci_bus_num(dev->bus);
+ret_data->devfn = dev->devfn;

 return 0;
 }

 void hmp_pcie_aer_inject_error(Monitor *mon, const QDict *qdict)
 {
-QObject *data;
-int devfn;
+PCIEErrorInject data;

 if (do_pcie_aer_inject_error(mon, qdict, ) < 0) {
 return;
 }

-assert(qobject_type(data) == QTYPE_QDICT);
-qdict = qobject_to_qdict(data);
-
-devfn = (int)qdict_get_int(qdict, "devfn");
 monitor_printf(mon, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
-   qdict_get_str(qdict, "id"),
-   qdict_get_str(qdict, "root_bus"),
-   (int) qdict_get_int(qdict, "bus"),
-   PCI_SLOT(devfn), PCI_FUNC(devfn));
+   data.id, data.root_bus, data.bus,
+   PCI_SLOT(data.devfn), PCI_FUNC(data.devfn));
 }
-- 
2.9.3




[Qemu-devel] [PATCH v2 16/25] qmp: update qmp-spec about async capability

2017-01-18 Thread Marc-André Lureau
Signed-off-by: Marc-André Lureau 
---
 docs/qmp-spec.txt | 48 +---
 1 file changed, 41 insertions(+), 7 deletions(-)

diff --git a/docs/qmp-spec.txt b/docs/qmp-spec.txt
index f8b5356015..b45c0700b6 100644
--- a/docs/qmp-spec.txt
+++ b/docs/qmp-spec.txt
@@ -83,9 +83,41 @@ The greeting message format is:
 2.2.1 Capabilities
 --
 
-As of the date this document was last revised, no server or client
-capability strings have been defined.
+The "capabilities" member of the greeting message and qmp_capabilities
+is a json-array of json-string of the following values:
 
+- "async"
+
+This capability indicates asynchronous commands support.
+
+An async command is a regular client message request with the "id"
+member mandatory (see 2.3), but the reply may be delivered
+asynchronously and out of order by the server if the client supports
+it too.
+
+If both the server and the client have the "async" capability, the
+client can make requests while previous async requests are being
+processed.
+
+If the client doesn't have the "async" capability, it may still call
+an async command, and make multiple outstanding calls. In this case,
+the commands are processed in order, so the replies will also be in
+order (this is sometime called 'pipelining'). The "id" member isn't
+mandatory in this case.
+
+The client should match the replies with the "id" member associated
+with the requests.
+
+When a client is disconnected, the pending commands are not
+necessarily canceled. But the future clients will not get replies from
+commands they didn't make (they might, however, receive side-effects
+events).
+
+Note that without "async" support, a client may still receive
+asynchronous messages (or events) from the server between the time a
+request is handled by the server and the reply is received. It must
+thus be prepared to handle dispatching both events and reply after
+sending a request.
 
 2.3 Issuing Commands
 
@@ -102,10 +134,11 @@ The format for command execution is:
   required. Each command documents what contents will be considered
   valid when handling the json-argument
 - The "id" member is a transaction identification associated with the
-  command execution, it is optional and will be part of the response if
-  provided. The "id" member can be any json-value, although most
+  command execution and will be part of the response if provided.
+  If "async" is negotiated (see 2.2.1), it is mandatory, optional
+  otherwise. The "id" member can be any json-value, although most
   clients merely use a json-number incremented for each successive
-  command
+  command.
 
 2.4 Commands Responses
 --
@@ -202,11 +235,12 @@ This section provides some examples of real QMP usage, in 
all of them
 ---
 
 S: { "QMP": { "version": { "qemu": { "micro": 50, "minor": 6, "major": 1 },
- "package": ""}, "capabilities": []}}
+ "package": ""}, "capabilities": [ "async" ]}}
 
 3.2 Client QMP negotiation
 --
-C: { "execute": "qmp_capabilities" }
+C: { "execute": "qmp_capabilities",
+ "arguments": { "capabilities": [ "async" ] } }
 S: { "return": {}}
 
 3.3 Simple 'stop' execution
-- 
2.11.0.295.gd7dffce1c




Re: [Qemu-devel] [PATCH 10/16] block: explicitly acquire aiocontext in timers that need it

2017-01-18 Thread Paolo Bonzini


On 18/01/2017 16:43, Stefan Hajnoczi wrote:
> On Fri, Jan 13, 2017 at 02:17:25PM +0100, Paolo Bonzini wrote:
>> diff --git a/block/null.c b/block/null.c
>> index b300390..356209a 100644
>> --- a/block/null.c
>> +++ b/block/null.c
>> @@ -141,7 +141,11 @@ static void null_bh_cb(void *opaque)
>>  static void null_timer_cb(void *opaque)
>>  {
>>  NullAIOCB *acb = opaque;
>> +AioContext *ctx = bdrv_get_aio_context(acb->common.bs);
>> +
>> +aio_context_acquire(ctx);
>>  acb->common.cb(acb->common.opaque, 0);
>> +aio_context_release(ctx);
>>  timer_deinit(>timer);
>>  qemu_aio_unref(acb);
> 
> Is qemu_aio_unref() thread-safe?

qemu_aio_ref()/qemu_aio_unref() is only used by bdrv_aio_cancel, which
in turn is not used by dataplane.  So in the multithreaded case
qemu_aio_unref() is effectively qemu_aio_free().

Probably needs more documentation, or a different implementation of
bdrv_aio_cancel (e.g. replacing the reference counting with a
NotifierList of some kind).  Let me know what you prefer for v2.

Paolo



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH v2 17/25] qtest: add qtest-timeout

2017-01-18 Thread Marc-André Lureau
This command allows to test async behavior. It is only registered when
qtest is enabled. See the schema documentation for more details.

Signed-off-by: Marc-André Lureau 
---
 qapi-schema.json | 22 ++
 qtest.c  | 48 
 2 files changed, 70 insertions(+)

diff --git a/qapi-schema.json b/qapi-schema.json
index 8366206415..42b2c645c5 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -6033,3 +6033,25 @@
 #
 ##
 { 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }
+
+##
+# @qtest-timeout:
+#
+# @duration: the time before timeout expires (in seconds)
+#
+# Test command that replies after @duration seconds.
+#
+# Example:
+#
+# -> { "execute": "qtest-timeout",
+#  "arguments": { "duration": 5 } }
+# ... after 5s
+# <- { "return": {} }
+#
+# Note: this command is only available with a qtest machine
+#
+# Since: 2.9
+##
+{ 'command': 'qtest-timeout',
+  'data': {'duration': 'int'},
+  'gen': false } # so we can can register it manually when qtest is enabled
diff --git a/qtest.c b/qtest.c
index bd9d417812..9477ad64e7 100644
--- a/qtest.c
+++ b/qtest.c
@@ -31,6 +31,8 @@
 #ifdef TARGET_PPC64
 #include "hw/ppc/spapr_rtas.h"
 #endif
+#include "qapi/qmp/dispatch.h"
+#include "qapi/qobject-input-visitor.h"
 
 #define MAX_IRQ 256
 
@@ -658,6 +660,49 @@ static void qtest_event(void *opaque, int event)
 }
 }
 
+static gboolean qtest_timeout_cb(void *data)
+{
+QmpReturn *qret = data;
+
+qmp_return(qret, NULL);
+
+return FALSE;
+}
+
+static void qmp_qtest_timeout(QDict *args, QmpReturn *qret)
+{
+Error *err = NULL;
+Visitor *v;
+int64_t duration = 0;
+
+v = qobject_input_visitor_new(QOBJECT(args), true);
+visit_start_struct(v, NULL, NULL, 0, );
+if (err) {
+goto out;
+}
+
+visit_type_int(v, "duration", , );
+if (!err) {
+visit_check_struct(v, );
+}
+visit_end_struct(v, NULL);
+if (err) {
+goto out;
+}
+
+if (duration <= 0) {
+qmp_return(qret, NULL);
+} else {
+g_timeout_add_seconds(duration, qtest_timeout_cb, qret);
+}
+
+out:
+if (err) {
+qmp_return_error(qret, err);
+}
+visit_free(v);
+}
+
 static int qtest_init_accel(MachineState *ms)
 {
 QemuOpts *opts = qemu_opts_create(qemu_find_opts("icount"), NULL, 0,
@@ -665,6 +710,9 @@ static int qtest_init_accel(MachineState *ms)
 qemu_opt_set(opts, "shift", "0", _abort);
 configure_icount(opts, _abort);
 qemu_opts_del(opts);
+
+qmp_register_async_command("qtest-timeout", qmp_qtest_timeout,
+   QCO_NO_OPTIONS);
 return 0;
 }
 
-- 
2.11.0.295.gd7dffce1c




Re: [Qemu-devel] [PATCH v2 1/6] pci: Use struct instead of QDict to pass back parameters

2017-01-18 Thread Michael S. Tsirkin
On Wed, Jan 18, 2017 at 10:16:48AM -0600, Eric Blake wrote:
> It's simpler to just use a C struct than it is to bundle things
> into a QDict in one function just to pull them back out in the
> caller.  Plus, doing this gets rid of one more user of dynamic
> JSON through qobject_from_jsonf().
> 
> Signed-off-by: Eric Blake 
> Acked-by: Michael S. Tsirkin 

All this JSON was for the purpose of making it
easier to inject errors from unit tests or QMP.
If this doesn't help anymore, let's get rid of it.
Pls feel free to merge with the rest of the patchset
through whatever tree seems appropriate.

> ---
>  hw/pci/pcie_aer.c | 36 +---
>  1 file changed, 17 insertions(+), 19 deletions(-)
> 
> diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
> index daf1f65..78fd2c3 100644
> --- a/hw/pci/pcie_aer.c
> +++ b/hw/pci/pcie_aer.c
> @@ -44,6 +44,13 @@
>  #define PCI_ERR_SRC_COR_OFFS0
>  #define PCI_ERR_SRC_UNCOR_OFFS  2
> 
> +typedef struct PCIEErrorInject {
> +const char *id;
> +const char *root_bus;
> +int bus;
> +int devfn;
> +} PCIEErrorInject;
> +
>  /* From 6.2.7 Error Listing and Rules. Table 6-2, 6-3 and 6-4 */
>  static uint32_t pcie_aer_uncor_default_severity(uint32_t status)
>  {
> @@ -943,7 +950,8 @@ static int pcie_aer_parse_error_string(const char 
> *error_name,
>  }
> 
>  static int do_pcie_aer_inject_error(Monitor *mon,
> -const QDict *qdict, QObject **ret_data)
> +const QDict *qdict,
> +PCIEErrorInject *ret_data)
>  {
>  const char *id = qdict_get_str(qdict, "id");
>  const char *error_name;
> @@ -1004,34 +1012,24 @@ static int do_pcie_aer_inject_error(Monitor *mon,
>  err.prefix[2] = qdict_get_try_int(qdict, "prefix2", 0);
>  err.prefix[3] = qdict_get_try_int(qdict, "prefix3", 0);
> 
> -ret = pcie_aer_inject_error(dev, );
> -*ret_data = qobject_from_jsonf("{'id': %s, "
> -   "'root_bus': %s, 'bus': %d, 'devfn': %d, "
> -   "'ret': %d}",
> -   id, pci_root_bus_path(dev),
> -   pci_bus_num(dev->bus), dev->devfn,
> -   ret);
> -assert(*ret_data);
> +pcie_aer_inject_error(dev, );
> +ret_data->id = id;
> +ret_data->root_bus = pci_root_bus_path(dev);
> +ret_data->bus = pci_bus_num(dev->bus);
> +ret_data->devfn = dev->devfn;
> 
>  return 0;
>  }
> 
>  void hmp_pcie_aer_inject_error(Monitor *mon, const QDict *qdict)
>  {
> -QObject *data;
> -int devfn;
> +PCIEErrorInject data;
> 
>  if (do_pcie_aer_inject_error(mon, qdict, ) < 0) {
>  return;
>  }
> 
> -assert(qobject_type(data) == QTYPE_QDICT);
> -qdict = qobject_to_qdict(data);
> -
> -devfn = (int)qdict_get_int(qdict, "devfn");
>  monitor_printf(mon, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
> -   qdict_get_str(qdict, "id"),
> -   qdict_get_str(qdict, "root_bus"),
> -   (int) qdict_get_int(qdict, "bus"),
> -   PCI_SLOT(devfn), PCI_FUNC(devfn));
> +   data.id, data.root_bus, data.bus,
> +   PCI_SLOT(data.devfn), PCI_FUNC(data.devfn));
>  }
> -- 
> 2.9.3



[Qemu-devel] [PATCH v2 18/25] qtest: add qtest_init_qmp_caps()

2017-01-18 Thread Marc-André Lureau
Add a function to specify the qmp capabilities content.

Signed-off-by: Marc-André Lureau 
---
 tests/libqtest.h |  9 +
 tests/libqtest.c | 13 +++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/tests/libqtest.h b/tests/libqtest.h
index 90f182e1d8..e7ab509d1a 100644
--- a/tests/libqtest.h
+++ b/tests/libqtest.h
@@ -32,6 +32,15 @@ extern QTestState *global_qtest;
 QTestState *qtest_init(const char *extra_args);
 
 /**
+ * qtest_init_qmp_caps:
+ * @extra_args: other arguments to pass to QEMU.
+ * @qmp_caps: qmp capabilities (ex: "'cap1', 'cap2'")
+ *
+ * Returns: #QTestState instance.
+ */
+QTestState *qtest_init_qmp_caps(const char *extra_args, const char *qmp_caps);
+
+/**
  * qtest_quit:
  * @s: #QTestState instance to operate on.
  *
diff --git a/tests/libqtest.c b/tests/libqtest.c
index d8fba6647a..eb4a0c12c0 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -149,7 +149,7 @@ void qtest_add_abrt_handler(GHookFunc fn, const void *data)
 g_hook_prepend(_hooks, hook);
 }
 
-QTestState *qtest_init(const char *extra_args)
+QTestState *qtest_init_qmp_caps(const char *extra_args, const char *qmp_caps)
 {
 QTestState *s;
 int sock, qmpsock, i;
@@ -206,7 +206,11 @@ QTestState *qtest_init(const char *extra_args)
 
 /* Read the QMP greeting and then do the handshake */
 qtest_qmp_discard_response(s, "");
-qtest_qmp_discard_response(s, "{ 'execute': 'qmp_capabilities' }");
+command = g_strdup_printf(
+"{ 'execute': 'qmp_capabilities',"
+" 'arguments': {'capabilities': [%s]}}", qmp_caps);
+qtest_qmp_discard_response(s, command);
+g_free(command);
 
 if (getenv("QTEST_STOP")) {
 kill(s->qemu_pid, SIGSTOP);
@@ -219,6 +223,11 @@ QTestState *qtest_init(const char *extra_args)
 return s;
 }
 
+QTestState *qtest_init(const char *extra_args)
+{
+return qtest_init_qmp_caps(extra_args, "");
+}
+
 void qtest_quit(QTestState *s)
 {
 qtest_instances = g_list_remove(qtest_instances, s);
-- 
2.11.0.295.gd7dffce1c




Re: [Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM

2017-01-18 Thread Eduardo Habkost
On Wed, Jan 18, 2017 at 01:44:50PM +0100, Thomas Huth wrote:
> Sometimes it is useful to have just a machine with CPU and RAM, without
> any further hardware in it, e.g. if you just want to do some instruction
> debugging for TCG with a remote GDB attached to QEMU, or run some embedded
> code with the "-semihosting" QEMU parameter. qemu-system-m68k already
> features a "dummy" machine, and xtensa a "sim" machine for exactly this
> purpose.
> All target architectures have nowadays also a "none" machine, which would
> be a perfect match for this, too - but it currently does not allow to add
> CPU and RAM yet. Thus let's add these possibilities in a generic way to the
> "none" machine, too, so that we hopefully do not need additional "dummy"
> machines in the future anymore (and maybe can also get rid of the already
> existing "dummy"/"sim" machines one day).
> Note that the default behaviour of the "none" machine is not changed, i.e.
> no CPU and no RAM is instantiated by default. You have explicitely got to
> specify the CPU model with "-cpu" and the amount of RAM with "-m" to get
> these new features.
> 
> Signed-off-by: Thomas Huth 

Reviewed-by: Eduardo Habkost 

I will wait for the opinion of others before applying it, though.

-- 
Eduardo



[Qemu-devel] [PATCH 0/2] Aspeed watchdog controller model

2017-01-18 Thread Cédric Le Goater
Hello,

The Aspeed SoC includes a set of watchdog timers using 32-bit
decrement counters. This patchset provides a model for this controller
and adds the first watchdog to the Aspeed SoC model. A second watchdog
exists and is used on real HW to boot from a second flash module
containing a golden image of the firmware. This is not supported yet
in qemu.

The main benefit today of this model is to enables reboot/reset of a
guest from U-Boot and Linux.

Thanks,

C.

Cédric Le Goater (1):
  aspeed: add a watchdog controller

Joel Stanley (1):
  wdt: Add Aspeed watchdog device model

 hw/arm/aspeed_soc.c  |  13 +++
 hw/watchdog/Makefile.objs|   1 +
 hw/watchdog/wdt_aspeed.c | 214 +++
 include/hw/arm/aspeed_soc.h  |   2 +
 include/hw/watchdog/wdt_aspeed.h |  37 +++
 5 files changed, 267 insertions(+)
 create mode 100644 hw/watchdog/wdt_aspeed.c
 create mode 100644 include/hw/watchdog/wdt_aspeed.h

-- 
2.7.4




[Qemu-devel] [PATCH v2 12/25] tests: add dispatch async tests

2017-01-18 Thread Marc-André Lureau
Add a few tests to check:
- async dispatch
- async command without "id" failure
- destroying the client with pending requests

Signed-off-by: Marc-André Lureau 
---
 tests/test-qmp-commands.c   | 132 
 tests/qapi-schema/qapi-schema-test.json |   6 ++
 tests/qapi-schema/qapi-schema-test.out  |   6 ++
 3 files changed, 144 insertions(+)

diff --git a/tests/test-qmp-commands.c b/tests/test-qmp-commands.c
index a3c7c590d1..4613a9a4c8 100644
--- a/tests/test-qmp-commands.c
+++ b/tests/test-qmp-commands.c
@@ -85,6 +85,36 @@ __org_qemu_x_Union1 
*qmp___org_qemu_x_command(__org_qemu_x_EnumList *a,
 return ret;
 }
 
+static GMainLoop *loop;
+
+typedef struct AsyncRet {
+QmpReturn *qret;
+UserDefB *ret;
+} AsyncRet;
+
+static gboolean qmp_user_async_idle(gpointer data)
+{
+struct AsyncRet *async = (struct AsyncRet *)data;
+
+qmp_user_async_return(async->qret, async->ret);
+g_free(async);
+
+g_main_loop_quit(loop);
+
+return FALSE;
+}
+
+void qmp_user_async(int64_t a, bool has_b, int64_t b, QmpReturn *qret)
+{
+AsyncRet *async = g_new0(AsyncRet, 1);
+
+async->ret = g_new0(UserDefB, 1);
+async->ret->intb = a + (has_b ? b : 0);
+async->qret = qret;
+
+g_idle_add(qmp_user_async_idle, async);
+}
+
 static void dispatch_cmd_return(QmpClient *client, QObject *resp)
 {
 assert(resp != NULL);
@@ -142,14 +172,19 @@ static void test_dispatch_cmd_failure(void)
 }
 
 static QObject *dispatch_ret;
+static char *ret_id;
 
 static void qmp_dispatch_return(QmpClient *client, QObject *resp_obj)
 {
 QDict *resp = qobject_to_qdict(resp_obj);
+
 assert(resp && !qdict_haskey(resp, "error"));
 dispatch_ret = qdict_get(resp, "return");
 assert(dispatch_ret);
 qobject_incref(dispatch_ret);
+
+g_free(ret_id);
+ret_id = g_strdup(qdict_get_try_str(resp, "id"));
 }
 
 static QObject *test_qmp_dispatch(QDict *req)
@@ -216,6 +251,97 @@ static void test_dispatch_cmd_io(void)
 QDECREF(req);
 }
 
+static void test_dispatch_cmd_async(void)
+{
+QmpClient client = { .has_async = true };
+QDict *dret, *req = qdict_new();
+QDict *args = qdict_new();
+
+loop = g_main_loop_new(NULL, FALSE);
+qmp_client_init(, qmp_dispatch_return);
+
+qdict_put(args, "a", qint_from_int(99));
+qdict_put(req, "arguments", args);
+qdict_put(req, "id", qstring_from_str("foo99"));
+qdict_put(req, "execute", qstring_from_str("user-async"));
+
+qmp_dispatch(, QOBJECT(req), NULL);
+assert(!dispatch_ret);
+
+g_main_loop_run(loop);
+g_main_loop_unref(loop);
+
+g_assert_cmpstr(ret_id, ==, "foo99");
+dret = qobject_to_qdict(dispatch_ret);
+assert(qdict_get_int(dret, "intb") == 99);
+QDECREF(dret);
+dispatch_ret = NULL;
+
+qmp_client_destroy();
+QDECREF(req);
+}
+
+static void test_dispatch_cmd_async_no_id(void)
+{
+QmpClient client = { .has_async = true };
+QDict *req = qdict_new();
+QDict *args = qdict_new();
+
+qmp_client_init(, dispatch_cmd_error_return);
+
+qdict_put(args, "a", qint_from_int(99));
+qdict_put(req, "arguments", args);
+qdict_put(req, "execute", qstring_from_str("user-async"));
+
+qmp_dispatch(, QOBJECT(req), NULL);
+
+assert(!dispatch_ret);
+assert(QLIST_EMPTY());
+
+qmp_client_destroy();
+QDECREF(req);
+}
+
+static void test_destroy_pending_async(void)
+{
+QmpClient client = { .has_async = true };
+QDict *req = qdict_new();
+QDict *args = qdict_new();
+QmpReturn *r;
+int npending = 0;
+
+loop = g_main_loop_new(NULL, FALSE);
+qmp_client_init(, qmp_dispatch_return);
+
+qdict_put(args, "a", qint_from_int(99));
+qdict_put(req, "arguments", args);
+qdict_put(req, "id", qstring_from_str("foo99"));
+qdict_put(req, "execute", qstring_from_str("user-async"));
+
+qmp_dispatch(, QOBJECT(req), NULL);
+qmp_dispatch(, QOBJECT(req), NULL);
+assert(!dispatch_ret);
+QDECREF(req);
+
+npending = 0;
+QLIST_FOREACH(r, , link) {
+npending++;
+}
+
+g_assert_cmpint(npending, ==, 2);
+
+/* destroy with pending async */
+qmp_client_destroy();
+
+while (g_main_context_pending(NULL)) {
+g_main_loop_run(loop);
+/* no return since the client is gone */
+assert(!dispatch_ret);
+}
+
+g_main_loop_unref(loop);
+}
+
 /* test generated dealloc functions for generated types */
 static void test_dealloc_types(void)
 {
@@ -287,11 +413,17 @@ int main(int argc, char **argv)
 g_test_add_func("/qmp/dispatch_cmd", test_dispatch_cmd);
 g_test_add_func("/qmp/dispatch_cmd_failure", test_dispatch_cmd_failure);
 g_test_add_func("/qmp/dispatch_cmd_io", test_dispatch_cmd_io);
+g_test_add_func("/qmp/dispatch_cmd_async", test_dispatch_cmd_async);
+g_test_add_func("/qmp/dispatch_cmd_async_no_id",
+test_dispatch_cmd_async_no_id);
+

[Qemu-devel] [PATCH v2 05/25] qmp: add QmpClient

2017-01-18 Thread Marc-André Lureau
Add a new QmpClient structure holding the dispatch return callback
and the list of pending QmpReturns.

When a client disconnects, call qmp_client_destroy(). This will remove
all pending returns from the client list, and prevent a reply from being
sent later: new clients will only receive reply they expect, and not one
from a previous client.

Signed-off-by: Marc-André Lureau 
---
 include/qapi/qmp/dispatch.h | 22 --
 monitor.c   | 10 +++---
 qapi/qmp-dispatch.c | 44 ++--
 qga/main.c  | 10 ++
 tests/test-qmp-commands.c   | 31 ++-
 5 files changed, 89 insertions(+), 28 deletions(-)

diff --git a/include/qapi/qmp/dispatch.h b/include/qapi/qmp/dispatch.h
index 780b3e2a09..32876764f3 100644
--- a/include/qapi/qmp/dispatch.h
+++ b/include/qapi/qmp/dispatch.h
@@ -17,14 +17,23 @@
 #include "qapi/qmp/qobject.h"
 #include "qapi/qmp/qdict.h"
 
-typedef void (QmpDispatchReturn) (QObject *rsp, void *opaque);
+typedef struct QmpClient QmpClient;
+
+typedef void (QmpDispatchReturn) (QmpClient *client, QObject *rsp);
 
 typedef struct QmpReturn {
 QDict *rsp;
-QmpDispatchReturn *return_cb;
-void *opaque;
+QmpClient *client;
+
+QLIST_ENTRY(QmpReturn) link;
 } QmpReturn;
 
+struct QmpClient {
+QmpDispatchReturn *return_cb;
+
+QLIST_HEAD(, QmpReturn) pending;
+};
+
 typedef void (QmpCommandFunc)(QDict *, QObject **, Error **);
 
 typedef enum QmpCommandOptions
@@ -46,8 +55,9 @@ void qmp_register_command(const char *name, QmpCommandFunc 
*fn,
   QmpCommandOptions options);
 void qmp_unregister_command(const char *name);
 QmpCommand *qmp_find_command(const char *name);
-void qmp_dispatch(QObject *request, QDict *rsp,
-  QmpDispatchReturn *return_cb, void *opaque);
+void qmp_client_init(QmpClient *client, QmpDispatchReturn *return_cb);
+void qmp_client_destroy(QmpClient *client);
+void qmp_dispatch(QmpClient *client, QObject *request, QDict *rsp);
 void qmp_disable_command(const char *name);
 void qmp_enable_command(const char *name);
 bool qmp_command_is_enabled(const QmpCommand *cmd);
@@ -61,7 +71,7 @@ void qmp_for_each_command(qmp_cmd_callback_fn fn, void 
*opaque);
  * qmp_return{_error}:
  *
  * Construct the command reply, and call the
- * return_cb() associated with the dispatch.
+ * return_cb() associated with the QmpClient.
  *
  * Finally, free the QmpReturn.
  */
diff --git a/monitor.c b/monitor.c
index 462ee127b4..98ba40b573 100644
--- a/monitor.c
+++ b/monitor.c
@@ -165,6 +165,7 @@ typedef struct {
  * mode.
  */
 bool in_command_mode;   /* are we in command mode? */
+QmpClient client;
 } MonitorQMP;
 
 /*
@@ -584,6 +585,7 @@ static void monitor_data_destroy(Monitor *mon)
 if (monitor_is_qmp(mon)) {
 json_message_parser_destroy(>qmp.parser);
 }
+qmp_client_destroy(>qmp.client);
 g_free(mon->rs);
 QDECREF(mon->outbuf);
 qemu_mutex_destroy(>out_lock);
@@ -3723,9 +3725,9 @@ static QDict *qmp_check_input_obj(QObject *input_obj, 
Error **errp)
 return input_dict;
 }
 
-static void qmp_dispatch_return(QObject *rsp, void *opaque)
+static void qmp_dispatch_return(QmpClient *client, QObject *rsp)
 {
-Monitor *mon = opaque;
+Monitor *mon = container_of(client, Monitor, qmp.client);
 
 monitor_json_emitter(mon, rsp);
 }
@@ -3765,7 +3767,7 @@ static void handle_qmp_command(JSONMessageParser *parser, 
GQueue *tokens)
 goto err_out;
 }
 
-qmp_dispatch(req, rqdict, qmp_dispatch_return, mon);
+qmp_dispatch(>qmp.client, req, rqdict);
 qobject_decref(req);
 return;
 
@@ -3854,6 +3856,7 @@ static void monitor_qmp_event(void *opaque, int event)
 
 switch (event) {
 case CHR_EVENT_OPENED:
+qmp_client_init(>qmp.client, qmp_dispatch_return);
 mon->qmp.in_command_mode = false;
 data = get_qmp_greeting();
 monitor_json_emitter(mon, data);
@@ -3863,6 +3866,7 @@ static void monitor_qmp_event(void *opaque, int event)
 case CHR_EVENT_CLOSED:
 json_message_parser_destroy(>qmp.parser);
 json_message_parser_init(>qmp.parser, handle_qmp_command);
+qmp_client_destroy(>qmp.client);
 mon_refcount--;
 monitor_fdsets_cleanup();
 break;
diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
index 7e9d03f262..31227ce6e9 100644
--- a/qapi/qmp-dispatch.c
+++ b/qapi/qmp-dispatch.c
@@ -120,6 +120,10 @@ static void qmp_return_free(QmpReturn *qret)
 {
 QDict *rsp = qret->rsp;
 
+if (qret->client) {
+QLIST_REMOVE(qret, link);
+}
+
 qobject_decref(QOBJECT(rsp));
 g_free(qret);
 }
@@ -127,8 +131,11 @@ static void qmp_return_free(QmpReturn *qret)
 static void do_qmp_return(QmpReturn *qret)
 {
 QDict *rsp = qret->rsp;
+QmpClient *client = qret->client;
 
-qret->return_cb(QOBJECT(rsp), qret->opaque);
+if 

[Qemu-devel] [PATCH v2 13/25] monitor: add 'async' capability

2017-01-18 Thread Marc-André Lureau
Declare that the server supports async.

Check if the client supports it: the following patch will suspend the
qmp monitor if an async command is ongoing but the client doesn't
support async.

Signed-off-by: Marc-André Lureau 
---
 qapi-schema.json| 16 ++--
 include/qapi/qmp/dispatch.h |  1 +
 monitor.c   | 19 ---
 3 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index ddc878390e..8366206415 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -72,11 +72,23 @@
 ##
 
 ##
+# @QMPCapability:
+#
+# QMP protocol capabilities
+#
+# @async: enables async messages
+#
+# Since: 2.9
+##
+{ 'enum': 'QMPCapability',
+  'data': ['async'] }
+
+##
 # @qmp_capabilities:
 #
 # Enable QMP capabilities.
 #
-# Arguments: None.
+# @capabilities: #optional an array of @QMPCapability (since 2.9)
 #
 # Example:
 #
@@ -90,7 +102,7 @@
 # Since: 0.13
 #
 ##
-{ 'command': 'qmp_capabilities' }
+{ 'command': 'qmp_capabilities', 'data': { '*capabilities': ['QMPCapability'] 
} }
 
 ##
 # @LostTickPolicy:
diff --git a/include/qapi/qmp/dispatch.h b/include/qapi/qmp/dispatch.h
index e13e381834..4dd6de5ab2 100644
--- a/include/qapi/qmp/dispatch.h
+++ b/include/qapi/qmp/dispatch.h
@@ -32,6 +32,7 @@ struct QmpClient {
 QmpDispatchReturn *return_cb;
 
 QLIST_HEAD(, QmpReturn) pending;
+bool has_async; /* the client has async capability */
 };
 
 typedef void (QmpCommandFunc)(QDict *, QObject **, Error **);
diff --git a/monitor.c b/monitor.c
index 98ba40b573..585f7b6a1a 100644
--- a/monitor.c
+++ b/monitor.c
@@ -563,9 +563,22 @@ static void monitor_qapi_event_init(void)
 qmp_event_set_func_emit(monitor_qapi_event_queue);
 }
 
-void qmp_qmp_capabilities(Error **errp)
+void qmp_qmp_capabilities(bool has_capabilities,
+  QMPCapabilityList *capabilities, Error **errp)
 {
+bool has_async = false;
+
+if (has_capabilities) {
+while (capabilities) {
+if (capabilities->value == QMP_CAPABILITY_ASYNC) {
+has_async = true;
+}
+capabilities = capabilities->next;
+}
+}
+
 cur_mon->qmp.in_command_mode = true;
+cur_mon->qmp.client.has_async = has_async;
 }
 
 static void handle_hmp_command(Monitor *mon, const char *cmdline);
@@ -3845,8 +3858,8 @@ static QObject *get_qmp_greeting(void)
 
 qmp_marshal_query_version(NULL, , NULL);
 
-return qobject_from_jsonf("{'QMP': {'version': %p, 'capabilities': []}}",
-  ver);
+return qobject_from_jsonf("{'QMP': {'version': %p, 'capabilities': ["
+  "'async']}}", ver);
 }
 
 static void monitor_qmp_event(void *opaque, int event)
-- 
2.11.0.295.gd7dffce1c




[Qemu-devel] [PATCH v2 3/6] qlist: Add convenience helpers for wrapped appends

2017-01-18 Thread Eric Blake
Similar to the qdict additions of the previous patch, although
this time there are not as many clients.

Signed-off-by: Eric Blake 
---
 include/qapi/qmp/qlist.h |  8 
 tests/check-qdict.c  | 10 +-
 tests/check-qlist.c  |  2 +-
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/include/qapi/qmp/qlist.h b/include/qapi/qmp/qlist.h
index a84117e..659325a 100644
--- a/include/qapi/qmp/qlist.h
+++ b/include/qapi/qmp/qlist.h
@@ -29,6 +29,14 @@ typedef struct QList {
 #define qlist_append(qlist, obj) \
 qlist_append_obj(qlist, QOBJECT(obj))

+/* Helpers for int, bool, and const char*. */
+#define qlist_append_int(qlist, value) \
+qlist_append(qlist, qint_from_int(value))
+#define qlist_append_bool(qlist, value) \
+qlist_append(qlist, qbool_from_bool(value))
+#define qlist_append_str(qlist, value) \
+qlist_append(qlist, qstring_from_str(value))
+
 #define QLIST_FOREACH_ENTRY(qlist, var) \
 for ((var) = ((qlist)->head.tqh_first); \
 (var);  \
diff --git a/tests/check-qdict.c b/tests/check-qdict.c
index d00b411..6d4f8a7 100644
--- a/tests/check-qdict.c
+++ b/tests/check-qdict.c
@@ -297,11 +297,11 @@ static void qdict_flatten_test(void)
 qdict_put_int(dict1, "a", 0);
 qdict_put_int(dict1, "b", 1);

-qlist_append_obj(list1, QOBJECT(qint_from_int(23)));
-qlist_append_obj(list1, QOBJECT(qint_from_int(66)));
-qlist_append_obj(list1, QOBJECT(dict1));
-qlist_append_obj(list2, QOBJECT(qint_from_int(42)));
-qlist_append_obj(list2, QOBJECT(list1));
+qlist_append_int(list1, 23);
+qlist_append_int(list1, 66);
+qlist_append(list1, dict1);
+qlist_append_int(list2, 42);
+qlist_append(list2, list1);

 qdict_put_int(dict2, "c", 2);
 qdict_put_int(dict2, "d", 3);
diff --git a/tests/check-qlist.c b/tests/check-qlist.c
index e16da5e..38463f1 100644
--- a/tests/check-qlist.c
+++ b/tests/check-qlist.c
@@ -74,7 +74,7 @@ static void qlist_destroy_test(void)
 qlist = qlist_new();

 for (i = 0; i < 42; i++)
-qlist_append(qlist, qint_from_int(i));
+qlist_append_int(qlist, i);

 QDECREF(qlist);
 }
-- 
2.9.3




[Qemu-devel] [PATCH v2 22/25] console: add graphic_hw_update_done()

2017-01-18 Thread Marc-André Lureau
Add a function to be called when an async graphic update is done.

Signed-off-by: Marc-André Lureau 
---
 include/ui/console.h| 1 +
 hw/display/qxl-render.c | 9 +++--
 ui/console.c| 4 
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/ui/console.h b/include/ui/console.h
index 9dd53c1a0f..e2d4f0df0d 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -380,6 +380,7 @@ void graphic_console_set_hwops(QemuConsole *con,
void *opaque);
 
 bool graphic_hw_update(QemuConsole *con);
+void graphic_hw_update_done(QemuConsole *con);
 void graphic_hw_invalidate(QemuConsole *con);
 void graphic_hw_text_update(QemuConsole *con, console_ch_t *chardata);
 void graphic_hw_gl_block(QemuConsole *con, bool block);
diff --git a/hw/display/qxl-render.c b/hw/display/qxl-render.c
index 50a019162f..8341f583a2 100644
--- a/hw/display/qxl-render.c
+++ b/hw/display/qxl-render.c
@@ -106,7 +106,7 @@ static void qxl_render_update_area_unlocked(PCIQXLDevice 
*qxl)
 qxl->guest_primary.surface.mem,
 MEMSLOT_GROUP_GUEST);
 if (!qxl->guest_primary.data) {
-return;
+goto end;
 }
 qxl_set_rect_to_surface(qxl, >dirty[0]);
 qxl->num_dirty_rects = 1;
@@ -134,7 +134,7 @@ static void qxl_render_update_area_unlocked(PCIQXLDevice 
*qxl)
 }
 
 if (!qxl->guest_primary.data) {
-return;
+goto end;
 }
 for (i = 0; i < qxl->num_dirty_rects; i++) {
 if (qemu_spice_rect_is_empty(qxl->dirty+i)) {
@@ -155,6 +155,11 @@ static void qxl_render_update_area_unlocked(PCIQXLDevice 
*qxl)
qxl->dirty[i].bottom - qxl->dirty[i].top);
 }
 qxl->num_dirty_rects = 0;
+
+end:
+if (qxl->render_update_cookie_num == 0) {
+graphic_hw_update_done(qxl->ssd.dcl.con);
+}
 }
 
 /*
diff --git a/ui/console.c b/ui/console.c
index 9131e45b36..46ad6abd94 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -254,6 +254,10 @@ static void gui_setup_refresh(DisplayState *ds)
 ds->have_text = have_text;
 }
 
+void graphic_hw_update_done(QemuConsole *con)
+{
+}
+
 bool graphic_hw_update(QemuConsole *con)
 {
 if (!con) {
-- 
2.11.0.295.gd7dffce1c




[Qemu-devel] [PATCH v2 06/25] qmp: add qmp_return_is_cancelled()

2017-01-18 Thread Marc-André Lureau
If the client is gone, no need to return. The async handler can use this
information to avoid unnecessary work and exit earlier.

Signed-off-by: Marc-André Lureau 
---
 include/qapi/qmp/dispatch.h |  8 
 qapi/qmp-dispatch.c | 10 ++
 2 files changed, 18 insertions(+)

diff --git a/include/qapi/qmp/dispatch.h b/include/qapi/qmp/dispatch.h
index 32876764f3..bc64d4ed15 100644
--- a/include/qapi/qmp/dispatch.h
+++ b/include/qapi/qmp/dispatch.h
@@ -78,4 +78,12 @@ void qmp_for_each_command(qmp_cmd_callback_fn fn, void 
*opaque);
 void qmp_return(QmpReturn *qret, QObject *cmd_rsp);
 void qmp_return_error(QmpReturn *qret, Error *err);
 
+/*
+ * qmp_return_is_cancelled:
+ *
+ * Return true if the QmpReturn is cancelled, and free the QmpReturn
+ * in this case.
+ */
+bool qmp_return_is_cancelled(QmpReturn *qret);
+
 #endif
diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
index 31227ce6e9..6ceece5ef0 100644
--- a/qapi/qmp-dispatch.c
+++ b/qapi/qmp-dispatch.c
@@ -155,6 +155,16 @@ void qmp_return_error(QmpReturn *qret, Error *err)
 do_qmp_return(qret);
 }
 
+bool qmp_return_is_cancelled(QmpReturn *qret)
+{
+if (!qret->client) {
+qmp_return_free(qret);
+return true;
+}
+
+return false;
+}
+
 void qmp_client_init(QmpClient *client, QmpDispatchReturn *return_cb)
 {
 assert(!client->return_cb);
-- 
2.11.0.295.gd7dffce1c




Re: [Qemu-devel] [PATCH 2/2] vl: Print warning when a default config file is loaded

2017-01-18 Thread Eduardo Habkost
On Wed, Jan 18, 2017 at 05:04:45PM +0100, Markus Armbruster wrote:
> Eduardo Habkost  writes:
> 
> > In case there were options set in the default config file, print
> > a warning so users can update their scripts.
> 
> Can you explain why you don't warn on an empty qemu.conf?

I didnt't want to show the warning to users that won't be
affected by the change. I assume that users with empty qemu.conf
files won't care when we stop loading it.

> 
> > If somebody wants to keep the config file as-is, avoid the
> > warning and use a command-line that will work in future QEMU
> > versions, they can use:
> >
> >  $QEMU -nodefconfig -readconfig /etc/qemu/qemu.conf
> >
> > I was going to add an additional message suggesting it as a
> > solution, but I thought it could make it more confusing. The
> > solution can be documented in the QEMU 2.9 ChangeLog.
> >
> > Signed-off-by: Eduardo Habkost 
> > ---
> >  vl.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/vl.c b/vl.c
> > index b563f9b924..e80b6da4bd 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -2999,6 +2999,12 @@ static int qemu_read_default_config_file(void)
> >  return ret;
> >  }
> >  
> > +if (ret > 0) {
> > +loc_set_none();
> > +error_report("Warning: Future QEMU versions won't load %s 
> > automatically",
> > + CONFIG_QEMU_CONFDIR "/qemu.conf");
> > +}
> > +
> >  return 0;
> >  }

-- 
Eduardo



Re: [Qemu-devel] [PATCH v6 wave 2 2/3] hw/isa/lpc_ich9: add broadcast SMI feature

2017-01-18 Thread Igor Mammedov
On Wed, 18 Jan 2017 16:42:27 +0100
Laszlo Ersek  wrote:

> On 01/18/17 13:38, Igor Mammedov wrote:
> > On Wed, 18 Jan 2017 11:23:48 +0100
> > Laszlo Ersek  wrote:
> >   
> >> On 01/18/17 11:19, Laszlo Ersek wrote:  
> >>> On 01/18/17 11:03, Igor Mammedov wrote:
>  On Tue, 17 Jan 2017 19:53:21 +0100
>  Laszlo Ersek  wrote:
> 
> >>
> >> [snip]
> >>  
> > This is the code I wrote (extracting a new ich9_apm_broadcast_smi()
> > function from ich9_apm_ctrl_changed(), due to size reasons):
> >
> >> static void ich9_apm_broadcast_smi(void)
> >> {
> >> CPUState *cs;
> >>
> >> cpu_synchronize_all_states(); /* <- mark this */
>  it probably should be executed after pause_all_vcpus(),
>  maybe it will help.
> 
> >> CPU_FOREACH(cs) {
> >> X86CPU *cpu = X86_CPU(cs);
> >> CPUX86State *env = >env;
> >>
> >> if (env->smbase == 0x3 && env->eip == 0xfff0) {
> >> CPUClass *k = CPU_GET_CLASS(cs);
> >> uint64_t cpu_arch_id = k->get_arch_id(cs);
> >>
> >> trace_ich9_apm_broadcast_smi_skip(cpu_arch_id);
> >> continue;
> >> }
> >>
> >> cpu_interrupt(cs, CPU_INTERRUPT_SMI);
> >> }
> >> }  
> >
>  [...]
> > (b) If I add the cpu_synchronize_all_states() call before the loop, then
> > the incorrect filter matches go away; QEMU sees the KVM VCPU states
> > correctly, and the SMI is broad-cast.
> >
> > However, in this case, the boot slows to a *crawl*. It's unbearable. All
> > VCPUs are pegged at 100%, and you can easily follow the OVMF debug log
> > with the naked eye, almost line by line.
> > I didn't expect that cpu_synchronize_all_states() would be so costly,
> > but it makes the idea of checking VCPU state in the APM_CNT handler a
> > non-starter.
>  I wonder were bottleneck is to slow down guest so much.
>  What is actual cost of calling cpu_synchronize_all_states()?
> 
>  Maybe calling pause_all_vcpus() before cpu_synchronize_all_states()
>  would help.
> >>>
> >>> If I prepend just a pause_all_vcpus() function call, at the top, then
> >>> the VM freezes (quite understandably) when the first SMI is raised via
> >>> APM_CNT.
> >>>
> >>> If I, instead, bracket the function body with pause_all_vcpus() and
> >>> resume_all_vcpus(), like this:
> >>>
> >>> static void ich9_apm_broadcast_smi(void)
> >>> {
> >>> CPUState *cs;
> >>>
> >>> pause_all_vcpus();
> >>> cpu_synchronize_all_states();
> >>> CPU_FOREACH(cs) {
> >>> X86CPU *cpu = X86_CPU(cs);
> >>> CPUX86State *env = >env;
> >>>
> >>> if (env->smbase == 0x3 && env->eip == 0xfff0) {
> >>> CPUClass *k = CPU_GET_CLASS(cs);
> >>> uint64_t cpu_arch_id = k->get_arch_id(cs);
> >>>
> >>> trace_ich9_apm_broadcast_smi_skip(cpu_arch_id);
> >>> continue;
> >>> }
> >>>
> >>> cpu_interrupt(cs, CPU_INTERRUPT_SMI);
> >>> }
> >>> resume_all_vcpus();
> >>> }
> >>>
> >>> then I see the following symptoms:
> >>> - rather than 4 VCPUs being pegged at 100%, only one VCPU is pegged at
> >>>   100%
> >>> - the boot process, as observed from the OVMF log, is just as slow
> >>>   (= crawling) as without the VCPU pausing/resuming (i.e., like with
> >>>   cpu_synchronize_all_states() only); so ultimately the
> >>>   pausing/resuming doesn't help.
> >>
> >> I also tried this variant (bracketing only the sync call with 
> >> pause/resume):
> >>
> >> static void ich9_apm_broadcast_smi(void)
> >> {
> >> CPUState *cs;
> >>
> >> pause_all_vcpus();
> >> cpu_synchronize_all_states();
> >> resume_all_vcpus();
> >> CPU_FOREACH(cs) {
> >> X86CPU *cpu = X86_CPU(cs);
> >> CPUX86State *env = >env;
> >>
> >> if (env->smbase == 0x3 && env->eip == 0xfff0) {
> >> CPUClass *k = CPU_GET_CLASS(cs);
> >> uint64_t cpu_arch_id = k->get_arch_id(cs);
> >>
> >> trace_ich9_apm_broadcast_smi_skip(cpu_arch_id);
> >> continue;
> >> }
> >>
> >> cpu_interrupt(cs, CPU_INTERRUPT_SMI);
> >> }
> >> }
> >>
> >> This behaves identically to the version where pause/resume bracket the
> >> entire function body (i.e., 1 VCPU pegged, super-slow boot progress).  
> > wrapping entire function into pause_all_vcpus()/resume_all_vcpus()
> > looks better as then cpu_interrupt() would not need to send IPIs to CPUs
> > since pause_all_vcpus() would have done it.
> 
> I don't understand, why would a pause operation send IPIs?
pause_all forces exit on all CPUs and cpu_interrupt() does the same to
a CPU so if all CPUs were kicked out of running state then cpu_interrupt()
would skip kick out step.

> Do you mean the resume? Even in that case, 

[Qemu-devel] [PATCH 1/2] wdt: Add Aspeed watchdog device model

2017-01-18 Thread Cédric Le Goater
From: Joel Stanley 

The Aspeed SoC includes a set of watchdog timers using 32-bit
decrement counters, which can be based either on the APB clock or
a 1 MHz clock.

The watchdog timer is designed to prevent system deadlock and, in
general, it should be restarted before timeout. When a timeout occurs,
different types of signals can be generated, ARM reset, SOC reset,
System reset, CPU Interrupt, external signal or boot from alternate
block. The current model only performs the system reset function as
this is used by U-Boot and Linux.

Signed-off-by: Joel Stanley 
[clg: - fixed compile breakage
  - fixed io region size
  - added watchdog_perform_action() on timer expiry
  - wrote a commit log  
  - merged fixes from Andrew Jeffery to scale the reload value ]  
Signed-off-by: Cédric Le Goater 
---
 hw/watchdog/Makefile.objs|   1 +
 hw/watchdog/wdt_aspeed.c | 214 +++
 include/hw/watchdog/wdt_aspeed.h |  37 +++
 3 files changed, 252 insertions(+)
 create mode 100644 hw/watchdog/wdt_aspeed.c
 create mode 100644 include/hw/watchdog/wdt_aspeed.h

diff --git a/hw/watchdog/Makefile.objs b/hw/watchdog/Makefile.objs
index 72e3ffd93c59..9589bed63a3d 100644
--- a/hw/watchdog/Makefile.objs
+++ b/hw/watchdog/Makefile.objs
@@ -2,3 +2,4 @@ common-obj-y += watchdog.o
 common-obj-$(CONFIG_WDT_IB6300ESB) += wdt_i6300esb.o
 common-obj-$(CONFIG_WDT_IB700) += wdt_ib700.o
 common-obj-$(CONFIG_WDT_DIAG288) += wdt_diag288.o
+common-obj-$(CONFIG_ASPEED_SOC) += wdt_aspeed.o
diff --git a/hw/watchdog/wdt_aspeed.c b/hw/watchdog/wdt_aspeed.c
new file mode 100644
index ..96e62c54dc04
--- /dev/null
+++ b/hw/watchdog/wdt_aspeed.c
@@ -0,0 +1,214 @@
+/*
+ * ASPEED Watchdog Controller
+ *
+ * Copyright (C) 2016-2017 IBM Corp.
+ *
+ * This code is licensed under the GPL version 2 or later. See the
+ * COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "sysemu/watchdog.h"
+#include "hw/sysbus.h"
+#include "qemu/timer.h"
+#include "hw/watchdog/wdt_aspeed.h"
+
+#define WDT_IO_REGION_SIZE  0x20
+
+#define WDT_STATUS  0x00
+#define WDT_RELOAD_VALUE0x04
+#define WDT_RESTART 0x08
+#define WDT_CTRL0x0C
+#define WDT_TIMEOUT_STATUS  0x10
+#define WDT_TIMEOUT_CLEAR   0x14
+#define WDT_RESET_WDITH 0x18
+
+#define WDT_RESTART_MAGIC   0x4755
+
+static uint64_t aspeed_wdt_read(void *opaque, hwaddr offset, unsigned size)
+{
+AspeedWDTState *s = ASPEED_WDT(opaque);
+
+switch (offset) {
+case WDT_STATUS:
+return s->reg_status;
+case WDT_RELOAD_VALUE:
+return s->reg_reload_value;
+case WDT_RESTART:
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: read from write-only reg at offset 0x%"
+  HWADDR_PRIx "\n", __func__, offset);
+return 0;
+case WDT_CTRL:
+return s->reg_ctrl;
+case WDT_TIMEOUT_STATUS:
+case WDT_TIMEOUT_CLEAR:
+case WDT_RESET_WDITH:
+qemu_log_mask(LOG_UNIMP,
+  "%s: uninmplemented read at offset 0x%" HWADDR_PRIx "\n",
+  __func__, offset);
+return 0;
+default:
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: Out-of-bounds read at offset 0x%" HWADDR_PRIx "\n",
+  __func__, offset);
+return 0;
+}
+
+}
+
+#define PCLK_HZ 2400
+
+static void aspeed_wdt_write(void *opaque, hwaddr offset, uint64_t data,
+ unsigned size)
+{
+AspeedWDTState *s = ASPEED_WDT(opaque);
+bool en = data & BIT(0);
+bool pclk = !(data & BIT(4));
+
+switch (offset) {
+case WDT_STATUS:
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: write to read-only reg at offset 0x%"
+  HWADDR_PRIx "\n", __func__, offset);
+break;
+case WDT_RELOAD_VALUE:
+s->reg_reload_value = data;
+break;
+case WDT_RESTART:
+if ((data & 0x) == 0x4755) {
+uint32_t reload;
+
+s->reg_status = s->reg_reload_value;
+
+if (pclk) {
+reload = muldiv64(s->reg_reload_value, NANOSECONDS_PER_SECOND,
+  PCLK_HZ) ;
+} else {
+reload = s->reg_reload_value * 1000;
+}
+
+if (s->enabled) {
+timer_mod(s->timer,
+  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + reload);
+}
+}
+break;
+case WDT_CTRL:
+if (en && !s->enabled) {
+uint32_t reload;
+
+if (pclk) {
+reload = muldiv64(s->reg_reload_value, NANOSECONDS_PER_SECOND,
+  PCLK_HZ);
+} else {
+reload = s->reg_reload_value * 1000;
+}
+
+s->enabled = 

Re: [Qemu-devel] [PATCH RFC] acpi: add reset register to fadt

2017-01-18 Thread Michael S. Tsirkin
On Wed, Jan 18, 2017 at 12:45:54PM +0100, Phil Dennis-Jordan wrote:
> About 2 years ago, Reza Jelveh submitted essentially this same patch:
> https://lists.gnu.org/archive/html/qemu-devel/2015-03/msg05832.html
> 
> It adds the reset register defined in ACPI 2.0 to the x86 FADT, which fixes 
> rebooting for Darwin/OS X/macOS guests.
> 
> I'm trying to revive this as part of an effort to get recent versions of OS 
> X/macOS working in Qemu/KVM with OVMF and without the need for out-of-tree 
> patches. I've adapted the original patch so it cleanly applies on current 
> master. The unaddressed issues last time around were:
> 
>  1. Does this work with a range of Windows versions?
> 
> I've tested this new version of the patch with KVM from Ubuntu's 
> 4.4.0-51-generic kernel, using the following guests:
> 
>  * Windows XP SP2 and SP3, x86. "pc" (FX440) machine, IDE disk, SeaBIOS.
>  * Windows 7 SP 1, x86. "pc" (FX440) machine, AHCI disk, SeaBIOS.
>  * Windows 10 1607, x86-64, q35 machine, AHCI disk, OVMF from 2017-01-17 EDK2 
> master.
>  * OS X 10.9 to 10.11, macOS 10.12; patched OVMF [1]
> 
> In all cases I went through a fresh install, checked basic functionality, and 
> rebooting. I noticed nothing different in any of the Windows VMs, and of 
> course the Darwin-based ones no longer hang when attempting to reboot.
> 
> 
>  2. The reset register is defined in ACPI 2.0, this still advertises 1.0.
> 
> I have to admit, I know very little about how ACPI works, so I'm not sure I 
> got this right, but: I subsequently added a line
> rsdp->revision = 0x02;
> to build_rsdp() in acpi-build.c, then booted the aforementioned Windows VMs, 
> and the macOS 10.12 one with this change. I noticed no change or ill effect 
> whatsoever.

For RSDP revision, I don't think we need to bother with it. People do
mix revisions of tables in practice.

I think what's important is the Fadt format revision. That one was 1 for 1.0b 
and 3 for 2.0.

See page 112, Table 5-5 Fixed ACPI Description Table Format in acpi spec
1.0b.

Now look at page 110 in spec 2.0, this time
"Table 5-8 Fixed ACPI Description Table (FADT) Format".

You will see that FADT revision is now 3, and there are a bunch of new
fields after the reset register. I think you have to fill them in,
you probably can get away with copying the non-extended values.




> I suspect more might be involved in enabling ACPI 2.0, and it should probably 
> be an option so as to avoid regressions. I don't know what the best approach 
> would be for this, so comments welcome. Should adding the reset register to 
> the FADT also be configurable?

I would say an option to make FADT use rev 3 format would be a good
idea.

I'd make it the default if XP survives.

> 
> Additionally, please suggest any further guest OSes and configurations I 
> should test which seem likely to exhibit regressions with this change.

Pls also try XP on q35. Paolo explained how on the thread you link to.

> 
> (First post to this list - apologies if I messed up any of the conventions! 
> Thanks, phil)
> 
> [1] EDK2 fork with OS X/macOS compatibility patches: 
> https://github.com/pmj/edk2/tree/mac-patches

It looks ok - you need to add your S.O.B (and maybe the original one)
to certify the origin of the patch. And you want to wrap lines around
80 characters.

> ---
>  hw/i386/acpi-build.c| 5 +
>  include/hw/acpi/acpi-defs.h | 2 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 0c8912f..93781a0 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -296,6 +296,11 @@ static void fadt_setup(AcpiFadtDescriptorRev1 *fadt, 
> AcpiPmInfo *pm)
>(1 << ACPI_FADT_F_SLP_BUTTON) |
>(1 << ACPI_FADT_F_RTC_S4));
>  fadt->flags |= cpu_to_le32(1 << ACPI_FADT_F_USE_PLATFORM_CLOCK);
> +fadt->flags |= cpu_to_le32(1 << ACPI_FADT_F_RESET_REG_SUP);
> +fadt->reset_val = 0xf;
> +fadt->reset_reg.address_space_id   = 1;
> +fadt->reset_reg.register_bit_width = 8;
> +fadt->reset_reg.address= ICH9_RST_CNT_IOPORT;
>  /* APIC destination mode ("Flat Logical") has an upper limit of 8 CPUs
>   * For more than 8 CPUs, "Clustered Logical" mode has to be used
>   */

So this works for PC too because RCR_IOPORT has the same value.
I think QEMU_BUILD_BUG_ON(ICH9_RST_CNT_IOPORT != RCR_IOPORT)
and a comment would be helpful here.


> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index 4cc3630..5755570 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -140,6 +140,8 @@ struct AcpiFadtDescriptorRev1
>  uint8_t  reserved4a; /* Reserved */
>  uint8_t  reserved4b; /* Reserved */
>  uint32_t flags;
> +Acpi20GenericAddress reset_reg;
> +uint8_t reset_val;
>  } QEMU_PACKED;
>  typedef struct AcpiFadtDescriptorRev1 AcpiFadtDescriptorRev1;

I think you want a 

[Qemu-devel] [PATCH v2 19/25] tests: add tests for async and non-async clients

2017-01-18 Thread Marc-André Lureau
Add two tests to check async and non-async client behaviour:
- an async client can see out of order replies
- an non-async client has commands processed in order

Signed-off-by: Marc-André Lureau 
---
 tests/qmp-test.c | 59 
 1 file changed, 59 insertions(+)

diff --git a/tests/qmp-test.c b/tests/qmp-test.c
index 480ff28339..f383d5d6f6 100644
--- a/tests/qmp-test.c
+++ b/tests/qmp-test.c
@@ -58,6 +58,61 @@ static void test_qom_set_without_value(void)
 QDECREF(ret);
 }
 
+static void test_no_async(void)
+{
+QDict *ret;
+int64_t id;
+
+/* check that only one async command is being processed */
+qmp_async("{'execute': 'qtest-timeout', 'id': 42, "
+  " 'arguments': { 'duration': 1 } }");
+qmp_async("{'execute': 'qtest-timeout', 'id': 43, "
+  " 'arguments': { 'duration': 0 } }");
+
+/* check that the second command didn't execute immediately */
+ret = qtest_qmp_receive(global_qtest);
+g_assert_nonnull(ret);
+id = qdict_get_try_int(ret, "id", -1);
+g_assert_cmpint(id, ==, 42);
+QDECREF(ret);
+
+/* check that the second command executes after */
+ret = qtest_qmp_receive(global_qtest);
+g_assert_nonnull(ret);
+id = qdict_get_try_int(ret, "id", -1);
+g_assert_cmpint(id, ==, 43);
+QDECREF(ret);
+}
+
+static void test_async(void)
+{
+QDict *ret;
+int64_t id;
+QTestState *qtest;
+
+qtest = qtest_init_qmp_caps("-machine none", "'async'");
+
+/* check that async are concurrent */
+qtest_async_qmp(qtest, "{'execute': 'qtest-timeout', 'id': 42, "
+  " 'arguments': { 'duration': 1 } }");
+qtest_async_qmp(qtest, "{'execute': 'qtest-timeout', 'id': 43, "
+  " 'arguments': { 'duration': 0 } }");
+
+ret = qtest_qmp_receive(qtest);
+g_assert_nonnull(ret);
+id = qdict_get_try_int(ret, "id", -1);
+g_assert_cmpint(id, ==, 43);
+QDECREF(ret);
+
+ret = qtest_qmp_receive(qtest);
+g_assert_nonnull(ret);
+id = qdict_get_try_int(ret, "id", -1);
+g_assert_cmpint(id, ==, 42);
+QDECREF(ret);
+
+qtest_quit(qtest);
+}
+
 int main(int argc, char **argv)
 {
 int ret;
@@ -70,6 +125,10 @@ int main(int argc, char **argv)
test_object_add_without_props);
 qtest_add_func("/qemu-qmp/qom-set-without-value",
test_qom_set_without_value);
+qtest_add_func("/qemu-qmp/no-async",
+   test_no_async);
+qtest_add_func("/qemu-qmp/async",
+   test_async);
 
 ret = g_test_run();
 
-- 
2.11.0.295.gd7dffce1c




Re: [Qemu-devel] [PATCH 00/16] aio_context_acquire/release pushdown, part 2

2017-01-18 Thread Paolo Bonzini


On 18/01/2017 17:03, Stefan Hajnoczi wrote:
> On Fri, Jan 13, 2017 at 02:17:15PM +0100, Paolo Bonzini wrote:
>> This series pushes down aio_context_acquire/release to the point
>> where we can actually reason on using different fine-grained mutexes.
>>
>> The main infrastructure is introduced in patch 1.  The new API aio_co_wake
>> starts a coroutine with aio_context_acquire/release protection, which
>> requires tracking each coroutine's "home" AioContext.  aio_co_schedule
>> instead takes care of moving a sleeping coroutine to a different
>> AioContext, also ensuring that it runs under aio_context_acquire/release.
>> This is useful to implement bdrv_set_aio_context, as a simpler alternative
>> to bottom halves.  Even though one-shot BHs are already simpler than
>> what we had before, after this patch aio_co_wake and aio_co_schedule
>> save you from having to do aio_context_acquire/release explicitly.
>>
>> After patch 2 and 3, which are just small preparatory changes, patches
>> 4 to 7 provide an example of how to use the new API.  In particular patch
>> 4 to 6 implement a new organization of coroutines in the NBD client,
>> which allows not blocking on partial reply header reads.
>>
>> Patch 8 introduces helpers for AioContext locking in QED, which is
>> the most complex AIO-based driver left.  Then the actual meat of the
>> series runs from patch 9 to patch 13, followed by small optimizations
>> in patches 14 and 15.
>>
>> The patches do some back and forth in adding/removing
>> aio_context_acquire/release calls in block/*.c but ultimately a small
>> number of aio_context_acquire/release pairs are added after the pushdown.
>> These are mostly in drivers that use external libraries (where they
>> actually could already be replaced by QemuMutex) and in device models.
>>
>> Notably, coroutines need not care about aio_context_acquire/release.
>> The device models ensure that the first creation of the coroutine has
>> the AioContext, while aio_co_wake/aio_co_schedule do the same after
>> they yield.  Therefore, most of the files only need to use those two
>> functions instead of, respectively, qemu_coroutine_enter and
>> aio_bh_schedule_oneshot.
>>
>> However, this is only an intermediate step which is needed because the
>> block layer and qemu-coroutine locks are thread-unsafe.  So the next
>> part will add separate locking, independent of AioContext, to block.c and
>> mostly block/io.c---this includes making CoMutex thread-safe.  Patch 16
>> therefore already documents the current locking policies block.h to
>> prepare for the next series.
>>
>> Paolo
>>
>> Paolo Bonzini (16):
>>   aio: introduce aio_co_schedule and aio_co_wake
>>   block-backend: allow blk_prw from coroutine context
>>   test-thread-pool: use generic AioContext infrastructure
>>   io: add methods to set I/O handlers on AioContext
>>   io: make qio_channel_yield aware of AioContexts
>>   nbd: do not block on partial reply header reads
>>   coroutine-lock: reschedule coroutine on the AioContext it was running
>> on
>>   qed: introduce qed_aio_start_io and qed_aio_next_io_cb
>>   aio: push aio_context_acquire/release down to dispatching
>>   block: explicitly acquire aiocontext in timers that need it
>>   block: explicitly acquire aiocontext in callbacks that need it
>>   block: explicitly acquire aiocontext in bottom halves that need it
>>   block: explicitly acquire aiocontext in aio callbacks that need it
>>   aio-posix: partially inline aio_dispatch into aio_poll
>>   async: remove unnecessary inc/dec pairs
>>   block: document fields protected by AioContext lock
>>
>>  aio-posix.c|  60 +++-
>>  aio-win32.c|  30 ++
>>  async.c|  81 ++--
>>  block/blkdebug.c   |   9 +-
>>  block/blkreplay.c  |   2 +-
>>  block/block-backend.c  |  13 ++-
>>  block/curl.c   |  44 ++---
>>  block/gluster.c|   9 +-
>>  block/io.c |   4 +-
>>  block/iscsi.c  |  15 ++-
>>  block/linux-aio.c  |  10 +-
>>  block/mirror.c |  12 ++-
>>  block/nbd-client.c | 108 -
>>  block/nbd-client.h |   2 +-
>>  block/nfs.c|   9 +-
>>  block/qed-cluster.c|   2 +
>>  block/qed-table.c  |  12 ++-
>>  block/qed.c|  58 +++
>>  block/qed.h|   3 +
>>  block/sheepdog.c   |  29 +++---
>>  block/ssh.c|  29 ++
>>  block/throttle-groups.c|   2 +
>>  block/win32-aio.c  |   9 +-
>>  dma-helpers.c  |   2 +
>>  hw/block/virtio-blk.c  |  19 +++-
>>  hw/scsi/scsi-bus.c |   2 +
>>  hw/scsi/scsi-disk.c|  15 +++
>>  hw/scsi/scsi-generic.c |  20 +++-
>>  hw/scsi/virtio-scsi.c  |   6 ++
>>  include/block/aio.h|  38 

Re: [Qemu-devel] [PATCH] numa: access CPU's node id via property in hmp_info_numa()

2017-01-18 Thread Igor Mammedov
On Wed, 18 Jan 2017 13:19:45 -0200
Eduardo Habkost  wrote:

> On Wed, Jan 18, 2017 at 03:48:45PM +0100, Igor Mammedov wrote:
> > Move vcpu's assocciated numa_node field out of generic CPUState
> > into inherited classes that actually care about cpu<->numa mapping
> > and make monitor 'info numa' get vcpu's assocciated node id via
> > node-id property.
> > It allows to drop implicit node id intialization in
> > numa_post_machine_init() and would allow switching to mapping
> > defined by target's CpuInstanceProperties instead of global
> > numa_info[i].node_cpu bitmaps.  
> 
> I agree to allow the node-id assignment logic to be defined by
> arch-specific code, but:
> 
> Considering that we still have the generic CPU<->node mapping in
> numa_info[].node_cpu, I don't see the benefit of moving the
> numa_info[].node_cpu => node-id translation from common generic
> code to duplicated arch-specific code.
it's duplicated for a time being until all targets that use
node_cpu are internally converted to socket/core/thread-id interface.
This patch is a part if re-factoring RFC which I'm about to post.


> What about adding this to cpu_generic_realize():
> 
>   node = (numa_get_node_for_cpu(cpu)
>   if (node >= 0) {
>  int cur_node = object_property_find(cpu, "node-id") ?
> object_property_get_int(cpu, "node-id") : -1;
>  if (cur_node >= 0 && cur_node != node) {
>  error_setg(, "Conflict between -numa option and CPU node-id");
>  goto out;
>  }
>  object_property_set_int(cpu, "node-id", node, );
>   }
What I don't like here is that putting above snippet into
cpu_generic_realize() is just doing the same implicit init
that numa_post_machine_init() has been doing before just
a bit later. It looks like a quick fix for 'info numa' issues.

However it would add stumble block on getting rid of 
numa_get_node_for_cpu() { numa_info[].node_cpu } and keeping
node-mapping along with the rest of topology in Machine object
instead of globals.

I'm in process of getting rid of numa_info[].node_cpu/numa_get_node_for_cpu()
altogether. And incrementally done it for PC, so I'd be forced
to reduplicate above snippet from cpu_generic_realize() in concrete
users anyway to do conversion without breaking other users.
 
[...]
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -1978,6 +1978,11 @@ static void pc_cpu_pre_plug(HotplugHandler 
> > *hotplug_dev,
> >  
> >  cs = CPU(cpu);
> >  cs->cpu_index = idx;
> > +
> > +idx = numa_get_node_for_cpu(cs->cpu_index);
> > +if (idx < nb_numa_nodes) {
> > +cpu->numa_nid = idx;
> > +}
this is the only place where I add above mentioned duplication,
which sort of compensated by removed numa_post_machine_init().
And it's here only to keep working+fix 'info numa'.
The other targets currently already do numa_get_node_for_cpu(),
lookup so I'm not changing there anything.
Later(not in this patch) I'm removing numa_get_node_for_cpu() from
pc_cpu_pre_plug() and from PC code altogether and replacing it
with node-id from possible_cpus.

PS:
since travis-ci seems to be broken, I'll post re-factoring
RFC without building there and it includes this patch as well.



[Qemu-devel] [PATCH v2 5/6] test-qga: Actually test 0xff sync bytes

2017-01-18 Thread Eric Blake
Commit 62c39b3 introduced test-qga, and at face value, appears
to be testing the 'guest-sync' behavior that is recommended for
guests in sending 0xff to QGA to force the parser to reset.  But
this aspect of the test has never actually done anything: the
qmp_fd() call chain converts its string argument into QObject,
then converts that QObject back to the actual string that is
sent over the wire - and the conversion process silently drops
the 0xff byte from the string sent to QGA, thus never resetting
the QGA parser.

An upcoming patch will get rid of the wasteful round trip
through QObject, at which point the string in test-qga will be
directly sent over the wire.

But fixing qmp_fd() to actually send 0xff over the wire is not
all we have to do - the actual QMP parser loudly complains that
0xff is not valid JSON, and sends an error message _prior_ to
actually parsing the 'guest-sync' or 'guest-sync-delimited'
command.  With 'guest-sync', we cannot easily tell if this error
message is a result of our command - which is WHY we invented
the 'guest-sync-delimited' command.  So for the testsuite, fix
things to only check 0xff behavior on 'guest-sync-delimited',
and to loop until we've consumed all garbage prior to the
requested delimiter, which matches the documented actions that
a real QGA client is supposed to do.

Ideally, we'd fix the QGA JSON parser to silently ignore 0xff
rather than sending an error message back, at which point we
could enhance this test for 'guest-sync' as well as for
'guest-sync-delimited'.  But for the sake of this patch, our
testing of 'guest-sync' is no worse than it was pre-patch,
because we have never been sending 0xff over the wire in the
first place.

Signed-off-by: Eric Blake 
---
 tests/libqtest.c |  8 
 tests/test-qga.c | 12 +++-
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/tests/libqtest.c b/tests/libqtest.c
index d8fba66..3912e3e 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -430,6 +430,14 @@ void qmp_fd_sendv(int fd, const char *fmt, va_list ap)
 va_list ap_copy;
 QObject *qobj;

+/* qobject_from_jsonv() silently eats leading 0xff as invalid
+ * JSON, but we want to test sending them over the wire to force
+ * resyncs */
+if (*fmt == '\377') {
+socket_send(fd, fmt, 1);
+fmt++;
+}
+
 /* Going through qobject ensures we escape strings properly.
  * This seemingly unnecessary copy is required in case va_list
  * is an array type.
diff --git a/tests/test-qga.c b/tests/test-qga.c
index 868b02a..4b64630 100644
--- a/tests/test-qga.c
+++ b/tests/test-qga.c
@@ -151,9 +151,11 @@ static void test_qga_sync_delimited(gconstpointer fix)
 qmp_fd_send(fixture->fd, cmd);
 g_free(cmd);

-v = read(fixture->fd, , 1);
-g_assert_cmpint(v, ==, 1);
-g_assert_cmpint(c, ==, 0xff);
+/* Read and ignore garbage until resynchronized */
+do {
+v = read(fixture->fd, , 1);
+g_assert_cmpint(v, ==, 1);
+} while (c != 0xff);

 ret = qmp_fd_receive(fixture->fd);
 g_assert_nonnull(ret);
@@ -172,8 +174,8 @@ static void test_qga_sync(gconstpointer fix)
 QDict *ret;
 gchar *cmd;

-cmd = g_strdup_printf("%c{'execute': 'guest-sync',"
-  " 'arguments': {'id': %u } }", 0xff, r);
+cmd = g_strdup_printf("{'execute': 'guest-sync',"
+  " 'arguments': {'id': %u } }", r);
 ret = qmp_fd(fixture->fd, cmd);
 g_free(cmd);

-- 
2.9.3




[Qemu-devel] [PATCH v2 2/6] qdict: Add convenience helpers for wrapped puts

2017-01-18 Thread Eric Blake
Quite a few users of qdict_put() were manually wrapping a
non-QObject. We can make such call-sites shorter, by providing
common macros to do the tedious work.  Also shorten nearby
qdict_put_obj(,,QOBJECT()) sequences.

Signed-off-by: Eric Blake 
Reviewed-by: Alberto Garcia 

---

v2: rebase to current master

I'm okay if you want me to break this patch into smaller pieces.
---
 include/qapi/qmp/qdict.h|   8 +++
 block.c |  59 +++-
 block/archipelago.c |   4 +-
 block/blkdebug.c|   6 +-
 block/blkverify.c   |  11 ++-
 block/curl.c|   2 +-
 block/file-posix.c  |   8 +--
 block/file-win32.c  |   4 +-
 block/iscsi.c   |   2 +-
 block/nbd.c |  41 ++-
 block/nfs.c |  43 +---
 block/null.c|   2 +-
 block/qcow2.c   |   4 +-
 block/quorum.c  |  13 ++--
 block/ssh.c |  16 ++---
 block/vvfat.c   |  10 +--
 blockdev.c  |  28 
 hw/block/xen_disk.c |   2 +-
 hw/usb/xen-usb.c|  12 ++--
 monitor.c   |  18 ++---
 qapi/qmp-event.c|   2 +-
 qemu-img.c  |   6 +-
 qemu-io.c   |   2 +-
 qemu-nbd.c  |   2 +-
 qobject/qdict.c |   2 +-
 target/s390x/cpu_models.c   |   4 +-
 tests/check-qdict.c | 132 ++--
 tests/test-qmp-commands.c   |  30 
 tests/test-qmp-event.c  |  30 
 tests/test-qobject-output-visitor.c |   6 +-
 util/qemu-option.c  |   6 +-
 31 files changed, 245 insertions(+), 270 deletions(-)

diff --git a/include/qapi/qmp/qdict.h b/include/qapi/qmp/qdict.h
index fe9a4c5..9d9f9a3 100644
--- a/include/qapi/qmp/qdict.h
+++ b/include/qapi/qmp/qdict.h
@@ -52,6 +52,14 @@ void qdict_destroy_obj(QObject *obj);
 #define qdict_put(qdict, key, obj) \
 qdict_put_obj(qdict, key, QOBJECT(obj))

+/* Helpers for int, bool, and const char*. */
+#define qdict_put_int(qdict, key, value) \
+qdict_put(qdict, key, qint_from_int(value))
+#define qdict_put_bool(qdict, key, value) \
+qdict_put(qdict, key, qbool_from_bool(value))
+#define qdict_put_str(qdict, key, value) \
+qdict_put(qdict, key, qstring_from_str(value))
+
 /* High level helpers */
 double qdict_get_double(const QDict *qdict, const char *key);
 int64_t qdict_get_int(const QDict *qdict, const char *key);
diff --git a/block.c b/block.c
index 39ddea3..e816657 100644
--- a/block.c
+++ b/block.c
@@ -876,16 +876,16 @@ static void update_flags_from_options(int *flags, 
QemuOpts *opts)
 static void update_options_from_flags(QDict *options, int flags)
 {
 if (!qdict_haskey(options, BDRV_OPT_CACHE_DIRECT)) {
-qdict_put(options, BDRV_OPT_CACHE_DIRECT,
-  qbool_from_bool(flags & BDRV_O_NOCACHE));
+qdict_put_bool(options, BDRV_OPT_CACHE_DIRECT,
+   flags & BDRV_O_NOCACHE);
 }
 if (!qdict_haskey(options, BDRV_OPT_CACHE_NO_FLUSH)) {
-qdict_put(options, BDRV_OPT_CACHE_NO_FLUSH,
-  qbool_from_bool(flags & BDRV_O_NO_FLUSH));
+qdict_put_bool(options, BDRV_OPT_CACHE_NO_FLUSH,
+   flags & BDRV_O_NO_FLUSH);
 }
 if (!qdict_haskey(options, BDRV_OPT_READ_ONLY)) {
-qdict_put(options, BDRV_OPT_READ_ONLY,
-  qbool_from_bool(!(flags & BDRV_O_RDWR)));
+qdict_put_bool(options, BDRV_OPT_READ_ONLY,
+   !(flags & BDRV_O_RDWR));
 }
 }

@@ -1244,7 +1244,7 @@ static int bdrv_fill_options(QDict **options, const char 
*filename,
 /* Fetch the file name from the options QDict if necessary */
 if (protocol && filename) {
 if (!qdict_haskey(*options, "filename")) {
-qdict_put(*options, "filename", qstring_from_str(filename));
+qdict_put_str(*options, "filename", filename);
 parse_filename = true;
 } else {
 error_setg(errp, "Can't specify 'file' and 'filename' options at "
@@ -1264,7 +1264,7 @@ static int bdrv_fill_options(QDict **options, const char 
*filename,
 }

 drvname = drv->format_name;
-qdict_put(*options, "driver", qstring_from_str(drvname));
+qdict_put_str(*options, "driver", drvname);
 } else {
 error_setg(errp, "Must specify either driver or file");
 return -EINVAL;
@@ -1517,7 +1517,7 @@ int bdrv_open_backing_file(BlockDriverState *bs, QDict 
*parent_options,
 }

 if (bs->backing_format[0] != '\0' && !qdict_haskey(options, "driver")) {
-

[Qemu-devel] [RFC 08/13] pc: add writeonly 'cpu' property to PCMachine

2017-01-18 Thread Igor Mammedov
it will allow generic numa code to set cpu to numa node mapping
in target independent manner in the next patch.

Signed-off-by: Igor Mammedov 
---
 hw/i386/pc.c | 56 
 1 file changed, 56 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f8ea635..1d33a5e 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -2201,6 +2201,56 @@ static void pc_machine_set_pit(Object *obj, bool value, 
Error **errp)
 pcms->pit = value;
 }
 
+static void pc_machine_set_cpu(Object *obj, Visitor *v, const char *name,
+   void *opaque, Error **errp)
+{
+uint32_t apic_id;
+X86CPUTopoInfo topo;
+CPUArchId *cpu_slot;
+Error *local_err = NULL;
+CpuInstanceProperties *cpu_props = NULL;
+PCMachineState *pcms = PC_MACHINE(obj);
+MachineClass *mc = MACHINE_GET_CLASS(obj);
+
+visit_type_CpuInstanceProperties(v, name, _props, _err);
+if (local_err) {
+goto out;
+}
+
+if (!cpu_props->has_node_id) {
+error_setg(_err, "node-id property is not specified");
+goto out;
+}
+
+/*
+ * make sure that possible_cpus is initialized
+ * as property setter might be called before machine init is called
+ */
+mc->possible_cpu_arch_ids(MACHINE(obj));
+
+topo.pkg_id = cpu_props->socket_id;
+topo.core_id = cpu_props->core_id;
+topo.smt_id = cpu_props->thread_id;
+apic_id = apicid_from_topo_ids(smp_cores, smp_threads, );
+cpu_slot = pc_find_cpu_slot(pcms, apic_id, NULL);
+if (!cpu_slot) {
+error_setg(_err, "unable to find CPU");
+goto out;
+}
+
+if (cpu_slot->props.has_node_id) {
+error_setg(_err, "CPU has already been assigned to node: 
%"PRId64,
+   cpu_slot->props.node_id);
+goto out;
+}
+cpu_slot->props.has_node_id = true;
+cpu_slot->props.node_id = cpu_props->node_id;
+
+ out:
+error_propagate(errp, local_err);
+qapi_free_CpuInstanceProperties(cpu_props);
+}
+
 static void pc_machine_initfn(Object *obj)
 {
 PCMachineState *pcms = PC_MACHINE(obj);
@@ -2395,6 +2445,12 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 
 object_class_property_add_bool(oc, PC_MACHINE_PIT,
 pc_machine_get_pit, pc_machine_set_pit, _abort);
+
+object_class_property_add(oc, "cpu", "CpuInstanceProperties",
+NULL, pc_machine_set_cpu,
+NULL, NULL, _abort);
+object_class_property_set_description(oc, "cpu",
+"Possible cpu placement", _abort);
 }
 
 static const TypeInfo pc_machine_info = {
-- 
2.7.4




Re: [Qemu-devel] [PATCH] virtio: force VIRTIO_F_IOMMU_PLATFORM

2017-01-18 Thread Michael S. Tsirkin
On Wed, Jan 18, 2017 at 10:42:48AM +0800, Jason Wang wrote:
> 
> 
> On 2017年01月17日 22:44, Michael S. Tsirkin wrote:
> > On Tue, Jan 17, 2017 at 12:01:00PM +0800, Jason Wang wrote:
> > > We allow vhost to clear VIRITO_F_IOMMU_PLATFORM which is wrong since
> > > VIRTIO_F_IOMMU_PLATFORM is mandatory for security. Fixing this by
> > > enforce it after vdc->get_features().
> > > 
> > > Signed-off-by: Jason Wang 
> > > ---
> > >   hw/virtio/virtio-bus.c | 5 +++--
> > >   1 file changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
> > > index d31cc00..a886011 100644
> > > --- a/hw/virtio/virtio-bus.c
> > > +++ b/hw/virtio/virtio-bus.c
> > > @@ -47,6 +47,7 @@ void virtio_bus_device_plugged(VirtIODevice *vdev, 
> > > Error **errp)
> > >   VirtioBusState *bus = VIRTIO_BUS(qbus);
> > >   VirtioBusClass *klass = VIRTIO_BUS_GET_CLASS(bus);
> > >   VirtioDeviceClass *vdc = VIRTIO_DEVICE_GET_CLASS(vdev);
> > > +bool has_iommu = virtio_host_has_feature(vdev, 
> > > VIRTIO_F_IOMMU_PLATFORM);
> > >   DPRINTF("%s: plug device.\n", qbus->name);
> > > @@ -63,8 +64,8 @@ void virtio_bus_device_plugged(VirtIODevice *vdev, 
> > > Error **errp)
> > >   klass->device_plugged(qbus->parent, errp);
> > >   }
> > > -if (klass->get_dma_as != NULL &&
> > > -virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM)) {
> > > +if (klass->get_dma_as != NULL && has_iommu) {
> > > +virtio_add_feature(>host_features, 
> > > VIRTIO_F_IOMMU_PLATFORM);
> > >   vdev->dma_as = klass->get_dma_as(qbus->parent);
> > >   } else {
> > >   vdev->dma_as = _space_memory;
> > I suspect that's not enough, we must also fail or disable vhost
> > (depending on the options), otherwise things won't work.
> 
> Looks like with the patch, VIRTIO_F_IOMMU_PLATFORM will be passed to
> vhost_set_features().

Okay then. Could you please test on an old host kernel and confirm
what happens? Pls mention this in commit log.

> So if vhost backend does not support it, it will fall
> back to userspace (This may not work for vhost-user, but it's a bug existed
> even before this patch).
> 
> Thanks

I guess this is true but this suddenly makes it important to
fix this. So I prefer a patchset where patch 2 addresses
the fallback bug. In which way? Do you think we should
just fail if vhost doesn't work? Does this apply to both
userspace and kernel?

-- 
MST



Re: [Qemu-devel] [PATCH v2 01/25] tests: start generic qemu-qmp tests

2017-01-18 Thread Marc-André Lureau


- Original Message -
> These 2 tests exhibited two qmp bugs that were fixed in 2.7
> (series from commit e64c75a9752c5d0fd64eb2e684c656a5ea7d03c6 to
> commit 1382d4abdf9619985e4078e37e49e487cea9935e)

Sorry, it was actually in 2.8

> 
> Signed-off-by: Marc-André Lureau 
> Reviewed-by: Daniel P. Berrange 
> Reviewed-by: Eric Blake 
> Reviewed-by: Markus Armbruster 
> Signed-off-by: Markus Armbruster 
> ---
>  tests/qmp-test.c   | 79
>  ++
>  MAINTAINERS|  1 +
>  tests/Makefile.include |  2 ++
>  3 files changed, 82 insertions(+)
>  create mode 100644 tests/qmp-test.c
> 
> diff --git a/tests/qmp-test.c b/tests/qmp-test.c
> new file mode 100644
> index 00..480ff28339
> --- /dev/null
> +++ b/tests/qmp-test.c
> @@ -0,0 +1,79 @@
> +/*
> + * QTest testcase for QMP
> + *
> + * Copyright (c) 2016 Red Hat, Inc.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + */
> +
> +/*
> + * This program tests QMP commands maintained with the QMP core.
> + * These are defined in qmp.c.  Tests for QMP commands defined in
> + * another subsystem should go into a test program maintained with
> + * that subsystem.
> + *
> + * TODO Actually cover the commands.  The tests we got so far only
> + * demonstrate specific bugs we've fixed.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "libqtest.h"
> +
> +static void test_object_add_without_props(void)
> +{
> +QDict *ret, *error;
> +const gchar *klass, *desc;
> +
> +ret = qmp("{'execute': 'object-add',"
> +  " 'arguments': { 'qom-type': 'memory-backend-ram', 'id':
> 'ram1' } }");
> +g_assert_nonnull(ret);
> +
> +error = qdict_get_qdict(ret, "error");
> +klass = qdict_get_try_str(error, "class");
> +desc = qdict_get_try_str(error, "desc");
> +
> +g_assert_cmpstr(klass, ==, "GenericError");
> +g_assert_cmpstr(desc, ==, "can't create backend with size 0");
> +
> +QDECREF(ret);
> +}
> +
> +static void test_qom_set_without_value(void)
> +{
> +QDict *ret, *error;
> +const gchar *klass, *desc;
> +
> +ret = qmp("{'execute': 'qom-set',"
> +  " 'arguments': { 'path': '/machine', 'property': 'rtc-time' }
> }");
> +g_assert_nonnull(ret);
> +
> +error = qdict_get_qdict(ret, "error");
> +klass = qdict_get_try_str(error, "class");
> +desc = qdict_get_try_str(error, "desc");
> +
> +g_assert_cmpstr(klass, ==, "GenericError");
> +g_assert_cmpstr(desc, ==, "Parameter 'value' is missing");
> +
> +QDECREF(ret);
> +}
> +
> +int main(int argc, char **argv)
> +{
> +int ret;
> +
> +g_test_init(, , NULL);
> +
> +qtest_start("-machine none");
> +
> +qtest_add_func("/qemu-qmp/object-add-without-props",
> +   test_object_add_without_props);
> +qtest_add_func("/qemu-qmp/qom-set-without-value",
> +   test_qom_set_without_value);
> +
> +ret = g_test_run();
> +
> +qtest_end();
> +
> +return ret;
> +}
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1444b26dc0..0c94a1ce27 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1368,6 +1368,7 @@ F: qmp.c
>  F: monitor.c
>  F: docs/*qmp-*
>  F: scripts/qmp/
> +F: tests/qmp-test.c
>  T: git git://repo.or.cz/qemu/armbru.git qapi-next
>  
>  Register API
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index 96f59703a1..152655d086 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -316,6 +316,7 @@ check-qtest-xtensaeb-y = $(check-qtest-xtensa-y)
>  check-qtest-s390x-y = tests/boot-serial-test$(EXESUF)
>  
>  check-qtest-generic-y += tests/qom-test$(EXESUF)
> +check-qtest-generic-y += tests/qmp-test$(EXESUF)
>  
>  qapi-schema += alternate-any.json
>  qapi-schema += alternate-array.json
> @@ -687,6 +688,7 @@ tests/tpci200-test$(EXESUF): tests/tpci200-test.o
>  tests/display-vga-test$(EXESUF): tests/display-vga-test.o
>  tests/ipoctal232-test$(EXESUF): tests/ipoctal232-test.o
>  tests/qom-test$(EXESUF): tests/qom-test.o
> +tests/qmp-test$(EXESUF): tests/qmp-test.o
>  tests/drive_del-test$(EXESUF): tests/drive_del-test.o $(libqos-pc-obj-y)
>  tests/qdev-monitor-test$(EXESUF): tests/qdev-monitor-test.o
>  $(libqos-pc-obj-y)
>  tests/nvme-test$(EXESUF): tests/nvme-test.o
> --
> 2.11.0.295.gd7dffce1c
> 
> 



Re: [Qemu-devel] [PATCH 05/16] io: make qio_channel_yield aware of AioContexts

2017-01-18 Thread Paolo Bonzini


On 18/01/2017 15:58, Stefan Hajnoczi wrote:
> On Fri, Jan 13, 2017 at 02:17:20PM +0100, Paolo Bonzini wrote:
>>  /**
>> + * qio_channel_set_aio_context:
>> + * @ioc: the channel object
>> + * @ctx: the #AioContext to set the handlers on
>> + *
>> + * Request that qio_channel_yield() sets I/O handlers on
>> + * the given #AioContext.  If @ctx is %NULL, qio_channel_yield()
>> + * uses QEMU's main thread event loop.
>> + */
>> +void qio_channel_set_aio_context(QIOChannel *ioc,
>> + AioContext *ctx);
>> +
>> +/**
>> + * qio_channel_detach_aio_context:
>> + * @ioc: the channel object
>> + *
>> + * Disable any I/O handlers set by qio_channel_yield().  With the
>> + * help of aio_co_schedule(), this allows moving a coroutine that was
>> + * paused by qio_channel_yield() to another context.
>> + */
>> +void qio_channel_detach_aio_context(QIOChannel *ioc);
> 
> The block layer's bdrv_set_aio_context() has different semantics.  It
> invokes .detach()/.attach() callbacks and does AioContext locking so the
> function can be called safely even while the block driver is waiting for
> events.
> 
> It's unfortunate to that the block and io channel APIs act differently
> despite having similar names.  Was there a reason to choose different
> semantics?

Hmm, it's true.  I had forgotten that bdrv_set_aio_context exists.

set_aio_context can be called from the block layer attach callback, but
it's not enough alone (you need aio_co_schedule too) so I didn't want to
call the function qio_channel_attach_aio_context.  But maybe it *is* a
better name, I'll go for it in v2.

By the way, v2 will have a better comment on how to use the API:

+ * You can move a #QIOChannel from an #AioContext to another even if
+ * I/O handlers are set for a coroutine.  However, #QIOChannel provides
+ * no synchronization between the calls to qio_channel_yield() and
+ * qio_channel_set_aio_context().
+ *
+ * Therefore you should first call qio_channel_detach_aio_context()
+ * to ensure that the coroutine is not entered concurrently.  Then,
+ * while the coroutine has yielded, call qio_channel_set_aio_context(),
+ * and then aio_co_schedule() to place the coroutine on the new
+ * #AioContext.  The calls to qio_channel_detach_aio_context()
+ * and qio_channel_set_aio_context() should be protected with
+ * aio_context_acquire() and aio_context_release().

The "while the coroutine has yielded" part is currently handled with
aio_context_acquire/aio_context_release (the coroutine cannot run at all
between aio_context_acquire and release).

When they will be gone, some kind of BDRV_POLL_WHILE at the end of
bdrv_detach_aio_context should be enough to ensure that the event loop
is quiescent.

Paolo

>> +
>> +/**
>>   * qio_channel_yield:
>>   * @ioc: the channel object
>>   * @condition: the I/O condition to wait for
>>   *
>> - * Yields execution from the current coroutine until
>> - * the condition indicated by @condition becomes
>> - * available.
>> + * Yields execution from the current coroutine until the condition
>> + * indicated by @condition becomes available.  @condition must
>> + * be either %G_IO_IN or %G_IO_OUT; it cannot contain both.  In
>> + * addition, no two coroutine can be waiting on the same condition
> 
> s/coroutine/coroutines/
> 



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH v2 6/6] qapi: Promote blockdev-change-medium arguments to QAPI type

2017-01-18 Thread Eric Blake
Having a named rather than anonymous C type will make it easier
to improve the testsuite in a later patch. No semantic change,
to any of the existing code or to the introspection output.

Signed-off-by: Eric Blake 

---
v2: rebase to master
---
 qapi/block-core.json | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index 1b3e6eb..0e31d25 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -3119,6 +3119,15 @@
 # combines blockdev-open-tray, x-blockdev-remove-medium,
 # x-blockdev-insert-medium and blockdev-close-tray).
 #
+# Since: 2.5
+##
+{ 'command': 'blockdev-change-medium',
+  'data': 'BlockdevChangeMedium' }
+
+
+##
+# @BlockdevChangeMedium:
+#
 # @device:  #optional Block device name (deprecated, use @id instead)
 #
 # @id:  #optional The name or QOM path of the guest device
@@ -3165,7 +3174,7 @@
 # <- { "return": {} }
 #
 ##
-{ 'command': 'blockdev-change-medium',
+{ 'struct': 'BlockdevChangeMedium',
   'data': { '*device': 'str',
 '*id': 'str',
 'filename': 'str',
-- 
2.9.3




[Qemu-devel] [PATCH v2 4/6] fdc-test: Avoid deprecated 'change' command

2017-01-18 Thread Eric Blake
Use the preferred blockdev-change-medium command instead.

Signed-off-by: Eric Blake 
Reviewed-by: John Snow 
---
 tests/fdc-test.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/fdc-test.c b/tests/fdc-test.c
index 738c6b4..f5ff68d 100644
--- a/tests/fdc-test.c
+++ b/tests/fdc-test.c
@@ -298,8 +298,9 @@ static void test_media_insert(void)

 /* Insert media in drive. DSKCHK should not be reset until a step pulse
  * is sent. */
-qmp_discard_response("{'execute':'change', 'arguments':{"
- " 'device':'floppy0', 'target': %s, 'arg': 'raw' }}",
+qmp_discard_response("{'execute':'blockdev-change-medium', 'arguments':{"
+ " 'device':'floppy0', 'filename': %s, "
+ "'format': 'raw' }}",
  test_image);

 dir = inb(FLOPPY_BASE + reg_dir);
-- 
2.9.3




Re: [Qemu-devel] [PATCH] x86-KVM: Supply TSC and APIC clock rates to guest like VMWare

2017-01-18 Thread Phil Dennis-Jordan
Thanks for the comments Paulo and Eduardo,

On 18 January 2017 at 16:05, Paolo Bonzini  wrote:
>
> > +DEFINE_PROP_BOOL("vmware-tsc-apic-clocks", X86CPU,
> vmware_clock_rates, false),
>
> Maybe just vmware-cpuid-freq instead?  Whatever the choice, please make
> the bool field in struct X86CPU consistent with the property name (e.g.
> enable_vmware_cpuid_freq).
>

Sounds good, I've fixed this and the page/leaf terminology mixup for the
next patch iteration.

One issue is that the TSC frequency can change, for example on
> migration.  Telling the guest about the TSC frequency makes little sense
> if it can change.
>

That makes sense. Darwin can't handle changing TSC frequencies in any case,
regardless of cpuid leaf 0x4010. Do I deduce correctly from the
following code (lines 967~977) that this bit inhibits migration
intrinsically, so other than depending on it, I don't need to specifically
disable migration for this option?

if (c && (c->edx & 1<<8) && invtsc_mig_blocker == NULL) {
…
vmstate_x86_cpu.unmigratable = 1;

(Likewise, it would appear that the user_tsc_khz case Eduardo suggested
already has a migration sanity check in cpu_post_load() too.)

So the leaf should be conditional on the INVTSC feature
> (CPUID[0x8007].EDX bit 8).  You can enable this unconditionally for
> new machine types (i.e. making it true here, and turning it off in
> include/hw/i386/pc.h's PC_COMPAT_2_8 macro), but only expose it if that
> bit is also set.
>

Sorry, you've lost me here. Would you mind explaining in a little more
detail? What would I be enabling unconditionally? (I'm getting lost on what
the various 'this'/'that'/'it' are referring to.)

> +if (cpu->vmware_clock_rates) {
>
> ^^ Here is where you should also check invtsc.
>
> > +if (cpu->expose_kvm
>
> I think this should not depend on cpu->expose_kvm.  This is not a KVM
> leaf, it's a vmware leaf; if it were a KVM leaf, it would obey kvm_base.
>  Of course checking kvm_base is still a good idea, to avoid stomping on
> Hyper-V's CPUID space.
>

Hmm, my thinking here is that leaf 0x4000 only is published if kvm or
Hyper-V is exposed. Without 0x4000, Darwin won't find 0x4010. Like
you say, this option is mutually exclusive with the Hyper-V leaves - so
either we rely on the KVM version of leaf 0x4000 (my code so far), or
this option will have to explicitly expose 0x4000. I'm not sure what
signature (ebx-edx) we should give it in the latter case - using VMWare's
seems off as it doesn't replicate any other of their leaves. Given that
exposing KVM is the default, anyone disabling it presumably has a reason
for not wanting page 0x4000 exposed. Thoughts?


Re: [Qemu-devel] [PATCH 06/16] nbd: do not block on partial reply header reads

2017-01-18 Thread Paolo Bonzini


On 18/01/2017 16:24, Stefan Hajnoczi wrote:
> On Fri, Jan 13, 2017 at 02:17:21PM +0100, Paolo Bonzini wrote:
>> @@ -65,54 +67,34 @@ static void nbd_teardown_connection(BlockDriverState *bs)
>>  client->ioc = NULL;
>>  }
>>  
>> -static void nbd_reply_ready(void *opaque)
>> +static void nbd_read_reply_entry(void *opaque)
> 
> Please use coroutine_fn.

Yes, you requested that in the RFC as well.

Paolo



Re: [Qemu-devel] [PATCH 2/2] vl: Print warning when a default config file is loaded

2017-01-18 Thread Markus Armbruster
Eduardo Habkost  writes:

> In case there were options set in the default config file, print
> a warning so users can update their scripts.

Can you explain why you don't warn on an empty qemu.conf?

> If somebody wants to keep the config file as-is, avoid the
> warning and use a command-line that will work in future QEMU
> versions, they can use:
>
>  $QEMU -nodefconfig -readconfig /etc/qemu/qemu.conf
>
> I was going to add an additional message suggesting it as a
> solution, but I thought it could make it more confusing. The
> solution can be documented in the QEMU 2.9 ChangeLog.
>
> Signed-off-by: Eduardo Habkost 
> ---
>  vl.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/vl.c b/vl.c
> index b563f9b924..e80b6da4bd 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2999,6 +2999,12 @@ static int qemu_read_default_config_file(void)
>  return ret;
>  }
>  
> +if (ret > 0) {
> +loc_set_none();
> +error_report("Warning: Future QEMU versions won't load %s 
> automatically",
> + CONFIG_QEMU_CONFDIR "/qemu.conf");
> +}
> +
>  return 0;
>  }



[Qemu-devel] [PATCH 2/2] aspeed: add a watchdog controller

2017-01-18 Thread Cédric Le Goater
This enables reboot of a guest from U-Boot and Linux.

Signed-off-by: Cédric Le Goater 
Reviewed-by: Joel Stanley 
---
 hw/arm/aspeed_soc.c | 13 +
 include/hw/arm/aspeed_soc.h |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index 4fb777e6df6e..6df76382f007 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -31,6 +31,7 @@
 #define ASPEED_SOC_SCU_BASE 0x1E6E2000
 #define ASPEED_SOC_SRAM_BASE0x1E72
 #define ASPEED_SOC_TIMER_BASE   0x1E782000
+#define ASPEED_SOC_WDT_BASE 0x1E785000
 #define ASPEED_SOC_I2C_BASE 0x1E78A000
 
 static const int uart_irqs[] = { 9, 32, 33, 34, 10 };
@@ -170,6 +171,10 @@ static void aspeed_soc_init(Object *obj)
  sc->info->silicon_rev);
 object_property_add_alias(obj, "ram-size", OBJECT(>sdmc),
   "ram-size", _abort);
+
+object_initialize(>wdt, sizeof(s->wdt), TYPE_ASPEED_WDT);
+object_property_add_child(obj, "wdt", OBJECT(>wdt), NULL);
+qdev_set_parent_bus(DEVICE(>wdt), sysbus_get_default());
 }
 
 static void aspeed_soc_realize(DeviceState *dev, Error **errp)
@@ -289,6 +294,14 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
 return;
 }
 sysbus_mmio_map(SYS_BUS_DEVICE(>sdmc), 0, ASPEED_SOC_SDMC_BASE);
+
+/* Watch dog */
+object_property_set_bool(OBJECT(>wdt), true, "realized", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(>wdt), 0, ASPEED_SOC_WDT_BASE);
 }
 
 static void aspeed_soc_class_init(ObjectClass *oc, void *data)
diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index 1ab5deaa0813..dbec0c159885 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -19,6 +19,7 @@
 #include "hw/timer/aspeed_timer.h"
 #include "hw/i2c/aspeed_i2c.h"
 #include "hw/ssi/aspeed_smc.h"
+#include "hw/watchdog/wdt_aspeed.h"
 
 #define ASPEED_SPIS_NUM  2
 
@@ -37,6 +38,7 @@ typedef struct AspeedSoCState {
 AspeedSMCState fmc;
 AspeedSMCState spi[ASPEED_SPIS_NUM];
 AspeedSDMCState sdmc;
+AspeedWDTState wdt;
 } AspeedSoCState;
 
 #define TYPE_ASPEED_SOC "aspeed-soc"
-- 
2.7.4




Re: [Qemu-devel] [Qemu-stable] Data corruption in Qemu 2.7.1

2017-01-18 Thread Paolo Bonzini


On 18/01/2017 17:19, Fabian Grünbichler wrote:
> Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#109 FAILED Result: 
> hostbyte=DID_OK driverbyte=DRIVER_SENSE
> Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#109 Sense Key : Illegal 
> Request [current]
> Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#109 Add. Sense: Invalid 
> field in cdb
> Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#109 CDB: Write(10) 2a 00 
> 0d d6 51 48 00 08 00 00
> Jan 18 17:07:51 ubuntu kernel: blk_update_request: critical target error, dev 
> sda, sector 232149320
> Jan 18 17:07:51 ubuntu kernel: EXT4-fs warning (device sda1): 
> ext4_end_bio:329: I/O error -121 writing to inode 125 (offset 0 size 0 
> starting block 29018921)
> Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical block 
> 29018409
> Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical block 
> 29018410
> Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical block 
> 29018411
> Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical block 
> 29018412
> Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical block 
> 29018413
> Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical block 
> 29018414
> Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical block 
> 29018415
> Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical block 
> 29018416
> Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical block 
> 29018417
> Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical block 
> 29018418
> Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#106 FAILED Result: 
> hostbyte=DID_OK driverbyte=DRIVER_SENSE
> Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#106 Sense Key : Illegal 
> Request [current]
> Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#106 Add. Sense: Invalid 
> field in cdb
> Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#106 CDB: Write(10) 2a 00 
> 0d d6 59 48 00 08 00 00
> Jan 18 17:07:51 ubuntu kernel: blk_update_request: critical target error, dev 
> sda, sector 232151368
> Jan 18 17:07:51 ubuntu kernel: EXT4-fs warning (device sda1): 
> ext4_end_bio:329: I/O error -121 writing to inode 125 (offset 0 size 0 
> starting block 29019177)
> Jan 18 17:07:52 ubuntu kernel: JBD2: Detected IO errors while flushing file 
> data on sda1-8
> Jan 18 17:07:58 ubuntu kernel: JBD2: Detected IO errors while flushing file 
> data on sda1-8
> 
> 
> strace (with some random grep-ing):
> [pid  1794] ioctl(19, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[10]=[2a, 00, 0d, d6, 
> 51, 48, 00, 08, 00, 00], mx_sb_len=252, iovec_count=17, dxfer_len=1048576, 
> timeout=4294967295, flags=0x1, 
> data[1048576]=["\0`\235=c\177\0\0\0\0\1\0\0\0\0\0\0`\236=c\177\0\0\0\0\1\0\0\0\0\0"...]})
>  = -1 EINVAL (Invalid argument)
> [pid  1794] ioctl(19, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[10]=[2a, 00, 0d, d6, 
> 59, 48, 00, 08, 00, 00], mx_sb_len=252, iovec_count=16, dxfer_len=1048576, 
> timeout=4294967295, flags=0x1, 
> data[1048576]=["\0`-=c\177\0\0\0\0\1\0\0\0\0\0\0`.=c\177\0\0\0\0\1\0\0\0\0\0"...]})
>  = -1 EINVAL (Invalid argument)

This is useful, thanks.  I suspect blk_rq_map_user_iov is failing,
meaning that the scatter/gather list has too many segments for the HBA
in the host.  (The limit can be found in /sys/block/sda/queue/max_segments).

This is consistent with your finding here:

> disabling THP on the hypervisor host with
> 
> # echo 'never' > /sys/kernel/mm/transparent_hugepage/enabled
> 
> allows reproducing the bug very reliably, shutting the VM down, then
> enabling THP (with 'always') and trying again makes it go away.

because no THP means more memory fragmentation and thus more segments.

I'm not sure how to fix it, unfortunately. :(

Paolo



Re: [Qemu-devel] [PATCH] x86-KVM: Supply TSC and APIC clock rates to guest like VMWare

2017-01-18 Thread Paolo Bonzini


On 18/01/2017 17:02, Phil Dennis-Jordan wrote:
> 
> One issue is that the TSC frequency can change, for example on
> migration.  Telling the guest about the TSC frequency makes little sense
> if it can change.
> 
> That makes sense. Darwin can't handle changing TSC frequencies in any
> case, regardless of cpuid leaf 0x4010. Do I deduce correctly from
> the following code (lines 967~977) that this bit inhibits migration
> intrinsically, so other than depending on it, I don't need to
> specifically disable migration for this option?

Correct.

> So the leaf should be conditional on the INVTSC feature
> (CPUID[0x8007].EDX bit 8).  You can enable this unconditionally for
> new machine types (i.e. making it true here, and turning it off in
> include/hw/i386/pc.h's PC_COMPAT_2_8 macro), but only expose it if that
> bit is also set.
> 
> Sorry, you've lost me here. Would you mind explaining in a little more
> detail? What would I be enabling unconditionally? (I'm getting lost on
> what the various 'this'/'that'/'it' are referring to.)

You enable vmware-cpuid-freq unconditionally.  But then you actually
publish 0x4010 only if INVTSC is set.
> 
> > +if (cpu->vmware_clock_rates) {
> 
> ^^ Here is where you should also check invtsc.
> 
> > +if (cpu->expose_kvm
> 
> I think this should not depend on cpu->expose_kvm.  This is not a KVM
> leaf, it's a vmware leaf; if it were a KVM leaf, it would obey kvm_base.
>  Of course checking kvm_base is still a good idea, to avoid stomping on
> Hyper-V's CPUID space.
> 
> Hmm, my thinking here is that leaf 0x4000 only is published if kvm
> or Hyper-V is exposed. Without 0x4000, Darwin won't find 0x4010.

Of course you're right, but please add a comment like this:

/* Guests depend on 0x4000 to detect this, so do not expose
 * it unless that leaf is present.
 */

Paolo



Re: [Qemu-devel] [Qemu-block] Question: any suggestions about zero-filled image grow of raw format files ?

2017-01-18 Thread Max Reitz
On 16.01.2017 07:20, fuweiwei (C) wrote:
> Dear all:
> 
>  
> 
> I have a question. In qemu-kvm platforms, raw format virtual images have
> several preallocation options,
> 
> such as thin (sparse, no preallocation), falloc and full (zero-filled
> preallocation). However, if one resize
> 
> a full-allocated image to a larger volume, the additional part of the
> image is thin-allocated. This may
> 
> introduce some diskspace management problems.

Adding something like preallocation=full would probably not be too
difficult, because qemu-img can just fill the space itself.

But adding preallocation=falloc for resize would probably require some
yet missing infrastructure in qemu. Currently, bdrv_truncate() is just a
function that takes the new size as an option and that's it.

> So I wonder if we could introduce zero-filled image grow (resize) for
> raw images. For offline image grow,
> 
> could we add addition options (-p) to specify the preallocation method
> for the additional part of image,
> 
> just like image creation:
> 
>  
> 
> qemu-img resize -f raw test.img [-p full] +1G
> 
>  
> 
> this will fill zeroes in the range of [original size, original size +
> 1G] in the file.

Well, for raw images you can just use fallocate afterwards manually; or,
if you want full preallocation, that shouldn't be too difficult to
implement.

> Online zero-filled image grow is the primary problem, because filling
> zeroes is time-consuming while
> 
> qmp_block_resize is a synchronized function, which may block the qemu
> main process. Is there any solutions?

The thing that comes to mind is doing the resize and then writing zeroes
in the guest.

Another thing that I can imagine, but which is probably strongly
disadvisable (because of several reasons of which I can only imagine a
few right now), is:

(0) modify the null block driver so that it can return BDRV_BLOCK_DATA
from null_co_get_block_status()

(1) resize the volume using block_resize; let size_old be the old size
and size_new be the new size
(2) blockdev-add a null-co block driver with read-zeroes=true,
size=$((new_size - old_size)), and the option so that it will return
BDRV_BLOCK_DATA
(3) blockdev-add a raw block driver on top of the original volume with
offset=old_size,size=$((new_size - old_size))
(4) blockdev-mirror from the null-co node to the new raw node

And you're done.

But as I said, that is a bad hack.

Maybe it would make sense to have a dedicated write-zeroes block job
that can write a range of zeroes to some offset of a block device.

This wouldn't help you if you wanted to use fallocate, but that is again
something that would need to be implemented for bdrv_truncate() and thus
exposed over block_resize.

Max





signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [RFC 02/13] pc: cleanup: move smbios_set_cpuid() into pc_build_smbios()

2017-01-18 Thread Igor Mammedov
move smbios_set_cpuid() close to the rest of smbios init code
where it belongs to instead of calling it from pc_cpus_init().

Signed-off-by: Igor Mammedov 
---
PS:
   it would allow to cleanup pc_new_cpu() in followup patch
---
 hw/i386/pc.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 9d2b265..2461d84 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -701,16 +701,20 @@ static uint32_t x86_cpu_apic_id_from_index(unsigned int 
cpu_index)
 }
 }
 
-static void pc_build_smbios(FWCfgState *fw_cfg)
+static void pc_build_smbios(PCMachineState *pcms)
 {
 uint8_t *smbios_tables, *smbios_anchor;
 size_t smbios_tables_len, smbios_anchor_len;
 struct smbios_phys_mem_area *mem_array;
 unsigned i, array_count;
+X86CPU *cpu = X86_CPU(pcms->possible_cpus->cpus[0].cpu);
+
+/* tell smbios about cpuid version and features */
+smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
 
 smbios_tables = smbios_get_table_legacy(_tables_len);
 if (smbios_tables) {
-fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
+fw_cfg_add_bytes(pcms->fw_cfg, FW_CFG_SMBIOS_ENTRIES,
  smbios_tables, smbios_tables_len);
 }
 
@@ -731,9 +735,9 @@ static void pc_build_smbios(FWCfgState *fw_cfg)
 g_free(mem_array);
 
 if (smbios_anchor) {
-fw_cfg_add_file(fw_cfg, "etc/smbios/smbios-tables",
+fw_cfg_add_file(pcms->fw_cfg, "etc/smbios/smbios-tables",
 smbios_tables, smbios_tables_len);
-fw_cfg_add_file(fw_cfg, "etc/smbios/smbios-anchor",
+fw_cfg_add_file(pcms->fw_cfg, "etc/smbios/smbios-anchor",
 smbios_anchor, smbios_anchor_len);
 }
 }
@@ -1191,9 +1195,6 @@ void pc_cpus_init(PCMachineState *pcms)
 object_unref(OBJECT(cpu));
 }
 }
-
-/* tell smbios about cpuid version and features */
-smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
 }
 
 static void pc_build_feature_control_file(PCMachineState *pcms)
@@ -1266,7 +1267,7 @@ void pc_machine_done(Notifier *notifier, void *data)
 
 acpi_setup();
 if (pcms->fw_cfg) {
-pc_build_smbios(pcms->fw_cfg);
+pc_build_smbios(pcms);
 pc_build_feature_control_file(pcms);
 /* update FW_CFG_NB_CPUS to account for -device added CPUs */
 fw_cfg_modify_i16(pcms->fw_cfg, FW_CFG_NB_CPUS, pcms->boot_cpus);
-- 
2.7.4




[Qemu-devel] [RFC 01/13] numa: access CPU's node id via property in hmp_info_numa()

2017-01-18 Thread Igor Mammedov
Move vcpu's assocciated numa_node field out of generic CPUState
into inherited classes that actually care about cpu<->numa mapping
and make monitor 'info numa' get vcpu's assocciated node id via
node-id property.
It allows to drop implicit node id intialization in
numa_post_machine_init() and would allow switching to mapping
defined by target's CpuInstanceProperties instead of global
numa_info[i].node_cpu bitmaps.

As side effect it fixes 'info numa' displaying wrong mapping
for CPUs specified with -device/device_add.
Before patch following CLI would produce:
QEMU -smp 1,sockets=3,maxcpus=3 \
   -device qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0 \
   -numa node,nodeid=0,cpus=0 \
   -numa node,nodeid=1,cpus=1 \
   -numa node,nodeid=2,cpus=2
(qemu) device_add qemu64-x86_64-cpu,socket-id=2,core-id=0,thread-id=0
(qemu) info numa
3 nodes
node 0 cpus: 0 1 2
node 0 size: 40 MB
node 1 cpus:
node 1 size: 40 MB
node 2 cpus:
node 2 size: 48 MB

after patch all CPUs are on nodes they are supposed to be:
(qemu) device_add qemu64-x86_64-cpu,socket-id=2,core-id=0,thread-id=0
(qemu) info numa
3 nodes
node 0 cpus: 0
node 0 size: 40 MB
node 1 cpus: 1
node 1 size: 40 MB
node 2 cpus: 2
node 2 size: 48 MB

Signed-off-by: Igor Mammedov 
---
CC: Dou Liyang 
CC: fanc.f...@cn.fujitsu.com
CC: caoj.f...@cn.fujitsu.com
CC: stefa...@redhat.com
CC: izumi.t...@jp.fujitsu.com
CC: vilan...@ac.upc.edu
CC: ehabk...@redhat.com
CC: peter.mayd...@linaro.org
CC: Andrew Jones 
CC: David Gibson 
CC: Thomas Huth 
---
 include/qom/cpu.h   |  2 --
 include/sysemu/numa.h   |  1 -
 target/arm/cpu.h|  2 ++
 target/i386/cpu.h   |  1 +
 target/ppc/cpu.h|  2 ++
 hw/arm/virt.c   | 12 
 hw/i386/pc.c|  5 +
 hw/ppc/spapr.c  |  2 +-
 hw/ppc/spapr_cpu_core.c |  2 +-
 monitor.c   |  7 +--
 numa.c  | 15 ---
 target/arm/cpu.c|  1 +
 target/i386/cpu.c   |  1 +
 target/ppc/translate_init.c |  1 +
 vl.c|  2 --
 15 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 3f79a8e..ae637a9 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -257,7 +257,6 @@ struct qemu_work_item;
  * @cpu_index: CPU index (informative).
  * @nr_cores: Number of cores within this CPU package.
  * @nr_threads: Number of threads within this CPU.
- * @numa_node: NUMA node this CPU is belonging to.
  * @host_tid: Host thread ID.
  * @running: #true if CPU is currently running (lockless).
  * @has_waiter: #true if a CPU is currently waiting for the cpu_exec_end;
@@ -306,7 +305,6 @@ struct CPUState {
 
 int nr_cores;
 int nr_threads;
-int numa_node;
 
 struct QemuThread *thread;
 #ifdef _WIN32
diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h
index 8f09dcf..b8015a5 100644
--- a/include/sysemu/numa.h
+++ b/include/sysemu/numa.h
@@ -25,7 +25,6 @@ typedef struct node_info {
 
 extern NodeInfo numa_info[MAX_NODES];
 void parse_numa_opts(MachineClass *mc);
-void numa_post_machine_init(void);
 void query_numa_node_mem(uint64_t node_mem[]);
 extern QemuOptsList qemu_numa_opts;
 void numa_set_mem_node_id(ram_addr_t addr, uint64_t size, uint32_t node);
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 7bd16ee..ef263f1 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -662,6 +662,8 @@ struct ARMCPU {
 
 ARMELChangeHook *el_change_hook;
 void *el_change_hook_opaque;
+
+int32_t numa_nid;
 };
 
 static inline ARMCPU *arm_env_get_cpu(CPUARMState *env)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 6c1902b..e43dcc2 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1264,6 +1264,7 @@ struct X86CPU {
 int32_t socket_id;
 int32_t core_id;
 int32_t thread_id;
+int32_t numa_nid;
 };
 
 static inline X86CPU *x86_env_get_cpu(CPUX86State *env)
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 2a50c43..2d12ad5 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1154,6 +1154,7 @@ do {\
  * @cpu_dt_id: CPU index used in the device tree. KVM uses this index too
  * @max_compat: Maximal supported logical PVR from the command line
  * @cpu_version: Current logical PVR, zero if in "raw" mode
+ * @numa_nid: Numa node id the CPU belongs to
  *
  * A PowerPC CPU.
  */
@@ -1166,6 +1167,7 @@ struct PowerPCCPU {
 int cpu_dt_id;
 uint32_t max_compat;
 uint32_t cpu_version;
+int32_t numa_nid;
 
 /* Fields related to migration compatibility hacks */
 bool pre_2_8_migration;
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 7a03f84..b86b5fd 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -329,7 +329,6 @@ static void fdt_add_cpu_nodes(const VirtMachineState *vms)
 {
 int cpu;
 

[Qemu-devel] [RFC 07/13] pc: pass apic_id to pc_find_cpu_slot() directly so lookup could be done without CPU object

2017-01-18 Thread Igor Mammedov
Signed-off-by: Igor Mammedov 
---
 hw/i386/pc.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index ed41046..f8ea635 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1776,13 +1776,12 @@ static int pc_apic_cmp(const void *a, const void *b)
  * in pcms->possible_cpus->cpus, if pcms->possible_cpus->cpus has no
  * entry correponding to CPU's apic_id returns NULL.
  */
-static CPUArchId *pc_find_cpu_slot(PCMachineState *pcms, CPUState *cpu,
+static CPUArchId *pc_find_cpu_slot(PCMachineState *pcms, uint32_t id,
int *idx)
 {
-CPUClass *cc = CPU_GET_CLASS(cpu);
 CPUArchId apic_id, *found_cpu;
 
-apic_id.arch_id = cc->get_arch_id(CPU(cpu));
+apic_id.arch_id = id;
 found_cpu = bsearch(_id, pcms->possible_cpus->cpus,
 pcms->possible_cpus->len, sizeof(*pcms->possible_cpus->cpus),
 pc_apic_cmp);
@@ -1798,6 +1797,7 @@ static void pc_cpu_plug(HotplugHandler *hotplug_dev,
 CPUArchId *found_cpu;
 HotplugHandlerClass *hhc;
 Error *local_err = NULL;
+X86CPU *cpu = X86_CPU(dev);
 PCMachineState *pcms = PC_MACHINE(hotplug_dev);
 
 if (pcms->acpi_dev) {
@@ -1817,7 +1817,7 @@ static void pc_cpu_plug(HotplugHandler *hotplug_dev,
 fw_cfg_modify_i16(pcms->fw_cfg, FW_CFG_NB_CPUS, pcms->boot_cpus);
 }
 
-found_cpu = pc_find_cpu_slot(pcms, CPU(dev), NULL);
+found_cpu = pc_find_cpu_slot(pcms, cpu->apic_id, NULL);
 found_cpu->cpu = CPU(dev);
 out:
 error_propagate(errp, local_err);
@@ -1828,9 +1828,10 @@ static void pc_cpu_unplug_request_cb(HotplugHandler 
*hotplug_dev,
 int idx = -1;
 HotplugHandlerClass *hhc;
 Error *local_err = NULL;
+X86CPU *cpu = X86_CPU(dev);
 PCMachineState *pcms = PC_MACHINE(hotplug_dev);
 
-pc_find_cpu_slot(pcms, CPU(dev), );
+pc_find_cpu_slot(pcms, cpu->apic_id, );
 assert(idx != -1);
 if (idx == 0) {
 error_setg(_err, "Boot CPU is unpluggable");
@@ -1855,6 +1856,7 @@ static void pc_cpu_unplug_cb(HotplugHandler *hotplug_dev,
 CPUArchId *found_cpu;
 HotplugHandlerClass *hhc;
 Error *local_err = NULL;
+X86CPU *cpu = X86_CPU(dev);
 PCMachineState *pcms = PC_MACHINE(hotplug_dev);
 
 hhc = HOTPLUG_HANDLER_GET_CLASS(pcms->acpi_dev);
@@ -1864,7 +1866,7 @@ static void pc_cpu_unplug_cb(HotplugHandler *hotplug_dev,
 goto out;
 }
 
-found_cpu = pc_find_cpu_slot(pcms, CPU(dev), NULL);
+found_cpu = pc_find_cpu_slot(pcms, cpu->apic_id, NULL);
 found_cpu->cpu = NULL;
 object_unparent(OBJECT(dev));
 
@@ -1922,7 +1924,7 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
 cpu->apic_id = apicid_from_topo_ids(smp_cores, smp_threads, );
 }
 
-cpu_slot = pc_find_cpu_slot(pcms, CPU(dev), );
+cpu_slot = pc_find_cpu_slot(pcms, cpu->apic_id, );
 if (!cpu_slot) {
 x86_topo_ids_from_apicid(cpu->apic_id, smp_cores, smp_threads, );
 error_setg(errp, "Invalid CPU [socket: %u, core: %u, thread: %u] with"
-- 
2.7.4




Re: [Qemu-devel] [PATCH 1/2] linux-user: fix settime old value location

2017-01-18 Thread Peter Maydell
On 18 January 2017 at 15:02, Pranith Kumar  wrote:
> From: Marc-André Lureau 
>
> old_value is the 4th argument of timer_settime(), not the 2nd.
>
> Signed-off-by: Marc-André Lureau 
> Signed-off-by: Pranith Kumar 
> ---
>  linux-user/syscall.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 7b77503f94..5bd477a71b 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -12027,7 +12027,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  target_to_host_itimerspec(_new, arg3);
>  ret = get_errno(
>timer_settime(htimer, arg2, _new, 
> _old));
> -host_to_target_itimerspec(arg2, _old);
> +host_to_target_itimerspec(arg4, _old);
>  }
>  break;
>  }
> --
> 2.11.0

I reviewed this when Marc sent it back in November,
but this resend doesn't seem to have addressed any
of that.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device

2017-01-18 Thread Ard Biesheuvel
On 18 January 2017 at 15:55, Laszlo Ersek  wrote:
> On 01/18/17 16:18, Igor Mammedov wrote:
>> On Tue, 17 Jan 2017 10:56:53 +
>> Peter Maydell  wrote:
>>
>>> On 17 January 2017 at 09:49, Andrew Jones  wrote:
 In some cases the problem we're solving with the compat guards is
 a bit hypothetical, but, IMHO, nonetheless a good practice. While
 we may be sure that AAVMF and Linux will be fine with this table
 changing under their feet, we can't be sure there aren't other
 mach-virt users that have more sensitive firmwares/OSes. An ACPI-
 sensitive OS may notice the change on its next reboot after a
 migration, and then simply refuse to continue.
>>>
>>> There's also the case where you do a VM migration midway through
>>> UEFI booting up, I think, which might cause things to go wrong
>>> if you catch it just at the wrong moment.
>> acpi blobs are migrated from source so above won't happen.
>> The time guest will see new table is fresh boot or reboot.
>>
>>>
 Now, that said, I just spoke with Igor in order to learn the x86
 practice. He says that the policy has been more lax than what I
 suggest above. Hypothetical, low-risk issues are left unguarded,
 and only when a bug is found during testing is it then managed.
 The idea is to try and reduce the amount of compat variables and
 conditions needed in the ACPI generation code, but, of course, at
 some level of risk to users expecting their versioned machine type
 to always appear the same.

 So far we've been strict with mach-virt, guarding all hypothetical
 issues. Perhaps this patch is a good example to get a discussion
 started on whether or not we should be so strict though.
>>>
>>> That said, I don't have a very strong opinion here, beyond that
>>> we should be consistent at least with x86 practice.
>> another reason why we are trying not to use strict approach with ACPI
>> tables is that it's part of firmware and we didn't version firmwares
>> so far. (i.e. dst host with newer QEMU will typically have newer
>> firmware and guest with old machine-type migrated to host with newer
>> QEMU will run new firmware on (re)boot)
>
> I haven't been aware of this argument, and I'm surprised by it, but I
> think it's valid. Regardless of our choice to ultimately compose the
> ACPI tables in QEMU, guest OSes definitely consider ACPI as part of the
> firmware. So, different ACPI content after a migration + guest reboot on
> the target host is not much different from any other firmware-level
> changes encountered on the same target host, after reboot.
>

I agree. But does that imply that this fix should be tightly coupled
to the mach-virt version, considering that the UEFI firmware you run
*inside* such a vm is not versioned either?



[Qemu-devel] [RFC 05/13] pc: move pcms->possible_cpus init out of pc_cpus_init()

2017-01-18 Thread Igor Mammedov
possible_cpus could be initialized earlier then cpu objects,
i.e. when -smp is parsed so move init code to possible_cpu_arch_ids()
interface func and do initialization on the first call.

it should help later with making -numa cpu/-smp parsing a machine state
properties.

Signed-off-by: Igor Mammedov 
---
 hw/i386/pc.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a2ab7fb..7ec5304 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1143,7 +1143,9 @@ void pc_cpus_init(PCMachineState *pcms)
 ObjectClass *oc;
 const char *typename;
 gchar **model_pieces;
+const CPUArchIdList *possible_cpus;
 MachineState *machine = MACHINE(pcms);
+MachineClass *mc = MACHINE_GET_CLASS(pcms);
 
 /* init CPUs */
 if (machine->cpu_model == NULL) {
@@ -1178,14 +1180,9 @@ void pc_cpus_init(PCMachineState *pcms)
  * This is used for FW_CFG_MAX_CPUS. See comments on bochs_bios_init().
  */
 pcms->apic_id_limit = x86_cpu_apic_id_from_index(max_cpus - 1) + 1;
-pcms->possible_cpus = g_malloc0(sizeof(CPUArchIdList) +
-sizeof(CPUArchId) * max_cpus);
-for (i = 0; i < max_cpus; i++) {
-pcms->possible_cpus->cpus[i].arch_id = x86_cpu_apic_id_from_index(i);
-pcms->possible_cpus->len++;
-if (i < smp_cpus) {
-pc_new_cpu(typename, x86_cpu_apic_id_from_index(i), _fatal);
-}
+possible_cpus = mc->possible_cpu_arch_ids(machine);
+for (i = 0; i < smp_cpus; i++) {
+pc_new_cpu(typename, possible_cpus->cpus[i].arch_id, _fatal);
 }
 }
 
@@ -2248,7 +2245,21 @@ static unsigned pc_cpu_index_to_socket_id(unsigned 
cpu_index)
 static const CPUArchIdList *pc_possible_cpu_arch_ids(MachineState *machine)
 {
 PCMachineState *pcms = PC_MACHINE(machine);
-assert(pcms->possible_cpus);
+if (!pcms->possible_cpus) {
+int i;
+CPUArchIdList *possible_cpus = g_malloc0(sizeof(CPUArchIdList) +
+ sizeof(CPUArchId) * max_cpus);
+possible_cpus->len = max_cpus;
+for (i = 0; i < max_cpus; i++) {
+possible_cpus->cpus[i].arch_id = x86_cpu_apic_id_from_index(i);
+}
+pcms->possible_cpus = possible_cpus;
+}
+/*
+ * make sure that max_cpus hasn't changed since the first use, i.e.
+ * -smp hasn't been parsed after it
+ */
+assert(pcms->possible_cpus->len == max_cpus);
 return pcms->possible_cpus;
 }
 
-- 
2.7.4




Re: [Qemu-devel] [PATCH 2/2] linux-user: fix tcg/mmap test

2017-01-18 Thread Peter Maydell
On 18 January 2017 at 15:02, Pranith Kumar  wrote:
> From: Marc-André Lureau 
>
> tests/tcg/mmap test fails with values other than default target page
> size. When creating a map beyond EOF, extra anonymous pages are added up
> to the target page boundary. Currently, this operation is performed only
> when qemu_real_host_page_size < TARGET_PAGE_SIZE, but it should be
> performed if the configured page size (qemu -p) is larger than
> qemu_real_host_page_size too.
>
> (also fixes some style issues to please checkpatch)
>
> Signed-off-by: Marc-André Lureau 
> Signed-off-by: Pranith Kumar 

This got reviewed-by with caveats from two people when
it was last sent but you have neither included the R-by
tags nor addressed the minor tweaks they asked you to
address.

thanks
-- PMM



[Qemu-devel] [RFC 00/13] numa: add '-numa cpu' option

2017-01-18 Thread Igor Mammedov

Series introduces a new CLI option to allow mapping cpus to numa
nodes using public properties [socket|core|thread]-ids instead of
internal cpu-index and moving cpu<->node mapping from global bitmaps
to PCMachineState struct.

It focuses on PC in RFC version to see if approach is suitable in general,
later we can move generic parts to common code or do a bigger non RFC
version of this series that would take care of all concerned targets
(arm-virt/spapr/pc).
Thing which I've kept PC specific but could be generalized is:
  * moving array possible_cpus to generic MachineState where
we already have possible_cpu_arch_ids(). I plan to reuse it
in virt-arm for CPU hotplug/-device cpu support and as this series
shows it also could be used for numa mapping.
Perhaps it could be used in simmilar manner for core based SPAPR
but I haven't looked it yet. So any opions on if we should move it there.

So far it only provides CLI interface to do mapping, there is no QMP
one as I haven't found a suitable place/way to update/set mapping
after machine_done for QEMU started with -S (stoppod mode) so that
mgmt could query hopluggable-cpus first, then map them to numa nodes
in runtime before actually allowing guest to run.
Any suggestions on how to make it work are welcome.

PS:
skipped travis-ci build as currently it seems to be broken.

CC: Dou Liyang 
CC: fanc.f...@cn.fujitsu.com
CC: caoj.f...@cn.fujitsu.com
CC: stefa...@redhat.com
CC: izumi.t...@jp.fujitsu.com
CC: vilan...@ac.upc.edu
CC: ehabk...@redhat.com
CC: peter.mayd...@linaro.org
CC: Andrew Jones 
CC: David Gibson 
CC: Thomas Huth 

Igor Mammedov (13):
  numa: access CPU's node id via property in hmp_info_numa()
  pc: cleanup: move smbios_set_cpuid() into pc_build_smbios()
  pc: don't return cpu pointer from pc_new_cpu() as it's not needed
anymore
  make possible_cpu_arch_ids() return const pointer
  pc: move pcms->possible_cpus init out of pc_cpus_init()
  pc: calculate topology only once when possible_cpus is initialised
  pc: pass apic_id to pc_find_cpu_slot() directly so lookup could be
done without CPU object
  pc: add writeonly 'cpu' property to PCMachine
  numa: introduce '-numa cpu' cpu option
  numa: replace cpu_index_to_socket_id() with
cpu_index_to_instance_props()
  numa: use new machine.cpu property with -numa cpus=... CLI
  pc: drop usage of legacy numa_get_node_for_cpu()
  pc: cpu: make sure that cpu.node-id matches -numa mapping

 include/hw/acpi/acpi_dev_interface.h |   2 +-
 include/hw/boards.h  |  14 ++-
 include/hw/i386/pc.h |   2 +-
 include/qom/cpu.h|   2 -
 include/sysemu/numa.h|   3 +-
 target/arm/cpu.h |   2 +
 target/i386/cpu.h|   1 +
 target/ppc/cpu.h |   2 +
 hw/acpi/cpu.c|  13 +--
 hw/acpi/cpu_hotplug.c|   4 +-
 hw/arm/virt.c|  12 +-
 hw/i386/acpi-build.c |  25 ++---
 hw/i386/pc.c | 210 +++
 hw/ppc/spapr.c   |  15 ++-
 hw/ppc/spapr_cpu_core.c  |   2 +-
 monitor.c|   7 +-
 numa.c   |  89 +++
 qapi-schema.json |   3 +-
 stubs/pc_madt_cpu_entry.c|   2 +-
 target/arm/cpu.c |   1 +
 target/i386/cpu.c|   1 +
 target/ppc/translate_init.c  |   1 +
 vl.c |   4 +-
 23 files changed, 269 insertions(+), 148 deletions(-)

-- 
2.7.4




Re: [Qemu-devel] [PATCH 05/16] io: make qio_channel_yield aware of AioContexts

2017-01-18 Thread Eric Blake
On 01/18/2017 10:43 AM, Paolo Bonzini wrote:
> By the way, v2 will have a better comment on how to use the API:
> 
> + * You can move a #QIOChannel from an #AioContext to another even if

s/from an/from one/

> + * I/O handlers are set for a coroutine.  However, #QIOChannel provides
> + * no synchronization between the calls to qio_channel_yield() and
> + * qio_channel_set_aio_context().
> + *

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] x86-KVM: Supply TSC and APIC clock rates to guest like VMWare

2017-01-18 Thread Eduardo Habkost
On Wed, Jan 18, 2017 at 05:04:27PM +0100, Phil Dennis-Jordan wrote:
> Thanks for the comments Paulo and Eduardo,
> 
> On 18 January 2017 at 16:05, Paolo Bonzini  wrote:
> >
> > > +DEFINE_PROP_BOOL("vmware-tsc-apic-clocks", X86CPU,
> > vmware_clock_rates, false),
> >
> > Maybe just vmware-cpuid-freq instead?  Whatever the choice, please make
> > the bool field in struct X86CPU consistent with the property name (e.g.
> > enable_vmware_cpuid_freq).
> >
> 
> Sounds good, I've fixed this and the page/leaf terminology mixup for the
> next patch iteration.
> 
> One issue is that the TSC frequency can change, for example on
> > migration.  Telling the guest about the TSC frequency makes little sense
> > if it can change.
> >
> 
> That makes sense. Darwin can't handle changing TSC frequencies in any case,
> regardless of cpuid leaf 0x4010. Do I deduce correctly from the
> following code (lines 967~977) that this bit inhibits migration
> intrinsically, so other than depending on it, I don't need to specifically
> disable migration for this option?
> 
> if (c && (c->edx & 1<<8) && invtsc_mig_blocker == NULL) {
> …
> vmstate_x86_cpu.unmigratable = 1;
> 
> (Likewise, it would appear that the user_tsc_khz case Eduardo suggested
> already has a migration sanity check in cpu_post_load() too.)

user_tsc_khz won't inhibit migration completely, but QEMU will
refuse to start if the host TSC frequency isn't an exact match
and the host doesn't support TSC scaling.

invtsc currently inhibits migration, but I have submitted a
series last week that will allow migration with invtsc if
user_tsc_khz is set.

There are also plans to allow very small TSC frequency mismatches
with tsc_user_khz set, so migration with tsc_user_khz can be
possible when TSC scaling is unavailable.

The discussion is at:
  Subject: [PATCH 0/4] Allow migration with invtsc if there's no frequency 
mismatch

-- 
Eduardo



Re: [Qemu-devel] [PATCH v2 1/6] Add cfgend parameter for ARM CPU selection.

2017-01-18 Thread Eduardo Habkost
On Tue, Jan 17, 2017 at 11:52:24AM +, Peter Maydell wrote:
> On 12 January 2017 at 14:28, Julian Brown  wrote:
> > On Wed, 11 Jan 2017 12:35:52 +
> > Julian Brown  wrote:
> >
> >> I'm a little confused, I think -- these changes seemed to be necessary
> >> to allow the parsing of the command-line syntax you suggested earlier
> >> (-mcpu=foo,cfgend=bar):
> >> [...]
> >> Can the existing properties be set like that via the command line?
> >
> > Aha! The answer was yes, but only currently for the "virt" board
> > (which we haven't been using for aarch32, and only supports a few recent
> > CPU types at present). I'm less confused now! (The string-splitting code
> > in arm_cpu_class_by_name is still dubious though, IMO.)
> 
> Oops, I'd forgotten there was board-specific code for handling
> cpu feature flags. I think we want to change the other boards
> to do it like the virt board does, but maybe I'm wrong.
> I've cc'd Eduardo who will hopefully know the right way to handle
> this.

I don't understand what's missing here: cpu_arm_init() already
calls cpu_generic_init(), which already calls
CPUClass::parse_features() after splitting the cpu_model string
and calling CPUClass::class_by_name().

Which board aree you using to test this? Is the board calling
cpu_arm_init() to create the CPU?

-- 
Eduardo



[Qemu-devel] [RFC 06/13] pc: calculate topology only once when possible_cpus is initialised

2017-01-18 Thread Igor Mammedov
Signed-off-by: Igor Mammedov 
---
 include/hw/boards.h |  1 +
 hw/i386/pc.c| 25 +
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index ac891a8..6364617 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -49,6 +49,7 @@ void machine_register_compat_props(MachineState *machine);
  */
 typedef struct {
 uint64_t arch_id;
+CpuInstanceProperties props;
 struct CPUState *cpu;
 } CPUArchId;
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 7ec5304..ed41046 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -2251,7 +2251,18 @@ static const CPUArchIdList 
*pc_possible_cpu_arch_ids(MachineState *machine)
  sizeof(CPUArchId) * max_cpus);
 possible_cpus->len = max_cpus;
 for (i = 0; i < max_cpus; i++) {
+X86CPUTopoInfo topo;
+CpuInstanceProperties *cpu_props = _cpus->cpus[i].props;
+
 possible_cpus->cpus[i].arch_id = x86_cpu_apic_id_from_index(i);
+x86_topo_ids_from_apicid(possible_cpus->cpus[i].arch_id,
+ smp_cores, smp_threads, );
+cpu_props->has_socket_id = true;
+cpu_props->socket_id = topo.pkg_id;
+cpu_props->has_core_id = true;
+cpu_props->core_id = topo.core_id;
+cpu_props->has_thread_id = true;
+cpu_props->thread_id = topo.smt_id;
 }
 pcms->possible_cpus = possible_cpus;
 }
@@ -2276,23 +2287,13 @@ static HotpluggableCPUList 
*pc_query_hotpluggable_cpus(MachineState *machine)
 cpu_type = object_class_get_name(OBJECT_CLASS(CPU_GET_CLASS(cpu)));
 
 for (i = 0; i < pcms->possible_cpus->len; i++) {
-X86CPUTopoInfo topo;
 HotpluggableCPUList *list_item = g_new0(typeof(*list_item), 1);
 HotpluggableCPU *cpu_item = g_new0(typeof(*cpu_item), 1);
-CpuInstanceProperties *cpu_props = g_new0(typeof(*cpu_props), 1);
-const uint32_t apic_id = pcms->possible_cpus->cpus[i].arch_id;
-
-x86_topo_ids_from_apicid(apic_id, smp_cores, smp_threads, );
 
 cpu_item->type = g_strdup(cpu_type);
 cpu_item->vcpus_count = 1;
-cpu_props->has_socket_id = true;
-cpu_props->socket_id = topo.pkg_id;
-cpu_props->has_core_id = true;
-cpu_props->core_id = topo.core_id;
-cpu_props->has_thread_id = true;
-cpu_props->thread_id = topo.smt_id;
-cpu_item->props = cpu_props;
+cpu_item->props = g_memdup(>possible_cpus->cpus[i].props,
+   sizeof(*cpu_item->props));
 
 cpu = pcms->possible_cpus->cpus[i].cpu;
 if (cpu) {
-- 
2.7.4




[Qemu-devel] SCSI HBA auto-created for -drive if=scsi

2017-01-18 Thread Markus Armbruster
Some boards automatically cold-plug SCSI HBAs to honor -drive if=scsi.
Which one depends on the machine:

pc*, realview-eb*, versatile*: lsi53c895a
spapr-machine: spapr-vscsi

Should we use something less thoroughly obsolete than lsi53c895a for new
machine types?  Something that actually has a maintainer?



Re: [Qemu-devel] [Qemu-stable] Data corruption in Qemu 2.7.1

2017-01-18 Thread Fabian Grünbichler

> Paolo Bonzini  hat am 18. Januar 2017 um 17:30 
> geschrieben:
> 
> 
> 
> 
> On 18/01/2017 17:19, Fabian Grünbichler wrote:
> > Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#109 FAILED Result: 
> > hostbyte=DID_OK driverbyte=DRIVER_SENSE
> > Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#109 Sense Key : 
> > Illegal Request [current]
> > Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#109 Add. Sense: 
> > Invalid field in cdb
> > Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#109 CDB: Write(10) 2a 
> > 00 0d d6 51 48 00 08 00 00
> > Jan 18 17:07:51 ubuntu kernel: blk_update_request: critical target error, 
> > dev sda, sector 232149320
> > Jan 18 17:07:51 ubuntu kernel: EXT4-fs warning (device sda1): 
> > ext4_end_bio:329: I/O error -121 writing to inode 125 (offset 0 size 0 
> > starting block 29018921)
> > Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical 
> > block 29018409
> > Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical 
> > block 29018410
> > Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical 
> > block 29018411
> > Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical 
> > block 29018412
> > Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical 
> > block 29018413
> > Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical 
> > block 29018414
> > Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical 
> > block 29018415
> > Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical 
> > block 29018416
> > Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical 
> > block 29018417
> > Jan 18 17:07:51 ubuntu kernel: Buffer I/O error on device sda1, logical 
> > block 29018418
> > Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#106 FAILED Result: 
> > hostbyte=DID_OK driverbyte=DRIVER_SENSE
> > Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#106 Sense Key : 
> > Illegal Request [current]
> > Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#106 Add. Sense: 
> > Invalid field in cdb
> > Jan 18 17:07:51 ubuntu kernel: sd 2:0:0:0: [sda] tag#106 CDB: Write(10) 2a 
> > 00 0d d6 59 48 00 08 00 00
> > Jan 18 17:07:51 ubuntu kernel: blk_update_request: critical target error, 
> > dev sda, sector 232151368
> > Jan 18 17:07:51 ubuntu kernel: EXT4-fs warning (device sda1): 
> > ext4_end_bio:329: I/O error -121 writing to inode 125 (offset 0 size 0 
> > starting block 29019177)
> > Jan 18 17:07:52 ubuntu kernel: JBD2: Detected IO errors while flushing file 
> > data on sda1-8
> > Jan 18 17:07:58 ubuntu kernel: JBD2: Detected IO errors while flushing file 
> > data on sda1-8
> > 
> > 
> > strace (with some random grep-ing):
> > [pid  1794] ioctl(19, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[10]=[2a, 00, 0d, 
> > d6, 51, 48, 00, 08, 00, 00], mx_sb_len=252, iovec_count=17, 
> > dxfer_len=1048576, timeout=4294967295, flags=0x1, 
> > data[1048576]=["\0`\235=c\177\0\0\0\0\1\0\0\0\0\0\0`\236=c\177\0\0\0\0\1\0\0\0\0\0"...]})
> >  = -1 EINVAL (Invalid argument)
> > [pid  1794] ioctl(19, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[10]=[2a, 00, 0d, 
> > d6, 59, 48, 00, 08, 00, 00], mx_sb_len=252, iovec_count=16, 
> > dxfer_len=1048576, timeout=4294967295, flags=0x1, 
> > data[1048576]=["\0`-=c\177\0\0\0\0\1\0\0\0\0\0\0`.=c\177\0\0\0\0\1\0\0\0\0\0"...]})
> >  = -1 EINVAL (Invalid argument)
> 
> This is useful, thanks.  I suspect blk_rq_map_user_iov is failing,
> meaning that the scatter/gather list has too many segments for the HBA
> in the host.  (The limit can be found in /sys/block/sda/queue/max_segments).

I can try to get some more info tomorrow..

> 
> This is consistent with your finding here:
> 
> > disabling THP on the hypervisor host with
> > 
> > # echo 'never' > /sys/kernel/mm/transparent_hugepage/enabled
> > 
> > allows reproducing the bug very reliably, shutting the VM down, then
> > enabling THP (with 'always') and trying again makes it go away.
> 
> because no THP means more memory fragmentation and thus more segments.
> 
> I'm not sure how to fix it, unfortunately. :(

Well at least this means we have a (potentially too conservative) check for 
deciding when to use scsi-disk instead of scsi-block (maybe this could be 
detected in qemu as well?).

Seems especially troublesome since the (hypervisor) admin can change it at 
runtime, and it seems like there are widespread recommendations to disable THP 
for e.g., DB use cases..

> 
> Paolo
>




Re: [Qemu-devel] [PATCH 0/3] cpu: numa: Fix the mapping initialization of VCPUs and NUMA nodes

2017-01-18 Thread Eduardo Habkost
On Wed, Jan 18, 2017 at 09:26:36PM +0800, Dou Liyang wrote:
> Hi, All
> 
> > **
> > ERROR:/tmp/qemu-test/src/tests/vhost-user-test.c:668:test_migrate: 
> > assertion failed: (qdict_haskey(rsp, "return"))
> > GTester: last random seed: R02Sf52546c4daff8087416f43fa7c146db8
> > ftruncate: Permission denied
> > ftruncate: Permission denied
> > qemu-system-aarch64: /tmp/qemu-test/src/qom/cpu.c:346: 
> > cpu_common_map_numa_node: Assertion `cpu->cpu_index < max_cpus' failed.
> > Broken pipe
> 
> I don't know What's the meaning of this log ?
> 
> Is the qemu-system-aarch64 can't recognize the
> qom/cpu.c:346: assert(cpu->cpu_index < max_cpus);

This means the assert() line is being triggered for some reason,
and cpu_index is >= max_cpus when we cpu_common_map_numa_node()
gets called. We need to investigate why.

-- 
Eduardo



Re: [Qemu-devel] [PATCH] numa: access CPU's node id via property in hmp_info_numa()

2017-01-18 Thread Eduardo Habkost
On Wed, Jan 18, 2017 at 06:08:24PM +0100, Igor Mammedov wrote:
> On Wed, 18 Jan 2017 13:19:45 -0200
> Eduardo Habkost  wrote:
> 
> > On Wed, Jan 18, 2017 at 03:48:45PM +0100, Igor Mammedov wrote:
> > > Move vcpu's assocciated numa_node field out of generic CPUState
> > > into inherited classes that actually care about cpu<->numa mapping
> > > and make monitor 'info numa' get vcpu's assocciated node id via
> > > node-id property.
> > > It allows to drop implicit node id intialization in
> > > numa_post_machine_init() and would allow switching to mapping
> > > defined by target's CpuInstanceProperties instead of global
> > > numa_info[i].node_cpu bitmaps.  
> > 
> > I agree to allow the node-id assignment logic to be defined by
> > arch-specific code, but:
> > 
> > Considering that we still have the generic CPU<->node mapping in
> > numa_info[].node_cpu, I don't see the benefit of moving the
> > numa_info[].node_cpu => node-id translation from common generic
> > code to duplicated arch-specific code.
> it's duplicated for a time being until all targets that use
> node_cpu are internally converted to socket/core/thread-id interface.
> This patch is a part if re-factoring RFC which I'm about to post.
> 
> 

Maybe the duplication will be OK if it's temporary, and going to
be removed immediately by the same series. But if it is a
standalone patch, I don't want to make the existing duplication
worse.

> > What about adding this to cpu_generic_realize():
> > 
> >   node = (numa_get_node_for_cpu(cpu)
> >   if (node >= 0) {
> >  int cur_node = object_property_find(cpu, "node-id") ?
> > object_property_get_int(cpu, "node-id") : -1;
> >  if (cur_node >= 0 && cur_node != node) {
> >  error_setg(, "Conflict between -numa option and CPU node-id");
> >  goto out;
> >  }
> >  object_property_set_int(cpu, "node-id", node, );
> >   }
> What I don't like here is that putting above snippet into
> cpu_generic_realize() is just doing the same implicit init
> that numa_post_machine_init() has been doing before just
> a bit later. It looks like a quick fix for 'info numa' issues.

Yes, it is. But I still don't see what's the problem with it. If
numa_info[].node_cpu still exists in generic code, I don't see
why not handle it in generic code.

> 
> However it would add stumble block on getting rid of 
> numa_get_node_for_cpu() { numa_info[].node_cpu } and keeping
> node-mapping along with the rest of topology in Machine object
> instead of globals.

Removing duplication would make it easier: then you'll have only
one user of numa_info[].node_cpu/numa_get_node_for_cpu() to get
rid of, instead of 4.

> 
> I'm in process of getting rid of numa_info[].node_cpu/numa_get_node_for_cpu()
> altogether. And incrementally done it for PC, so I'd be forced
> to reduplicate above snippet from cpu_generic_realize() in concrete
> users anyway to do conversion without breaking other users.

If you manage to get rid of numa_info[].node_cpu somehow, then we
could get rid of numa_post_machine_init()/numa_get_node_for_cpu()
at the same time. But I don't see the benefit of duplicating
existing generic code into arch-specific code while keeping the
existing generic numa_info[].node_cpu data structure untouched.

>  
> [...]
> > > --- a/hw/i386/pc.c
> > > +++ b/hw/i386/pc.c
> > > @@ -1978,6 +1978,11 @@ static void pc_cpu_pre_plug(HotplugHandler 
> > > *hotplug_dev,
> > >  
> > >  cs = CPU(cpu);
> > >  cs->cpu_index = idx;
> > > +
> > > +idx = numa_get_node_for_cpu(cs->cpu_index);
> > > +if (idx < nb_numa_nodes) {
> > > +cpu->numa_nid = idx;
> > > +}
> this is the only place where I add above mentioned duplication,
> which sort of compensated by removed numa_post_machine_init().

Is it? I see the same logic duplicated in 3 places (see below).
Not all cases were added by you, but that doesn't mean it is OK
to make it worse.

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f721fde..9d2b265 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1978,6 +1978,11 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
 
 cs = CPU(cpu);
 cs->cpu_index = idx;
+
+idx = numa_get_node_for_cpu(cs->cpu_index);
+if (idx < nb_numa_nodes) {
+cpu->numa_nid = idx;
+}
diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index c18632b..7f6661b 100644
--- a/hw/ppc/spapr_cpu_core.c
+++ b/hw/ppc/spapr_cpu_core.c
@@ -71,7 +71,7 @@ void spapr_cpu_init(sPAPRMachineState *spapr, PowerPCCPU 
*cpu, Error **errp)
 /* Set NUMA node for the added CPUs  */
 i = numa_get_node_for_cpu(cs->cpu_index);
 if (i < nb_numa_nodes) {
-cs->numa_node = i;
+cpu->numa_nid = i;
 }
 
 xics_cpu_setup(spapr->xics, cpu);
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 7a03f84..b86b5fd 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1333,6 +1332,11 @@ static void machvirt_init(MachineState *machine)
 

Re: [Qemu-devel] [libvirt] [PATCH 0/9] i386: query-cpu-model-expansion test script

2017-01-18 Thread Eduardo Habkost
On Wed, Jan 18, 2017 at 12:09:28PM -0500, Jason J. Herne wrote:
> On 01/18/2017 12:00 PM, Eduardo Habkost wrote:
> > On Tue, Jan 17, 2017 at 10:22:10AM -0500, Jason J. Herne wrote:
> > > On 01/16/2017 08:01 PM, Eduardo Habkost wrote:
> > > > This is a follow-up to the series that implements
> > > > query-cpu-model-expansion. Before including the test script, the
> > > > series has some fixes to allow the results of
> > > > query-cpu-model-expansion to be used in the QEMU command-line.
> > > > 
> > > > The script probably will work on s390x too, but I couldn't test
> > > > it yet.
> > > > 
> > > 
> > > Eduardo,
> > > 
> > > This test seems to mostly work on s390. The only issue I ran into is
> > > querying host model using tcg only. s390 requires kvm to query the host
> > > model. Perhaps we could just skip the tcg host test case on s390?
> > 
> > We could still try to test "host", but add it to a greylist where
> > errors returned by query-cpu-model-expansion can be non-fatal.
> > query-cpu-model-expansion model="host" can also fail with KVM if
> > the host doesn't support CPU models.
> > 
> 
> David had the idea to just support -cpu host for tcg. We could do that.
> In the meantime, I'm ok with your greylist idea too. This would allow the
> script to work properly on s390 right from the start, and we can remove the
> greylist when s390 supports specifying -cpu host for tcg.

I believe we will still need to ignore query-cpu-model-expansion
errors on some cases, otherwise the test script will fail on
hosts where KVM doesn't support CPU models in KVM.

But we probably don't need a hardcoded greylist, anyway: we could
just make the error non-fatal in case the CPU model is not
reported as migration-safe in query-cpu-definitions.

But I was wondering:

1) Isn't "-cpu host" the default CPU model on s390x on KVM,
   even if the host doesn't support CPU models?

2) Is it really correct to return an error on
   "query-cpu-model-expansion model=host type=full" if the host
   doesn't support CPU models?

   What if it just returned { name: "host", props: {} }
   on those cases, meaning that the CPU model is valid and
   usable, but QEMU is unable to provide extra information about
   it.

-- 
Eduardo



Re: [Qemu-devel] [RFC 09/13] numa: introduce '-numa cpu' cpu option

2017-01-18 Thread Eric Blake
On 01/18/2017 11:13 AM, Igor Mammedov wrote:
> It allows to specify mapping of a CPU to NUMA node on CLI.
> Option should be repeated for each present/possible CPU.
> Example for PC machine:
>   -numa node,nodeid=0 -numa node,nodeid=1 \
>   -numa cpu,socket-id=0,core-id=0,thread-id=0,node-id=0 \
>   -numa cpu,socket-id=1,core-id=0,thread-id=0,node-id=1
> 
> Signed-off-by: Igor Mammedov 
> ---

> +++ b/qapi-schema.json
> @@ -5543,7 +5543,8 @@
>  ##
>  { 'union': 'NumaOptions',
>'data': {
> -'node': 'NumaNodeOptions' }}
> +'node': 'NumaNodeOptions',
> +'cpu': 'CpuInstanceProperties' }}

Missing a documentation blurb that includes a '(since 2.9)' tag.


-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [RFC 11/13] numa: use new machine.cpu property with -numa cpus=... CLI

2017-01-18 Thread Eduardo Habkost
On Wed, Jan 18, 2017 at 06:13:27PM +0100, Igor Mammedov wrote:
> add compat layer to legacy cpu_index based '-numa cpus=...'
> CLI option, which will use new machine.cpu property to set
> numa mapping if that propety is available.
> 
> This way machine that supports machine.cpu property will
> not break legacy CLI but will be able to move away from
> using numa_info[node_id].node_cpu bitmaps and use only
> possible_cpus instead.
> 
> Signed-off-by: Igor Mammedov 
> ---
>  numa.c | 63 ---
>  1 file changed, 48 insertions(+), 15 deletions(-)
> 
> diff --git a/numa.c b/numa.c
> index 887ee58..0c34130 100644
> --- a/numa.c
> +++ b/numa.c
> @@ -141,10 +141,35 @@ uint32_t numa_get_node(ram_addr_t addr, Error **errp)
>  return -1;
>  }
>  
> -static void numa_node_parse(NumaNodeOptions *node, QemuOpts *opts, Error 
> **errp)
> +static void numa_cpu_set_nid(MachineState *ms, CpuInstanceProperties *props,
> + Error **errp)
> +{
> +Visitor *v;
> +QObject *qobj;
> +Error *local_error = NULL;
> +
> +v = qobject_output_visitor_new();
> +visit_type_CpuInstanceProperties(v, "cpu", , _error);
> +visit_complete(v, );
> +visit_free(v);
> +if (local_error) {
> +goto end;
> +}
> +v = qobject_input_visitor_new(qobj, true);
> +object_property_set(OBJECT(ms), v, "cpu", _error);
> +visit_free(v);
> +qobject_decref(qobj);
> +end:
> +error_propagate(errp, local_error);
> +}
> +
> +static void numa_node_parse(MachineState *ms, NumaNodeOptions *node,
> +QemuOpts *opts, Error **errp)
>  {
>  uint16_t nodenr;
>  uint16List *cpus = NULL;
> +MachineClass *mc = MACHINE_GET_CLASS(ms);
> +bool has_cpu_prop = object_property_find(OBJECT(ms), "cpu", NULL);
>  
>  if (node->has_nodeid) {
>  nodenr = node->nodeid;
> @@ -172,6 +197,19 @@ static void numa_node_parse(NumaNodeOptions *node, 
> QemuOpts *opts, Error **errp)
>  return;
>  }
>  bitmap_set(numa_info[nodenr].node_cpu, cpus->value, 1);
> +if (mc->cpu_index_to_instance_props && has_cpu_prop) {
> +CpuInstanceProperties props;
> +Error *local_error = NULL;
> +
> +props = mc->cpu_index_to_instance_props(ms, cpus->value);
> +props.has_node_id = true;
> +props.node_id = nodenr;
> +numa_cpu_set_nid(ms, , _error);
> +if (local_error) {
> +error_propagate(errp, local_error);
> +return;
> +}
> +}
>  }

With this, now we have two completely different ways to store the
results of "-numa node,cpus...", and both are likely to stay
forever if we take too long to update the other machines.

Do you plan to make ppc/spapr and arm/virt use the new
machine.cpu system so we could remove numa_info[].node_cpu
completely in the same series?

-- 
Eduardo



Re: [Qemu-devel] [PATCH RFC] acpi: add reset register to fadt

2017-01-18 Thread Igor Mammedov
On Wed, 18 Jan 2017 18:30:59 +0200
"Michael S. Tsirkin"  wrote:

> On Wed, Jan 18, 2017 at 12:45:54PM +0100, Phil Dennis-Jordan wrote:
[...]

> > I suspect more might be involved in enabling ACPI 2.0, and it should 
> > probably be an option so as to avoid regressions. I don't know what the 
> > best approach would be for this, so comments welcome. Should adding the 
> > reset register to the FADT also be configurable?  
> 
> I would say an option to make FADT use rev 3 format would be a good
> idea.
> 
> I'd make it the default if XP survives.
if XP and legacy linux survive,
I'd skip adding option as probably there won't be any users,
in unlikely case such user surfaces we always can add option later
but we can't do it other way around (i.e. take it away).



Re: [Qemu-devel] [PATCH 0/9] i386: query-cpu-model-expansion test script

2017-01-18 Thread Eduardo Habkost
On Tue, Jan 17, 2017 at 10:22:10AM -0500, Jason J. Herne wrote:
> On 01/16/2017 08:01 PM, Eduardo Habkost wrote:
> > This is a follow-up to the series that implements
> > query-cpu-model-expansion. Before including the test script, the
> > series has some fixes to allow the results of
> > query-cpu-model-expansion to be used in the QEMU command-line.
> > 
> > The script probably will work on s390x too, but I couldn't test
> > it yet.
> > 
> 
> Eduardo,
> 
> This test seems to mostly work on s390. The only issue I ran into is
> querying host model using tcg only. s390 requires kvm to query the host
> model. Perhaps we could just skip the tcg host test case on s390?

We could still try to test "host", but add it to a greylist where
errors returned by query-cpu-model-expansion can be non-fatal.
query-cpu-model-expansion model="host" can also fail with KVM if
the host doesn't support CPU models.

> 
> 
> hernejj: ['/usr/local/bin/qemu-system-s390x', '-chardev',
> 'socket,id=mon,path=/var/tmp/qom-fetch-monitor.sock', '-mon',
> 'chardev=mon,mode=control', '-display', 'none', '-vga', 'none', '-qtest',
> 'unix:path=/var/tmp/qom-fetch-qtest.sock', '-qtest-log', '/dev/null',
> '-machine', 'accel=qtest', '-machine', 'accel=tcg', '-S', '-cpu', 'host']
> qemu-system-s390x: CPU definition requires KVM
> E
> ==
> ERROR: testTCGModels (__main__.CPUModelTest)
> --
> Traceback (most recent call last):
>   File "./query-cpu-model-test.py", line 380, in testTCGModels
> self.checkAllCPUModels()
>   File "./query-cpu-model-test.py", line 375, in checkAllCPUModels
> self.checkOneCPUModel(m)
>   File "./query-cpu-model-test.py", line 304, in checkOneCPUModel
> self.checkExpansions(model, msg)
>   File "./query-cpu-model-test.py", line 221, in checkExpansions
> '%s.static' % (msg))
>   File "./query-cpu-model-test.py", line 177, in checkOneExpansion
> type=type, model=model['model'])
>   File "./../scripts/qemu.py", line 185, in command
> raise Exception(reply["error"]["desc"])
> Exception: The CPU definition 'host' requires KVM
> 
> --
> Ran 2 tests in 74.622s
> 
> 
> -- 
> -- Jason J. Herne (jjhe...@linux.vnet.ibm.com)
> 

-- 
Eduardo



[Qemu-devel] [RFC 12/13] pc: drop usage of legacy numa_get_node_for_cpu()

2017-01-18 Thread Igor Mammedov
Replace usage of legacy cpu_index based node_cpu bitmaps
with PCMachineState.possible_cpus which have node-ids for
all possible CPUs.

As result:
 * -1 usage of global max_cpus
 * considering not set CPUArchId.props.node_id is 0
   drop not needed (numa_get_node_for_cpu(i) < nb_numa_nodes) checks,
   for the case where not all CPUs have been mapped to a numa,
   as it will have the same effect
 * -5 usage of global nb_numa_nodes

Signed-off-by: Igor Mammedov 
---
 hw/acpi/cpu.c|  7 +++
 hw/i386/acpi-build.c | 17 ++---
 hw/i386/pc.c | 19 ++-
 3 files changed, 15 insertions(+), 28 deletions(-)

diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
index 6017ca0..ac63cb9 100644
--- a/hw/acpi/cpu.c
+++ b/hw/acpi/cpu.c
@@ -503,7 +503,6 @@ void build_cpus_aml(Aml *table, MachineState *machine, 
CPUHotplugFeatures opts,
 
 /* build Processor object for each processor */
 for (i = 0; i < arch_ids->len; i++) {
-int j;
 Aml *dev;
 Aml *uid = aml_int(i);
 GArray *madt_buf = g_array_new(0, 1, 1);
@@ -557,9 +556,9 @@ void build_cpus_aml(Aml *table, MachineState *machine, 
CPUHotplugFeatures opts,
  * as a result _PXM is required for all CPUs which might
  * be hot-plugged. For simplicity, add it for all CPUs.
  */
-j = numa_get_node_for_cpu(i);
-if (j < nb_numa_nodes) {
-aml_append(dev, aml_name_decl("_PXM", aml_int(j)));
+if (arch_ids->cpus[i].props.has_node_id) {
+aml_append(dev, aml_name_decl("_PXM",
+aml_int(arch_ids->cpus[i].props.node_id)));
 }
 
 aml_append(cpus_dev, dev);
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 0c91043..d0dc8d9 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2305,19 +2305,16 @@ build_srat(GArray *table_data, BIOSLinker *linker, 
MachineState *machine)
 srat->reserved1 = cpu_to_le32(1);
 
 for (i = 0; i < apic_ids->len; i++) {
-int j = numa_get_node_for_cpu(i);
-uint32_t apic_id = apic_ids->cpus[i].arch_id;
+const CPUArchId *cpu = _ids->cpus[i];
 
-if (apic_id < 255) {
+if (cpu->arch_id < 255) {
 AcpiSratProcessorAffinity *core;
 
 core = acpi_data_push(table_data, sizeof *core);
 core->type = ACPI_SRAT_PROCESSOR_APIC;
 core->length = sizeof(*core);
-core->local_apic_id = apic_id;
-if (j < nb_numa_nodes) {
-core->proximity_lo = j;
-}
+core->local_apic_id = cpu->arch_id;
+core->proximity_lo = cpu->props.node_id;
 memset(core->proximity_hi, 0, 3);
 core->local_sapic_eid = 0;
 core->flags = cpu_to_le32(1);
@@ -2327,10 +2324,8 @@ build_srat(GArray *table_data, BIOSLinker *linker, 
MachineState *machine)
 core = acpi_data_push(table_data, sizeof *core);
 core->type = ACPI_SRAT_PROCESSOR_x2APIC;
 core->length = sizeof(*core);
-core->x2apic_id = cpu_to_le32(apic_id);
-if (j < nb_numa_nodes) {
-core->proximity_domain = cpu_to_le32(j);
-}
+core->x2apic_id = cpu_to_le32(cpu->arch_id);
+core->proximity_domain = cpu_to_le32(cpu->props.node_id);
 core->flags = cpu_to_le32(1);
 }
 }
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 5066339..e2833e0 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -746,7 +746,7 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
PCMachineState *pcms)
 {
 FWCfgState *fw_cfg;
 uint64_t *numa_fw_cfg;
-int i, j;
+int i;
 
 fw_cfg = fw_cfg_init_io_dma(FW_CFG_IO_BASE, FW_CFG_IO_BASE + 4, as);
 fw_cfg_add_i16(fw_cfg, FW_CFG_NB_CPUS, pcms->boot_cpus);
@@ -781,13 +781,10 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
PCMachineState *pcms)
  */
 numa_fw_cfg = g_new0(uint64_t, 1 + pcms->apic_id_limit + nb_numa_nodes);
 numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes);
-for (i = 0; i < max_cpus; i++) {
-unsigned int apic_id = x86_cpu_apic_id_from_index(i);
-assert(apic_id < pcms->apic_id_limit);
-j = numa_get_node_for_cpu(i);
-if (j < nb_numa_nodes) {
-numa_fw_cfg[apic_id + 1] = cpu_to_le64(j);
-}
+for (i = 0; i < pcms->possible_cpus->len; i++) {
+const CPUArchId *cpu = >possible_cpus->cpus[i];
+assert(cpu->arch_id < pcms->apic_id_limit);
+numa_fw_cfg[cpu->arch_id + 1] = cpu_to_le64(cpu->props.node_id);
 }
 for (i = 0; i < nb_numa_nodes; i++) {
 numa_fw_cfg[pcms->apic_id_limit + 1 + i] =
@@ -1970,11 +1967,7 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
 
 cs = CPU(cpu);
 cs->cpu_index = idx;
-
-idx = numa_get_node_for_cpu(cs->cpu_index);
-if (idx < nb_numa_nodes) {
-

Re: [Qemu-devel] [virtio-dev] RE: [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification

2017-01-18 Thread Halil Pasic


On 01/17/2017 03:49 AM, Gonglei (Arei) wrote:
> Hi Halil,
> 
>>
>> On 01/16/2017 01:43 PM, Gonglei (Arei) wrote:
>>> Hi Michael and others,
>>>
>>> I'd like to redefine struct virtio_crypto_op_data_req is as below:
>>>
>>> struct virtio_crypto_op_data_req {
>>> struct virtio_crypto_op_header header;
>>>
>>> union {
>>> struct virtio_crypto_sym_data_req   sym_req;
>>> struct virtio_crypto_hash_data_req  hash_req;
>>> struct virtio_crypto_mac_data_req   mac_req;
>>> struct virtio_crypto_aead_data_req  aead_req;
>>> struct virtio_crypto_sym_data_req_non_sess
>> sym_non_sess_req;
>>> struct virtio_crypto_hash_data_req_non_sess
>> hash_non_sess_req;
>>> struct virtio_crypto_mac_data_req_non_sess
>> mac_non_sess_req;
>>> struct virtio_crypto_aead_data_req_non_sess
>> aead_non_sess_req;
>>> __u8 padding[72];
>>> } u;
>>> };
>>>
>>> The length of union in the structure will be changed, which from current 48
>> byte to 72 byte.

Quoting seems broken :(

>>>
>>> We couldn't redefine a structure named
>> virtio_crypto_op_data_req_non_sess,
>>> Because the feature bits are for crypto services, not for the wrapper packet
>> request.
>>>
>>
>> You mean virtio_crypto_op_data_req.virtio_crypto_op_header.flags
>> are conceptually meant for something else and using that field woulb
>> be misuse?
>>
> Nope...
>>

I'm having huge difficulties following you. Please tell me what was
the intended meaning of the sentence I commented! About which
flags are you talking?

>>> It's impossible to mixed use struct virtio_crypto_op_data_req and
>>> struct named virtio_crypto_op_data_req_non_sess for one data virtqueue.
>>>
>>
>> I do not understand what are you trying to say here. I think you
>> should tell us what is the new feature and how it is guarded.
>>
>> Would this mean that session or non-session mode will be tied
>> to the whole device, or to one data-queue. If it's data-queue
>> level how is it controlled (e.g. control queue)?
>>
> ... I'm so sorry for confusing explanation. Let me try to explain it more 
> clear.

Which explanation? Now I see three ideas as a more clear explanation
where I figured we are discussing one idea.

> 
> 1 ) The first idea: For support non-session mode crypto operations, I 
> introduce 4 feature bits
> for different crypto services, they are:
> 
> VIRTIO_CRYPTO_F_CIPHER_NON_SESSION_MODE (1) non-session mode is available for 
> CIPHER service.
> VIRTIO_CRYPTO_F_HASH_NON_SESSION_MODE (2) non-session mode is available for 
> HASH service.
> VIRTIO_CRYPTO_F_MAC_NON_SESSION_MODE (3) non-session mode is available for 
> MAC service.
> VIRTIO_CRYPTO_F_AEAD_NON_SESSION_MODE (4) non-session mode is available for 
> AEAD service.
> 
> but not only one feature bit, something like:
> 
> VIRTIO_CRYPTO_F_ NON_SESSION_MODE (1) non-session mode is available.
> 
> Meanwhile, I define 4 new non-session mode structures for different crypto
> services in order to keep compatibility to pre-existing driver.
> 
> -*Advantages*:
> 
> a) We can support different modes for different crypto services
> according to which features are negotiated.
> 
> b) The driver can still use the session mode when 
> VIRTIO_CRYPTO_F_*_NON_SESSION_MODE are negotiated,
> which is under control by 
> virtio_crypto_op_data_req.virtio_crypto_op_header.flags.
> 
> - *Disadvantages*:
> 
> The current crypto packets of all
> crypto services (CIPHER, HASH, MAC and AEAD) are wrapped in structure
> virtio_crypto_op_data_req by an union in the data plane.
> 
> It will change the length of the union and break the pre-existing code
> if still lay all non-session mode structures in strut 
> virtio_crypto_op_data_req
> like this:
> 
> struct virtio_crypto_op_data_req {
> struct virtio_crypto_op_header header;
> 
> union {
> struct virtio_crypto_sym_data_req   sym_req;
> struct virtio_crypto_hash_data_req  hash_req;
> struct virtio_crypto_mac_data_req   mac_req;
> struct virtio_crypto_aead_data_req  aead_req;
> struct virtio_crypto_sym_data_req_non_sess   sym_non_sess_req;
> struct virtio_crypto_hash_data_req_non_sess  hash_non_sess_req;
> struct virtio_crypto_mac_data_req_non_sess   mac_non_sess_req;
> struct virtio_crypto_aead_data_req_non_sess  aead_non_sess_req;
>   __u8 padding[72];
> } u;
> };

Yeah if you say a request has to look like this regardless
of negotiated features, then you render the currently upstream
code non-conform. That's pretty much a decisive disadvantage!

> 
> So I should submit patches to fix them.

And IMHO you can not fix that with patches because it's already
released -- and you would have to travel back in time to fix
it in time.

> 
> 2) Another idea is define a non-session mode structure for strut 
> virtio_crypto_op_data_req.
> 
> struct virtio_crypto_op_data_req_non_sess {
> struct virtio_crypto_op_header header;
> 
> union {
> 

Re: [Qemu-devel] SCSI HBA auto-created for -drive if=scsi

2017-01-18 Thread Paolo Bonzini


On 18/01/2017 18:15, Markus Armbruster wrote:
> Some boards automatically cold-plug SCSI HBAs to honor -drive if=scsi.
> Which one depends on the machine:
> 
> pc*, realview-eb*, versatile*: lsi53c895a
> spapr-machine: spapr-vscsi
> 
> Should we use something less thoroughly obsolete than lsi53c895a for new
> machine types?  Something that actually has a maintainer?

Or just raise an error?...

Paolo



[Qemu-devel] [Bug 1657538] [NEW] qemu 2.7.x 2.8 softmmu dont work on BE machine

2017-01-18 Thread luigiburdo
Public bug reported:

Build on Be machine qemu 2.7.1 and 2.8 in pure softmmu (tgc) dont work on big 
endian hardware .
tested with ppc-softmmu,i386-softmmu,arm-softmmu same result:

with :
 ./qemu-system-i386 
Gtk-Message: Failed to load module "overlay-scrollbar"
qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it 
crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb 
QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a 
ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line and that 
you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with 
the -d debug options; in particular -d guest_errors will cause the log to 
include a dump of the guest register state at this point.

Execution cannot continue; stopping here.


I try to add the -L option with ../pc-bios/bios.bin 
and have the same result.

note the ppc-softmmu and ppc64-softmmu work in kvm mode only emulated
mode have issue.


tested on my hardware a  Qriq P5040 and G5 4x970MP with Ubuntu Mate 16.10 
thanks
Luigi

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1657538

Title:
  qemu 2.7.x 2.8 softmmu dont work on BE machine

Status in QEMU:
  New

Bug description:
  Build on Be machine qemu 2.7.1 and 2.8 in pure softmmu (tgc) dont work on big 
endian hardware .
  tested with ppc-softmmu,i386-softmmu,arm-softmmu same result:

  with :
   ./qemu-system-i386 
  Gtk-Message: Failed to load module "overlay-scrollbar"
  qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a
  This usually means one of the following happened:

  (1) You told QEMU to execute a kernel for the wrong machine type, and it 
crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb 
QEMU machine)
  (2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed 
a ROM full of no-op instructions until it fell off the end
  (3) Your guest kernel has a bug and crashed by jumping off into nowhere

  This is almost always one of the first two, so check your command line and 
that you are using the right type of kernel for this machine.
  If you think option (3) is likely then you can try debugging your guest with 
the -d debug options; in particular -d guest_errors will cause the log to 
include a dump of the guest register state at this point.

  Execution cannot continue; stopping here.

  
  I try to add the -L option with ../pc-bios/bios.bin 
  and have the same result.

  note the ppc-softmmu and ppc64-softmmu work in kvm mode only emulated
  mode have issue.

  
  tested on my hardware a  Qriq P5040 and G5 4x970MP with Ubuntu Mate 16.10 
  thanks
  Luigi

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1657538/+subscriptions



Re: [Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM

2017-01-18 Thread Alistair Francis
On Wed, Jan 18, 2017 at 4:44 AM, Thomas Huth  wrote:
> Sometimes it is useful to have just a machine with CPU and RAM, without
> any further hardware in it, e.g. if you just want to do some instruction
> debugging for TCG with a remote GDB attached to QEMU, or run some embedded
> code with the "-semihosting" QEMU parameter. qemu-system-m68k already
> features a "dummy" machine, and xtensa a "sim" machine for exactly this
> purpose.
> All target architectures have nowadays also a "none" machine, which would
> be a perfect match for this, too - but it currently does not allow to add
> CPU and RAM yet. Thus let's add these possibilities in a generic way to the
> "none" machine, too, so that we hopefully do not need additional "dummy"
> machines in the future anymore (and maybe can also get rid of the already
> existing "dummy"/"sim" machines one day).
> Note that the default behaviour of the "none" machine is not changed, i.e.
> no CPU and no RAM is instantiated by default. You have explicitely got to
> specify the CPU model with "-cpu" and the amount of RAM with "-m" to get
> these new features.
>
> Signed-off-by: Thomas Huth 
> ---
>  v3:
>  - Get rid of the cpu_init_def() wrapper again, make null-machine.o
>target dependent instead and use cpu_init() directly.
>  - Omit the loader code for the "-kernel" option for now (users can
>use "-device loader,..." instead). We can add code for the -kernel
>parameter later (either an implementation or a warning), once we've
>decided how it should behave for the "none" machine.

I think there should at least be a warning to start with though. It
seems confusing that no errors are reported but the argument is
ignored.

Thanks,

Alistair

>
>  hw/core/Makefile.objs  |  2 +-
>  hw/core/null-machine.c | 27 +--
>  2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
> index a4c94e5..0b6c0f1 100644
> --- a/hw/core/Makefile.objs
> +++ b/hw/core/Makefile.objs
> @@ -12,7 +12,6 @@ common-obj-$(CONFIG_XILINX_AXI) += stream.o
>  common-obj-$(CONFIG_PTIMER) += ptimer.o
>  common-obj-$(CONFIG_SOFTMMU) += sysbus.o
>  common-obj-$(CONFIG_SOFTMMU) += machine.o
> -common-obj-$(CONFIG_SOFTMMU) += null-machine.o
>  common-obj-$(CONFIG_SOFTMMU) += loader.o
>  common-obj-$(CONFIG_SOFTMMU) += qdev-properties-system.o
>  common-obj-$(CONFIG_SOFTMMU) += register.o
> @@ -20,3 +19,4 @@ common-obj-$(CONFIG_SOFTMMU) += or-irq.o
>  common-obj-$(CONFIG_PLATFORM_BUS) += platform-bus.o
>
>  obj-$(CONFIG_SOFTMMU) += generic-loader.o
> +obj-$(CONFIG_SOFTMMU) += null-machine.o
> diff --git a/hw/core/null-machine.c b/hw/core/null-machine.c
> index 0351ba7..27c8369 100644
> --- a/hw/core/null-machine.c
> +++ b/hw/core/null-machine.c
> @@ -13,18 +13,41 @@
>
>  #include "qemu/osdep.h"
>  #include "qemu-common.h"
> +#include "qemu/error-report.h"
>  #include "hw/hw.h"
>  #include "hw/boards.h"
> +#include "sysemu/sysemu.h"
> +#include "exec/address-spaces.h"
> +#include "cpu.h"
>
> -static void machine_none_init(MachineState *machine)
> +static void machine_none_init(MachineState *mch)
>  {
> +CPUState *cpu = NULL;
> +
> +/* Initialize CPU (if a model has been specified) */
> +if (mch->cpu_model) {
> +cpu = cpu_init(mch->cpu_model);
> +if (!cpu) {
> +error_report("Unable to initialize CPU");
> +exit(1);
> +}
> +}
> +
> +/* RAM at address zero */
> +if (mch->ram_size) {
> +MemoryRegion *ram = g_new(MemoryRegion, 1);
> +
> +memory_region_allocate_system_memory(ram, NULL, "ram", 
> mch->ram_size);
> +memory_region_add_subregion(get_system_memory(), 0, ram);
> +}
>  }
>
>  static void machine_none_machine_init(MachineClass *mc)
>  {
>  mc->desc = "empty machine";
>  mc->init = machine_none_init;
> -mc->max_cpus = 0;
> +mc->max_cpus = 1;
> +mc->default_ram_size = 0;
>  }
>
>  DEFINE_MACHINE("none", machine_none_machine_init)
> --
> 1.8.3.1
>
>



[Qemu-devel] [RFC 10/13] numa: replace cpu_index_to_socket_id() with cpu_index_to_instance_props()

2017-01-18 Thread Igor Mammedov
new cpu_index_to_instance_props() returns topo info which
includes socket_id so it could be used as drop in replacement
in the only user parse_numa_opts().

In follow up path cpu_index_to_instance_props() will be used in
compat code to set legacy index based cpu<->node mapping using
new machine.cpu property.

Signed-off-by: Igor Mammedov 
---
 include/hw/boards.h | 11 ++-
 hw/i386/pc.c| 14 --
 hw/ppc/spapr.c  | 13 ++---
 numa.c  |  7 +--
 4 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index 6364617..daceee5 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -70,10 +70,10 @@ typedef struct {
  *of HotplugHandler object, which handles hotplug operation
  *for a given @dev. It may return NULL if @dev doesn't require
  *any actions to be performed by hotplug handler.
- * @cpu_index_to_socket_id:
- *used to provide @cpu_index to socket number mapping, allowing
- *a machine to group CPU threads belonging to the same socket/package
- *Returns: socket number given cpu_index belongs to.
+ * @cpu_index_to_instance_props:
+ *used to provide @cpu_index to socket/core/thread number mapping, allowing
+ *legacy code to perform maping from cpu_index to topology properties
+ *Returns: tuple of socket/core/thread ids given cpu_index belongs to.
  * @hw_version:
  *Value of QEMU_VERSION when the machine was added to QEMU.
  *Set only by old machines because they need to keep
@@ -135,7 +135,8 @@ struct MachineClass {
 
 HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
DeviceState *dev);
-unsigned (*cpu_index_to_socket_id)(unsigned cpu_index);
+CpuInstanceProperties (*cpu_index_to_instance_props)(MachineState *machine,
+ unsigned cpu_index);
 const CPUArchIdList *(*possible_cpu_arch_ids)(MachineState *machine);
 HotpluggableCPUList *(*query_hotpluggable_cpus)(MachineState *machine);
 };
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 1d33a5e..5066339 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -2286,12 +2286,14 @@ static void pc_machine_reset(void)
 }
 }
 
-static unsigned pc_cpu_index_to_socket_id(unsigned cpu_index)
+static CpuInstanceProperties
+pc_cpu_index_to_instance_props(MachineState *ms, unsigned cpu_index)
 {
-X86CPUTopoInfo topo;
-x86_topo_ids_from_idx(smp_cores, smp_threads, cpu_index,
-  );
-return topo.pkg_id;
+MachineClass *mc = MACHINE_GET_CLASS(ms);
+const CPUArchIdList *possible_cpus = mc->possible_cpu_arch_ids(ms);
+
+assert(cpu_index < possible_cpus->len);
+return possible_cpus->cpus[cpu_index].props;
 }
 
 static const CPUArchIdList *pc_possible_cpu_arch_ids(MachineState *machine)
@@ -2398,7 +2400,7 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->acpi_data_size = 0x2 + 0x8000;
 pcmc->save_tsc_khz = true;
 mc->get_hotplug_handler = pc_get_hotpug_handler;
-mc->cpu_index_to_socket_id = pc_cpu_index_to_socket_id;
+mc->cpu_index_to_instance_props = pc_cpu_index_to_instance_props;
 mc->possible_cpu_arch_ids = pc_possible_cpu_arch_ids;
 mc->query_hotpluggable_cpus = pc_query_hotpluggable_cpus;
 mc->default_boot_order = "cad";
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index efcd925..17eec87 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2571,11 +2571,18 @@ static HotplugHandler 
*spapr_get_hotplug_handler(MachineState *machine,
 return NULL;
 }
 
-static unsigned spapr_cpu_index_to_socket_id(unsigned cpu_index)
+static CpuInstanceProperties
+spapr_cpu_index_to_instance_props(MachineState *ms, unsigned cpu_index)
 {
 /* Allocate to NUMA nodes on a "socket" basis (not that concept of
  * socket means much for the paravirtualized PAPR platform) */
-return cpu_index / smp_threads / smp_cores;
+CpuInstanceProperties topo = {
+.socket_id = cpu_index / smp_threads / smp_cores,
+.has_socket_id = true,
+.has_core_id = false,
+.has_thread_id = false,
+};
+return topo;
 }
 
 static HotpluggableCPUList *spapr_query_hotpluggable_cpus(MachineState 
*machine)
@@ -2688,7 +2695,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
 hc->pre_plug = spapr_machine_device_pre_plug;
 hc->plug = spapr_machine_device_plug;
 hc->unplug = spapr_machine_device_unplug;
-mc->cpu_index_to_socket_id = spapr_cpu_index_to_socket_id;
+mc->cpu_index_to_instance_props = spapr_cpu_index_to_instance_props;
 hc->unplug_request = spapr_machine_device_unplug_request;
 
 smc->dr_lmb_enabled = true;
diff --git a/numa.c b/numa.c
index 0164cd7..887ee58 100644
--- a/numa.c
+++ b/numa.c
@@ -404,8 +404,11 @@ void parse_numa_opts(MachineState *ms)
 if (i == nb_numa_nodes) {
 for (i = 0; i < 

[Qemu-devel] [RFC 13/13] pc: cpu: make sure that cpu.node-id matches -numa mapping

2017-01-18 Thread Igor Mammedov
for PC CPU's node mapping defined statically at startup
and not possible to changle at hotplug time.
So check that user set cpu.node-id matches whatever values
were configured with -numa options (ex|im)plicitly.

Signed-off-by: Igor Mammedov 
---
 hw/i386/pc.c  | 11 ++-
 target/i386/cpu.c |  2 +-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index e2833e0..d828a1a 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1967,7 +1967,16 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
 
 cs = CPU(cpu);
 cs->cpu_index = idx;
-cpu->numa_nid = cpu_slot->props.node_id;
+
+if (cpu->numa_nid == -1) {
+cpu->numa_nid = cpu_slot->props.node_id;
+} else if (cpu->numa_nid != cpu_slot->props.node_id) {
+error_setg(errp, "property node-id: %u doesn't match with -numa"
+" explictly specified value(s) or implicitly set defaults."
+" Expected value: %" PRIi64,
+cpu->numa_nid, cpu_slot->props.node_id);
+return;
+}
 }
 
 static void pc_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev,
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 85c52f1..6375a37 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3649,7 +3649,7 @@ static Property x86_cpu_properties[] = {
 DEFINE_PROP_INT32("core-id", X86CPU, core_id, -1),
 DEFINE_PROP_INT32("socket-id", X86CPU, socket_id, -1),
 #endif
-DEFINE_PROP_INT32("node-id", X86CPU, numa_nid, 0),
+DEFINE_PROP_INT32("node-id", X86CPU, numa_nid, -1),
 DEFINE_PROP_BOOL("pmu", X86CPU, enable_pmu, false),
 { .name  = "hv-spinlocks", .info  = _prop_spinlocks },
 DEFINE_PROP_BOOL("hv-relaxed", X86CPU, hyperv_relaxed_timing, false),
-- 
2.7.4




Re: [Qemu-devel] [PATCH v3] aspeed/smc: handle dummy bytes when doing fast reads in command mode

2017-01-18 Thread mar.krzeminski

W dniu 18.01.2017 o 16:01, Cédric Le Goater pisze:

When doing fast read, a certain amount of dummy bytes should be sent
before the read. This number is configurable in the controler CE0
Control Register and needs to be modeled using fake transfers to the
flash module.

This only supports command mode. User mode requires more work and a
possible extension of the m25p80 device model.

Signed-off-by: Cédric Le Goater 
---

  Changes since v2:

  - handled dummies under read routine and removed the test on the spi
command READ_FAST (0xb)

  hw/ssi/aspeed_smc.c | 21 +
  1 file changed, 21 insertions(+)

diff --git a/hw/ssi/aspeed_smc.c b/hw/ssi/aspeed_smc.c
index a0a816407fc1..fc3cccec0566 100644
--- a/hw/ssi/aspeed_smc.c
+++ b/hw/ssi/aspeed_smc.c
@@ -69,7 +69,9 @@
  #define R_CTRL0   (0x10 / 4)
  #define   CTRL_CMD_SHIFT   16
  #define   CTRL_CMD_MASK0xff
+#define   CTRL_DUMMY_HIGH_SHIFT14
  #define   CTRL_AST2400_SPI_4BYTE   (1 << 13)
+#define   CTRL_DUMMY_LOW_SHIFT 6 /* 2 bits [7:6] */
  #define   CTRL_CE_STOP_ACTIVE  (1 << 2)
  #define   CTRL_CMD_MODE_MASK   0x3
  #define CTRL_READMODE  0x0
@@ -490,6 +492,16 @@ static uint32_t aspeed_smc_check_segment_addr(const 
AspeedSMCFlash *fl,
  return addr;
  }
  
+static int aspeed_smc_flash_dummies(const AspeedSMCFlash *fl)

+{
+const AspeedSMCState *s = fl->controller;
+uint32_t r_ctrl0 = s->regs[s->r_ctrl0 + fl->id];
+uint32_t dummy_high = (r_ctrl0 >> CTRL_DUMMY_HIGH_SHIFT) & 0x1;
+uint32_t dummy_low = (r_ctrl0 >> CTRL_DUMMY_LOW_SHIFT) & 0x3;
+
+return ((dummy_high << 2) | dummy_low) * 8;
+}
+
  static void aspeed_smc_flash_send_addr(AspeedSMCFlash *fl, uint32_t addr)
  {
  const AspeedSMCState *s = fl->controller;
@@ -526,6 +538,15 @@ static uint64_t aspeed_smc_flash_read(void *opaque, hwaddr 
addr, unsigned size)
  aspeed_smc_flash_select(fl);
  aspeed_smc_flash_send_addr(fl, addr);
  
+/*

+ * Use fake transfers to model dummy bytes. The value should
+ * be configured to some non-zero value in fast read mode and
+ * zero in read mode.
+ */
+for (i = 0; i < aspeed_smc_flash_dummies(fl); i++) {
+ssi_transfer(fl->controller->spi, 0xFF);
+}
+
  for (i = 0; i < size; i++) {
  ret |= ssi_transfer(s->spi, 0x0) << (8 * i);
  }

If it does not break CTRL_WRITEMODE then:
Acked-by: Marcin Krzemiński 




Re: [Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM

2017-01-18 Thread Thomas Huth
On 18.01.2017 18:57, Alistair Francis wrote:
> On Wed, Jan 18, 2017 at 4:44 AM, Thomas Huth  wrote:
>> Sometimes it is useful to have just a machine with CPU and RAM, without
>> any further hardware in it, e.g. if you just want to do some instruction
>> debugging for TCG with a remote GDB attached to QEMU, or run some embedded
>> code with the "-semihosting" QEMU parameter. qemu-system-m68k already
>> features a "dummy" machine, and xtensa a "sim" machine for exactly this
>> purpose.
>> All target architectures have nowadays also a "none" machine, which would
>> be a perfect match for this, too - but it currently does not allow to add
>> CPU and RAM yet. Thus let's add these possibilities in a generic way to the
>> "none" machine, too, so that we hopefully do not need additional "dummy"
>> machines in the future anymore (and maybe can also get rid of the already
>> existing "dummy"/"sim" machines one day).
>> Note that the default behaviour of the "none" machine is not changed, i.e.
>> no CPU and no RAM is instantiated by default. You have explicitely got to
>> specify the CPU model with "-cpu" and the amount of RAM with "-m" to get
>> these new features.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  v3:
>>  - Get rid of the cpu_init_def() wrapper again, make null-machine.o
>>target dependent instead and use cpu_init() directly.
>>  - Omit the loader code for the "-kernel" option for now (users can
>>use "-device loader,..." instead). We can add code for the -kernel
>>parameter later (either an implementation or a warning), once we've
>>decided how it should behave for the "none" machine.
> 
> I think there should at least be a warning to start with though. It
> seems confusing that no errors are reported but the argument is
> ignored.

I'm still rather in favor of adding the hunk here that calls the generic
loader for "-kernel" ... anyway, we can add either behavior with a later
patch. So far the "none" machine never reported an error here, so this
is not a regression if we do not have this right from the start.

 Thomas




Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type

2017-01-18 Thread no-reply
Hi,

Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Message-id: 20170118160332.13390-1-marcandre.lur...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=16
make docker-test-quick@centos6
make docker-test-mingw@fedora
make docker-test-build@min-glib
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
41964b5 qmp: move json-message-parser and check to QmpClient
cda70c8 qtest: add /qemu-qmp/screendump test
7f25d0c console: make screendump async
f6fd70a console: add graphic_hw_update_done()
3b4426b console: graphic_hw_update return true if async
eebbe9d qapi: improve 'screendump' documentation
296c894 tests: add tests for async and non-async clients
11f8f59 qtest: add qtest_init_qmp_caps()
9c37e95 qtest: add qtest-timeout
ee1936a qmp: update qmp-spec about async capability
772f607 monitor: suspend when running async and client has no async
7f9c73e monitor: add !qmp pre-conditions
9967230 monitor: add 'async' capability
3a484e5 tests: add dispatch async tests
8eded8c scripts: learn 'async' qapi commands
04a99cd qmp: check that async command have an 'id'
422c166 qmp: take 'id' from request
981bd6b qapi: ignore top-level 'id' field
7861275 qmp: introduce async command type
0328828 qmp: add qmp_return_is_cancelled()
8d2ff5f qmp: add QmpClient
4be5d8c qmp: use a return callback for the command reply
317c314 qmp: teach qmp_dispatch() to take a pre-filled QDict
5b8f81d tests: change /0.15/* tests to /qmp/*
d61d8f7 tests: start generic qemu-qmp tests

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
  BUILD   centos6
make[1]: Entering directory `/var/tmp/patchew-tester-tmp-nlrtpn_4/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=4cb985a08678
TERM=xterm
MAKEFLAGS= -j16
HISTSIZE=1000
J=16
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1-pthread -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels -Wmissing-include-dirs 
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu 

Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device

2017-01-18 Thread Laszlo Ersek
On 01/18/17 18:02, Ard Biesheuvel wrote:
> On 18 January 2017 at 15:55, Laszlo Ersek  wrote:
>> On 01/18/17 16:18, Igor Mammedov wrote:
>>> On Tue, 17 Jan 2017 10:56:53 +
>>> Peter Maydell  wrote:
>>>
 On 17 January 2017 at 09:49, Andrew Jones  wrote:
> In some cases the problem we're solving with the compat guards is
> a bit hypothetical, but, IMHO, nonetheless a good practice. While
> we may be sure that AAVMF and Linux will be fine with this table
> changing under their feet, we can't be sure there aren't other
> mach-virt users that have more sensitive firmwares/OSes. An ACPI-
> sensitive OS may notice the change on its next reboot after a
> migration, and then simply refuse to continue.

 There's also the case where you do a VM migration midway through
 UEFI booting up, I think, which might cause things to go wrong
 if you catch it just at the wrong moment.
>>> acpi blobs are migrated from source so above won't happen.
>>> The time guest will see new table is fresh boot or reboot.
>>>

> Now, that said, I just spoke with Igor in order to learn the x86
> practice. He says that the policy has been more lax than what I
> suggest above. Hypothetical, low-risk issues are left unguarded,
> and only when a bug is found during testing is it then managed.
> The idea is to try and reduce the amount of compat variables and
> conditions needed in the ACPI generation code, but, of course, at
> some level of risk to users expecting their versioned machine type
> to always appear the same.
>
> So far we've been strict with mach-virt, guarding all hypothetical
> issues. Perhaps this patch is a good example to get a discussion
> started on whether or not we should be so strict though.

 That said, I don't have a very strong opinion here, beyond that
 we should be consistent at least with x86 practice.
>>> another reason why we are trying not to use strict approach with ACPI
>>> tables is that it's part of firmware and we didn't version firmwares
>>> so far. (i.e. dst host with newer QEMU will typically have newer
>>> firmware and guest with old machine-type migrated to host with newer
>>> QEMU will run new firmware on (re)boot)
>>
>> I haven't been aware of this argument, and I'm surprised by it, but I
>> think it's valid. Regardless of our choice to ultimately compose the
>> ACPI tables in QEMU, guest OSes definitely consider ACPI as part of the
>> firmware. So, different ACPI content after a migration + guest reboot on
>> the target host is not much different from any other firmware-level
>> changes encountered on the same target host, after reboot.
>>
> 
> I agree. But does that imply that this fix should be tightly coupled
> to the mach-virt version, considering that the UEFI firmware you run
> *inside* such a vm is not versioned either?

No, it implies the exact opposite: given that the UEFI firmware is not
versioned, and may very well differ on source host and target host, the
ACPI payload that QEMU generates (and that the guest OS considers part
of the firmware) should be permitted to differ between src and dst host
just the same.

In brief, for one data point, I'd be fine if we didn't tie this change
to machine types.

Thanks
Laszlo



[Qemu-devel] [RFC 03/13] pc: don't return cpu pointer from pc_new_cpu() as it's not needed anymore

2017-01-18 Thread Igor Mammedov
Signed-off-by: Igor Mammedov 
---
 hw/i386/pc.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 2461d84..c0eba8a 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1092,28 +1092,24 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int 
level)
 }
 }
 
-static X86CPU *pc_new_cpu(const char *typename, int64_t apic_id,
-  Error **errp)
+static void pc_new_cpu(const char *typename, int64_t apic_id, Error **errp)
 {
-X86CPU *cpu = NULL;
+Object *cpu = NULL;
 Error *local_err = NULL;
 
-cpu = X86_CPU(object_new(typename));
+cpu = object_new(typename);
 
-object_property_set_int(OBJECT(cpu), apic_id, "apic-id", _err);
-object_property_set_bool(OBJECT(cpu), true, "realized", _err);
+object_property_set_int(cpu, apic_id, "apic-id", _err);
+object_property_set_bool(cpu, true, "realized", _err);
 
+object_unref(cpu);
 if (local_err) {
 error_propagate(errp, local_err);
-object_unref(OBJECT(cpu));
-cpu = NULL;
 }
-return cpu;
 }
 
 void pc_hot_add_cpu(const int64_t id, Error **errp)
 {
-X86CPU *cpu;
 ObjectClass *oc;
 PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
 int64_t apic_id = x86_cpu_apic_id_from_index(id);
@@ -1133,12 +1129,11 @@ void pc_hot_add_cpu(const int64_t id, Error **errp)
 
 assert(pcms->possible_cpus->cpus[0].cpu); /* BSP is always present */
 oc = OBJECT_CLASS(CPU_GET_CLASS(pcms->possible_cpus->cpus[0].cpu));
-cpu = pc_new_cpu(object_class_get_name(oc), apic_id, _err);
+pc_new_cpu(object_class_get_name(oc), apic_id, _err);
 if (local_err) {
 error_propagate(errp, local_err);
 return;
 }
-object_unref(OBJECT(cpu));
 }
 
 void pc_cpus_init(PCMachineState *pcms)
@@ -1148,7 +1143,6 @@ void pc_cpus_init(PCMachineState *pcms)
 ObjectClass *oc;
 const char *typename;
 gchar **model_pieces;
-X86CPU *cpu = NULL;
 MachineState *machine = MACHINE(pcms);
 
 /* init CPUs */
@@ -1190,9 +1184,7 @@ void pc_cpus_init(PCMachineState *pcms)
 pcms->possible_cpus->cpus[i].arch_id = x86_cpu_apic_id_from_index(i);
 pcms->possible_cpus->len++;
 if (i < smp_cpus) {
-cpu = pc_new_cpu(typename, x86_cpu_apic_id_from_index(i),
- _fatal);
-object_unref(OBJECT(cpu));
+pc_new_cpu(typename, x86_cpu_apic_id_from_index(i), _fatal);
 }
 }
 }
-- 
2.7.4




[Qemu-devel] [RFC 09/13] numa: introduce '-numa cpu' cpu option

2017-01-18 Thread Igor Mammedov
It allows to specify mapping of a CPU to NUMA node on CLI.
Option should be repeated for each present/possible CPU.
Example for PC machine:
  -numa node,nodeid=0 -numa node,nodeid=1 \
  -numa cpu,socket-id=0,core-id=0,thread-id=0,node-id=0 \
  -numa cpu,socket-id=1,core-id=0,thread-id=0,node-id=1

Signed-off-by: Igor Mammedov 
---
 include/sysemu/numa.h |  2 +-
 numa.c| 30 +++---
 qapi-schema.json  |  3 ++-
 vl.c  |  2 +-
 4 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h
index b8015a5..d4b139e 100644
--- a/include/sysemu/numa.h
+++ b/include/sysemu/numa.h
@@ -24,7 +24,7 @@ typedef struct node_info {
 } NodeInfo;
 
 extern NodeInfo numa_info[MAX_NODES];
-void parse_numa_opts(MachineClass *mc);
+void parse_numa_opts(MachineState *ms);
 void query_numa_node_mem(uint64_t node_mem[]);
 extern QemuOptsList qemu_numa_opts;
 void numa_set_mem_node_id(ram_addr_t addr, uint64_t size, uint32_t node);
diff --git a/numa.c b/numa.c
index 5f68497..0164cd7 100644
--- a/numa.c
+++ b/numa.c
@@ -37,6 +37,8 @@
 #include "hw/mem/pc-dimm.h"
 #include "qemu/option.h"
 #include "qemu/config-file.h"
+#include "qapi/qobject-output-visitor.h"
+#include "qapi/qobject-input-visitor.h"
 
 QemuOptsList qemu_numa_opts = {
 .name = "numa",
@@ -213,11 +215,13 @@ static void numa_node_parse(NumaNodeOptions *node, 
QemuOpts *opts, Error **errp)
 
 static int parse_numa(void *opaque, QemuOpts *opts, Error **errp)
 {
+Visitor *v;
 NumaOptions *object = NULL;
+MachineState *ms = MACHINE(opaque);
 Error *err = NULL;
 
 {
-Visitor *v = opts_visitor_new(opts);
+v = opts_visitor_new(opts);
 visit_type_NumaOptions(v, NULL, , );
 visit_free(v);
 }
@@ -234,6 +238,25 @@ static int parse_numa(void *opaque, QemuOpts *opts, Error 
**errp)
 }
 nb_numa_nodes++;
 break;
+case NUMA_OPTIONS_KIND_CPU: {
+QObject *qobj;
+
+v = qobject_output_visitor_new();
+visit_type_CpuInstanceProperties(v, "cpu", >u.cpu.data, );
+visit_complete(v, );
+visit_free(v);
+if (err) {
+goto end;
+}
+v = qobject_input_visitor_new(qobj, true);
+object_property_set(OBJECT(ms), v, "cpu", );
+visit_free(v);
+qobject_decref(qobj);
+if (err) {
+goto end;
+}
+break;
+}
 default:
 abort();
 }
@@ -293,15 +316,16 @@ static void validate_numa_cpus(void)
 g_free(seen_cpus);
 }
 
-void parse_numa_opts(MachineClass *mc)
+void parse_numa_opts(MachineState *ms)
 {
 int i;
+MachineClass *mc = MACHINE_GET_CLASS(ms);
 
 for (i = 0; i < MAX_NODES; i++) {
 numa_info[i].node_cpu = bitmap_new(max_cpus);
 }
 
-if (qemu_opts_foreach(qemu_find_opts("numa"), parse_numa, NULL, NULL)) {
+if (qemu_opts_foreach(qemu_find_opts("numa"), parse_numa, ms, NULL)) {
 exit(1);
 }
 
diff --git a/qapi-schema.json b/qapi-schema.json
index ddc8783..69c059b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -5543,7 +5543,8 @@
 ##
 { 'union': 'NumaOptions',
   'data': {
-'node': 'NumaNodeOptions' }}
+'node': 'NumaNodeOptions',
+'cpu': 'CpuInstanceProperties' }}
 
 ##
 # @NumaNodeOptions:
diff --git a/vl.c b/vl.c
index afe40ce..d724523 100644
--- a/vl.c
+++ b/vl.c
@@ -4485,7 +4485,7 @@ int main(int argc, char **argv, char **envp)
 default_drive(default_floppy, snapshot, IF_FLOPPY, 0, FD_OPTS);
 default_drive(default_sdcard, snapshot, IF_SD, 0, SD_OPTS);
 
-parse_numa_opts(machine_class);
+parse_numa_opts(current_machine);
 
 if (qemu_opts_foreach(qemu_find_opts("mon"),
   mon_init_func, NULL, NULL)) {
-- 
2.7.4




Re: [Qemu-devel] [PATCH 01/18] tcg: add support for 128bit vector type

2017-01-18 Thread Richard Henderson

On 01/17/2017 01:07 AM, Kirill Batuzov wrote:

+static inline TCGv_v128 tcg_global_mem_new_v128(TCGv_ptr reg, intptr_t offset,
+const char *name)
+{
+int idx = tcg_global_mem_new_internal(TCG_TYPE_V128, reg, offset, name);
+return MAKE_TCGV_V128(idx);
+}


You shouldn't allow a v128 type to be created if the host doesn't support it.

You may want to treat v128 as a pair of v64 if the host supports that. 
Although there's limited applicability there, since only minor hosts (MIPS, 
Sparc, ia64) have 64-bit-only vector extensions.


That said, treating v128 as 2 x v64 scales nicely when we add v256.  Which, if 
we've already gone this far, is clearly how avx2 guest support should be 
implemented.


For hosts that have had no vector support added, you may want to represent v128 
as 2 x i64, for the purpose of intermediate expansion.



r~



Re: [Qemu-devel] [PATCH v1 11/15] qcow2: convert QCow2 to use QCryptoBlock for encryption

2017-01-18 Thread Max Reitz
On 03.01.2017 19:27, Daniel P. Berrange wrote:
> This converts the qcow2 driver to make use of the QCryptoBlock
> APIs for encrypting image content, using the legacyy QCow2 AES
> scheme.
> 
> With this change it is now required to use the QCryptoSecret
> object for providing passwords, instead of the current block
> password APIs / interactive prompting.
> 
>   $QEMU \
> -object secret,id=sec0,filename=/home/berrange/encrypted.pw \
> -drive file=/home/berrange/encrypted.qcow2,aes-key-secret=sec0
> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  block/qcow2-cluster.c  |  47 +--
>  block/qcow2.c  | 190 
> +
>  block/qcow2.h  |   5 +-
>  qapi/block-core.json   |   7 +-
>  tests/qemu-iotests/049 |   2 +-
>  tests/qemu-iotests/049.out |   4 +-
>  tests/qemu-iotests/082.out |  27 +++
>  tests/qemu-iotests/087 |  28 ++-
>  tests/qemu-iotests/087.out |   6 +-
>  tests/qemu-iotests/134 |  18 +++--
>  tests/qemu-iotests/134.out |  10 +--
>  tests/qemu-iotests/158 |  19 +++--
>  tests/qemu-iotests/158.out |  14 +---
>  13 files changed, 219 insertions(+), 158 deletions(-)

[...]

> diff --git a/block/qcow2.c b/block/qcow2.c
> index 3c14c86..5c9e196 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c

[...]

> @@ -1122,6 +1144,24 @@ static int qcow2_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  goto fail;
>  }
>  
> +if (s->crypt_method_header == QCOW_CRYPT_AES) {
> +unsigned int cflags = 0;
> +if (flags & BDRV_O_NO_IO) {
> +cflags |= QCRYPTO_BLOCK_OPEN_NO_IO;
> +}
> +/* XXX how do we pass the same crypto opts down to the

I think a TODO instead of an XXX would have been sufficient, but it's
your call.

> + * backing file by default, so we don't have to manually
> + * provide the same key-secret property against the full
> + * backing chain
> + */
> +s->crypto = qcrypto_block_open(s->crypto_opts, NULL, NULL,
> +   cflags, errp);
> +if (!s->crypto) {
> +ret = -EINVAL;
> +goto fail;
> +}

[...]

> @@ -2022,6 +2027,44 @@ static int qcow2_change_backing_file(BlockDriverState 
> *bs,
>  return qcow2_update_header(bs);
>  }
>  
> +
> +static int qcow2_change_encryption(BlockDriverState *bs, QemuOpts *opts,
> +   Error **errp)

I think this name is not quite appropriate, since this doesn't change
the format of the file if it is already encrypted (and it will not
encrypt any existing data).

Maybe set_up instead of change?

(qcow2_change_backing_file()'s name is good because it will actually
work if there already is a different backing file.)

> +{
> +BDRVQcow2State *s = bs->opaque;
> +QCryptoBlockCreateOptions *cryptoopts = NULL;
> +QCryptoBlock *crypto = NULL;
> +int ret = -EINVAL;

[...]

> diff --git a/block/qcow2.h b/block/qcow2.h
> index 033d8c0..f4cb171 100644
> --- a/block/qcow2.h
> +++ b/block/qcow2.h
> @@ -25,7 +25,7 @@
>  #ifndef BLOCK_QCOW2_H
>  #define BLOCK_QCOW2_H
>  
> -#include "crypto/cipher.h"
> +#include "crypto/block.h"
>  #include "qemu/coroutine.h"
>  
>  //#define DEBUG_ALLOC
> @@ -256,7 +256,8 @@ typedef struct BDRVQcow2State {
>  
>  CoMutex lock;
>  
> -QCryptoCipher *cipher; /* current cipher, NULL if no key yet */
> +QCryptoBlockOpenOptions *crypto_opts; /* Disk encryption runtime options 
> */
> +QCryptoBlock *crypto; /* Disk encryption format driver */
>  uint32_t crypt_method_header;
>  uint64_t snapshots_offset;
>  int snapshots_size;
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index c2b70e8..2ca5674 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -1935,6 +1935,9 @@
>  # @cache-clean-interval:  #optional clean unused entries in the L2 and 
> refcount
>  # caches. The interval is in seconds. The default 
> value
>  # is 0 and it disables this feature (since 2.5)
> +# @aes-key-secret:#optional the ID of a QCryptoSecret object 
> providing
> +# the AES decryption key (since 2.9) Mandatory except

Missing full stop after the closing parenthesis.

Also, it's mandatory only for encrypted images. I know it's obvious but
that's not what it says here.

> +# when doing a metadata-only probe of the image.
>  #
>  # Since: 1.7
>  ##
> @@ -1948,8 +1951,8 @@
>  '*cache-size': 'int',
>  '*l2-cache-size': 'int',
>  '*refcount-cache-size': 'int',
> -'*cache-clean-interval': 'int' } }
> -
> +'*cache-clean-interval': 'int',
> +'*aes-key-secret': 'str' } }
>  
>  ##
>  # @BlockdevOptionsArchipelago:
> diff --git a/tests/qemu-iotests/049 b/tests/qemu-iotests/049
> index fff0760..7da4ac8 100755
> --- 

Re: [Qemu-devel] [PATCH 10/18] tcg/i386: add support for vector opcodes

2017-01-18 Thread Richard Henderson

On 01/18/2017 05:05 AM, Kirill Batuzov wrote:

Why are you not defining xmm8-15?


At first I thought about supporting both x86_64 and i386 targets, but
put this idea away (at least for the time being). Since defining xmm8-15
does not contradict anything (as I see it now) I'll add them too.


Thanks.  Although (potentialy) all you need to do to support i386 is to make 
sure that TCG_TARGET_HAS_add_* are properly conditionalized on a runtime 
have_sse2 check.  There are other examples of how such runtime checks should be 
done.


(That said, I can imagine there might be other issues with respect to i64 vs 
v64 that might turn out to be complicated.  It wouldn't bother me if we 
restricted vector support to 64-bit hosts.)



r~



Re: [Qemu-devel] [RFC 08/13] pc: add writeonly 'cpu' property to PCMachine

2017-01-18 Thread Eduardo Habkost
On Wed, Jan 18, 2017 at 06:13:24PM +0100, Igor Mammedov wrote:
> it will allow generic numa code to set cpu to numa node mapping
> in target independent manner in the next patch.
> 
> Signed-off-by: Igor Mammedov 

This looks like a creative way to abuse the QOM property system.
What's the problem with using a simple C function like:
  void (*set_cpu_affinity)(MachineState *m, CpuInstanceProperties *props, Error 
**errp)
?


> ---
>  hw/i386/pc.c | 56 
>  1 file changed, 56 insertions(+)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index f8ea635..1d33a5e 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -2201,6 +2201,56 @@ static void pc_machine_set_pit(Object *obj, bool 
> value, Error **errp)
>  pcms->pit = value;
>  }
>  
> +static void pc_machine_set_cpu(Object *obj, Visitor *v, const char *name,
> +   void *opaque, Error **errp)
> +{
> +uint32_t apic_id;
> +X86CPUTopoInfo topo;
> +CPUArchId *cpu_slot;
> +Error *local_err = NULL;
> +CpuInstanceProperties *cpu_props = NULL;
> +PCMachineState *pcms = PC_MACHINE(obj);
> +MachineClass *mc = MACHINE_GET_CLASS(obj);
> +
> +visit_type_CpuInstanceProperties(v, name, _props, _err);
> +if (local_err) {
> +goto out;
> +}
> +
> +if (!cpu_props->has_node_id) {
> +error_setg(_err, "node-id property is not specified");
> +goto out;
> +}
> +
> +/*
> + * make sure that possible_cpus is initialized
> + * as property setter might be called before machine init is called
> + */
> +mc->possible_cpu_arch_ids(MACHINE(obj));
> +
> +topo.pkg_id = cpu_props->socket_id;
> +topo.core_id = cpu_props->core_id;
> +topo.smt_id = cpu_props->thread_id;
> +apic_id = apicid_from_topo_ids(smp_cores, smp_threads, );
> +cpu_slot = pc_find_cpu_slot(pcms, apic_id, NULL);
> +if (!cpu_slot) {
> +error_setg(_err, "unable to find CPU");
> +goto out;
> +}
> +
> +if (cpu_slot->props.has_node_id) {
> +error_setg(_err, "CPU has already been assigned to node: 
> %"PRId64,
> +   cpu_slot->props.node_id);
> +goto out;
> +}
> +cpu_slot->props.has_node_id = true;
> +cpu_slot->props.node_id = cpu_props->node_id;
> +
> + out:
> +error_propagate(errp, local_err);
> +qapi_free_CpuInstanceProperties(cpu_props);
> +}
> +
>  static void pc_machine_initfn(Object *obj)
>  {
>  PCMachineState *pcms = PC_MACHINE(obj);
> @@ -2395,6 +2445,12 @@ static void pc_machine_class_init(ObjectClass *oc, 
> void *data)
>  
>  object_class_property_add_bool(oc, PC_MACHINE_PIT,
>  pc_machine_get_pit, pc_machine_set_pit, _abort);
> +
> +object_class_property_add(oc, "cpu", "CpuInstanceProperties",
> +NULL, pc_machine_set_cpu,
> +NULL, NULL, _abort);
> +object_class_property_set_description(oc, "cpu",
> +"Possible cpu placement", _abort);
>  }
>  
>  static const TypeInfo pc_machine_info = {
> -- 
> 2.7.4
> 

-- 
Eduardo



Re: [Qemu-devel] [PATCH v6 wave 2 0/3] q35: add negotiable broadcast SMI

2017-01-18 Thread Michael S. Tsirkin
On Thu, Jan 12, 2017 at 07:24:43PM +0100, Laszlo Ersek wrote:
> Previous version (v5):
> http://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg01902.html
> 
> Changes in v6 (see the individual patches for details):
> - pick up feedback tags
> - rename "smi_broadcast" to "x-smi-broadcast" [Eduardo]
> 
> Cc: "Michael S. Tsirkin" 
> Cc: Eduardo Habkost 
> Cc: Gerd Hoffmann 
> Cc: Igor Mammedov 
> Cc: Paolo Bonzini 

Series:

Reviewed-by: Michael S. Tsirkin 

Paolo, I'm merging wave 1, I assume you will want to merge wave 2?

> Thanks!
> Laszlo
> 
> Laszlo Ersek (3):
>   hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
>   hw/isa/lpc_ich9: add broadcast SMI feature
>   hw/isa/lpc_ich9: negotiate SMI broadcast on pc-q35-2.9+ machine types
> 
>  include/hw/i386/ich9.h | 13 
>  include/hw/i386/pc.h   |  5 +++
>  hw/isa/lpc_ich9.c  | 91 
> +-
>  3 files changed, 108 insertions(+), 1 deletion(-)
> 
> -- 
> 2.9.3



Re: [Qemu-devel] [libvirt] [PATCH 0/9] i386: query-cpu-model-expansion test script

2017-01-18 Thread Jason J. Herne

On 01/18/2017 12:00 PM, Eduardo Habkost wrote:

On Tue, Jan 17, 2017 at 10:22:10AM -0500, Jason J. Herne wrote:

On 01/16/2017 08:01 PM, Eduardo Habkost wrote:

This is a follow-up to the series that implements
query-cpu-model-expansion. Before including the test script, the
series has some fixes to allow the results of
query-cpu-model-expansion to be used in the QEMU command-line.

The script probably will work on s390x too, but I couldn't test
it yet.



Eduardo,

This test seems to mostly work on s390. The only issue I ran into is
querying host model using tcg only. s390 requires kvm to query the host
model. Perhaps we could just skip the tcg host test case on s390?


We could still try to test "host", but add it to a greylist where
errors returned by query-cpu-model-expansion can be non-fatal.
query-cpu-model-expansion model="host" can also fail with KVM if
the host doesn't support CPU models.



David had the idea to just support -cpu host for tcg. We could do that.
In the meantime, I'm ok with your greylist idea too. This would allow the
script to work properly on s390 right from the start, and we can remove the
greylist when s390 supports specifying -cpu host for tcg.

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)




Re: [Qemu-devel] [PATCH v6 wave 2 2/3] hw/isa/lpc_ich9: add broadcast SMI feature

2017-01-18 Thread Laszlo Ersek
On 01/18/17 17:26, Igor Mammedov wrote:
> On Wed, 18 Jan 2017 16:42:27 +0100
> Laszlo Ersek  wrote:
> 
>> On 01/18/17 13:38, Igor Mammedov wrote:
>>> On Wed, 18 Jan 2017 11:23:48 +0100
>>> Laszlo Ersek  wrote:
>>>   
 On 01/18/17 11:19, Laszlo Ersek wrote:  
> On 01/18/17 11:03, Igor Mammedov wrote:
>> On Tue, 17 Jan 2017 19:53:21 +0100
>> Laszlo Ersek  wrote:
>>

 [snip]
  
>>> This is the code I wrote (extracting a new ich9_apm_broadcast_smi()
>>> function from ich9_apm_ctrl_changed(), due to size reasons):
>>>
 static void ich9_apm_broadcast_smi(void)
 {
 CPUState *cs;

 cpu_synchronize_all_states(); /* <- mark this */
>> it probably should be executed after pause_all_vcpus(),
>> maybe it will help.
>>
 CPU_FOREACH(cs) {
 X86CPU *cpu = X86_CPU(cs);
 CPUX86State *env = >env;

 if (env->smbase == 0x3 && env->eip == 0xfff0) {
 CPUClass *k = CPU_GET_CLASS(cs);
 uint64_t cpu_arch_id = k->get_arch_id(cs);

 trace_ich9_apm_broadcast_smi_skip(cpu_arch_id);
 continue;
 }

 cpu_interrupt(cs, CPU_INTERRUPT_SMI);
 }
 }  
>>>
>> [...]
>>> (b) If I add the cpu_synchronize_all_states() call before the loop, then
>>> the incorrect filter matches go away; QEMU sees the KVM VCPU states
>>> correctly, and the SMI is broad-cast.
>>>
>>> However, in this case, the boot slows to a *crawl*. It's unbearable. All
>>> VCPUs are pegged at 100%, and you can easily follow the OVMF debug log
>>> with the naked eye, almost line by line.
>>> I didn't expect that cpu_synchronize_all_states() would be so costly,
>>> but it makes the idea of checking VCPU state in the APM_CNT handler a
>>> non-starter.
>> I wonder were bottleneck is to slow down guest so much.
>> What is actual cost of calling cpu_synchronize_all_states()?
>>
>> Maybe calling pause_all_vcpus() before cpu_synchronize_all_states()
>> would help.
>
> If I prepend just a pause_all_vcpus() function call, at the top, then
> the VM freezes (quite understandably) when the first SMI is raised via
> APM_CNT.
>
> If I, instead, bracket the function body with pause_all_vcpus() and
> resume_all_vcpus(), like this:
>
> static void ich9_apm_broadcast_smi(void)
> {
> CPUState *cs;
>
> pause_all_vcpus();
> cpu_synchronize_all_states();
> CPU_FOREACH(cs) {
> X86CPU *cpu = X86_CPU(cs);
> CPUX86State *env = >env;
>
> if (env->smbase == 0x3 && env->eip == 0xfff0) {
> CPUClass *k = CPU_GET_CLASS(cs);
> uint64_t cpu_arch_id = k->get_arch_id(cs);
>
> trace_ich9_apm_broadcast_smi_skip(cpu_arch_id);
> continue;
> }
>
> cpu_interrupt(cs, CPU_INTERRUPT_SMI);
> }
> resume_all_vcpus();
> }
>
> then I see the following symptoms:
> - rather than 4 VCPUs being pegged at 100%, only one VCPU is pegged at
>   100%
> - the boot process, as observed from the OVMF log, is just as slow
>   (= crawling) as without the VCPU pausing/resuming (i.e., like with
>   cpu_synchronize_all_states() only); so ultimately the
>   pausing/resuming doesn't help.

 I also tried this variant (bracketing only the sync call with 
 pause/resume):

 static void ich9_apm_broadcast_smi(void)
 {
 CPUState *cs;

 pause_all_vcpus();
 cpu_synchronize_all_states();
 resume_all_vcpus();
 CPU_FOREACH(cs) {
 X86CPU *cpu = X86_CPU(cs);
 CPUX86State *env = >env;

 if (env->smbase == 0x3 && env->eip == 0xfff0) {
 CPUClass *k = CPU_GET_CLASS(cs);
 uint64_t cpu_arch_id = k->get_arch_id(cs);

 trace_ich9_apm_broadcast_smi_skip(cpu_arch_id);
 continue;
 }

 cpu_interrupt(cs, CPU_INTERRUPT_SMI);
 }
 }

 This behaves identically to the version where pause/resume bracket the
 entire function body (i.e., 1 VCPU pegged, super-slow boot progress).  
>>> wrapping entire function into pause_all_vcpus()/resume_all_vcpus()
>>> looks better as then cpu_interrupt() would not need to send IPIs to CPUs
>>> since pause_all_vcpus() would have done it.
>>
>> I don't understand, why would a pause operation send IPIs?
> pause_all forces exit on all CPUs and cpu_interrupt() does the same to
> a CPU so if all CPUs were kicked out of running state then cpu_interrupt()
> would skip kick 

[Qemu-devel] [RFC 04/13] make possible_cpu_arch_ids() return const pointer

2017-01-18 Thread Igor Mammedov
make sure that external callers won't try to modify
possible_cpus and owner of possible_cpus can access
it directly when it modifies it.

Signed-off-by: Igor Mammedov 
---
 include/hw/acpi/acpi_dev_interface.h |  2 +-
 include/hw/boards.h  |  2 +-
 include/hw/i386/pc.h |  2 +-
 hw/acpi/cpu.c|  6 ++
 hw/acpi/cpu_hotplug.c|  4 +---
 hw/i386/acpi-build.c |  8 +++-
 hw/i386/pc.c | 10 +++---
 stubs/pc_madt_cpu_entry.c|  2 +-
 8 files changed, 13 insertions(+), 23 deletions(-)

diff --git a/include/hw/acpi/acpi_dev_interface.h 
b/include/hw/acpi/acpi_dev_interface.h
index 901a4ae..71d3c48 100644
--- a/include/hw/acpi/acpi_dev_interface.h
+++ b/include/hw/acpi/acpi_dev_interface.h
@@ -57,6 +57,6 @@ typedef struct AcpiDeviceIfClass {
 void (*ospm_status)(AcpiDeviceIf *adev, ACPIOSTInfoList ***list);
 void (*send_event)(AcpiDeviceIf *adev, AcpiEventStatusBits ev);
 void (*madt_cpu)(AcpiDeviceIf *adev, int uid,
- CPUArchIdList *apic_ids, GArray *entry);
+ const CPUArchIdList *apic_ids, GArray *entry);
 } AcpiDeviceIfClass;
 #endif
diff --git a/include/hw/boards.h b/include/hw/boards.h
index a51da9c..ac891a8 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -135,7 +135,7 @@ struct MachineClass {
 HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
DeviceState *dev);
 unsigned (*cpu_index_to_socket_id)(unsigned cpu_index);
-CPUArchIdList *(*possible_cpu_arch_ids)(MachineState *machine);
+const CPUArchIdList *(*possible_cpu_arch_ids)(MachineState *machine);
 HotpluggableCPUList *(*query_hotpluggable_cpus)(MachineState *machine);
 };
 
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index b22e699..f4a5941 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -361,7 +361,7 @@ uint16_t pvpanic_port(void);
 
 /* acpi-build.c */
 void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
-   CPUArchIdList *apic_ids, GArray *entry);
+   const CPUArchIdList *apic_ids, GArray *entry);
 
 /* e820 types */
 #define E820_RAM1
diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
index 5ac89fe..6017ca0 100644
--- a/hw/acpi/cpu.c
+++ b/hw/acpi/cpu.c
@@ -190,7 +190,7 @@ void cpu_hotplug_hw_init(MemoryRegion *as, Object *owner,
 {
 MachineState *machine = MACHINE(qdev_get_machine());
 MachineClass *mc = MACHINE_GET_CLASS(machine);
-CPUArchIdList *id_list;
+const CPUArchIdList *id_list;
 int i;
 
 assert(mc->possible_cpu_arch_ids);
@@ -201,7 +201,6 @@ void cpu_hotplug_hw_init(MemoryRegion *as, Object *owner,
 state->devs[i].cpu =  id_list->cpus[i].cpu;
 state->devs[i].arch_id = id_list->cpus[i].arch_id;
 }
-g_free(id_list);
 memory_region_init_io(>ctrl_reg, owner, _hotplug_ops, state,
   "acpi-mem-hotplug", ACPI_CPU_HOTPLUG_REG_LEN);
 memory_region_add_subregion(as, base_addr, >ctrl_reg);
@@ -325,7 +324,7 @@ void build_cpus_aml(Aml *table, MachineState *machine, 
CPUHotplugFeatures opts,
 Aml *one = aml_int(1);
 Aml *sb_scope = aml_scope("_SB");
 MachineClass *mc = MACHINE_GET_CLASS(machine);
-CPUArchIdList *arch_ids = mc->possible_cpu_arch_ids(machine);
+const CPUArchIdList *arch_ids = mc->possible_cpu_arch_ids(machine);
 char *cphp_res_path = g_strdup_printf("%s." CPUHP_RES_DEVICE, res_root);
 Object *obj = object_resolve_path_type("", TYPE_ACPI_DEVICE_IF, NULL);
 AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_GET_CLASS(obj);
@@ -574,5 +573,4 @@ void build_cpus_aml(Aml *table, MachineState *machine, 
CPUHotplugFeatures opts,
 aml_append(table, method);
 
 g_free(cphp_res_path);
-g_free(arch_ids);
 }
diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
index f15a240..5243918 100644
--- a/hw/acpi/cpu_hotplug.c
+++ b/hw/acpi/cpu_hotplug.c
@@ -128,7 +128,7 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, MachineState 
*machine,
 Aml *zero = aml_int(0);
 Aml *one = aml_int(1);
 MachineClass *mc = MACHINE_GET_CLASS(machine);
-CPUArchIdList *apic_ids = mc->possible_cpu_arch_ids(machine);
+const CPUArchIdList *apic_ids = mc->possible_cpu_arch_ids(machine);
 PCMachineState *pcms = PC_MACHINE(machine);
 
 /*
@@ -329,8 +329,6 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, MachineState 
*machine,
 apic_idx = apic_id + 1;
 }
 aml_append(sb_scope, aml_name_decl(CPU_ON_BITMAP, pkg));
-g_free(apic_ids);
-
 aml_append(ctx, sb_scope);
 
 method = aml_method("\\_GPE._E02", 0, AML_NOTSERIALIZED);
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 0c8912f..0c91043 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -332,7 +332,7 @@ build_fadt(GArray *table_data, BIOSLinker *linker, 
AcpiPmInfo *pm,
 }
 
 void 

Re: [Qemu-devel] [PATCH v6 wave 2 2/3] hw/isa/lpc_ich9: add broadcast SMI feature

2017-01-18 Thread Igor Mammedov
On Wed, 18 Jan 2017 18:23:45 +0100
Laszlo Ersek  wrote:

> On 01/18/17 17:26, Igor Mammedov wrote:
> > On Wed, 18 Jan 2017 16:42:27 +0100
> > Laszlo Ersek  wrote:
> >   
> >> On 01/18/17 13:38, Igor Mammedov wrote:  
> >>> On Wed, 18 Jan 2017 11:23:48 +0100
> >>> Laszlo Ersek  wrote:
> >>> 
>  On 01/18/17 11:19, Laszlo Ersek wrote:
> > On 01/18/17 11:03, Igor Mammedov wrote:  
> >> On Tue, 17 Jan 2017 19:53:21 +0100
> >> Laszlo Ersek  wrote:
> >>  
> 
>  [snip]
> 
> >>> This is the code I wrote (extracting a new ich9_apm_broadcast_smi()
> >>> function from ich9_apm_ctrl_changed(), due to size reasons):
> >>>  
>  static void ich9_apm_broadcast_smi(void)
>  {
>  CPUState *cs;
> 
>  cpu_synchronize_all_states(); /* <- mark this */  
> >> it probably should be executed after pause_all_vcpus(),
> >> maybe it will help.
> >>  
>  CPU_FOREACH(cs) {
>  X86CPU *cpu = X86_CPU(cs);
>  CPUX86State *env = >env;
> 
>  if (env->smbase == 0x3 && env->eip == 0xfff0) {
>  CPUClass *k = CPU_GET_CLASS(cs);
>  uint64_t cpu_arch_id = k->get_arch_id(cs);
> 
>  trace_ich9_apm_broadcast_smi_skip(cpu_arch_id);
>  continue;
>  }
> 
>  cpu_interrupt(cs, CPU_INTERRUPT_SMI);
>  }
>  }
> >>>  
> >> [...]  
> >>> (b) If I add the cpu_synchronize_all_states() call before the loop, 
> >>> then
> >>> the incorrect filter matches go away; QEMU sees the KVM VCPU states
> >>> correctly, and the SMI is broad-cast.
> >>>
> >>> However, in this case, the boot slows to a *crawl*. It's unbearable. 
> >>> All
> >>> VCPUs are pegged at 100%, and you can easily follow the OVMF debug log
> >>> with the naked eye, almost line by line.
> >>> I didn't expect that cpu_synchronize_all_states() would be so costly,
> >>> but it makes the idea of checking VCPU state in the APM_CNT handler a
> >>> non-starter.  
> >> I wonder were bottleneck is to slow down guest so much.
> >> What is actual cost of calling cpu_synchronize_all_states()?
> >>
> >> Maybe calling pause_all_vcpus() before cpu_synchronize_all_states()
> >> would help.  
> >
> > If I prepend just a pause_all_vcpus() function call, at the top, then
> > the VM freezes (quite understandably) when the first SMI is raised via
> > APM_CNT.
> >
> > If I, instead, bracket the function body with pause_all_vcpus() and
> > resume_all_vcpus(), like this:
> >
> > static void ich9_apm_broadcast_smi(void)
> > {
> > CPUState *cs;
> >
> > pause_all_vcpus();
> > cpu_synchronize_all_states();
> > CPU_FOREACH(cs) {
> > X86CPU *cpu = X86_CPU(cs);
> > CPUX86State *env = >env;
> >
> > if (env->smbase == 0x3 && env->eip == 0xfff0) {
> > CPUClass *k = CPU_GET_CLASS(cs);
> > uint64_t cpu_arch_id = k->get_arch_id(cs);
> >
> > trace_ich9_apm_broadcast_smi_skip(cpu_arch_id);
> > continue;
> > }
> >
> > cpu_interrupt(cs, CPU_INTERRUPT_SMI);
> > }
> > resume_all_vcpus();
> > }
> >
> > then I see the following symptoms:
> > - rather than 4 VCPUs being pegged at 100%, only one VCPU is pegged at
> >   100%
> > - the boot process, as observed from the OVMF log, is just as slow
> >   (= crawling) as without the VCPU pausing/resuming (i.e., like with
> >   cpu_synchronize_all_states() only); so ultimately the
> >   pausing/resuming doesn't help.  
> 
>  I also tried this variant (bracketing only the sync call with 
>  pause/resume):
> 
>  static void ich9_apm_broadcast_smi(void)
>  {
>  CPUState *cs;
> 
>  pause_all_vcpus();
>  cpu_synchronize_all_states();
>  resume_all_vcpus();
>  CPU_FOREACH(cs) {
>  X86CPU *cpu = X86_CPU(cs);
>  CPUX86State *env = >env;
> 
>  if (env->smbase == 0x3 && env->eip == 0xfff0) {
>  CPUClass *k = CPU_GET_CLASS(cs);
>  uint64_t cpu_arch_id = k->get_arch_id(cs);
> 
>  trace_ich9_apm_broadcast_smi_skip(cpu_arch_id);
>  continue;
>  }
> 
>  cpu_interrupt(cs, CPU_INTERRUPT_SMI);
>  }
>  }
> 
>  This behaves identically to the version where pause/resume bracket the
>  entire function body (i.e., 1 VCPU pegged, super-slow boot progress).
> >>> wrapping entire function into 

[Qemu-devel] [RFC 11/13] numa: use new machine.cpu property with -numa cpus=... CLI

2017-01-18 Thread Igor Mammedov
add compat layer to legacy cpu_index based '-numa cpus=...'
CLI option, which will use new machine.cpu property to set
numa mapping if that propety is available.

This way machine that supports machine.cpu property will
not break legacy CLI but will be able to move away from
using numa_info[node_id].node_cpu bitmaps and use only
possible_cpus instead.

Signed-off-by: Igor Mammedov 
---
 numa.c | 63 ---
 1 file changed, 48 insertions(+), 15 deletions(-)

diff --git a/numa.c b/numa.c
index 887ee58..0c34130 100644
--- a/numa.c
+++ b/numa.c
@@ -141,10 +141,35 @@ uint32_t numa_get_node(ram_addr_t addr, Error **errp)
 return -1;
 }
 
-static void numa_node_parse(NumaNodeOptions *node, QemuOpts *opts, Error 
**errp)
+static void numa_cpu_set_nid(MachineState *ms, CpuInstanceProperties *props,
+ Error **errp)
+{
+Visitor *v;
+QObject *qobj;
+Error *local_error = NULL;
+
+v = qobject_output_visitor_new();
+visit_type_CpuInstanceProperties(v, "cpu", , _error);
+visit_complete(v, );
+visit_free(v);
+if (local_error) {
+goto end;
+}
+v = qobject_input_visitor_new(qobj, true);
+object_property_set(OBJECT(ms), v, "cpu", _error);
+visit_free(v);
+qobject_decref(qobj);
+end:
+error_propagate(errp, local_error);
+}
+
+static void numa_node_parse(MachineState *ms, NumaNodeOptions *node,
+QemuOpts *opts, Error **errp)
 {
 uint16_t nodenr;
 uint16List *cpus = NULL;
+MachineClass *mc = MACHINE_GET_CLASS(ms);
+bool has_cpu_prop = object_property_find(OBJECT(ms), "cpu", NULL);
 
 if (node->has_nodeid) {
 nodenr = node->nodeid;
@@ -172,6 +197,19 @@ static void numa_node_parse(NumaNodeOptions *node, 
QemuOpts *opts, Error **errp)
 return;
 }
 bitmap_set(numa_info[nodenr].node_cpu, cpus->value, 1);
+if (mc->cpu_index_to_instance_props && has_cpu_prop) {
+CpuInstanceProperties props;
+Error *local_error = NULL;
+
+props = mc->cpu_index_to_instance_props(ms, cpus->value);
+props.has_node_id = true;
+props.node_id = nodenr;
+numa_cpu_set_nid(ms, , _error);
+if (local_error) {
+error_propagate(errp, local_error);
+return;
+}
+}
 }
 
 if (node->has_mem && node->has_memdev) {
@@ -232,26 +270,14 @@ static int parse_numa(void *opaque, QemuOpts *opts, Error 
**errp)
 
 switch (object->type) {
 case NUMA_OPTIONS_KIND_NODE:
-numa_node_parse(object->u.node.data, opts, );
+numa_node_parse(ms, object->u.node.data, opts, );
 if (err) {
 goto end;
 }
 nb_numa_nodes++;
 break;
 case NUMA_OPTIONS_KIND_CPU: {
-QObject *qobj;
-
-v = qobject_output_visitor_new();
-visit_type_CpuInstanceProperties(v, "cpu", >u.cpu.data, );
-visit_complete(v, );
-visit_free(v);
-if (err) {
-goto end;
-}
-v = qobject_input_visitor_new(qobj, true);
-object_property_set(OBJECT(ms), v, "cpu", );
-visit_free(v);
-qobject_decref(qobj);
+numa_cpu_set_nid(ms, object->u.cpu.data, );
 if (err) {
 goto end;
 }
@@ -402,6 +428,8 @@ void parse_numa_opts(MachineState *ms)
  * would be on the same node.
  */
 if (i == nb_numa_nodes) {
+bool has_cpu_prop = object_property_find(OBJECT(ms), "cpu", NULL);
+
 for (i = 0; i < max_cpus; i++) {
 unsigned node_id = i % nb_numa_nodes;
 if (mc->cpu_index_to_instance_props) {
@@ -409,6 +437,11 @@ void parse_numa_opts(MachineState *ms)
 topo = mc->cpu_index_to_instance_props(ms, i);
 assert(topo.has_socket_id);
 node_id = topo.socket_id % nb_numa_nodes;
+if (has_cpu_prop) {
+topo.has_node_id = true;
+topo.node_id = node_id;
+numa_cpu_set_nid(ms, , _fatal);
+}
 }
 
 set_bit(i, numa_info[node_id].node_cpu);
-- 
2.7.4




Re: [Qemu-devel] [RFC 01/13] numa: access CPU's node id via property in hmp_info_numa()

2017-01-18 Thread Eduardo Habkost
On Wed, Jan 18, 2017 at 06:13:17PM +0100, Igor Mammedov wrote:
> Move vcpu's assocciated numa_node field out of generic CPUState
> into inherited classes that actually care about cpu<->numa mapping
> and make monitor 'info numa' get vcpu's assocciated node id via
> node-id property.
> It allows to drop implicit node id intialization in
> numa_post_machine_init() and would allow switching to mapping
> defined by target's CpuInstanceProperties instead of global
> numa_info[i].node_cpu bitmaps.
> 
> As side effect it fixes 'info numa' displaying wrong mapping
> for CPUs specified with -device/device_add.
> Before patch following CLI would produce:
> QEMU -smp 1,sockets=3,maxcpus=3 \
>-device qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0 \
>-numa node,nodeid=0,cpus=0 \
>-numa node,nodeid=1,cpus=1 \
>-numa node,nodeid=2,cpus=2
> (qemu) device_add qemu64-x86_64-cpu,socket-id=2,core-id=0,thread-id=0
> (qemu) info numa
> 3 nodes
> node 0 cpus: 0 1 2
> node 0 size: 40 MB
> node 1 cpus:
> node 1 size: 40 MB
> node 2 cpus:
> node 2 size: 48 MB
> 
> after patch all CPUs are on nodes they are supposed to be:
> (qemu) device_add qemu64-x86_64-cpu,socket-id=2,core-id=0,thread-id=0
> (qemu) info numa
> 3 nodes
> node 0 cpus: 0
> node 0 size: 40 MB
> node 1 cpus: 1
> node 1 size: 40 MB
> node 2 cpus: 2
> node 2 size: 48 MB
> 
> Signed-off-by: Igor Mammedov 

So, in addition to the other comments I had, it looks like this
patch is doing 3 things at the same time:

1) Adding a "node-id" property to CPU objects.
2) Moving CPUState::numa_node to arch-specific CPU structs.
3) Fixing the bug where the NUMA node info isn't initialized
   for PC on CPUs created by -device/device_add.

All of them are independent from each other. For example, all you
need to fix the bug you describe above is (3), which is contained
in a single hunk from this patch, that is:

> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index f721fde..9d2b265 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1978,6 +1978,11 @@ static void pc_cpu_pre_plug(HotplugHandler 
> *hotplug_dev,
>  
>  cs = CPU(cpu);
>  cs->cpu_index = idx;
> +
> +idx = numa_get_node_for_cpu(cs->cpu_index);
> +if (idx < nb_numa_nodes) {
> +cpu->numa_nid = idx;
> +}
>  }

All the rest seems irrelevant to fix the bug. (1) and (2) may be
useful, but they need separate justification.

-- 
Eduardo



Re: [Qemu-devel] [RFC 08/13] pc: add writeonly 'cpu' property to PCMachine

2017-01-18 Thread Eduardo Habkost
On Wed, Jan 18, 2017 at 06:13:24PM +0100, Igor Mammedov wrote:
> it will allow generic numa code to set cpu to numa node mapping
> in target independent manner in the next patch.
> 
> Signed-off-by: Igor Mammedov 
> ---
>  hw/i386/pc.c | 56 
>  1 file changed, 56 insertions(+)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index f8ea635..1d33a5e 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -2201,6 +2201,56 @@ static void pc_machine_set_pit(Object *obj, bool 
> value, Error **errp)
>  pcms->pit = value;
>  }
>  
> +static void pc_machine_set_cpu(Object *obj, Visitor *v, const char *name,
> +   void *opaque, Error **errp)
> +{
> +uint32_t apic_id;
> +X86CPUTopoInfo topo;
> +CPUArchId *cpu_slot;
> +Error *local_err = NULL;
> +CpuInstanceProperties *cpu_props = NULL;
> +PCMachineState *pcms = PC_MACHINE(obj);
> +MachineClass *mc = MACHINE_GET_CLASS(obj);
> +
> +visit_type_CpuInstanceProperties(v, name, _props, _err);
> +if (local_err) {
> +goto out;
> +}
> +
> +if (!cpu_props->has_node_id) {
> +error_setg(_err, "node-id property is not specified");
> +goto out;
> +}
> +
> +/*
> + * make sure that possible_cpus is initialized
> + * as property setter might be called before machine init is called
> + */
> +mc->possible_cpu_arch_ids(MACHINE(obj));
> +
> +topo.pkg_id = cpu_props->socket_id;
> +topo.core_id = cpu_props->core_id;
> +topo.smt_id = cpu_props->thread_id;
> +apic_id = apicid_from_topo_ids(smp_cores, smp_threads, );
> +cpu_slot = pc_find_cpu_slot(pcms, apic_id, NULL);

If we make TYPE_MACHINE provide an API to query CPU slots, e.g.:
  CPUArchId *machine_find_cpu_slot(MachineState *m, CpuInstanceProperties 
*props)
  CPUArchId *machine_slot_for_cpu(MachineState *m, CPUState *cpu)

(Which can probably be implemented using
MachineClass::possible_cpu_arch_ids(), already)

Then this function could be implemented in a generic way, and all
existing calls of:
  numa_get_node_for_cpu(cpu->cpu_index)
could be easily replaced by:
  machine_slot_for_cpu(cpu)->props.node_id

This should make it easier to get rid numa_info[].node_cpu.

> +if (!cpu_slot) {
> +error_setg(_err, "unable to find CPU");
> +goto out;
> +}
> +
> +if (cpu_slot->props.has_node_id) {
> +error_setg(_err, "CPU has already been assigned to node: 
> %"PRId64,
> +   cpu_slot->props.node_id);
> +goto out;
> +}
> +cpu_slot->props.has_node_id = true;
> +cpu_slot->props.node_id = cpu_props->node_id;
> +
> + out:
> +error_propagate(errp, local_err);
> +qapi_free_CpuInstanceProperties(cpu_props);
> +}
> +
>  static void pc_machine_initfn(Object *obj)
>  {
>  PCMachineState *pcms = PC_MACHINE(obj);
> @@ -2395,6 +2445,12 @@ static void pc_machine_class_init(ObjectClass *oc, 
> void *data)
>  
>  object_class_property_add_bool(oc, PC_MACHINE_PIT,
>  pc_machine_get_pit, pc_machine_set_pit, _abort);
> +
> +object_class_property_add(oc, "cpu", "CpuInstanceProperties",
> +NULL, pc_machine_set_cpu,
> +NULL, NULL, _abort);
> +object_class_property_set_description(oc, "cpu",
> +"Possible cpu placement", _abort);
>  }
>  
>  static const TypeInfo pc_machine_info = {
> -- 
> 2.7.4
> 

-- 
Eduardo



[Qemu-devel] [PATCH v2 2/4] compiler: drop ; after BUILD_BUG_ON

2017-01-18 Thread Michael S. Tsirkin
All users include the trailing ;, let's require that
so that uses such as if (a) QEMU_BUILD_BUG_ON(); do not
produce unexpected results.

Not a huge problem for QEMU since our style requires the use
of {} but seems cleaner nevertheless.

Signed-off-by: Michael S. Tsirkin 
---
 include/qemu/compiler.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index 157698b..2882470 100644
--- a/include/qemu/compiler.h
+++ b/include/qemu/compiler.h
@@ -86,7 +86,8 @@
 #define type_check(t1,t2) ((t1*)0 - (t2*)0)
 
 #define QEMU_BUILD_BUG_ON(x) \
-typedef char glue(qemu_build_bug_on__,__LINE__)[(x)?-1:1] 
__attribute__((unused));
+typedef char glue(qemu_build_bug_on__,__LINE__)[(x) ? -1 : 1] \
+__attribute__((unused))
 
 #if defined __GNUC__
 # if !QEMU_GNUC_PREREQ(4, 4)
-- 
MST




[Qemu-devel] [PATCH v2 4/4] ARRAY_SIZE: check that argument is an array

2017-01-18 Thread Michael S. Tsirkin
It's a familiar pattern: some code uses ARRAY_SIZE, then refactoring
changes the argument from an array to a pointer to a dynamically
allocated buffer.  Code keeps compiling but any ARRAY_SIZE calls now
return the size of the pointer divided by element size.

Let's add build time checks to ARRAY_SIZE before we allow more
of these in the code-base.

Signed-off-by: Michael S. Tsirkin 
---
 include/qemu/osdep.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index 689f253..24bfda0 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -199,7 +199,13 @@ extern int daemon(int, int);
 #endif
 
 #ifndef ARRAY_SIZE
-#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+/*
+ * &(x)[0] is always a pointer - if it's same type as x then the argument is a
+ * pointer, not an array as expected.
+ */
+#define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + QEMU_BUILD_BUG_ON_ZERO( \
+__builtin_types_compatible_p(typeof(x), \
+ typeof(&(x)[0]
 #endif
 
 int qemu_daemon(int nochdir, int noclose);
-- 
MST




[Qemu-devel] [PATCH 0/7] target-m68k: implement 680x0 FPU

2017-01-18 Thread Laurent Vivier
This series modifies the original ColdFire FPU implementation
to use floatx80 instead of float64 internally as this
is the native datatype for 680x0. I didn't keep the float64
type for ColdFire, but if someone thinks it's required I
can update this series in this way.

The series also adds the FPU status and control registers and
several floating point instructions.

The floatx80 datatype used here is not exactly the same as the
one used by 680x0 for its extended precision data type, because
normally the signaling bit of 680x0 NAN is the MSB of the mantissa
minus one and in floatx80 it is the MSB.

We also add the gdb server parts to read the new FPU registers.
A strange thing happens here: while the gdb client running remotely
from a debian etch-m68k has no issue working with 96bit FPU registers
(the 680x0 extended precision data type), new gdbs (from a debian unstable
and gdb for cross-compiled environment) don't expect this FPU registers
size. But it seems like a bug in gdb, not in this implementation.

After this series is applied, qemu-m68k can run a debian etch-m68k
or a debian unstable chroot.

Laurent Vivier (7):
  target-m68k: move FPU helpers to fpu_helper.c
  target-m68k: define ext_opsize
  softfloat: define 680x0 specific values
  target-m68k: use floatx80 internally
  target-m68k: add fmovem
  target-m68k: introduce fscc.
  target-m68k: implements more FPU instructions

 configure  |2 +-
 fpu/softfloat-specialize.h |   30 +-
 gdb-xml/m68k-fp.xml|   21 +
 target/m68k/Makefile.objs  |2 +-
 target/m68k/cpu.c  |   13 +-
 target/m68k/cpu.h  |   75 ++-
 target/m68k/fpu_helper.c   |  765 +++
 target/m68k/helper.c   |  165 +++---
 target/m68k/helper.h   |   57 +-
 target/m68k/qregs.def  |4 +-
 target/m68k/translate.c| 1244 
 11 files changed, 1930 insertions(+), 448 deletions(-)
 create mode 100644 gdb-xml/m68k-fp.xml
 create mode 100644 target/m68k/fpu_helper.c

-- 
2.7.4




Re: [Qemu-devel] [PATCH v2 2/4] compiler: drop ; after BUILD_BUG_ON

2017-01-18 Thread Peter Maydell
On 18 January 2017 at 20:55, Michael S. Tsirkin  wrote:
> All users include the trailing ;, let's require that
> so that uses such as if (a) QEMU_BUILD_BUG_ON(); do not
> produce unexpected results.

When would it ever make sense for a build-time
assert to be the only thing inside a runtime
conditional anyway?

thanks
-- PMM



[Qemu-devel] [PATCH 1/7] target-m68k: move FPU helpers to fpu_helper.c

2017-01-18 Thread Laurent Vivier
Signed-off-by: Laurent Vivier 
---
 target/m68k/Makefile.objs |   2 +-
 target/m68k/fpu_helper.c  | 112 ++
 target/m68k/helper.c  |  88 
 3 files changed, 113 insertions(+), 89 deletions(-)
 create mode 100644 target/m68k/fpu_helper.c

diff --git a/target/m68k/Makefile.objs b/target/m68k/Makefile.objs
index 02cf616..39141ab 100644
--- a/target/m68k/Makefile.objs
+++ b/target/m68k/Makefile.objs
@@ -1,3 +1,3 @@
 obj-y += m68k-semi.o
-obj-y += translate.o op_helper.o helper.o cpu.o
+obj-y += translate.o op_helper.o helper.o cpu.o fpu_helper.o
 obj-y += gdbstub.o
diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
new file mode 100644
index 000..5bf2576
--- /dev/null
+++ b/target/m68k/fpu_helper.c
@@ -0,0 +1,112 @@
+/*
+ *  m68k FPU helpers
+ *
+ *  Copyright (c) 2006-2007 CodeSourcery
+ *  Written by Paul Brook
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "cpu.h"
+#include "exec/helper-proto.h"
+
+uint32_t HELPER(f64_to_i32)(CPUM68KState *env, float64 val)
+{
+return float64_to_int32(val, >fp_status);
+}
+
+float32 HELPER(f64_to_f32)(CPUM68KState *env, float64 val)
+{
+return float64_to_float32(val, >fp_status);
+}
+
+float64 HELPER(i32_to_f64)(CPUM68KState *env, uint32_t val)
+{
+return int32_to_float64(val, >fp_status);
+}
+
+float64 HELPER(f32_to_f64)(CPUM68KState *env, float32 val)
+{
+return float32_to_float64(val, >fp_status);
+}
+
+float64 HELPER(iround_f64)(CPUM68KState *env, float64 val)
+{
+return float64_round_to_int(val, >fp_status);
+}
+
+float64 HELPER(itrunc_f64)(CPUM68KState *env, float64 val)
+{
+return float64_trunc_to_int(val, >fp_status);
+}
+
+float64 HELPER(sqrt_f64)(CPUM68KState *env, float64 val)
+{
+return float64_sqrt(val, >fp_status);
+}
+
+float64 HELPER(abs_f64)(float64 val)
+{
+return float64_abs(val);
+}
+
+float64 HELPER(chs_f64)(float64 val)
+{
+return float64_chs(val);
+}
+
+float64 HELPER(add_f64)(CPUM68KState *env, float64 a, float64 b)
+{
+return float64_add(a, b, >fp_status);
+}
+
+float64 HELPER(sub_f64)(CPUM68KState *env, float64 a, float64 b)
+{
+return float64_sub(a, b, >fp_status);
+}
+
+float64 HELPER(mul_f64)(CPUM68KState *env, float64 a, float64 b)
+{
+return float64_mul(a, b, >fp_status);
+}
+
+float64 HELPER(div_f64)(CPUM68KState *env, float64 a, float64 b)
+{
+return float64_div(a, b, >fp_status);
+}
+
+float64 HELPER(sub_cmp_f64)(CPUM68KState *env, float64 a, float64 b)
+{
+/* ??? This may incorrectly raise exceptions.  */
+/* ??? Should flush denormals to zero.  */
+float64 res;
+res = float64_sub(a, b, >fp_status);
+if (float64_is_quiet_nan(res, >fp_status)) {
+/* +/-inf compares equal against itself, but sub returns nan.  */
+if (!float64_is_quiet_nan(a, >fp_status)
+&& !float64_is_quiet_nan(b, >fp_status)) {
+res = float64_zero;
+if (float64_lt_quiet(a, res, >fp_status)) {
+res = float64_chs(res);
+}
+}
+}
+return res;
+}
+
+uint32_t HELPER(compare_f64)(CPUM68KState *env, float64 val)
+{
+return float64_compare_quiet(val, float64_zero, >fp_status);
+}
diff --git a/target/m68k/helper.c b/target/m68k/helper.c
index f750d3d..5ca9911 100644
--- a/target/m68k/helper.c
+++ b/target/m68k/helper.c
@@ -284,94 +284,6 @@ void HELPER(set_sr)(CPUM68KState *env, uint32_t val)
 m68k_switch_sp(env);
 }
 
-/* FPU helpers.  */
-uint32_t HELPER(f64_to_i32)(CPUM68KState *env, float64 val)
-{
-return float64_to_int32(val, >fp_status);
-}
-
-float32 HELPER(f64_to_f32)(CPUM68KState *env, float64 val)
-{
-return float64_to_float32(val, >fp_status);
-}
-
-float64 HELPER(i32_to_f64)(CPUM68KState *env, uint32_t val)
-{
-return int32_to_float64(val, >fp_status);
-}
-
-float64 HELPER(f32_to_f64)(CPUM68KState *env, float32 val)
-{
-return float32_to_float64(val, >fp_status);
-}
-
-float64 HELPER(iround_f64)(CPUM68KState *env, float64 val)
-{
-return float64_round_to_int(val, >fp_status);
-}
-
-float64 HELPER(itrunc_f64)(CPUM68KState *env, float64 val)
-{
-return float64_trunc_to_int(val, >fp_status);
-}
-
-float64 HELPER(sqrt_f64)(CPUM68KState *env, float64 val)
-{
-return float64_sqrt(val, >fp_status);
-}
-

[Qemu-devel] [PATCH 6/7] target-m68k: introduce fscc.

2017-01-18 Thread Laurent Vivier
use DisasCompare with FPU conditions in fscc and fbcc.

Signed-off-by: Laurent Vivier 
---
 target/m68k/translate.c | 228 
 1 file changed, 153 insertions(+), 75 deletions(-)

diff --git a/target/m68k/translate.c b/target/m68k/translate.c
index 49c0b06..3d55f0e 100644
--- a/target/m68k/translate.c
+++ b/target/m68k/translate.c
@@ -4654,139 +4654,215 @@ undef:
 disas_undef_fpu(env, s, insn);
 }
 
-DISAS_INSN(fbcc)
+static void gen_fcc_cond(DisasCompare *c, DisasContext *s, int cond)
 {
-uint32_t offset;
-uint32_t addr;
-TCGLabel *l1;
-TCGv tmp;
-
-addr = s->pc;
-offset = cpu_ldsw_code(env, s->pc);
-s->pc += 2;
-if (insn & (1 << 6)) {
-offset = (offset << 16) | read_im16(env, s);
-}
-
-l1 = gen_new_label();
+c->g1 = 0;
+c->v2 = tcg_const_i32(0);
+c->g2 = 1;
 /* TODO: Raise BSUN exception.  */
-/* Jump to l1 if condition is true.  */
-switch (insn & 0xf)  {
+switch (cond) {
 case 0:  /* False */
 case 16: /* Signaling false */
+c->v1 = c->v2;
+c->tcond = TCG_COND_NEVER;
 break;
 case 1:  /* Equal Z */
 case 17: /* Signaling Equal Z */
-tmp = tcg_temp_new();
-tcg_gen_andi_i32(tmp, QREG_FPSR, FPSR_CC_Z);
-tcg_gen_brcondi_i32(TCG_COND_NE, tmp, 0, l1);
+c->v1 = tcg_temp_new();
+c->g1 = 1;
+tcg_gen_andi_i32(c->v1, QREG_FPSR, FPSR_CC_Z);
+c->tcond = TCG_COND_NE;
 break;
 case 2: /* Ordered Greater Than !(A || Z || N) */
 case 18:
-tmp = tcg_temp_new();
-tcg_gen_andi_i32(tmp, QREG_FPSR,
+c->v1 = tcg_temp_new();
+c->g1 = 1;
+tcg_gen_andi_i32(c->v1, QREG_FPSR,
  FPSR_CC_A | FPSR_CC_Z | FPSR_CC_N);
-tcg_gen_brcondi_i32(TCG_COND_EQ, tmp, 0, l1);
+c->tcond = TCG_COND_EQ;
 break;
 case 3: /* Ordered Greater Than or Equal Z || !(A || N) */
 case 19:
 assert(FPSR_CC_A == (FPSR_CC_N >> 3));
-tmp = tcg_temp_new();
-tcg_gen_shli_i32(tmp, QREG_FPSR, 3);
-tcg_gen_or_i32(tmp, tmp, QREG_FPSR);
-tcg_gen_xori_i32(tmp, tmp, FPSR_CC_N);
-tcg_gen_andi_i32(tmp, tmp, FPSR_CC_N | FPSR_CC_Z);
-tcg_gen_brcondi_i32(TCG_COND_NE, tmp, 0, l1);
+c->v1 = tcg_temp_new();
+c->g1 = 1;
+tcg_gen_shli_i32(c->v1, QREG_FPSR, 3);
+tcg_gen_or_i32(c->v1, c->v1, QREG_FPSR);
+tcg_gen_xori_i32(c->v1, c->v1, FPSR_CC_N);
+tcg_gen_andi_i32(c->v1, c->v1, FPSR_CC_N | FPSR_CC_Z);
+c->tcond = TCG_COND_NE;
 break;
 case 4: /* Ordered Less Than !(!N || A || Z); */
 case 20:
-tmp = tcg_temp_new();
-tcg_gen_xori_i32(tmp, QREG_FPSR, FPSR_CC_N);
-tcg_gen_andi_i32(tmp, tmp, FPSR_CC_N | FPSR_CC_A | FPSR_CC_Z);
-tcg_gen_brcondi_i32(TCG_COND_EQ, tmp, 0, l1);
+c->v1 = tcg_temp_new();
+c->g1 = 1;
+tcg_gen_xori_i32(c->v1, QREG_FPSR, FPSR_CC_N);
+tcg_gen_andi_i32(c->v1, c->v1, FPSR_CC_N | FPSR_CC_A | FPSR_CC_Z);
+c->tcond = TCG_COND_EQ;
 break;
 case 5: /* Ordered Less Than or Equal Z || (N && !A) */
 case 21:
 assert(FPSR_CC_A == (FPSR_CC_N >> 3));
-tmp = tcg_temp_new();
-tcg_gen_xori_i32(tmp, QREG_FPSR, FPSR_CC_A);
-tcg_gen_shli_i32(tmp, tmp, 3);
-tcg_gen_ori_i32(tmp, tmp, FPSR_CC_Z);
-tcg_gen_and_i32(tmp, tmp, QREG_FPSR);
-tcg_gen_brcondi_i32(TCG_COND_NE, tmp, 0, l1);
+c->v1 = tcg_temp_new();
+c->g1 = 1;
+tcg_gen_xori_i32(c->v1, QREG_FPSR, FPSR_CC_A);
+tcg_gen_shli_i32(c->v1, c->v1, 3);
+tcg_gen_ori_i32(c->v1, c->v1, FPSR_CC_Z);
+tcg_gen_and_i32(c->v1, c->v1, QREG_FPSR);
+c->tcond = TCG_COND_NE;
 break;
 case 6: /* Ordered Greater or Less Than !(A || Z) */
 case 22:
-tmp = tcg_temp_new();
-tcg_gen_andi_i32(tmp, QREG_FPSR, FPSR_CC_A | FPSR_CC_Z);
-tcg_gen_brcondi_i32(TCG_COND_EQ, tmp, 0, l1);
+c->v1 = tcg_temp_new();
+c->g1 = 1;
+tcg_gen_andi_i32(c->v1, QREG_FPSR, FPSR_CC_A | FPSR_CC_Z);
+c->tcond = TCG_COND_EQ;
 break;
 case 7: /* Ordered !A */
 case 23:
-tmp = tcg_temp_new();
-tcg_gen_andi_i32(tmp, QREG_FPSR, FPSR_CC_A);
-tcg_gen_brcondi_i32(TCG_COND_EQ, tmp, 0, l1);
+c->v1 = tcg_temp_new();
+c->g1 = 1;
+tcg_gen_andi_i32(c->v1, QREG_FPSR, FPSR_CC_A);
+c->tcond = TCG_COND_EQ;
 break;
 case 8: /* Unordered A */
 case 24:
-tmp = tcg_temp_new();
-tcg_gen_andi_i32(tmp, QREG_FPSR, FPSR_CC_A);
-tcg_gen_brcondi_i32(TCG_COND_NE, tmp, 0, l1);
+c->v1 = tcg_temp_new();
+c->g1 = 1;
+tcg_gen_andi_i32(c->v1, QREG_FPSR, FPSR_CC_A);
+c->tcond = TCG_COND_NE;
 break;
 case 9: /* Unordered or Equal A 

[Qemu-devel] [PATCH 2/7] target-m68k: define ext_opsize

2017-01-18 Thread Laurent Vivier
Signed-off-by: Laurent Vivier 
---
 target/m68k/translate.c | 43 ---
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/target/m68k/translate.c b/target/m68k/translate.c
index 9f60fbc..d9ba735 100644
--- a/target/m68k/translate.c
+++ b/target/m68k/translate.c
@@ -669,6 +669,21 @@ static inline int insn_opsize(int insn)
 }
 }
 
+static inline int ext_opsize(int ext, int pos)
+{
+switch ((ext >> pos) & 7) {
+case 0: return OS_LONG;
+case 1: return OS_SINGLE;
+case 2: return OS_EXTENDED;
+case 3: return OS_PACKED;
+case 4: return OS_WORD;
+case 5: return OS_DOUBLE;
+case 6: return OS_BYTE;
+default:
+g_assert_not_reached();
+}
+}
+
 /* Assign value to a register.  If the width is less than the register width
only the low part of the register is set.  */
 static void gen_partset_reg(int opsize, TCGv reg, TCGv val)
@@ -4101,20 +4116,19 @@ DISAS_INSN(fpu)
 tmp32 = tcg_temp_new_i32();
 /* fmove */
 /* ??? TODO: Proper behavior on overflow.  */
-switch ((ext >> 10) & 7) {
-case 0:
-opsize = OS_LONG;
+
+opsize = ext_opsize(ext, 10);
+switch (opsize) {
+case OS_LONG:
 gen_helper_f64_to_i32(tmp32, cpu_env, src);
 break;
-case 1:
-opsize = OS_SINGLE;
+case OS_SINGLE:
 gen_helper_f64_to_f32(tmp32, cpu_env, src);
 break;
-case 4:
-opsize = OS_WORD;
+case OS_WORD:
 gen_helper_f64_to_i32(tmp32, cpu_env, src);
 break;
-case 5: /* OS_DOUBLE */
+case OS_DOUBLE:
 tcg_gen_mov_i32(tmp32, AREG(insn, 0));
 switch ((insn >> 3) & 7) {
 case 2:
@@ -4143,8 +4157,7 @@ DISAS_INSN(fpu)
 }
 tcg_temp_free_i32(tmp32);
 return;
-case 6:
-opsize = OS_BYTE;
+case OS_BYTE:
 gen_helper_f64_to_i32(tmp32, cpu_env, src);
 break;
 default:
@@ -4217,15 +4230,7 @@ DISAS_INSN(fpu)
 }
 if (ext & (1 << 14)) {
 /* Source effective address.  */
-switch ((ext >> 10) & 7) {
-case 0: opsize = OS_LONG; break;
-case 1: opsize = OS_SINGLE; break;
-case 4: opsize = OS_WORD; break;
-case 5: opsize = OS_DOUBLE; break;
-case 6: opsize = OS_BYTE; break;
-default:
-goto undef;
-}
+opsize = ext_opsize(ext, 10);
 if (opsize == OS_DOUBLE) {
 tmp32 = tcg_temp_new_i32();
 tcg_gen_mov_i32(tmp32, AREG(insn, 0));
-- 
2.7.4




[Qemu-devel] [PATCH 3/7] softfloat: define 680x0 specific values

2017-01-18 Thread Laurent Vivier
Signed-off-by: Laurent Vivier 
---
 fpu/softfloat-specialize.h | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/fpu/softfloat-specialize.h b/fpu/softfloat-specialize.h
index f5aed72..8bd3fa9 100644
--- a/fpu/softfloat-specialize.h
+++ b/fpu/softfloat-specialize.h
@@ -111,7 +111,7 @@ float16 float16_default_nan(float_status *status)
 **/
 float32 float32_default_nan(float_status *status)
 {
-#if defined(TARGET_SPARC)
+#if defined(TARGET_SPARC) || defined(TARGET_M68K)
 return const_float32(0x7FFF);
 #elif defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_ALPHA) || \
   defined(TARGET_XTENSA) || defined(TARGET_S390X) || 
defined(TARGET_TRICORE)
@@ -134,7 +134,7 @@ float32 float32_default_nan(float_status *status)
 **/
 float64 float64_default_nan(float_status *status)
 {
-#if defined(TARGET_SPARC)
+#if defined(TARGET_SPARC) || defined(TARGET_M68K)
 return const_float64(LIT64(0x7FFF));
 #elif defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_ALPHA) || \
   defined(TARGET_S390X)
@@ -158,7 +158,10 @@ float64 float64_default_nan(float_status *status)
 floatx80 floatx80_default_nan(float_status *status)
 {
 floatx80 r;
-
+#if defined(TARGET_M68K)
+r.low = LIT64(0x);
+r.high = 0x7FFF;
+#else
 if (status->snan_bit_is_one) {
 r.low = LIT64(0xBFFF);
 r.high = 0x7FFF;
@@ -166,6 +169,7 @@ floatx80 floatx80_default_nan(float_status *status)
 r.low = LIT64(0xC000);
 r.high = 0x;
 }
+#endif
 return r;
 }
 
@@ -491,6 +495,26 @@ static int pickNaN(flag aIsQNaN, flag aIsSNaN, flag 
bIsQNaN, flag bIsSNaN,
 return 1;
 }
 }
+#elif defined(TARGET_M68K)
+static int pickNaN(flag aIsQNaN, flag aIsSNaN, flag bIsQNaN, flag bIsSNaN,
+   flag aIsLargerSignificand)
+{
+/* If either operand, but not both operands, of an operation is a
+ * nonsignaling NAN, then that NAN is returned as the result. If both
+ * operands are nonsignaling NANs, then the destination operand
+ * nonsignaling NAN is returned as the result.
+ */
+
+if (aIsSNaN) {
+return 0;
+} else if (bIsSNaN) {
+return 1;
+} else if (bIsQNaN) {
+return 1;
+} else {
+return 0;
+}
+}
 #else
 static int pickNaN(flag aIsQNaN, flag aIsSNaN, flag bIsQNaN, flag bIsSNaN,
 flag aIsLargerSignificand)
-- 
2.7.4




[Qemu-devel] [PATCH 7/7] target-m68k: implements more FPU instructions

2017-01-18 Thread Laurent Vivier
Add fmovecr, fsinh, flognp1, ftanh, fatan, fasin, fatanh,
fsin, ftan, fetox, ftwotox, ftentox, flogn, flog10, facos,
fcos, fgetexp, fgetman, fmod, fsgldiv, fscale, fsglmul, sin,
cos, frestore, fsave.

Signed-off-by: Laurent Vivier 
---
 target/m68k/cpu.h|   1 +
 target/m68k/fpu_helper.c | 348 +++
 target/m68k/helper.h |  22 +++
 target/m68k/translate.c  |  97 -
 4 files changed, 467 insertions(+), 1 deletion(-)

diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index b2d06f5..e48fd24 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -250,6 +250,7 @@ typedef enum {
 /* Quotient */
 
 #define FPSR_QT_MASK  0x00ff
+#define FPSR_QT_SHIFT 16
 
 /* Floating-Point Control Register */
 /* Rounding mode */
diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
index 126535f..3bb531b 100644
--- a/target/m68k/fpu_helper.c
+++ b/target/m68k/fpu_helper.c
@@ -25,6 +25,31 @@
 #include "exec/exec-all.h"
 #include 
 
+static const floatx80 fpu_rom[128] = {
+[0x00] = floatx80_pi,   /* Pi */
+[0x0b] = make_floatx80(0x3ffd, 0x9a209a84fbcff798ULL),  /* Log10(2) */
+[0x0c] = make_floatx80(0x4000, 0xadf85458a2bb4a9aULL),  /* e*/
+[0x0d] = make_floatx80(0x3fff, 0xb8aa3b295c17f0bcULL),  /* Log2(e)  */
+[0x0e] = make_floatx80(0x3ffd, 0xde5bd8a937287195ULL),  /* Log10(e) */
+[0x0f] = floatx80_zero, /* Zero */
+[0x30] = floatx80_ln2,  /* ln(2)*/
+[0x31] = make_floatx80(0x4000, 0x935d8dddaaa8ac17ULL),  /* ln(10)   */
+[0x32] = floatx80_one,  /* 10^0 */
+[0x33] = make_floatx80(0x4002, 0xa000ULL),  /* 10^1 */
+[0x34] = make_floatx80(0x4005, 0xc800ULL),  /* 10^2 */
+[0x35] = make_floatx80(0x400c, 0x9c40ULL),  /* 10^4 */
+[0x36] = make_floatx80(0x4019, 0xbebc2000ULL),  /* 10^8 */
+[0x37] = make_floatx80(0x4034, 0x8e1bc9bf0400ULL),  /* 10^16*/
+[0x38] = make_floatx80(0x4069, 0x9dc5ada82b70b59eULL),  /* 10^32*/
+[0x39] = make_floatx80(0x40d3, 0xc2781f49ffcfa6d5ULL),  /* 10^64*/
+[0x3a] = make_floatx80(0x41a8, 0x93ba47c980e98ce0ULL),  /* 10^128   */
+[0x3b] = make_floatx80(0x4351, 0xaa7eebfb9df9de8eULL),  /* 10^256   */
+[0x3c] = make_floatx80(0x46a3, 0xe319a0aea60e91c7ULL),  /* 10^512   */
+[0x3d] = make_floatx80(0x4d48, 0xc976758681750c17ULL),  /* 10^1024  */
+[0x3e] = make_floatx80(0x5a92, 0x9e8b3b5dc53d5de5ULL),  /* 10^2048  */
+[0x3f] = make_floatx80(0x7525, 0xc46052028a20979bULL),  /* 10^4096  */
+};
+
 static floatx80 FP0_to_floatx80(CPUM68KState *env)
 {
 return (floatx80){ .low = env->fp0l, .high = env->fp0h };
@@ -70,6 +95,12 @@ static floatx80 FP1_to_floatx80(CPUM68KState *env)
 return (floatx80){ .low = env->fp1l, .high = env->fp1h };
 }
 
+static void floatx80_to_FP1(CPUM68KState *env, floatx80 res)
+{
+env->fp1l = res.low;
+env->fp1h = res.high;
+}
+
 void HELPER(exts32_FP0)(CPUM68KState *env)
 {
 floatx80 res;
@@ -415,3 +446,320 @@ void HELPER(fmovem)(CPUM68KState *env, uint32_t opsize,
 {
 fprintf(stderr, "MISSING HELPER fmovem\n");
 }
+
+void HELPER(const_FP0)(CPUM68KState *env, uint32_t offset)
+{
+env->fp0l = fpu_rom[offset].low;
+env->fp0h = fpu_rom[offset].high;
+}
+
+static long double floatx80_to_ldouble(floatx80 val)
+{
+if (floatx80_is_infinity(val)) {
+if (floatx80_is_neg(val)) {
+return -__builtin_infl();
+}
+return __builtin_infl();
+}
+if (floatx80_is_any_nan(val)) {
+char low[20];
+sprintf(low, "0x%016"PRIx64, val.low);
+
+return nanl(low);
+}
+
+return *(long double *)
+}
+
+static floatx80 ldouble_to_floatx80(long double val)
+{
+floatx80 res;
+
+if (isinf(val)) {
+res.high = floatx80_default_nan(NULL).high;
+res.low = 0;
+}
+if (isinf(val) < 0) {
+res.high |= 0x8000;
+}
+if (isnan(val)) {
+res.high = floatx80_default_nan(NULL).high;
+res.low = *(uint64_t *)((char *) + 4);
+}
+return *(floatx80 *)
+}
+
+void HELPER(sinh_FP0)(CPUM68KState *env)
+{
+floatx80 res;
+long double val;
+
+val = sinhl(floatx80_to_ldouble(FP0_to_floatx80(env)));
+res = ldouble_to_floatx80(val);
+
+floatx80_to_FP0(env, res);
+}
+
+void HELPER(lognp1_FP0)(CPUM68KState *env)
+{
+floatx80 val;
+long double res;
+
+val = FP0_to_floatx80(env);
+res = logl(floatx80_to_ldouble(val) + 1.0);
+
+floatx80_to_FP0(env, ldouble_to_floatx80(res));
+}
+
+void HELPER(ln_FP0)(CPUM68KState *env)
+{
+floatx80 val;
+long double res;
+
+val = FP0_to_floatx80(env);
+res = logl(floatx80_to_ldouble(val));
+
+floatx80_to_FP0(env, ldouble_to_floatx80(res));

[Qemu-devel] [PATCH 5/7] target-m68k: add fmovem

2017-01-18 Thread Laurent Vivier
Signed-off-by: Laurent Vivier 
---
 target/m68k/fpu_helper.c |  6 +++
 target/m68k/helper.h |  1 +
 target/m68k/translate.c  | 99 +++-
 3 files changed, 80 insertions(+), 26 deletions(-)

diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
index b308364..126535f 100644
--- a/target/m68k/fpu_helper.c
+++ b/target/m68k/fpu_helper.c
@@ -409,3 +409,9 @@ void HELPER(update_fpstatus)(CPUM68KState *env)
 
 set_float_exception_flags(flags, >fp_status);
 }
+
+void HELPER(fmovem)(CPUM68KState *env, uint32_t opsize,
+uint32_t mode, uint32_t mask)
+{
+fprintf(stderr, "MISSING HELPER fmovem\n");
+}
diff --git a/target/m68k/helper.h b/target/m68k/helper.h
index 072a6d0..58bc273 100644
--- a/target/m68k/helper.h
+++ b/target/m68k/helper.h
@@ -31,6 +31,7 @@ DEF_HELPER_1(cmp_FP0_FP1, void, env)
 DEF_HELPER_2(set_fpcr, void, env, i32)
 DEF_HELPER_1(tst_FP0, void, env)
 DEF_HELPER_1(update_fpstatus, void, env)
+DEF_HELPER_4(fmovem, void, env, i32, i32, i32)
 
 DEF_HELPER_3(mac_move, void, env, i32, i32)
 DEF_HELPER_3(macmulf, i64, env, i32, i32)
diff --git a/target/m68k/translate.c b/target/m68k/translate.c
index 70fd680..49c0b06 100644
--- a/target/m68k/translate.c
+++ b/target/m68k/translate.c
@@ -4483,13 +4483,79 @@ static void gen_op_fmove_fcr(CPUM68KState *env, 
DisasContext *s,
 tcg_temp_free_i32(addr);
 }
 
+static void gen_op_fmovem(CPUM68KState *env, DisasContext *s,
+  uint32_t insn, uint32_t ext)
+{
+int opsize;
+uint16_t mask;
+int i;
+uint32_t mode;
+int32_t incr;
+TCGv addr, tmp;
+int is_load;
+
+if (m68k_feature(s->env, M68K_FEATURE_FPU)) {
+opsize = OS_EXTENDED;
+} else {
+opsize = OS_DOUBLE;  /* FIXME */
+}
+
+mode = (ext >> 11) & 0x3;
+if ((mode & 0x1) == 1) {
+gen_helper_fmovem(cpu_env, tcg_const_i32(opsize),
+  tcg_const_i32(mode), DREG(ext, 0));
+return;
+}
+
+tmp = gen_lea(env, s, insn, opsize);
+if (IS_NULL_QREG(tmp)) {
+gen_addr_fault(s);
+return;
+}
+
+addr = tcg_temp_new();
+tcg_gen_mov_i32(addr, tmp);
+is_load = ((ext & 0x2000) == 0);
+incr = opsize_bytes(opsize);
+mask = ext & 0x00FF;
+
+if (!is_load && (mode & 2) == 0) {
+for (i = 7; i >= 0; i--, mask <<= 1) {
+if (mask & 0x80) {
+gen_op_load_fpr_FP0(i);
+gen_store_FP0(s, opsize, addr);
+if ((mask & 0xff) != 0x80) {
+tcg_gen_subi_i32(addr, addr, incr);
+}
+}
+}
+tcg_gen_mov_i32(AREG(insn, 0), addr);
+} else {
+for (i = 0; i < 8; i++, mask <<= 1) {
+if (mask & 0x80) {
+if (is_load) {
+gen_load_FP0(s, opsize, addr);
+gen_op_store_fpr_FP0(i);
+} else {
+gen_op_load_fpr_FP0(i);
+gen_store_FP0(s, opsize, addr);
+}
+tcg_gen_addi_i32(addr, addr, incr);
+}
+}
+if ((insn & 070) == 030) {
+tcg_gen_mov_i32(AREG(insn, 0), addr);
+}
+}
+tcg_temp_free_i32(addr);
+}
+
 /* ??? FP exceptions are not implemented.  Most exceptions are deferred until
immediately before the next FP instruction is executed.  */
 DISAS_INSN(fpu)
 {
 uint16_t ext;
 int opmode;
-TCGv tmp32;
 int opsize;
 
 ext = read_im16(env, s);
@@ -4514,32 +4580,13 @@ DISAS_INSN(fpu)
 return;
 case 6: /* fmovem */
 case 7:
-{
-TCGv addr;
-uint16_t mask;
-int i;
-if ((ext & 0x1f00) != 0x1000 || (ext & 0xff) == 0)
-goto undef;
-tmp32 = gen_lea(env, s, insn, OS_LONG);
-if (IS_NULL_QREG(tmp32)) {
-gen_addr_fault(s);
-return;
-}
-addr = tcg_temp_new_i32();
-tcg_gen_mov_i32(addr, tmp32);
-mask = 0x80;
-for (i = 0; i < 8; i++) {
-if (ext & mask) {
-gen_op_load_fpr_FP0(REG(i, 0));
-gen_ldst_FP0(s, OS_DOUBLE, addr, (ext & (1 << 13)) ?
- EA_STORE : EA_LOADS);
-if (ext & (mask - 1))
-tcg_gen_addi_i32(addr, addr, 8);
-}
-mask >>= 1;
-}
-tcg_temp_free_i32(addr);
+if ((ext & 0xf00) != 0 || (ext & 0xff) == 0) {
+goto undef;
+}
+if ((ext & 0x1000) == 0 && !m68k_feature(s->env, M68K_FEATURE_FPU)) {
+goto undef;
 }
+gen_op_fmovem(env, s, insn, ext);
 return;
 }
 if (ext & (1 << 14)) {
-- 
2.7.4




Re: [Qemu-devel] [PATCH v2 0/4] virtio: ARRAY_SIZE fixups

2017-01-18 Thread no-reply
Hi,

Your series seems to have some coding style problems. See output below for
more information:

Message-id: 1484772931-16272-1-git-send-email-...@redhat.com
Subject: [Qemu-devel] [PATCH v2 0/4] virtio: ARRAY_SIZE fixups
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/1484772931-16272-1-git-send-email-...@redhat.com 
-> patchew/1484772931-16272-1-git-send-email-...@redhat.com
Switched to a new branch 'test'
798c743 ARRAY_SIZE: check that argument is an array
f3f401d compiler: expression version of QEMU_BUILD_BUG_ON
0f5bfd8 compiler: drop ; after BUILD_BUG_ON
489ff1b virtio: fix up max size checks

=== OUTPUT BEGIN ===
Checking PATCH 1/4: virtio: fix up max size checks...
Checking PATCH 2/4: compiler: drop ; after BUILD_BUG_ON...
ERROR: space required after that ',' (ctx:VxV)
#25: FILE: include/qemu/compiler.h:89:
+typedef char glue(qemu_build_bug_on__,__LINE__)[(x) ? -1 : 1] \
  ^

total: 1 errors, 0 warnings, 9 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 3/4: compiler: expression version of QEMU_BUILD_BUG_ON...
Checking PATCH 4/4: ARRAY_SIZE: check that argument is an array...
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

[Qemu-devel] [PATCH 4/7] target-m68k: use floatx80 internally

2017-01-18 Thread Laurent Vivier
Coldfire uses float64, but 680x0 use floatx80.
This patch introduces the use of floatx80 internally and
enable FPU for 680x0.

Signed-off-by: Laurent Vivier 
---
 configure|   2 +-
 gdb-xml/m68k-fp.xml  |  21 ++
 target/m68k/cpu.c|  13 +-
 target/m68k/cpu.h|  74 +++-
 target/m68k/fpu_helper.c | 381 +---
 target/m68k/helper.c |  77 +++-
 target/m68k/helper.h |  34 +-
 target/m68k/qregs.def|   4 +-
 target/m68k/translate.c  | 915 +--
 9 files changed, 1176 insertions(+), 345 deletions(-)
 create mode 100644 gdb-xml/m68k-fp.xml

diff --git a/configure b/configure
index 86f5214..02f1c1c 100755
--- a/configure
+++ b/configure
@@ -5912,7 +5912,7 @@ case "$target_name" in
   ;;
   m68k)
 bflt="yes"
-gdb_xml_files="cf-core.xml cf-fp.xml"
+gdb_xml_files="cf-core.xml cf-fp.xml m68k-fp.xml"
   ;;
   microblaze|microblazeel)
 TARGET_ARCH=microblaze
diff --git a/gdb-xml/m68k-fp.xml b/gdb-xml/m68k-fp.xml
new file mode 100644
index 000..64290d1
--- /dev/null
+++ b/gdb-xml/m68k-fp.xml
@@ -0,0 +1,21 @@
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+
+  
+  ,
+  
+
diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
index ba17480..caf0b12 100644
--- a/target/m68k/cpu.c
+++ b/target/m68k/cpu.c
@@ -49,6 +49,8 @@ static void m68k_cpu_reset(CPUState *s)
 M68kCPU *cpu = M68K_CPU(s);
 M68kCPUClass *mcc = M68K_CPU_GET_CLASS(cpu);
 CPUM68KState *env = >env;
+floatx80 nan = floatx80_default_nan(NULL);
+int i;
 
 mcc->parent_reset(s);
 
@@ -57,7 +59,16 @@ static void m68k_cpu_reset(CPUState *s)
 env->sr = 0x2700;
 #endif
 m68k_switch_sp(env);
-/* ??? FP regs should be initialized to NaN.  */
+for (i = 0; i < 8; i++) {
+env->fregs[i].d = nan;
+}
+env->fp0h = nan.high;
+env->fp0l = nan.low;
+env->fp1h = nan.high;
+env->fp1l = nan.low;
+cpu_m68k_set_fpcr(env, 0);
+env->fpsr = 0;
+
 cpu_m68k_set_ccr(env, 0);
 /* TODO: We should set PC from the interrupt vector.  */
 env->pc = 0;
diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index fc1f16f..b2d06f5 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -57,6 +57,15 @@
 #define EXCP_TRAP15 47   /* User trap #15.  */
 #define EXCP_UNSUPPORTED61
 #define EXCP_ICE13
+#define EXCP_FP_BSUN48 /* Branch Set on Unordered */
+#define EXCP_FP_INEX49 /* Inexact result */
+#define EXCP_FP_DZ  50 /* Divide by Zero */
+#define EXCP_FP_UNFL51 /* Underflow */
+#define EXCP_FP_OPERR   52 /* Operand Error */
+#define EXCP_FP_OVFL53 /* Overflow */
+#define EXCP_FP_SNAN54 /* Signaling Not-A-Number */
+#define EXCP_FP_UNIMP   55 /* Unimplemented Data type */
+
 
 #define EXCP_RTE0x100
 #define EXCP_HALT_INSN  0x101
@@ -64,6 +73,8 @@
 #define NB_MMU_MODES 2
 #define TARGET_INSN_START_EXTRA_WORDS 1
 
+typedef CPU_LDoubleU FPReg;
+
 typedef struct CPUM68KState {
 uint32_t dregs[8];
 uint32_t aregs[8];
@@ -82,12 +93,16 @@ typedef struct CPUM68KState {
 uint32_t cc_c; /* either 0/1, unused, or computed from cc_n and cc_v */
 uint32_t cc_z; /* == 0 or unused */
 
-float64 fregs[8];
-float64 fp_result;
+FPReg fregs[8];
 uint32_t fpcr;
 uint32_t fpsr;
 float_status fp_status;
 
+uint32_t fp0h;
+uint64_t fp0l;
+uint32_t fp1h;
+uint64_t fp1l;
+
 uint64_t mactmp;
 /* EMAC Hardware deals with 48-bit values composed of one 32-bit and
two 8-bit parts.  We store a single 64-bit value and
@@ -159,6 +174,7 @@ int cpu_m68k_signal_handler(int host_signum, void *pinfo,
void *puc);
 uint32_t cpu_m68k_get_ccr(CPUM68KState *env);
 void cpu_m68k_set_ccr(CPUM68KState *env, uint32_t);
+void cpu_m68k_set_fpcr(CPUM68KState *env, uint32_t val);
 
 
 /* Instead of computing the condition codes after each m68k instruction,
@@ -203,6 +219,55 @@ typedef enum {
 #define M68K_SSP0
 #define M68K_USP1
 
+/* Floating-Point Status Register */
+
+/* Condition Code */
+#define FPSR_CC_MASK  0x0f00
+#define FPSR_CC_A 0x0100 /* Not-A-Number */
+#define FPSR_CC_I 0x0200 /* Infinity */
+#define FPSR_CC_Z 0x0400 /* Zero */
+#define FPSR_CC_N 0x0800 /* Negative */
+
+/* Exception Status */
+#define FPSR_ES_MASK  0xff00
+#define FPSR_ES_BSUN  0x8000 /* Branch Set on Unordered */
+#define FPSR_ES_SNAN  0x4000 /* Signaling Not-A-Number */
+#define FPSR_ES_OPERR 0x2000 /* Operand Error */
+#define FPSR_ES_OVFL  0x1000 /* Overflow */
+#define FPSR_ES_UNFL  0x0800 /* Underflow */
+#define FPSR_ES_DZ0x0400 /* Divide by Zero */
+#define FPSR_ES_INEX2 0x0200 /* Inexact operation */
+#define FPSR_ES_INEX  0x0100 /* Inexact decimal input */
+
+/* Accrued Exception */
+#define FPSR_AE_MASK  0x00ff
+#define FPSR_AE_IOP   0x0080 /* Invalid Operation */

Re: [Qemu-devel] [PATCH v2 2/4] compiler: drop ; after BUILD_BUG_ON

2017-01-18 Thread Michael S. Tsirkin
On Wed, Jan 18, 2017 at 09:04:03PM +, Peter Maydell wrote:
> On 18 January 2017 at 20:55, Michael S. Tsirkin  wrote:
> > All users include the trailing ;, let's require that
> > so that uses such as if (a) QEMU_BUILD_BUG_ON(); do not
> > produce unexpected results.
> 
> When would it ever make sense for a build-time
> assert to be the only thing inside a runtime
> conditional anyway?
> 
> thanks
> -- PMM

What do I know? Do you want to keep the trailing ; in there?
I can drop this patch.

-- 
MST



Re: [Qemu-devel] [PATCH 0/7] target-m68k: implement 680x0 FPU

2017-01-18 Thread no-reply
Hi,

Your series seems to have some coding style problems. See output below for
more information:

Message-id: 1484773521-16530-1-git-send-email-laur...@vivier.eu
Subject: [Qemu-devel] [PATCH 0/7] target-m68k: implement 680x0 FPU
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1484773521-16530-1-git-send-email-laur...@vivier.eu -> 
patchew/1484773521-16530-1-git-send-email-laur...@vivier.eu
Switched to a new branch 'test'
aba9788 target-m68k: implements more FPU instructions
9ec3c4f target-m68k: introduce fscc.
a5d5dab target-m68k: add fmovem
1dc2042 target-m68k: use floatx80 internally
c202985 softfloat: define 680x0 specific values
e1de738 target-m68k: define ext_opsize
1cb012d target-m68k: move FPU helpers to fpu_helper.c

=== OUTPUT BEGIN ===
Checking PATCH 1/7: target-m68k: move FPU helpers to fpu_helper.c...
Checking PATCH 2/7: target-m68k: define ext_opsize...
Checking PATCH 3/7: softfloat: define 680x0 specific values...
Checking PATCH 4/7: target-m68k: use floatx80 internally...
ERROR: storage class should be at the beginning of the declaration
#849: FILE: target/m68k/translate.c:39:
+#define DEFF96(name, offset) static TCGv_i32 QREG_##name##H; \

total: 1 errors, 0 warnings, 1898 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 5/7: target-m68k: add fmovem...
Checking PATCH 6/7: target-m68k: introduce fscc
Checking PATCH 7/7: target-m68k: implements more FPU instructions...
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

Re: [Qemu-devel] [PATCH v2 2/4] compiler: drop ; after BUILD_BUG_ON

2017-01-18 Thread Michael S. Tsirkin
On Wed, Jan 18, 2017 at 11:16:07PM +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 18, 2017 at 09:04:03PM +, Peter Maydell wrote:
> > On 18 January 2017 at 20:55, Michael S. Tsirkin  wrote:
> > > All users include the trailing ;, let's require that
> > > so that uses such as if (a) QEMU_BUILD_BUG_ON(); do not
> > > produce unexpected results.
> > 
> > When would it ever make sense for a build-time
> > assert to be the only thing inside a runtime
> > conditional anyway?
> > 
> > thanks
> > -- PMM
> 
> What do I know? Do you want to keep the trailing ; in there?
> I can drop this patch.

Maybe a better justification:


QEMU_BUILD_BUG_ON(0)

QEMU_BUILD_BUG_ON(0)

looks ugly but is allowed by the current implementation.
Let's drop the trailing ; within the macro to make sure all
users include the ';'.


> -- 
> MST



[Qemu-devel] [PATCH] numa: access CPU's node id via property in hmp_info_numa()

2017-01-18 Thread Igor Mammedov
Move vcpu's assocciated numa_node field out of generic CPUState
into inherited classes that actually care about cpu<->numa mapping
and make monitor 'info numa' get vcpu's assocciated node id via
node-id property.
It allows to drop implicit node id intialization in
numa_post_machine_init() and would allow switching to mapping
defined by target's CpuInstanceProperties instead of global
numa_info[i].node_cpu bitmaps.

As side effect it fixes 'info numa' displaying wrong mapping
for CPUs specified with -device/device_add.
Before patch following CLI would produce:
QEMU -smp 1,sockets=3,maxcpus=3 \
   -device qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0 \
   -numa node,nodeid=0,cpus=0 \
   -numa node,nodeid=1,cpus=1 \
   -numa node,nodeid=2,cpus=2
(qemu) device_add qemu64-x86_64-cpu,socket-id=2,core-id=0,thread-id=0
(qemu) info numa
3 nodes
node 0 cpus: 0 1 2
node 0 size: 40 MB
node 1 cpus:
node 1 size: 40 MB
node 2 cpus:
node 2 size: 48 MB

after patch all CPUs are on nodes they are supposed to be:
(qemu) device_add qemu64-x86_64-cpu,socket-id=2,core-id=0,thread-id=0
(qemu) info numa
3 nodes
node 0 cpus: 0
node 0 size: 40 MB
node 1 cpus: 1
node 1 size: 40 MB
node 2 cpus: 2
node 2 size: 48 MB

Signed-off-by: Igor Mammedov 
---
CC: Dou Liyang 
CC: fanc.f...@cn.fujitsu.com
CC: caoj.f...@cn.fujitsu.com
CC: stefa...@redhat.com
CC: izumi.t...@jp.fujitsu.com
CC: vilan...@ac.upc.edu
CC: ehabk...@redhat.com
CC: peter.mayd...@linaro.org
CC: Andrew Jones 
CC: David Gibson 
CC: Thomas Huth 
---
 include/qom/cpu.h   |  2 --
 include/sysemu/numa.h   |  1 -
 target/arm/cpu.h|  2 ++
 target/i386/cpu.h   |  1 +
 target/ppc/cpu.h|  2 ++
 hw/arm/virt.c   | 12 
 hw/i386/pc.c|  5 +
 hw/ppc/spapr.c  |  2 +-
 hw/ppc/spapr_cpu_core.c |  2 +-
 monitor.c   |  7 +--
 numa.c  | 15 ---
 target/arm/cpu.c|  1 +
 target/i386/cpu.c   |  1 +
 target/ppc/translate_init.c |  1 +
 vl.c|  2 --
 15 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 3f79a8e..ae637a9 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -257,7 +257,6 @@ struct qemu_work_item;
  * @cpu_index: CPU index (informative).
  * @nr_cores: Number of cores within this CPU package.
  * @nr_threads: Number of threads within this CPU.
- * @numa_node: NUMA node this CPU is belonging to.
  * @host_tid: Host thread ID.
  * @running: #true if CPU is currently running (lockless).
  * @has_waiter: #true if a CPU is currently waiting for the cpu_exec_end;
@@ -306,7 +305,6 @@ struct CPUState {
 
 int nr_cores;
 int nr_threads;
-int numa_node;
 
 struct QemuThread *thread;
 #ifdef _WIN32
diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h
index 8f09dcf..b8015a5 100644
--- a/include/sysemu/numa.h
+++ b/include/sysemu/numa.h
@@ -25,7 +25,6 @@ typedef struct node_info {
 
 extern NodeInfo numa_info[MAX_NODES];
 void parse_numa_opts(MachineClass *mc);
-void numa_post_machine_init(void);
 void query_numa_node_mem(uint64_t node_mem[]);
 extern QemuOptsList qemu_numa_opts;
 void numa_set_mem_node_id(ram_addr_t addr, uint64_t size, uint32_t node);
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 7bd16ee..ef263f1 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -662,6 +662,8 @@ struct ARMCPU {
 
 ARMELChangeHook *el_change_hook;
 void *el_change_hook_opaque;
+
+int32_t numa_nid;
 };
 
 static inline ARMCPU *arm_env_get_cpu(CPUARMState *env)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 6c1902b..e43dcc2 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1264,6 +1264,7 @@ struct X86CPU {
 int32_t socket_id;
 int32_t core_id;
 int32_t thread_id;
+int32_t numa_nid;
 };
 
 static inline X86CPU *x86_env_get_cpu(CPUX86State *env)
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 2a50c43..2d12ad5 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1154,6 +1154,7 @@ do {\
  * @cpu_dt_id: CPU index used in the device tree. KVM uses this index too
  * @max_compat: Maximal supported logical PVR from the command line
  * @cpu_version: Current logical PVR, zero if in "raw" mode
+ * @numa_nid: Numa node id the CPU belongs to
  *
  * A PowerPC CPU.
  */
@@ -1166,6 +1167,7 @@ struct PowerPCCPU {
 int cpu_dt_id;
 uint32_t max_compat;
 uint32_t cpu_version;
+int32_t numa_nid;
 
 /* Fields related to migration compatibility hacks */
 bool pre_2_8_migration;
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 7a03f84..b86b5fd 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -329,7 +329,6 @@ static void fdt_add_cpu_nodes(const VirtMachineState *vms)
 {
 int cpu;
 

[Qemu-devel] [PATCH] configure: allow enabling seccomp on s390x

2017-01-18 Thread Christian Ehrhardt
Allow enabling seccomp support on s390x if sufficient build
dependencies are provided.

Signed-off-by: Christian Ehrhardt 
---
 configure | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configure b/configure
index 86f5214..5056ba9 100755
--- a/configure
+++ b/configure
@@ -1927,6 +1927,9 @@ if test "$seccomp" != "no" ; then
 ppc|ppc64)
 libseccomp_minver="2.3.0"
 ;;
+s390|s390x)
+libseccomp_minver="2.3.0"
+;;
 *)
 libseccomp_minver=""
 ;;
-- 
2.7.4




Re: [Qemu-devel] [PATCH] x86-KVM: Supply TSC and APIC clock rates to guest like VMWare

2017-01-18 Thread Paolo Bonzini


On 18/01/2017 15:24, Phil Dennis-Jordan wrote:
> ---
>  target/i386/cpu.c |  1 +
>  target/i386/cpu.h |  4 
>  target/i386/kvm.c | 40 
>  3 files changed, 37 insertions(+), 8 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index aba11ae..e5523d4 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -3677,6 +3677,7 @@ static Property x86_cpu_properties[] = {
>  DEFINE_PROP_BOOL("cpuid-0xb", X86CPU, enable_cpuid_0xb, true),
>  DEFINE_PROP_BOOL("lmce", X86CPU, enable_lmce, false),
>  DEFINE_PROP_BOOL("l3-cache", X86CPU, enable_l3_cache, true),
> +DEFINE_PROP_BOOL("vmware-tsc-apic-clocks", X86CPU, vmware_clock_rates, 
> false),

Maybe just vmware-cpuid-freq instead?  Whatever the choice, please make
the bool field in struct X86CPU consistent with the property name (e.g.
enable_vmware_cpuid_freq).

One issue is that the TSC frequency can change, for example on
migration.  Telling the guest about the TSC frequency makes little sense
if it can change.

So the leaf should be conditional on the INVTSC feature
(CPUID[0x8007].EDX bit 8).  You can enable this unconditionally for
new machine types (i.e. making it true here, and turning it off in
include/hw/i386/pc.h's PC_COMPAT_2_8 macro), but only expose it if that
bit is also set.

>  DEFINE_PROP_END_OF_LIST()
>  };
>  
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 6c1902b..1d8590b 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1213,6 +1213,10 @@ struct X86CPU {
>  bool host_features;
>  uint32_t apic_id;
>  
> +/* Enables publishing of TSC increment and Local APIC bus frequencies to
> + * the guest OS in CPUID page 0x4010, the same way that VMWare does. 
> */
> +bool vmware_clock_rates;
> +
>  /* if true the CPUID code directly forward host cache leaves to the 
> guest */
>  bool cache_info_passthrough;
>  
> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> index 10a9cd8..7830b3a 100644
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -778,10 +778,14 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  }
>  
>  if (cpu->expose_kvm) {
> +uint32_t kvm_max_page = KVM_CPUID_FEATURES | kvm_base;

s/page/leaf/

> +if (cpu->vmware_clock_rates && kvm_base == KVM_CPUID_SIGNATURE) {
> +kvm_max_page = MAX(kvm_max_page, KVM_CPUID_SIGNATURE | 0x10);
> +}
>  memcpy(signature, "KVMKVMKVM\0\0\0", 12);
>  c = _data.entries[cpuid_i++];
>  c->function = KVM_CPUID_SIGNATURE | kvm_base;
> -c->eax = KVM_CPUID_FEATURES | kvm_base;
> +c->eax = kvm_max_page;
>  c->ebx = signature[0];
>  c->ecx = signature[1];
>  c->edx = signature[2];
> @@ -910,7 +914,6 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  }
>  }
>  
> -cpuid_data.cpuid.nent = cpuid_i;
>  
>  if (((env->cpuid_version >> 8)&0xF) >= 6
>  && (env->features[FEAT_1_EDX] & (CPUID_MCE | CPUID_MCA)) ==
> @@ -973,12 +976,6 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  vmstate_x86_cpu.unmigratable = 1;
>  }
>  
> -cpuid_data.cpuid.padding = 0;
> -r = kvm_vcpu_ioctl(cs, KVM_SET_CPUID2, _data);
> -if (r) {
> -return r;
> -}
> -
>  r = kvm_arch_set_tsc_khz(cs);
>  if (r < 0) {
>  return r;
> @@ -998,6 +995,33 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  }
>  }
>  
> +if (cpu->vmware_clock_rates) {

^^ Here is where you should also check invtsc.

> +if (cpu->expose_kvm

I think this should not depend on cpu->expose_kvm.  This is not a KVM
leaf, it's a vmware leaf; if it were a KVM leaf, it would obey kvm_base.
 Of course checking kvm_base is still a good idea, to avoid stomping on
Hyper-V's CPUID space.

Thanks,

Paolo

> +&& kvm_base == KVM_CPUID_SIGNATURE
> +&& env->tsc_khz != 0) {
> +/* Publish TSC and LAPIC resolution on CPUID page 0x4010
> + * like VMWare for benefit of Darwin guests. */
> +c = _data.entries[cpuid_i++];
> +c->function = KVM_CPUID_SIGNATURE | 0x10;
> +c->eax = env->tsc_khz;
> +/* LAPIC resolution of 1ns (freq: 1GHz) is hardcoded in KVM's
> + * APIC_BUS_CYCLE_NS*/
> +c->ebx = 100;
> +c->ecx = c->edx = 0;
> +} else {
> +error_report(
> +"Warning: VMWare-style TSC/LAPIC clock reporting 
> impossible.");


> +}
> +}
> +
> +cpuid_data.cpuid.nent = cpuid_i;
> +
> +cpuid_data.cpuid.padding = 0;
> +r = kvm_vcpu_ioctl(cs, KVM_SET_CPUID2, _data);
> +if (r) {
> +return r;
> +}
> +
>  if (has_xsave) {
>  env->kvm_xsave_buf = qemu_memalign(4096, sizeof(struct kvm_xsave));
>  }
> 



<    1   2   3   4   >