When specifying lbr_fmt=VALUE in cpu options with an invalid VALUE, error_setg() gets triggered twice, causing an assertion failure in error_setv() which requires *errp to be NULL, preventing meaningful error messages from being displayed.
Fix this by checking visit_type_uint64()'s return value and returning early on failure, consistent with other property setters like set_string().
Fixes: 18c22d7112 (qdev-properties: Add a new macro with bitmask check for uint64_t property)
Cc: qemu-stable@nongnu.org
Signed-off-by: Zesen Liu <ftyghome@gmail.com>
Message-ID: <20251217-qdev-fix-v1-1-bd33ea463220@gmail.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Add Fixes: and Cc:]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Block layer patches
- Fix crash due to BDS use after free during shutdown (in particular
while migration is running)
- iotests: Fix a typo that made a check to prevent overwriting a file
ineffective
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmlAQOARHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9YNCBAAqoWuOIdybhv44cLtrl3DZWHZnt1XbYvT
# xSUWI9fQQM6WLI1gAHXzl4awsTz0yZzc7KSyYPXdoub3A5D2LoFl4kJKXDzubAwr
# YP1Zmg6UWfaKfxkM42FV07xV8K4kvD11jMTimuYql6uFpzXZILwIPjl10ifdjwYg
# /5c9HUct+y28CdmvFYyt5B0lxJq2VSgLPjqyF7yltzKglirqBcvc1YbMoXfiN4JY
# tSvUHIiiJft839QbG1jrt5spl2xhORP6N7woqlgSiTeGKpPavp9nkWFPZO01QmkU
# la6/vgFZZPCgZOlmt0lVMWy5UsWqKb0voOzi3QvDpGYNie+85JmI4OEOXtsKQvDw
# 7EV+JaMtE72sjO35ruFo1KlapuFbM3yyJ97OpwpRuua1oCRXSyLYQMr5RvDO4rqf
# sdSJw/h+VZ524ydza3d/kj8qlzXkOhEo2WidBQCRRMpI8va4+IcMwHB8ZuthU3LZ
# MfOoEo4XayCQRUhFslHb6Y870Wsi3TxZCZ/fxpWqrCsxz5U5mNyUWoQHVdsofT6j
# WrzeA5ibt1GOC42dif0178PhdowFQHySz1wDbxUEO4yKIo3ziQbH95aUmcT3hYuI
# 17pSQegCA2EOCEzUXdD09qXSotJz7a+aKjiQ3hDxK7a1JokC9O4hvAwSbgOPsxCd
# BbKwOhhsSM4=
# =zBtX
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 16 Dec 2025 04:09:52 AM AEDT
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* tag 'for-upstream' of https://repo.or.cz/qemu/kevin:
block: Fix BDS use after free during shutdown
tests/qemu-iotests: Fix check for existing file in _require_disk_usage()
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
During shutdown, blockdev_close_all_bdrv_states() drops any block node
references that are still owned by the monitor (i.e. the user). However,
in doing so, it forgot to also remove the node from monitor_bdrv_states
(which qmp_blockdev_del() correctly does), which means that later calls
of bdrv_first()/bdrv_next() will still return the (now stale) pointer to
the node.
Usually there is no such call after this point, but in some cases it can
happen. In the reported case, there was an ongoing migration, and the
migration thread wasn't shut down yet: migration_shutdown() called by
qemu_cleanup() doesn't actually wait for the migration to be shut down,
but may just move it to MIGRATION_STATUS_CANCELLING. The next time
migration_iteration_finish() runs, it sees the status and tries to
re-activate all block devices that migration may have previously
inactivated. This is where bdrv_first()/bdrv_next() get called and the
access to the already freed node happens.
It is debatable if migration_shutdown() should really return before
migration has settled, but leaving a dangling pointer in the list of
monitor-owned block nodes is clearly a bug either way and fixing it
solves the immediate problem, so fix it.
Cc: qemu-stable@nongnu.org
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20251215150714.130214-1-kwolf@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This reverts commit 0f142cbd91.
Said commit changed the replay_bh_schedule_oneshot_event() in
nvme_rw_cb() to aio_co_wake(), allowing the request coroutine to be
entered directly (instead of only being scheduled for later execution).
This can cause the device to become stalled like so:
It is possible that after completion the request coroutine goes on to
submit another request without yielding, e.g. a flush after a write to
emulate FUA. This will likely cause a nested nvme_process_completion()
call because nvme_rw_cb() itself is called from there.
(After submitting a request, we invoke nvme_process_completion() through
defer_call(); but the fact that nvme_process_completion() ran in the
first place indicates that we are not in a call-deferring section, so
defer_call() will call nvme_process_completion() immediately.)
If this inner nvme_process_completion() loop then processes any
completions, it will write the final completion queue (CQ) head index to
the CQ head doorbell, and subsequently execution will return to the
outer nvme_process_completion() loop. Even if this loop now finds no
further completions, it still processed at least one completion before,
or it would not have called the nvme_rw_cb() which led to nesting.
Therefore, it will now write the exact same CQ head index value to the
doorbell, which effectively is an unrecoverable error[1].
Therefore, nesting of nvme_process_completion() does not work at this
point. Reverting said commit removes the nesting (by scheduling the
request coroutine instead of entering it immediately), and so fixes the
stall.
On the downside, reverting said commit breaks multiqueue for nvme, but
better to have single-queue working than neither. For 11.0, we will
have a solution that makes both work.
A side note: There is a comment in nvme_process_completion() above
qemu_bh_schedule() that claims nesting works, as long as it is done
through the completion_bh. I am quite sure that is not true, for two
reasons:
- The problem described above, which is even worse when going through
nvme_process_completion_bh() because that function unconditionally
writes to the CQ head doorbell,
- nvme_process_completion_bh() never takes q->lock, so
nvme_process_completion() unlocking it will likely abort.
Given the lack of reports of such aborts, I believe that completion_bh
simply is unused in practice.
[1] See the NVMe Base Specification revision 2.3, page 180, figure 152:
“Invalid Doorbell Write Value: A host attempted to write an invalid
doorbell value. Some possible causes of this error are: [...] the
value written is the same as the previously written doorbell value.”
To even be notified of this error, we would need to send an
Asynchronous Event Request to the admin queue (p. 178ff), which we
don’t do, and then to handle it, we would need to delete and
recreate the queue (p. 88, section 3.3.1.2 Queue Usage).
Cc: qemu-stable@nongnu.org
Reported-by: Lukáš Doktor <ldoktor@redhat.com>
Tested-by: Lukáš Doktor <ldoktor@redhat.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-id: 20251215141540.88915-1-hreitz@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Misc HW / migration / typo fixes
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmk4gN0ACgkQ4+MsLN6t
# wN6wPw/9EiBPEumIFhsGQZdB4pZZBgjBgOilkazeVaitWwfjhZGWTB6l5O0+aEmH
# jCeK2AAUZEashB/CrGI9irQ8Zli/CGgzV8/pF25AHDnDFyhCwR2czxeVDiZtMmcE
# tOYfjqs57/85r0OiQHHzqgp7w25p/p0Toz5g9GR+7Wu8xFi5SkHVM2gblSViz9ks
# JY+RLnQN4KKessqFKwGJb/m6cnBUWTf3DCscD/j+Crb9OI3WQpz2DsbQaZ06NHR7
# hlPzQ05taMhIqh6OdRAGqGS7Mud+eQ58k9qkYGuSBUkuBoJ/3/EqHJXQ4blZt9IN
# reJ6EtN+xYTT+BGBhIXmAtIVERzyk1MF99hgUZJW0RDuE4Ioa7Omp5bnv82Yensz
# UledFAMrGpX25SlJG2oNGnqZTYnCYoQnRQTB90AlaluJqHSpSgBBoJyfukjKQDVa
# NmL+sJOthonvGsydJP8IYfmcBUC1AzmXFxzN+/xZOSJe1qmSh1kUaehsbyytdd/C
# tgyav8DsvxXR8rfYBX5bSml8pAKL5pSD0DYJD3LCyvRoC0SnYROFU1kaUfMpPA+/
# H1r0RO5Lzkcub1JW253gA89GfrK0Y7ShMtoJ+GBivH/cK+ZYT4uEAZajcgUi5kJJ
# FSWz/sNxOJ03s3CWQhlPOEnkLQ41/1+eqbLpmWceRIAfOmmXE00=
# =vcUd
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 09 Dec 2025 02:04:45 PM CST
# 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 'hw-misc-20251209' of https://github.com/philmd/qemu:
Revert "hw/net/virtio-net: make VirtIONet.vlans an array instead of a pointer"
Revert "migration/vmstate: remove VMSTATE_BUFFER_POINTER_UNSAFE macro"
Fix const qualifier build errors with recent glibc
scripts/nsis.py: Tell makensis that WoA is 64 bit
hw/pci: Fix typo in documentation
migration: Fix order of function arguments
vhost: Always initialize cached vring data
scripts: fix broken error path in modinfo-collect.py
hw/9pfs: Correct typo
osdep: Undefine FSCALE definition to fix Solaris builds
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Next commit will re-use VMSTATE_BUFFER_POINTER_UNSAFE().
This reverts commit 58341158d0.
Suggested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'.
This breaks the build in various files with errors such as :
error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
208 | char *pidstr = strstr(filename, "%");
| ^~~~~~
Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251209174328.698774-1-clg@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
This fixes a compiler error when higher warning levels are enabled:
../migration/postcopy-ram.c: In function ‘postcopy_temp_pages_setup’:
../migration/postcopy-ram.c:1483:50: error: ‘g_malloc0_n’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
1483 | mis->postcopy_tmp_pages = g_malloc0_n(sizeof(PostcopyTmpPage), channels);
| ^~~~~~~~~~~~~~~
../migration/postcopy-ram.c:1483:50: note: earlier argument should specify number of elements, later size of each element
Avoid also a related int/unsigned mismatch by fixing the type of
two local variables.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251209125049.764095-1-sw@weilnetz.de>
[PMD: Replace g_malloc0_n() by g_new0()]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Peter Xu <peterx@redhat.com>
Message-Id: <20251209195010.83219-1-philmd@linaro.org>
vhost_virtqueue_start() can exit early if the descriptor ring address is
0, assuming the virtqueue isn’t ready to start.
In this case, all cached vring information (size, physical address,
pointer) is left as-is. This is OK at first startup, when that info is
still initialized to 0, but after a reset, it will retain old (outdated)
information.
vhost_virtqueue_start() must make sure these values are (re-)set
properly before exiting.
(When using an IOMMU, these outdated values can stall the device:
vhost_dev_start() deliberately produces an IOMMU miss event for each
used vring. If used_phys contains an outdated value, the resulting
lookup may fail, forcing the device to be stopped.)
Cc: qemu-stable@nongnu.org
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251208113008.153249-1-hreitz@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
sys.stderr.print is dropped long ago and should not be used. Official
replacement is sys.stderr.write
The problem has been found debugging building on some fancy platform
derived from Debian.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: John Snow <jsnow@redhat.com>
CC: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251203220138.159656-1-den@openvz.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Solaris defines FSCALE in <sys/param.h>:
301 /*
302 * Scale factor for scaled integers used to count
303 * %cpu time and load averages.
304 */
305 #define FSHIFT 8 /* bits to right of fixed binary point */
306 #define FSCALE (1<<FSHIFT)
When emulating the SVE FSCALE instruction, we defines the same name
in decodetree format in target/arm/tcg/sve.decode:
1129:FSCALE 01100101 .. 00 1001 100 ... ..... ..... @rdn_pg_rm
This leads to a definition clash:
In file included from ../target/arm/tcg/translate-sve.c:21:
../target/arm/tcg/translate.h:875:17: error: pasting "trans_" and "(" does not give a valid preprocessing token
875 | static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \
| ^~~~~~
../target/arm/tcg/translate-sve.c:4205:5: note: in expansion of macro 'TRANS_FEAT'
4205 | TRANS_FEAT(NAME, FEAT, gen_gvec_fpst_arg_zpzz, name##_zpzz_fns[a->esz], a)
| ^~~~~~~~~~
../target/arm/tcg/translate-sve.c:4249:1: note: in expansion of macro 'DO_ZPZZ_FP'
4249 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
| ^~~~~~~~~~
../target/arm/tcg/translate-sve.c:4249:12: error: expected declaration specifiers or '...' before numeric constant
4249 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
| ^~~~~~
../target/arm/tcg/translate.h:875:25: note: in definition of macro 'TRANS_FEAT'
875 | static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \
| ^~~~
../target/arm/tcg/translate-sve.c:4249:1: note: in expansion of macro 'DO_ZPZZ_FP'
4249 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
| ^~~~~~~~~~
../target/arm/tcg/translate.h:875:47: error: pasting "arg_" and "(" does not give a valid preprocessing token
875 | static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \
| ^~~~
../target/arm/tcg/translate-sve.c:4205:5: note: in expansion of macro 'TRANS_FEAT'
4205 | TRANS_FEAT(NAME, FEAT, gen_gvec_fpst_arg_zpzz, name##_zpzz_fns[a->esz], a)
| ^~~~~~~~~~
../target/arm/tcg/translate-sve.c:4249:1: note: in expansion of macro 'DO_ZPZZ_FP'
4249 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
| ^~~~~~~~~~
In file included from ../target/arm/tcg/translate-sve.c💯
libqemu-aarch64-softmmu.a.p/decode-sve.c.inc:1227:13: warning: 'trans_FSCALE' used but never defined
1227 | static bool trans_FSCALE(DisasContext *ctx, arg_FSCALE *a);
| ^~~~~~~~~~~~
../target/arm/tcg/translate-sve.c:4249:30: warning: 'sve_fscalbn_zpzz_fns' defined but not used [-Wunused-const-variable=]
4249 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)
| ^~~~~~~~~~~
../target/arm/tcg/translate-sve.c:4201:42: note: in definition of macro 'DO_ZPZZ_FP'
4201 | static gen_helper_gvec_4_ptr * const name##_zpzz_fns[4] = { \
| ^~~~
As a kludge, undefine it globally in <qemu/osdep.h>.
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20251203120315.62889-1-philmd@linaro.org>
a few Arm HVF and TCG bug fixes:
- don't re-use TCG only PSCI code in HVF
- fix deadlock in HVF when shutting down (#3228)
- fix corruption of register state from PSCI (#3228)
- properly prioritise PC alignment faults (#3233)
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmk4TeQACgkQ+9DbCVqe
# KkSJJAf/QEn6KTwZ9vBr3wbsXEptvZgjImjDo0ywg+9lxZCqTTfX62HFai9229I/
# ALf3uzO0QwRUzz7peNk4F0tHVCrA1X6jQDezChcFFv2Y+FH+xufK1JbzlroYLdWE
# Jn2bc6pkOCHYvs6X6HIefDUCU9k2LLxH1udpm1DyHEdf19MkI/nb4FIgE2fQ9630
# W/Wv+Bg+s1TeIb9hhJy5jrcbJQ6u/VzIlqrT9PVWe8XLpqJd2Ib+lOZp2mIlQyi4
# /ady0yC1i6hSNZSHDJek6TUMC5Np6HYYyrzGxGuOoVizk9zWPvLoWjx8nxsmG8tB
# jR8BuMJ46hWL9fzL7bJ4PNKHoBF7lg==
# =X9n6
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 09 Dec 2025 10:27:16 AM CST
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.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: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-10.2-more-final-fixes-091225-1' of https://gitlab.com/stsquad/qemu:
target/arm: handle unaligned PC during tlb probe
target/arm: make HV_EXIT_REASON_CANCELED leave hvf_arch_vcpu_exec
target/arm: ensure PSCI register updates are flushed
Revert "target/arm: Re-use arm_is_psci_call() in HVF"
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
PC alignment faults have priority over instruction aborts and we have
code to deal with this in the translation front-ends. However during
tb_lookup we can see a potentially faulting probe which doesn't get a
MemOp set. If the page isn't available this results in
EC_INSNABORT (0x20) instead of EC_PCALIGNMENT (0x22).
As there is no easy way to set the appropriate MemOp in the
instruction fetch probe path lets just detect it in
arm_cpu_tlb_fill_align() ahead of the main alignment check. We also
teach arm_deliver_fault to deliver the right syndrome for
MMU_INST_FETCH alignment issues.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3233
Tested-by: Jessica Clarke <jrtc27@jrtc27.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20251209092459.1058313-5-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Final fixes for 10.2 (gitlab, testing, docker, docs, plugins)
- drop out of date --disable-pie workaround for aarch64 custom job
- remove explicit pxe-test from build with no libslirp
- update the FreeBSD test image
- don't try and run check-tcg tests we haven't built qemu for
- skip iotests which need crypto if we haven't got support
- transition debian-all-test-cross to lcitool
- update build env documentation to refer to lcitool
- update MAINTAINERS entry for custom runners
- ensure discon plugins can read registers
- fix a bug on uftrace symbol helper script
- deprecate the fby35 machine
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmkzAAsACgkQ+9DbCVqe
# KkSCmAf/e5bJGX4GJhNBV9OwBahjDx0U+oCPUCQwH5E7KgUbvBKMd2e+icgjoPnF
# mAA+SVk1wlqi/EPywqMWIcYTNSwg1ZKkqxQwKnzjlinzshk5Q3Rd8CkIUCDE+i6B
# Cn5HXNMxAHwJZXi2ftOUm2wvb5p4NgahbtKUkEAsYvVWgHF+gQ+1KrpbKze2+Mzk
# 707c2zf0/8mcNl7GZDc7ti6MXEmlejR46UTsKz6u12hGTHjN13UDa+yQXqpot5y7
# blUxwneXo7zdxB6EnGgvArzZQh8o0fOo0zWoC5GDKrbdLIrBVxhXYoWCqgaQv7h7
# v5HhMvzq7obIa+qRnjRzUO68MT1rcw==
# =e46t
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 05 Dec 2025 09:53:47 AM CST
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.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: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-10.2-final-fixes-051225-2' of https://gitlab.com/stsquad/qemu:
aspeed: Deprecate the fby35 machine
contrib/plugins/uftrace_symbols.py: unbreak --no-prefix-symbols
plugins/core: allow reading of registers during discon events
MAINTAINERS: update the custom runner entries
docs/devel: Correct typo
docs/devel: update build environment setup documentation
tests/docker: drop --disable-[tools|system] from all-test-cross
tests/docker: transition debian-all-test-cross to lcitool
tests/lcitool: add bzip2 to the minimal dependency list
tests/qemu-iotests: Check for a functional "secret" object before using it
tests/tcg: honour the available QEMU binaries when running check-tcg
gitlab-ci.d/cirrus: Update the FreeBSD job to v14.3
gitlab: drop explicit pxe-test from the build-tci job
gitlab: drop --disable-pie from aarch64-all-linux-static build
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
There are no functional tests for the 'fby35' machine which makes
harder to determine when something becomes deprecated or unused.
The 'fby35' machine was originally added as an example of a multi-SoC
system, with the expectation the models would evolve over time in an
heterogeneous system. This hasn't happened and no public firmware is
available to boot it. It can be replaced by the 'ast2700fc', another
multi-SoC machine based on the newer AST2700 SoCs which are excepted
to receive better support in the future.
Cc: Peter Delevoryas <peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20251126102424.927527-1-clg@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Fix a number of issues:
- update the ubuntu references to 24.0
- add the s390x and ppc64le yml files
- replace Works on Arm with Linaro
- Also mention IBM (s390x) and OSUL (ppc64le) as HW hosts
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20251204194902.1340008-11-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Bring `libvirt-ci` front and centre when discussing dependencies for
QEMU. While we are at it:
- drop links to additional instructions (libvirt is more upto date)
- compress pkg installs into a table
- call out distro/upstream dep difference in a proper note
Message-ID: <20251204194902.1340008-9-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
We use this container to build system images in CI which do not honour
QEMU_CONFIGURE_OPTS. Drop the --disables from the container so
developers don not need to jump through hoops trying to replicate that
on their workstations.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20251204194902.1340008-8-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
While we are at it bump up to debian-13. As we use this container in
the CI runs this also has the benefit of ensuring our qemu-minimal
dependencies project really has just what we need to build a basic
QEMU.
We add a few extra packages so we can build with clang as well as what
we need to probe for the available cross-compilers in the image.
Message-ID: <20251204194902.1340008-7-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Currently configure can identify all the targets that have
cross-compilers available from the supplied target-list. By default
this is the default_target_list which is all possible targets we can
build.
At the same time the target list passed to meson is filtered down
depending on various factors including not building 64 bit targets on
32 bit hosts. As a result make check-tcg will erroneously attempt to
run tests for which we haven't built a QEMU.
Solve this by filtering the final list of TCG_TEST_TARGETS based on
what actually was configured by meson. Rename the variable that
configure spits out to TCG_TESTS_WITH_COMPILERS for clarity and to
avoid larger churn in the Makefile.
Message-ID: <20251204194902.1340008-4-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
The tmp[lh] variables were defined as inputs to the
asm rather than outputs, which meant that the compiler
rightly diagnosed uninitialized inputs.
Reported-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Use the Int128Alias structure more when we need to convert
between Int128 and __int128_t, when Int128 is a struct.
Fixes the build on aarch64 host with TCI, which forces
the use of the struct.
Reported-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Since we build TCI with FFI (commit 22f15579fa "tcg: Build ffi data
structures for helpers") we get on Darwin:
In file included from ../../tcg/tci.c:22:
In file included from include/tcg/helper-info.h:13:
/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/ffi/ffi.h:483:5: warning: 'FFI_GO_CLOSURES' is not defined, evaluates to 0 [-Wundef]
483 | #if FFI_GO_CLOSURES
| ^
1 warning generated.
This was fixed in upstream libffi in 2023, but not backported to MacOSX.
Simply disable the warning locally.
Reported-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
