Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Sep 21, 2017
  3. Sep 14, 2017
  5. Sep 04, 2017
  7. Aug 31, 2017
  9. Aug 01, 2017
    • Denis V. Lunev's avatar
      monitor: Reduce handle_qmp_command() tracing overhead · bd6952a3
      Denis V. Lunev authored 
      
We are malloc'ing a QString and spending CPU cycles on converting a
QObject to string, just for the sake of sticking the string in the trace
message.  Wasted when we aren't tracing.  Avoid that.

[Commit message and description suggested by Markus Armbruster to
provide more detail about the rationale for this patch.

Use trace_event_get_state_backends() instead of trace_event_get_state()
to honor DTrace/UST backend dstates.
--Stefan]

Signed-off-by: default avatarDenis V. Lunev <den@openvz.org>
Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Message-id: 20170725143923.11241-1-den@openvz.org
CC: Stefan Hajnoczi <stefanha@redhat.com>
CC: Lluís Vilanova <vilanova@ac.upc.edu>
CC: Dr. David Alan Gilbert <dgilbert@redhat.com>
CC: Markus Armbruster <armbru@redhat.com>
Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      bd6952a3
  11. Jul 14, 2017
  13. Jul 12, 2017
  15. Jul 11, 2017
  17. Jul 04, 2017
  19. Jun 29, 2017
  21. Jun 20, 2017
  23. Jun 13, 2017
  25. Jun 05, 2017
  27. Jun 02, 2017
  29. May 18, 2017
  31. May 17, 2017
    • Eduardo Habkost's avatar
      qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable · e90f2a8c
      Eduardo Habkost authored 
      
cannot_instantiate_with_device_add_yet was introduced by commit
efec3dd6 to replace no_user. It was
supposed to be a temporary measure.

When it was introduced, we had 54
cannot_instantiate_with_device_add_yet=true lines in the code.
Today (3 years later) this number has not shrunk: we now have
57 cannot_instantiate_with_device_add_yet=true lines. I think it
is safe to say it is not a temporary measure, and we won't see
the flag go away soon.

Instead of a long field name that misleads people to believe it
is temporary, replace it a shorter and less misleading field:
user_creatable.

Except for code comments, changes were generated using the
following Coccinelle patch:

  @@
  expression DC;
  @@
  (
  -DC->cannot_instantiate_with_device_add_yet = false;
  +DC->user_creatable = true;
  |
  -DC->cannot_instantiate_with_device_add_yet = true;
  +DC->user_creatable = false;
  )

  @@
  typedef ObjectClass;
  expression dc;
  identifier class, data;
  @@
   static void device_class_init(ObjectClass *class, void *data)
   {
   ...
   dc->hotpluggable = true;
  +dc->user_creatable = true;
   ...
   }

  @@
  @@
   struct DeviceClass {
   ...
  -bool cannot_instantiate_with_device_add_yet;
  +bool user_creatable;
   ...
  }

  @@
  expression DC;
  @@
  (
  -!DC->cannot_instantiate_with_device_add_yet
  +DC->user_creatable
  |
  -DC->cannot_instantiate_with_device_add_yet
  +!DC->user_creatable
  )

Cc: Alistair Francis <alistair.francis@xilinx.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Thomas Huth <thuth@redhat.com>
Acked-by: default avatarAlistair Francis <alistair.francis@xilinx.com>
Reviewed-by: default avatarThomas Huth <thuth@redhat.com>
Reviewed-by: default avatarMarcel Apfelbaum <marcel@redhat.com>
Acked-by: default avatarMarcel Apfelbaum <marcel@redhat.com>
Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20170503203604.31462-2-ehabkost@redhat.com>
[ehabkost: kept "TODO remove once we're there" comment]
Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      e90f2a8c
  33. May 09, 2017
  35. May 04, 2017
  37. Apr 28, 2017
  39. Apr 26, 2017
  41. Mar 14, 2017
  43. Mar 07, 2017
  45. Mar 05, 2017
    • Markus Armbruster's avatar
      qmp: Drop duplicated QMP command object checks · 104fc302
      Markus Armbruster authored 
      
qmp_check_input_obj() duplicates qmp_dispatch_check_obj(), except the
latter screws up an error message.  handle_qmp_command() runs first
the former, then the latter via qmp_dispatch(), masking the screwup.

qemu-ga also masks the screwup, because it also duplicates checks,
just differently.

qmp_check_input_obj() exists because handle_qmp_command() needs to
examine the command before dispatching it.  The previous commit got
rid of this need, except for a tracepoint, and a bit of "id" code that
relies on qdict not being null.

Fix up the error message in qmp_dispatch_check_obj(), drop
qmp_check_input_obj() and the tracepoint.  Protect the "id" code with
a conditional.

Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Message-Id: <1488544368-30622-9-git-send-email-armbru@redhat.com>
      104fc302
    • Markus Armbruster's avatar
      qmp: Clean up how we enforce capability negotiation · 635db18f
      Markus Armbruster authored 
      
To enforce capability negotiation before normal operation,
handle_qmp_command() inspects every command before it's handed off to
qmp_dispatch().  This is a bit of a layering violation, and results in
duplicated code.

Before capability negotiation (!cur_mon->in_command_mode), we fail
commands other than "qmp_capabilities".  This is what enforces
capability negotiation.

Afterwards, we fail command "qmp_capabilities".

Clean this up as follows.

The obvious place to fail a command is the command itself, so move the
"afterwards" check to qmp_qmp_capabilities().

We do the "before" check in every other command, but that would be
bothersome.  Instead, start with an alternate list of commands that
contains only "qmp_capabilities".  Switch to the full list in
qmp_qmp_capabilities().

Additionally, replace the generic human-readable error message for
CommandNotFound by one that reminds the user to run qmp_capabilities.
Without that, we'd regress commit 2d5a8346.

Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
Message-Id: <1488544368-30622-8-git-send-email-armbru@redhat.com>
[Mirco-optimization squashed in, commit message typo fixed]
Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      635db18f
    • Markus Armbruster's avatar
      qapi: Support multiple command registries per program · 1527badb
      Markus Armbruster authored 
      
The command registry encapsulates a single command list.  Give the
functions using it a parameter instead.  Define suitable command lists
in monitor, guest agent and test-qmp-commands.

Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
Message-Id: <1488544368-30622-6-git-send-email-armbru@redhat.com>
[Debugging turds buried]
Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      1527badb
    • Markus Armbruster's avatar
      qmp: Dumb down how we run QMP command registration · 05875687
      Markus Armbruster authored 
      
The way we get QMP commands registered is high tech:

* qapi-commands.py generates qmp_init_marshal() that does the actual work

* it also generates the magic to register it as a MODULE_INIT_QAPI
  function, so it runs when someone calls
  module_call_init(MODULE_INIT_QAPI)

* main() calls module_call_init()

QEMU needs to register a few non-qapified commands.  Same high tech
works: monitor.c has its own qmp_init_marshal() along with the magic
to make it run in module_call_init(MODULE_INIT_QAPI).

QEMU also needs to unregister commands that are not wanted in this
build's configuration (commit 5032a16d).  Simple enough:
qmp_unregister_commands_hack().  The difficulty is to make it run
after the generated qmp_init_marshal().  We can't simply run it in
monitor.c's qmp_init_marshal(), because the order in which the
registered functions run is indeterminate.  So qmp_init_marshal()
registers qmp_unregister_commands_hack() separately.  Since
registering *appends* to the list of registered functions, this will
make it run after all the functions that have been registered already.

I suspect it takes a long and expensive computer science education to
not find this silly.

Dumb it down as follows:

* Drop MODULE_INIT_QAPI entirely

* Give the generated qmp_init_marshal() external linkage.

* Call it instead of module_call_init(MODULE_INIT_QAPI)

* Except in QEMU proper, call new monitor_init_qmp_commands() that in
  turn calls the generated qmp_init_marshal(), registers the
  additional commands and unregisters the unwanted ones.

Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Message-Id: <1488544368-30622-5-git-send-email-armbru@redhat.com>
      05875687
  47. Feb 27, 2017
    • Eduardo Habkost's avatar
      i386: Implement query-cpu-model-expansion QMP command · f99fd7ca
      Eduardo Habkost authored 
      
Implement query-cpu-model-expansion for target-i386.

This should meet all the requirements while being simple. In the
case of static expansion, it will use the new "base" CPU model,
and in the case of full expansion, it will keep the original CPU
model name+props, and append extra properties.

A future follow-up should improve the implementation of
type=full, so that it returns more detailed data, including every
writable QOM property in the CPU object.

Cc: libvir-list@redhat.com
Cc: Jiri Denemark <jdenemar@redhat.com>
Message-Id: <20170222190029.17243-3-ehabkost@redhat.com>
Tested-by: default avatarJiri Denemark <jdenemar@redhat.com>
Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      f99fd7ca
  49. Feb 23, 2017
  51. Feb 22, 2017