aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-10-11migration/multifd: fix a typo in comment of multifd_recv_unfill_packet()Wei Yang
Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20191011085050.17622-2-richardw.yang@linux.intel.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration/postcopy: check PostcopyState before setting to ↵Wei Yang
POSTCOPY_INCOMING_RUNNING Currently, we set PostcopyState blindly to RUNNING, even we found the previous state is not LISTENING. This will lead to a corner case. First let's look at the code flow: qemu_loadvm_state_main() ret = loadvm_process_command() loadvm_postcopy_handle_run() return -1; if (ret < 0) { if (postcopy_state_get() == POSTCOPY_INCOMING_RUNNING) ... } >From above snippet, the corner case is loadvm_postcopy_handle_run() always sets state to RUNNING. And then it checks the previous state. If the previous state is not LISTENING, it will return -1. But at this moment, PostcopyState is already been set to RUNNING. Then ret is checked in qemu_loadvm_state_main(), when it is -1 PostcopyState is checked. Current logic would pause postcopy and retry if PostcopyState is RUNNING. This is not what we expect, because postcopy is not active yet. This patch makes sure state is set to RUNNING only previous state is LISTENING by checking the state first. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Suggested by: Peter Xu <peterx@redhat.com> Message-Id: <20191010011316.31363-3-richardw.yang@linux.intel.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration/postcopy: rename postcopy_ram_enable_notify to ↵Wei Yang
postcopy_ram_incoming_setup Function postcopy_ram_incoming_setup and postcopy_ram_incoming_cleanup is a pair. Rename to make it clear for audience. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20191010011316.31363-2-richardw.yang@linux.intel.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration/postcopy: postpone setting PostcopyState to ENDWei Yang
There are two places to call function postcopy_ram_incoming_cleanup() postcopy_ram_listen_thread on migration success loadvm_postcopy_handle_listen one setup failure On success, the vm will never accept another migration. On failure, PostcopyState is transited from LISTENING to END and would be checked in qemu_loadvm_state_main(). If PostcopyState is RUNNING, migration would be paused and retried. Currently PostcopyState is set to END in function postcopy_ram_incoming_cleanup(). With above analysis, we can take this step out and postpone this till the end of listen thread to indicate the listen thread is done. This is a preparation patch for later cleanup. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20191006000249.29926-3-richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Fixed up in merge to the 1 parameter postcopy_state_set
2019-10-11migration/postcopy: mis->have_listen_thread check will never be touchedWei Yang
If mis->have_listen_thread is true, this means current PostcopyState must be LISTENING or RUNNING. While the check at the beginning of the function makes sure the state transaction happens when its previous PostcopyState is ADVISE or DISCARD. This means we would never touch this check. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20191006000249.29926-2-richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration: report SaveStateEntry id and name on failureWei Yang
This provides helpful information on which entry failed. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20191005220517.24029-5-richardw.yang@linux.intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration: pass in_postcopy instead of check state againWei Yang
Not necessary to do the check again. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20191005220517.24029-4-richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration/postcopy: fix typo in mark_postcopy_blocktime_begin's commentWei Yang
Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20191005220517.24029-3-richardw.yang@linux.intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration/postcopy: map large zero page in postcopy_ram_incoming_setup()Wei Yang
postcopy_ram_incoming_setup() and postcopy_ram_incoming_cleanup() are counterpart. It is reasonable to map/unmap large zero page in these two functions respectively. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20191005135021.21721-3-richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration/postcopy: allocate tmp_page in setup stageWei Yang
During migration, a tmp page is allocated so that we could place a whole host page during postcopy. Currently the page is allocated during load stage, this is a little bit late. And more important, if we failed to allocate it, the error is not checked properly. Even it is NULL, we would still use it. This patch moves the allocation to setup stage and if failed error message would be printed and caller would notice it. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration: Don't try and recover return path in non-postcopyDr. David Alan Gilbert
In normal precopy we can't do reconnection recovery - but we also don't need to, since you can just rerun migration. At the moment if the 'return-path' capability is on, we use the return path in precopy to give a positive 'OK' to the end of migration; however if migration fails then we fall into the postcopy recovery path and hang. This fixes it by only running the return path in the postcopy case. Reported-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11rcu: Use automatic rc_read unlock in core memory/exec codeDr. David Alan Gilbert
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20191007143642.301445-6-dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration: Use automatic rcu_read unlock in rdma.cDr. David Alan Gilbert
Use the automatic read unlocker in migration/rdma.c. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20191007143642.301445-5-dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration: Use automatic rcu_read unlock in ram.cDr. David Alan Gilbert
Use the automatic read unlocker in migration/ram.c Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20191007143642.301445-4-dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration: Fix missing rcu_read_unlockDr. David Alan Gilbert
Use the automatic rcu_read unlocker to fix a missing unlock. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20191007143642.301445-3-dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11rcu: Add automatically released rcu_read_lock variantsDr. David Alan Gilbert
RCU_READ_LOCK_GUARD() takes the rcu_read_lock and then uses glib's g_auto infrastructure (and thus whatever the compiler's hooks are) to release it on all exits of the block. WITH_RCU_READ_LOCK_GUARD() is similar but is used as a wrapper for the lock, i.e.: WITH_RCU_READ_LOCK_GUARD() { stuff under lock } Note the 'unused' attribute is needed to work around clang bug: https://bugs.llvm.org/show_bug.cgi?id=43482 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20191007143642.301445-2-dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-11migration: use migration_is_active to represent active stateWei Yang
Wrap the check into a function to make it easy to read. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20190717005341.14140-1-richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-10-08Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into ↵Peter Maydell
staging Pull request This pull request also contains the two commits from the previous pull request that was dropped due to a mingw compilation error. The compilation should now be fixed. # gpg: Signature made Tue 08 Oct 2019 15:54:26 BST # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full] # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [full] # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha/tags/block-pull-request: iotests/262: Switch source/dest VM launch order block: Skip COR for inactive nodes virtio-blk: schedule virtio_notify_config to run on main context util/ioc.c: try to reassure Coverity about qemu_iovec_init_extended Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-08iotests/262: Switch source/dest VM launch orderMax Reitz
Launching the destination VM before the source VM gives us a regression test for HEAD^: The guest device causes a read from the disk image through guess_disk_lchs(). This will not work if the first sector (containing the partition table) is yet unallocated, we use COR, and the node is inactive. By launching the source VM before the destination, however, the COR filter on the source will allocate that area in the image shared between both VMs, thus the problem will not become apparent. Switching the launch order causes the sector to still be unallocated when guess_disk_lchs() runs on the inactive node in the destination VM, and thus we get our test case. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20191001174827.11081-3-mreitz@redhat.com Message-Id: <20191001174827.11081-3-mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-10-08block: Skip COR for inactive nodesMax Reitz
We must not write data to inactive nodes, and a COR is certainly something we can simply not do without upsetting anyone. So skip COR operations on inactive nodes. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20191001174827.11081-2-mreitz@redhat.com Message-Id: <20191001174827.11081-2-mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-10-08virtio-blk: schedule virtio_notify_config to run on main contextSergio Lopez
virtio_notify_config() needs to acquire the global mutex, which isn't allowed from an iothread, and may lead to a deadlock like this: - main thead * Has acquired: qemu_global_mutex. * Is trying the acquire: iothread AioContext lock via AIO_WAIT_WHILE (after aio_poll). - iothread * Has acquired: AioContext lock. * Is trying to acquire: qemu_global_mutex (via virtio_notify_config->prepare_mmio_access). If virtio_blk_resize() is called from an iothread, schedule virtio_notify_config() to be run in the main context BH. [Removed unnecessary newline as suggested by Kevin Wolf <kwolf@redhat.com>. --Stefan] Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-id: 20190916112411.21636-1-slp@redhat.com Message-Id: <20190916112411.21636-1-slp@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-10-08util/ioc.c: try to reassure Coverity about qemu_iovec_init_extendedVladimir Sementsov-Ogievskiy
Make it more obvious, that filling qiov corresponds to qiov allocation, which in turn corresponds to total_niov calculation, based on mid_niov (not mid_len). Still add an assertion to show that there should be no difference. [Added mingw "error: 'mid_iov' may be used uninitialized in this function" compiler error fix suggested by Vladimir. --Stefan] Reported-by: Coverity (CID 1405302) Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20190910090310.14032-1-vsementsov@virtuozzo.com Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20190910090310.14032-1-vsementsov@virtuozzo.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> fixup! util/ioc.c: try to reassure Coverity about qemu_iovec_init_extended
2019-10-08Merge remote-tracking branch 'remotes/philmd-gitlab/tags/edk2-next-20191007' ↵Peter Maydell
into staging Improve scripts relying on the EDK2 submodule, drop Python2 dependency in EDK2 build scripts. # gpg: Signature made Mon 07 Oct 2019 14:31:38 BST # gpg: using RSA key 89C1E78F601EE86C867495CBA2A3FD6EDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (Phil) <philmd@redhat.com>" [marginal] # 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: 89C1 E78F 601E E86C 8674 95CB A2A3 FD6E DEAD C0DE * remotes/philmd-gitlab/tags/edk2-next-20191007: edk2 build scripts: work around TianoCore#1607 without forcing Python 2 edk2 build scripts: honor external BaseTools flags with uefi-test-tools roms: Add a 'make help' target alias roms/Makefile.edk2: don't pull in submodules when building from tarball make-release: pull in edk2 submodules so we can build it from tarballs Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-08Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into ↵Peter Maydell
staging slirp: Allow non-local DNS address when restrict is off # gpg: Signature made Mon 07 Oct 2019 00:54:44 BST # gpg: using RSA key 5ED9E856F7D6C6EAF51167A18D35C355720BBAFD # gpg: Good signature from "Samuel Thibault <samuel.thibault@aquilenet.fr>" [unknown] # gpg: aka "Samuel Thibault <sthibault@debian.org>" [marginal] # gpg: aka "Samuel Thibault <samuel.thibault@gnu.org>" [unknown] # gpg: aka "Samuel Thibault <samuel.thibault@inria.fr>" [marginal] # gpg: aka "Samuel Thibault <samuel.thibault@labri.fr>" [marginal] # gpg: aka "Samuel Thibault <samuel.thibault@ens-lyon.org>" [marginal] # gpg: aka "Samuel Thibault <samuel.thibault@u-bordeaux.fr>" [unknown] # 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: 5ED9 E856 F7D6 C6EA F511 67A1 8D35 C355 720B BAFD * remotes/thibault/tags/samuel-thibault: slirp: Allow non-local DNS address when restrict is off Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-07Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches: - Fix internal snapshots with typical -blockdev setups - iotests: Require Python 3.6 or later # gpg: Signature made Fri 04 Oct 2019 10:59:21 BST # gpg: using RSA key 7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: iotests: Remove Python 2 compatibility code iotests: Require Python 3.6 or later iotests: Test internal snapshots with -blockdev block/snapshot: Restrict set of snapshot nodes Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-07edk2 build scripts: work around TianoCore#1607 without forcing Python 2Laszlo Ersek
It turns out that forcing python2 for running the edk2 "build" utility is neither necessary nor sufficient. Forcing python2 is not sufficient for two reasons: - QEMU is moving away from python2, with python2 nearing EOL, - according to my most recent testing, the lacking dependency information in the makefiles that are generated by edk2's "build" utility can cause parallel build failures even when "build" is executed by python2. And forcing python2 is not necessary because we can still return to the original idea of filtering out jobserver-related options from MAKEFLAGS. So do that. While at it, cut short edk2's auto-detection of the python3.* minor version, by setting PYTHON_COMMAND to "python3" (which we expect to be available wherever we intend to build edk2). With this patch, the guest UEFI binaries that are used as part of the BIOS tables test, and the OVMF and ArmVirtQemu platform firmwares, will be built strictly in a single job, regardless of an outermost "-jN" make option. Alas, there appears to be no reliable way to build edk2 in an (outer make, inner make) environment, with a jobserver enabled. Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: John Snow <jsnow@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Reported-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190920083808.21399-3-lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-10-07edk2 build scripts: honor external BaseTools flags with uefi-test-toolsLaszlo Ersek
Unify the recipe for "build-edk2-tools" in "tests/uefi-test-tools/Makefile" with the recipe for "edk2-basetools" in "roms/Makefile". Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190920083808.21399-2-lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-10-07roms: Add a 'make help' target aliasPhilippe Mathieu-Daudé
Various C projects provide a 'make help' target. Our root directory does so. The roms/ directory lacks a such rule, but already displays a help output when the default target is called. Add a 'help' target aliased to the default one, to avoid: $ make -C roms help make: *** No rule to make target 'help'. Stop. Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190920171159.18633-1-philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-10-07roms/Makefile.edk2: don't pull in submodules when building from tarballMichael Roth
Currently the `make efi` target pulls submodules nested under the roms/edk2 submodule as dependencies. However, when we attempt to build from a tarball this fails since we are no longer in a git tree. A preceding patch will pre-populate these submodules in the tarball, so assume this build dependency is only needed when building from a git tree. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Bruce Rogers <brogers@suse.com> Cc: qemu-stable@nongnu.org # v4.1.0 Reported-by: Bruce Rogers <brogers@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Message-Id: <20190912231202.12327-3-mdroth@linux.vnet.ibm.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-10-07make-release: pull in edk2 submodules so we can build it from tarballsMichael Roth
The `make efi` target added by 536d2173 is built from the roms/edk2 submodule, which in turn relies on additional submodules nested under roms/edk2. The make-release script currently only pulls in top-level submodules, so these nested submodules are missing in the resulting tarball. We could try to address this situation more generally by recursively pulling in all submodules, but this doesn't necessarily ensure the end-result will build properly (this case also required other changes). Additionally, due to the nature of submodules, we may not always have control over how these sorts of things are dealt with, so for now we continue to handle it on a case-by-case in the make-release script. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Bruce Rogers <brogers@suse.com> Cc: qemu-stable@nongnu.org # v4.1.0 Reported-by: Bruce Rogers <brogers@suse.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Message-Id: <20190912231202.12327-2-mdroth@linux.vnet.ibm.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-10-07Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.2-20191004' ↵Peter Maydell
into staging ppc patch queue 2019-10-04 Here's the next batch of ppc and spapr patches. Includes: * Fist part of a large cleanup to irq infrastructure * Recreate the full FDT at CAS time, instead of making a difficult to follow set of updates. This will help us move towards eliminating CAS reboots altogether * No longer provide RTAS blob to SLOF - SLOF can include it just as well itself, since guests will generally need to relocate it with a call to instantiate-rtas * A number of DFP fixes and cleanups from Mark Cave-Ayland * Assorted bugfixes * Several new small devices for powernv # gpg: Signature made Fri 04 Oct 2019 10:35:57 BST # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-4.2-20191004: (53 commits) ppc/pnv: Remove the XICSFabric Interface from the POWER9 machine spapr: Eliminate SpaprIrq::init hook spapr: Add return value to spapr_irq_check() spapr: Use less cryptic representation of which irq backends are supported xive: Improve irq claim/free path spapr, xics, xive: Better use of assert()s on irq claim/free paths spapr: Handle freeing of multiple irqs in frontend only spapr: Remove unhelpful tracepoints from spapr_irq_free_xics() spapr: Eliminate SpaprIrq:get_nodename method spapr: Simplify spapr_qirq() handling spapr: Fix indexing of XICS irqs spapr: Eliminate nr_irqs parameter to SpaprIrq::init spapr: Clarify and fix handling of nr_irqs spapr: Replace spapr_vio_qirq() helper with spapr_vio_irq_pulse() helper spapr: Fold spapr_phb_lsi_qirq() into its single caller xics: Create sPAPR specific ICS subtype xics: Merge TYPE_ICS_BASE and TYPE_ICS_SIMPLE classes xics: Eliminate reset hook xics: Rename misleading ics_simple_*() functions xics: Eliminate 'reject', 'resend' and 'eoi' class hooks ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-04Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell
* Compilation fix for KVM (Alex) * SMM fix (Dmitry) * VFIO error reporting (Eric) * win32 fixes and workarounds (Marc-André) * qemu-pr-helper crash bugfix (Maxim) * Memory leak fixes (myself) * VMX features (myself) * Record-replay deadlock (Pavel) * i386 CPUID bits (Sebastian) * kconfig tweak (Thomas) * Valgrind fix (Thomas) * Autoconverge test (Yury) # gpg: Signature made Fri 04 Oct 2019 17:57:48 BST # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # 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: (29 commits) target/i386/kvm: Silence warning from Valgrind about uninitialized bytes target/i386: work around KVM_GET_MSRS bug for secondary execution controls target/i386: add VMX features vmxcap: correct the name of the variables target/i386: add VMX definitions target/i386: expand feature words to 64 bits target/i386: introduce generic feature dependency mechanism target/i386: handle filtered_features in a new function mark_unavailable_features tests/docker: only enable ubsan for test-clang win32: work around main-loop busy loop on socket/fd event tests: skip serial test on windows util: WSAEWOULDBLOCK on connect should map to EINPROGRESS Fix wrong behavior of cpu_memory_rw_debug() function in SMM memory: allow memory_region_register_iommu_notifier() to fail vfio: Turn the container error into an Error handle i386: Add CPUID bit for CLZERO and XSAVEERPTR docker: test-debug: disable LeakSanitizer lm32: do not leak memory on object_new/object_unref cris: do not leak struct cris_disasm_data mips: fix memory leaks in board initialization ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-04target/i386/kvm: Silence warning from Valgrind about uninitialized bytesThomas Huth
When I run QEMU with KVM under Valgrind, I currently get this warning: Syscall param ioctl(generic) points to uninitialised byte(s) at 0x95BA45B: ioctl (in /usr/lib64/libc-2.28.so) by 0x429DC3: kvm_ioctl (kvm-all.c:2365) by 0x51B249: kvm_arch_get_supported_msr_feature (kvm.c:469) by 0x4C2A49: x86_cpu_get_supported_feature_word (cpu.c:3765) by 0x4C4116: x86_cpu_expand_features (cpu.c:5065) by 0x4C7F8D: x86_cpu_realizefn (cpu.c:5242) by 0x5961F3: device_set_realized (qdev.c:835) by 0x7038F6: property_set_bool (object.c:2080) by 0x707EFE: object_property_set_qobject (qom-qobject.c:26) by 0x705814: object_property_set_bool (object.c:1338) by 0x498435: pc_new_cpu (pc.c:1549) by 0x49C67D: pc_cpus_init (pc.c:1681) Address 0x1ffeffee74 is on thread 1's stack in frame #2, created by kvm_arch_get_supported_msr_feature (kvm.c:445) It's harmless, but a little bit annoying, so silence it by properly initializing the whole structure with zeroes. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04target/i386: work around KVM_GET_MSRS bug for secondary execution controlsPaolo Bonzini
Some secondary controls are automatically enabled/disabled based on the CPUID values that are set for the guest. However, they are still available at a global level and therefore should be present when KVM_GET_MSRS is sent to /dev/kvm. Unfortunately KVM forgot to include those, so fix that. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04target/i386: add VMX featuresPaolo Bonzini
Add code to convert the VMX feature words back into MSR values, allowing the user to enable/disable VMX features as they wish. The same infrastructure enables support for limiting VMX features in named CPU models. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04vmxcap: correct the name of the variablesPaolo Bonzini
The low bits are 1 if the control must be one, the high bits are 1 if the control can be one. Correct the variable names as they are very confusing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04target/i386: add VMX definitionsPaolo Bonzini
These will be used to compile the list of VMX features for named CPU models, and/or by the code that sets up the VMX MSRs. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04target/i386: expand feature words to 64 bitsPaolo Bonzini
VMX requires 64-bit feature words for the IA32_VMX_EPT_VPID_CAP and IA32_VMX_BASIC MSRs. (The VMX control MSRs are 64-bit wide but actually have only 32 bits of information). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04target/i386: introduce generic feature dependency mechanismPaolo Bonzini
Sometimes a CPU feature does not make sense unless another is present. In the case of VMX features, KVM does not even allow setting the VMX controls to some invalid combinations. Therefore, this patch adds a generic mechanism that looks for bits that the user explicitly cleared, and uses them to remove other bits from the expanded CPU definition. If these dependent bits were also explicitly *set* by the user, this will be a warning for "-cpu check" and an error for "-cpu enforce". If not, then the dependent bits are cleared silently, for convenience. With VMX features, this will be used so that for example "-cpu host,-rdrand" will also hide support for RDRAND exiting. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04target/i386: handle filtered_features in a new function ↵Paolo Bonzini
mark_unavailable_features The next patch will add a different reason for filtering features, unrelated to host feature support. Extract a new function that takes care of disabling the features and optionally reporting them. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04tests/docker: only enable ubsan for test-clangPaolo Bonzini
-fsanitize=undefined is not the same thing as --enable-sanitizers. After commit 47c823e ("tests/docker: add sanitizers back to clang build", 2019-09-11) test-clang is almost duplicating the asan (test-debug) test, so partly revert commit 47c823e5b while leaving ubsan enabled. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04win32: work around main-loop busy loop on socket/fd eventMarc-André Lureau
Commit 05e514b1d4d5bd4209e2c8bbc76ff05c85a235f3 introduced an AIO context optimization to avoid calling event_notifier_test_and_clear() on ctx->notifier. On Windows, the same notifier is being used to wakeup the wait on socket events (see commit d3385eb448e38f828c78f8f68ec5d79c66a58b5d). The ctx->notifier event is added to the gpoll sources in aio_set_event_notifier(), aio_ctx_check() should clear the event regardless of ctx->notified, since Windows sets the event by itself, bypassing the aio->notified. This fixes qemu not clearing the event resulting in a busy loop. Paolo suggested to me on irc to call event_notifier_test_and_clear() after select() >0 from aio-win32.c's aio_prepare. Unfortunately, not all fds associated with ctx->notifiers are in AIO fd handlers set. (qemu_set_nonblock() in util/oslib-win32.c calls qemu_fd_register()). This is essentially a v2 of a patch that was sent earlier: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00420.html that resurfaced when James investigated Spice performance issues on Windows: https://gitlab.freedesktop.org/spice/spice/issues/36 In order to test that patch, I simply tried running test-char on win32, and it hangs. Applying that patch solves it. QIO idle sources are not dispatched. I haven't investigated much further, I suspect source priorities and busy looping still come into play. This version keeps the "notified" field, so event_notifier_poll() should still work as expected. Cc: James Le Cuirot <chewi@gentoo.org> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04tests: skip serial test on windowsMarc-André Lureau
Serial test is currently hard-coded to /dev/null. On Windows, serial chardev expect a COM: device, which may not be availble. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04util: WSAEWOULDBLOCK on connect should map to EINPROGRESSMarc-André Lureau
In general, WSAEWOULDBLOCK can be mapped to EAGAIN as done by socket_error() (or EWOULDBLOCK). But for connect() with non-blocking sockets, it actually means the operation is in progress: https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-connect "The socket is marked as nonblocking and the connection cannot be completed immediately." (this is also the behaviour implemented by GLib GSocket) This fixes socket_can_bind_connect() test on win32. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04Fix wrong behavior of cpu_memory_rw_debug() function in SMMDmitry Poletaev
There is a problem, that you don't have access to the data using cpu_memory_rw_debug() function when in SMM. You can't remotely debug SMM mode program because of that for example. Likely attrs version of get_phys_page_debug should be used to get correct asidx at the end to handle access properly. Here the patch to fix it. Signed-off-by: Dmitry Poletaev <poletaev@ispras.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04memory: allow memory_region_register_iommu_notifier() to failEric Auger
Currently, when a notifier is attempted to be registered and its flags are not supported (especially the MAP one) by the IOMMU MR, we generally abruptly exit in the IOMMU code. The failure could be handled more nicely in the caller and especially in the VFIO code. So let's allow memory_region_register_iommu_notifier() to fail as well as notify_flag_changed() callback. All sites implementing the callback are updated. This patch does not yet remove the exit(1) in the amd_iommu code. in SMMUv3 we turn the warning message into an error message saying that the assigned device would not work properly. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04vfio: Turn the container error into an Error handleEric Auger
The container error integer field is currently used to store the first error potentially encountered during any vfio_listener_region_add() call. However this fails to propagate detailed error messages up to the vfio_connect_container caller. Instead of using an integer, let's use an Error handle. Messages are slightly reworded to accomodate the propagation. Signed-off-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04i386: Add CPUID bit for CLZERO and XSAVEERPTRSebastian Andrzej Siewior
The CPUID bits CLZERO and XSAVEERPTR are availble on AMD's ZEN platform and could be passed to the guest. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04docker: test-debug: disable LeakSanitizerPaolo Bonzini
There are just too many leaks in device-introspect-test (especially for the plethora of arm and aarch64 boards) to make LeakSanitizer useful; disable it for now. Whoever is interested in debugging leaks can also use valgrind like this: QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64 \ QTEST_QEMU_IMG=qemu-img \ valgrind --trace-children=yes --leak-check=full \ tests/device-introspect-test -p /aarch64/device/introspect/concrete/defaults/none Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04lm32: do not leak memory on object_new/object_unrefPaolo Bonzini
Bottom halves and ptimers are malloced, but nothing in these files is freeing memory allocated by instance_init. Since these are sysctl devices that are never unrealized, just moving the allocations to realize is enough to avoid the leak in practice (and also to avoid upsetting asan when running device-introspect-test). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-11 10:14:14 +0000