* remotes/huth-gitlab/tags/pull-request-2021-01-11v2:
fuzz: map all BARs and enable PCI devices
tests/acceptance: Fix race conditions in s390x tests & skip fedora on gitlab-CI
bsd-user: Update strace.list for FreeBSD's latest syscalls
bsd-user: move strace OS/arch dependent code to host/arch dirs
bsd-user: regenerate FreeBSD's system call numbers
fuzz: heuristic split write based on past IOs
fuzz: add minimization options
fuzz: set bits in operand of write/out to zero
fuzz: remove IO commands iteratively
fuzz: split write operand using binary approach
fuzz: double the IOs to remove for every loop
fuzz: accelerate non-crash detection
util/oslib-win32: Fix _aligned_malloc() arguments order
qtest/libqtest: fix heap-buffer-overflow in qtest_cb_for_every_machine()
gitlab-ci.yml: Add openSUSE Leap 15.2 for gitlab CI/CD
Prior to this patch, the fuzzer found inputs to map PCI device BARs and
enable the device. While it is nice that the fuzzer can do this, it
added significant overhead, since the fuzzer needs to map all the
BARs (regenerating the memory topology), at the start of each input.
With this patch, we do this once, before fuzzing, mitigating some of
this overhead.
Thomas Huth [Fri, 8 Jan 2021 18:56:45 +0000 (19:56 +0100)]
tests/acceptance: Fix race conditions in s390x tests & skip fedora on gitlab-CI
There was a race condition in the first test where there was already the
"crw" output in the dmesg, but the "0.0.4711" entry has not been created
in the /sys fs yet. Fix it by waiting until it is there.
The second test has even more problems on gitlab-CI. Even after adding some
more synchronization points (that wait for some messages in the "dmesg"
output to make sure that the modules got loaded correctly), there are still
occasionally some hangs in this test when it is running in the gitlab-CI.
So far I was unable to reproduce these hangs locally on my computer, so
this issue might take a while to debug. Thus disable the 2nd test in the
gitlab-CI until the problems are better understood and fixed.
Stacey Son [Fri, 18 Dec 2020 20:54:50 +0000 (13:54 -0700)]
bsd-user: move strace OS/arch dependent code to host/arch dirs
This change moves host OS and arch dependent code for the sysarch
system call related to the -strace functionality into the
appropriate host OS and target arch directories.
Warner Losh [Fri, 18 Dec 2020 20:54:48 +0000 (13:54 -0700)]
bsd-user: regenerate FreeBSD's system call numbers
Recreate the FreeBSD system call numbers from current sys/syscall.h. Since this
isn't guaranteed to be on all systems, continue the practice of generating it
with some variation on:
sed -e s/SYS_/TARGET_NR_/ < $FREEBSD_SRC/sys/syscall.h > syscall_nr.h
until a more comprehensive system can be put in place.
Qiuhao Li [Mon, 11 Jan 2021 06:11:50 +0000 (14:11 +0800)]
fuzz: set bits in operand of write/out to zero
Simplifying the crash cases by opportunistically setting bits in operands of
out/write to zero may help to debug, since usually bit one means turn on or
trigger a function while zero is the default turn-off setting.
Qiuhao Li [Mon, 11 Jan 2021 06:11:49 +0000 (14:11 +0800)]
fuzz: remove IO commands iteratively
Now we use a one-time scan and remove strategy in the minimizer,
which is not suitable for timing dependent instructions.
For example, instruction A will indicate an address where the config
chunk locates, and instruction B will make the configuration active.
If we have the following instruction sequence:
...
A1
B1
A2
B2
...
A2 and B2 are the actual instructions that trigger the bug.
If we scan from top to bottom, after we remove A1, the behavior of B1
might be unknowable, including not to crash the program. But we will
successfully remove B1 later cause A2 and B2 will crash the process
anyway:
...
A1
A2
B2
...
Now one more trimming will remove A1.
In the perfect case, we would need to be able to remove A and B (or C!) at
the same time. But for now, let's just add a loop around the minimizer.
Since we only remove instructions, this iterative algorithm is converging.
Qiuhao Li [Mon, 11 Jan 2021 06:11:48 +0000 (14:11 +0800)]
fuzz: split write operand using binary approach
Currently, we split the write commands' data from the middle. If it does not
work, try to move the pivot left by one byte and retry until there is no
space.
But, this method has two flaws:
1. It may fail to trim all unnecessary bytes on the right side.
For example, there is an IO write command:
write addr uuxxxxuu
u is the unnecessary byte for the crash. Unlike ram write commands, in most
case, a split IO write won't trigger the same crash, So if we split from the
middle, we will get:
write addr uu (will be removed in next round)
write addr xxxxuu
For xxxxuu, since split it from the middle and retry to the leftmost byte
won't get the same crash, we will be stopped from removing the last two
bytes.
2. The algorithm complexity is O(n) since we move the pivot byte by byte.
To solve the first issue, we can try a symmetrical position on the right if
we fail on the left. As for the second issue, instead moving by one byte, we
can approach the boundary exponentially, achieving O(log(n)).
Qiuhao Li [Mon, 11 Jan 2021 06:11:47 +0000 (14:11 +0800)]
fuzz: double the IOs to remove for every loop
Instead of removing IO instructions one by one, we can try deleting multiple
instructions at once. According to the locality of reference, we double the
number of instructions to remove for the next round and recover it to one
once we fail.
This patch is usually significant for large input.
Test with quadrupled trace input at:
https://bugs.launchpad.net/qemu/+bug/1890333/comments/1
Patched 1/6 version:
real 0m45.904s
user 0m16.874s
sys 0m10.042s
Refined version:
real 0m11.412s
user 0m6.888s
sys 0m3.325s
Signed-off-by: Qiuhao Li <[email protected]> Reviewed-by: Alexander Bulekov <[email protected]> Tested-by: Alexander Bulekov <[email protected]>
Message-Id: <SYCPR01MB350280A67BB55C3FADF173E3FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com> Signed-off-by: Thomas Huth <[email protected]>
Qiuhao Li [Mon, 11 Jan 2021 06:11:46 +0000 (14:11 +0800)]
fuzz: accelerate non-crash detection
We spend much time waiting for the timeout program during the minimization
process until it passes a time limit. This patch hacks the CLOSED (indicates
the redirection file closed) notification in QTest's output if it doesn't
crash.
Test with quadrupled trace input at:
https://bugs.launchpad.net/qemu/+bug/1890333/comments/1
Original version:
real 1m37.246s
user 0m13.069s
sys 0m8.399s
Refined version:
real 0m45.904s
user 0m16.874s
sys 0m10.042s
Note:
Sometimes the mutated or the same trace may trigger a different crash
summary (second-to-last line) but indicates the same bug. For example, Bug 1910826 [1], which will trigger a stack overflow, may output summaries
like:
SUMMARY: AddressSanitizer: stack-overflow
/home/qiuhao/hack/qemu/build/../softmmu/physmem.c:488 in
flatview_do_translate
or
SUMMARY: AddressSanitizer: stack-overflow
(/home/qiuhao/hack/qemu/build/qemu-system-i386+0x27ca049) in __asan_memcpy
Etc.
If we use the whole summary line as the token, we may be prevented from
further minimization. So in this patch, we only use the first three words
which indicate the type of crash:
Gan Qixin [Wed, 6 Jan 2021 05:06:25 +0000 (13:06 +0800)]
qtest/libqtest: fix heap-buffer-overflow in qtest_cb_for_every_machine()
When the length of mname is less than 5, memcpy("xenfv", mname, 5) will cause
heap buffer overflow. Therefore, use strncmp to avoid this problem.
The asan showed stack:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000f2f4 at
pc 0x7f65d8cc2225 bp 0x7ffe93cc5a60 sp 0x7ffe93cc5208 READ of size 5 at
0x60200000f2f4 thread T0
#0 0x7f65d8cc2224 in memcmp (/lib64/libasan.so.5+0xdf224)
#1 0x5632c20be95b in qtest_cb_for_every_machine tests/qtest/libqtest.c:1282
#2 0x5632c20b7995 in main tests/qtest/test-hmp.c:160
#3 0x7f65d88fed42 in __libc_start_main (/lib64/libc.so.6+0x26d42)
#4 0x5632c20b72cd in _start (build/tests/qtest/test-hmp+0x542cd)
Peter Maydell [Fri, 8 Jan 2021 15:37:04 +0000 (15:37 +0000)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20210108' into staging
target-arm queue:
* intc/arm_gic: Fix gic_irq_signaling_enabled() for vCPUs
* target/arm: Fix MTE0_ACTIVE
* target/arm: Implement v8.1M and Cortex-M55 model
* hw/arm/highbank: Drop dead KVM support code
* util/qemu-timer: Make timer_free() imply timer_del()
* various devices: Use ptimer_free() in finalize function
* docs/system: arm: Add sabrelite board description
* sabrelite: Minor fixes to allow booting U-Boot
* remotes/pmaydell/tags/pull-target-arm-20210108: (23 commits)
docs/system: arm: Add sabrelite board description
hw/arm: sabrelite: Connect the Ethernet PHY at address 6
hw/msic: imx6_ccm: Correct register value for silicon type
hw/misc: imx6_ccm: Update PMU_MISC0 reset value
exynos4210_mct: Use ptimer_free() in the finalize function to avoid memleaks
musicpal: Use ptimer_free() in the finalize function to avoid memleaks
mss-timer: Use ptimer_free() in the finalize function to avoid memleaks
exynos4210_pwm: Use ptimer_free() in the finalize function to avoid memleaks
exynos4210_rtc: Use ptimer_free() in the finalize function to avoid memleaks
allwinner-a10-pit: Use ptimer_free() in the finalize function to avoid memleaks
digic-timer: Use ptimer_free() in the finalize function to avoid memleaks
target/arm: Remove timer_del()/timer_deinit() before timer_free()
Remove superfluous timer_del() calls
scripts/coccinelle: New script to remove unnecessary timer_del() calls
util/qemu-timer: Make timer_free() imply timer_del()
hw/arm/highbank: Drop dead KVM support code
target/arm: Implement Cortex-M55 model
target/arm: Implement FPCXT_NS fp system register
target/arm: Correct store of FPSCR value via FPCXT_S
hw/intc/armv7m_nvic: Correct handling of CCR.BFHFNMIGN
...
Bin Meng [Wed, 6 Jan 2021 06:35:03 +0000 (14:35 +0800)]
hw/arm: sabrelite: Connect the Ethernet PHY at address 6
At present, when booting U-Boot on QEMU sabrelite, we see:
Net: Board Net Initialization Failed
No ethernet found.
U-Boot scans PHY at address 4/5/6/7 (see board_eth_init() in the
U-Boot source: board/boundary/nitrogen6x/nitrogen6x.c). On the real
board, the Ethernet PHY is at address 6. Adjust this by updating the
"fec-phy-num" property of the fsl_imx6 SoC object.
With this change, U-Boot sees the PHY but complains MAC address:
Net: using phy at 6
FEC [PRIME]
Error: FEC address not set.
This is due to U-Boot tries to read the MAC address from the fuse,
which QEMU does not have any valid content filled in. However this
does not prevent the Ethernet from working in QEMU. We just need to
set up the MAC address later in the U-Boot command shell, by:
Bin Meng [Wed, 6 Jan 2021 06:35:02 +0000 (14:35 +0800)]
hw/msic: imx6_ccm: Correct register value for silicon type
Currently when U-Boot boots, it prints "??" for i.MX processor:
CPU: Freescale i.MX?? rev1.0 at 792 MHz
The register that was used to determine the silicon type is
undocumented in the latest IMX6DQRM (Rev. 6, 05/2020), but we
can refer to get_cpu_rev() in arch/arm/mach-imx/mx6/soc.c in
the U-Boot source codes that USB_ANALOG_DIGPROG is used.
Bin Meng [Wed, 6 Jan 2021 06:35:01 +0000 (14:35 +0800)]
hw/misc: imx6_ccm: Update PMU_MISC0 reset value
U-Boot expects PMU_MISC0 register bit 7 is set (see init_bandgap()
in arch/arm/mach-imx/mx6/soc.c) during boot. This bit indicates the
bandgap has stabilized.
With this change, the latest upstream U-Boot (v2021.01-rc3) for imx6
sabrelite board (mx6qsabrelite_defconfig), with a slight change made
by switching CONFIG_OF_SEPARATE to CONFIG_OF_EMBED, boots to U-Boot
shell on QEMU with the following command:
CPU: Freescale i.MX?? rev1.0 at 792 MHz
Reset cause: POR
Model: Freescale i.MX6 Quad SABRE Lite Board
Board: SABRE Lite
I2C: ready
DRAM: 1 GiB
force_idle_bus: sda=0 scl=0 sda.gp=0x5c scl.gp=0x55
force_idle_bus: failed to clear bus, sda=0 scl=0
force_idle_bus: sda=0 scl=0 sda.gp=0x6d scl.gp=0x6c
force_idle_bus: failed to clear bus, sda=0 scl=0
force_idle_bus: sda=0 scl=0 sda.gp=0xcb scl.gp=0x5
force_idle_bus: failed to clear bus, sda=0 scl=0
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - No block device, using default environment
In: serial
Out: serial
Err: serial
Net: Board Net Initialization Failed
No ethernet found.
starting USB...
Bus usb@2184000: usb dr_mode not found
USB EHCI 1.00
Bus usb@2184200: USB EHCI 1.00
scanning bus usb@2184000 for devices... 1 USB Device(s) found
scanning bus usb@2184200 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Hit any key to stop autoboot: 0
=>
Gan Qixin [Thu, 17 Dec 2020 11:31:50 +0000 (19:31 +0800)]
exynos4210_mct: Use ptimer_free() in the finalize function to avoid memleaks
When running device-introspect-test, a memory leak occurred in the
exynos4210_mct_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 96 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf56b01a0 in exynos4210_mct_init /qemu/hw/timer/exynos4210_mct.c:1505
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164
#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381
#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306
Gan Qixin [Thu, 17 Dec 2020 11:31:54 +0000 (19:31 +0800)]
musicpal: Use ptimer_free() in the finalize function to avoid memleaks
When running device-introspect-test, a memory leak occurred in the
mv88w8618_pit_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 192 byte(s) in 4 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf5bb2290 in mv88w8618_timer_init /qemu/hw/arm/musicpal.c:862
#7 0xaaabf5bb2290 in mv88w8618_pit_init /qemu/hw/arm/musicpal.c:954
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf5a95540 in qdev_device_help /qemu/softmmu/qdev-monitor.c:283
#12 0xaaabf5a96940 in qmp_device_add /qemu/softmmu/qdev-monitor.c:801
Gan Qixin [Thu, 17 Dec 2020 11:31:53 +0000 (19:31 +0800)]
mss-timer: Use ptimer_free() in the finalize function to avoid memleaks
When running device-introspect-test, a memory leak occurred in the
mss_timer_init function, so use ptimer_free() in the finalize function to avoid
it.
ASAN shows memory leak stack:
Indirect leak of 192 byte(s) in 2 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf58a0010 in mss_timer_init /qemu/hw/timer/mss-timer.c:235
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564
#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547
#7 0xaaabf5b8316c in m2sxxx_soc_initfn /qemu/hw/arm/msf2-soc.c:70
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
Gan Qixin [Thu, 17 Dec 2020 11:31:51 +0000 (19:31 +0800)]
exynos4210_pwm: Use ptimer_free() in the finalize function to avoid memleaks
When running device-introspect-test, a memory leak occurred in the
exynos4210_pwm_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 240 byte(s) in 5 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf56a36cc in exynos4210_pwm_init /qemu/hw/timer/exynos4210_pwm.c:401
#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#8 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#9 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#10 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#11 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#12 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
Gan Qixin [Thu, 17 Dec 2020 11:31:52 +0000 (19:31 +0800)]
exynos4210_rtc: Use ptimer_free() in the finalize function to avoid memleaks
When running device-introspect-test, a memory leak occurred in the
exynos4210_rtc_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 96 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf57b3934 in exynos4210_rtc_init /qemu/hw/rtc/exynos4210_rtc.c:567
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164
#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381
#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306
Gan Qixin [Thu, 17 Dec 2020 11:31:48 +0000 (19:31 +0800)]
allwinner-a10-pit: Use ptimer_free() in the finalize function to avoid memleaks
When running device-introspect-test, a memory leak occurred in the a10_pit_init
function, so use ptimer_free() in the finalize function to avoid it.
ASAN shows memory leak stack:
Indirect leak of 288 byte(s) in 6 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf57415e8 in a10_pit_init /qemu/hw/timer/allwinner-a10-pit.c:278
#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#8 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564
#9 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547
#10 0xaaabf5b94680 in aw_a10_init /qemu/hw/arm/allwinner-a10.c:49
#11 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#12 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
Gan Qixin [Thu, 17 Dec 2020 11:31:49 +0000 (19:31 +0800)]
digic-timer: Use ptimer_free() in the finalize function to avoid memleaks
When running device-introspect-test, a memory leak occurred in the
digic_timer_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 288 byte(s) in 3 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf5b04084 in digic_timer_init /qemu/hw/timer/digic-timer.c:142
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564
#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547
#7 0xaaabf5b40e84 in digic_init /qemu/hw/arm/digic.c:46
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
Peter Maydell [Tue, 15 Dec 2020 15:41:07 +0000 (15:41 +0000)]
target/arm: Remove timer_del()/timer_deinit() before timer_free()
The Arm CPU finalize function uses a sequence of timer_del(), timer_deinit(),
timer_free() to free the timer. The timer_deinit() step in this was always
unnecessary, and now the timer_del() is implied by timer_free(), so we can
collapse this down to simply calling timer_free().
Peter Maydell [Tue, 15 Dec 2020 15:41:04 +0000 (15:41 +0000)]
util/qemu-timer: Make timer_free() imply timer_del()
Currently timer_free() is a simple wrapper for g_free(). This means
that the timer being freed must not be currently active, as otherwise
QEMU might crash later when the active list is processed and still
has a pointer to freed memory on it. As a result almost all calls to
timer_free() are preceded by a timer_del() call, as can be seen in
the output of
git grep -B1 '\<timer_free\>'
This is unfortunate API design as it makes it easy to accidentally
misuse (by forgetting the timer_del()), and the correct use is
annoyingly verbose.
Peter Maydell [Tue, 15 Dec 2020 14:42:15 +0000 (14:42 +0000)]
hw/arm/highbank: Drop dead KVM support code
Support for running KVM on 32-bit Arm hosts was removed in commit 82bf7ae84ce739e. You can still run a 32-bit guest on a 64-bit Arm
host CPU, but because Arm KVM requires the host and guest CPU types
to match, it is not possible to run a guest that requires a Cortex-A9
or Cortex-A15 CPU there. That means that the code in the
highbank/midway board models to support KVM is no longer used, and we
can delete it.
Peter Maydell [Thu, 10 Dec 2020 20:14:33 +0000 (20:14 +0000)]
target/arm: Implement Cortex-M55 model
Now that we have implemented all the features needed by the v8.1M
architecture, we can add the model of the Cortex-M55. This is the
configuration without MVE support; we'll add MVE later.
Peter Maydell [Thu, 10 Dec 2020 20:14:32 +0000 (20:14 +0000)]
target/arm: Implement FPCXT_NS fp system register
Implement the v8.1M FPCXT_NS floating-point system register. This is
a little more complicated than FPCXT_S, because it has specific
handling for "current FP state is inactive", and it only wants to do
PreserveFPState(), not the full set of actions done by
ExecuteFPCheck() which vfp_access_check() implements.
Peter Maydell [Thu, 10 Dec 2020 20:14:31 +0000 (20:14 +0000)]
target/arm: Correct store of FPSCR value via FPCXT_S
In commit 64f863baeedc8659 we implemented the v8.1M FPCXT_S register,
but we got the write behaviour wrong. On read, this register reads
bits [27:0] of FPSCR plus the CONTROL.SFPA bit. On write, it doesn't
just write back those bits -- it writes a value to the whole FPSCR,
whose upper 4 bits are zeroes.
We also incorrectly implemented the write-to-FPSCR as a simple store
to vfp.xregs; this skips the "update the softfloat flags" part of
the vfp_set_fpscr helper so the value would read back correctly but
not actually take effect.
Fix both of these things by doing a complete write to the FPSCR
using the helper function.
Peter Maydell [Thu, 10 Dec 2020 20:14:30 +0000 (20:14 +0000)]
hw/intc/armv7m_nvic: Correct handling of CCR.BFHFNMIGN
The CCR is a register most of whose bits are banked between security
states but where BFHFNMIGN is not, and we keep it in the non-secure
entry of the v7m.ccr[] array. The logic which tries to handle this
bit fails to implement the "RAZ/WI from Nonsecure if AIRCR.BFHFNMINS
is zero" requirement; correct the omission.
In 50244cc76abc we updated mte_check_fail to match the ARM
pseudocode, using the correct EL to select the TCF field.
But we failed to update MTE0_ACTIVE the same way, which led
to g_assert_not_reached().
Andrew Jones [Tue, 15 Dec 2020 17:48:15 +0000 (18:48 +0100)]
hw/arm/virt: Remove virt machine state 'smp_cpus'
virt machine's 'smp_cpus' and machine->smp.cpus must always have the
same value. And, anywhere we have virt machine state we have machine
state. So let's remove the redundancy. Also, to make it easier to see
that machine->smp is the true source for "smp_cpus" and "max_cpus",
avoid passing them in function parameters, preferring instead to get
them from the state.
Peter Maydell [Thu, 7 Jan 2021 20:34:05 +0000 (20:34 +0000)]
Merge remote-tracking branch 'remotes/rth-gitlab/tags/pull-tcg-20210107' into staging
Build fix for ppc64 centos7.
Reduce the use of scratch registers for tcg/i386.
Use _aligned_malloc for Win32.
Enable split w^x code gen buffers.
# gpg: Signature made Thu 07 Jan 2021 20:06:38 GMT
# gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg: issuer "[email protected]"
# gpg: Good signature from "Richard Henderson <[email protected]>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F
* remotes/rth-gitlab/tags/pull-tcg-20210107: (47 commits)
tcg: Constify TCGLabelQemuLdst.raddr
tcg: Constify tcg_code_gen_epilogue
tcg: Remove TCG_TARGET_SUPPORT_MIRROR
tcg/arm: Support split-wx code generation
tcg/mips: Support split-wx code generation
tcg/mips: Do not assert on relocation overflow
accel/tcg: Add mips support to alloc_code_gen_buffer_splitwx_memfd
tcg/riscv: Support split-wx code generation
tcg/riscv: Remove branch-over-branch fallback
tcg/riscv: Fix branch range checks
tcg/s390: Support split-wx code generation
tcg/s390: Use tcg_tbrel_diff
tcg/sparc: Support split-wx code generation
tcg/sparc: Use tcg_tbrel_diff
tcg/ppc: Support split-wx code generation
tcg/ppc: Use tcg_out_mem_long to reset TCG_REG_TB
tcg/ppc: Use tcg_tbrel_diff
tcg: Introduce tcg_tbrel_diff
tcg/tci: Push const down through bytecode reading
disas: Push const down through host disassembly
...
Since 7ecd02a06f8, we are prepared to re-start code generation
with a smaller TB if a relocation is out of range. We no longer
need to leave a nop in the stream Just In Case.
The offset even checks were folded into the range check incorrectly.
By offsetting by 1, and not decrementing the width, we silently
allowed out of range branches.
Assert that the offset is always even instead. Move tcg_out_goto
down into the CONFIG_SOFTMMU block so that it is not unused.
We cannot use a real temp file, because we would need to find
a filesystem that does not have noexec enabled. However, a
memfd is not associated with any filesystem.
Report better error messages than just "could not allocate".
Let alloc_code_gen_buffer set ctx->code_gen_buffer_size
and ctx->code_gen_buffer, and simply return bool.
Simplify the arguments to always use s->code_ptr instead of
take it as an argument. That makes it easy to ensure that
the value_ptr is always the rx version.
Change TCGLabel.u.value_ptr to const, and initialize it with
tcg_splitwx_to_rx. Propagate const through tcg/host/ only
as far as needed to avoid errors from the value_ptr change.
For darwin, the CTR_EL0 register is not accessible, but there
are system routines that we can use.
For other hosts, copy the single pointer implementation from
libgcc and modify it to support the double pointer interface
we require. This halves the number of cache operations required
when split-rwx is enabled.
util: Enhance flush_icache_range with separate data pointer
We are shortly going to have a split rw/rx jit buffer. Depending
on the host, we need to flush the dcache at the rw data pointer and
flush the icache at the rx code pointer.
For now, the two passed pointers are identical, so there is no
effective change in behaviour.
Enable this on i386 to restrict the set of input registers
for an 8-bit store, as required by the architecture. This
removes the last use of scratch registers for user-only mode.
Peter Maydell [Wed, 6 Jan 2021 22:18:36 +0000 (22:18 +0000)]
Merge remote-tracking branch 'remotes/stsquad/tags/pull-testing-060121-4' into staging
Testing updates (back to green)
- include ccache in Debian 10 docker image
- iotests: drop 312 from auto group
- bound reading of s390x framebuffer file
- cirrus: drop non-x86 tests so we complete
# gpg: Signature made Wed 06 Jan 2021 17:31:14 GMT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <[email protected]>" [full]
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* remotes/stsquad/tags/pull-testing-060121-4:
cirrus: don't run full qtest on macOS
tests/acceptance: bound the size of readline in s390_ccw_virtio
tests/iotests: drop test 312 from auto group
tests/docker: Include 'ccache' in Debian base image
The Cirrus CI macOS build hosts have exhibited a serious performance
degradation in recent months. For example the "qom-test" qtest takes
over an hour for only the qemu-system-aarch64 binary. This is as much
20-40 times slower than other environments. The other qtests all show
similar performance degradation, as do many of the unit tests.
This does not appear related to QEMU code changes, since older git
commits which were known to fully complete in less than 1 hour on
Cirrus CI now also show similar bad performance. Either Cirrus CI
performance has degraded, or an change in its environment has exposed
a latent bug widely affecting all of QEMU. Debugging the qom-test
showed no easily identified large bottleneck - every step of the
test execution was simply slower.
macOS builds/tests run outside Cirrus CI show normal performance.
With an inability to identify any obvious problem, the only viable
way to get a reliably completing Cirrus CI macOS job is to cut out
almost all of the qtests. We choose to run the x86_64 target only,
since that has very few machine types and thus is least badly
impacted in the qom-test execution.
With this change, the macOS jobs complete in approx 35 minutes.
Alex Bennée [Tue, 5 Jan 2021 10:04:02 +0000 (10:04 +0000)]
tests/iotests: drop test 312 from auto group
The "auto" documentation states:
That means they should run with every QEMU binary (also non-x86)
which is not the case as the check-system-fedora build which only
includes a rag tag group of rare and deprecated targets doesn't
support the virtio device required.
Peter Maydell [Wed, 6 Jan 2021 15:55:29 +0000 (15:55 +0000)]
Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into staging
From Alex's pull request:
* improve cross-build KVM coverage
* new --without-default-features configure flag
* add __repr__ for ConsoleSocket for debugging
* build tcg tests with -Werror
* test 32 bit builds with fedora
* remove last traces of debian9
* hotfix for centos8 powertools repo
* Move lots of feature detection code to meson (Alex, myself)
* CFI and LTO support (Daniele)
* test-char dangling pointer (Eduardo)
* Build system and win32 fixes (Marc-André)
* Initialization fixes (myself)
* TCG include cleanup (Richard, myself)
* x86 'int N' fix (Peter)
* remotes/bonzini-gitlab/tags/for-upstream: (52 commits)
win32: drop fd registration to the main-loop on setting non-block
configure: move tests/qemu-iotests/common.env generation to meson
meson.build: convert --with-default-devices to meson
libattr: convert to meson
cap_ng: convert to meson
virtfs: convert to meson
seccomp: convert to meson
zstd: convert to meson
lzfse: convert to meson
snappy: convert to meson
lzo: convert to meson
rbd: convert to meson
libnfs: convert to meson
libiscsi: convert to meson
bzip2: convert to meson
glusterfs: convert to meson
curl: convert to meson
curl: remove compatibility code, require 7.29.0
brlapi: convert to meson
configure: remove CONFIG_FILEVERSION and CONFIG_PRODUCTVERSION
...
Signed-off-by: Peter Maydell <[email protected]>
# Conflicts:
# trace/meson.build
Peter Maydell [Wed, 6 Jan 2021 13:31:11 +0000 (13:31 +0000)]
Merge remote-tracking branch 'remotes/mcayland/tags/qemu-sparc-20210106' into staging
qemu-sparc queue
# gpg: Signature made Wed 06 Jan 2021 11:43:02 GMT
# gpg: using RSA key CC621AB98E82200D915CC9C45BC2C56FAE0F321F
# gpg: issuer "[email protected]"
# gpg: Good signature from "Mark Cave-Ayland <[email protected]>" [full]
# Primary key fingerprint: CC62 1AB9 8E82 200D 915C C9C4 5BC2 C56F AE0F 321F
* remotes/mcayland/tags/qemu-sparc-20210106:
sun4m: don't connect two qemu_irqs directly to the same input
include/hw/sparc/grlib.h: Remove unused set_pil_in_fn typedef
hw/sparc: Make grlib-irqmp device handle its own inbound IRQ lines
hw/timer/slavio_timer: Allow 64-bit accesses
Mark Cave-Ayland [Sat, 19 Dec 2020 11:19:34 +0000 (11:19 +0000)]
sun4m: don't connect two qemu_irqs directly to the same input
The sun4m board code connects both of the IRQ outputs of each ESCC to the
same slavio input qemu_irq. Connecting two qemu_irqs outputs directly to the
same input is not valid as it produces subtly wrong behaviour (for instance
if both the IRQ lines are high, and then one goes low, the PIC input will see
this as a high-to-low transition even though the second IRQ line should still
be holding it high).
This kind of wiring needs an explicitly created OR gate; add one.
Peter Maydell [Sat, 12 Dec 2020 14:41:33 +0000 (14:41 +0000)]
hw/sparc: Make grlib-irqmp device handle its own inbound IRQ lines
Currently the GRLIB_IRQMP device is used in one place (the leon3 board),
but instead of the device providing inbound gpio lines for the board
to wire up, the board code itself calls qemu_allocate_irqs() with
the handler function being a set_irq function defined in the code
for the device.
Refactor this into the standard setup of a device having input
gpio lines.
This fixes a trivial Coverity memory leak report (the leon3
board code leaks the IRQ array returned from qemu_allocate_irqs()).
The address map indicated the allowed accesses at each address.
[...] W indicates a word access, and D indicates a double-word
access.
The SLAVIO timer controller is implemented expecting 32-bit accesses.
Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
the device allows 64-bit accesses.
This was not an issue until commit 5d971f9e67 which reverted
("memory: accept mismatching sizes in memory_region_access_valid").
Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
access range (W -> 4, D -> 8).
Since commit 21786c7e598 ("memory: Log invalid memory accesses")
this class of bug can be quickly debugged displaying 'guest_errors'
accesses, as:
Peter Maydell [Wed, 6 Jan 2021 11:24:11 +0000 (11:24 +0000)]
Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.0-20210106' into staging
ppc patch queue 2021-01-06
First pull request for 2021, which has a bunch of things accumulated
over the holidays. Includes:
* A number of cleanups to sam460ex and ppc440 code from BALATON Zoltan
* Several fixes for builds with --without-default-devices from Greg Kurz
* Fixes for some DRC reset problems from Greg Kurz
* QOM conversion of the PPC 4xx UIC devices from Peter Maydell
* Some other assorted fixes and cleanups
* remotes/dg-gitlab/tags/ppc-for-6.0-20210106: (22 commits)
ppc440_pcix: Fix up pci config access
ppc440_pcix: Fix register write trace event
ppc440_pcix: Improve comment for IRQ mapping
sam460ex: Remove FDT_PPC dependency from KConfig
ppc4xx: Move common dependency on serial to common option
pnv: Fix reverse dependency on PCI express root ports
ppc: Simplify reverse dependencies of POWERNV and PSERIES on XICS and XIVE
ppc: Fix build with --without-default-devices
spapr: Add drc_ prefix to the DRC realize and unrealize functions
spapr: Use spapr_drc_reset_all() at machine reset
spapr: Introduce spapr_drc_reset_all()
spapr: Fix reset of transient DR connectors
spapr: Call spapr_drc_reset() for all DRCs at CAS
spapr: Fix buffer overflow in spapr_numa_associativity_init()
spapr: Allow memory unplug to always succeed
spapr: Fix DR properties of the root node
spapr/xive: Make spapr_xive_pic_print_info() static
spapr: DRC lookup cannot fail
hw/ppc/ppc440_bamboo: Drop use of ppcuic_init()
hw/ppc/virtex_ml507: Drop use of ppcuic_init()
...
projects / qemu.git / log