aboutsummaryrefslogtreecommitdiff
path: root/qapi
AgeCommit message (Collapse)Author
2018-06-11qapi: add disabled parameter to block-dirty-bitmap-addVladimir Sementsov-Ogievskiy
This is needed, for example, to create a new bitmap and merge several disabled bitmaps into a new one. Without this flag we will have to put block-dirty-bitmap-add and block-dirty-bitmap-disable into one transaction. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Message-id: 20180606182449.1607-6-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2018-06-11qapi: add x-block-dirty-bitmap-mergeVladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Message-id: 20180606182449.1607-5-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2018-06-11qmp: transaction support for x-block-dirty-bitmap-enable/disableVladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Message-id: 20180606182449.1607-4-jsnow@redhat.com [Added x- prefix. --js] Signed-off-by: John Snow <jsnow@redhat.com>
2018-06-11qapi: add x-block-dirty-bitmap-enable/disableVladimir Sementsov-Ogievskiy
Expose the ability to turn bitmaps "on" or "off". This is experimental and principally for the sake of the Libvirt Checkpoints API, and it may or may not be committed for 3.0. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Message-id: 20180606182449.1607-3-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2018-06-08Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into ↵Peter Maydell
staging slirp updates Prasad J Pandit (2): slirp: Fix buffer overflow on packet reassembling Samuel Thibault (3): slirp: Add Samuel Thibault's staging tree for slirp slirp: fix domainname version availability # gpg: Signature made Fri 08 Jun 2018 07:12:24 BST # gpg: using RSA key 996849C1CF560478 # gpg: Good signature from "Samuel Thibault <samuel.thibault@aquilenet.fr>" # gpg: aka "Samuel Thibault <sthibault@debian.org>" # gpg: aka "Samuel Thibault <samuel.thibault@gnu.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: aka "Samuel Thibault <samuel.thibault@u-bordeaux.fr>" # 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: 3A3A 5D46 4660 E867 610C A427 9968 49C1 CF56 0478 * remotes/thibault/tags/samuel-thibault: slirp: reformat m_inc routine slirp: correct size computation while concatenating mbuf slirp: fix domainname version availability slirp: Add Samuel Thibault's staging tree for slirp slirp: Fix spurious error report when sending directly Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-06-08slirp: fix domainname version availabilitySamuel Thibault
The change missed the 2.12 deadline. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2018-06-04Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20180604' ↵Peter Maydell
into staging migration/next for 20180604 # gpg: Signature made Mon 04 Jun 2018 05:14:24 BST # gpg: using RSA key F487EF185872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" # gpg: aka "Juan Quintela <quintela@trasno.org>" # Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723 * remotes/juanquintela/tags/migration/20180604: migration: not wait RDMA_CM_EVENT_DISCONNECTED event after rdma_disconnect migration: remove unnecessary variables len in QIOChannelRDMA migration: Don't activate block devices if using -S migration: discard non-migratable RAMBlocks migration: introduce decompress-error-check Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-06-04migration: Don't activate block devices if using -SDr. David Alan Gilbert
Activating the block devices causes the locks to be taken on the backing file. If we're running with -S and the destination libvirt hasn't started the destination with 'cont', it's expecting the locks are still untaken. Don't activate the block devices if we're not going to autostart the VM; 'cont' already will do that anyway. This change is tied to the new migration capability 'late-block-activate' that defaults to off, keeping the old behaviour by default. bz: https://bugzilla.redhat.com/show_bug.cgi?id=1560854 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@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-31slirp: Add domainname option to slirp's DHCP serverBenjamin Drung
This patch will allow the user to include the domainname option in replies from the built-in DHCP server. Signed-off-by: Benjamin Drung <benjamin.drung@profitbricks.com> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
2018-05-31Merge remote-tracking branch 'remotes/ehabkost/tags/numa-next-pull-request' ↵Peter Maydell
into staging NUMA queue, 2018-05-30 * New command-line option: --preconfig This option allows pausing QEMU and allow the configuration using QMP commands before running board initialization code. * New QMP set-numa-node, now made possible because of --preconfig * Small update on -numa error messages # gpg: Signature made Thu 31 May 2018 00:02:59 BST # gpg: using RSA key 2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/numa-next-pull-request: tests: functional tests for QMP command set-numa-node qmp: add set-numa-node command qmp: permit query-hotpluggable-cpus in preconfig state tests: extend qmp test with preconfig checks cli: add --preconfig option tests: qapi-schema tests for allow-preconfig qapi: introduce new cmd option "allow-preconfig" hmp: disable monitor in preconfig state qapi: introduce preconfig runstate numa: split out NumaOptions parsing into set_numa_options() numa: postpone options post-processing till machine_run_board_init() numa: clarify error message when node index is out of range in -numa dist, ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
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-30qapi: introduce preconfig runstateIgor Mammedov
New preconfig runstate will be used in follow up patches related to introducing --preconfig CLI option and is intended to replace prelaunch runstate from QEMU start up to machine_init callback. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1525423069-61903-4-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-30block/create: Mark blockdev-create stableKevin Wolf
We're ready to declare the blockdev-create job stable. This renames the corresponding QMP command from x-blockdev-create to blockdev-create. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com>
2018-05-30block/create: Make x-blockdev-create a jobKevin Wolf
This changes the x-blockdev-create QMP command so that it doesn't block the monitor and the main loop any more, but starts a background job that performs the image creation. The basic job as implemented here is all that is necessary to make image creation asynchronous and to provide a QMP interface that can be marked stable, but it still lacks a few features that jobs usually provide: The job will ignore pause commands and it doesn't publish more than very basic progress yet (total-progress is 1 and current-progress advances from 0 to 1 when the driver callbacks returns). These features can be added later without breaking compatibility. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Jeff Cody <jcody@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-23job: Add query-jobs QMP commandKevin Wolf
This adds a minimal query-jobs implementation that shouldn't pose many design questions. It can later be extended to expose more information, and especially job-specific information. Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-05-23job: Add lifecycle QMP commandsKevin Wolf
This adds QMP commands that control the transition between states of the job lifecycle. Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-05-23job: Add JOB_STATUS_CHANGE QMP eventKevin Wolf
This adds a QMP event that is emitted whenever a job transitions from one status to another. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2018-05-23job: Introduce qapi/job.jsonKevin Wolf
This adds a separate schema file for all job-related definitions that aren't tied to the block layer. For a start, move the enums JobType, JobStatus and JobVerb. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2018-05-23job: Move state transitions to JobKevin Wolf
This moves BlockJob.status and the closely related functions (block_)job_state_transition() and (block_)job_apply_verb to Job. The two QAPI enums are renamed to JobStatus and JobVerb. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2018-05-23job: Rename BlockJobType into JobTypeKevin Wolf
QAPI types aren't externally visible, so we can rename them without causing problems. Before we add a job type to Job, rename the enum so it can be used for more than just block jobs. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2018-05-23blockjob: Improve BlockJobInfo.offset/len documentationKevin Wolf
Clarify that len is just an estimation of the end value of offset, and that offset increases monotonically while len can change arbitrarily. While touching the documentation of offset, move it directly after len to match the order of the declaration below. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2018-05-23blockjob: Update block-job-pause/resume documentationKevin Wolf
Commit 0ec4dfb8d changed block-job_pause/resume so that they return an error if they don't do anything because the job is already paused/running. It forgot to update the documentation, so do that now. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2018-05-20qapi/net.json: Fix the version number of the "vlan" removalThomas Huth
"vlan" will be dropped in 2.13, not in 2.12. And while we're at it, use the better wording "dropped in" instead of "removed with" (also for the "dump" removal). Reported-by: Stefan Hajnoczi <stefanha@redhat.com> Reported-by: Eric Blake <eblake@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2018-05-15migration: Textual fixups for blocktimeDr. David Alan Gilbert
Blank lines and comments as suggested by Eric. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180427111502.9822-1-dgilbert@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2018-05-15migration/qmp: add command migrate-pausePeter Xu
It pauses an ongoing migration. Currently it only supports postcopy. Note that this command will work on either side of the migration. Basically when we trigger this on one side, it'll interrupt the other side as well since the other side will get notified on the disconnect event. However, it's still possible that the other side is not notified, for example, when the network is totally broken, or due to some firewall configuration changes. In that case, we will also need to run the same command on the other side so both sides will go into the paused state. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180502104740.12123-24-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> --- s/2.12/2.13/
2018-05-15qmp/migration: new command migrate-recoverPeter Xu
The first allow-oob=true command. It's used on destination side when the postcopy migration is paused and ready for a recovery. After execution, a new migration channel will be established for postcopy to continue. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180502104740.12123-21-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> --- s/2.12/2.13/
2018-05-15migration: new state "postcopy-recover"Peter Xu
Introducing new migration state "postcopy-recover". If a migration procedure is paused and the connection is rebuilt afterward successfully, we'll switch the source VM state from "postcopy-paused" to the new state "postcopy-recover", then we'll do the resume logic in the migration thread (along with the return path thread). This patch only do the state switch on source side. Another following up patch will handle the state switching on destination side using the same status bit. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180502104740.12123-10-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> --- s/2.11/2.13/
2018-05-15qmp: hmp: add migrate "resume" optionPeter Xu
It will be used when we want to resume one paused migration. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180502104740.12123-8-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> --- s/2.12/2.13/
2018-05-15migration: new postcopy-pause statePeter Xu
Introducing a new state "postcopy-paused", which can be used when the postcopy migration is paused. It is targeted for postcopy network failure recovery. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180502104740.12123-3-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2018-05-15block: Add COR filter driverMax Reitz
This adds a simple copy-on-read filter driver. It relies on the already existing COR functionality in the central block layer code, which may be moved here once we no longer need it there. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180421132929.21610-2-mreitz@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-15blockjob: expose error string via queryJohn Snow
When we've reached the concluded state, we need to expose the error state if applicable. Add the new field. This should be sufficient for determining if a job completed successfully or not after concluding; if we want to discriminate based on how it failed more mechanically, we can always add an explicit return code enumeration later. I didn't bother to make it only show up if we are in the concluded state; I don't think it's necessary. Cc: qemu-stable@nongnu.org Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-05-14Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into ↵Peter Maydell
staging Block pull request * Support -drive cache.direct=off live migration for POSIX files # gpg: Signature made Sat 12 May 2018 10:27:51 BST # gpg: using RSA key 9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha/tags/block-pull-request: block/file-posix: add x-check-page-cache=on|off option block/file-posix: implement bdrv_co_invalidate_cache() on Linux checkpatch: reduce MAINTAINERS update message frequency checkpatch: emit a warning on file add/move/delete checkpatch: ignore email headers better checkpatch: check utf-8 content from a commit log when it's missing from charset checkpatch: add a --strict check for utf-8 in commit logs blockjob: drop block_job_pause/resume_all() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-05-14net: Remove the deprecated "vlan" parameterThomas Huth
It's been marked as deprecated since QEMU v2.9.0, so that should have been enough time for everybody to either just drop unnecessary "vlan=0" parameters, to switch to the modern -device + -netdev syntax for connecting guest NICs with host network backends, or to switch to the "hubport" netdev in case hubs are really wanted instead. Buglink: https://bugs.launchpad.net/qemu/+bug/658904 Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2018-05-11block/file-posix: add x-check-page-cache=on|off optionStefan Hajnoczi
mincore(2) checks whether pages are resident. Use it to verify that page cache has been dropped. You can trigger a verification failure by mmapping the image file from another process that loads a byte from a page, forcing it to become resident. bdrv_co_invalidate_cache() will fail while that process is alive. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-id: 20180427162312.18583-3-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
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: add SysEmuTarget to "common.json"Laszlo Ersek
We'll soon need an enumeration type that lists all the softmmu targets that QEMU (the project) supports. Introduce @SysEmuTarget to "common.json". The enum constant @x86_64 doesn't match the QAPI convention of preferring hyphen ("-") over underscore ("_"). This is intentional; the @SysEmuTarget constants are supposed to produce QEMU executable names when stringified and appended to the "qemu-system-" prefix. Put differently, the replacement text of the TARGET_NAME preprocessor macro must be possible to look up in the list of (stringified) enum constants. Like other enum types, @SysEmuTarget too can be used for discriminator fields in unions. For the @i386 constant, a C-language union member called "i386" would be generated. On mingw build hosts, "i386" is a macro however. Add "i386" to "polluted_words" at once. 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-3-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: 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-05-04qobject: Modify qobject_ref() to return objMarc-André Lureau
For convenience and clarity, make it possible to call qobject_ref() at the time when the reference is associated with a variable, or argument, by making qobject_ref() return the same pointer as given. Use that to simplify the callers. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180419150145.24795-5-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Useless change to qobject_ref_impl() dropped, commit message improved slightly] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-05-04qobject: Replace qobject_incref/QINCREF qobject_decref/QDECREFMarc-André Lureau
Now that we can safely call QOBJECT() on QObject * as well as its subtypes, we can have macros qobject_ref() / qobject_unref() that work everywhere instead of having to use QINCREF() / QDECREF() for QObject and qobject_incref() / qobject_decref() for its subtypes. The replacement is mechanical, except I broke a long line, and added a cast in monitor_qmp_cleanup_req_queue_locked(). Unlike qobject_decref(), qobject_unref() doesn't accept void *. Note that the new macros evaluate their argument exactly once, thus no need to shout them. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180419150145.24795-4-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Rebased, semantic conflict resolved, commit message improved] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-04-27qapi: Parameter gl of DisplayType now accept an enumElie Tournier
v2: Rebase on top of master v3: Fix the json format (Eric Blake) Fix a comparison issue (Gerd Hoffmann) Signed-off-by: Elie Tournier <elie.tournier@collabora.com> Message-id: 20180413135842.21325-2-tournier.elie@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-04-25migration: add postcopy total blocktime into query-migrateAlexey Perevalov
Postcopy total blocktime is available on destination side only. But query-migrate was possible only for source. This patch adds ability to call query-migrate on destination. To be able to see postcopy blocktime, need to request postcopy-blocktime capability. The query-migrate command will show following sample result: {"return": "postcopy-vcpu-blocktime": [115, 100], "status": "completed", "postcopy-blocktime": 100 }} postcopy_vcpu_blocktime contains list, where the first item is the first vCPU in QEMU. This patch has a drawback, it combines states of incoming and outgoing migration. Ongoing migration state will overwrite incoming state. Looks like better to separate query-migrate for incoming and outgoing migration or add parameter to indicate type of migration. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <1521742647-25550-7-git-send-email-a.perevalov@samsung.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2018-04-25migration: introduce postcopy-blocktime capabilityAlexey Perevalov
Right now it could be used on destination side to enable vCPU blocktime calculation for postcopy live migration. vCPU blocktime - it's time since vCPU thread was put into interruptible sleep, till memory page was copied and thread awake. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <1521742647-25550-2-git-send-email-a.perevalov@samsung.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-02 14:16:52 +0000