Paolo Bonzini [Wed, 19 Aug 2020 12:44:56 +0000 (08:44 -0400)]
libqemuutil, qapi, trace: convert to meson
This shows how to do some "computations" in meson.build using its array
and dictionary data structures, and also a basic usage of the sourceset
module for conditional compilation.
Notice the new "if have_system" part of util/meson.build, which fixes
a bug in the old build system was buggy: util/dbus.c was built even for
non-softmmu builds, but the dependency on -lgio was lost when the linking
was done through libqemuutil.a. Because all of its users required gio
otherwise, the bug was hidden. Meson instead propagates libqemuutil's
dependencies down to its users, and shows the problem.
Paolo Bonzini [Tue, 28 Jan 2020 13:48:54 +0000 (14:48 +0100)]
meson: add testsuite Makefile generator
Rules to execute tests are generated by a simple Python program
that integrates into the existing "make check" mechanism. This
provides familiarity for developers, and also allows piecewise
conversion of the testsuite Makefiles to meson.
The generated rules are based on QEMU's existing test harness
Makefile and TAP parser.
In order to link the *-obj-y files into tests, we will make static
libraries of them in Meson, and then link them as whole archives
into the tests. To separate regular static libraries from link-whole
libraries, give them a different file extension.
Paolo Bonzini [Mon, 10 Jun 2019 10:05:14 +0000 (12:05 +0200)]
configure: integrate Meson in the build system
The Meson build system is integrated in the existing configure/make steps
by invoking Meson from the configure script and converting Meson's build.ninja
rules to an included Makefile.
build.ninja already provides tags/ctags/cscope rules, so they are removed.
configure: add support for pseudo-"in source tree" builds
Meson requires the build dir to be separate from the source tree. Many
people are used to just running "./configure && make" though and the
meson conversion breaks that.
This introduces some backcompat support to make it appear as if an
"in source tree" build is being done, but with the results in the
"build/" directory. This allows "./configure && make" to work as it
did historically, albeit with the output binaries staying under build/.
Paolo Bonzini [Mon, 3 Feb 2020 14:22:17 +0000 (15:22 +0100)]
configure: prepare CFLAGS/CXXFLAGS/LDFLAGS for Meson
Split between CFLAGS/QEMU_CFLAGS and CXXFLAGS/QEMU_CXXFLAGS so that
we will use CFLAGS and CXXFLAGS for flags that we do not want to
pass to add_project_arguments.
Paolo Bonzini [Tue, 4 Feb 2020 11:41:01 +0000 (12:41 +0100)]
meson: rename included C source files to .c.inc
With Makefiles that have automatically generated dependencies, you
generated includes are set as dependencies of the Makefile, so that they
are built before everything else and they are available when first
building the .c files.
Alternatively you can use a fine-grained dependency, e.g.
With Meson you have only one choice and it is a third option, namely
"build at the beginning of the corresponding target"; the way you
express it is to list the includes in the sources of that target.
The problem is that Meson decides if something is a source vs. a
generated include by looking at the extension: '.c', '.cc', '.m', '.C'
are sources, while everything else is considered an include---including
'.inc.c'.
Use '.c.inc' to avoid this, as it is consistent with our other convention
of using '.rst.inc' for included reStructuredText files. The editorconfig
file is adjusted.
Paolo Bonzini [Tue, 4 Feb 2020 11:20:10 +0000 (12:20 +0100)]
trace: switch position of headers to what Meson requires
Meson doesn't enjoy the same flexibility we have with Make in choosing
the include path. In particular the tracing headers are using
$(build_root)/$(<D).
In order to keep the include directives unchanged,
the simplest solution is to generate headers with patterns like
"trace/trace-audio.h" and place forwarding headers in the source tree
such that for example "audio/trace.h" includes "trace/trace-audio.h".
This patch is too ugly to be applied to the Makefiles now. It's only
a way to separate the changes to the tracing header files from the
Meson rewrite of the tracing logic.
Paolo Bonzini [Sun, 9 Aug 2020 15:17:00 +0000 (17:17 +0200)]
oss-fuzz/build: remove LIB_FUZZING_ENGINE
Meson build scripts will only include qemu-fuzz-TARGET rules if configured
with --enable-fuzzing, and that takes care of adding -fsanitize=fuzzer.
Therefore we can just specify the configure option and stop modifying
the CFLAGS and CONFIG_FUZZ options in the "make" invocation.
* remotes/maxreitz/tags/pull-block-2020-08-11:
iotests: add test for unaligned granularity bitmap backup
block/block-copy: always align copied region to cluster size
Stefan Reiter [Mon, 10 Aug 2020 09:55:23 +0000 (11:55 +0200)]
iotests: add test for unaligned granularity bitmap backup
Start a VM with a 4097 byte image attached, add a 4096 byte granularity
dirty bitmap, mark it dirty, and then do a backup.
This used to run into an assert and fail, check that it works as
expected and also check the created image to ensure that misaligned
backups in general work correctly.
Stefan Reiter [Mon, 10 Aug 2020 09:55:22 +0000 (11:55 +0200)]
block/block-copy: always align copied region to cluster size
Since commit 42ac214406e0 (block/block-copy: refactor task creation)
block_copy_task_create calculates the area to be copied via
bdrv_dirty_bitmap_next_dirty_area, but that can return an unaligned byte
count if the image's last cluster end is not aligned to the bitmap's
granularity.
Always ALIGN_UP the resulting bytes value to satisfy block_copy_do_copy,
which requires the 'bytes' parameter to be aligned to cluster size.
Peter Maydell [Tue, 4 Aug 2020 19:39:03 +0000 (20:39 +0100)]
target/arm: Fix Rt/Rt2 in ESR_ELx for copro traps from AArch32 to 64
When a coprocessor instruction in an AArch32 guest traps to AArch32
Hyp mode, the syndrome register (HSR) includes Rt and Rt2 fields
which are simply copies of the Rt and Rt2 fields from the trapped
instruction. However, if the instruction is trapped from AArch32 to
an AArch64 higher exception level, the Rt and Rt2 fields in the
syndrome register (ESR_ELx) must be the AArch64 view of the register.
This makes a difference if the AArch32 guest was in a mode other than
User or System and it was using r13 or r14, or if it was in FIQ mode
and using r8-r14.
We don't know at translate time which AArch32 CPU mode we are in, so
we leave the values we generate in our prototype syndrome register
value at translate time as the raw Rt/Rt2 from the instruction, and
instead correct them to the AArch64 view when we find we need to take
an exception from AArch32 to AArch64 with one of these syndrome
values.
Tuguoyi [Wed, 5 Aug 2020 09:22:58 +0000 (09:22 +0000)]
qcow2-cluster: Fix integer left shift error in qcow2_alloc_cluster_link_l2()
When calculating the offset, the result of left shift operation will be promoted
to type int64 automatically because the left operand of + operator is uint64_t.
but the result after integer promotion may be produce an error value for us and
trigger the following asserting error.
For example, consider i=0x2000, cluster_bits=18, the result of left shift
operation will be 0x80000000. Cause argument i is of signed integer type,
the result is automatically promoted to 0xffffffff80000000 which is not
we expected
The way to trigger the assertion error:
qemu-img create -f qcow2 -o preallocation=full,cluster_size=256k tmpdisk 10G
This patch fix it by casting @i to uint64_t before doing left shift operation
Peter Maydell [Wed, 5 Aug 2020 10:02:46 +0000 (11:02 +0100)]
Merge remote-tracking branch 'remotes/huth-gitlab/tags/pull-request-2020-08-05' into staging
* Test rx-softmmu, avr-softmmu, Centos7 and Debian on gitlab-CI
* Fix compiler warning on 32-bit big endian systems
* Remove remainders of libqemustub.a
* remotes/huth-gitlab/tags/pull-request-2020-08-05:
Get rid of the libqemustub.a remainders
target/riscv/vector_helper: Fix build on 32-bit big endian hosts
gitlab-ci: Fix Avocado cache usage
gitlab-ci.yml: Add build-system-debian and build-system-centos jobs
tests/acceptance: Disable the rx sash and arm cubieboard replay test on Gitlab
tests/docker: Add python3-venv and netcat to the debian-amd64 container
Thomas Huth [Mon, 3 Aug 2020 17:54:36 +0000 (19:54 +0200)]
target/riscv/vector_helper: Fix build on 32-bit big endian hosts
The code currently fails to compile on 32-bit big endian hosts:
target/riscv/vector_helper.c: In function 'vext_clear':
target/riscv/vector_helper.c:154:16: error: cast to pointer from integer
of different size [-Werror=int-to-pointer-cast]
memset((void *)((uintptr_t)tail & ~(7ULL)), 0, part1);
^
target/riscv/vector_helper.c:155:16: error: cast to pointer from integer
of different size [-Werror=int-to-pointer-cast]
memset((void *)(((uintptr_t)tail + 8) & ~(7ULL)), 0, part2);
^
cc1: all warnings being treated as errors
We should not use "long long" (i.e. 64-bit) values here to avoid the
problem. Switch to our QEMU_ALIGN_PTR_DOWN/UP macros instead.
Thomas Huth [Thu, 30 Jul 2020 08:35:48 +0000 (10:35 +0200)]
gitlab-ci: Fix Avocado cache usage
In commit 6957fd98dc ("gitlab: add avocado asset caching") we
tried to save the Avocado cache (as in commit c1073e44b4 with
Travis-CI) however it doesn't work as expected. For some reason
Avocado uses /root/avocado_cache/ which we can not select later.
Manually generate a Avocado config to force the use of the
current job's directory.
This patch is based on an earlier version from Philippe Mathieu-Daudé.
Thomas Huth [Tue, 14 Jul 2020 15:35:45 +0000 (17:35 +0200)]
gitlab-ci.yml: Add build-system-debian and build-system-centos jobs
We were missing the two new targets avr-softmmu and rx-softmmu in the
gitlab-CI so far, and did not add some of the "other endianess" targets
like sh4eb-softmmu yet.
Since the current build-system-* jobs run already for a very long time,
let's do not add these missing targets there, but introduce two new
additional build jobs, one running with Debian and one running with
CentOS, and add the new targets there. Also move some targets from
the old build-system-* jobs to these new targets, to distribute the
load and reduce the runtime of the CI.
Thomas Huth [Wed, 15 Jul 2020 04:35:01 +0000 (06:35 +0200)]
tests/docker: Add python3-venv and netcat to the debian-amd64 container
Without python3-venv, I get the following message when trying to
run the acceptance tests within the debian container:
The virtual environment was not created successfully because ensurepip is not
available. On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.
apt-get install python3-venv
You may need to use sudo with that command. After installing the python3-venv
package, recreate your virtual environment.
Let's do it as the message suggests.
And while we're at it, also add netcat here since it is required for
some of the acceptance tests.
Bruce Rogers [Thu, 30 Jul 2020 13:05:19 +0000 (07:05 -0600)]
virtio-mem: Correct format specifier mismatch for RISC-V
This likely affects other, less popular host architectures as well.
Less common host architectures under linux get QEMU_VMALLOC_ALIGN (from
which VIRTIO_MEM_MIN_BLOCK_SIZE is derived) define to a variable of
type uintptr, which isn't compatible with the format specifier used to
print a user message. Since this particular usage of the underlying data
seems unique to this file, the simple fix is to just cast
QEMU_VMALLOC_ALIGN to uint32_t, which corresponds to the format specifier
used.
accel/xen: Fix xen_enabled() behavior on target-agnostic objects
CONFIG_XEN is generated by configure and stored in "config-target.h",
which is (obviously) only include for target-specific objects.
This is a problem for target-agnostic objects as CONFIG_XEN is never
defined and xen_enabled() is always inlined as 'false'.
Fix by following the KVM schema, defining CONFIG_XEN_IS_POSSIBLE
when we don't know to force the call of the non-inlined function,
returning the xen_allowed boolean.
Peter Maydell [Tue, 4 Aug 2020 09:20:08 +0000 (10:20 +0100)]
Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into staging
# gpg: Signature made Tue 04 Aug 2020 07:15:08 BST
# gpg: using RSA key EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <[email protected]>" [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: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211
* remotes/jasowang/tags/net-pull-request:
hw/net/net_tx_pkt: fix assertion failure in net_tx_pkt_add_raw_fragment()
colo-compare: Remove superfluous NULL-pointer checks for s->iothread
hw/net/net_tx_pkt: fix assertion failure in net_tx_pkt_add_raw_fragment()
An assertion failure issue was found in the code that processes network packets
while adding data fragments into the packet context. It could be abused by a
malicious guest to abort the QEMU process on the host. This patch replaces the
affected assert() with a conditional statement, returning false if the current
data fragment exceeds max_raw_frags.
colo-compare: Remove superfluous NULL-pointer checks for s->iothread
s->iothread is checked for NULL on object creation in colo_compare_complete,
so it's guaranteed not to be NULL.
This resolves a false alert from Coverity (CID 1429969).
Peter Maydell [Mon, 3 Aug 2020 19:34:26 +0000 (20:34 +0100)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200803' into staging
target-arm queue:
* hw/timer/imx_epit: Avoid assertion when CR.SWR is written
* netduino2, netduinoplus2, microbit: set system_clock_scale so that
SysTick running on the CPU clock works
* target/arm: Avoid maybe-uninitialized warning with gcc 4.9
* target/arm: Fix AddPAC error indication
* Make AIRCR.SYSRESETREQ actually reset the system for the
microbit, mps2-*, musca-*, netduino* boards
* remotes/pmaydell/tags/pull-target-arm-20200803:
hw/timer/imx_epit: Avoid assertion when CR.SWR is written
hw/arm/nrf51_soc: Set system_clock_scale
target/arm: Avoid maybe-uninitialized warning with gcc 4.9
target/arm: Fix AddPAC error indication
msf2-soc, stellaris: Don't wire up SYSRESETREQ
hw/intc/armv7m_nvic: Provide default "reset the system" behaviour for SYSRESETREQ
include/hw/irq.h: New function qemu_irq_is_connected()
hw/arm/netduino2, netduinoplus2: Set system_clock_scale
Peter Maydell [Mon, 27 Jul 2020 15:45:50 +0000 (16:45 +0100)]
hw/timer/imx_epit: Avoid assertion when CR.SWR is written
The imx_epit device has a software-controllable reset triggered by
setting the SWR bit in the CR register. An error in commit cc2722ec83ad9
means that we will end up assert()ing if the guest does this, because
the code in imx_epit_write() starts ptimer transactions, and then
imx_epit_reset() also starts ptimer transactions, triggering
"ptimer_transaction_begin: Assertion `!s->in_transaction' failed".
The cleanest way to avoid this double-transaction is to move the
start-transaction for the CR write handling down below the check of
the SWR bit.
Peter Maydell [Mon, 27 Jul 2020 19:34:58 +0000 (20:34 +0100)]
hw/arm/nrf51_soc: Set system_clock_scale
The nrf51 SoC model wasn't setting the system_clock_scale
global.which meant that if guest code used the systick timer in "use
the processor clock" mode it would hang because time never advances.
Set the global to match the documented CPU clock speed for this SoC.
This SoC in fact doesn't have a SysTick timer (which is the only thing
currently that cares about the system_clock_scale), because it's
a configurable option in the Cortex-M0. However our Cortex-M0 and
thus our nrf51 and our micro:bit board do provide a SysTick, so
we ought to provide a functional one rather than a broken one.
Kaige Li [Mon, 3 Aug 2020 16:55:04 +0000 (17:55 +0100)]
target/arm: Avoid maybe-uninitialized warning with gcc 4.9
GCC version 4.9.4 isn't clever enough to figure out that all
execution paths in disas_ldst() that use 'fn' will have initialized
it first, and so it warns:
/home/LiKaige/qemu/target/arm/translate-a64.c: In function ‘disas_ldst’:
/home/LiKaige/qemu/target/arm/translate-a64.c:3392:5: error: ‘fn’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
fn(cpu_reg(s, rt), clean_addr, tcg_rs, get_mem_index(s),
^
/home/LiKaige/qemu/target/arm/translate-a64.c:3318:22: note: ‘fn’ was declared here
AtomicThreeOpFn *fn;
^
Make it happy by initializing the variable to NULL.
The definition of top_bit used in this function is one higher
than that used in the Arm ARM psuedo-code, which put the error
indication at top_bit - 1 at the wrong place, which meant that
it wasn't visible to Auth.
Fixing the definition of top_bit requires more changes, because
its most common use is for the count of bits in top_bit:bot_bit,
which would then need to be computed as top_bit - bot_bit + 1.
For now, prefer the minimal fix to the error indication alone.
Peter Maydell [Mon, 3 Aug 2020 16:55:03 +0000 (17:55 +0100)]
msf2-soc, stellaris: Don't wire up SYSRESETREQ
The MSF2 SoC model and the Stellaris board code both wire
SYSRESETREQ up to a function that just invokes
qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
This is now the default action that the NVIC does if the line is
not connected, so we can delete the handling code.
Peter Maydell [Mon, 3 Aug 2020 16:55:03 +0000 (17:55 +0100)]
hw/intc/armv7m_nvic: Provide default "reset the system" behaviour for SYSRESETREQ
The NVIC provides an outbound qemu_irq "SYSRESETREQ" which it signals
when the guest sets the SYSRESETREQ bit in the AIRCR register. This
matches the hardware design (where the CPU has a signal of this name
and it is up to the SoC to connect that up to an actual reset
mechanism), but in QEMU it mostly results in duplicated code in SoC
objects and bugs where SoC model implementors forget to wire up the
SYSRESETREQ line.
Provide a default behaviour for the case where SYSRESETREQ is not
actually connected to anything: use qemu_system_reset_request() to
perform a system reset. This will allow us to remove the
implementations of SYSRESETREQ handling from the boards where that's
exactly what it does, and also fixes the bugs in the board models
which forgot to wire up the signal:
We still allow the board to wire up the signal if it needs to, in case
we need to model more complicated reset controller logic or to model
buggy SoC hardware which forgot to wire up the line itself. But
defaulting to "reset the system" is more often going to be correct
than defaulting to "do nothing".
Peter Maydell [Mon, 3 Aug 2020 16:55:03 +0000 (17:55 +0100)]
include/hw/irq.h: New function qemu_irq_is_connected()
Mostly devices don't need to care whether one of their output
qemu_irq lines is connected, because functions like qemu_set_irq()
silently do nothing if there is nothing on the other end. However
sometimes a device might want to implement default behaviour for the
case where the machine hasn't wired the line up to anywhere.
Provide a function qemu_irq_is_connected() that devices can use for
this purpose. (The test is trivial but encapsulating it in a
function makes it easier to see where we're doing it in case we need
to change the implementation later.)
Peter Maydell [Mon, 3 Aug 2020 16:55:03 +0000 (17:55 +0100)]
hw/arm/netduino2, netduinoplus2: Set system_clock_scale
The netduino2 and netduinoplus2 boards forgot to set the system_clock_scale
global, which meant that if guest code used the systick timer in "use
the processor clock" mode it would hang because time never advances.
Set the global to match the documented CPU clock speed of these boards.
Judging by the data sheet this is slightly simplistic because the
SoC allows configuration of the SYSCLK source and frequency via the
RCC (reset and clock control) module, but we don't model that.
Max Reitz [Thu, 30 Jul 2020 12:02:33 +0000 (14:02 +0200)]
qcow2: Release read-only bitmaps when inactivated
During migration, we release all bitmaps after storing them on disk, as
long as they are (1) stored on disk, (2) not read-only, and (3)
consistent.
(2) seems arbitrary, though. The reason we do not release them is
because we do not write them, as there is no need to; and then we just
forget about all bitmaps that we have not written to the file. However,
read-only persistent bitmaps are still in the file and in sync with
their in-memory representation, so we may as well release them just like
any R/W bitmap that we have updated.
It leads to actual problems, too: After migration, letting the source
continue may result in an error if there were any bitmaps on read-only
nodes (such as backing images), because those have not been released by
bdrv_inactive_all(), but bdrv_invalidate_cache_all() attempts to reload
them (which fails, because they are still present in memory).
projects / qemu.git / log