Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: aed74d3d6244b3ed8662ac9a987415079ac3eb31
https://github.com/qemu/qemu/commit/aed74d3d6244b3ed8662ac9a987415079ac3eb31
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M include/block/aio.h
Log Message:
-----------
block: Note on aio_co_wake use if not yet yielding
aio_co_wake() is generally safe to call regardless of whether the
coroutine is already yielding or not. If it is not yet yielding, it
will be scheduled to run when it does yield.
Caveats:
- The caller must be independent of the coroutine (to ensure the
coroutine must be yielding if both are in the same AioContext), i.e.
must not be the same coroutine
- The coroutine must yield at some point
Make note of this so callers can reason that their use is safe.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 89d22536d1a1715083ef8118fe7e6e9239f900c1
https://github.com/qemu/qemu/commit/89d22536d1a1715083ef8118fe7e6e9239f900c1
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/rbd.c
Log Message:
-----------
rbd: Run co BH CB in the coroutine’s AioContext
qemu_rbd_completion_cb() schedules the request completion code
(qemu_rbd_finish_bh()) to run in the BDS’s AioContext, assuming that
this is the same thread in which qemu_rbd_start_co() runs.
To explain, this is how both latter functions interact:
In qemu_rbd_start_co():
while (!task.complete)
qemu_coroutine_yield();
In qemu_rbd_finish_bh():
task->complete = true;
aio_co_wake(task->co); // task->co is qemu_rbd_start_co()
For this interaction to work reliably, both must run in the same thread
so that qemu_rbd_finish_bh() can only run once the coroutine yields.
Otherwise, finish_bh() may run before start_co() checks task.complete,
which will result in the latter seeing .complete as true immediately and
skipping the yield altogether, even though finish_bh() still wakes it.
With multiqueue, the BDS’s AioContext is not necessarily the thread
start_co() runs in, and so finish_bh() may be scheduled to run in a
different thread than start_co(). With the right timing, this will
cause the problems described above; waking a non-yielding coroutine is
not good, as can be reproduced by putting e.g. a usleep(100000) above
the while loop in start_co() (and using multiqueue), giving finish_bh()
a much better chance at exiting before start_co() can yield.
So instead of scheduling finish_bh() in the BDS’s AioContext, schedule
finish_bh() in task->co’s AioContext.
In addition, we can get rid of task.complete altogether because we will
get woken exactly once, when the task is indeed complete, no need to
check.
(We could go further and drop the BH, running aio_co_wake() directly in
qemu_rbd_completion_cb() because we are allowed to do that even if the
coroutine isn’t yet yielding and we’re in a different thread – but the
doc comment on qemu_rbd_completion_cb() says to be careful, so I decided
not to go so far here.)
Buglink: https://issues.redhat.com/browse/RHEL-67115
Reported-by: Junyao Zhao <[email protected]>
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: a9500527db10db7cf8a490b0de58a9b2321440b7
https://github.com/qemu/qemu/commit/a9500527db10db7cf8a490b0de58a9b2321440b7
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/iscsi.c
Log Message:
-----------
iscsi: Run co BH CB in the coroutine’s AioContext
For rbd (and others), as described in “rbd: Run co BH CB in the
coroutine’s AioContext”, the pattern of setting a completion flag and
waking a coroutine that yields while the flag is not set can only work
when both run in the same thread.
iscsi has the same pattern, but the details are a bit different:
iscsi_co_generic_cb() can (as far as I understand) only run through
iscsi_service(), not just from a random thread at a random time.
iscsi_service() in turn can only be run after iscsi_set_events() set up
an FD event handler, which is done in iscsi_co_wait_for_task().
As a result, iscsi_co_wait_for_task() will always yield exactly once,
because iscsi_co_generic_cb() can only run after iscsi_set_events(),
after the completion flag has already been checked, and the yielding
coroutine will then be woken only once the completion flag was set to
true. So as far as I can tell, iscsi has no bug and already works fine.
Still, we don’t need the completion flag because we know we have to
yield exactly once, so we can drop it. This simplifies the code and
makes it more obvious that the “rbd bug” isn’t present here.
This makes iscsi_co_generic_bh_cb() and iscsi_retry_timer_expired() a
bit boring, so at least the former we can drop and call aio_co_wake()
directly from scsi_co_generic_cb() to the same effect. As for the
latter, the timer needs a CB, so we can’t drop it (I suppose we could
technically use aio_co_wake directly as the CB, but that would be
nasty), but we can put it into the coroutine’s AioContext to make its
aio_co_wake() a simple wrapper around qemu_coroutine_enter() without a
further BH indirection.
Finally, remove the iTask->co != NULL checks: This field is set by
iscsi_co_init_iscsitask(), which all users of IscsiTask run before even
setting up iscsi_co_generic_cb() as the callback, and it is never set or
cleared elsewhere, so it is impossible to not be set in
iscsi_co_generic_cb().
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: deb35c129b859b9bec70fd42f856a0b7c1dc6e61
https://github.com/qemu/qemu/commit/deb35c129b859b9bec70fd42f856a0b7c1dc6e61
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/nfs.c
Log Message:
-----------
nfs: Run co BH CB in the coroutine’s AioContext
Like in “rbd: Run co BH CB in the coroutine’s AioContext”, drop the
completion flag, yield exactly once, and run the BH in the coroutine’s
AioContext.
(Can be reproduced with multiqueue by adding a usleep(100000) before the
`while (!task.complete)` loops.)
Like in “iscsi: Run co BH CB in the coroutine’s AioContext”, this makes
nfs_co_generic_bh_cb() trivial, so we can drop it in favor of just
calling aio_co_wake() directly.
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 53d5c7ffac7bd4e0d12174432ebb2b3e88614b15
https://github.com/qemu/qemu/commit/53d5c7ffac7bd4e0d12174432ebb2b3e88614b15
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: Fix coroutine waking
If we wake a coroutine from a different context, we must ensure that it
will yield exactly once (now or later), awaiting that wake.
curl’s current .ret == -EINPROGRESS loop may lead to the coroutine not
yielding if the request finishes before the loop gets run. To fix it,
we must drop the loop and yield exactly once, if we need to yield.
Finding out that latter part ("if we need to yield") makes it a bit
complicated: Requests may be served from a cache internal to the curl
block driver, or fail before being submitted. In these cases, we must
not yield. However, if we find a matching but still ongoing request in
the cache, we will have to await that, i.e. still yield.
To address this, move the yield inside of the respective functions:
- Inside of curl_find_buf() when awaiting ongoing concurrent requests,
- Inside of curl_setup_preadv() when having created a new request.
Rename curl_setup_preadv() to curl_do_preadv() to reflect this.
(Can be reproduced with multiqueue by adding a usleep(100000) before the
`while (acb.ret == -EINPROGRESS)` loop.)
Also, add a comment why aio_co_wake() is safe regardless of whether the
coroutine and curl_multi_check_completion() run in the same context.
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 7214ad20da625c84e55536a274acdd5af9627ff7
https://github.com/qemu/qemu/commit/7214ad20da625c84e55536a274acdd5af9627ff7
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/gluster.c
Log Message:
-----------
gluster: Do not move coroutine into BDS context
The request coroutine may not run in the BDS AioContext. We should wake
it in its own context, not move it.
With that, we can remove GlusterAIOCB.aio_context.
Also add a comment why aio_co_schedule() is safe to use in this way.
**Note:** Due to a lack of a gluster set-up, I have not tested this
commit. It seemed safe enough to send anyway, just maybe not to
qemu-stable. To be clear, I don’t know of any user-visible bugs that
would arise from the state without this patch; the request coroutine is
moved into the main BDS AioContext, so guest device completion code will
run in a different context than where the request started, which can’t
be good, but I haven’t actually confirmed any bugs (due to not being
able to test it).
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 7a501bbd51941fb1867d78e6b0d1dc69e396b9e2
https://github.com/qemu/qemu/commit/7a501bbd51941fb1867d78e6b0d1dc69e396b9e2
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/nvme.c
Log Message:
-----------
nvme: Kick and check completions in BDS context
nvme_process_completion() must run in the main BDS context, so schedule
a BH for requests that aren’t there.
The context in which we kick does not matter, but let’s just keep kick
and process_completion together for simplicity’s sake.
(For what it’s worth, a quick fio bandwidth test indicates that on my
test hardware, if anything, this may be a bit better than kicking
immediately before scheduling a pure nvme_process_completion() BH. But
I wouldn’t take more from those results than that it doesn’t really seem
to matter either way.)
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 0f142cbd919fcb6cea7aa176f7e4939925806dd9
https://github.com/qemu/qemu/commit/0f142cbd919fcb6cea7aa176f7e4939925806dd9
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/nvme.c
Log Message:
-----------
nvme: Fix coroutine waking
nvme wakes the request coroutine via qemu_coroutine_enter() from a BH
scheduled in the BDS AioContext. This may not be the same context as
the one in which the request originally ran, which would be wrong:
- It could mean we enter the coroutine before it yields,
- We would move the coroutine in to a different context.
(Can be reproduced with multiqueue by adding a usleep(100000) before the
`while (data.ret == -EINPROGRESS)` loop.)
To fix that, use aio_co_wake() to run the coroutine in its home context.
Just like in the preceding iscsi and nfs patches, we can drop the
trivial nvme_rw_cb_bh() and use aio_co_wake() directly.
With this, we can remove NVMeCoData.ctx.
Note the check of data->co == NULL to bypass the BH/yield combination in
case nvme_rw_cb() is called from nvme_submit_command(): We probably want
to keep this fast path for performance reasons, but we have to be quite
careful about it:
- We cannot overload .ret for this, but have to use a dedicated
.skip_yield field. Otherwise, if nvme_rw_cb() runs in a different
thread than the coroutine, it may see .ret set and skip the yield,
while nvme_rw_cb() will still schedule a BH for waking. Therefore,
the signal to skip the yield can only be set in nvme_rw_cb() if waking
too is skipped, which is independent from communicating the return
value.
- We can only skip the yield if nvme_rw_cb() actually runs in the
request coroutine. Otherwise (specifically if they run in different
AioContexts), the order between this function’s execution and the
coroutine yielding (or not yielding) is not reliable.
- There is no point to yielding in a loop; there are no spurious wakes,
so once we yield, we will only be re-entered once the command is done.
Replace `while` by `if`.
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: ac3520f599fedee05945ce06bb0f71820a7b2ffc
https://github.com/qemu/qemu/commit/ac3520f599fedee05945ce06bb0f71820a7b2ffc
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/nvme.c
Log Message:
-----------
nvme: Note in which AioContext some functions run
Sprinkle comments throughout block/nvme.c noting for some functions
(where it may not be obvious) that they require a certain AioContext, or
in which AioContext they do happen to run (for callbacks, BHs, event
notifiers).
Suggested-by: Kevin Wolf <[email protected]>
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 9b9ee60c07f52009f9bb659f54c42afae95c1d94
https://github.com/qemu/qemu/commit/9b9ee60c07f52009f9bb659f54c42afae95c1d94
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/io.c
Log Message:
-----------
block/io: Take reqs_lock for tracked_requests
bdrv_co_get_self_request() does not take a lock around iterating through
bs->tracked_requests. With multiqueue, it may thus iterate over a list
that is in the process of being modified, producing an assertion
failure:
../block/file-posix.c:3702: raw_do_pwrite_zeroes: Assertion `req' failed.
[0] abort() at /lib64/libc.so.6
[1] __assert_fail_base.cold() at /lib64/libc.so.6
[2] raw_do_pwrite_zeroes() at ../block/file-posix.c:3702
[3] bdrv_co_do_pwrite_zeroes() at ../block/io.c:1910
[4] bdrv_aligned_pwritev() at ../block/io.c:2109
[5] bdrv_co_do_zero_pwritev() at ../block/io.c:2192
[6] bdrv_co_pwritev_part() at ../block/io.c:2292
[7] bdrv_co_pwritev() at ../block/io.c:2225
[8] handle_alloc_space() at ../block/qcow2.c:2573
[9] qcow2_co_pwritev_task() at ../block/qcow2.c:2625
Fix this by taking reqs_lock.
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 90db3a1721b30daf839901813616c0854f383cc5
https://github.com/qemu/qemu/commit/90db3a1721b30daf839901813616c0854f383cc5
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/qcow2.c
Log Message:
-----------
qcow2: Re-initialize lock in invalidate_cache
After clearing our state (memset()-ing it to 0), we should
re-initialize objects that need it. Specifically, that applies to
s->lock, which is originally initialized in qcow2_open().
Given qemu_co_mutex_init() is just a memset() to 0, this is functionally
a no-op, but still seems like the right thing to do.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: f86dde9a1524f0d7fca0f4037f560e6131d31f7f
https://github.com/qemu/qemu/commit/f86dde9a1524f0d7fca0f4037f560e6131d31f7f
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/qcow2.c
M block/qcow2.h
Log Message:
-----------
qcow2: Fix cache_clean_timer
The cache-cleaner runs as a timer CB in the BDS AioContext. With
multiqueue, it can run concurrently to I/O requests, and because it does
not take any lock, this can break concurrent cache accesses, corrupting
the image. While the chances of this happening are low, it can be
reproduced e.g. by modifying the code to schedule the timer CB every
5 ms (instead of at most once per second) and modifying the last (inner)
while loop of qcow2_cache_clean_unused() like so:
while (i < c->size && can_clean_entry(c, i)) {
for (int j = 0; j < 1000 && can_clean_entry(c, i); j++) {
usleep(100);
}
c->entries[i].offset = 0;
c->entries[i].lru_counter = 0;
i++;
to_clean++;
}
i.e. making it wait on purpose for the point in time where the cache is
in use by something else.
The solution chosen for this in this patch is not the best solution, I
hope, but I admittedly can’t come up with anything strictly better.
We can protect from concurrent cache accesses either by taking the
existing s->lock, or we introduce a new (non-coroutine) mutex
specifically for cache accesses. I would prefer to avoid the latter so
as not to introduce additional (very slight) overhead.
Using s->lock, which is a coroutine mutex, however means that we need to
take it in a coroutine, so the timer must run in a coroutine. We can
transform it from the current timer CB style into a coroutine that
sleeps for the set interval. As a result, however, we can no longer
just deschedule the timer to instantly guarantee it won’t run anymore,
but have to await the coroutine’s exit.
(Note even before this patch there were places that may not have been so
guaranteed after all: Anything calling cache_clean_timer_del() from the
QEMU main AioContext could have been running concurrently to an existing
timer CB invocation.)
Polling to await the timer to actually settle seems very complicated for
something that’s rather a minor problem, but I can’t come up with any
better solution that doesn’t again just overlook potential problems.
(Not Cc-ing qemu-stable, as the issue is quite unlikely to be hit, and
I’m not too fond of this solution.)
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 94ce870f60dc59777aa78313633930c252638c19
https://github.com/qemu/qemu/commit/94ce870f60dc59777aa78313633930c252638c19
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/qcow2.c
Log Message:
-----------
qcow2: Schedule cache-clean-timer in realtime
There is no reason why the cache cleaning timer should run in virtual
time, run it in realtime instead.
Suggested-by: Kevin Wolf <[email protected]>
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 7c3e9b87f568e726731fad8b64f8e3dd28417563
https://github.com/qemu/qemu/commit/7c3e9b87f568e726731fad8b64f8e3dd28417563
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/ssh.c
Log Message:
-----------
ssh: Run restart_coroutine in current AioContext
restart_coroutine() is attached as an FD handler just to wake the
current coroutine after yielding. It makes most sense to attach it to
the current (request) AioContext instead of the BDS main context. This
way, the coroutine can be entered directly from the BH instead of having
yet another indirection through AioContext.co_schedule_bh.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: b0cc742f8475398467eaf85f1d3692d215465327
https://github.com/qemu/qemu/commit/b0cc742f8475398467eaf85f1d3692d215465327
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/blkreplay.c
Log Message:
-----------
blkreplay: Run BH in coroutine’s AioContext
While it does not matter in which AioContext we run aio_co_wake() to
continue an exactly-once-yielding coroutine, making this commit not
strictly necessary, there is also no reason why the BH should run in any
context but the request’s AioContext.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: d45b2c65f2570433c092f35296976c1f6241f54b
https://github.com/qemu/qemu/commit/d45b2c65f2570433c092f35296976c1f6241f54b
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M include/block/block_int-common.h
Log Message:
-----------
block: Note in which AioContext AIO CBs are called
This doesn’t seem to be specified anywhere, but is something we probably
want to be clear. I believe it is reasonable to implicitly assume that
callbacks are run in the current thread (unless explicitly noted
otherwise), so codify that assumption.
Some implementations don’t actually fulfill this contract yet. The next
patches should rectify that.
Note: I don’t know of any user-visible bugs produced by not running AIO
callbacks in the original context. AIO functionality is generally
mapped to coroutines through the use of bdrv_co_io_em_complete(), which
can run in any AioContext, and will always wake the yielding coroutine
in its original context. The only benefit here is that running
bdrv_co_io_em_complete() in the original context will make that
aio_co_wake() most likely a simpler qemu_coroutine_enter() instead of
scheduling the wakeup through AioContext.co_schedule_bh.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 63d15c7aa5c82b3bebcaf4be3802f6949657f41c
https://github.com/qemu/qemu/commit/63d15c7aa5c82b3bebcaf4be3802f6949657f41c
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/iscsi.c
Log Message:
-----------
iscsi: Create AIO BH in original AioContext
AIO callbacks must be called in the original request’s AioContext,
regardless of the BDS’s “main” AioContext.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: f18782a8f538160f1b9924e5964ed1899f130852
https://github.com/qemu/qemu/commit/f18782a8f538160f1b9924e5964ed1899f130852
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/null.c
Log Message:
-----------
null-aio: Run CB in original AioContext
AIO callbacks must be called in the originally calling AioContext,
regardless of the BDS’s “main” AioContext.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: 837c04e9fc798cddafe721e2abbbd0d932571793
https://github.com/qemu/qemu/commit/837c04e9fc798cddafe721e2abbbd0d932571793
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M block/win32-aio.c
Log Message:
-----------
win32-aio: Run CB in original context
AIO callbacks must be called in the originally calling AioContext,
regardless of the BDS’s “main” AioContext.
Note: I tried to test this (under wine), but failed. Whenever I tried
to use multiqueue or even just an I/O thread for a virtio-blk (or
virtio-scsi) device, I/O stalled, both with and without this patch.
For what it’s worth, when not using an I/O thread, I/O continued to work
with this patch.
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Commit: ad2085658511d0b14db7fca54094471b37bc6751
https://github.com/qemu/qemu/commit/ad2085658511d0b14db7fca54094471b37bc6751
Author: David Hildenbrand (Red Hat) <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M .mailmap
M MAINTAINERS
Log Message:
-----------
MAINTAINERS: Update David Hildenbrand's email address
Switch to kernel.org email address as I will be leaving Red Hat. The
old address will remain active until end of January 2026, so performing
the change now should make sure that most mails will reach me.
Signed-off-by: David Hildenbrand <[email protected]>
Signed-off-by: David Hildenbrand (Red Hat) <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 3abfbb571143ba865488b6c11f8ad75dda97d1a3
https://github.com/qemu/qemu/commit/3abfbb571143ba865488b6c11f8ad75dda97d1a3
Author: Cédric Le Goater <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M hw/intc/ioapic.c
Log Message:
-----------
hw/intc/ioapic: Fix ACCEL_KERNEL_GSI_IRQFD_POSSIBLE typo
Commit 638ac1c78457 introduced a regression in interrupt remapping
when running a VM configured with an intel-iommu device and an
assigned PCI VF. During boot, Linux reports repeated messages :
[ 15.416794] __common_interrupt: 2.37 No irq handler for vector
[ 15.417266] __common_interrupt: 2.37 No irq handler for vector
[ 15.417733] __common_interrupt: 2.37 No irq handler for vector
[ 15.418202] __common_interrupt: 2.37 No irq handler for vector
[ 15.418670] __common_interrupt: 2.37 No irq handler for vector
and may eventually hang.
The issue is caused by the incorrect use of the macro
ACCEL_KERNEL_GSI_IRQFD_POSSIBLE, which should instead be
ACCEL_GSI_IRQFD_POSSIBLE.
Fixes: 638ac1c78457 ("hw/intc: Generalize APIC helper names from kvm_* to
accel_*")
Cc: Magnus Kulke <[email protected]>
Signed-off-by: Cédric Le Goater <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 321ded29e663ca040a0c4ecd3ff97452c9d30a3f
https://github.com/qemu/qemu/commit/321ded29e663ca040a0c4ecd3ff97452c9d30a3f
Author: Peter Maydell <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M system/qtest.c
Log Message:
-----------
system/qtest.c: Allow for multiple CHR_EVENT_CLOSED events
In the qtest_event() QEMUChrEvent handler, we create a timer
and log OPENED on CHR_EVENT_OPENED, and we destroy the timer and
log CLOSED on CHR_EVENT_CLOSED. However, the chardev subsystem
can send us more than one CHR_EVENT_CLOSED if we're reading from
a file chardev:
* the first one happens when we read the last data from the file
* the second one happens when the user hits ^C to exit QEMU
and the chardev is finalized: char_fd_finalize()
This causes us to call g_timer_elapsed() with a NULL timer
(which glib complains about) and print an extra CLOSED log line
with a zero timestamp:
[I +0.063829] CLOSED
qemu-system-aarch64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
[I +0.000000] CLOSED
Avoid this by ignoring a CHR_EVENT_CLOSED if we have already
processed one.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 2739d6ff50bbfcb1983660730a05be26271e4fce
https://github.com/qemu/qemu/commit/2739d6ff50bbfcb1983660730a05be26271e4fce
Author: Bin Meng <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M hw/sd/sd.c
Log Message:
-----------
hw/sd: Fix incorrect idle state reporting in R1 response for SPI mode
Since commit b66f73a0 ("hw/sd: Add SDHC support for SD card SPI-mode"),
the CARD_POWER_UP bit in the OCR register has been set after reset.
Therefore, checking this bit against zero in sd_response_r1_make() to
determine the card’s idle state is incorrect in SPI mode. As a result,
QEMU makes the U-Boot mmc-spi driver believe the card never leaves the
reset state.
Fixes: 1585ab9f ("hw/sd/sdcard: Fill SPI response bits in card code")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2945
Reported-by: Tom Rini <[email protected]>
Signed-off-by: Bin Meng <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 40260d3ea67cc5cdf20553be24353680d70b1b6c
https://github.com/qemu/qemu/commit/40260d3ea67cc5cdf20553be24353680d70b1b6c
Author: Bin Meng <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M hw/sd/sd.c
Log Message:
-----------
hw/sd: Fix ACMD41 state machine in SPI mode
In SPI mode, the ACMD41 argument only defines bit 30 (HCS); all other
bits are reserved. The current implementation incorrectly checks the
voltage window bits even in SPI mode, preventing the state machine
from transitioning to the READY state. As a result, the U-Boot
mmc-spi driver falls into an endless CMD55/ACMD41 loop.
Fixes: 3241a61a ("hw/sd/sdcard: Use complete SEND_OP_COND implementation in SPI
mode")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2945
Reported-by: Tom Rini <[email protected]>
Signed-off-by: Bin Meng <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: a344e22917f48d8cd876d72057bcfb938beb0630
https://github.com/qemu/qemu/commit/a344e22917f48d8cd876d72057bcfb938beb0630
Author: Yannick Voßen <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M hw/dma/xlnx-zynq-devcfg.c
Log Message:
-----------
hw/dma/zynq-devcfg: Fix register memory
Registers are always 32 bit aligned. R_MAX is not the maximum
register address, it is the maximum register number. The memory
size can be determined by 4 * R_MAX.
Currently every register with an offset bigger than 0x40 will be
ignored, because the memory size is set wrong. This effects the
MCTRL register and makes it useless. This commit restores the
correct behaviour.
Cc: [email protected]
Fixes: 034c2e69023 ("dma: Add Xilinx Zynq devcfg device model")
Signed-off-by: YannickV <[email protected]>
Reviewed-by: Edgar E. Iglesias <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: f20a824902abe144c1441322d02ba18567797452
https://github.com/qemu/qemu/commit/f20a824902abe144c1441322d02ba18567797452
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M hw/arm/xen-pvh.c
Log Message:
-----------
hw/arm: Re-enable xenpvh machine in qemu-system-arm/aarch64 binaries
While registering the ARM/Aarch64 machine interfaces
in commit 38c5ab40031 ("hw/arm: Filter machine types
for qemu-system-arm/aarch64 binaries"), we missed the
XenPV machine. Correct that.
Reported-by: Edgar E. Iglesias <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Edgar E. Iglesias <[email protected]>
Reviewed-by: Edgar E. Iglesias <[email protected]>
Message-Id: <[email protected]>
Commit: 99282a805cea60a1b81223b1ed4fe42ea4b16189
https://github.com/qemu/qemu/commit/99282a805cea60a1b81223b1ed4fe42ea4b16189
Author: Jan Kiszka <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M hw/sd/sd.c
Log Message:
-----------
hw/sd/sdcard: Avoid confusing address calculation in rpmb_calc_hmac
>From the source frame, we initially need to copy out all fields after
data, thus starting from nonce on. Avoid expressing this indirectly by
pointing to the end of the data field - which also raised the attention
of Coverity (out-of-bound read /wrt data).
Resolves: CID 1642869
Reported-by: GuoHan Zhao <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
[PMD: Add comment before the memcpy() call]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: d3bc229c79c7d5a94463f836707793331807b709
https://github.com/qemu/qemu/commit/d3bc229c79c7d5a94463f836707793331807b709
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M qga/commands-posix.c
Log Message:
-----------
qga/commands: Include proper Solaris header for getloadavg()
Solaris declares getloadavg() in <sys/loadavg.h>:
getloadavg(3C) Standard C Library Functions getloadavg(3C)
NAME
getloadavg - get system load averages
SYNOPSIS
#include <sys/loadavg.h>
int getloadavg(double loadavg[], int nelem);
[...]
Oracle Solaris 11.4 23 Jul 2020 getloadavg(3C)
Include it in order to avoid:
../qga/commands-posix.c: In function 'qmp_guest_get_load':
../qga/commands-posix.c:1408:9: error: implicit declaration of function
'getloadavg' [-Wimplicit-function-declaration]
1408 | if (getloadavg(loadavg, G_N_ELEMENTS(loadavg)) < 0) {
| ^~~~~~~~~~
../qga/commands-posix.c:1408:9: warning: nested extern declaration of
'getloadavg' [-Wnested-externs]
../configure relevant output:
C compiler for the host machine: gcc (gcc 14.2.0 "gcc (GCC) 14.2.0")
C linker for the host machine: gcc ld.solaris 5.11-1.3315
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Kostiantyn Kostiuk <[email protected]>
Acked-by: Richard Henderson <[email protected]>
Message-Id: <[email protected]>
Commit: 9c3b76a0d40671cbdf1f97c662311ec8bb517c76
https://github.com/qemu/qemu/commit/9c3b76a0d40671cbdf1f97c662311ec8bb517c76
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M include/hw/misc/lasi.h
Log Message:
-----------
hw/southbridge/lasi: Correct LasiState parent
TYPE_LASI_CHIP inherits from TYPE_SYS_BUS_DEVICE, not
TYPE_PCI_HOST_BRIDGE, so its parent structure is of
SysBusDevice type.
Cc: [email protected]
Fixes: 376b851909d ("hppa: Add support for LASI chip with i82596 NIC")
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Gustavo Romero <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
Commit: 15544486f0609608f6118a551f876e3030fc5eb9
https://github.com/qemu/qemu/commit/15544486f0609608f6118a551f876e3030fc5eb9
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M meson.build
Log Message:
-----------
buildsys: Remove dead 'mips' entry in supported_cpus[] array
Remove 'mips' from supported_cpus[], forgotten in commit
269ffaabc84 ("buildsys: Remove support for 32-bit MIPS hosts").
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-Id: <[email protected]>
Commit: 0456a977af2157d85871a7645b9b34ca29bd8d8a
https://github.com/qemu/qemu/commit/0456a977af2157d85871a7645b9b34ca29bd8d8a
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M meson.build
M migration/rdma.c
Log Message:
-----------
migration/rdma: Check ntohll() availability with meson
Commit 44ce1b5d2fc ("migration/rdma: define htonll/ntohll
only if not predefined") tried to only include htonll/ntohll
replacements when their symbol is *defined*, but this doesn't
work, as they aren't:
../migration/rdma.c:242:17: error: static declaration of 'htonll' follows
non-static declaration
242 | static uint64_t htonll(uint64_t v)
| ^~~~~~
In file included from /usr/include/netinet/in.h:73,
from /usr/include/sys/socket.h:32,
from /home/f4bug/qemu/include/system/os-posix.h:30,
from /home/f4bug/qemu/include/qemu/osdep.h:176,
from ../migration/rdma.c:17:
/usr/include/sys/byteorder.h:75:18: note: previous declaration of 'htonll'
with type 'uint64_t(uint64_t)' {aka 'long unsigned int(long unsigned int)'}
75 | extern uint64_t htonll(uint64_t);
| ^~~~~~
../migration/rdma.c:252:17: error: static declaration of 'ntohll' follows
non-static declaration
252 | static uint64_t ntohll(uint64_t v)
| ^~~~~~
/usr/include/sys/byteorder.h:76:18: note: previous declaration of 'ntohll'
with type 'uint64_t(uint64_t)' {aka 'long unsigned int(long unsigned int)'}
76 | extern uint64_t ntohll(uint64_t);
| ^~~~~~
Better to check the symbol availability with meson.
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Acked-by: Peter Xu <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <[email protected]>
Commit: 08ab276a38002baabf05aa7cdb96f395bb8d5c35
https://github.com/qemu/qemu/commit/08ab276a38002baabf05aa7cdb96f395bb8d5c35
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M docs/about/deprecated.rst
M docs/about/removed-features.rst
Log Message:
-----------
docs: Correct release of MIPS deprecations / removals
We are going to release 10.2, not 11.0 :)
Reported-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <[email protected]>
Commit: 4af2433a81bd057161371413348790969500bd4b
https://github.com/qemu/qemu/commit/4af2433a81bd057161371413348790969500bd4b
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M docs/about/removed-features.rst
Log Message:
-----------
docs: Mention 32-bit PPC host as removed
We removed support for 32-bit PPC hosts in commit 5c1ec5a1ee0
("tcg/ppc: Remove support for 32-bit hosts").
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Acked-by: Harsh Prateek Bora <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <[email protected]>
Commit: f6816bf9adeac77db3cc7832f0d27a6482acf6e9
https://github.com/qemu/qemu/commit/f6816bf9adeac77db3cc7832f0d27a6482acf6e9
Author: Djordje Todorovic <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M scripts/checkpatch.pl
Log Message:
-----------
scripts/checkpatch: Check DEVICE_NATIVE_ENDIAN
Developers should specify endianess explicitly.
Signed-off-by: Djordje Todorovic <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 29ca82150657624a77df301d2c11114c4420d23a
https://github.com/qemu/qemu/commit/29ca82150657624a77df301d2c11114c4420d23a
Author: Markus Armbruster <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M ebpf/ebpf_rss-stub.c
Log Message:
-----------
ebpf: Fix stubs to set an error when they return failure
Stubs in ebpf_rss-stub.c return false for failure without setting an
Error. This is wrong. Callers may assume that the functions set an
error when they fail, and crash when they try to examine or report the
error. Callers may also check the error instead of the return value,
and misinterpret the failure as success.
ebpf_rss_load() and ebpf_rss_load() are reachable via
virtio_net_load_ebpf(). Fix them to set an error.
ebpf_rss_set_all() is unreachable: it can only be called when the
context has an eBPF program loaded, which is impossible with eBPF
support compiled out. Call abort() there to make that clear, and to
get rid of the latent bug.
Fixes: 00b69f1d867d (ebpf: add formal error reporting to all APIs)
Signed-off-by: Markus Armbruster <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 6cb4cd503b7c8d543a234b59271522a524b2f6b0
https://github.com/qemu/qemu/commit/6cb4cd503b7c8d543a234b59271522a524b2f6b0
Author: Markus Armbruster <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M ebpf/ebpf_rss.c
Log Message:
-----------
ebpf: Clean up useless error check in ebpf_rss_set_all()
ebpf_rss_set_all() is only called when the context has an eBPF program
loaded. Replace the dead error check with an assertion.
Signed-off-by: Markus Armbruster <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: de285aa9076841c618d068f7b838e312fc8b26c6
https://github.com/qemu/qemu/commit/de285aa9076841c618d068f7b838e312fc8b26c6
Author: Markus Armbruster <[email protected]>
Date: 2025-11-18 (Tue, 18 Nov 2025)
Changed paths:
M ebpf/ebpf_rss.c
M hw/net/virtio-net.c
Log Message:
-----------
ebpf: Make ebpf_rss_load() return value consistent with @errp
ebpf_rss_load() returns false for failure without setting an Error
when its @ctx argument already has an eBPF program loaded. This is
wrong. Fortunately, it is only called @ctx has a program. Replace
the incorrect error check by an assertion.
The return value is now obviously reliable. Change the caller to use
it, because it's more concise.
Signed-off-by: Markus Armbruster <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Commit: 6327540d92e4ef4039dc812d73213d248a9de05b
https://github.com/qemu/qemu/commit/6327540d92e4ef4039dc812d73213d248a9de05b
Author: Richard Henderson <[email protected]>
Date: 2025-11-19 (Wed, 19 Nov 2025)
Changed paths:
M block/blkreplay.c
M block/curl.c
M block/gluster.c
M block/io.c
M block/iscsi.c
M block/nfs.c
M block/null.c
M block/nvme.c
M block/qcow2.c
M block/qcow2.h
M block/rbd.c
M block/ssh.c
M block/win32-aio.c
M include/block/aio.h
M include/block/block_int-common.h
Log Message:
-----------
Merge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into staging
Block layer patches
- Multi-threading fixes in several block drivers
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmkcpowRHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9bnrA/9HpvuLovahyZH+zke9FAzE9EcZ8eLgT4t
# JM5ijkrfZ8KoyvW9zmUiT/T/BhewFY4if6FqIUvQoCVIQAN+Y3Z8Us/WcZpb3xG7
# EMUr/CeiRl7Ka0SGbxZWR6H10Enuq4hoesfkRPXGV33CKuef09HvgE0184aazZLs
# bfeBn562zUcYzn/HqNFcPqLh6goeHWhsnQuxfJJeu7i05HofeM/3T7WUcCmxhn3V
# 4Pk6o0toYONuZpfUZityieEI54ID95gVmllaE8QT5f0rBXHp6ae5P6x+fnqbj306
# DA5RKBxM5nJ5Md2mo2tJtJ0eUNzbxXpAnT+wMkcDO4OQq8F6KngOTokPPKv13z1f
# uUSwZW5QXV8pvU6AZouUlPStz0MFtfXSVqLZaV51BB7MrIGF79ina9vwMYoteTNJ
# CGi32Ca0dl3PjLm//avmZiHYAeczpK34nPImRLZnhh78zQal/yDpdpi5No/tm4Yf
# /0OAES0legGC3hTsuDh9sXqkmRn3qNvUd40IuDRyvrNYxMUuF+2IQymD5Hcm/6CO
# uIf+/61OPHLHwKFYHyyK44XmcYQHCE0LxilmWVrNaULs4a3nvlRz3GTZ09R/ebAl
# ddtedo9eHN6KfViTa95YWuu53iXzQRPUp3CrSC1gPB04zphpYsCy7eJ/t3kJqCpP
# 9CVf3PMOmZA=
# =FNy0
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 18 Nov 2025 06:02:04 PM CET
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "[email protected]"
# gpg: Good signature from "Kevin Wolf <[email protected]>" [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:
win32-aio: Run CB in original context
null-aio: Run CB in original AioContext
iscsi: Create AIO BH in original AioContext
block: Note in which AioContext AIO CBs are called
blkreplay: Run BH in coroutine’s AioContext
ssh: Run restart_coroutine in current AioContext
qcow2: Schedule cache-clean-timer in realtime
qcow2: Fix cache_clean_timer
qcow2: Re-initialize lock in invalidate_cache
block/io: Take reqs_lock for tracked_requests
nvme: Note in which AioContext some functions run
nvme: Fix coroutine waking
nvme: Kick and check completions in BDS context
gluster: Do not move coroutine into BDS context
curl: Fix coroutine waking
nfs: Run co BH CB in the coroutine’s AioContext
iscsi: Run co BH CB in the coroutine’s AioContext
rbd: Run co BH CB in the coroutine’s AioContext
block: Note on aio_co_wake use if not yet yielding
Signed-off-by: Richard Henderson <[email protected]>
Commit: 5e0242e9a847b5d17b87be80b70c5dbe45bbcdc7
https://github.com/qemu/qemu/commit/5e0242e9a847b5d17b87be80b70c5dbe45bbcdc7
Author: Richard Henderson <[email protected]>
Date: 2025-11-19 (Wed, 19 Nov 2025)
Changed paths:
M .mailmap
M MAINTAINERS
M docs/about/deprecated.rst
M docs/about/removed-features.rst
M ebpf/ebpf_rss-stub.c
M ebpf/ebpf_rss.c
M hw/arm/xen-pvh.c
M hw/dma/xlnx-zynq-devcfg.c
M hw/intc/ioapic.c
M hw/net/virtio-net.c
M hw/sd/sd.c
M include/hw/misc/lasi.h
M meson.build
M migration/rdma.c
M qga/commands-posix.c
M scripts/checkpatch.pl
M system/qtest.c
Log Message:
-----------
Merge tag 'hw-misc-20251118' of https://github.com/philmd/qemu into staging
Misc HW patches
- Re-enable xenpvh machine in qemu-system-arm/aarch64 binaries
- Correct Xilinx Zynq DMA Devcfg registers range size
- Correct ACCEL_KERNEL_GSI_IRQFD_POSSIBLE typo
- Allow for multiple CHR_EVENT_CLOSED events in QTest framework
- Fix ACMD41 state machine for SD cards in SPI mode
- Avoid confusing address calculation around eMMC RPMB HMAC
- Fix a pair of build failures on Solaris (guest-agent and RDMA migration)
- Correct QOM parent of LASI south bridge
- Clarify MIPS / PPC 32-bit hosts removal in documentation
- Prevent further uses of DEVICE_NATIVE_ENDIAN definition
- Fix Error uses in eBPF
- Update David Hildenbrand's email address
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmkcwjAACgkQ4+MsLN6t
# wN7Wxg//UMbpEgp92clPcGUX1RFHViEYu5DDM96nwjLpOR8nNAJvLZ5+qxDfyZRQ
# qfVGaE0cm5a/rXRMgFAzeJw5ptcSwLJXsUvnRuNLEpKlIAfqInqqk+JTi/r7hJSq
# W8m07IrdtADwoas0OYKur0XwF+k1hqVOENQWPxiLiyViEH2tR8MFA+nrqQhZzgwo
# Emu3ICc01wX+hhY2R51mf+GdVcmr8RACc07lmG7MnMtvQW8vzCkA/VJ5jWWQv6Xj
# ADKBTciYEK/PKD5vbbwMadZfxaWRiH1l+unfpw0qXC46YOAMvpe3+0mRqk7VeSRc
# anqdXQk9dbqw7qwJ+L+RVdUjNf1bLc9LxOePeMOgsNzd8wxlsBia9PDNxvVTRFmh
# /JxLYO9bM4vRojaGOCFoppoF++JSdZzI6WM56hY465L3VCx36V1p2YESX8x/5F1B
# +w/JPV0dUGeq+MFUNKg/pBy9dgRYIGJfcbcp2jwMxyEB5d0np53zXbMaZmqX/cEO
# AjE/haqtpu/yAqSK7oklx1gJEI9gRE0cJp2B/7l/3RwW3fcMsN3HJB3GH8f+3vg2
# VQMYDrAWBF5wA/5HQtsGNrfImlYGHa535KnLujTcNLVwS+2gZ6N6FwfwhM2fwXQh
# +X7nQZbBsAVa0jDqck8zkIarVuISocC10DWfuP5k4hlKxeyg71M=
# =K5DF
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 18 Nov 2025 08:00:00 PM CET
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <[email protected]>"
[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-20251118' of https://github.com/philmd/qemu:
ebpf: Make ebpf_rss_load() return value consistent with @errp
ebpf: Clean up useless error check in ebpf_rss_set_all()
ebpf: Fix stubs to set an error when they return failure
scripts/checkpatch: Check DEVICE_NATIVE_ENDIAN
docs: Mention 32-bit PPC host as removed
docs: Correct release of MIPS deprecations / removals
migration/rdma: Check ntohll() availability with meson
buildsys: Remove dead 'mips' entry in supported_cpus[] array
hw/southbridge/lasi: Correct LasiState parent
qga/commands: Include proper Solaris header for getloadavg()
hw/sd/sdcard: Avoid confusing address calculation in rpmb_calc_hmac
hw/arm: Re-enable xenpvh machine in qemu-system-arm/aarch64 binaries
hw/dma/zynq-devcfg: Fix register memory
hw/sd: Fix ACMD41 state machine in SPI mode
hw/sd: Fix incorrect idle state reporting in R1 response for SPI mode
system/qtest.c: Allow for multiple CHR_EVENT_CLOSED events
hw/intc/ioapic: Fix ACCEL_KERNEL_GSI_IRQFD_POSSIBLE typo
MAINTAINERS: Update David Hildenbrand's email address
Signed-off-by: Richard Henderson <[email protected]>
Compare: https://github.com/qemu/qemu/compare/711a1ddf899b...5e0242e9a847
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
