aboutsummaryrefslogtreecommitdiff
path: root/qapi/misc.json
AgeCommit message (Collapse)Author
2018-12-18qmp hmp: Make system_wakeup check wake-up support and run stateDaniel Henrique Barboza
The qmp/hmp command 'system_wakeup' is simply a direct call to 'qemu_system_wakeup_request' from vl.c. This function verifies if runstate is SUSPENDED and if the wake up reason is valid before proceeding. However, no error or warning is thrown if any of those pre-requirements isn't met. There is no way for the caller to differentiate between a successful wakeup or an error state caused when trying to wake up a guest that wasn't suspended. This means that system_wakeup is silently failing, which can be considered a bug. Adding error handling isn't an API break in this case - applications that didn't check the result will remain broken, the ones that check it will have a chance to deal with it. Adding to that, the commit before previous created a new QMP API called query-current-machine, with a new flag called wakeup-suspend-support, that indicates if the guest has the capability of waking up from suspended state. Although such guest will never reach SUSPENDED state and erroring it out in this scenario would suffice, it is more informative for the user to differentiate between a failure because the guest isn't suspended versus a failure because the guest does not have support for wake up at all. All this considered, this patch changes qmp_system_wakeup to check if the guest is capable of waking up from suspend, and if it is suspended. After this patch, this is the output of system_wakeup in a guest that does not have wake-up from suspend support (ppc64): (qemu) system_wakeup wake-up from suspend is not supported by this guest (qemu) And this is the output of system_wakeup in a x86 guest that has the support but isn't suspended: (qemu) system_wakeup Unable to wake up: guest is not in suspended state (qemu) Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20181205194701.17836-4-danielhb413@gmail.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-18qmp: query-current-machine with wakeup-suspend-supportDaniel Henrique Barboza
When issuing the qmp/hmp 'system_wakeup' command, what happens in a nutshell is: - qmp_system_wakeup_request set runstate to RUNNING, sets a wakeup_reason and notify the event - in the main_loop, all vcpus are paused, a system reset is issued, all subscribers of wakeup_notifiers receives a notification, vcpus are then resumed and the wake up QAPI event is fired Note that this procedure alone doesn't ensure that the guest will awake from SUSPENDED state - the subscribers of the wake up event must take action to resume the guest, otherwise the guest will simply reboot. At this moment, only the ACPI machines via acpi_pm1_cnt_init and xen_hvm_init have wake-up from suspend support. However, only the presence of 'system_wakeup' is required for QGA to support 'guest-suspend-ram' and 'guest-suspend-hybrid' at this moment. This means that the user/management will expect to suspend the guest using one of those suspend commands and then resume execution using system_wakeup, regardless of the support offered in system_wakeup in the first place. This patch creates a new API called query-current-machine [1], that holds a new flag called 'wakeup-suspend-support' that indicates if the guest supports wake up from suspend via system_wakeup. The machine is considered to implement wake-up support if a call to a new 'qemu_register_wakeup_support' is made during its init, as it is now being done inside acpi_pm1_cnt_init and xen_hvm_init. This allows for any other machine type to declare wake-up support regardless of ACPI state or wakeup_notifiers subscription, making easier for newer implementations that might have their own mechanisms in the future. This is the expected output of query-current-machine when running a x86 guest: {"execute" : "query-current-machine"} {"return": {"wakeup-suspend-support": true}} Running the same x86 guest, but with the --no-acpi option: {"execute" : "query-current-machine"} {"return": {"wakeup-suspend-support": false}} This is the output when running a pseries guest: {"execute" : "query-current-machine"} {"return": {"wakeup-suspend-support": false}} With this extra tool, management can avoid situations where a guest that does not have proper suspend/wake capabilities ends up in inconsistent state (e.g. https://github.com/open-power-host-os/qemu/issues/31). [1] the decision of creating the query-current-machine API is based on discussions in the QEMU mailing list where it was decided that query-target wasn't a proper place to store the wake-up flag, neither was query-machines because this isn't a static property of the machine object. This new API can then be used to store other dynamic machine properties that are scattered around the code ATM. More info at: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04235.html Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20181205194701.17836-2-danielhb413@gmail.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-13qapi: break long lines at 'data' memberMarc-André Lureau
Let's break the line before 'data'. While at it, improve a bit indentation/spacing. (I removed some alignment which are not helping much readability and become quickly inconsistent) Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20181208111606.8505-26-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-12monitor: Suspend monitor instead dropping commandsPeter Xu
When a QMP client sends in-band commands more quickly that we can process them, we can either queue them without limit (QUEUE), drop commands when the queue is full (DROP), or suspend receiving commands when the queue is full (SUSPEND). None of them is ideal: * QUEUE lets a misbehaving client make QEMU eat memory without bounds. Not such a hot idea. * With DROP, the client has to cope with dropped in-band commands. To inform the client, we send a COMMAND_DROPPED event then. The event is flawed by design in two ways: it's ambiguous (see commit d621cfe0a17), and it brings back the "eat memory without bounds" problem. * With SUSPEND, the client has to manage the flow of in-band commands to keep the monitor available for out-of-band commands. We currently DROP. Switch to SUSPEND. Managing the flow of in-band commands to keep the monitor available for out-of-band commands isn't really hard: just count the number of "outstanding" in-band commands (commands sent minus replies received), and if it exceeds the limit, hold back additional ones until it drops below the limit again. Note that we need to be careful pairing the suspend with a resume, or else the monitor will hang, possibly forever. And here since we need to make sure both: (1) popping request from the req queue, and (2) reading length of the req queue will be in the same critical section, we let the pop function take the corresponding queue lock when there is a request, then we release the lock from the caller. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20181009062718.1914-2-peterx@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-11Deprecate QMP `cpu-add`Kashyap Chamarthy
The intended functionality of QMP `cpu-add` is replaced with `device_add` (and `query-hotpluggable-cpus`). So let's deprecate `cpu-add`. A complete example of vCPU hotplug with the recommended way (using `device_add`) is provided as part of a seperate docs patch. Suggested-by: Eduardo Habkost <ehabkost@redhat.com Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Message-Id: <20181030123526.26415-2-kchamart@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-10-24memory-device: introduce separate config optionDavid Hildenbrand
Some architectures might support memory devices, while they don't support DIMM/NVDIMM. So let's - Rename CONFIG_MEM_HOTPLUG to CONFIG_MEM_DEVICE - Introduce CONFIG_DIMM and use it similarly to CONFIG NVDIMM CONFIG_DIMM and CONFIG_NVDIMM require CONFIG_MEM_DEVICE. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20181005092024.14344-7-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-10-19vl, qapi: offset calculation in RTC_CHANGE event revertedArtem Pisarenko
Return value of qemu_timedate_diff(), used for calculation offset in QAPI 'RTC_CHANGE' event, restored to keep compatibility. Since it wasn't documented that difference is relative to host clock advancement, this change also adds important note to 'RTC_CHANGE' event description to highlight established implementation specifics. Signed-off-by: Artem Pisarenko <artem.k.pisarenko@gmail.com> Message-Id: <1fc12c77e8b7115d3842919a8b586d9cbe4efca6.1539846575.git.artem.k.pisarenko@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-10-11qmp, hmp: make subsystem/system-vendor identities optionalDenis V. Lunev
According to PCI specification, subsystem id and subsystem vendor id are present only in type 0 and type 2 headers (at different offsets), but not in type 1 headers. Thus we should make this data optional in struct PciDeviceId and skip reporting them via HMP if the information is not available. Additional (wrong information) about PCI bridges (Type1 devices) has been added in 5383a705 and fortunately not released. This patch fixes that problem. The problem was spotted by Markus. Signed-off-by: Denis V. Lunev <den@openvz.org> CC: "Dr. David Alan Gilbert" <dgilbert@redhat.com> CC: Eric Blake <eblake@redhat.com> CC: Markus Armbruster <armbru@redhat.com> Message-Id: <20181002135538.12113-1-den@openvz.org> Reported-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2018-10-09qapi/misc.json: Remove superfluous words in CpuModelExpansionTypeKashyap Chamarthy
Remove repetition of 'independent of'. While at it, s/QMU/QEMU in @CpuDefinitionInfo. Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Message-Id: <20181003104605.8477-1-kchamart@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> [Commit message updated as requested by Kashyap] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-09-25qmp, hmp: add PCI subsystem id and vendor id to PCI infoDenis V. Lunev
This is a long story. Red Hat has relicensed Windows KVM device drivers in 2018 and there was an agreement that to avoid WHQL driver conflict software manufacturers should set proper PCI subsystem vendor ID in their distributions. Thus PCI subsystem vendor id becomes actively used. The problem is that this field is applied by us via hardware compats. Thus technically it could be lost. This patch adds PCI susbsystem id and vendor id to exportable parameters for validation. Signed-off-by: Denis V. Lunev <den@openvz.org> CC: "Dr. David Alan Gilbert" <dgilbert@redhat.com> CC: Eric Blake <eblake@redhat.com> CC: Markus Armbruster <armbru@redhat.com> Message-Id: <20180918095852.28422-1-den@openvz.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2018-07-16cli qmp: Mark --preconfig, exit-preconfig experimentalMarkus Armbruster
Committing to the current --preconfig / exit-preconfig interface before it has seen any use is premature. Mark both as experimental, the former in documentation, the latter by renaming it to x-exit-preconfig. See the previous commit for more detailed rationale. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180705091402.26244-3-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> [Straightforward conflict with commit 514337c142f resolved]
2018-07-03qmp: Get rid of x-oob-test commandMarkus Armbruster
tests/qmp-test tests an out-of-band command overtaking a slow in-band command. To do that, it needs: 1. An in-band command that *reliably* takes long enough to be overtaken. 2. An out-of-band command to do the overtaking. 3. To avoid delays, a way to make the in-band command complete quickly after it was overtaken. To satisfy these needs, commit 469638f9cb3 provides the rather peculiar oob-capable QMP command x-oob-test: * With "lock": true, it waits for a global semaphore. * With "lock": false, it signals the global semaphore. To satisfy 1., the test runs x-oob-test in-band with "lock": true. To satisfy 2. and 3., it runs x-oob-test out-of-band with "lock": false. Note that waiting for a semaphore violates the rules for oob-capable commands. Running x-oob-test with "lock": true hangs the monitor until you run x-oob-test with "lock": false on another monitor (which you might not have set up). Having an externally visible QMP command that may hang the monitor is not nice. Let's apply a little more ingenuity to the problem. Idea: have an existing command block on reading a FIFO special file, unblock it by opening the FIFO for writing. For 1., use {"execute": "blockdev-add", "id": ID1, "arguments": { "driver": "blkdebug", "node-name": ID1, "config": FIFO, "image": { "driver": "null-co"}}} where ID1 is an arbitrary string, and FIFO is the name of the FIFO. For 2., use {"execute": "migrate-pause", "id": ID2, "control": {"run-oob": true}} where ID2 is a different arbitrary string. Since there's no migration to pause, the command will fail, but that's fine; instant failure is still a test of out-of-band responses overtaking in-band commands. For 3., open FIFO for writing. Drop QMP command x-oob-test. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180703085358.13941-6-armbru@redhat.com> [Error checking tweaked]
2018-07-03qmp: Document COMMAND_DROPPED design flawMarkus Armbruster
Events are broadcast to all monitors. If another monitor's client has a command with the same ID in flight, the event will incorrectly claim that command was dropped. This must be fixed before out-of-band execution can graduate from "experimental". Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180703085358.13941-5-armbru@redhat.com>
2018-07-03qmp: Say "out-of-band" instead of "Out-Of-Band"Markus Armbruster
Affects documentation and a few error messages. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180703085358.13941-2-armbru@redhat.com>
2018-06-29dump: add Windows dump format to dump-guest-memoryViktor Prutyanov
This patch adds Windows crashdumping feature. Now QEMU can produce ELF-dump containing Windows crashdump header, which can help to convert to a valid WinDbg-understandable crashdump file, or immediately create such file. The crashdump will be obtained by joining physical memory dump and 8K header exposed through vmcoreinfo/fw_cfg device by guest driver at BSOD time. Option '-w' was added to dump-guest-memory command. At the moment, only x64 configuration is supported. Suitable driver can be found at https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/fwcfg64 Signed-off-by: Viktor Prutyanov <viktor.prutyanov@virtuozzo.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20180517162342.4330-2-viktor.prutyanov@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-22qapi: remove empty flat union branches and typesAnton Nefedov
Flat unions may now have uncovered branches, so it is possible to get rid of empty types defined for that purpose only. Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1529311206-76847-3-git-send-email-anton.nefedov@virtuozzo.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-06-21qmp: Enable a few commands in preconfig stateIgor Mammedov
Commands query-chardev, query-version, query-name, query-uuid, query-iothreads, query-memdev are informational and do not depend on the machine being initialized. Make them available in preconfig runstate to make the latter a little bit more useful. The generic qom commands don't depend on the machine being initialized either; so enabled qom-list, qom-get, qom-set, qom-list-types, qom-list-properties. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180620153947.30834-5-dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2018-06-01Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell
* Linux header upgrade (Peter) * firmware.json definition (Laszlo) * IPMI migration fix (Corey) * QOM improvements (Alexey, Philippe, me) * Memory API cleanups (Jay, me, Tristan, Peter) * WHPX fixes and improvements (Lucian) * Chardev fixes (Marc-André) * IOMMU documentation improvements (Peter) * Coverity fixes (Peter, Philippe) * Include cleanup (Philippe) * -clock deprecation (Thomas) * Disable -sandbox unless CONFIG_SECCOMP (Yi Min Zhao) * Configurability improvements (me) # gpg: Signature made Fri 01 Jun 2018 17:42:13 BST # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (56 commits) hw: make virtio devices configurable via default-configs/ hw: allow compiling out SCSI memory: Make operations using MemoryRegionIoeventfd struct pass by pointer. char: Remove unwanted crlf conversion qdev: Remove DeviceClass::init() and ::exit() qdev: Simplify the SysBusDeviceClass::init path hw/i2c: Use DeviceClass::realize instead of I2CSlaveClass::init hw/i2c/smbus: Use DeviceClass::realize instead of SMBusDeviceClass::init target/i386/kvm.c: Remove compatibility shim for KVM_HINTS_REALTIME Update Linux headers to 4.17-rc6 target/i386/kvm.c: Handle renaming of KVM_HINTS_DEDICATED scripts/update-linux-headers: Handle kernel license no longer being one file scripts/update-linux-headers: Handle __aligned_u64 virtio-gpu-3d: Define VIRTIO_GPU_CAPSET_VIRGL2 elsewhere gdbstub: Prevent fd leakage docs/interop: add "firmware.json" ipmi: Use proper struct reference for KCS vmstate vmstate: Add a VSTRUCT type tcg: remove softfloat from --disable-tcg builds qemu-options: Mark the non-functional -clock option as deprecated ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-06-01qom: Document qom/device-list-properties implementation specificAlexey Kardashevskiy
The recently introduced qom-list-properties QMP command raised a question what properties it (and its cousin - device-list-properties) can possibly print - only those defined by DeviceClass::props or dynamically created in TypeInfo::instance_init() so properties created elsewhere won't show up and this behaviour might confuse the user. For example, PIIX4 does that from piix4_pm_realize() via piix4_pm_add_propeties(): object_property_add_uint8_ptr(OBJECT(s), ACPI_PM_PROP_ACPI_ENABLE_CMD, &acpi_enable_cmd, NULL); This adds a note to the command descriptions about the limitation. Reviewed-by: Markus Armbruster <armbru@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20180530071129.9013-1-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-05-30qmp: add set-numa-node commandIgor Mammedov
Command is allowed to run only in preconfig stage and will allow to configure numa mapping for CPUs depending on possible CPUs layout (query-hotpluggable-cpus) for given machine instance. Example of configuration session: $QEMU -smp 2 --preconfig ... QMP: -> {'execute': 'query-hotpluggable-cpus' } <- {'return': [ {'props': {'core-id': 0, 'thread-id': 0, 'socket-id': 1}, ... }, {'props': {'core-id': 0, 'thread-id': 0, 'socket-id': 0}, ... } ]} -> {'execute': 'set-numa-node', 'arguments': { 'type': 'node', 'nodeid': 0 } } <- {'return': {}} -> {'execute': 'set-numa-node', 'arguments': { 'type': 'cpu', 'node-id': 0, 'core-id': 0, 'thread-id': 0, 'socket-id': 1, } } <- {'return': {}} -> {'execute': 'set-numa-node', 'arguments': { 'type': 'node', 'nodeid': 1 } } -> {'execute': 'set-numa-node', 'arguments': { 'type': 'cpu', 'node-id': 1, 'core-id': 0, 'thread-id': 0, 'socket-id': 0 } } <- {'return': {}} -> {'execute': 'query-hotpluggable-cpus' } <- {'return': [ {'props': {'core-id': 0, 'thread-id': 0, 'node-id': 0, 'socket-id': 1}, ... }, {'props': {'core-id': 0, 'thread-id': 0, 'node-id': 1, 'socket-id': 0}, ... } ]} Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1525423069-61903-11-git-send-email-imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> [ehabkost: Changed "since 2.13" to "since 3.0"] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-05-30qmp: permit query-hotpluggable-cpus in preconfig stateIgor Mammedov
it will allow mgmt to query possible CPUs, which depends on used machine(version)/-smp options, without restarting QEMU and use results to configure numa mapping or adding CPUs with device_add* later. PS: *) device_add is not allowed to run at preconfig in this series but later it could be dealt with by injecting -device in preconfig state and letting existing -device handling to actually plug devices Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1525423069-61903-10-git-send-email-imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-05-30cli: add --preconfig optionIgor Mammedov
This option allows pausing QEMU in the new RUN_STATE_PRECONFIG state, allowing the configuration of QEMU from QMP before the machine jumps into board initialization code of machine_run_board_init() The intent is to allow management to query machine state and additionally configure it using previous query results within one QEMU instance (i.e. eliminate the need to start QEMU twice, 1st to query board specific parameters and 2nd for actual VM start using query results for additional parameters). The new option complements -S option and could be used with or without it. The difference is that -S pauses QEMU when the machine is completely initialized with all devices wired up and ready to execute guest code (QEMU needs only to unpause VCPUs to let guest execute its code), while the "preconfig" option pauses QEMU early before board specific init callback (machine_run_board_init) is executed and allows the configuration of machine parameters which will be used by board init code. When early introspection/configuration is done, command 'exit-preconfig' should be used to exit RUN_STATE_PRECONFIG and transition to the next requested state (i.e. if -S is used then QEMU will pause the second time when board/device initialization is completed or start guest execution if -S isn't provided on CLI) PS: Initially 'preconfig' is planned to be used for configuring numa topology depending on board specified possible cpus layout. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1526059483-42847-1-git-send-email-imammedo@redhat.com> [ehabkost: Changed "since 2.13" to "since 3.0"] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-05-30qapi: introduce new cmd option "allow-preconfig"Igor Mammedov
New option will be used to allow commands, which are prepared/need to run, during preconfig state. Other commands that should be able to run in preconfig state, should be amended to not expect machine in initialized state or deal with it. For compatibility reasons, commands that don't use new flag 'allow-preconfig' explicitly are not permitted to run in preconfig state but allowed in all other states like they used to be. Within this patch allow following commands in preconfig state: qmp_capabilities query-qmp-schema query-commands query-command-line-options query-status exit-preconfig to allow qmp connection, basic introspection and moving to the next state. PS: set-numa-node and query-hotpluggable-cpus will be enabled later in a separate patches. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1526057503-39287-1-git-send-email-imammedo@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> [ehabkost: Changed "since 2.13" to "since 3.0"] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-05-29qapi: Change "since 2.13" annotations to "since 3.0"Peter Maydell
We're going to make the next release be 3.0, not 2.13; change the annotations in our json appropriately. Changes produced with sed -i -e 's/2\.13/3.0/g' qapi/*.json Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 20180522104000.9044-2-peter.maydell@linaro.org
2018-05-04qapi: deprecate CpuInfoFast.archLaszlo Ersek
The TARGET_BASE_ARCH values from "configure" don't all map to the @CpuInfoArch enum constants; in particular "s390x" from the former does not match @s390 in the latter. Clients are known to rely on the @s390 constant specifically, so we can't change it silently. Instead, deprecate the @CpuInfoFast.@arch member (in favor of @CpuInfoFast.@target) using the regular deprecation process. (No deprecation reminder is added to sysemu_target_to_cpuinfo_arch(): once @CpuInfoFast.@arch is removed, the assignment expression that calls sysemu_target_to_cpuinfo_arch() from qmp_query_cpus_fast() will have to disappear; in turn the static function left without callers will also break the build, thus it'll have to go.) Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20180427192852.15013-6-lersek@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-05-04qapi: discriminate CpuInfoFast on SysEmuTarget, not CpuInfoArchLaszlo Ersek
Add a new field @target (of type @SysEmuTarget) to the output of the @query-cpus-fast command, which provides more information about the emulation target than the field @arch (of type @CpuInfoArch). Make @target the new discriminator for the @CpuInfoFast return structure. Keep @arch for compatibility. Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180427192852.15013-5-lersek@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-05-04qapi: change the type of TargetInfo.arch from string to enum SysEmuTargetLaszlo Ersek
Now that we have @SysEmuTarget, it makes sense to restrict @TargetInfo.@arch to valid sysemu targets at the schema level. Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180427192852.15013-4-lersek@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-05-04qapi: fill in CpuInfoFast.arch in query-cpus-fastLaszlo Ersek
* Commit ca230ff33f89 added the @arch field to @CpuInfoFast, but it failed to set the new field in qmp_query_cpus_fast(), when TARGET_S390X was not defined. The updated @query-cpus-fast example in "qapi-schema.json" showed "arch":"x86" only because qmp_query_cpus_fast() calls g_malloc0() to allocate @CpuInfoFast, and the CPU_INFO_ARCH_X86 enum constant is generated with value 0. All @arch values other than @s390 implied the @CpuInfoOther sub-struct for @CpuInfoFast -- at the time of writing the patch --, thus no fields other than @arch needed to be set when TARGET_S390X was not defined. Set @arch now, by copying the corresponding assignments from qmp_query_cpus(). * Commit 25fa194b7b11 added the @riscv enum constant to @CpuInfoArch (used in both @CpuInfo and @CpuInfoFast -- the return types of the @query-cpus and @query-cpus-fast commands, respectively), and assigned, in both return structures, the @CpuInfoRISCV sub-structure to the new enum value. However, qmp_query_cpus_fast() would not populate either the @arch field or the @CpuInfoRISCV sub-structure, when TARGET_RISCV was defined; only qmp_query_cpus() would. Assign @CpuInfoOther to the @riscv enum constant in @CpuInfoFast, and populate only the @arch field in qmp_query_cpus_fast(). Getting CPU state without interrupting KVM is an exceptional thing that only S390X does currently. Quoting Cornelia Huck <cohuck@redhat.com>, "s390x is exceptional in that it has state in QEMU that is actually interesting for upper layers and can be retrieved without performance penalty". See also <https://www.redhat.com/archives/libvir-list/2018-February/msg00121.html>. Cc: Cornelia Huck <cohuck@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Viktor VM Mihajlovski <mihajlov@linux.vnet.ibm.com> Cc: qemu-stable@nongnu.org Fixes: ca230ff33f89bf7102cbfbc2328716da6750aaed Fixes: 25fa194b7b11901561532e435beb83d046899f7a Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180427192852.15013-2-lersek@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-03-20Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
virtio,vhost,pci,pc: features, cleanups SRAT tables for DIMM devices new virtio net flags for speed/duplex post-copy migration support in vhost cleanups in pci Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Tue 20 Mar 2018 14:40:43 GMT # gpg: using RSA key 281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: (51 commits) postcopy shared docs libvhost-user: Claim support for postcopy postcopy: Allow shared memory vhost: Huge page align and merge vhost+postcopy: Wire up POSTCOPY_END notify vhost-user: Add VHOST_USER_POSTCOPY_END message libvhost-user: mprotect & madvises for postcopy vhost+postcopy: Call wakeups vhost+postcopy: Add vhost waker postcopy: postcopy_notify_shared_wake postcopy: helper for waking shared vhost+postcopy: Resolve client address postcopy-ram: add a stub for postcopy_request_shared_page vhost+postcopy: Helper to send requests to source for shared pages vhost+postcopy: Stash RAMBlock and offset vhost+postcopy: Send address back to qemu libvhost-user+postcopy: Register new regions with the ufd migration/ram: ramblock_recv_bitmap_test_byte_offset postcopy+vhost-user: Split set_mem_table for postcopy vhost+postcopy: Transmit 'listen' to slave ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # scripts/update-linux-headers.sh
2018-03-20qmp: distinguish PC-DIMM and NVDIMM in MemoryDeviceInfoListHaozhong Zhang
It may need to treat PC-DIMM and NVDIMM differently, e.g., when deciding the necessity of non-volatile flag bit in SRAT memory affinity structures. A new field 'nvdimm' is added to the union type MemoryDeviceInfo for such purpose. Its type is currently PCDIMMDeviceInfo and will be updated when necessary in the future. It also fixes "info memory-devices"/query-memory-devices which currently show nvdimm devices as dimm devices since object_dynamic_cast(obj, TYPE_PC_DIMM) happily cast nvdimm to TYPE_PC_DIMM which it's been inherited from. Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-19qmp: add command "x-oob-test"Peter Xu
This command is only used to test OOB functionality. It should not be used for any other purposes. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180309090006.10018-22-peterx@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> [eblake: grammar tweak] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-19qmp: add new event "command-dropped"Eric Blake
This event will be emitted if one QMP command is dropped. Also, declare an enum for the reasons. Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180309090006.10018-16-peterx@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> [eblake: rebase to master] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-19qmp: introduce QMPCapabilityPeter Xu
There were no QMP capabilities defined. Define the first capability, "oob", to allow out-of-band messages. After this patch, we will allow QMP clients to enable QMP capabilities when sending the first "qmp_capabilities" command. Originally we are starting QMP session with no arguments like: { "execute": "qmp_capabilities" } Now we can enable some QMP capabilities using (take OOB as example, which is the only capability that we support): { "execute": "qmp_capabilities", "arguments": { "enable": [ "oob" ] } } When the "arguments" key is not provided, no capability is enabled. For capability "oob", the monitor needs to be run on a dedicated IO thread, otherwise the command will fail. For example, trying to enable OOB on a MUXed typed QMP monitor will fail. One thing to mention is that QMP capabilities are per-monitor, and also when the connection is closed due to some reason, the capabilities will be reset. Also, touch up qmp-test.c to test the new bits. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180309090006.10018-11-peterx@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> [eblake: touch up commit message] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-13sev/i386: qmp: add query-sev-capabilities commandBrijesh Singh
The command can be used by libvirt to query the SEV capabilities. Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-13sev/i386: qmp: add query-sev-launch-measure commandBrijesh Singh
The command can be used by libvirt to retrieve the measurement of SEV guest. This measurement is a signature of the memory contents that was encrypted through the LAUNCH_UPDATE_DATA. Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-13sev/i386: qmp: add query-sev commandBrijesh Singh
The QMP query command can used to retrieve the SEV information when memory encryption is enabled on AMD platform. Cc: Eric Blake <eblake@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-07RISC-V Build InfrastructureMichael Clark
This adds RISC-V into the build system enabling the following targets: - riscv32-softmmu - riscv64-softmmu - riscv32-linux-user - riscv64-linux-user This adds defaults configs for RISC-V, enables the build for the RISC-V CPU core, hardware, and Linux User Emulation. The 'qemu-binfmt-conf.sh' script is updated to add the RISC-V ELF magic. Expected checkpatch errors for consistency reasons: ERROR: line over 90 characters FILE: scripts/qemu-binfmt-conf.sh Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-06qmp: Add qom-list-properties to list QOM object propertiesAlexey Kardashevskiy
There is already 'device-list-properties' which does most of the job, however it does not handle everything returned by qom-list-types such as machines as they inherit directly from TYPE_OBJECT and not TYPE_DEVICE. It does not handle abstract classes either. This adds a new qom-list-properties command which prints properties of a specific class and its instance. It is pretty much a simplified copy of the device-list-properties handler. Since it creates an object instance, device properties should appear in the output as they are copied to QOM properties at the instance_init hook. This adds a object_class_property_iter_init() helper to allow class properties enumeration uses it in the new QMP command to allow properties listing for abstract classes. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20180301130939.15875-3-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-06qmp: Merge ObjectPropertyInfo and DevicePropertyInfoAlexey Kardashevskiy
ObjectPropertyInfo is more generic and only missing @description. This adds a description to ObjectPropertyInfo and removes DevicePropertyInfo so the resulting ObjectPropertyInfo can be used elsewhere. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20180301130939.15875-2-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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>