summary refs log tree commit diff stats
path: root/docs/sphinx/kerneldoc.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-04-14configure: Honour --disable-werror for SphinxPeter Maydell2-2/+9
If we are not making warnings fatal for compilation, make them non-fatal when building the Sphinx documentation also. (For instance Sphinx 3.0 warns about some constructs that older versions were happy with, which is a build failure if we use the warnings-as-errors flag.) This provides a workaround at least for LP:1872113. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200411182934.28678-2-peter.maydell@linaro.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2020-04-14docs: Improve our gdbstub documentationPeter Maydell2-14/+34
The documentation of our -s and -gdb options is quite old; in particular it still claims that it will cause QEMU to stop and wait for the gdb connection, when this has not been true for some time: you also need to pass -S if you want to make QEMU not launch the guest on startup. Improve the documentation to mention this requirement in the executable's --help output, the documentation of the -gdb option in the manual, and in the "GDB usage" chapter. Includes some minor tweaks to these paragraphs of documentation since I was editing them anyway (such as dropping the description of our gdb support as "primitive"). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200403094014.9589-1-peter.maydell@linaro.org
2020-04-14scripts/coverity-scan: Add Docker supportPeter Maydell2-0/+221
Add support for running the Coverity Scan tools inside a Docker container rather than directly on the host system. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200319193323.2038-7-peter.maydell@linaro.org
2020-04-14scripts/run-coverity-scan: Script to run Coverity Scan buildPeter Maydell2-0/+316
Add a new script to automate the process of running the Coverity Scan build tools and uploading the resulting tarball to the website. This is intended eventually to be driven from Travis, but it can be run locally, if you are a maintainer of the QEMU project on the Coverity Scan website and have the secret upload token. The script must be run on a Fedora 30 system. Support for using a Docker container is added in a following commit. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200319193323.2038-6-peter.maydell@linaro.org
2020-04-14linux-user/flatload.c: Use "" for include of QEMU header target_flat.hPeter Maydell1-1/+1
The target_flat.h file is a QEMU header, so we should include it using quotes, not angle brackets. Coverity otherwise is unable to find the header: "../linux-user/flatload.c", line 40: error #1712: cannot open source file "target_flat.h" #include <target_flat.h> ^ because the relevant directory is only on the -iquote path, not the -I path. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200319193323.2038-5-peter.maydell@linaro.org
2020-04-14thread.h: Remove trailing semicolons from Coverity qemu_mutex_lock() etcPeter Maydell1-6/+6
All the Coverity-specific definitions of qemu_mutex_lock() and friends have a trailing semicolon. This works fine almost everywhere because of QEMU's mandatory-braces coding style and because most callsites are simple, but target/s390x/sigp.c has a use of qemu_mutex_trylock() as an if() statement, which makes the ';' a syntax error: "../target/s390x/sigp.c", line 461: warning #18: expected a ")" if (qemu_mutex_trylock(&qemu_sigp_mutex)) { ^ Remove the bogus semicolons from the macro definitions. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200319193323.2038-4-peter.maydell@linaro.org
2020-04-14thread.h: Fix Coverity version of qemu_cond_timedwait()Peter Maydell1-1/+1
For Coverity's benefit, we provide simpler versions of functions like qemu_mutex_lock(), qemu_cond_wait() and qemu_cond_timedwait(). When we added qemu_cond_timedwait() in commit 3dcc9c6ec4ea, a cut and paste error meant that the Coverity version of qemu_cond_timedwait() was using the wrong _impl function, which makes the Coverity parser complain: "/qemu/include/qemu/thread.h", line 159: warning #140: too many arguments in function call return qemu_cond_timedwait(cond, mutex, ms); ^ "/qemu/include/qemu/thread.h", line 159: warning #120: return value type does not match the function type return qemu_cond_timedwait(cond, mutex, ms); ^ "/qemu/include/qemu/thread.h", line 156: warning #1563: function "qemu_cond_timedwait" not emitted, consider modeling it or review parse diagnostics to improve fidelity static inline bool (qemu_cond_timedwait)(QemuCond *cond, QemuMutex *mutex, ^ These aren't fatal, but reduce the scope of the analysis. Fix the error. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200319193323.2038-3-peter.maydell@linaro.org
2020-04-14osdep.h: Drop no-longer-needed Coverity workaroundsPeter Maydell1-14/+0
In commit a1a98357e3fd in 2018 we added some workarounds for Coverity not being able to handle the _Float* types introduced by recent glibc. Newer versions of the Coverity scan tools have support for these types, and will fail with errors about duplicate typedefs if we have our workaround. Remove our copy of the typedefs. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200319193323.2038-2-peter.maydell@linaro.org
2020-04-13exec: Fix for qemu_ram_resize() callbackDavid Hildenbrand1-2/+14
Summarizing the issue: 1. Memory regions contain ram blocks with a different size, if the size is not properly aligned. While memory regions can have an unaligned size, ram blocks can't. This is true when creating resizable memory region with an unaligned size. 2. When resizing a ram block/memory region, the size of the memory region is set to the aligned size. The callback is called with the aligned size. The unaligned piece is lost. Because of the above, if ACPI blob length modifications happens after the initial virt_acpi_build() call, and the changed blob length is within the PAGE size boundary, then the revised size is not seen by the firmware on Guest reboot. Hence make sure callback is called if memory region size is changed, irrespective of aligned or not. Signed-off-by: David Hildenbrand <david@redhat.com> [Shameer: added commit log] Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200403101827.30664-4-shameerali.kolothum.thodi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-04-13fw_cfg: Migrate ACPI table mr sizes separatelyShameer Kolothum3-1/+97
Any sub-page size update to ACPI MRs will be lost during migration, as we use aligned size in ram_load_precopy() -> qemu_ram_resize() path. This will result in inconsistency in FWCfgEntry sizes between source and destination. In order to avoid this, save and restore them separately during migration. Up until now, this problem may not be that relevant for x86 as both ACPI table and Linker MRs gets padded and aligned. Also at present, qemu_ram_resize() doesn't invoke callback to update FWCfgEntry for unaligned size changes. But since we are going to fix the qemu_ram_resize() in the subsequent patch, the issue may become more serious especially for RSDP MR case. Moreover, the issue will soon become prominent in arm/virt as well where the MRs are not padded or aligned at all and eventually have acpi table changes as part of future additions like NVDIMM hot-add feature. Suggested-by: David Hildenbrand <david@redhat.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Acked-by: David Hildenbrand <david@redhat.com> Message-Id: <20200403101827.30664-3-shameerali.kolothum.thodi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-04-13acpi: Use macro for table-loader file nameShameer Kolothum3-2/+3
Use macro for "etc/table-loader" and move it to the header file similar to ACPI_BUILD_TABLE_FILE/ACPI_BUILD_RSDP_FILE etc. Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200403101827.30664-2-shameerali.kolothum.thodi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-04-13MAINTAINERS: Add myself as vhost-user-blk maintainerRaphael Norwitz1-0/+12
As suggested by Michael, let's add me as a maintainer of vhost-user-blk and vhost-user-scsi. CC: Michael S. Tsirkin <mst@redhat.com> CC Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <1585213047-20089-1-git-send-email-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-04-13module: increase dirs array size by oneBruce Rogers1-1/+1
With the module upgrades code change, the statically sized dirs array can now overflow. Increase it's size by one, according to the new maximum possible usage. Fixes: bd83c861c0 ("modules: load modules from versioned /var/run dir") Signed-off-by: Bruce Rogers <brogers@suse.com> Message-Id: <20200411010746.472295-1-brogers@suse.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-13memory: Do not allow direct write access to rom_device regionsAlexander Duyck1-2/+2
According to the documentation in memory.h a ROM memory region will be backed by RAM for reads, but is supposed to go through a callback for writes. Currently we were not checking for the existence of the rom_device flag when determining if we could perform a direct write or not. To correct that add a check to memory_region_is_direct so that if the memory region has the rom_device flag set we will return false for all checks where is_write is set. Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Message-Id: <20200410034150.24738.98143.stgit@localhost.localdomain> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-13vl.c: error out if -mem-path is used together with -M memory-backendIgor Mammedov1-0/+5
the former is not actually used by explicit backend, so instead of silently ignoring the option in non valid context, exit with error. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200409134133.11339-1-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-13rcu: do not mention atomic_mb_read/set in documentationPaolo Bonzini1-2/+2
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-13atomics: update documentationPaolo Bonzini1-210/+271
Some of the constraints on operand sizes have been relaxed, so adjust the documentation. Deprecate atomic_mb_read and atomic_mb_set; it is not really possible to use them correctly because they do not interoperate with sequentially-consistent RMW operations. Finally, extend the memory barrier pairing section to cover acquire and release semantics in general, roughly based on the KVM Forum 2016 talk, "<atomic.h> weapons". Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-12tcg/mips: mips sync* encode errorlixinyu1-5/+5
OPC_SYNC_WMB, OPC_SYNC_MB, OPC_SYNC_ACQUIRE, OPC_SYNC_RELEASE and OPC_SYNC_RMB have wrong encode. According to the mips manual, their encode should be 'OPC_SYNC | 0x?? << 6' rather than 'OPC_SYNC | 0x?? << 5'. Wrong encode can lead illegal instruction errors. These instructions often appear with multi-threaded simulation. Fixes: 6f0b99104a3 ("tcg/mips: Add support for fence") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: lixinyu <precinct@mail.ustc.edu.cn> Message-Id: <20200411124612.12560-1-precinct@mail.ustc.edu.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-04-11atomics: convert to reStructuredTextPaolo Bonzini3-403/+447
No attempts to fix or update the text; these are left for the next patch in the series. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-11oslib-posix: take lock before qemu_cond_broadcastBauerchen1-0/+3
In touch_all_pages, if the mutex is not taken around qemu_cond_broadcast, qemu_cond_broadcast may be called before all touch page threads enter qemu_cond_wait. In this case, the touch page threads wait forever for the main thread to wake them up, causing a deadlock. Signed-off-by: Bauerchen <bauerchen@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-11piix: fix xenfv regression, add compat machine xenfv-4.2Olaf Hering4-39/+26
With QEMU 4.0 an incompatible change was added to pc_piix, which makes it practical impossible to migrate domUs started with qemu2 or qemu3 to newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea added and enabled a new member "smbus_no_migration_support". In commit 4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new elements, which are conditionally filled. As a result, an incoming migration expected smbus related data unless smbus migration was disabled for a given MachineClass. Since first commit forgot to handle 'xenfv', domUs started with QEMU 4.x are incompatible with their QEMU siblings. Using other existing machine types, such as 'pc-i440fx-3.1', is not possible because 'xenfv' creates the 'xen-platform' PCI device at 00:02.0, while all other variants to run a domU would create it at 00:04.0. To cover both the existing and the broken case of 'xenfv' in a single qemu binary, a new compatibility variant of 'xenfv-4.2' must be added which targets domUs started with qemu 4.2. The existing 'xenfv' restores compatibility of QEMU 5.x with qemu 3.1. Host admins who started domUs with QEMU 4.x (preferrable QEMU 4.2) have to use a wrapper script which appends '-machine xenfv-4.2' to the device-model command line. This is only required if there is no maintenance window which allows to temporary shutdown the domU and restart it with a fixed device-model. The wrapper script is as simple as this: #!/bin/sh exec /usr/bin/qemu-system-i386 "$@" -machine xenfv-4.2 With xl this script will be enabled with device_model_override=, see xl.cfg(5). To live migrate a domU, adjust the existing domU.cfg and pass it to xl migrate or xl save/restore: xl migrate -C new-domU.cfg domU remote-host xl save domU CheckpointFile new-domU.cfg xl restore new-domU.cfg CheckpointFile With libvirt this script will be enabled with the <emulator> element in domU.xml. Use 'virsh edit' prior 'virsh migrate' to replace the existing <emulator> element to point it to the wrapper script. Signed-off-by: Olaf Hering <olaf@aepfle.de> Message-Id: <20200327151841.13877-1-olaf@aepfle.de> [Adjust tests for blacklisted machine types, simplifying the one in qom-test. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-09async: use explicit memory barriersPaolo Bonzini3-9/+40
When using C11 atomics, non-seqcst reads and writes do not participate in the total order of seqcst operations. In util/async.c and util/aio-posix.c, in particular, the pattern that we use write ctx->notify_me write bh->scheduled read bh->scheduled read ctx->notify_me if !bh->scheduled, sleep if ctx->notify_me, notify needs to use seqcst operations for both the write and the read. In general this is something that we do not want, because there can be many sources that are polled in addition to bottom halves. The alternative is to place a seqcst memory barrier between the write and the read. This also comes with a disadvantage, in that the memory barrier is implicit on strongly-ordered architectures and it wastes a few dozen clock cycles. Fortunately, ctx->notify_me is never written concurrently by two threads, so we can assert that and relax the writes to ctx->notify_me. The resulting solution works and performs well on both aarch64 and x86. Note that the atomic_set/atomic_read combination is not an atomic read-modify-write, and therefore it is even weaker than C11 ATOMIC_RELAXED; on x86, ATOMIC_RELAXED compiles to a locked operation. Analyzed-by: Ying Fang <fangying1@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Ying Fang <fangying1@huawei.com> Message-Id: <20200407140746.8041-6-pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-04-09aio-wait: delegate polling of main AioContext if BQL not heldPaolo Bonzini2-19/+32
Any thread that is not a iothread returns NULL for qemu_get_current_aio_context(). As a result, it would also return true for in_aio_context_home_thread(qemu_get_aio_context()), causing AIO_WAIT_WHILE to invoke aio_poll() directly. This is incorrect if the BQL is not held, because aio_poll() does not expect to run concurrently from multiple threads, and it can actually happen when savevm writes to the vmstate file from the migration thread. Therefore, restrict in_aio_context_home_thread to return true for the main AioContext only if the BQL is held. The function is moved to aio-wait.h because it is mostly used there and to avoid a circular reference between main-loop.h and block/aio.h. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200407140746.8041-5-pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-04-09aio-posix: signal-proof fdmon-io_uringStefan Hajnoczi1-2/+8
The io_uring_enter(2) syscall returns with errno=EINTR when interrupted by a signal. Retry the syscall in this case. It's essential to do this in the io_uring_submit_and_wait() case. My interpretation of the Linux v5.5 io_uring_enter(2) code is that it shouldn't affect the io_uring_submit() case, but there is no guarantee this will always be the case. Let's check for -EINTR around both APIs. Note that the liburing APIs have -errno return values. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200408091139.273851-1-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-04-07target/rx/translate: Add missing fall through commentPhilippe Mathieu-Daudé1-0/+1
Coverity reported a missing fall through comment, add it. Fixes: e5918d7d7f0 ("target/rx: TCG translation") Reported-by: Coverity (CID 1422222 MISSING_BREAK) Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200403184419.28556-1-philmd@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-04-07target/xtensa: statically allocate xtensa_insnbufs in DisasContextMax Filippov3-16/+6
Rather than dynamically allocate, and risk failing to free when we longjmp out of the translator, allocate the maximum buffer size based on the maximum supported instruction length. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Richard Henderson <richard.henderson@linaro.org>
2020-04-07target/xtensa: fix pasto in pfwait.r opcode nameMax Filippov1-1/+1
Core xtensa opcode table has pfwait.o instead of pfwait.r. Fix that. Fixes: c884400f2988 ("target/xtensa: implement block prefetch option opcodes") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-04-07Update version for v5.0.0-rc2 releasePeter Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-07tcg/i386: Fix %r12 guest_base initializationRichard Henderson1-1/+1
When %gs cannot be used, we use register offset addressing. This path is almost never used, so it was clearly not tested. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200406174803.8192-1-richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2020-04-07configure: Add -Werror to PIE probeRichard Henderson1-2/+2
Without -Werror, the probe may succeed, but then compilation fails later when -Werror is added for other reasons. Shows up on windows, where the compiler complains about -fPIC. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200401214756.6559-1-richard.henderson@linaro.org> Message-Id: <20200403191150.863-13-alex.bennee@linaro.org>
2020-04-07hw/core: properly terminate loading .hex on EOF recordAlex Bennée1-1/+4
The https://makecode.microbit.org/#editor generates slightly weird .hex files which work fine on a real microbit but causes QEMU to choke. The reason is extraneous data after the EOF record which causes the loader to attempt to write a bigger file than it should to the "rom". According to the HEX file spec an EOF really should be the last thing we process so lets do that. Reported-by: Ursula Bennée <alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200403191150.863-12-alex.bennee@linaro.org>
2020-04-07linux-user: clean-up padding on /proc/self/mapsAlex Bennée1-13/+19
Don't use magic spaces, calculate the justification for the file field like the kernel does with seq_pad. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200403191150.863-10-alex.bennee@linaro.org>
2020-04-07linux-user: factor out reading of /proc/self/mapsAlex Bennée4-30/+151
Unfortunately reading /proc/self/maps is still considered the gold standard for a process finding out about it's own memory layout. As we will want this data in other contexts soon factor out the code to read and parse the data. Rather than just blindly copying the existing sscanf based code we use a more modern glib version of the parsing code to make a more general purpose map structure. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200403191150.863-9-alex.bennee@linaro.org>
2020-04-07softfloat: Fix BAD_SHIFT from normalizeFloatx80SubnormalRichard Henderson1-0/+3
All other calls to normalize*Subnormal detect zero input before the call -- this is the only outlier. This case can happen with +0.0 + +0.0 = +0.0 or -0.0 + -0.0 = -0.0, so return a zero of the correct sign. Reported-by: Coverity (CID 1421991) Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200327232042.10008-1-richard.henderson@linaro.org> Message-Id: <20200403191150.863-8-alex.bennee@linaro.org>
2020-04-07gdbstub: fix compiler complainingDenis Plotnikov1-2/+2
./gdbstub.c: In function ‘handle_query_thread_extra’: /usr/include/glib-2.0/glib/glib-autocleanups.h:28:10: error: ‘cpu_name’ may be used uninitialized in this function [-Werror=maybe-uninitialized] g_free (*pp); ^ ./gdbstub.c:2063:26: note: ‘cpu_name’ was declared here g_autofree char *cpu_name; ^ cc1: all warnings being treated as errors Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com> Message-Id: <20200326151407.25046-1-dplotnikov@virtuozzo.com> Reported-by: Euler Robot <euler.robot@huawei.com> Reported-by: Chen Qun <kuhn.chenqun@huawei.com> Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com> Message-Id: <20200325092137.24020-1-kuhn.chenqun@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200403191150.863-7-alex.bennee@linaro.org>
2020-04-07target/xtensa: add FIXME for translation memory leakAlex Bennée1-0/+5
Dynamically allocating a new structure within the DisasContext can potentially leak as we can longjmp out of the translation loop (see test_phys_mem). The proper fix would be to use static allocation within the DisasContext but as the Xtensa translator imports it's code from elsewhere I leave that as an exercise for the maintainer. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Message-Id: <20200403191150.863-6-alex.bennee@linaro.org>
2020-04-07linux-user: more debug for init_guest_spaceAlex Bennée1-1/+7
Searching for memory space can cause problems so lets extend the CPU_LOG_PAGE output so you can watch init_guest_space fail to allocate memory. A more involved fix is actually required to make this function play nicely with the large guard pages the sanitiser likes to use. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20200403191150.863-5-alex.bennee@linaro.org>
2020-04-07tests/tcg: remove extraneous pasting macrosAlex Bennée1-4/+1
We are not using them and they just get in the way. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200403191150.863-4-alex.bennee@linaro.org>
2020-04-07linux-user: protect fcntl64 with an #ifdefAlex Bennée1-4/+4
Checking TARGET_ABI_BITS is sketchy - we should check for the presence of the define to be sure. Also clean up the white space while we are there. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200403191150.863-3-alex.bennee@linaro.org>
2020-04-07elf-ops: bail out if we have no function symbolsAlex Bennée1-23/+25
It's perfectly possible to have no function symbols in your elf file and if we do the undefined behaviour sanitizer rightly complains about us passing NULL to qsort. Check nsyms before we go ahead. While we are at it lets drop the unchecked return value and cleanup the fail leg by use of g_autoptr. Another fix was proposed 101 weeks ago in: Message-Id: 20180421232120.22208-1-f4bug@amsat.org Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200403191150.863-2-alex.bennee@linaro.org>
2020-04-07.github: Enable repo-lockdown bot to refuse GitHub pull requestsPhilippe Mathieu-Daudé2-0/+35
Some GitHub users try to open pull requests against the GitHub mirror. Unfortunate these get ignored until eventually someone notices and closes the request. Enable the 'Repo Lockdown' [*] 3rd party bot which can autorespond to pull requests with a friendly comment, close the request, and then lock it to prevent further comments. [*] https://github.com/dessant/repo-lockdown Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: John Snow <jsnow@redhat.com> Message-Id: <20200406214125.18538-1-f4bug@amsat.org> [AJB: s/fill/file/ and point at canonical qemu.org/contribute] Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2020-04-07MAINTAINERS: Add xen-usb.c to Xen sectionAnthony PERARD1-0/+1
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Paul Durrant <paul@xen.org> Message-Id: <20200406165043.1447837-1-anthony.perard@citrix.com>
2020-04-07xen-block: Fix uninitialized variableAnthony PERARD1-1/+1
Since 7f5d9b206d1e ("object-add: don't create return value if failed"), qmp_object_add() don't write any value in 'ret_data', thus has random data. Then qobject_unref() fails and abort(). Fix by initialising 'ret_data' properly. Fixes: 5f07c4d60d09 ("qapi: Flatten object-add") Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200406164207.1446817-1-anthony.perard@citrix.com>
2020-04-07hw/usb/xen-usb.c: Pass struct usbback_req* to usbback_packet_complete()Peter Maydell1-6/+4
The function usbback_packet_complete() currently takes a USBPacket*, which must be a pointer to the packet field within a struct usbback_req; the function uses container_of() to get the struct usbback_req* given the USBPacket*. This is unnecessarily confusing (and in particular it confuses the Coverity Scan analysis, resulting in the false positive CID 1421919 where it thinks that we write off the end of the structure). Since both callsites already have the pointer to the struct usbback_req, just pass that in directly. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200323164318.26567-1-peter.maydell@linaro.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2020-04-07vpc: Don't round up already aligned BAT sizesKevin Wolf1-1/+1
As reported on Launchpad, Azure apparently doesn't accept images for upload that are not both aligned to 1 MB blocks and have a BAT size that matches the image size exactly. As far as I can tell, there is no real reason why we create a BAT that is one entry longer than necessary for aligned image sizes, so change that. (Even though the condition is only mentioned as "should" in the spec and previous products accepted larger BATs - but we'll try to maintain compatibility with as many of Microsoft's ever-changing interpretations of the VHD spec as possible.) Fixes: https://bugs.launchpad.net/bugs/1870098 Reported-by: Tobias Witek Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200402093603.2369-1-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-04-07block: Fix blk->in_flight during blk_wait_while_drained()Kevin Wolf1-12/+5
Waiting in blk_wait_while_drained() while blk->in_flight is increased for the current request is wrong because it will cause the drain operation to deadlock. This patch makes sure that blk_wait_while_drained() is called with blk->in_flight increased exactly once for the current request, and that it temporarily decreases the counter while it waits. Fixes: cf3129323f900ef5ddbccbe86e4fa801e88c566e Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200407121259.21350-4-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-04-07block: Increase BB.in_flight for coroutine and sync interfacesKevin Wolf2-24/+80
External callers of blk_co_*() and of the synchronous blk_*() functions don't currently increase the BlockBackend.in_flight counter, but calls from blk_aio_*() do, so there is an inconsistency whether the counter has been increased or not. This patch moves the actual operations to static functions that can later know they will always be called with in_flight increased exactly once, even for external callers using the blk_co_*() coroutine interfaces. If the public blk_co_*() interface is unused, remove it. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200407121259.21350-3-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-04-07block-backend: Reorder flush/pdiscard function definitionsKevin Wolf1-46/+46
Move all variants of the flush/pdiscard functions to a single place and put the blk_co_*() version first because it is called by all other variants (and will become static in the next patch). Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200407121259.21350-2-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-04-07backup: don't acquire aio_context in backup_cleanStefan Reiter1-4/+0
All code-paths leading to backup_clean (via job_clean) have the job's context already acquired. The job's context is guaranteed to be the same as the one used by backup_top via backup_job_create. Since the previous logic effectively acquired the lock twice, this broke cleanup of backups for disks using IO threads, since the BDRV_POLL_WHILE in bdrv_backup_top_drop -> bdrv_do_drained_begin would only release the lock once, thus deadlocking with the IO thread. This is a partial revert of 0abf2581717a19. Signed-off-by: Stefan Reiter <s.reiter@proxmox.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200407115651.69472-4-s.reiter@proxmox.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-04-07replication: assert we own context before job_cancel_syncStefan Reiter1-1/+4
job_cancel_sync requires the job's lock to be held, all other callers already do this (replication_stop, drive_backup_abort, blockdev_backup_abort, job_cancel_sync_all, cancel_common). In this case we're in a BlockDriver handler, so we already have a lock, just assert that it is the same as the one used for the commit_job. Signed-off-by: Stefan Reiter <s.reiter@proxmox.com> Message-Id: <20200407115651.69472-3-s.reiter@proxmox.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>