1. 17 Jun, 2016 1 commit
    • Igor Mammedov's avatar
      QMP: Add query-hotpluggable-cpus · d4633541
      Igor Mammedov authored
      It will allow mgmt to query present and hotpluggable CPU objects,
      it is required from a target platform that wishes to support command
      to implement and set MachineClass.query_hotpluggable_cpus callback,
      which will return a list of possible CPU objects with options that
      would be needed for hotplugging possible CPU objects.
      
      There are:
      'type': 'str' - QOM CPU object type for usage with device_add
      'vcpus-count': 'int' - number of logical VCPU threads per
                              CPU object (mgmt needs to know)
      
      and a set of optional fields that are to used for hotplugging a CPU
      objects and would allows mgmt tools to know what/where it could be
      hotplugged;
      [node],[socket],[core],[thread]
      
      For present CPUs there is a 'qom-path' field which would allow mgmt to
      inspect whatever object/abstraction the target platform considers
      as CPU object.
      Signed-off-by: 's avatarIgor Mammedov <imammedo@redhat.com>
      Signed-off-by: 's avatarBharata B Rao <bharata@linux.vnet.ibm.com>
      Reviewed-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      d4633541
  2. 07 Jun, 2016 1 commit
  3. 25 May, 2016 1 commit
    • Kevin Wolf's avatar
      block: Fix bdrv_next() memory leak · 88be7b4b
      Kevin Wolf authored
      The bdrv_next() users all leaked the BdrvNextIterator after completing
      the iteration. Simply changing bdrv_next() to free the iterator before
      returning NULL at the end of list doesn't work because some callers exit
      the loop before looking at all BDSes.
      
      This patch moves the BdrvNextIterator from the heap to the stack of
      the caller and switches to a bdrv_first()/bdrv_next() interface for
      initialising the iterator.
      Signed-off-by: 's avatarKevin Wolf <kwolf@redhat.com>
      Reviewed-by: 's avatarFam Zheng <famz@redhat.com>
      88be7b4b
  4. 19 May, 2016 4 commits
  5. 30 Mar, 2016 1 commit
    • Peter Xu's avatar
      arm: qmp: add query-gic-capabilities interface · ae50a770
      Peter Xu authored
      This patch add "query-gic-capabilities" but does not implement it. The
      command is ARM-only. The command will return a list of GICCapability
      structs that describes all GIC versions that current QEMU and system
      support.
      
      Libvirt is possibly the first consumer of this new command.
      
      Before this patch, a libvirt user can successfully configure all kinds
      of GIC devices for ARM guests, no matter whether current QEMU/kernel
      supports them. If the specified GIC version/type is not supported, the
      user will get an ambiguous "QEMU boot failure" error when trying to start
      the VM. This is not user-friendly.
      
      With this patch, libvirt should be able to query which type (and which
      version) of GIC device is supported. Using this information, libvirt
      can warn the user during configuration of guests when specified GIC
      device type is not supported. Or better, we can just list those versions
      that we support, and filter out the unsupported ones.
      
      For example, if we got the query result:
      
      {"return": [{"emulated": false, "version": 3, "kernel": true},
                  {"emulated": true, "version": 2, "kernel": false}]}
      
      then it means that we support emulated GIC version 2 using:
      
        qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ...
      
      or KVM-accelerated GIC version 3 using:
      
        qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ...
      
      If we specify other explicit GIC versions rather than the above, QEMU
      will not be able to boot.
      
      The community is working on a more generic way to query these kinds of
      information about valid values of machine properties. However, due to
      the importance of supporting this specific use case, weecided to first
      implement this ad-hoc one; then when the generic method is ready, we
      can move on to that one smoothly.
      Signed-off-by: 's avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com
      [PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only]
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      ae50a770
  6. 22 Mar, 2016 2 commits
  7. 17 Mar, 2016 1 commit
  8. 14 Mar, 2016 2 commits
  9. 01 Mar, 2016 1 commit
  10. 04 Feb, 2016 1 commit
    • Peter Maydell's avatar
      all: Clean up includes · d38ea87a
      Peter Maydell authored
      Clean up includes so that osdep.h is included first and headers
      which it implies are not included manually.
      
      This commit was created with scripts/clean-includes.
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      Message-id: 1454089805-5470-16-git-send-email-peter.maydell@linaro.org
      d38ea87a
  11. 13 Jan, 2016 1 commit
    • Markus Armbruster's avatar
      error: Use error_report_err() instead of monitor_printf() · 193227f9
      Markus Armbruster authored
      Both error_report_err() and monitor_printf() print to the same
      destination when monitor_printf() is used correctly, i.e. within an
      HMP monitor.  Elsewhere, monitor_printf() does nothing, while
      error_report_err() reports to stderr.
      
      Most changed functions are HMP command handlers.  These should only
      run within an HMP monitor.  The one exception is bdrv_password_cb(),
      which should also only run within an HMP monitor.
      
      Four command handlers prefix the error message with the command name:
      balloon, migrate_set_capability, migrate_set_parameter, migrate.
      Pointless, drop.
      
      Unlike monitor_printf(), error_report_err() uses the error whole
      instead of just its message obtained with error_get_pretty().  This
      avoids suppressing its hint (see commit 50b7b000).  Example:
      
          (qemu) device_add ivshmem,id=666
          Parameter 'id' expects an identifier
          Identifiers consist of letters, digits, '-', '.', '_', starting with a letter.
          Try "help device_add" for more information
      
      The "Identifiers consist of..." line is new with this patch.
      
      Coccinelle semantic patch:
      
          @@
          expression M, E;
          @@
          -    monitor_printf(M, "%s\n", error_get_pretty(E));
          -    error_free(E);
          +    error_report_err(E);
          @r1@
          expression M, E;
          format F;
          position p;
          @@
          -    monitor_printf(M, "...%@F@\n", error_get_pretty(E));@p
          -    error_free(E);
          +    error_report_err(E);
          @script:python@
      	p << r1.p;
          @@
          print "%s:%s:%s: prefix dropped" % (p[0].file, p[0].line, p[0].column)
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1450452927-8346-4-git-send-email-armbru@redhat.com>
      193227f9
  12. 17 Dec, 2015 3 commits
    • Eric Blake's avatar
      qapi: Change munging of CamelCase enum values · d20a580b
      Eric Blake authored
      When munging enum values, the fact that we were passing the entire
      prefix + value through camel_to_upper() meant that enum values
      spelled with CamelCase could be turned into CAMEL_CASE.  However,
      this provides a potential collision (both OneTwo and One-Two would
      munge into ONE_TWO) for enum types, when the same two names are
      valid side-by-side as QAPI member names.  By changing the generation
      of enum constants to always be prefix + '_' + c_name(value,
      False).upper(), and ensuring that there are no case collisions (in
      the next patches), we no longer have to worry about names that
      would be distinct as QAPI members but collide as variant tag names,
      without having to think about what munging the heuristics in
      camel_to_upper() will actually perform on an enum value.
      
      Making the change will affect enums that did not follow coding
      conventions, using 'CamelCase' rather than desired 'lower-case'.
      
      Thankfully, there are only two culprits: InputButton and ErrorClass.
      We already tweaked ErrorClass to make it an alias of QapiErrorClass,
      where only the alias needs changing rather than the whole tree.  So
      the bulk of this change is modifying INPUT_BUTTON_WHEEL_UP to the
      new INPUT_BUTTON_WHEELUP (and likewise for WHEELDOWN).  That part
      of this commit may later need reverting if we rename the enum
      constants from 'WheelUp' to 'wheel-up' as part of moving
      x-input-send-event to a stable interface; but at least we have
      documentation bread crumbs in place to remind us (commit 513e7cdb),
      and it matches the fact that SDL constants are also spelled
      SDL_BUTTON_WHEELUP.
      
      Suggested by: Markus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1447836791-369-27-git-send-email-eblake@redhat.com>
      [Commit message tweaked]
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      d20a580b
    • Eric Blake's avatar
      qapi: Add alias for ErrorClass · f22a28b8
      Eric Blake authored
      The qapi enum ErrorClass is unusual that it uses 'CamelCase' names,
      contrary to our documented convention of preferring 'lower-case'.
      However, this enum is entrenched in the API; we cannot change
      what strings QMP outputs.  Meanwhile, we want to simplify how
      c_enum_const() is used to generate enum constants, by moving away
      from the heuristics of camel_to_upper() to a more straightforward
      c_name(N).upper() - but doing so will rename all of the ErrorClass
      constants and cause churn to all client files, where the new names
      are aesthetically less pleasing (ERROR_CLASS_DEVICENOTFOUND looks
      like we can't make up our minds on whether to break between words).
      
      So as always in computer science, solve the problem by some more
      indirection: rename the qapi type to QapiErrorClass, and add a
      new enum ErrorClass in error.h whose members are aliases of the
      qapi type, but with the spelling expected elsewhere in the tree.
      Then, when c_enum_const() changes the munging, we only have to
      adjust the one alias spot.
      
      Suggested by: Markus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1447836791-369-26-git-send-email-eblake@redhat.com>
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      f22a28b8
    • Eric Blake's avatar
      qapi: Don't let implicit enum MAX member collide · 7fb1cf16
      Eric Blake authored
      Now that we guarantee the user doesn't have any enum values
      beginning with a single underscore, we can use that for our
      own purposes.  Renaming ENUM_MAX to ENUM__MAX makes it obvious
      that the sentinel is generated.
      
      This patch was mostly generated by applying a temporary patch:
      
      |diff --git a/scripts/qapi.py b/scripts/qapi.py
      |index e6d014b..b862ec9 100644
      |--- a/scripts/qapi.py
      |+++ b/scripts/qapi.py
      |@@ -1570,6 +1570,7 @@ const char *const %(c_name)s_lookup[] = {
      |     max_index = c_enum_const(name, 'MAX', prefix)
      |     ret += mcgen('''
      |     [%(max_index)s] = NULL,
      |+// %(max_index)s
      | };
      | ''',
      |                max_index=max_index)
      
      then running:
      
      $ cat qapi-{types,event}.c tests/test-qapi-types.c |
          sed -n 's,^// \(.*\)MAX,s|\1MAX|\1_MAX|g,p' > list
      $ git grep -l _MAX | xargs sed -i -f list
      
      The only things not generated are the changes in scripts/qapi.py.
      
      Rejecting enum members named 'MAX' is now useless, and will be dropped
      in the next patch.
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1447836791-369-23-git-send-email-eblake@redhat.com>
      Reviewed-by: 's avatarJuan Quintela <quintela@redhat.com>
      [Rebased to current master, commit message tweaked]
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      7fb1cf16
  13. 26 Nov, 2015 2 commits
  14. 12 Nov, 2015 1 commit
    • Alexey Kardashevskiy's avatar
      monitor/target-ppc: Define target_get_monitor_def · 0a9516c2
      Alexey Kardashevskiy authored
      At the moment get_monitor_def() returns only registers from statically
      defined monitor_defs array. However there is a lot of BOOK3S SPRs
      which are not in the list and cannot be printed from the monitor.
      
      This adds a new target platform hook - target_get_monitor_def().
      The hook is called if a register was not found in the static
      array returned by the target_monitor_defs() hook.
      
      The hook is only defined for POWERPC, it returns registered
      SPRs and fails on unregistered ones providing the user with information
      on what is actually supported on the running CPU. The register value is
      saved as uint64_t as it is the biggest supported register size;
      target_ulong cannot be used because of the stub - it is in a "common"
      code and cannot include "cpu.h", etc; this is also why the hook prototype
      is redefined in the stub instead of being included from some header.
      
      This replaces static descriptors for GPRs, FPRs, SRs with a helper which
      looks for a value in a corresponding array in the CPUPPCState.
      The immediate effect is that all 32 SRs can be printed now (instead of 16);
      later this can be reused for VSX or TM registers.
      
      This replaces callbacks for MSR and XER with static descriptors in
      monitor_defs as they are stored in CPUPPCState.
      
      While we are here, this adds "cr" as a synonym of "ccr".
      Signed-off-by: 's avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      0a9516c2
  15. 09 Nov, 2015 1 commit
  16. 30 Oct, 2015 2 commits
  17. 29 Oct, 2015 4 commits
  18. 23 Oct, 2015 1 commit
  19. 25 Sep, 2015 2 commits
  20. 21 Sep, 2015 2 commits
    • Markus Armbruster's avatar
      qapi: New QMP command query-qmp-schema for QMP introspection · 39a18158
      Markus Armbruster authored
      qapi/introspect.json defines the introspection schema.  It's designed
      for QMP introspection, but should do for similar uses, such as QGA.
      
      The introspection schema does not reflect all the rules and
      restrictions that apply to QAPI schemata.  A valid QAPI schema has an
      introspection value conforming to the introspection schema, but the
      converse is not true.
      
      Introspection lowers away a number of schema details, and makes
      implicit things explicit:
      
      * The built-in types are declared with their JSON type.
      
        All integer types are mapped to 'int', because how many bits we use
        internally is an implementation detail.  It could be pressed into
        external interface service as very approximate range information,
        but that's a bad idea.  If we need range information, we better do
        it properly.
      
      * Implicit type definitions are made explicit, and given
        auto-generated names:
      
        - Array types, named by appending "List" to the name of their
          element type, like in generated C.
      
        - The enumeration types implicitly defined by simple union types,
          named by appending "Kind" to the name of their simple union type,
          like in generated C.
      
        - Types that don't occur in generated C.  Their names start with ':'
          so they don't clash with the user's names.
      
      * All type references are by name.
      
      * The struct and union types are generalized into an object type.
      
      * Base types are flattened.
      
      * Commands take a single argument and return a single result.
      
        Dictionary argument or list result is an implicit type definition.
      
        The empty object type is used when a command takes no arguments or
        produces no results.
      
        The argument is always of object type, but the introspection schema
        doesn't reflect that.
      
        The 'gen': false directive is omitted as implementation detail.
      
        The 'success-response' directive is omitted as well for now, even
        though it's not an implementation detail, because it's not used by
        QMP.
      
      * Events carry a single data value.
      
        Implicit type definition and empty object type use, just like for
        commands.
      
        The value is of object type, but the introspection schema doesn't
        reflect that.
      
      * Types not used by commands or events are omitted.
      
        Indirect use counts as use.
      
      * Optional members have a default, which can only be null right now
      
        Instead of a mandatory "optional" flag, we have an optional default.
        No default means mandatory, default null means optional without
        default value.  Non-null is available for optional with default
        (possible future extension).
      
      * Clients should *not* look up types by name, because type names are
        not ABI.  Look up the command or event you're interested in, then
        follow the references.
      
        TODO Should we hide the type names to eliminate the temptation?
      
      New generator scripts/qapi-introspect.py computes an introspection
      value for its input, and generates a C variable holding it.
      
      It can generate awfully long lines.  Marked TODO.
      
      A new test-qmp-input-visitor test case feeds its result for both
      tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
      QmpInputVisitor to verify it actually conforms to the schema.
      
      New QMP command query-qmp-schema takes its return value from that
      variable.  Its reply is some 85KiBytes for me right now.
      
      If this turns out to be too much, we have a couple of options:
      
      * We can use shorter names in the JSON.  Not the QMP style.
      
      * Optionally return the sub-schema for commands and events given as
        arguments.
      
        Right now qmp_query_schema() sends the string literal computed by
        qmp-introspect.py.  To compute sub-schema at run time, we'd have to
        duplicate parts of qapi-introspect.py in C.  Unattractive.
      
      * Let clients cache the output of query-qmp-schema.
      
        It changes only on QEMU upgrades, i.e. rarely.  Provide a command
        query-qmp-schema-hash.  Clients can have a cache indexed by hash,
        and re-query the schema only when they don't have it cached.  Even
        simpler: put the hash in the QMP greeting.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      39a18158
    • Markus Armbruster's avatar
      qapi: Rename qmp_marshal_input_FOO() to qmp_marshal_FOO() · 7fad30f0
      Markus Armbruster authored
      These functions marshal both input and output.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Reviewed-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
      Message-Id: <1442401589-24189-17-git-send-email-armbru@redhat.com>
      7fad30f0
  21. 16 Sep, 2015 3 commits
  22. 04 Sep, 2015 1 commit
  23. 03 Sep, 2015 2 commits