Block patches for 7.0-rc2:
- Disable GLOBAL_STATE_CODE() assertion for the 7.0 release: We got
another bug report for this, and we do not have the time to
investigate before 7.0, so disable the assertion for the release, to
re-enable and continue investigation in the 7.1 cycle
- stream job fix (regarding interaction with concurrent block jobs)
- iotests fixes
# gpg: Signature made Tue 29 Mar 2022 15:55:33 BST
# gpg: using RSA key CB62D7A0EE3829E45F004D34A1FA40D098019CDF
# gpg: issuer "hreitz@redhat.com"
# gpg: Good signature from "Hanna Reitz <hreitz@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: CB62 D7A0 EE38 29E4 5F00 4D34 A1FA 40D0 9801 9CDF
* tag 'pull-block-2022-03-29' of https://gitlab.com/hreitz/qemu:
iotests: Fix status checks
block/stream: Drain subtree around graph change
main-loop: Disable GLOBAL_STATE_CODE() assertions
iotests: update test owner contact information
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
If the migration is over before we cancel it, we are
waiting in a loop a state that never comes because the state
is already "completed".
To avoid an infinite loop, skip the test if the migration
is "completed" before we were able to cancel it.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Message-id: 20220329124259.355995-1-lvivier@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
An iotest's 'paused' condition is fickle; it will be reported as true
whenever the job is drained, for example, or when it is in the process
of completing.
030 and 041 contain such checks, we should replace them by checking the
job status instead. (As was done for 129 in commit f9a6256b48
for the 'busy' condition.)
Additionally, when we want to test that a job is paused on error, we
might want to give it some time to actually switch to the paused state.
Do that by waiting on the corresponding JOB_STATUS_CHANGE event. (But
only if they are not already paused; the loops these places are in fetch
all VM events, so they may have already fetched that event from the
queue.)
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220324180221.24508-1-hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
When the stream block job cuts out the nodes between top and base in
stream_prepare(), it does not drain the subtree manually; it fetches the
base node, and tries to insert it as the top node's backing node with
bdrv_set_backing_hd(). bdrv_set_backing_hd() however will drain, and so
the actual base node might change (because the base node is actually not
part of the stream job) before the old base node passed to
bdrv_set_backing_hd() is installed.
This has two implications:
First, the stream job does not keep a strong reference to the base node.
Therefore, if it is deleted in bdrv_set_backing_hd()'s drain (e.g.
because some other block job is drained to finish), we will get a
use-after-free. We should keep a strong reference to that node.
Second, even with such a strong reference, the problem remains that the
base node might change before bdrv_set_backing_hd() actually runs and as
a result the wrong base node is installed.
Both effects can be seen in 030's TestParallelOps.test_overlapping_5()
case, which has five nodes, and simultaneously streams from the middle
node to the top node, and commits the middle node down to the base node.
As it is, this will sometimes crash, namely when we encounter the
above-described use-after-free.
Taking a strong reference to the base node, we no longer get a crash,
but the resuling block graph is less than ideal: The expected result is
obviously that all middle nodes are cut out and the base node is the
immediate backing child of the top node. However, if stream_prepare()
takes a strong reference to its base node (the middle node), and then
the commit job finishes in bdrv_set_backing_hd(), supposedly dropping
that middle node, the stream job will just reinstall it again.
Therefore, we need to keep the whole subtree drained in
stream_prepare(), so that the graph modification it performs is
effectively atomic, i.e. that the base node it fetches is still the base
node when bdrv_set_backing_hd() sets it as the top node's backing node.
Verify this by asserting in said 030's test case that the base node is
always the top node's immediate backing child when both jobs are done.
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220324140907.17192-1-hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Acked-by: Vladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru>
These assertions are very useful for developers to find bugs, and so
they have indeed pointed us towards bugs already. For users, it is not
so useful to find these bugs. We should probably not enable them in
releases until we are sufficiently certain that they will not fire
during normal operation, unless something is going seriously wrong.
For example, we have received a bug report that you cannot add an NBD
server on a BDS in an I/O thread with `-incoming defer`. I am sure this
is a real bug that needs investigation, but we do not really have that
time right now, so close to release, and so I would rather disable the
assertions to get time to investigate such reports.
(I am just putting the link as "buglink" below, not "closes", because
disabling the assertion will not fix the likely underlying bug.)
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/945
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220329093545.52114-1-hreitz@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Darwin patches
- UI fixes
# gpg: Signature made Mon 28 Mar 2022 23:42:21 BST
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* tag 'darwin-20220329' of https://github.com/philmd/qemu:
ui/console: Check console before emitting GL event
ui/cocoa: Respect left-command-key option
main-loop: Disable block backend global state assertion on Cocoa
gitattributes: Cover Objective-C source files
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This was attempted in commit 533b0a1a41 ("tests/tcg: Fix target-specific
Makefile variables path for user-mode", 2022-01-12) but it also used the
wrong path; default.mak is used for config/devices, not config/targets.
While at it, explain what the inclusion is about.
Cc: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The vhost-shadow-virtqueue.c build requires include files from
linux-headers/, so it cannot be built on non-Linux systems.
Fortunately it is only needed by vhost-vdpa, so move it there.
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
MIPS patches queue
- ABI fixes (Xuerui, Andreas)
- Memory API alias fix (David)
# gpg: Signature made Tue 29 Mar 2022 11:34:42 BST
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* tag 'mips-20220329' of https://github.com/philmd/qemu:
qemu-binfmt-conf.sh: mips: allow nonzero EI_ABIVERSION, distinguish o32 and n32
target/mips: Fix address space range declaration on n32
memory: Make memory_region_readd_subregion() properly handle mapped aliases
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
With the command line flag -mplt and a recent toolchain, ELF binaries
generated by gcc can obtain EI_ABIVERSION=1, which makes, e.g., gcc
three-stage bootstrap in a mips-unknown-linux-gnu qemu-user chroot
fail since the binfmt-misc magic does not match anymore. Also other
values are technically possible. qemu executes these binaries just
fine, so relax the mask for the EI_ABIVERSION byte at offset 0x08.
In addition, extend magic string to distinguish mips o32 and n32 ABI.
This information is given by the EF_MIPS_ABI2 (0x20) bit in the
e_flags field of the ELF header (a 4-byte value at offset 0x24 for
the here applicable ELFCLASS32).
See-also: ace3d65459
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: WANG Xuerui <xen0n@gentoo.org>
Cc: Laurent Vivier <laurent@vivier.eu>
Cc: WANG Xuerui <xen0n@gentoo.org>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Alex Bennee <alex.bennee@linaro.org>
Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>
Closes: https://gitlab.com/qemu-project/qemu/-/issues/843
Message-Id: <20220328204900.3914990-1-dilfridge@gentoo.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
memory_region_readd_subregion() wants to readd a region by first
removing it and then readding it. For readding, it doesn't use one of
the memory_region_add_*() variants, which is why fail to re-increment the
mr->mapped_via_alias counters, resulting in the
assert(alias->mapped_via_alias >= 0) in memory_region_del_subregion()
triggering the next time we call memory_region_readd_subregion().
Fix it by using memory_region_add_subregion_common() for readding the
region.
Reported-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Fixes: 5ead62185d ("memory: Make memory_region_is_mapped() succeed when mapped via an alias")
Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20220201100940.47788-1-david@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
ppc-7.0 queue:
* target/ppc: fix helper_xvmadd* argument order
# gpg: Signature made Sat 26 Mar 2022 12:57:54 GMT
# gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1
* tag 'pull-ppc-20220326' of https://github.com/legoater/qemu:
target/ppc: fix helper_xvmadd* argument order
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In commit 84d43d2e82 we rearranged the logging of errors in
process_mapc(), and inadvertently dropped the trailing newlines
from the log messages. Restore them. The same commit also
attempted to switch the ICID printing to hex (which is how we
print ICIDs elsewhere) but only did half the job, adding the
0x prefix but leaving the format string at %d; correct to %x.
Fixes: 84d43d2e82 ("hw/intc/arm_gicv3_its: In MAPC with V=0, don't check rdbase field")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Pull request
Philippe found cases where the 0x%d format string was used, leading to
misleading output. The patches look harmless and could save people time, so I
think it's worth including them in 7.0.
# gpg: Signature made Thu 24 Mar 2022 17:15:20 GMT
# 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
* tag 'block-pull-request' of https://gitlab.com/stefanha/qemu:
hw: Fix misleading hexadecimal format
block: Fix misleading hexadecimal format
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Some versions of Windows hang on reboot if their TSC value is greater
than 2^54. The calibration of the Hyper-V reference time overflows
and fails; as a result the processors' clock sources are out of sync.
The issue is that the TSC _should_ be reset to 0 on CPU reset and
QEMU tries to do that. However, KVM special cases writing 0 to the
TSC and thinks that QEMU is trying to hot-plug a CPU, which is
correct the first time through but not later. Thwart this valiant
effort and reset the TSC to 1 instead, but only if the CPU has been
run once.
For this to work, env->tsc has to be moved to the part of CPUArchState
that is not zeroed at the beginning of x86_cpu_reset.
Reported-by: Vadim Rozenfeld <vrozenfe@redhat.com>
Supersedes: <20220324082346.72180-1-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Some AMD processors expose the PKRU extended save state even if they do not have
the related PKU feature in CPUID. Worse, when they do they report a size of
64, whereas the expected size of the PKRU extended save state is 8, therefore
the esa->size == eax assertion does not hold.
The state is already ignored by KVM_GET_SUPPORTED_CPUID because it
was not enabled in the host XCR0. However, QEMU kvm_cpu_xsave_init()
runs before QEMU invokes arch_prctl() to enable dynamically-enabled
save states such as XTILEDATA, and KVM_GET_SUPPORTED_CPUID hides save
states that have yet to be enabled. Therefore, kvm_cpu_xsave_init()
needs to consult the host CPUID instead of KVM_GET_SUPPORTED_CPUID,
and dies with an assertion failure.
When setting up the ExtSaveArea array to match the host, ignore features that
KVM does not report as supported. This will cause QEMU to skip the incorrect
CPUID leaf instead of tripping the assertion.
Closes: https://gitlab.com/qemu-project/qemu/-/issues/916
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Analyzed-by: Yang Zhong <yang.zhong@intel.com>
Reported-by: Peter Krempa <pkrempa@redhat.com>
Tested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Various fixes for 7.0
- make clean also cleans tcg tests
- fix rounding error in i386 fildl[l]
- more clean-ups to gitdm/mailmap metadata
- apply some organisation to docs/devel
- clean-up semihosting argv handling
- add custom runner for aarch32
- remove old qemu_logo.pdf
- document QEMU_PLUGIN env var
# gpg: Signature made Wed 23 Mar 2022 10:41:03 GMT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full]
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-fixes-for-7.0-230322-1' of https://github.com/stsquad/qemu:
docs/tcg-plugins: document QEMU_PLUGIN behaviour
docs: remove qemu_logo.pdf
gitlab: include new aarch32 job in custom-runners
semihosting: clean up handling of expanded argv
docs/devel: try and impose some organisation
mailmap/gitdm: more fixes for bad tags and authors
target/i386: force maximum rounding precision for fildl[l]
tests/Makefile.include: Let "make clean" remove the TCG tests, too
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In the physical machine environment, when a SRAR error occurs,
the IA32_MCG_STATUS RIPV bit is set, but qemu does not set this
bit. When qemu injects an SRAR error into virtual machine, the
virtual machine kernel just call do_machine_check() to kill the
current task, but not call memory_failure() to isolate the faulty
page, which will cause the faulty page to be allocated and used
repeatedly. If used by the virtual machine kernel, it will cause
the virtual machine to crash
Signed-off-by: luofei <luofei@unicloud.com>
Message-Id: <20220120084634.131450-1-luofei@unicloud.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fix vCPU hot-unplug related leak reported by Valgrind:
==132362== 4,096 bytes in 1 blocks are definitely lost in loss record 8,440 of 8,549
==132362== at 0x4C3B15F: memalign (vg_replace_malloc.c:1265)
==132362== by 0x4C3B288: posix_memalign (vg_replace_malloc.c:1429)
==132362== by 0xB41195: qemu_try_memalign (memalign.c:53)
==132362== by 0xB41204: qemu_memalign (memalign.c:73)
==132362== by 0x7131CB: kvm_init_xsave (kvm.c:1601)
==132362== by 0x7148ED: kvm_arch_init_vcpu (kvm.c:2031)
==132362== by 0x91D224: kvm_init_vcpu (kvm-all.c:516)
==132362== by 0x9242C9: kvm_vcpu_thread_fn (kvm-accel-ops.c:40)
==132362== by 0xB2EB26: qemu_thread_start (qemu-thread-posix.c:556)
==132362== by 0x7EB2159: start_thread (in /usr/lib64/libpthread-2.28.so)
==132362== by 0x9D45DD2: clone (in /usr/lib64/libc-2.28.so)
Reported-by: Mark Kanda <mark.kanda@oracle.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Mark Kanda <mark.kanda@oracle.com>
Message-Id: <20220322120522.26200-1-philippe.mathieu.daude@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
QEMU plugins can be loaded via command line arguments or via
the QEMU_PLUGIN environment variable. Currently, only the first method
is documented. Let's document QEMU_PLUGIN.
As drive-by cleanup, this patch fixes the path to the plugins
in the same section of the documentation.
Signed-off-by: Christoph Muellner <cmuellner@linux.com>
Message-Id: <20220316181412.1550044-1-cmuellner@linux.com>
[AJB: fixed some minor typos]
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Another cleanup patch tripped over the fact we weren't being careful
in our casting. Fix the casts, allow for a non-const and switch from
g_realloc to g_renew.
The whole semihosting argument handling could do with some tests
though.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220315121251.2280317-8-alex.bennee@linaro.org>
We have a growing set of developer docs but the index is currently in
order of when stuff was added. Try and make things a bit easier to
find my adding sub indexes and organising into themes.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com>
Message-Id: <20220315121251.2280317-7-alex.bennee@linaro.org>
I was running some historical tags for the last 10 years and got the
following warnings:
git log --use-mailmap --numstat --since "June 2010" | ~/src/gitdm.git/gitdm -n -l 5
alarson@ddci.com is an author name, probably not what you want
bad utf-8 ('utf-8' codec can't decode byte 0xe4 in position 552: invalid continuation byte) in patchm skipping
bad utf-8 ('utf-8' codec can't decode byte 0xe4 in position 342: invalid continuation byte) in patchm skipping
michael@ozlabs.org is an author name, probably not what you want
Oops...funky email nicta.com.au
bad utf-8 ('utf-8' codec can't decode byte 0xe9 in position 232: invalid continuation byte) in patchm skipping
Oops...funky email andreas.faerber
Grabbing changesets...done
Processed 76422 csets from 1902 developers
The following fixes try and alleviate that although I still get a
warning for Aaron which I think is from 9743cd5736.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220315121251.2280317-6-alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Acked-by: Aaron Larson <alarson@ddci.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: Andreas Färber <andreas.faerber@web.de>
Cc: Jason Wang <jasowang@redhat.com>
Victor Toso