* Re: [PATCH v2 4/7] commit-reach: add trace2 instrumentation to paint_down_to_common()
From: Derrick Stolee @ 2026-06-24 13:41 UTC (permalink / raw)
To: Kristofer Karlsson via GitGitGadget, git
Cc: Elijah Newren, Kristofer Karlsson
In-Reply-To: <6ade4df2ed2a836a3b4c5400ab13e8247e36c029.1782303254.git.gitgitgadget@gmail.com>
On 6/24/2026 8:14 AM, Kristofer Karlsson via GitGitGadget wrote:
> From: Kristofer Karlsson <krka@spotify.com>
>
> Add a step counter and trace2_data_intmax() call so that the number
> of commits visited during the paint walk is observable via
> GIT_TRACE2_PERF. This provides a way to measure the impact of
> future optimizations without relying on wall-clock benchmarks alone.
> + trace2_data_intmax("paint_down_to_common", r,
> + "steps", steps);
This is great data. Very clearly marked for what we should be
doing here.
> +test_expect_success 'merge-base --all commit-walk steps' '
> + test_when_finished rm -rf .git/objects/info/commit-graph \
> + .git/objects/info/commit-graphs &&
(highlighting this chunk)
> + rm -rf .git/objects/info/commit-graph \
> + .git/objects/info/commit-graphs &&
> +
> + GIT_TRACE2_EVENT="$(pwd)/trace-none.txt" \
> + git merge-base --all commit-9-9 commit-9-1 >actual &&
> + test_trace2_data paint_down_to_common steps 81 <trace-none.txt &&
I'd rather see the whitespace line before the `rm` to make it
more obvious that it's setting up the "none" case.
> +
> + cp commit-graph-full .git/objects/info/commit-graph &&
> + GIT_TRACE2_EVENT="$(pwd)/trace-full.txt" \
> + git merge-base --all commit-9-9 commit-9-1 >actual &&
> + test_trace2_data paint_down_to_common steps 80 <trace-full.txt &&
> +
> + cp commit-graph-half .git/objects/info/commit-graph &&
> + GIT_TRACE2_EVENT="$(pwd)/trace-half.txt" \
> + git merge-base --all commit-9-9 commit-9-1 >actual &&
> + test_trace2_data paint_down_to_common steps 81 <trace-half.txt
> +'
> +
This test is a great example. I look forward to seeing that it
updates in the future.
One thing I was hoping to see was that your side-exhaustion tests
(from patch v2 2/7) would also include these checks so they are
more obviously updating when the implementation updates later.
One way to accomplish that is to reorder this patch before adding
those tests so their first version includes these checks and then
the values update when changing the implementation.
Thanks,
-Stolee
^ permalink raw reply
* Re:Re: After upgrading from Debian 11 to Debian 12, the latency became worse
From: mars_liu @ 2026-06-24 13:40 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
In-Reply-To: <cda3f311-155b-408e-828e-e90c21c857ad@siemens.com>
At 2026-06-22 22:17:28, "Jan Kiszka" <jan.kiszka@siemens.com> wrote:
>Can you try to systematically eliminate variables that may contribute to
>the increase? E.g., use the old kernel with its original configuration
>on the new installation or go back to the original Xenomai version.
>
>If the kernel is the cause, checking once more if the effective config
>of 6.1 is not missing or adding suspicious things compared to the
>effective 5.10 kernel config.
>
>An alternative is obviously turning on tracing and record one of those
>events that are longer than expected. At least basic event traces
>(cobalt events) should not increase latencies on their own a lot while
>giving a general overview what happens.
>
>Jan
>
>--
>Siemens AG, Foundational Technologies
>Linux Expert Center
I was running latency test with event trace on. Initially I enabled cobalt event and irq_pipeline – got result 1. Then I enabled local_timer_entry as well to see what's going on, got result 2. Both times the test cut off when max latency exceeded 70us.
result 1:============================================================================================
...
......
dd-1728 [000] *.~.. 7426.819882: cobalt_tick_shot: next tick at 7426.819975 (delay: 93 us)
dd-1728 [000] *.~.. 7426.819883: irq_pipeline_exit: irq=524547
dd-1728 [000] #.~.. 7426.819883: cobalt_schedule: status=0x10000000
dd-1728 [000] #.~.. 7426.819883: cobalt_trace_pid: pid=1728, prio=-1
dd-1728 [000] #.~.. 7426.819883: cobalt_switch_context: prev_name=ROOT/0 prev_pid=0 prev_prio=-1 prev_state=0x18008 ==> next_name=sampling-1732 next_pid=1736 next_prio=1
dd-1728 [000] #.~.. 7426.819883: cobalt_timer_start: timer=00000000885e65cf([watchdog]) value=1000000000 interval=0 mode=rel
sampling-1732-1736 [000] *.~2. 7426.819884: cobalt_trace_pid: pid=1736, prio=1
sampling-1732-1736 [000] d.~2. 7426.819885: cobalt_head_sysexit: result=8
sampling-1732-1736 [000] d.~2. 7426.819885: cobalt_head_sysentry: syscall=read
sampling-1732-1736 [000] d.~2. 7426.819885: cobalt_fd_read: device=00000000705fa65c fd=3 arg=0x8 pid=1736 comm=sampling-1732
sampling-1732-1736 [000] *.~2. 7426.819886: cobalt_synch_sleepon: synch=00000000a14e53ef
sampling-1732-1736 [000] *.~2. 7426.819886: cobalt_thread_suspend: pid=1736 mask=0x2 timeout=0 timeout_mode=0 wchan=00000000a14e53ef
sampling-1732-1736 [000] *.~2. 7426.819886: cobalt_schedule: status=0x10000000
sampling-1732-1736 [000] *.~2. 7426.819886: cobalt_trace_pid: pid=1736, prio=1
sampling-1732-1736 [000] *.~2. 7426.819886: cobalt_switch_context: prev_name=sampling-1732 prev_pid=1736 prev_prio=1 prev_state=0x4c042 ==> next_name=ROOT/0 next_pid=0 next_prio=-1
sampling-1732-1736 [000] *.~2. 7426.819886: cobalt_timer_stop: timer=00000000885e65cf
dd-1728 [000] #.~.. 7426.819887: cobalt_trace_pid: pid=1728, prio=-1
dd-1728 [000] *.~.. 7426.820043: irq_pipeline_entry: irq=524547
dd-1728 [000] *.~.. 7426.820044: cobalt_timer_expire: timer=00000000a7d2b833
dd-1728 [000] *.~.. 7426.820044: cobalt_synch_wakeup: synch=00000000a14e53ef
dd-1728 [000] *.~.. 7426.820044: cobalt_thread_resume: name=sampling-1732 pid=1736 mask=0x2
dd-1728 [000] *.~.. 7426.820044: cobalt_trace_pid: pid=1736, prio=1
dd-1728 [000] *.~.. 7426.820045: cobalt_tick_shot: next tick at 7426.820075 (delay: 30 us)
dd-1728 [000] *.~.. 7426.820045: irq_pipeline_exit: irq=524547
...
......
result 2:============================================================================================
...
......
dd-1510 [001] *.~.. 1689.009700: cobalt_tick_shot: next tick at 1689.009796 (delay: 95 us)
dd-1510 [001] *.~.. 1689.009701: local_timer_exit: vector=236
dd-1510 [001] *.~.. 1689.009701: irq_pipeline_exit: irq=524547
dd-1510 [001] #.~.. 1689.009702: cobalt_schedule: status=0x10000000
dd-1510 [001] #.~.. 1689.009702: cobalt_trace_pid: pid=1510, prio=-1
dd-1510 [001] #.~.. 1689.009702: cobalt_switch_context: prev_name=ROOT/1 prev_pid=0 prev_prio=-1 prev_state=0x18008 ==> next_name=sampling-1512 next_pid=1516 next_prio=1
dd-1510 [001] #.~.. 1689.009702: cobalt_timer_start: timer=0000000086a46b6d([watchdog]) value=1000000000 interval=0 mode=rel
sampling-1512-1516 [001] *.~2. 1689.009702: cobalt_trace_pid: pid=1516, prio=1
sampling-1512-1516 [001] d.~2. 1689.009703: cobalt_head_sysexit: result=8
sampling-1512-1516 [001] d.~2. 1689.009703: cobalt_head_sysentry: syscall=read
sampling-1512-1516 [001] d.~2. 1689.009703: cobalt_fd_read: device=00000000693aa32d fd=3 arg=0x8 pid=1516 comm=sampling-1512
sampling-1512-1516 [001] *.~2. 1689.009703: cobalt_synch_sleepon: synch=00000000978f36ce
sampling-1512-1516 [001] *.~2. 1689.009703: cobalt_thread_suspend: pid=1516 mask=0x2 timeout=0 timeout_mode=0 wchan=00000000978f36ce
sampling-1512-1516 [001] *.~2. 1689.009704: cobalt_schedule: status=0x10000000
sampling-1512-1516 [001] *.~2. 1689.009704: cobalt_trace_pid: pid=1516, prio=1
sampling-1512-1516 [001] *.~2. 1689.009704: cobalt_switch_context: prev_name=sampling-1512 prev_pid=1516 prev_prio=1 prev_state=0x4c042 ==> next_name=ROOT/1 next_pid=0 next_prio=-1
sampling-1512-1516 [001] *.~2. 1689.009704: cobalt_timer_stop: timer=0000000086a46b6d
dd-1510 [001] #.~.. 1689.009705: cobalt_trace_pid: pid=1510, prio=-1
dd-1510 [001] *.~.. 1689.009800: irq_pipeline_entry: irq=524547
dd-1510 [001] *.~.. 1689.009861: local_timer_entry: vector=236
dd-1510 [001] *.~.. 1689.009862: cobalt_timer_expire: timer=00000000ac269294
dd-1510 [001] *.~.. 1689.009862: cobalt_synch_wakeup: synch=00000000978f36ce
dd-1510 [001] *.~.. 1689.009862: cobalt_thread_resume: name=sampling-1512 pid=1516 mask=0x2
dd-1510 [001] *.~.. 1689.009862: cobalt_trace_pid: pid=1516, prio=1
dd-1510 [001] *.~.. 1689.009862: cobalt_tick_shot: next tick at 1689.009896 (delay: 34 us)
dd-1510 [001] *.~.. 1689.009862: local_timer_exit: vector=236
dd-1510 [001] *.~.. 1689.009863: irq_pipeline_exit: irq=524547
============================================================================================
In result 1, the max latency interval was between the expected next tick and irq_pipeline_entry:
7426820043 – 7426.819975 = 68 µs.
In result 2, the max latency interval was between irq_pipeline_entry and local_timer_entry:
1689.009861 – 1689.009800 = 61 µs.
What caused these two scenarios? Please give me some hints.
^ permalink raw reply
* [Stable-11.0.2 050/107] util/envlist: fix prefix-match in envlist_unsetenv() name lookup
From: Michael Tokarev @ 2026-06-24 13:30 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Denis V. Lunev, Stefan Hajnoczi, Markus Armbruster,
Paolo Bonzini, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: "Denis V. Lunev" <den@openvz.org>
envlist_unsetenv() looked up the entry to remove with
strncmp(entry->ev_var, env, strlen(env)). The comparison length is
the requested name's length, so any stored entry whose name *starts*
with that name compares equal. envlist_setenv() inserts at the head
of the list, so the first hit wins: with FOO=... stored first and
FOOBAR=... stored afterward, envlist_unsetenv("FOO") iterates from
the head, matches FOOBAR=... on the prefix, and drops it instead of
FOO=...
linux-user and bsd-user reach this code via the -U command-line
switch, so the bug is reachable from a normal qemu-user invocation.
envlist_setenv() used the same strncmp pattern but with
envname_len = (eq_sign - env + 1), so the '=' byte sat inside the
compared window and acted as an implicit boundary. setenv was
therefore not buggy -- but the safety lived in the byte layout of
ev_var rather than in the entry, so a future edit could easily
drift the two sites apart again.
Store the name length on each entry at insertion time and compare
with explicit length equality plus memcmp via a small helper. Use
the helper at both lookup sites so the boundary becomes a
structural property of the entry: envlist_unsetenv() stops
prefix-matching, and envlist_setenv()'s self-search no longer
depends on the '=' byte serving as a sentinel.
Fixes: 04a6dfebb6b5 ("linux-user: Add generic env variable handling")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20260520212628.479772-2-den@openvz.org
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit c131ae56c13ffe6bd7089cf0d9bd00a7c2dbc71f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/util/envlist.c b/util/envlist.c
index 15fdbb109d..196c92c190 100644
--- a/util/envlist.c
+++ b/util/envlist.c
@@ -3,7 +3,8 @@
#include "qemu/envlist.h"
struct envlist_entry {
- const char *ev_var; /* actual env value */
+ const char *ev_var; /* actual env value: "NAME=VALUE" */
+ size_t ev_name_len; /* length of NAME (offset of '=') */
QLIST_ENTRY(envlist_entry) ev_link;
};
@@ -12,6 +13,13 @@ struct envlist {
size_t el_count; /* number of entries */
};
+static inline bool envlist_name_eq(const struct envlist_entry *entry,
+ const char *name, size_t name_len)
+{
+ return entry->ev_name_len == name_len &&
+ memcmp(entry->ev_var, name, name_len) == 0;
+}
+
/*
* Allocates new envlist and returns pointer to it.
*/
@@ -67,7 +75,7 @@ envlist_setenv(envlist_t *envlist, const char *env)
/* find out first equals sign in given env */
if ((eq_sign = strchr(env, '=')) == NULL)
return (EINVAL);
- envname_len = eq_sign - env + 1;
+ envname_len = eq_sign - env;
/*
* If there already exists variable with given name
@@ -76,8 +84,9 @@ envlist_setenv(envlist_t *envlist, const char *env)
*/
for (entry = envlist->el_entries.lh_first; entry != NULL;
entry = entry->ev_link.le_next) {
- if (strncmp(entry->ev_var, env, envname_len) == 0)
+ if (envlist_name_eq(entry, env, envname_len)) {
break;
+ }
}
if (entry != NULL) {
@@ -90,6 +99,7 @@ envlist_setenv(envlist_t *envlist, const char *env)
entry = g_malloc(sizeof(*entry));
entry->ev_var = g_strdup(env);
+ entry->ev_name_len = envname_len;
QLIST_INSERT_HEAD(&envlist->el_entries, entry, ev_link);
return (0);
@@ -119,8 +129,9 @@ envlist_unsetenv(envlist_t *envlist, const char *env)
envname_len = strlen(env);
for (entry = envlist->el_entries.lh_first; entry != NULL;
entry = entry->ev_link.le_next) {
- if (strncmp(entry->ev_var, env, envname_len) == 0)
+ if (envlist_name_eq(entry, env, envname_len)) {
break;
+ }
}
if (entry != NULL) {
QLIST_REMOVE(entry, ev_link);
--
2.47.3
^ permalink raw reply related
* [Stable-11.0.2 033/107] target/arm: Enable REVD for SVE2.1
From: Michael Tokarev @ 2026-06-24 13:30 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Richard Henderson, Peter Maydell, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Richard Henderson <richard.henderson@linaro.org>
Cc: qemu-stable@nongnu.org
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260522220408.235438-1-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit f12e7ba6f43803ec73c92b4ebeee6187113ba1fc)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/target/arm/tcg/translate-sve.c b/target/arm/tcg/translate-sve.c
index f9dfda4a7a..a05967f4fb 100644
--- a/target/arm/tcg/translate-sve.c
+++ b/target/arm/tcg/translate-sve.c
@@ -2992,7 +2992,8 @@ TRANS_FEAT(REVH, aa64_sme_or_sve, gen_gvec_ool_arg_zpz, revh_fns[a->esz], a, 0)
TRANS_FEAT(REVW, aa64_sme_or_sve, gen_gvec_ool_arg_zpz,
a->esz == 3 ? gen_helper_sve_revw_d : NULL, a, 0)
-TRANS_FEAT(REVD, aa64_sme, gen_gvec_ool_arg_zpz, gen_helper_sme_revd_q, a, 0)
+TRANS_FEAT(REVD, aa64_sme_or_sve2p1, gen_gvec_ool_arg_zpz,
+ gen_helper_sme_revd_q, a, 0)
TRANS_FEAT(SPLICE, aa64_sme_or_sve, gen_gvec_ool_arg_zpzz,
gen_helper_sve_splice, a, a->esz)
--
2.47.3
^ permalink raw reply related
* [Stable-11.0.2 068/107] qed: Don't try to flush during incoming migration
From: Michael Tokarev @ 2026-06-24 13:31 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Fabiano Rosas, Stefan Hajnoczi, Kevin Wolf,
Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Fabiano Rosas <farosas@suse.de>
It's not possible to access the image file while there is an incoming
migration in progress, the QEMU process doesn't hold any locks to the
storage at this point so nodes are inactive. Attempting to flush leads
to an assert at bdrv_co_write_req_prepare():
assert(!(bs->open_flags & BDRV_O_INACTIVE))
The issue is reproducible by running iotest 181 on a host under cpu
load. The migration must coincide with the header already containing
the QED_F_NEED_CHECK flag.
The sequence of events is as follows, with the respective call stacks
referenced below:
During block device init, bdrv_qed_attach_aio_context() starts the
'need_check' timer. The timer will not fire during incoming migration
as it uses QEMU_CLOCK_VIRTUAL (to avoid this very issue, as the code
comment indicates). (0)
However, there's still bdrv_qed_drain_begin() which uses the fact that
the timer is live to decide whether to start the
qed_need_check_timer_entry() directly. (1)
The qed_need_check_timer_entry() eventually calls into
qed_write_header() -> bdrv_co_pwrite() leading to the assert. (2)
Skip creating the 'need_check' timer whenever the image is inactive.
The stacks:
(0) == issues timer_mod ==
#6 in qed_start_need_check_timer at ../block/qed.c:340
#7 in bdrv_qed_attach_aio_context at ../block/qed.c:373
#8 in bdrv_qed_do_open at ../block/qed.c:556
#9 in bdrv_qed_open_entry at ../block/qed.c:582
#10 in coroutine_trampoline at ../util/coroutine-ucontext.c:175
#0 in qemu_coroutine_switch<+120> at ../util/coroutine-ucontext.c:321
#1 in qemu_aio_coroutine_enter<+356> at ../util/qemu-coroutine.c:293
#2 in aio_co_enter<+179> at ../util/async.c:710
#3 in aio_co_wake<+53> at ../util/async.c:695
#4 in thread_pool_co_cb<+47> at ../util/thread-pool.c:283
#5 in thread_pool_completion_bh<+241> at ../util/thread-pool.c:202
#6 in aio_bh_call<+109> at ../util/async.c:173
#7 in aio_bh_poll<+299> at ../util/async.c:220
#8 in aio_poll<+690> at ../util/aio-posix.c:745
#9 in bdrv_qed_open<+392> at ../block/qed.c:607
#10 in bdrv_open_driver<+327> at ../block.c:1678
#11 in bdrv_open_common<+1619> at ../block.c:2008
#12 in bdrv_open_inherit<+2556> at ../block.c:4191
#13 in bdrv_open<+118> at ../block.c:4286
#14 in blk_new_open<+199> at ../block/block-backend.c:458
#15 in blockdev_init<+2011> at ../blockdev.c:612
#16 in drive_new<+3008> at ../blockdev.c:1008
#17 in drive_init_func<+51> at ../system/vl.c:662
#18 in qemu_opts_foreach<+227> at ../util/qemu-option.c:1148
#19 in configure_blockdev<+350> at ../system/vl.c:721
#20 in qemu_create_early_backends<+343> at ../system/vl.c:2076
#21 in qemu_init<+12483> at ../system/vl.c:3778
#22 in main<+46> at ../system/main.c:71
(1) == sees timer_pending ==
#6 in bdrv_qed_drain_begin at ../block/qed.c:391
#7 in bdrv_do_drained_begin at ../block/io.c:366
#8 in bdrv_do_drained_begin_quiesce at ../block/io.c:386
#9 in bdrv_child_cb_drained_begin at ../block.c:1207
#10 in bdrv_parent_drained_begin_single at ../block/io.c:133
#11 in bdrv_parent_drained_begin at ../block/io.c:64
#12 in bdrv_do_drained_begin at ../block/io.c:364
#13 in bdrv_drained_begin at ../block/io.c:393
#14 in blk_drain at ../block/block-backend.c:2101
#15 in blk_unref at ../block/block-backend.c:544
#16 in bdrv_open_inherit at ../block.c:4197
#17 in bdrv_open at ../block.c:4286
#18 in blk_new_open at ../block/block-backend.c:458
#19 in blockdev_init at ../blockdev.c:612
#20 in drive_new at ../blockdev.c:1008
#21 in drive_init_func at ../system/vl.c:662
#22 in qemu_opts_foreach at ../util/qemu-option.c:1148
#23 in configure_blockdev at ../system/vl.c:721
#24 in qemu_create_early_backends at ../system/vl.c:2076
#25 in qemu_init at ../system/vl.c:3778
#26 in main at ../system/main.c:71
(2) == crashes ==
#5 in __assert_fail (assertion="!(bs->open_flags & BDRV_O_INACTIVE)", file="../block/io.c", line=1977
#6 in bdrv_co_write_req_prepare at ../block/io.c:1977
#7 in bdrv_aligned_pwritev at ../block/io.c:2099
#8 in bdrv_co_pwritev_part at ../block/io.c:2316
#9 in bdrv_co_pwritev at ../block/io.c:2233
#10 in bdrv_co_pwrite at ../include/block/block_int-io.h:77
#11 in qed_write_header at ../block/qed.c:128
#12 in qed_need_check_timer at ../block/qed.c:305
#13 in qed_need_check_timer_entry at ../block/qed.c:319
Note that this issue is not exactly the same as what's been reported
in Gitlab, but given how easily this reproduces, I imagine it has to
be happening in that setup as well.
Link: https://gitlab.com/qemu-project/qemu/-/work_items/3515
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20260603193813.2327596-1-farosas@suse.de>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 7e573b660fefdebd21cb755d0d34bb5942fd3af3)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/block/qed.c b/block/qed.c
index da23a83d62..0eccfa21c9 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -351,16 +351,22 @@ static void bdrv_qed_detach_aio_context(BlockDriverState *bs)
{
BDRVQEDState *s = bs->opaque;
- qed_cancel_need_check_timer(s);
- timer_free(s->need_check_timer);
- s->need_check_timer = NULL;
+ if (s->need_check_timer) {
+ qed_cancel_need_check_timer(s);
+ timer_free(s->need_check_timer);
+ s->need_check_timer = NULL;
+ }
}
-static void bdrv_qed_attach_aio_context(BlockDriverState *bs,
- AioContext *new_context)
+static void GRAPH_RDLOCK bdrv_qed_attach_aio_context(BlockDriverState *bs,
+ AioContext *new_context)
{
BDRVQEDState *s = bs->opaque;
+ if (bdrv_is_inactive(bs)) {
+ return;
+ }
+
s->need_check_timer = aio_timer_new(new_context,
QEMU_CLOCK_VIRTUAL, SCALE_NS,
qed_need_check_timer_cb, s);
--
2.47.3
^ permalink raw reply related
* [Stable-11.0.2 058/107] hw/i3c: fix CMD/data FIFO depth reset values to match real silicon
From: Michael Tokarev @ 2026-06-24 13:31 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Jithu Joseph, Jamin Lin, Cédric Le Goater,
Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Jithu Joseph <jithu.joseph@oss.qualcomm.com>
The Linux DW-I3C master driver infers controller queue depths at probe
by reading two status registers that report free queue slots, which at
probe (queues empty) equals the full depth. It then uses those values
to gate every I3C transfer -- any batch whose word count exceeds the
advertised depth is rejected with -EOPNOTSUPP.
QUEUE_STATUS_LEVEL (0x4c) [7:0] -> cmdfifodepth (cmd slots)
DATA_BUFFER_STATUS_LEVEL (0x50) [7:0] -> datafifodepth (32-bit words)
Per the AST2600 datasheet the reset values are 0x10 and 0x40 (16 cmd
slots, 64 words = 256 B). QEMU was advertising 0x02 and 0x10, making
the kernel believe the controller can only do 64-byte transfers. The
visible symptom was -EOPNOTSUPP on any I3C transfer whose payload
exceeded 64 B (datafifodepth = 0x10 = 16 words = 64 B).
The underlying FIFOs in QEMU were already allocated at the right size
(fifo32_create takes word counts; the existing defaults give 16 cmd
slots and 64 data words). Only the advertised reset values were wrong.
Correct the reset values in dw_i3c_resets[], and additionally drive the
advertised depths from the queue-capacity configs in the reset handlers
(as is already done for the device/char table pointers), so a configured
override is reflected in what the guest reads instead of being silently
ignored. The advertised fields are 8-bit, so the depth saturates at 255
regardless of the wider capacity configs.
With this fix the guest sees datafifodepth=64 words and accepts
transfers up to 256 B.
Fixes: e974c6957576 ("hw/i3c/dw-i3c: Add more reset values")
Cc: qemu-stable@nongnu.org
Signed-off-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com>
Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260604142207.2118098-2-jithu.joseph@oss.qualcomm.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 2d3dc20d9d716729e06093311f678dc739affe5b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/hw/i3c/dw-i3c.c b/hw/i3c/dw-i3c.c
index d87d42be89..402c8f1922 100644
--- a/hw/i3c/dw-i3c.c
+++ b/hw/i3c/dw-i3c.c
@@ -282,8 +282,8 @@ static const uint32_t dw_i3c_resets[DW_I3C_NR_REGS] = {
[R_QUEUE_THLD_CTRL] = 0x01000101,
[R_DATA_BUFFER_THLD_CTRL] = 0x01010100,
[R_SLV_EVENT_CTRL] = 0x0000000b,
- [R_QUEUE_STATUS_LEVEL] = 0x00000002,
- [R_DATA_BUFFER_STATUS_LEVEL] = 0x00000010,
+ [R_QUEUE_STATUS_LEVEL] = 0x00000010,
+ [R_DATA_BUFFER_STATUS_LEVEL] = 0x00000040,
[R_PRESENT_STATE] = 0x00000003,
[R_I3C_VER_ID] = 0x3130302a,
[R_I3C_VER_TYPE] = 0x6c633033,
@@ -947,6 +947,10 @@ static void dw_i3c_reset(DeviceState *dev)
s->cfg.dev_char_table_pointer);
ARRAY_FIELD_DP32(s->regs, DEV_CHAR_TABLE_POINTER, DEV_CHAR_TABLE_DEPTH,
s->cfg.dev_char_table_depth);
+ ARRAY_FIELD_DP32(s->regs, QUEUE_STATUS_LEVEL, CMD_QUEUE_EMPTY_LOC,
+ s->cfg.cmd_resp_queue_capacity_bytes);
+ ARRAY_FIELD_DP32(s->regs, DATA_BUFFER_STATUS_LEVEL, TX_BUF_EMPTY_LOC,
+ s->cfg.tx_rx_queue_capacity_bytes);
dw_i3c_cmd_queue_reset(s);
dw_i3c_resp_queue_reset(s);
@@ -1795,6 +1799,10 @@ static void dw_i3c_reset_enter(Object *obj, ResetType type)
s->cfg.dev_char_table_pointer);
ARRAY_FIELD_DP32(s->regs, DEV_CHAR_TABLE_POINTER, DEV_CHAR_TABLE_DEPTH,
s->cfg.dev_char_table_depth);
+ ARRAY_FIELD_DP32(s->regs, QUEUE_STATUS_LEVEL, CMD_QUEUE_EMPTY_LOC,
+ s->cfg.cmd_resp_queue_capacity_bytes);
+ ARRAY_FIELD_DP32(s->regs, DATA_BUFFER_STATUS_LEVEL, TX_BUF_EMPTY_LOC,
+ s->cfg.tx_rx_queue_capacity_bytes);
}
static void dw_i3c_realize(DeviceState *dev, Error **errp)
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] xfs: fix capabily check in xfs_setattr_nonsize
From: Christoph Hellwig @ 2026-06-24 13:40 UTC (permalink / raw)
To: cem
Cc: linux-xfs, stable, Darrick J. Wong, Dave Chinner, Eric Sandeen,
Christoph Hellwig, Dr. Thomas Orgis, Jan Kara, linux-fsdevel,
Christian Brauner
In-Reply-To: <20260624101436.362533-1-cem@kernel.org>
Adding Jan and Christian for quota and user_ns knowledge.
On Wed, Jun 24, 2026 at 12:14:29PM +0200, cem@kernel.org wrote:
> From: Carlos Maiolino <cem@kernel.org>
>
> An user reported a bug where he managed to evade group's quota
> by changing a file's gid to a different group id the same user
> belonged to, even though quotas were enforced on both gids and the
> file's size was big enough to exceed the quota's hardlimit.
>
> Commit eba0549bc7d1 replaced a capable() call by a
> has_capability_noaudit() to prevent unnecessary selinux audit messages.
> Turns out that both calls have slightly different semantics even though
> their documentation seems similar. Where in a nutshell:
>
> capable() - Tests the task's effective credentials
> has_ns_capability_noaudit() - Tests the task's real credentials
Eww..
> This most of the time has no practical difference but in some cases like
> changing attrs (specifically group id in this case) through a NFS client
> this will allow the quota code to use XFS_QMOPT_FORCE_RES, effectively
> bypassing quota accounting checks.
Yeah, this does look wrong. Do the other conversion in the above commit
have tthe same issue?
> Using instead ns_capable_noaudit() should fix this issue and prevent
> selinux audit messages.
The generic quota code manages to do without either has_capability_noaudit
or ns_capable_noaudit. I think this might be hidden behind
inode_owner_or_capable calls. Any idea why we're different?
> + bool force = ns_capable_noaudit(&init_user_ns,
> + CAP_FOWNER);
I'd do away with the local variable here.
^ permalink raw reply
* Kernsec sales
From: Eric Young @ 2026-06-24 13:40 UTC (permalink / raw)
To: linux-integrity
Hi,
I noticed your focus on the Linux kernel security subsystem and the resources you provide for developers and users.
Managing detailed technical information and supporting user communication can be time consuming without the right tools.
We have helped teams automate client interactions and scheduling in complex technical environments without adding extra resources.
Would you be open to a brief conversation to explore if this could help streamline your community engagement?
Eric
422 Richards St, Suite 170. Vancouver, BC V6B 2Z4
P.S. Please let me know if you don't want to hear from me again
^ permalink raw reply
* [Stable-11.0.2 049/107] 9pfs: fix missing rename lock in v9fs_co_readdir_many (CVE-2026-48004)
From: Michael Tokarev @ 2026-06-24 13:30 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, sin99xx, Christian Schoenebeck, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: sin99xx <sin99xx@proton.me>
v9fs_co_readdir_many() dispatches do_readdir_many() to a worker thread
that reads V9fsFidState's path.data without holding a rename lock.
A concurrent rename request, e.g. of its parent dir, causes the FID's
absolute path to be altered by freeing the old path string and
assigning a new one. This causes a heap-use-after-free race condition
while do_readdir_many() is still accessing the old object.
This allows a DoS by an unprivileged guest user.
Fix this by wrapping the worker thread dispatch block within a pair of
v9fs_path_read_lock() and v9fs_path_unlock() calls, like it's done at
other places.
Fixes: 2149675b195f ("9pfs: add new function v9fs_co_readdir_many()")
Fixes: CVE-2026-48004
Reported-by: sin99xx <sin99xx@proton.me>
Signed-off-by: sin99xx <sin99xx@proton.me>
[Christian Schoenebeck: add commit log message]
Link: https://lore.kernel.org/qemu-devel/E1wPkYi-000adH-4E@kylie.crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
(cherry picked from commit 5a8da7e979f1f56b1cab82c2354833f309f1a78f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/hw/9pfs/codir.c b/hw/9pfs/codir.c
index bce7dd96e9..5568399343 100644
--- a/hw/9pfs/codir.c
+++ b/hw/9pfs/codir.c
@@ -220,13 +220,16 @@ int coroutine_fn v9fs_co_readdir_many(V9fsPDU *pdu, V9fsFidState *fidp,
bool dostat)
{
int err = 0;
+ V9fsState *s = pdu->s;
if (v9fs_request_cancelled(pdu)) {
return -EINTR;
}
+ v9fs_path_read_lock(s);
v9fs_co_run_in_worker({
err = do_readdir_many(pdu, fidp, entries, offset, maxsize, dostat);
});
+ v9fs_path_unlock(s);
return err;
}
--
2.47.3
^ permalink raw reply related
* Re: mm/hwpoison: persist poisoned PFN list across kexec via KHO [RFC]
From: Pratyush Yadav @ 2026-06-24 13:40 UTC (permalink / raw)
To: Breno Leitao
Cc: nao.horiguchi, linmiaohe, david, lance.yang, akpm, baoquan.he,
rppt, pratyush, kexec, linux-mm, rneu, riel, caggio, kas
In-Reply-To: <ajut_LDQGYCShApx@gmail.com>
On Wed, Jun 24 2026, Breno Leitao wrote:
> TL;DR: carry the hardware-poisoned page list across kexec using KHO, so the
> next kernel doesn't hand out known-bad RAM.
>
> The problem
> ===========
>
> When a page is hard-offlined due to an uncorrectable memory error (multi bit
> ECC), memory_failure() sets PG_hwpoison, unmaps it, removes it from the buddy
> allocator and accounts it in num_poisoned_pages / HardwareCorrupted. All of
> that lives in the running kernel's data structures, not in the hardware.
>
> A kexec replaces the kernel image but not the physical DRAM. The next kernel
> rebuilds mem_map[] from the firmware-provided memory map, sees the bad frame as
> ordinary system RAM, and the buddy allocator hands it back out on the next
> kernel. The known-bad cell is silently back in circulation, and the next
> access faults again - potentially in a context that is harder to recover than
> the original (e.g. a kernel allocation rather than a killable user page).
>
> This matters most where kexec is frequent and machines are long-lived: live
> kernel update on large fleets. Poison knowledge accumulates over uptime and is
> thrown away on every update.
I don't know much about hardware page poisoning. From what I understand
of your description, it seems like the hardware fires off an event that
the kernel receives, and then the kernel stores the state, and hardware
"forgets" it. So what happens when something accesses the poisoned
memory anyway? Do we get another hwpoison event?
Also, what happens on cold reboot? If the HW does not remember bad
pages, won't the kernel be in the same position? How does it know the
bad pages on a cold boot?
>
> This is the case at Meta and in many hyperscalers.
>
>
> Possible solutions
> ==================
>
> 1. Do nothing (status quo). The next kernel hands out known-bad
> RAM, and hope for the best.
>
> 2. e820 / EFI memory map (E820_TYPE_UNUSABLE). Tempting because the
> frame would simply never become RAM (no allocator race at all).
> But: it is x86-only (no arm64 equivalent in the same mechanism;
> this series is tested on arm64);
>
> 3. Firmware / platform page retirement (PPR, BMC page-offline, CXL
> device poison lists). This is the correct layer for *cross power
> cycle* persistence and is complementary to this work. But it is
> per-platform, out of OS control, not universally available, and
> cannot carry OS-discovered or software-simulated poison
> (MADV_HWPOISON, the injector). kexec can also happen long before
> firmware retirement takes effect.
I don't know enough about these two to say whether they are a good idea
or not. I'll let more competent people comment on that.
>
> 4. reserve_mem= / memmap= on the command line. Automatically sent reserved_mem=
> for the next kexec kernel cmdline.
Does this scale at all? How many poisoned pages do you expect to see on
a big machine with say a few terabytes of RAM? Won't the commandline end
up being way too big?
>
> 5. A bespoke kexec segment / setup_data blob. This reinvents what
> KHO already provides - preserved memory plus an FDT handoff to
> the next kernel - which is the upstream-blessed generic mechanism
> for exactly this kind of state.
Yeah, at that point you'd be better off using KHO directly. You won't
have to muck about with architecture specific bits.
>
> This PoC
> ========
>
> * Makes hardware-poisoned pages survive a kexec, using KHO (Kexec
> HandOver) to carry the poison list between kernels.
>
> * Producer: hooks num_poisoned_pages_inc()/_sub() - the single
> chokepoint for every poison/unpoison event - and records each
> poisoned PFN into a vmalloc array that KHO preserves across the
> kexec, described by a small versioned "hwpoison" subtree.
More of an implementation detail, but with vmalloc array, what if you
have too many poisoned pages?
We have two alternative data structures in KHO: the radix tree [0] and
KHO block [1]. I think the radix tree will be inefficient unless you
have a _lot_ of poisoned pages, but KHO block is likely going to work a
lot better because you don't have to define the buffer size up front.
>
> * Consumer: early in the next boot (fs_initcall_sync, before the
> buddy allocator has handed anything out) it restores that array
Why do you say so? Buddy is up and running after memblock_free_all(),
which happens from mm_core_init(), and memblock goes away entirely in
page_alloc_init_late(), which runs right after early initcalls but
before any other levels. See kernel_init_freeable().
Concrete example: hugetlb is initialized at subsys_initcall(), and
allocates all its 2M hugepages from buddy.
So I think you probably need to do this somewhere in
page_alloc_init_late(), after all the deferred struct pages are
initialized.
> and re-runs memory_failure() on each PFN, re-offlining the frame
> and rebuilding the full hwpoison state (PG_hwpoison, counters,
> HardwareCorrupted).
>
> * The replay feeds back through the producer, so the list
> re-publishes itself and survives an arbitrary chain of kexecs.
>
>
> Open questions
> ==============
>
> * Is there any alternative I am not seeing?
>
> * Is a dedicated "hwpoison" subtree the right granularity, or
> should this live under a broader RAS/KHO umbrella?
What's "RAS"?
A dedicated subtree sounds the best to me, but I think an alternate
option is to stick it into kexec-metadata. But I don't know what we'd
gain from doing so.
I _don't_ think it belongs in the base KHO ABI.
>
> * Trusting the inherited list: should the next kernel bound the count /
> validate PFNs against its own memory map before replaying?
Normally with KHO you assume the memory map does not change and the
previous kernel is trustworthy. You can try to do basic validation of
the memory map to ensure correctness, but I think in the end you just
_have_ to trust the previous kernel.
>
> Limitations
> ===========
>
> * Poison events before KHO init (fs_initcall) cannot be published;
> academic in practice as MCEs do not fire that early.
>
> * Per-page only. Cross-power-cycle retirement of a whole DIMM
> is not covered.
>
> I've got a PoC working, and it is available in here, in case you are interested
> in the details I am playing with
>
> https://github.com/leitao/linux/tree/b4/hwpoison
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kho_radix_tree.h
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kho_block.h
--
Regards,
Pratyush Yadav
^ permalink raw reply
* [Stable-11.0.2 066/107] block/export/fuse: set FUSE_DIRECT_IO_ALLOW_MMAP flag to fix regression
From: Michael Tokarev @ 2026-06-24 13:31 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Fiona Ebner, Kevin Wolf, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Fiona Ebner <f.ebner@proxmox.com>
Commit 8599559580 ("fuse: Set direct_io and parallel_direct_writes")
broke use cases that require mmap() with MAP_SHARED on the export. In
particular, swtpm_setup using its 'file://' protocol requires this.
From the kernel documentation [0]:
> To allow shared mmap, the FUSE_DIRECT_IO_ALLOW_MMAP flag may be
> enabled in the FUSE_INIT reply.
Set the FUSE_DIRECT_IO_ALLOW_MMAP flag to restore compatibility with
users requiring shared mmap. The FUSE_INIT_EXT flag needs to be set
for the flags2 member to have an effect.
[0]: https://www.kernel.org/doc/html/next/filesystems/fuse/fuse-io.html
Cc: qemu-stable@nongnu.org
Fixes: 8599559580 ("fuse: Set direct_io and parallel_direct_writes")
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20260506145424.10249-3-f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit d1664a4058b2b4285d281d32c81ef646f78e7d9a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/block/export/fuse.c b/block/export/fuse.c
index 35218e3197..c0e8dfb643 100644
--- a/block/export/fuse.c
+++ b/block/export/fuse.c
@@ -856,7 +856,8 @@ static ssize_t coroutine_fn GRAPH_RDLOCK
fuse_co_init(FuseExport *exp, struct fuse_init_out *out,
const struct fuse_init_in *in)
{
- const uint32_t supported_flags = FUSE_ASYNC_READ | FUSE_ASYNC_DIO;
+ uint32_t supported_flags = FUSE_ASYNC_READ | FUSE_ASYNC_DIO;
+ uint32_t flags2 = 0;
if (in->major != 7) {
error_report("FUSE major version mismatch: We have 7, but kernel has %"
@@ -871,13 +872,21 @@ fuse_co_init(FuseExport *exp, struct fuse_init_out *out,
return -EINVAL;
}
+ if (!using_old_fuse_init_in(in)) {
+ /* The flags2 flags must be shifted down by 32 bits. */
+ const uint32_t supported_flags2 = FUSE_DIRECT_IO_ALLOW_MMAP >> 32;
+ /* flags2 is only considered if FUSE_INIT_EXT is set. */
+ supported_flags = supported_flags | FUSE_INIT_EXT;
+ flags2 = in->flags2 & supported_flags2;
+ }
+
*out = (struct fuse_init_out) {
.major = 7,
.minor = MIN(FUSE_KERNEL_MINOR_VERSION, in->minor),
.max_readahead = in->max_readahead,
.max_write = FUSE_MAX_WRITE_BYTES,
.flags = in->flags & supported_flags,
- .flags2 = 0,
+ .flags2 = flags2,
/* libfuse maximum: 2^16 - 1 */
.max_background = UINT16_MAX,
--
2.47.3
^ permalink raw reply related
* [PATCH v2 5/6] docs/system/arm: Add FEAT_FPRCVT to A-profile support
From: Jim MacArthur @ 2026-06-24 13:37 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, qemu-arm, Richard Henderson, Alex Bennee,
Jim MacArthur
In-Reply-To: <20260624-jmac-fprcvt-v2-0-dc6cf8e512b6@linaro.org>
Signed-off-by: Jim MacArthur <jim.macarthur@linaro.org>
---
docs/system/arm/emulation.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index a8072ddb67..98c028f6a6 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -85,6 +85,7 @@ the following architecture extensions:
- FEAT_FPACCOMBINE (Faulting on combined pointer authentication instructions)
- FEAT_FPACC_SPEC (Speculative behavior of combined pointer authentication instructions)
- FEAT_FPMR (Floating-point Mode Register)
+- FEAT_FPRCVT (Floating-Point to/from Integer in Scalar FP register)
- FEAT_FRINTTS (Floating-point to integer instructions)
- FEAT_FlagM (Flag manipulation instructions v2)
- FEAT_FlagM2 (Enhancements to flag manipulation instructions)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/7] PCI/IOV: Return u16 from pci_sriov_get_totalvfs()
From: David Laight @ 2026-06-24 13:39 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Zhi Wang, dakr, airlied, simona, ojeda, alex.gaynor, boqun.feng,
gary, bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, jhubbard,
ecourtney, joelagnelf, apopple, cjia, smitra, kjaju, alkumar,
ankita, aniketa, kwankhede, targupta, nova-gpu, linux-kernel,
zhiwang, Bjorn Helgaas, linux-pci
In-Reply-To: <DJHAC9W05615.19MHKPF67OG2T@nvidia.com>
On Wed, 24 Jun 2026 21:40:52 +0900
"Alexandre Courbot" <acourbot@nvidia.com> wrote:
> On Tue Jun 23, 2026 at 4:43 AM JST, Zhi Wang wrote:
> > pci_sriov_get_totalvfs() reports a VF count, not an errno-style
> > status. It returns 0 when SR-IOV is unavailable or the device is not a
> > PF, and otherwise returns the PF's driver_max_VFs value.
> >
> > driver_max_VFs is stored as a u16 in struct pci_sriov. It is derived
> > from the SR-IOV TotalVFs field or from a driver-provided limit, so the
> > implementation cannot return a negative value.
> >
> > Change the declaration, CONFIG_PCI_IOV stub, and implementation to
> > return u16. Update callers to store the result in u16 variables, remove
> > obsolete negative-value checks, and use unsigned format specifiers where
> > needed.
> >
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: linux-pci@vger.kernel.org
> > Signed-off-by: Zhi Wang <zhiw@nvidia.com>
>
> Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
> Link: https://lore.kernel.org/all/DETDILPA1GFY.27WND0TEC5352@nvidia.com/
>
> > ---
> > drivers/crypto/hisilicon/qm.c | 8 +++++---
> > drivers/crypto/intel/qat/qat_common/adf_sriov.c | 6 +++---
> > drivers/gpu/drm/xe/xe_sriov_pf.c | 6 ++----
> > drivers/misc/genwqe/card_base.c | 6 ++----
> > drivers/net/ethernet/cavium/thunder/nic_main.c | 2 +-
> > drivers/net/ethernet/emulex/benet/be_main.c | 3 ++-
> > drivers/net/ethernet/mellanox/mlx5/core/sriov.c | 3 ++-
> > drivers/net/ethernet/sfc/ef10_sriov.c | 2 +-
>
> I believe that you can avoid converting all these drivers in this patch.
> The implicit `u16 -> int` conversion done by C should result in the
> expected behavior, and it will be fewer Acked-by to collect.
The generated code is also likely to be slightly better if the function
return value is a 32bit value.
Similarly you don't really want to do any kind of maths on local variables
that aren't 32bit (or 64bit on 64bit builds).
The fact that the domain of a value fits in 16 bits doesn't mean that
it is better to use u16 - it is usually worse.
Pretty much the only place u16 should be used is to reduce the size
of structures.
So it is probably correct to change the return type to unsigned int and
remove the error return checks, but nothing else.
David
>
> I.e. just updating drivers/pci/iov.c and include/linux/pci.h should be
> sufficient as the first step. Specific drivers can then be updated using
> separate patches that will be easier to merge individually, if you want
> to do so.
>
^ permalink raw reply
* [Stable-11.0.2 031/107] vfio-user: reject zero migration page size capability
From: Michael Tokarev @ 2026-06-24 13:30 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, GuoHan Zhao, Cédric Le Goater, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: GuoHan Zhao <zhaoguohan@kylinos.cn>
check_migr_pgsize() validates that no page-size bits smaller than
VFIO_USER_DEF_PGSIZE are set, but it still accepts pgsize=0. This can replace
the default migration page size with an unusable value.
Reject a zero migration page size during version capability parsing, matching
the lower-bound check used for the DMA page-size capability.
Fixes: 36227628d824 (vfio-user: implement message send infrastructure)
Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Link: https://lore.kernel.org/qemu-devel/20260522081306.4186242-2-zhaoguohan@kylinos.cn
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 497b5c5b05ac2be00ae16c723e2445ebbc486cb2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/hw/vfio-user/proxy.c b/hw/vfio-user/proxy.c
index 3fe5b0138b..3167d27b03 100644
--- a/hw/vfio-user/proxy.c
+++ b/hw/vfio-user/proxy.c
@@ -1081,9 +1081,11 @@ static bool check_migr_pgsize(VFIOUserProxy *proxy, QObject *qobj, Error **errp)
return false;
}
- /* must be larger than default */
- if (pgsize & (VFIO_USER_DEF_PGSIZE - 1)) {
- error_setg(errp, "pgsize 0x%"PRIx64" too small", pgsize);
+ /* must not be zero or smaller than default */
+ if (pgsize < VFIO_USER_DEF_PGSIZE ||
+ (pgsize & (VFIO_USER_DEF_PGSIZE - 1))) {
+ error_setg(errp, "%s 0x%"PRIx64" too small",
+ VFIO_USER_CAP_PGSIZE, pgsize);
return false;
}
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2] PCI: qcom-ep: Fix runtime PM reference leak in probe error paths
From: sashiko-bot @ 2026-06-24 13:39 UTC (permalink / raw)
To: Wentao Liang; +Cc: linux-pci
In-Reply-To: <20260624132943.40718-1-vulab@iscas.ac.cn>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Double-disable of runtime PM on `devm_pm_runtime_enable()` failure permanently breaks runtime PM.
- [High] Double-put of the runtime PM usage counter due to unhandled fall-through on `pm_runtime_put_sync()` failure.
--
commit c1b17f3fe6107b8e2d84d7608e5bf717e1aa999e
Author: Wentao Liang <vulab@iscas.ac.cn>
PCI: qcom-ep: Fix runtime PM reference leak in probe error paths
This commit updates qcom_pcie_ep_probe() to distinguish between error
paths before and after devm_pm_runtime_enable() succeeds. It adds
manual cleanup for early errors and uses pm_runtime_put_sync() for
later errors to prevent runtime PM reference leaks.
> - On the successful probe path: call pm_runtime_put_sync() to drop
> the initial reference. The return value of pm_runtime_put_sync()
> is ignored because errors like -EAGAIN or -EBUSY only indicate
> that the device cannot be suspended at this moment and do not
> represent a fatal probe failure.
[Severity: High]
The commit message states that the return value of pm_runtime_put_sync()
is ignored, but the code still checks the return value and jumps to the
error path if it fails.
> diff --git a/drivers/pci/controller/dwc/pcie-qcom-ep.c b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> --- a/drivers/pci/controller/dwc/pcie-qcom-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> @@ -892,16 +892,16 @@ static int qcom_pcie_ep_probe(struct platform_device *pdev)
> pm_runtime_set_active(dev);
> ret = devm_pm_runtime_enable(dev);
> if (ret)
> - return ret;
> + goto err_manual_cleanup;
[Severity: High]
If devm_pm_runtime_enable() fails (for example, due to a devres memory
allocation failure), it internally guarantees its cleanup action is executed,
which already calls pm_runtime_disable().
By jumping to err_manual_cleanup and calling pm_runtime_disable() again,
will this incorrectly increment the device's disable_depth to 2? Could this
permanently leave runtime PM disabled for the device on subsequent deferred
probe attempts?
[ ... ]
> @@ -932,6 +932,13 @@ static int qcom_pcie_ep_probe(struct platform_device *pdev)
> err_ep_deinit:
> dw_pcie_ep_deinit(&pcie_ep->pci.ep);
>
> +err_put_ref:
> + pm_runtime_put_sync(dev);
> + return ret;
[Severity: High]
Because the patch leaves the original error check intact on the successful
probe path:
ret = pm_runtime_put_sync(dev);
if (ret < 0) {
dev_err(dev, "Failed to suspend device: %d\n", ret);
goto err_disable_irqs;
}
If the initial put returns a transient error like -EAGAIN, the usage count
has already been decremented by the PM core. However, the code jumps to
err_disable_irqs, unwinds the probe, and falls through to err_put_ref here.
Could this result in calling pm_runtime_put_sync() a second time, causing
a usage counter underflow?
> +err_manual_cleanup:
> + pm_runtime_put_noidle(dev);
> + pm_runtime_disable(dev);
> return ret;
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624132943.40718-1-vulab@iscas.ac.cn?part=1
^ permalink raw reply
* [Stable-11.0.2 035/107] target/arm: SME BFCVT, BFCVTN have "Alternate BFloat16 behaviors"
From: Michael Tokarev @ 2026-06-24 13:30 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Peter Maydell, Richard Henderson, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Peter Maydell <peter.maydell@linaro.org>
The Arm ARM A1.5.10 notes that some instructions have "Alternate
Bfloat16 behaviors" when FPCR.AH == 1. We implement these using the
FPST_AH and FPST_AH_F16 fp_status words. The list includes the SME
BFVCT (single-precision to BFloat16) and BFCVTN, but we forgot to
make those use FPST_AH_F16 when we implemented them. (We get the
ASIMD and SVE insns on the list right.)
Add the missing logic to select the right FPST.
Cc: qemu-stable@nongnu.org
Fixes: 465d36db0e1 ("target/arm: Implement SME2 BFCVT, BFCVTN, FCVT, FCVTN")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260521180854.1744788-1-peter.maydell@linaro.org
(cherry picked from commit ca33de98447c2c2825c1af73cfacf4f65a9bc6c6)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/target/arm/tcg/translate-sme.c b/target/arm/tcg/translate-sme.c
index 7d25ac5a51..6064ed8697 100644
--- a/target/arm/tcg/translate-sme.c
+++ b/target/arm/tcg/translate-sme.c
@@ -1418,9 +1418,9 @@ static bool do_zz_fpst(DisasContext *s, arg_zz_n *a, int data,
}
TRANS_FEAT(BFCVT, aa64_sme2, do_zz_fpst, a, 0,
- FPST_A64, gen_helper_sme2_bfcvt)
+ s->fpcr_ah ? FPST_AH : FPST_A64, gen_helper_sme2_bfcvt)
TRANS_FEAT(BFCVTN, aa64_sme2, do_zz_fpst, a, 0,
- FPST_A64, gen_helper_sme2_bfcvtn)
+ s->fpcr_ah ? FPST_AH : FPST_A64, gen_helper_sme2_bfcvtn)
TRANS_FEAT(FCVT_n, aa64_sme2, do_zz_fpst, a, 0,
FPST_A64, gen_helper_sme2_fcvt_n)
TRANS_FEAT(FCVTN, aa64_sme2, do_zz_fpst, a, 0,
--
2.47.3
^ permalink raw reply related
* [Stable-11.0.2 017/107] ui/vnc: fix OOB read access in VNC SASL mechname array
From: Michael Tokarev @ 2026-06-24 13:30 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Daniel P. Berrangé, boy juju,
Marc-André Lureau, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Daniel P. Berrangé <berrange@redhat.com>
When reading the SASL mechname array off the VNC connection, if
malicious, the received data may contain embedded NULs. If this
happens the memory buffer returned by g_strndup may be shorter
than the original data. Unfortunately the code continued to
index into this buffer with an offset equal to the original
length. This is a potential OOB read of the array.
Fixes: 5847d9e1 (ui/vnc: simplify and avoid strncpy)
Reported-by: boy juju <agx1657748706@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260521103353.1645561-2-berrange@redhat.com>
(cherry picked from commit ae18df638fb4285c7b645f98c43f5ebc2e123a55)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
index 3f4cfc471d..9f15980fca 100644
--- a/ui/vnc-auth-sasl.c
+++ b/ui/vnc-auth-sasl.c
@@ -490,6 +490,8 @@ static int protocol_client_auth_sasl_mechname(VncState *vs, uint8_t *data, size_
char *mechname = g_strndup((const char *) data, len);
trace_vnc_auth_sasl_mech_choose(vs, mechname);
+ /* If 'data' had embedded NUL the dup'd string might now be shorter */
+ len = strlen(mechname);
if (strncmp(vs->sasl.mechlist, mechname, len) == 0) {
if (vs->sasl.mechlist[len] != '\0' &&
vs->sasl.mechlist[len] != ',') {
--
2.47.3
^ permalink raw reply related
* [Stable-11.0.2 055/107] lcitool: remove Cirrus CI support
From: Michael Tokarev @ 2026-06-24 13:31 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Stefan Hajnoczi, Pierrick Bouvier, Warner Losh,
Alex Bennée, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Stefan Hajnoczi <stefanha@redhat.com>
Remove GitLab CI integration for Cirrus CI now that nothing uses it
anymore.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Warner Losh <imp@bsdimp.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20260602162457.828969-3-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 29c042c6e9d4a09d4a0ac3fa54aeb7ee08ce0bdc)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/.gitlab-ci.d/base.yml b/.gitlab-ci.d/base.yml
index 7640a1d52c..72eadc8073 100644
--- a/.gitlab-ci.d/base.yml
+++ b/.gitlab-ci.d/base.yml
@@ -52,10 +52,6 @@ variables:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
when: never
- # Cirrus jobs can't run unless the creds / target repo are set
- - if: '$QEMU_JOB_CIRRUS && ($CIRRUS_GITHUB_REPO == null || $CIRRUS_API_TOKEN == null)'
- when: never
-
# Publishing jobs should only run on the default branch in upstream
- if: '$QEMU_JOB_PUBLISH == "1" && $CI_PROJECT_NAMESPACE == $QEMU_CI_UPSTREAM && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH'
when: never
diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
deleted file mode 100644
index 4769d00c67..0000000000
--- a/.gitlab-ci.d/cirrus.yml
+++ /dev/null
@@ -1,32 +0,0 @@
-# Jobs that we delegate to Cirrus CI because they require an operating
-# system other than Linux. These jobs will only run if the required
-# setup has been performed on the GitLab account.
-#
-# The Cirrus CI configuration is generated by replacing target-specific
-# variables in a generic template: some of these variables are provided
-# when the GitLab CI job is defined, others are taken from a shell
-# snippet generated using lcitool.
-#
-# Note that the $PATH environment variable has to be treated with
-# special care, because we can't just override it at the GitLab CI job
-# definition level or we risk breaking it completely.
-.cirrus_build_job:
- extends: .base_job_template
- stage: build
- image: registry.gitlab.com/libvirt/libvirt-ci/cirrus-run:latest
- needs: []
- allow_failure:
- exit_codes: 3
- # 20 mins larger than "timeout_in" in cirrus/build.yml
- # as there's often a 5-10 minute delay before Cirrus CI
- # actually starts the task
- timeout: 80m
- script:
- - set -o allexport
- - source .gitlab-ci.d/cirrus/$NAME.vars
- - set +o allexport
- - cirrus-vars <.gitlab-ci.d/cirrus/build.yml >.gitlab-ci.d/cirrus/$NAME.yml
- - cat .gitlab-ci.d/cirrus/$NAME.yml
- - cirrus-run -v --show-build-log always .gitlab-ci.d/cirrus/$NAME.yml
- variables:
- QEMU_JOB_CIRRUS: 1
diff --git a/.gitlab-ci.d/cirrus/README.rst b/.gitlab-ci.d/cirrus/README.rst
deleted file mode 100644
index 657b0706d7..0000000000
--- a/.gitlab-ci.d/cirrus/README.rst
+++ /dev/null
@@ -1,54 +0,0 @@
-Cirrus CI integration
-=====================
-
-GitLab CI shared runners only provide a docker environment running on Linux.
-While it is possible to provide private runners for non-Linux platforms this
-is not something most contributors/maintainers will wish to do.
-
-To work around this limitation, we take advantage of `Cirrus CI`_'s free
-offering: more specifically, we use the `cirrus-run`_ script to trigger Cirrus
-CI jobs from GitLab CI jobs so that Cirrus CI job output is integrated into
-the main GitLab CI pipeline dashboard.
-
-There is, however, some one-time setup required. If you want FreeBSD and macOS
-builds to happen when you push to your GitLab repository, you need to
-
-* set up a GitHub repository for the project, eg. ``yourusername/qemu``.
- This repository needs to exist for cirrus-run to work, but it doesn't need to
- be kept up to date, so you can create it and then forget about it;
-
-* enable the `Cirrus CI GitHub app`_ for your GitHub account;
-
-* sign up for Cirrus CI. It's enough to log into the website using your GitHub
- account;
-
-* grab an API token from the `Cirrus CI settings`_ page;
-
-* it may be necessary to push an empty ``.cirrus.yml`` file to your github fork
- for Cirrus CI to properly recognize the project. You can check whether
- Cirrus CI knows about your project by navigating to:
-
- ``https://cirrus-ci.com/yourusername/qemu``
-
-* in the *CI/CD / Variables* section of the settings page for your GitLab
- repository, create two new variables:
-
- * ``CIRRUS_GITHUB_REPO``, containing the name of the GitHub repository
- created earlier, eg. ``yourusername/qemu``;
-
- * ``CIRRUS_API_TOKEN``, containing the Cirrus CI API token generated earlier.
- This variable **must** be marked as *Masked*, because anyone with knowledge
- of it can impersonate you as far as Cirrus CI is concerned.
-
- Neither of these variables should be marked as *Protected*, because in
- general you'll want to be able to trigger Cirrus CI builds from non-protected
- branches.
-
-Once this one-time setup is complete, you can just keep pushing to your GitLab
-repository as usual and you'll automatically get the additional CI coverage.
-
-
-.. _Cirrus CI GitHub app: https://github.com/marketplace/cirrus-ci
-.. _Cirrus CI settings: https://cirrus-ci.com/settings/profile/
-.. _Cirrus CI: https://cirrus-ci.com/
-.. _cirrus-run: https://github.com/sio/cirrus-run/
diff --git a/.gitlab-ci.d/cirrus/build.yml b/.gitlab-ci.d/cirrus/build.yml
deleted file mode 100644
index 41abd0b31a..0000000000
--- a/.gitlab-ci.d/cirrus/build.yml
+++ /dev/null
@@ -1,42 +0,0 @@
-@CIRRUS_VM_INSTANCE_TYPE@:
- @CIRRUS_VM_IMAGE_SELECTOR@: @CIRRUS_VM_IMAGE_NAME@
- cpu: @CIRRUS_VM_CPUS@
- memory: @CIRRUS_VM_RAM@
-
-env:
- CIRRUS_CLONE_DEPTH: 1
- CI_REPOSITORY_URL: "@CI_REPOSITORY_URL@"
- CI_COMMIT_REF_NAME: "@CI_COMMIT_REF_NAME@"
- CI_COMMIT_SHA: "@CI_COMMIT_SHA@"
- PATH: "@PATH_EXTRA@:$PATH"
- PKG_CONFIG_PATH: "@PKG_CONFIG_PATH@"
- PYTHON: "@PYTHON@"
- MAKE: "@MAKE@"
- CONFIGURE_ARGS: "@CONFIGURE_ARGS@"
- TEST_TARGETS: "@TEST_TARGETS@"
-
-build_task:
- # A little shorter than GitLab timeout in ../cirrus.yml
- timeout_in: 60m
- install_script:
- - @UPDATE_COMMAND@
- - @INSTALL_COMMAND@ @PKGS@
- - if test -n "@PYPI_PKGS@" ; then PYLIB=$(@PYTHON@ -c 'import sysconfig; print(sysconfig.get_path("stdlib"))'); rm -f $PYLIB/EXTERNALLY-MANAGED; @PIP3@ install @PYPI_PKGS@ ; fi
- clone_script:
- - git clone --depth 100 "$CI_REPOSITORY_URL" .
- - git fetch origin "$CI_COMMIT_REF_NAME"
- - git reset --hard "$CI_COMMIT_SHA"
- step_script:
- - mkdir build
- - cd build
- - ../configure --enable-werror $CONFIGURE_ARGS
- || { cat config.log meson-logs/meson-log.txt; exit 1; }
- - $MAKE -j$(sysctl -n hw.ncpu)
- - for TARGET in $TEST_TARGETS ;
- do
- $MAKE -j$(sysctl -n hw.ncpu) $TARGET V=1 ;
- done
- always:
- build_result_artifacts:
- path: build/meson-logs/*log.txt
- type: text/plain
diff --git a/.gitlab-ci.d/qemu-project.yml b/.gitlab-ci.d/qemu-project.yml
index 9cbb5fe787..104a147b2d 100644
--- a/.gitlab-ci.d/qemu-project.yml
+++ b/.gitlab-ci.d/qemu-project.yml
@@ -17,6 +17,5 @@ include:
- local: '/.gitlab-ci.d/buildtest.yml'
- local: '/.gitlab-ci.d/static_checks.yml'
- local: '/.gitlab-ci.d/custom-runners.yml'
- - local: '/.gitlab-ci.d/cirrus.yml'
- local: '/.gitlab-ci.d/windows.yml'
- local: '/.gitlab-ci.d/macos.yml'
diff --git a/docs/devel/testing/ci-jobs.rst.inc b/docs/devel/testing/ci-jobs.rst.inc
index f1c70344ec..d5b081978a 100644
--- a/docs/devel/testing/ci-jobs.rst.inc
+++ b/docs/devel/testing/ci-jobs.rst.inc
@@ -91,12 +91,6 @@ Maintainer controlled job variables
The following variables may be set when defining a job in the
CI configuration file.
-QEMU_JOB_CIRRUS
-~~~~~~~~~~~~~~~
-
-The job makes use of Cirrus CI infrastructure, requiring the
-configuration setup for cirrus-run to be present in the repository
-
QEMU_JOB_OPTIONAL
~~~~~~~~~~~~~~~~~
diff --git a/docs/devel/testing/main.rst b/docs/devel/testing/main.rst
index 0662766b5c..e929ab3ec9 100644
--- a/docs/devel/testing/main.rst
+++ b/docs/devel/testing/main.rst
@@ -516,8 +516,8 @@ mappings to distribution package names for a wide variety of third
party projects. ``lcitool`` applies the mappings to a list of build
pre-requisites in ``tests/lcitool/projects/qemu.yml``, determines the
list of native packages to install on each distribution, and uses them
-to generate build environments (dockerfiles and Cirrus CI variable files)
-that are consistent across OS distribution.
+to generate build environments (dockerfiles) that are consistent across OS
+distribution.
Adding new build pre-requisites
diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index ad6a1e6fe8..0ccce6d5be 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -81,12 +81,6 @@ def generate_dockerfile(host, target, project="qemu", cross=None, trailer=None,
generate(filename, cmd, trailer)
-def generate_cirrus(target, trailer=None):
- filename = Path(src_dir, ".gitlab-ci.d", "cirrus", target + ".vars")
- cmd = lcitool_cmd + ["variables", "--format", "shell", target, "qemu"]
- generate(filename, cmd, trailer)
-
-
def generate_vars(target, trailer=None):
filename = Path(src_dir, ".gitlab-ci.d", target + ".vars")
cmd = lcitool_cmd + ["variables", "--format", "shell", target, "qemu"]
--
2.47.3
^ permalink raw reply related
* [Stable-11.0.2 061/107] qemu-io: Add 'aio_discard' command
From: Michael Tokarev @ 2026-06-24 13:31 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Kevin Wolf, Denis V. Lunev, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Kevin Wolf <kwolf@redhat.com>
Testing interactions between multiple requests that include discard
requests require that qemu-io can do the discard asynchronously, like it
already does for reads and writes. To this effect, add an 'aio_discard'
command.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20260427170520.101242-3-kwolf@redhat.com>
Reviewed-by: Denis V. Lunev <den@openvz.org>
Tested-by: Denis V. Lunev <den@openvz.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 7f8466e2ce620e3c6a6e2f32d616367174d4dbe9)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
index f6d077908f..de4c1966fe 100644
--- a/qemu-io-cmds.c
+++ b/qemu-io-cmds.c
@@ -2218,6 +2218,120 @@ static int discard_f(BlockBackend *blk, int argc, char **argv)
return 0;
}
+static void aio_discard_help(void)
+{
+ printf(
+"\n"
+" asynchronously discards a range of bytes from the given offset\n"
+"\n"
+" Example:\n"
+" 'aio_discard 512 1k' - discards 1 kilobyte from 512 bytes into the file\n"
+"\n"
+" Discards a segment of the currently open file.\n"
+" -C, -- report statistics in a machine parsable format\n"
+" -q, -- quiet mode, do not show I/O statistics\n"
+" The discard is performed asynchronously and the aio_flush command must be\n"
+" used to ensure all outstanding aio requests have been completed.\n"
+" Note that due to its asynchronous nature, this command will be\n"
+" considered successful once the request is submitted, independently\n"
+" of potential I/O errors.\n"
+"\n");
+}
+
+static int aio_discard_f(BlockBackend *blk, int argc, char **argv);
+
+static const cmdinfo_t aio_discard_cmd = {
+ .name = "aio_discard",
+ .cfunc = aio_discard_f,
+ .perm = BLK_PERM_WRITE,
+ .argmin = 2,
+ .argmax = -1,
+ .args = "[-Cq] off len",
+ .oneline = "asynchronously discards a number of bytes",
+ .help = aio_discard_help,
+};
+
+static void aio_discard_done(void *opaque, int ret)
+{
+ struct aio_ctx *ctx = opaque;
+ struct timespec t2;
+
+ clock_gettime(CLOCK_MONOTONIC, &t2);
+
+ if (ret < 0) {
+ printf("aio_discard failed: %s\n", strerror(-ret));
+ block_acct_failed(blk_get_stats(ctx->blk), &ctx->acct);
+ goto out;
+ }
+
+ block_acct_done(blk_get_stats(ctx->blk), &ctx->acct);
+
+ if (ctx->qflag) {
+ goto out;
+ }
+
+ /* Finally, report back -- -C gives a parsable format */
+ t2 = tsub(t2, ctx->t1);
+ print_report("discarded ", &t2, ctx->offset, ctx->qiov.size,
+ ctx->qiov.size, 1, ctx->Cflag);
+out:
+ g_free(ctx);
+}
+
+static int aio_discard_f(BlockBackend *blk, int argc, char **argv)
+{
+ int c, ret;
+ int64_t count;
+ struct aio_ctx *ctx = g_new0(struct aio_ctx, 1);
+
+ ctx->blk = blk;
+
+ while ((c = getopt(argc, argv, "Cq")) != -1) {
+ switch (c) {
+ case 'C':
+ ctx->Cflag = true;
+ break;
+ case 'q':
+ ctx->qflag = true;
+ break;
+ default:
+ g_free(ctx);
+ qemuio_command_usage(&aio_discard_cmd);
+ return -EINVAL;
+ }
+ }
+
+ if (optind != argc - 2) {
+ g_free(ctx);
+ qemuio_command_usage(&aio_discard_cmd);
+ return -EINVAL;
+ }
+
+ ctx->offset = cvtnum(argv[optind]);
+ if (ctx->offset < 0) {
+ ret = ctx->offset;
+ print_cvtnum_err(ret, argv[optind]);
+ g_free(ctx);
+ return ret;
+ }
+ optind++;
+
+ count = cvtnum(argv[optind]);
+ if (count < 0) {
+ print_cvtnum_err(count, argv[optind]);
+ g_free(ctx);
+ return count;
+ }
+
+ clock_gettime(CLOCK_MONOTONIC, &ctx->t1);
+ ctx->qiov.size = count;
+ block_acct_start(blk_get_stats(blk), &ctx->acct, ctx->qiov.size,
+ BLOCK_ACCT_UNMAP);
+ blk_aio_pdiscard(blk, ctx->offset, count, aio_discard_done, ctx);
+
+ return 0;
+}
+
static int alloc_f(BlockBackend *blk, int argc, char **argv)
{
BlockDriverState *bs = blk_bs(blk);
@@ -2800,6 +2914,7 @@ static void __attribute((constructor)) init_qemuio_commands(void)
qemuio_add_command(&length_cmd);
qemuio_add_command(&info_cmd);
qemuio_add_command(&discard_cmd);
+ qemuio_add_command(&aio_discard_cmd);
qemuio_add_command(&alloc_cmd);
qemuio_add_command(&map_cmd);
qemuio_add_command(&reopen_cmd);
--
2.47.3
^ permalink raw reply related
* [Stable-11.0.2 029/107] target/arm: Set correct fp flags for FLOGB when FPCR.AH = 1
From: Michael Tokarev @ 2026-06-24 13:30 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Peter Maydell, Alex Bennée, Richard Henderson,
Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Peter Maydell <peter.maydell@linaro.org>
Our implementation of the FLOGB insn does the operations entirely
in the helper function, without needing to use fpu functions.
This means it needs to handle all the fp status flags itself.
We aren't setting float_flag_input_denormal_used when we
use (i.e. do not flush to zero) an input denormal, which means
that FPCR.IDC isn't set when it should be for FPCR.AH=1.
We missed this when we added float_flag_input_denormal_used
and made the fpu/ code set it.
Add the missing float_raise().
Cc: qemu-stable@nongnu.org
Fixes: d38a57a3f ("target/arm: Enable FEAT_AFP for '-cpu max'")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260521122913.1565011-4-peter.maydell@linaro.org
(cherry picked from commit 23ece2805f9a3f90f317aac1b49ee45783b57636)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/target/arm/tcg/sve_helper.c b/target/arm/tcg/sve_helper.c
index 179cbd74fb..d884ba474f 100644
--- a/target/arm/tcg/sve_helper.c
+++ b/target/arm/tcg/sve_helper.c
@@ -5036,6 +5036,7 @@ static int16_t do_float16_logb_as_int(float16 a, float_status *s)
if (frac != 0) {
if (!get_flush_inputs_to_zero(s)) {
/* denormal: bias - fractional_zeros */
+ float_raise(float_flag_input_denormal_used, s);
return -15 - clz32(frac);
}
/* flush to zero */
@@ -5064,6 +5065,7 @@ static int32_t do_float32_logb_as_int(float32 a, float_status *s)
if (frac != 0) {
if (!get_flush_inputs_to_zero(s)) {
/* denormal: bias - fractional_zeros */
+ float_raise(float_flag_input_denormal_used, s);
return -127 - clz32(frac);
}
/* flush to zero */
@@ -5092,6 +5094,7 @@ static int64_t do_float64_logb_as_int(float64 a, float_status *s)
if (frac != 0) {
if (!get_flush_inputs_to_zero(s)) {
/* denormal: bias - fractional_zeros */
+ float_raise(float_flag_input_denormal_used, s);
return -1023 - clz64(frac);
}
/* flush to zero */
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v15 02/11] arm64/ptrace: Refactor syscall_trace_enter/exit() to accept flags parameter
From: Ada Couprie Diaz @ 2026-06-24 13:38 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-3-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Refactor syscall_trace_enter() and syscall_trace_exit() to move thread
> flag reading to the caller. This aligns arm64's syscall trace enter/exit
> function signature with generic entry framework.
>
> [Changes]
> 1. Function signature changes:
> - syscall_trace_enter(regs) → syscall_trace_enter(regs, flags)
> - syscall_trace_exit(regs) → syscall_trace_exit(regs, flags)
>
> 2. Move flags reading to caller:
> - Previously: read_thread_flags() called inside each function.
> - Now: caller (like el0_svc_common) passes flags as parameter.
>
> 3. Update syscall.c:
> - el0_svc_common() now passes flags to tracing functions and
> re-fetches flags before entry/exit to handle potential TIF
> updates.
>
> [Why this matters]
> - Aligns arm64 with the generic entry interface.
> - Makes future migration to generic entry framework.
>
> No functional changes intended.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
I was a bit confused with some parts, but those changes were made to align
exactly on the generic entry code, so makes sense !
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* [Stable-11.0.2 024/107] apic: fix delivery bitmask with modified xAPIC ids
From: Michael Tokarev @ 2026-06-24 13:30 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Paolo Bonzini, Wei Che Kao, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Paolo Bonzini <pbonzini@redhat.com>
Self-IPIs (or all-but-self IPIs) in QEMU can cause a out-of-bounds access
to deliver_bitmask, because the access uses the APIC ID register which
is writable by the guest. However, foreach_apic uses the delivery
bitmask indexes to look up the local_apics[] array, which is indexed
by *initial* APIC id. Using the right id fixes both a possible heap
write overflow if the modified APIC id is too large for max_apic_words,
and a mis-delivery of both self and all-but-self IPIs.
Reported-by: Wei Che Kao <skps96g313.cs10@gmail.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 153dc2fa7bbe0491290d22c4bbb6807074f24260)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/hw/intc/apic.c b/hw/intc/apic.c
index 8766ed00b9..ced7df49bd 100644
--- a/hw/intc/apic.c
+++ b/hw/intc/apic.c
@@ -648,13 +648,6 @@ static void apic_deliver(APICCommonState *s, uint32_t dest, uint8_t dest_mode,
APICCommonState *apic_iter;
uint32_t deliver_bitmask_size = max_apic_words * sizeof(uint32_t);
g_autofree uint32_t *deliver_bitmask = g_new(uint32_t, max_apic_words);
- uint32_t current_apic_id;
-
- if (is_x2apic_mode(s)) {
- current_apic_id = s->initial_apic_id;
- } else {
- current_apic_id = s->id;
- }
switch (dest_shorthand) {
case 0:
@@ -662,14 +655,20 @@ static void apic_deliver(APICCommonState *s, uint32_t dest, uint8_t dest_mode,
break;
case 1:
memset(deliver_bitmask, 0x00, deliver_bitmask_size);
- apic_set_bit(deliver_bitmask, current_apic_id);
+ /*
+ * The self and all-but-self cases do not use apic_match_dest() and
+ * directly fill in deliver_bitmask; the bitmask's indexes in turn
+ * map to local_apics[] slots which are never changed even if the
+ * xAPIC id is modified. So use s->initial_apic_id instead of s->id.
+ */
+ apic_set_bit(deliver_bitmask, s->initial_apic_id);
break;
case 2:
memset(deliver_bitmask, 0xff, deliver_bitmask_size);
break;
case 3:
memset(deliver_bitmask, 0xff, deliver_bitmask_size);
- apic_reset_bit(deliver_bitmask, current_apic_id);
+ apic_reset_bit(deliver_bitmask, s->initial_apic_id);
break;
}
--
2.47.3
^ permalink raw reply related
* [Stable-11.0.2 032/107] vfio/container: Restrict dma_map_file() to shared RAM or RAM devices
From: Michael Tokarev @ 2026-06-24 13:30 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Chenyi Qiang, Farrah Chen, Zhenzhong Duan,
Cédric Le Goater, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Chenyi Qiang <chenyi.qiang@intel.com>
vfio_container_dma_map() uses dma_map_file() whenever a RAMBlock has an
fd and the VFIO IOMMU backend supports file-based DMA mapping. That is
not correct for private file-backed guest RAM.
dma_map_file() resolves PFNs from the backing file, but private guest
RAM mappings (MAP_PRIVATE) can run on different PFNs than the file
because they are subject to copy-on-write (COW) anomalies. As a result,
using dma_map_file() on a privately mapped RAMBlock can program DMA
against pages that do not back QEMU's actual guest memory.
Fix this by using dma_map_file() only for shared mapped RAMBlocks
(MAP_SHARED) or RAM device regions.
Fixes: fb32965b6dd8 ("vfio/iommufd: use IOMMU_IOAS_MAP_FILE")
Reported-by: Farrah Chen <farrah.chen@intel.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220776
Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Suggested-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
Link: https://lore.kernel.org/qemu-devel/20260527101109.71781-1-chenyi.qiang@intel.com
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit e6c47bebdf8628e635e1ba970919ca96d572dbbe)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/hw/vfio/container.c b/hw/vfio/container.c
index 4c2816b574..56bd9ac009 100644
--- a/hw/vfio/container.c
+++ b/hw/vfio/container.c
@@ -74,15 +74,43 @@ void vfio_address_space_insert(VFIOAddressSpace *space,
bcontainer->space = space;
}
+static bool vfio_container_can_dma_map_file(VFIOContainer *bcontainer,
+ MemoryRegion *mr, int *fd)
+{
+ VFIOIOMMUClass *vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
+ RAMBlock *rb = mr->ram_block;
+
+ if (!vioc->dma_map_file || !rb) {
+ return false;
+ }
+
+ *fd = qemu_ram_get_fd(rb);
+ if (*fd < 0) {
+ return false;
+ }
+
+ /*
+ * We can use IOMMU DMA mapping (IOMMU_IOAS_MAP_FILE) for :
+ *
+ * 1) Guest RAM blocks explicitly configured as shared (MAP_SHARED)
+ * 2) RAM device sub-regions (MMIO BARs)
+ *
+ * Private RAM mappings (MAP_PRIVATE) are strictly excluded. Because
+ * they are subject to copy-on-write (COW) anomalies, their underlying
+ * PFNs can permanently diverge from the backing file
+ */
+ return qemu_ram_is_shared(rb) || memory_region_is_ram_device(mr);
+}
+
int vfio_container_dma_map(VFIOContainer *bcontainer,
hwaddr iova, uint64_t size,
void *vaddr, bool readonly, MemoryRegion *mr)
{
VFIOIOMMUClass *vioc = VFIO_IOMMU_GET_CLASS(bcontainer);
- RAMBlock *rb = mr->ram_block;
- int mfd = rb ? qemu_ram_get_fd(rb) : -1;
+ int mfd;
- if (mfd >= 0 && vioc->dma_map_file) {
+ if (vfio_container_can_dma_map_file(bcontainer, mr, &mfd)) {
+ RAMBlock *rb = mr->ram_block;
unsigned long start = vaddr - qemu_ram_get_host_addr(rb);
unsigned long offset = qemu_ram_get_fd_offset(rb);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v15 02/11] arm64/ptrace: Refactor syscall_trace_enter/exit() to accept flags parameter
From: Ada Couprie Diaz @ 2026-06-24 13:38 UTC (permalink / raw)
To: Jinjie Ruan
Cc: Ada Couprie Diaz, catalin.marinas, will, oleg, tglx, peterz, luto,
kees, wad, mark.rutland, yeoreum.yun, linusw, kevin.brodsky, ldv,
thuth, james.morse, song, anshuman.khandual, broonie,
ryan.roberts, pengcan, liqiang01, linux-arm-kernel, linux-kernel
In-Reply-To: <20260511092103.1974980-3-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Refactor syscall_trace_enter() and syscall_trace_exit() to move thread
> flag reading to the caller. This aligns arm64's syscall trace enter/exit
> function signature with generic entry framework.
>
> [Changes]
> 1. Function signature changes:
> - syscall_trace_enter(regs) → syscall_trace_enter(regs, flags)
> - syscall_trace_exit(regs) → syscall_trace_exit(regs, flags)
>
> 2. Move flags reading to caller:
> - Previously: read_thread_flags() called inside each function.
> - Now: caller (like el0_svc_common) passes flags as parameter.
>
> 3. Update syscall.c:
> - el0_svc_common() now passes flags to tracing functions and
> re-fetches flags before entry/exit to handle potential TIF
> updates.
>
> [Why this matters]
> - Aligns arm64 with the generic entry interface.
> - Makes future migration to generic entry framework.
>
> No functional changes intended.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
I was a bit confused with some parts, but those changes were made to align
exactly on the generic entry code, so makes sense !
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* [Stable-11.0.2 040/107] linux-user/sh4: preserve T/M/Q bits across signal delivery
From: Michael Tokarev @ 2026-06-24 13:30 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Matt Turner, Yoshinori Sato, Richard Henderson,
Helge Deller, Michael Tokarev
In-Reply-To: <qemu-stable-11.0.2-20260624163118@cover.tls.msk.ru>
From: Matt Turner <mattst88@gmail.com>
QEMU keeps the SH4 T, M and Q status-register bits outside env->sr, in
the dedicated env->sr_t, env->sr_m and env->sr_q fields; cpu_read_sr()
folds them back into the architectural SR value and cpu_write_sr()
splits them back out.
setup_sigcontext() saved the bare env->sr (so the T/M/Q bits were always
zero in the signal frame) and restore_sigcontext() wrote the value
straight back into env->sr without updating sr_t/sr_m/sr_q. As a result
the T bit was never preserved across signal delivery: on sigreturn the
interrupted code resumed with whatever T value the signal handler last
left behind. Any conditional branch (or addc/subc/rotcl/div1, etc.)
immediately following the interrupted instruction could then take the
wrong path.
This is the cause of the long-standing intermittent failures of the
tests/tcg/multiarch/signals.c test on sh4, which was marked BROKEN. With
a SIGRTMIN timer firing every millisecond across many threads, the race
was hit a few percent of the time and corrupted the guest heap, surfacing
as a SIGSEGV in memset, a malloc assertion, or an rseq registration abort.
Traced on a deterministic rr recording: a cmp/hi set T=0, the timer
signal interrupted the very next instruction (a bf), the handler left
T=1, and the resumed bf took glibc calloc's MORECORE_CLEARS branch,
using the old top-chunk size as the clear length for a freshly split
small chunk and running memset off the end of the heap.
Fix setup_sigcontext()/restore_sigcontext() to use cpu_read_sr() and
cpu_write_sr() so the T, M and Q bits round-trip correctly, and drop the
BROKEN annotation on the sh4 signals test.
Fixes: c3b5bc8ab3 ("SH4: Signal handling for the user space emulator, by Magnus Damm.")
Cc: qemu-stable@nongnu.org
Reviewed-by: Yoshinori Sato <yoshinori.sato@nifty.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
(cherry picked from commit 6bf4c0295cccf74f3c5c0b674328b97d6fd1505c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
diff --git a/linux-user/sh4/signal.c b/linux-user/sh4/signal.c
index d70be24c38..cc36425c49 100644
--- a/linux-user/sh4/signal.c
+++ b/linux-user/sh4/signal.c
@@ -131,8 +131,10 @@ static void setup_sigcontext(struct target_sigcontext *sc,
COPY(gregs[14]); COPY(gregs[15]);
COPY(gbr); COPY(mach);
COPY(macl); COPY(pr);
- COPY(sr); COPY(pc);
+ COPY(pc);
#undef COPY
+ /* The T, M and Q bits live outside env->sr; fold them back in. */
+ __put_user(cpu_read_sr(regs), &sc->sc_sr);
for (i=0; i<16; i++) {
__put_user(regs->fregs[i], &sc->sc_fpregs[i]);
@@ -159,8 +161,14 @@ static void restore_sigcontext(CPUSH4State *regs, struct target_sigcontext *sc)
COPY(gregs[14]); COPY(gregs[15]);
COPY(gbr); COPY(mach);
COPY(macl); COPY(pr);
- COPY(sr); COPY(pc);
+ COPY(pc);
#undef COPY
+ /* The T, M and Q bits live outside env->sr; unfold them. */
+ {
+ uint32_t sr;
+ __get_user(sr, &sc->sc_sr);
+ cpu_write_sr(regs, sr);
+ }
for (i=0; i<16; i++) {
__get_user(regs->fregs[i], &sc->sc_fpregs[i]);
diff --git a/tests/tcg/sh4/Makefile.target b/tests/tcg/sh4/Makefile.target
index 7852fa62d8..b7a8737be0 100644
--- a/tests/tcg/sh4/Makefile.target
+++ b/tests/tcg/sh4/Makefile.target
@@ -3,13 +3,6 @@
# SuperH specific tweaks
#
-# This triggers failures for sh4-linux about 10% of the time.
-# Random SIGSEGV at unpredictable guest address, cause unknown.
-run-signals: signals
- $(call skip-test, $<, "BROKEN")
-run-plugin-signals-with-%:
- $(call skip-test, $<, "BROKEN")
-
VPATH += $(SRC_PATH)/tests/tcg/sh4
test-macl: CFLAGS += -O -g
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.