path: root/qapi-schema.json
AgeCommit message (Collapse)Author
2018-03-02qapi: Move qapi-schema.json to qapi/, rename generated filesMarkus Armbruster
Move qapi-schema.json to qapi/, so it's next to its modules, and all files get generated to qapi/, not just the ones generated for modules. Consistently name the generated files qapi-MODULE.EXT: qmp-commands.[ch] become qapi-commands.[ch], qapi-event.[ch] become qapi-events.[ch], and qmp-introspect.[ch] become qapi-introspect.[ch]. This gets rid of the temporary hacks in scripts/qapi/commands.py, scripts/qapi/events.py, and scripts/qapi/common.py. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180211093607.27351-28-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> [eblake: Fix trailing dot in tpm.c, undo temporary hack for OSX toolchain] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-02qapi: Empty out qapi-schema.jsonMarkus Armbruster
The previous commit improved compile time by including less of the generated QAPI headers. This is impossible for stuff defined directly in qapi-schema.json, because that ends up in headers that that pull in everything. Move everything but include directives from qapi-schema.json to new sub-module qapi/misc.json, then include just the "misc" shard where possible. It's possible everywhere, except: * monitor.c needs qmp-command.h to get qmp_init_marshal() * monitor.c, ui/vnc.c and the generated qapi-event-FOO.c need qapi-event.h to get enum QAPIEvent Perhaps we'll get rid of those some other day. Adding a type to qapi/migration.json now recompiles some 120 instead of 2300 out of 5100 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180211093607.27351-25-armbru@redhat.com> [eblake: rebase to master] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-02watchdog: Consolidate QAPI into single fileEric Blake
Commit f0df84c6 added watchdog-set-action in the main qapi-schema.json, but it belongs better in qapi/run-state.json alongside the definition of WatchdogAction. The command was written prior to commit 0e201d34 creating the latter file, even though it was merged after. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20180226225744.26356-1-eblake@redhat.com>
2018-03-02qapi-gen: New common driver for code and doc generatorsMarkus Armbruster
Whenever qapi-schema.json changes, we run six programs eleven times to update eleven files. Similar for qga/qapi-schema.json. This is silly. Replace the six programs by a single program that spits out all eleven files. The programs become modules in new Python package qapi, along with the helper library. This requires moving them to scripts/qapi/. While moving them, consistently drop executable mode bits. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20180211093607.27351-9-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> [eblake: move change to one-line 'blurb' earlier in series, mention mode bit change as intentional, update qapi-code-gen.txt to match actual generated events.c file] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-02-26qemu-doc: deprecate query-cpusViktor Mihajlovski
Start the deprecation period for QAPI query-cpus (replaced by query-cpus-fast) beginning with 2.12.0. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1518797321-28356-5-git-send-email-mihajlov@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-26qmp: add architecture specific cpu data for query-cpus-fastViktor Mihajlovski
The s390 CPU state can be retrieved without interrupting the VM execution. Extendend the CpuInfoFast union with architecture specific data and an implementation for s390. Return data looks like this: [ {"thread-id":64301,"props":{"core-id":0}, "arch":"s390","cpu-state":"operating", "qom-path":"/machine/unattached/device[0]","cpu-index":0}, {"thread-id":64302,"props":{"core-id":1}, "arch":"s390","cpu-state":"operating", "qom-path":"/machine/unattached/device[1]","cpu-index":1} ] Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1518797321-28356-4-git-send-email-mihajlov@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-26qmp: add query-cpus-fastLuiz Capitulino
The query-cpus command has an extremely serious side effect: it always interrupts all running vCPUs so that they can run ioctl calls. This can cause a huge performance degradation for some workloads. And most of the information retrieved by the ioctl calls are not even used by query-cpus. This commit introduces a replacement for query-cpus called query-cpus-fast, which has the following features: o Never interrupt vCPUs threads. query-cpus-fast only returns vCPU information maintained by QEMU itself, which should be sufficient for most management software needs o Drop "halted" field as it can not be retrieved in a fast way on most architectures o Drop irrelevant fields such as "current", "pc" and "arch" o Rename some fields for better clarification & proper naming standard Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Message-Id: <1518797321-28356-3-git-send-email-mihajlov@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-26qmp: expose s390-specific CPU infoViktor Mihajlovski
Presently s390x is the only architecture not exposing specific CPU information via QMP query-cpus. Upstream discussion has shown that it could make sense to report the architecture specific CPU state, e.g. to detect that a CPU has been stopped. With this change the output of query-cpus will look like this on s390: [ {"arch": "s390", "current": true, "props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0, "qom_path": "/machine/unattached/device[0]", "halted": false, "thread_id": 63115}, {"arch": "s390", "current": false, "props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1, "qom_path": "/machine/unattached/device[1]", "halted": true, "thread_id": 63116} ] This change doesn't add the s390-specific data to HMP 'info cpus'. A follow-on patch will remove all architecture specific information from there. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-10qapi-schema.json: spelling (independant comparation)Michael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-12-20qmp: remove qmp_cpuDaniel Henrique Barboza
'qmp_cpu' was implemented in commit 755f196898 ("qapi: Convert the cpu command") as a functional no-op, a QMP call that does nothing and return success. The idea, apparently, was to provide a counterpart for the HMP 'hmp_cpu' command, introduced in the same commit. After 6 years of its creation, qmp_cpu remains a functional no-op that does nothing, having no value for any caller/user. A proposal was sent to implement qmp_cpu like hmp_cpu works, but it was denied [1]. The reason is that QMP must be as stateless as possible and a function that changes its state (the current CPU monitor in the case of qmp_cpu) goes against it. Any QMP command that needs a specific monitor CPU setup must provide it in its arguments, instead of relying in the current QMP monitor state. After discussions that happened in [2] it was decided that a command that does nothing since its birth, no one uses for anything and will not be implemented, should be deprecated and erased. Given that we will *not* provide any replacement for qmp_cpu and we believe that there is no user relying on it, there is no point in adding a deprecation delay for it. So, this patch nukes qmp_cpu from QEMU code, removing both its blank implementation in qmp.c and its doc in qapi-schema.json. [1] https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg02283.html [2] https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03696.html Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> CC: Markus Armbruster <armbru@redhat.com> CC: Eric Blake <eblake@redhat.com> CC: Daniel P. Berrange <berrange@redhat.com> Message-Id: <20171220102304.8288-1-danielhb@linux.vnet.ibm.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-12-20qapi-schema: Fix query-vm-generation-id's doc comment markupMarkus Armbruster
Reported-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20171002141341.24616-2-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-10-30target/s390x: change CPU type name to "s390x-cpu"David Hildenbrand
For now, e.g. host-s390-cpu wasn't exposed to the user. cpu-add, -cpu and the CPU model qmp interfaces didn't care about the actual type, as that information was hidden. This changed with CPU hotplug via device_add. Now the type is visible to the user. Before we get that supported in a stable version, this is our last chance to change it. So change it from "s390-cpu" to "s390x-cpu", to match the architecture name. Example names are then e.g. z14-s390x-cpu or qemu-s390x-cpu. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20171020115803.14093-1-david@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2017-10-02watchdog: Allow setting action on the flyMichal Privoznik
Currently, the only time that users can set watchdog action is at the start as all we expose is this -watchdog-action command line argument. This is suboptimal when users want to plug the device later via monitor. Alternatively, they might want to change the action for already existing device on the fly. Inspired by: https://bugzilla.redhat.com/show_bug.cgi?id=1447169 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Message-Id: <35d6ce6fe3d357122d73b8272bc8198134c74104.1504771369.git.mprivozn@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> [Missing colon in doc comment fixed] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-09-19s390x: implement query-hotpluggable-cpusDavid Hildenbrand
CPU hotplug is only possible on a per core basis on s390x. So let's add possible_cpus and wire everything up properly. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-19-david@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-09-14qmp: introduce query-memory-size-summary commandVadim Galitsyn
Add a new query-memory-size-summary command which provides the following memory information in bytes: * base-memory - size of "base" memory specified with command line option -m. * plugged-memory - amount of memory that was hot-plugged. If target does not have CONFIG_MEM_HOTPLUG enabled, no value is reported. Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com> Signed-off-by: Mohammed Gamal <mohammed.gamal@profitbricks.com> Signed-off-by: Eduardo Otubo <eduardo.otubo@profitbricks.com> Signed-off-by: Vadim Galitsyn <vadim.galitsyn@profitbricks.com> Reviewed-by: Eugene Crosser <evgenii.cherkashin@profitbricks.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: qemu-devel@nongnu.org Message-Id: <20170829153022.27004-3-vadim.galitsyn@profitbricks.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Fixup comments as per Igor's review Added 'of' from Vadim's reply
2017-09-04qapi-schema: Improve section headingsMarkus Armbruster
The generated QEMU QMP reference is now structured as follows: 1.1 Introduction 1.2 Stability Considerations 1.3 Common data types 1.4 Socket data types 1.5 VM run state 1.6 Cryptography 1.7 Block devices 1.7.1 Block core (VM unrelated) 1.7.2 QAPI block definitions (vm unrelated) 1.8 Character devices 1.9 Net devices 1.10 Rocker switch device 1.11 TPM (trusted platform module) devices 1.12 Remote desktop 1.12.1 Spice 1.12.2 VNC 1.13 Input 1.14 Migration 1.15 Transactions 1.16 Tracing 1.17 QMP introspection 1.18 Miscellanea Section "1.18 Miscellanea" is still too big: it documents 134 symbols. Section "1.7.1 Block core (VM unrelated)" is also rather big: 128 symbols. All the others are of reasonable size. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-17-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-09-04qapi-schema: Move queries from common.json to qapi-schema.jsonMarkus Armbruster
query-version and query-commands are in common.json for no good reason. Several similar queries are in qapi-schema.json. Move them there. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-16-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-09-04qapi-schema: Make block-core.json self-containedMarkus Armbruster
Except for block-core.json, the sub-schemas are self-contained: if they use a symbol defined in another sub-schema, they include that sub-schema. To check, feed the sub-schema to qapi2texi (or any other QAPI generator) along with the pragma from qapi-schema.json. Fix up things to make block-core.json self-contained, too. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-15-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-09-04qapi-schema: Fold event.json back into qapi-schema.jsonMarkus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-14-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-09-04qapi-schema: Collect TPM stuff in qapi/tpm.jsonMarkus Armbruster
Sadly, we don't have a TPM maintainer, not even a MAINTAINERS entry. Create one, and mark it orphaned. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-12-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-09-04qapi-schema: Collect transaction stuff in qapi/transaction.jsonMarkus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-11-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-09-04qapi-schema: Collect migration stuff in qapi/migration.jsonMarkus Armbruster
Cc: Juan Quintela <quintela@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-10-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-09-04qapi-schema: Collect UI stuff in qapi/ui.jsonMarkus Armbruster
UI stuff is remote desktop stuff (Spice, VNC) and input stuff (mouse, keyboard). Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-9-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
2017-09-04qapi-schema: Collect net device stuff in qapi/net.jsonMarkus Armbruster
Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-8-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-09-04qapi-schema: Collect char device stuff in qapi/char.jsonMarkus Armbruster
Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-7-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-09-04qapi-schema: Collect run state stuff in qapi/run-state.jsonMarkus Armbruster
Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-6-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-09-04qapi-schema: Collect sockets stuff in qapi/sockets.jsonMarkus Armbruster
Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503602048-12268-5-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-09-04qapi-schema: Rocker doc section contains unrelated stuff, fixMarkus Armbruster
Bug: section "Rocker switch device" starts with the rocker stuff, but then has unrelated stuff, like ReplayMode, xen-load-devices-state, ... Cause: rocker.json is included in the middle of section "QMP commands". Fix: include it in a sane place, namely next to the other sub-schemas. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1503602048-12268-4-git-send-email-armbru@redhat.com>
2017-09-04qapi-schema: Document how generated documentation is orderedMarkus Armbruster
Documentation generated with qapi2texi.py is in source order, with included sub-schemas inserted at the first include directive (subsequent include directives have no effect). To get a sane and stable order, it's best to include each sub-schema just once, or include it first in qapi-schema.json. Document that. While there, drop a few redundant comments. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1503602048-12268-2-git-send-email-armbru@redhat.com>
2017-07-31docs: fix broken paths to docs/interop dirCleber Rosa
With the move of some docs to docs/interop on d59157e, a couple of references were not updated. Signed-off-by: Cleber Rosa <crosa@redhat.com> [PMD: fixed a typo and another reference of docs/interop/qmp-spec.txt] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2017-07-28ui: drop ac_search and ac_stopGerd Hoffmann
Both keys exist already: "ac_search" is "find" and "ac_stop" is "stop". Fixes: 37810e80553c19f0dac3644924895a9bf5c70785 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170728063415.27480-1-kraxel@redhat.com
2017-07-27ui: drop altgr and altgr_r QKeyCodesGerd Hoffmann
The right alt key (alt_r aka KEY_RIGHTALT) is used for AltGr. The altgr and altgr_r keys simply don't exist. Drop them. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20170727104720.30061-1-kraxel@redhat.com
2017-07-27ui: add multimedia keysGerd Hoffmann
Add multimedia keys to QKeyCodes and to the keymaps. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20170726152918.11995-5-kraxel@redhat.com
2017-07-24migration: Use JSON null instead of "" to reset parameter to defaultMarkus Armbruster
migrate-set-parameters sets migration parameters according to is arguments like this: * Present means "set the parameter to this value" * Absent means "leave the parameter unchanged" * Except for parameters tls_creds and tls_hostname, "" means "reset the parameter to its default value The first two are perfectly normal: presence of the parameter makes the command do something. The third one overloads the parameter with a second meaning. The overloading is *implicit*, i.e. it's not visible in the types. Works here, because "" is neither a valid TLS credentials ID, nor a valid host name. Pressing argument values the schema accepts, but are semantically invalid, into service to mean "reset to default" is not general, as suitable invalid values need not exist. I also find it ugly. To clean this up, we could add a separate flag argument to ask for "reset to default", or add a distinct value to @tls_creds and @tls_hostname. This commit implements the latter: add JSON null to the values of @tls_creds and @tls_hostname, deprecate "". Because we're so close to the 2.10 freeze, implement it in the stupidest way possible: have qmp_migrate_set_parameters() rewrite null to "" before anything else can see the null. The proper way to do it would be rewriting "" to null, but that requires fixing up code to work with null. Add TODO comments for that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-07-24migration: Unshare MigrationParameters struct for nowMarkus Armbruster
Commit de63ab6 "migrate: Share common MigrationParameters struct" reused MigrationParameters for the arguments of migrate-set-parameters, with the following rationale: It is rather verbose, and slightly error-prone, to repeat the same set of parameters for input (migrate-set-parameters) as for output (query-migrate-parameters), where the only difference is whether the members are optional. We can just document that the optional members will always be present on output, and then share a common struct between both commands. The next patch can then reduce the amount of code needed on input. I need to unshare them to correct a design flaw in a stupid, but minimally invasive way, in the next commit. We can restore the sharing when we redo that patch in a less stupid way. Add a suitable TODO comment. Note that I revert only the sharing part of commit de63ab6, not the part that made the members of query-migrate-parameters' result optional. The schema (and thus introspection) remains inaccurate for query-migrate-parameters. If we decide not to restore the sharing, we should revert that part, too. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-07-24migration: Clean up around tls_creds, tls_hostnameMarkus Armbruster
Optional MigrationParameters members tls_creds and tls_hostname can't actually be absent outside qmp_migrate_set_parameters() since commit 4af245d (v2.9.0). Note that commit 4af245d reverted the part of commit de63ab6 (v2.8.0) that made tls_creds and tls_hostname absent instead of "" in the value of query-migrate-parameters, even though commit de63ab6 called that a mistake. What a mess. Drop the redundant tests for presence, and update documentation. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-07-20vnc: Clarify documentation of QMP command changeMarkus Armbruster
QMP command { "execute": "change", "arguments": { "device": "vnc", "target": "password", "arg": PWD } } behaves just like { "execute": "change-vnc-password", "arguments": { "password", "arg": PWD } } Their documentation differs, however. According to change-vnc-password's documentation, "an empty password [...] will set the password to the empty string", while change's documentation claims "no future logins will be allowed". The former is actually correct. Replace the incorrect claim by a reference to change-vnc-password. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 1500448182-21376-1-git-send-email-armbru@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-07-17qmp: Include parent type on 'qom-list-types' outputEduardo Habkost
Include name of parent type of each type on 'qom-list-types' output. Without this, there's no way to figure out the parents of a given type without making additional 'qom-list-types' queries. In addition to the test case for the new feature, update the abstract-interface test case to use the new field and avoid the "qom-list-types implements=object" trick. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170707122215.8819-4-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-07-17qmp: Include 'abstract' field on 'qom-list-types' outputEduardo Habkost
A client may be interested in getting the list of both abstract and non-abstract types. Instead of requiring them to make multiple queries with different filter arguments, just return an 'abstract' field in 'qom-list-types'. In addition to the new test code for validating this field, update the abstract-interfaces test case to query for all 'interface' subtypes (including abstract ones), and to look at the 'abstract' field directly. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170707122215.8819-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-07-14char: chardevice hotswapAnton Nefedov
This patch adds a possibility to change a char device without a frontend removal. Ideally, it would have to happen transparently to a frontend, i.e. frontend would continue its regular operation. However, backends are not stateless and are set up by the frontends via qemu_chr_fe_<> functions, and it's not (generally) possible to replay that setup entirely in a backend code, as different chardevs respond to the setup calls differently, so do frontends work differently basing on those setup responses. Moreover, some frontend can generally get and save the backend pointer (qemu_chr_fe_get_driver()), and it will become invalid after backend change. So, a frontend which would like to support chardev hotswap has to register a "backend change" handler, and redo its backend setup there. Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <1499342940-56739-4-git-send-email-anton.nefedov@virtuozzo.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-11block: rip out all traces of password promptingDaniel P. Berrange
Now that qcow & qcow2 are wired up to get encryption keys via the QCryptoSecret object, nothing is relying on the interactive prompting for passwords. All the code related to password prompting can thus be ripped out. Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-17-berrange@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-29Add chardev-send-break monitor commandStefan Fritsch
Sending a break on a serial console can be useful for debugging the guest. But not all chardev backends support sending breaks (only telnet and mux do). The chardev-send-break command allows to send a break even if using other backends. Signed-off-by: Stefan Fritsch <sf@sfritsch.de> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20170611074817.13621-1-sf@sfritsch.de> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Use 'send a break' in all 3 pieces of text as suggested by eblake
2017-06-28migration: add "return-path" capabilityPeter Xu
When this capability is enabled, QEMU will use the return path even for precopy migration. This is helpful at least in one case when destination failed to load the image while source quited without confirmation. With return path, source will wait for the last response from destination, and if destination fails, it'll fail the migration on source, then the guest can be run again on the source (rather than assuming to be good, then the guest will be lost after source quits). It needs to be enabled explicitly on source, otherwise disabled. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1498472935-14461-1-git-send-email-peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-05-30Merge remote-tracking branch 'armbru/tags/pull-qapi-2017-05-23' into stagingStefan Hajnoczi
QAPI patches for 2017-05-23 # gpg: Signature made Tue 23 May 2017 12:33:32 PM BST # gpg: using RSA key 0x3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * armbru/tags/pull-qapi-2017-05-23: qapi-schema: Remove obsolete note from ObjectTypeInfo block: Use QDict helpers for --force-share shutdown: Expose bool cause in SHUTDOWN and RESET events shutdown: Add source information to SHUTDOWN and RESET shutdown: Preserve shutdown cause through replay shutdown: Prepare for use of an enum in reset/shutdown_request shutdown: Simplify shutdown_signal sockets: Plug memory leak in socket_address_flatten() scripts/qmp/qom-set: fix the value argument passed to srv.command() Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-23qapi-schema: Remove obsolete note from ObjectTypeInfoEduardo Habkost
The "This command is experimental" note in ObjectTypeInfo is obsolete since 2012. Commit 5192082097549c5b3aa7c913c6853d97a68172cb removed the warning from the qom-list-types command documentation, but we forgot to remove the warning from ObjectTypeInfo. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170516205351.12101-1-ehabkost@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-05-18migration: Create block capabilityJuan Quintela
Create one capability for block migration and one parameter for incremental block migration. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> --- - address all Markus comments - use Markus and Eric text descriptions - change logic another time - improve text messages
2017-05-11numa: add '-numa cpu,...' option for property based node mappingIgor Mammedov
legacy cpu to node mapping is using cpu index values to map VCPU to node with help of '-numa node,nodeid=node,cpus=x[-y]' option. However cpu index is internal concept and QEMU users have to guess /reimplement qemu's logic/ to map it to a concrete cpu socket/core/thread to make sane CPUs placement across numa nodes. This patch allows to map cpu objects to numa nodes using the same properties as used for cpus with -device/device_add (socket-id/core-id/thread-id/node-id). At present valid properties/values to address CPUs could be fetched using hotpluggable-cpus monitor/qmp command, it will require user to start qemu twice when creating domain to fetch possible CPUs for a machine type/-smp layout first and then the second time with numa explicit mapping for actual usage. The first step results could be saved and reused to set/change mapping later as far as machine type/-smp stays the same. Proposed impl. supports exact and wildcard matching to simplify CLI and allow to set mapping for a specific cpu or group of cpu objects specified by matched properties. For example: # exact mapping x86 -numa cpu,node-id=x,socket-id=y,core-id=z,thread-id=n # exact mapping SPAPR -numa cpu,node-id=x,core-id=y # wildcard mapping, all cpu objects that match socket-id=y # are mapped to node-id=x -numa cpu,node-id=x,socket-id=y Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1494415802-227633-18-git-send-email-imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11QMP: include CpuInstanceProperties into query_cpus output outputIgor Mammedov
if board supports CpuInstanceProperties, report them for each CPU thread listed. Main motivation for this is to provide these properties introspection via QMP interface for using in test cases to verify numa node to cpu mapping, which includes not only boards that support cpu hotplug and have this info in query-hotpluggable-cpus (pc/spapr) but also for boards that don't not support hotpluggable-cpus but support numa mapping (virt-arm). Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1494415802-227633-12-git-send-email-imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-11numa: Allow setting NUMA distance for different NUMA nodesHe Chen
This patch is going to add SLIT table support in QEMU, and provides additional option `dist` for command `-numa` to allow user set vNUMA distance by QEMU command. With this patch, when a user wants to create a guest that contains several vNUMA nodes and also wants to set distance among those nodes, the QEMU command would like: ``` -numa node,nodeid=0,cpus=0 \ -numa node,nodeid=1,cpus=1 \ -numa node,nodeid=2,cpus=2 \ -numa node,nodeid=3,cpus=3 \ -numa dist,src=0,dst=1,val=21 \ -numa dist,src=0,dst=2,val=31 \ -numa dist,src=0,dst=3,val=41 \ -numa dist,src=1,dst=2,val=21 \ -numa dist,src=1,dst=3,val=31 \ -numa dist,src=2,dst=3,val=21 \ ``` Signed-off-by: He Chen <he.chen@linux.intel.com> Message-Id: <1493260558-20728-1-git-send-email-he.chen@linux.intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-09sockets: Limit SocketAddressLegacy to external interfacesMarkus Armbruster
SocketAddressLegacy is a simple union, and simple unions are awkward: they have their variant members wrapped in a "data" object on the wire, and require additional indirections in C. SocketAddress is the equivalent flat union. Convert all users of SocketAddressLegacy to SocketAddress, except for existing external interfaces. See also commit fce5d53..9445673 and 85a82e8..c5f1ae3. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1493192202-3184-7-git-send-email-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> [Minor editing accident fixed, commit message and a comment tweaked] Signed-off-by: Markus Armbruster <armbru@redhat.com>