aboutsummaryrefslogtreecommitdiff
path: root/qapi-schema.json
AgeCommit message (Collapse)Author
2016-09-19Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2016-09-19' into ↵Peter Maydell
staging QAPI patches for 2016-09-19 # gpg: Signature made Mon 19 Sep 2016 17:27:42 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 * remotes/armbru/tags/pull-qapi-2016-09-19: Replace qmp-commands.hx by docs/qmp-commands.txt qmp-commands.hx: fix some styling build-sys: remove qmp-commands-old.h monitor: use qmp_dispatch() tests: add a test to check invalid args qapi: check invalid arguments on no-args commands qapi: remove the "middle" mode monitor: remove mhandler.cmd_new monitor: implement 'qmp_query_commands' without qmp_cmds monitor: use qmp_find_command() (using generated qapi code) qapi: export the marshallers qmp: Hack to keep commands configuration-specific qapi: Support unregistering QMP commands monitor: register gen:false commands manually monitor: simplify invalid_qmp_mode() qapi-schema: add 'device_add' qapi-schema: use generated marshaller for 'qmp_capabilities' build-sys: define QEMU_VERSION_{MAJOR, MINOR, MICRO} Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-09-19qapi-schema: add 'device_add'Marc-André Lureau
Even though device_add is not fully qapi'fied, we may add it to the json schema with 'gen': false, so registration and documentation can be generated. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20160912091913.15831-4-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-09-19qapi-schema: use generated marshaller for 'qmp_capabilities'Marc-André Lureau
qapi'fy the 'qmp_capabilities' command, makes the command visible in query-qmp-schema. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20160912091913.15831-3-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-09-19QMP: fixup typos and whitespace damageChristian Borntraeger
Fixup some typos and whitespace damage introduced by the CPU model patches for s390. Reported-by: Eric Blake <eblake@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: implement QMP interface "query-cpu-model-baseline"David Hildenbrand
Let's implement that interface by reusing our conversion code and lookup code for CPU definitions. In order to find a compatible CPU model, we first detect the maximum possible CPU generation and then try to find a maximum model, satisfying all base features (not exceeding the maximum generation). Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-31-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: implement QMP interface "query-cpu-model-comparison"David Hildenbrand
Let's implement that interface by reusing our convertion code implemented for expansion. We use CPU generations and CPU features to calculate the result. This means, that a zEC12 cannot simply be converted into a z13 by stripping of features. This is required, as other magic values (e.g. maximum address sizes) belong to a CPU generation and cannot simply be emulated by an older generation. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-30-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: implement QMP interface "query-cpu-model-expansion"David Hildenbrand
In order to expand CPU models, we create temporary cpus that handle the feature/group parsing. Only CPU feature properties are expanded. When converting the data structure back, we always fall back to the static base CPU model, which is by definition migration-safe. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-29-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06qmp: add QMP interface "query-cpu-model-baseline"David Hildenbrand
Let's provide a standardized interface to baseline two CPU models, to create a third, compatible one. This is especially helpful when two CPU models are not identical, but a CPU model is required that is guaranteed to run under both configurations, where the original models run. "query-cpu-model-baseline" takes two CPU models and returns a third, compatible model. The result will always be a static CPU model. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-28-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06qmp: add QMP interface "query-cpu-model-comparison"David Hildenbrand
Let's provide a standardized interface to compare two CPU models. "query-cpu-model-compare" takes two models and returns how they compare in a specific configuration. The result will give guarantees about runnability. E.g. if a CPU model A is a subset of CPU model B, model A is guaranteed to run in configurations where model B runs, but not the other way around (might or might not run). Usually, CPU features or CPU generations are used to calculate the result. If a model is not guaranteed to run in a certain environment (e.g. incompatible), a compatible one can be created by "baselining" both models (follow up patch). Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-27-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06qmp: add QMP interface "query-cpu-model-expansion"David Hildenbrand
Let's provide a standardized interface to expand CPU models. This interface can be used by tooling to get details about a specific CPU model in a certain configuration, e.g. about the "host" model. To take care of all architectures, two detail levels for an expansion are introduced. Certain architectures might not support all detail levels. While "full" will expand and indicate all relevant properties/features of a CPU model, "static" expands to a static base CPU model, that will never change between QEMU versions and therefore have the same features when used under different compatibility machines. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-26-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05qmp: details about CPU definitions in query-cpu-definitionsDavid Hildenbrand
It might be of interest for tooling whether a CPU definition can be safely used when migrating, or if e.g. CPU features might get lost during migration when migrationg from/to a different QEMU version or host, even if the same compatibility machine is used. Also, we want to know if a CPU definition is static and will never change. Beause these definitions can then be used independantly of a compatibility machine and will always have the same feature set, they can e.g. be used to indicate the "host" model in libvirt later on. Let's add two return values to query-cpu-definitions, stating for each returned CPU definition, if it is migration-safe and if it is static. While "migration-safe" is optional, "static" will be set to "false" automatically by all implementing architectures. If a model really was static all the time and will be in the future, this can simply be changed later. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-2-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-19qapi: Change Netdev into a flat unionEric Blake
This is a mostly-mechanical conversion that creates a new flat union 'Netdev' QAPI type that covers all the branches of the former 'NetClientOptions' simple union, where the branches are now listed in a new 'NetClientDriver' enum rather than generated from the simple union. The existence of a flat union has no change to the command line syntax accepted for new code, and will make it possible for a future patch to switch the QMP command to parse a boxed union for no change to valid QMP; but it does have some ripple effect on the C code when dealing with the new types. While making the conversion, note that the 'NetLegacy' type remains unchanged: it applies only to legacy command line options, and will not be ported to QMP, so it should remain a wrapper around a simple union; to avoid confusion, the type named 'NetClientOptions' is now gone, and we introduce 'NetLegacyOptions' in its place. Then, in the C code, we convert from NetLegacy to Netdev as soon as possible, so that the bulk of the net stack only has to deal with one QAPI type, not two. Note that since the old legacy code always rejected 'hubport', we can just omit that branch from the new 'NetLegacyOptions' simple union. Based on an idea originally by Zoltán Kővágó <DirtY.iCE.hu@gmail.com>: Message-Id: <01a527fbf1a5de880091f98cf011616a78adeeee.1441627176.git.DirtY.iCE.hu@gmail.com> although the sed script in that patch no longer applies due to other changes in the tree since then, and I also did some manual cleanups (such as fixing whitespace to keep checkpatch happy). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1468468228-27827-13-git-send-email-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Fixup from Eric squashed in] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-07-07tap: vhost busy polling supportJason Wang
This patch add the capability of basic vhost net busy polling which is supported by recent kernel. User could configure the maximum number of us that could be spent on busy polling through a new property of tap "poll-us". Cc: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2016-06-27qapi: keep names in 'CpuInstanceProperties' in sync with struct CPUCorePeter Krempa
struct CPUCore uses 'id' suffix in the property name. As docs for query-hotpluggable-cpus state that the cpu core properties should be passed back to device_add by management in case new members are added and thus the names for the fields should be kept in sync. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> [dwg: Removed a duplicated word in comment] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-06-27qapi: Report support for -device cpu hotplug in query-machinesPeter Krempa
For management apps it's very useful to know whether the selected machine type supports cpu hotplug via the new -device approach. Using the presence of 'query-hotpluggable-cpus' alone is not enough as a witness. Add a property to 'MachineInfo' called 'hotpluggable-cpus' that will report the presence of this feature. Example of output: { "hotpluggable-cpus": false, "name": "mac99", "cpu-max": 1 }, { "hotpluggable-cpus": true, "name": "pseries-2.7", "is-default": true, "cpu-max": 255, "alias": "pseries" }, Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-06-24acpi: cpuhp: add cpu._OST handlingIgor Mammedov
it adds HW and AML parts for CPU_Device._OST method handling to allow OSPM reports status of hot-(un)plug operation. And extends QMP command query-acpi-ospm-status to report CPU's OST info along with already reported PC-DIMM devices. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-06-17QMP: Add query-hotpluggable-cpusIgor Mammedov
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: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-06-16migration: fix typos in qapi-schema from latest migration additionsDaniel P. Berrange
Recent migration QAPI enhancements had a few spelling mistakes and also incorrect version number in a few places. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1464776234-9910-2-git-send-email-berrange@redhat.com Message-Id: <1464776234-9910-2-git-send-email-berrange@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-16Postcopy: Add stats on page requestsDr. David Alan Gilbert
On the source, add a count of page requests received from the destination. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Denis V. Lunev <den@openvz.org> Message-id: 1465816605-29488-4-git-send-email-dgilbert@redhat.com Message-Id: <1465816605-29488-4-git-send-email-dgilbert@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-06-13Introduce "xen-load-devices-state"Wen Congyang
Introduce a "xen-load-devices-state" QAPI command that can be used to load the state of all devices, but not the RAM or the block devices of the VM. We only have hmp commands savevm/loadvm, and qmp commands xen-save-devices-state. We use this new command for COLO: 1. suspend both primary vm and secondary vm 2. sync the state 3. resume both primary vm and secondary vm In such case, we need to update all devices' state in any time. Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Signed-off-by: Changlong Xie <xiecl.fnst@cn.fujitsu.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
2016-05-26migration: define 'tls-creds' and 'tls-hostname' migration parametersDaniel P. Berrange
Define two new migration parameters to be used with TLS encryption. The 'tls-creds' parameter provides the ID of an instance of the 'tls-creds' object type, or rather a subclass such as 'tls-creds-x509'. Providing these credentials will enable use of TLS on the migration data stream. If using x509 certificates, together with a migration URI that does not include a hostname, the 'tls-hostname' parameter provides the hostname to use when verifying the server's x509 certificate. This allows TLS to be used in combination with fd: and exec: protocols where a TCP connection is established by a 3rd party outside of QEMU. NB, this requires changing the migrate_set_parameter method in the HMP to accept a 's' (string) value instead of 'i' (integer). This is backwards compatible, because the parsing of strings allows the quotes to be optional, thus any integer is also a valid string. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1461751518-12128-26-git-send-email-berrange@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-05-26migration: add reporting of errors for outgoing migrationDaniel P. Berrange
Currently if an application initiates an outgoing migration, it may or may not, get an error reported back on failure. If the error occurs synchronously to the 'migrate' command execution, the client app will see the error message. This is the case for DNS lookup failures. If the error occurs asynchronously to the monitor command though, the error will be thrown away and the client left guessing about what went wrong. This is the case for failure to connect to the TCP server (eg due to wrong port, or firewall rules, or other similar errors). In the future we'll be adding more scope for errors to happen asynchronously with the TLS protocol handshake. TLS errors are hard to diagnose even when they are well reported, so discarding errors entirely will make it impossible to debug TLS connection problems. Management apps which do migration are already using 'query-migrate' / 'info migrate' to check up on progress of background migration operations and to see their end status. This is a fine place to also include the error message when things go wrong. This patch thus adds an 'error-desc' field to the MigrationInfo struct, which will be populated when the 'status' is set to 'failed': (qemu) migrate -d tcp:localhost:9001 (qemu) info migrate capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off x-postcopy-ram: off Migration status: failed (Error connecting to socket: Connection refused) total time: 0 milliseconds In the HMP, when doing non-detached migration, it is also possible to display this error message directly to the app. (qemu) migrate tcp:localhost:9001 Error connecting to socket: Connection refused Or with QMP { "execute": "query-migrate", "arguments": {} } { "return": { "status": "failed", "error-desc": "address resolution failed for myhost:9000: No address associated with hostname" } } Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <1461751518-12128-11-git-send-email-berrange@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-05-23migration: Promote improved autoconverge commands out of experimental stateJason J. Herne
The new autoconverge throttling commands have been tested for a release now. It is time to move them out of the experimental state. Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com> Message-Id: <1461262038-8197-1-git-send-email-jjherne@linux.vnet.ibm.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-04-01slirp: Allow disabling IPv4 or IPv6Samuel Thibault
Add ipv4 and ipv6 boolean options, so the user can setup IPv4-only and IPv6-only network environments. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
2016-03-30arm: qmp: add query-gic-capabilities interfacePeter Xu
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: Peter Xu <peterx@redhat.com> Reviewed-by: Eric 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: Peter Maydell <peter.maydell@linaro.org>
2016-03-29Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into ↵Peter Maydell
staging slirp updates # gpg: Signature made Tue 29 Mar 2016 00:16:05 BST using RSA key ID FB6B2F1D # gpg: Good signature from "Samuel Thibault <samuel.thibault@gnu.org>" # gpg: aka "Samuel Thibault <sthibault@debian.org>" # gpg: aka "Samuel Thibault <samuel.thibault@inria.fr>" # gpg: aka "Samuel Thibault <samuel.thibault@labri.fr>" # gpg: aka "Samuel Thibault <samuel.thibault@ens-lyon.org>" # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 900C B024 B679 31D4 0F82 304B D017 8C76 7D06 9EE6 # Subkey fingerprint: F632 74CD C630 0873 CB3D 29D9 E3E5 1CE8 FB6B 2F1D * remotes/thibault/tags/samuel-thibault: Rework ipv6 options Use C99 flexible array instead of 1-byte trailing array Avoid embedding struct mbuf in other structures slirp: send icmp6 errors when UDP send failed slirp: Fix memory leak on small incoming ipv4 packet Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-29Rework ipv6 optionsSamuel Thibault
Rename the recently-added ip6-foo options into ipv6-foo options, to make them coherent with other ipv6 options. Also rework the documentation. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-23qapi-schema.json: Add power and keypad equal keysJohn Arbuckle
Add the power and keypad equal keys. These keys are found on a real Macintosh keyboard. Signed-off-by: John Arbuckle <programmingkidx@gmail.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-03-18qapi: Use anonymous bases in QMP flat unionsEric Blake
Now that the generator supports it, we might as well use an anonymous base rather than breaking out a single-use Base structure, for all three of our current QMP flat unions. Oddly enough, this change does not affect the resulting introspection output (because we already inline the members of a base type into an object, and had no independent use of the base type reachable from a command). The case_whitelist now has to list the name of an implicit type; which is not too bad (consider it a feature if it makes it harder for developers to make the whitelist grow :) Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1458254921-17042-16-git-send-email-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-03-15qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addressesYann Bordenave
This patch adds parameters to manage some new options in the qemu -net command. Slirp IPv6 address, network prefix, and DNS IPv6 address can be given in argument to the qemu command. Defaults parameters are respectively fec0::2, fec0::, /64 and fec0::3. Signed-off-by: Yann Bordenave <meow@meowstars.org> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
2016-03-11postcopy: Remove the x-Dr. David Alan Gilbert
Postcopy seems to have survived a cycle with only a few fixes, and Jiri has the current libvirt wired up and working ( https://www.redhat.com/archives/libvir-list/2016-March/msg00080.html ) so remove the experimental tag. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1457690016-9070-3-git-send-email-dgilbert@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-03-05chardev: Drop useless ChardevDummy typeEric Blake
Commit d0d7708b made ChardevDummy be an empty wrapper type around ChardevCommon. But there is no technical reason for this indirection, so simplify the code by directly using the base type. Also change the fallback assignment to assign u.null rather than u.data, since a future patch will remove the data member of the C struct generated for QAPI unions. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1457106160-23614-1-git-send-email-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-03-01qapi: promote input-send-event to stableGerd Hoffmann
With all fixups being in place now, we can promote input-send-event to stable abi by removing the x- prefix. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-01qapi: rename InputAxis values.Gerd Hoffmann
Lowercase them. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-01qapi: rename input buttonsGerd Hoffmann
All lowercase, use-dash instead of CamelCase. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-01qapi: switch x-input-send-event from console to device+headGerd Hoffmann
Use display device qdev id and head number instead of console index to specify the QemuConsole. This makes things consistent with input devices (for input routing) and vnc server configuration, which both use display and head too. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2016-02-22Dump: add qmp command "query-dump"Peter Xu
When dump-guest-memory is requested with detach flag, after its return, user could query its status using "query-dump" command (with no argument). The result contains: - status: current dump status - completed: bytes written in the latest dump - total: bytes to write in the latest dump From completed and total, we could know how much work finished by calculating: 100.0 * completed / total (%) Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1455772616-8668-10-git-send-email-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-02-22dump-guest-memory: using static DumpState, add DumpStatusPeter Xu
Instead of malloc/free each time for DumpState, make it static. Added DumpStatus to show status for dump. This is to be used for detached dump. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-Id: <1455772616-8668-4-git-send-email-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-02-22dump-guest-memory: add "detach" flag for QMP/HMP interfaces.Peter Xu
This patch only adds the interfaces, but does not implement them. "detach" parameter is made optional, to make sure that all the old dump-guest-memory requests will still be able to work. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-Id: <1455772616-8668-3-git-send-email-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-26char: introduce support for TLS encrypted TCP chardev backendDaniel P. Berrange
This integrates support for QIOChannelTLS object in the TCP chardev backend. If the 'tls-creds=NAME' option is passed with the '-chardev tcp' argument, then it will setup the chardev such that the client is required to establish a TLS handshake when connecting. There is no support for checking the client certificate against ACLs in this initial patch. This is pending work to QOM-ify the ACL object code. A complete invocation to run QEMU as the server for a TLS encrypted serial dev might be $ qemu-system-x86_64 \ -nodefconfig -nodefaults -device sga -display none \ -chardev socket,id=s0,host=127.0.0.1,port=9000,tls-creds=tls0,server \ -device isa-serial,chardev=s0 \ -object tls-creds-x509,id=tls0,endpoint=server,verify-peer=off,\ dir=/home/berrange/security/qemutls To test with the gnutls-cli tool as the client: $ gnutls-cli --priority=NORMAL -p 9000 \ --x509cafile=/home/berrange/security/qemutls/ca-cert.pem \ 127.0.0.1 If QEMU was told to use 'anon' credential type, then use the priority string 'NORMAL:+ANON-DH' with gnutls-cli Alternatively, if setting up a chardev to operate as a client, then the TLS credentials registered must be for the client endpoint. First a TLS server must be setup, which can be done with the gnutls-serv tool $ gnutls-serv --priority=NORMAL -p 9000 --echo \ --x509cafile=/home/berrange/security/qemutls/ca-cert.pem \ --x509certfile=/home/berrange/security/qemutls/server-cert.pem \ --x509keyfile=/home/berrange/security/qemutls/server-key.pem Then QEMU can connect with $ qemu-system-x86_64 \ -nodefconfig -nodefaults -device sga -display none \ -chardev socket,id=s0,host=127.0.0.1,port=9000,tls-creds=tls0 \ -device isa-serial,chardev=s0 \ -object tls-creds-x509,id=tls0,endpoint=client,\ dir=/home/berrange/security/qemutls Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1453202071-10289-5-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-15qemu-char: add logfile facility to all chardev backendsDaniel P. Berrange
Typically a UNIX guest OS will log boot messages to a serial port in addition to any graphical console. An admin user may also wish to use the serial port for an interactive console. A virtualization management system may wish to collect system boot messages by logging the serial port, but also wish to allow admins interactive access. Currently providing such a feature forces the mgmt app to either provide 2 separate serial ports, one for logging boot messages and one for interactive console login, or to proxy all output via a separate service that can multiplex the two needs onto one serial port. While both are valid approaches, they each have their own downsides. The former causes confusion and extra setup work for VM admins creating disk images. The latter places an extra burden to re-implement much of the QEMU chardev backends logic in libvirt or even higher level mgmt apps and adds extra hops in the data transfer path. A simpler approach that is satisfactory for many use cases is to allow the QEMU chardev backends to have a "logfile" property associated with them. $QEMU -chardev socket,host=localhost,port=9000,\ server=on,nowait,id-charserial0,\ logfile=/var/log/libvirt/qemu/test-serial0.log -device isa-serial,chardev=charserial0,id=serial0 This patch introduces a 'ChardevCommon' struct which is setup as a base for all the ChardevBackend types. Ideally this would be registered directly as a base against ChardevBackend, rather than each type, but the QAPI generator doesn't allow that since the ChardevBackend is a non-discriminated union. The ChardevCommon struct provides the optional 'logfile' parameter, as well as 'logappend' which controls whether QEMU truncates or appends (default truncate). Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com> [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-15qapi-schema: dump-guest-memory: Improve textAndrew Jones
dump-guest-memory is supported by more than just x86, however the paging option is not. (No functional change.) Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1452542185-10914-2-git-send-email-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-12-18qemu-char: convert to use error checked base64 decodeDaniel P. Berrange
Switch from using g_base64_decode over to qbase64_decode in order to get error checking of the base64 input data. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-12-17qemu-char: append opt to stop truncation of serial fileOlga Krishtal
Our QA team wants to preserve serial output of the guest in between QEMU runs to perform post-analysis. By default this behavior is off (file is truncated each time QEMU is started or device is plugged). Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Eric Blake <eblake@redhat.com> CC: Markus Armbruster <armbru@redhat.com> CC: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1449211324-17856-1-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-12-17cpu: Convert CpuInfo into flat unionEric Blake
The CpuInfo struct is used only by the 'query-cpus' output command, so we are free to modify it by adding fields (clients are already supposed to ignore unknown output fields), or by changing optional members to mandatory, while still keeping QMP wire compatibility with older versions of qemu. When qapi type CpuInfo was originally created for 0.14, we had no notion of a flat union, and instead just listed a bunch of optional fields with documentation about the mutually-exclusive choice of which instruction pointer field(s) would be provided for a given architecture. But now that we have flat unions and introspection, it is better to segregate off which fields will be provided according to the actual architecture. With this in place, we no longer need the fields to be optional, because the choice of the new 'arch' discriminator serves that role. This has an additional benefit: the old all-in-one struct was the only place in the code base that had a case-sensitive naming of members 'pc' vs. 'PC'. Separating these spellings into different branches of the flat union will allow us to add restrictions against future case-insensitive collisions, since that is generally a poor interface practice. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com> [Spelling of CPUInfo{SPARC,PPC,MIPS} fixed] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-17input: Document why x-input-send-event is still experimentalEric Blake
The x-input-send-event command was introduced in 2.2 with mention that it is experimental, but now that several releases have elapsed without any changes, it would be nice to document why that was done and should still remain experimental in 2.5. Meanwhile, our documentation states that we prefer 'lower-case', rather than 'CamelCase', for qapi enum values. The InputButton and InputAxis enums violate this convention. However, because they are currently used primarily for generating code that is used internally; and their only exposure through QMP is via the experimental 'x-input-send-event' command, we are free to change their spelling. Of course, it would be nicer to delay such a change until the same time we promote the command to non-experimental. Adding documentation will help us remember to do that rename. We have plans to tighten the qapi generator to flag instances of inconsistent use of naming conventions; if that lands first, it will just need to whitelist these exceptions until the time we settle on the final interface. Fix a typo in the docs for InputAxis while at it. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1447354243-31825-1-git-send-email-eblake@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-12Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20151112' ↵Peter Maydell
into staging migration/next for 20151112 # gpg: Signature made Thu 12 Nov 2015 16:56:44 GMT using RSA key ID 5872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" # gpg: aka "Juan Quintela <quintela@trasno.org>" * remotes/juanquintela/tags/migration/20151112: migration_init: Fix lock initialisation/make it explicit migrate-start-postcopy: Improve text Postcopy: Fix TP!=HP zero case Finish non-postcopiable iterative devices before package migration: Make 32bit linux compile with RDMA migration: print ram_addr_t as RAM_ADDR_FMT not %zx Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-11-12migrate-start-postcopy: Improve textDr. David Alan Gilbert
Improve the text in both the qapi-schema and hmp help to point out you need to set the postcopy-ram capability prior to issuing migrate-start-postcopy. Also fix the text of the migrate_start_postcopy error that deals with capabilities. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Acked-by: Jason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2015-11-12block: add transactional propertiesJohn Snow
Add both transactional properties to the QMP transactional interface, and add the BlockJobTxn that we create as a result of the err-cancel property to the BlkActionState structure. [split up from a patch originally by Stefan and Fam. --js] Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 1446765200-3054-13-git-send-email-jsnow@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-11-12qed: Implement .bdrv_drainFam Zheng
The "need_check_timer" is used to clear the "NEED_CHECK" flag in the image header after a grace period once metadata update has finished. In compliance to the bdrv_drain semantics we should make sure it remains deleted once .bdrv_drain is called. We cannot reuse qed_need_check_timer_cb because here it doesn't satisfy the assertion. Do the "plug" and "flush" calls manually. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-id: 1447064214-29930-10-git-send-email-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>