Update qemu to v10.2.0 #123
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This patch is pure refactoring: instead of hard-coding permission to use a protocol prefix when creating an image, the drivers can now pass in a parameter, comparable to what they could already do for opening a pre-existing image. This patch is purely mechanical (all drivers pass in true for now), but it will enable the next patch to cater to drivers that want to differ in behavior for the primary image vs. any secondary images that are opened at the same time as creating the primary image. Signed-off-by: Eric Blake <[email protected]> Message-ID: <[email protected]> Reviewed-by: Kevin Wolf <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>
Ever since CVE-2024-4467 (see commit 7ead946 in qemu v9.1.0), we have intentionally treated the opening of secondary files whose name is specified in the contents of the primary file, such as a qcow2 data_file, as something that must be a local file and not a protocol prefix (it is still possible to open a qcow2 file that wraps an NBD data image by using QMP commands, but that is from the explicit action of the QMP overriding any string encoded in the qcow2 file). At the time, we did not prevent the use of protocol prefixes on the secondary image while creating a qcow2 file, but it results in a qcow2 file that records an empty string for the data_file, rather than the protocol passed in during creation: $ qemu-img create -f raw datastore.raw 2G $ qemu-nbd -e 0 -t -f raw datastore.raw & $ qemu-img create -f qcow2 -o data_file=nbd://localhost:10809/ \ datastore_nbd.qcow2 2G Formatting 'datastore_nbd.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=2147483648 data_file=nbd://localhost:10809/ lazy_refcounts=off refcount_bits=16 $ qemu-img info datastore_nbd.qcow2 | grep data $ qemu-img info datastore_nbd.qcow2 | grep data image: datastore_nbd.qcow2 data file: data file raw: false filename: datastore_nbd.qcow2 And since an empty string was recorded in the file, attempting to open the image without using QMP to supply the NBD data store fails, with a somewhat confusing error message: $ qemu-io -f qcow2 datastore_nbd.qcow2 qemu-io: can't open device datastore_nbd.qcow2: The 'file' block driver requires a file name Although the ability to create an image with a convenience reference to a protocol data file is not a security hole (unlike the case with open, the image is not untrusted if we are the ones creating it), the above demo shows that it is still inconsistent. Thus, it makes more sense if we also insist that image creation rejects a protocol prefix when using the same syntax. Now, the above attempt produces: $ qemu-img create -f qcow2 -o data_file=nbd://localhost:10809/ \ datastore_nbd.qcow2 2G Formatting 'datastore_nbd.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=2147483648 data_file=nbd://localhost:10809/ lazy_refcounts=off refcount_bits=16 qemu-img: datastore_nbd.qcow2: Could not create 'nbd://localhost:10809/': No such file or directory with datastore_nbd.qcow2 no longer created. Signed-off-by: Eric Blake <[email protected]> Message-ID: <[email protected]> Reviewed-by: Kevin Wolf <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>
During a rebase operation data is copied from the backing chain into the target image using a loop, and each iteration looks for a contiguous region of allocated data of at most IO_BUF_SIZE (2 MB). Once that region is found, and in order to avoid partial writes, its boundaries are extended so they are aligned to the (sub)clusters of the target image (see commit 12df580). This operation can however result in a region that exceeds the maximum allowed IO_BUF_SIZE, crashing qemu-img. This can be easily reproduced when the source image has a smaller cluster size than the target image: base <- int <- active $ qemu-img create -f qcow2 base.qcow2 4M $ qemu-img create -f qcow2 -F qcow2 -b base.qcow2 -o cluster_size=1M int.qcow2 $ qemu-img create -f qcow2 -F qcow2 -b int.qcow2 -o cluster_size=2M active.qcow2 $ qemu-io -c "write -P 0xff 1M 2M" int.qcow2 $ qemu-img rebase -F qcow2 -b base.qcow2 active.qcow2 qemu-img: qemu-img.c:4102: img_rebase: Assertion `written + pnum <= IO_BUF_SIZE' failed. Aborted Cc: qemu-stable <[email protected]> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3174 Fixes: 12df580 ("qemu-img: rebase: avoid unnecessary COW operations") Signed-off-by: Alberto Garcia <[email protected]> Message-ID: <[email protected]> Reviewed-by: Kevin Wolf <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>
Block layer patches - stream: Fix potential crash during job completion - aio: add the aio_add_sqe() io_uring API - qcow2: put discards in discard queue when discard-no-unref is enabled - qcow2, vmdk: Restrict creation with secondary file using protocol - qemu-img rebase: Fix assertion failure due to exceeding IO_BUF_SIZE - iotests: Run iotests with sanitizers - iotests: Add more image formats to the thorough testing - iotests: Improve the dry run list to speed up thorough testing - Code cleanup # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmkTqWcRHGt3b2xmQHJl # ZGhhdC5jb20ACgkQfwmycsiPL9awPg//VqEgqYbEr3dVUvBFk8tlcewoo7KGICVk # 4kddOwMJIdcsVpiLuNzqQARH2kHV93Hiv+mVt25o00PkJx565eCGTh/bBFas3UXL # JMBjgHyJutGr4cijkNrnQgqWfeTgc32xdVEWh1nZM2K7LslzC9I1PfUzfxRMYqZA # Em0KE3vwQDC7xtIyk4t451hkfcQY8fwN9bDMpD+zbzaLsYTEyOJ900En88iW7oHE # TuJhrviin11jdQCA26QVNXRaw7iIVVo8vJP1VEgbn31iY+Qpcr/HcQRs0x2gex67 # OqIdh4onqkdGCFDxTGUoAH+jORXWUmk/JipIhl9pJP0ZDyAjsm97ThJ6SvctURsK # UMU0dzXEc1C5spD2CWnN0PujqHYQqYaylx7MdiCJMjaCfDB3ZeIRsTGoiLMB24P+ # WBrcn2P+f03nC/sVvxRZWrpyI2kZwEh1RsO/mnLQ3apVBFeKqaFi8Ouo9oi1ZMd6 # ahUw7sZSoTxmGY1FhOSRCGEh2Wjy0ZIOx9tHT1U9vig5Kf9KeE81yO8yaq2T60mq # 9eaUL8rcUrKRiJw9NUkcEYmIUJrh0nUe/kK2RWmbEGMYIH7ASrGqiyUP5FxpekD+ # i/uen4BeyRwe6rnPOzGolg+HMysMBr8VD/8PwJ8g88FLH1jIdTYvFUdRbrkciUlo # okC+y4+kqiU= # =SI8s # -----END PGP SIGNATURE----- # gpg: Signature made Tue 11 Nov 2025 10:23:51 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: (28 commits) qemu-img rebase: don't exceed IO_BUF_SIZE in one operation qcow2, vmdk: Restrict creation with secondary file using protocol block: Allow drivers to control protocol prefix at creation tests/qemu-iotest: Add more image formats to the thorough testing tests/qemu-iotests: Improve the dry run list to speed up thorough testing tests/qemu-iotests/184: Fix skip message for qemu-img without throttle qcow2: put discards in discard queue when discard-no-unref is enabled qcow2: rename update_refcount_discard to queue_discard iotests: Run iotests with sanitizers qemu-img: Fix amend option parse error handling iotests: Test resizing file node under raw with size/offset block: Drop detach_subchain for bdrv_replace_node block: replace TABs with space block/io_uring: use non-vectored read/write when possible block/io_uring: use aio_add_sqe() aio-posix: add aio_add_sqe() API for user-defined io_uring requests aio-posix: add fdmon_ops->dispatch() aio-posix: unindent fdmon_io_uring_destroy() aio-posix: gracefully handle io_uring_queue_init() failure aio: add errp argument to aio_context_setup() ... Signed-off-by: Richard Henderson <[email protected]>
Output files are not executables. Noticed while preparing another iotest addition. Fixes: c8f60bf ("iotests: Add `vvfat` tests", v9.1.0) Signed-off-by: Eric Blake <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]> Message-ID: <[email protected]>
Upcoming patches will adjust how net_listener watches for new client connections; adding trace points now makes it easier to debug that the changes work as intended. For example, adding --trace='qio_net_listener*' to the qemu-storage-daemon command line before --nbd-server will track when the server first starts listening for clients. Signed-off-by: Eric Blake <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]> Message-ID: <[email protected]>
When changing the callback registered with QIONetListener, the code was calling notify on the old opaque data prior to actually removing the old GSource objects still pointing to that data. Similarly, during finalize, it called notify before tearing down the various GSource objects tied to the data. In practice, a grep of the QEMU code base found that every existing client of QIONetListener passes in a NULL notifier (the opaque data, if non-NULL, outlives the NetListener and so does not need cleanup when the NetListener is torn down), so this patch has no impact. And even if a caller had passed in a reference-counted object with a notifier of object_unref but kept its own reference on the data, then the early notify would merely reduce a refcount from (say) 2 to 1, but not free the object. However, it is a latent bug waiting to bite any future caller that passes in data where the notifier actually frees the object, because the GSource could then trigger a use-after-free if it loses the race on a last-minute client connection resulting in the data being passed to one final use of the async callback. Better is to delay the notify call until after all GSource that have been given a copy of the opaque data are torn down. CC: [email protected] Fixes: 5304739 "io: introduce a network socket listener API", v2.12.0 Signed-off-by: Eric Blake <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]> Message-ID: <[email protected]>
io/net-listener.c has two modes of use: asynchronous (the user calls qio_net_listener_set_client_func to wake up the callback via the global GMainContext, or qio_net_listener_set_client_func_full to wake up the callback via the caller's own alternative GMainContext), and synchronous (the user calls qio_net_listener_wait_client which creates its own GMainContext and waits for the first client connection before returning, with no need for a user's callback). But commit 938c8b7 has a latent logic flaw: when qio_net_listener_wait_client finishes on its temporary context, it reverts all of the siocs back to the global GMainContext rather than the potentially non-NULL context they might have been originally registered with. Similarly, if the user creates a net-listener, adds initial addresses, registers an async callback with a non-default context (which ties to all siocs for the initial addresses), then adds more addresses with qio_net_listener_add, the siocs for later addresses are blindly placed in the global context, rather than sharing the context of the earlier ones. In practice, I don't think this has caused issues. As pointed out by the original commit, all async callers prior to that commit were already okay with the NULL default context; and the typical usage pattern is to first add ALL the addresses the listener will pay attention to before ever setting the async callback. Likewise, if a file uses only qio_net_listener_set_client_func instead of qio_net_listener_set_client_func_full, then it is never using a custom context, so later assignments of async callbacks will still be to the same global context as earlier ones. Meanwhile, any callers that want to do the sync operation to grab the first client are unlikely to register an async callback; altogether bypassing the question of whether later assignments of a GSource are being tied to a different context over time. I do note that chardev/char-socket.c is the only file that calls both qio_net_listener_wait_client (sync for a single client in tcp_chr_accept_server_sync), and qio_net_listener_set_client_func_full (several places, all with chr->gcontext, but sometimes with a NULL callback function during teardown). But as far as I can tell, the two uses are mutually exclusive, based on the is_waitconnect parameter to qmp_chardev_open_socket_server. That said, it is more robust to remember when an async callback function is tied to a non-default context, and have both the sync wait and any late address additions honor that same context. That way, the code will be robust even if a later user performs a sync wait for a specific client in the middle of servicing a longer-lived QIONetListener that has an async callback for all other clients. CC: [email protected] Fixes: 938c8b7 ("qio: store gsources for net listeners", v2.12.0) Signed-off-by: Eric Blake <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]> Message-ID: <[email protected]>
Without a mutex, NetListener can run into this data race between a
thread changing the async callback callback function to use when a
client connects, and the thread servicing polling of the listening
sockets:
Thread 1:
qio_net_listener_set_client_func(lstnr, f1, ...);
=> foreach sock: socket
=> object_ref(lstnr)
=> sock_src = qio_channel_socket_add_watch_source(sock, ...., lstnr, object_unref);
Thread 2:
poll()
=> event POLLIN on socket
=> ref(GSourceCallback)
=> if (lstnr->io_func) // while lstnr->io_func is f1
...interrupt..
Thread 1:
qio_net_listener_set_client_func(lstnr, f2, ...);
=> foreach sock: socket
=> g_source_unref(sock_src)
=> foreach sock: socket
=> object_ref(lstnr)
=> sock_src = qio_channel_socket_add_watch_source(sock, ...., lstnr, object_unref);
Thread 2:
=> call lstnr->io_func(lstnr->io_data) // now sees f2
=> return dispatch(sock)
=> unref(GSourceCallback)
=> destroy-notify
=> object_unref
Found by inspection; I did not spend the time trying to add sleeps or
execute under gdb to try and actually trigger the race in practice.
This is a SEGFAULT waiting to happen if f2 can become NULL because
thread 1 deregisters the user's callback while thread 2 is trying to
service the callback. Other messes are also theoretically possible,
such as running callback f1 with an opaque pointer that should only be
passed to f2 (if the client code were to use more than just a binary
choice between a single async function or NULL).
Mitigating factor: if the code that modifies the QIONetListener can
only be reached by the same thread that is executing the polling and
async callbacks, then we are not in a two-thread race documented above
(even though poll can see two clients trying to connect in the same
window of time, any changes made to the listener by the first async
callback will be completed before the thread moves on to the second
client). However, QEMU is complex enough that this is hard to
generically analyze. If QMP commands (like nbd-server-stop) are run
in the main loop and the listener uses the main loop, things should be
okay. But when a client uses an alternative GMainContext, or if
servicing a QMP command hands off to a coroutine to avoid blocking, I
am unable to state with certainty whether a given net listener can be
modified by a thread different from the polling thread running
callbacks.
At any rate, it is worth having the API be robust. To ensure that
modifying a NetListener can be safely done from any thread, add a
mutex that guarantees atomicity to all members of a listener object
related to callbacks. This problem has been present since
QIONetListener was introduced.
Note that this does NOT prevent the case of a second round of the
user's old async callback being invoked with the old opaque data, even
when the user has already tried to change the async callback during
the first async callback; it is only about ensuring that there is no
sharding (the eventual io_func(io_data) call that does get made will
correspond to a particular combination that the user had requested at
some point in time, and not be sharded to a combination that never
existed in practice). In other words, this patch maintains the status
quo that a user's async callback function already needs to be robust
to parallel clients landing in the same window of poll servicing, even
when only one client is desired, if that particular listener can be
amended in a thread other than the one doing the polling.
CC: [email protected]
Fixes: 5304739 ("io: introduce a network socket listener API", v2.12.0)
Signed-off-by: Eric Blake <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
[eblake: minor commit message wording improvements]
Signed-off-by: Eric Blake <[email protected]>
In qemu-nbd and other NBD server setups where parallel clients are supported, it is common that the caller will re-register the same callback function as long as it has not reached its limit on simultaneous clients. In that case, there is no need to tear down and reinstall GSource watches in the GMainContext. In practice, all existing callers currently pass NULL for notify, and no caller ever changes context across calls (for async uses, either the caller consistently uses qio_net_listener_set_client_func_full with the same context, or the caller consistently uses only qio_net_listener_set_client_func which always uses the global context); but the time spent checking these two fields in addition to the more important func and data is still less than the savings of not churning through extra GSource manipulations when the result will be unchanged. Signed-off-by: Eric Blake <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]> Message-ID: <[email protected]>
The code had three similar repetitions of an iteration over one or all of nsiocs to set up a GSource, and likewise for teardown. Since an upcoming patch wants to tweak whether GSource or AioContext is used, it's better to consolidate that into one helper function for fewer places to edit later. Signed-off-by: Eric Blake <[email protected]> Message-ID: <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
Directly accessing the fd member of a QIOChannelSocket is an undesirable leaky abstraction. What's more, grabbing that fd merely to force an eventual call to getsockname() can be wasteful, since the channel is often able to return its cached local name. Reported-by: Daniel P. Berrangé <[email protected]> Signed-off-by: Eric Blake <[email protected]> Message-ID: <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
An upcoming patch needs to pass more than just sioc as the opaque pointer to an AioContext; but since our AioContext code in general (and its QIO Channel wrapper code) lacks a notify callback present with GSource, we do not have the trivial option of just g_malloc'ing a small struct to hold all that data coupled with a notify of g_free. Instead, the data pointer must outlive the registered handler; in fact, having the data pointer have the same lifetime as QIONetListener is adequate. But the cleanest way to stick such a helper struct in QIONetListener will be to rearrange internal struct members. And that in turn means that all existing code that currently directly accesses listener->nsioc and listener->sioc[] should instead go through accessor functions, to be immune to the upcoming struct layout changes. So this patch adds accessor methods qio_net_listener_nsioc() and qio_net_listener_sioc(), and puts them to use. While at it, notice that the pattern of grabbing an sioc from the listener only to turn around can call qio_channel_socket_get_local_address is common enough to also warrant the helper of qio_net_listener_get_local_address, and fix a copy-paste error in the corresponding documentation. Signed-off-by: Eric Blake <[email protected]> Message-ID: <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
For ease of review, this patch adds an AioContext pointer to the QIONetListener struct, the code to trace it, and refactors listener->io_source to instead be an array of utility structs; but the aio_context pointer is always NULL until the next patch adds an API to set it. There should be no semantic change in this patch. Signed-off-by: Eric Blake <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]> Message-ID: <[email protected]>
The user calling himself "John Doe" reported a deadlock when attempting to use qemu-storage-daemon to serve both a base file over NBD, and a qcow2 file with that NBD export as its backing file, from the same process, even though it worked just fine when there were two q-s-d processes. The bulk of the NBD server code properly uses coroutines to make progress in an event-driven manner, but the code for spawning a new coroutine at the point when listen(2) detects a new client was hard-coded to use the global GMainContext; in other words, the callback that triggers nbd_client_new to let the server start the negotiation sequence with the client requires the main loop to be making progress. However, the code for bdrv_open of a qcow2 image with an NBD backing file uses an AIO_WAIT_WHILE nested event loop to ensure that the entire qcow2 backing chain is either fully loaded or rejected, without any side effects from the main loop causing unwanted changes to the disk being loaded (in short, an AioContext represents the set of actions that are known to be safe while handling block layer I/O, while excluding any other pending actions in the global main loop with potentially larger risk of unwanted side effects). This creates a classic case of deadlock: the server can't progress to the point of accept(2)ing the client to write to the NBD socket because the main loop is being starved until the AIO_WAIT_WHILE completes the bdrv_open, but the AIO_WAIT_WHILE can't progress because it is blocked on the client coroutine stuck in a read() of the expected magic number from the server side of the socket. This patch adds a new API to allow clients to opt in to listening via an AioContext rather than a GMainContext. This will allow NBD to fix the deadlock by performing all actions during bdrv_open in the main loop AioContext. Technical debt warning: I would have loved to utilize a notify function with AioContext to guarantee that we don't finalize listener due to an object_unref if there is any callback still running (the way GSource does), but wiring up notify functions into AioContext is a bigger task that will be deferred to a later QEMU release. But for solving the NBD deadlock, it is sufficient to note that the QMP commands for enabling and disabling the NBD server are really the only points where we want to change the listener's callback. Furthermore, those commands are serviced in the main loop, which is the same AioContext that is also listening for connections. Since a thread cannot interrupt itself, we are ensured that at the point where we are changing the watch, there are no callbacks active. This is NOT as powerful as the GSource cross-thread safety, but sufficient for the needs of today. An upcoming patch will then add a unit test (kept separate to make it easier to rearrange the series to demonstrate the deadlock without this patch). Fixes: https://gitlab.com/qemu-project/qemu/-/issues/3169 Signed-off-by: Eric Blake <[email protected]> Message-ID: <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
See the previous patch for a longer description of the deadlock. Now that QIONetListener supports waiting for clients in the main loop AioContext, NBD can use that to ensure that the server can make progress even when a client is intentionally starving the GMainContext from any activity not tied to an AioContext. Note that command-line arguments and QMP commands like nbd-server-start or nbd-server-stop that manipulate whether the NBD server exists are serviced in the main loop; and therefore, this patch does not fall foul of the restrictions in the previous patch about the inherent unsafe race possible if a QIONetListener can have its async callback modified by a different thread than the one servicing polls. Fixes: https://gitlab.com/qemu-project/qemu/-/issues/3169 Signed-off-by: Eric Blake <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]> Message-ID: <[email protected]>
Test that all images in a qcow2 chain using an NBD backing file can be
served by the same process. Prior to the recent QIONetListener fixes,
this test would demonstrate deadlock.
The test borrows heavily from the original formula by "John Doe" in
the gitlab bug, but uses a Unix socket rather than TCP to avoid port
contention, and uses a full-blown QEMU rather than qemu-storage-daemon
since both programs were impacted.
The test starts out with the even simpler task of directly adding an
NBD client without qcow2 chain ('client'), which also provokes the
deadlock; but commenting out the 'Adding explicit NBD client' section
will still show deadlock when reaching the 'Adding wrapper image...'.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/3169
Signed-off-by: Eric Blake <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Message-ID: <[email protected]>
Running "./check -ssh 207" fails for me with lots of lines like this in the output: +base64: invalid input While looking closer at it, I noticed that the grep -v "\\^#" command in this test is not working as expected - it is likely meant to filter out the comment lines that are starting with a "#", but at least my version of grep (GNU grep 3.11) does not work with the backslashes here. There does not seem to be a compelling reason for these backslashes, so let's simply drop them to fix this issue. Signed-off-by: Thomas Huth <[email protected]> Message-ID: <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]> Signed-off-by: Eric Blake <[email protected]>
Use 'qemu-io -c map' instead of 'qemu-img map' to get an output that works with both image types. Cc: qemu-stable <[email protected]> Fixes: 909852b ("qemu-img rebase: don't exceed IO_BUF_SIZE in one operation") Signed-off-by: Alberto Garcia <[email protected]> Message-ID: <[email protected]> Reviewed-by: Eric Blake <[email protected]> Tested-by: Thomas Huth <[email protected]> Signed-off-by: Eric Blake <[email protected]>
Makes the net_hub_port_cleanup function idempotent to avoid double removals by guarding its QLIST_REMOVE with a flag. When using a Xen networking device with hubport backends, e.g.: -accel kvm,xen-version=0x40011 -netdev hubport,... -device xen-net-device,... the shutdown order starts with net_cleanup, which walks the list and deletes netdevs (including hubports). Then Xen's xen_device_unrealize is called, which eventually leads to a second net_hub_port_cleanup call, resulting in a segfault. Fixes: e7891c5 ("net: move backend cleanup to NIC cleanup") Reported-by: David Woodhouse <[email protected]> Signed-off-by: Jonah Palmer <[email protected]> Signed-off-by: Jason Wang <[email protected]>
…riptors In e1000e_write_packet_to_guest() we don't write data for RX descriptors where the buffer address is NULL (as required by the i82574 datasheet section 7.1.7.2). However, when we do this we still update desc_offset by the amount of data we would have written to the RX descriptor if it had a valid buffer pointer, resulting in our dropping that data entirely. The data sheet is not 100% clear on the subject, but this seems unlikely to be the correct behaviour. Rearrange the null-descriptor logic so that we don't treat these do-nothing descriptors as if we'd really written the data. This both fixes a bug and also is a prerequisite to cleaning up the size calculation logic in the next patch. (Cc to stable largely because it will be needed for the next patch, which fixes a more serious bug.) Cc: [email protected] Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Akihiko Odaki <[email protected]> Signed-off-by: Jason Wang <[email protected]>
In e1000e_write_packet_to_guest() we attempt to ensure that we don't write more of a packet to a descriptor than will fit in the guest configured receive buffers. However, this code does not allow for the "packet split" feature. When packet splitting is enabled, the first of up to 4 buffers in the descriptor is used for the packet header only, with the payload going into buffers 2, 3 and 4. Our length check only checks against the total sizes of all 4 buffers, which meant that if an incoming packet was large enough to fit in (1 + 2 + 3 + 4) but not into (2 + 3 + 4) and packet splitting was enabled, we would run into the assertion in e1000e_write_hdr_frag_to_rx_buffers() that we had enough buffers for the data: qemu-system-i386: ../../hw/net/e1000e_core.c:1418: void e1000e_write_payload_frag_to_rx_buffers(E1000ECore *, hwaddr *, E1000EBAState *, const char *, dma_addr_t): Assertion `bastate->cur_idx < MAX_PS_BUFFERS' failed. A malicious guest could provoke this assertion by configuring the device into loopback mode, and then sending itself a suitably sized packet into a suitably arrange rx descriptor. The code also fails to deal with the possibility that the descriptor buffers are sized such that the trailing checksum word does not fit into the last descriptor which has actual data, which might also trigger this assertion. Rework the length handling to use two variables: * desc_size is the total amount of data DMA'd to the guest for the descriptor being processed in this iteration of the loop * rx_desc_buf_size is the total amount of space left in it As we copy data to the guest (packet header, payload, checksum), update these two variables. (Previously we attempted to calculate desc_size once at the top of the loop, but this is too difficult to do correctly.) Then we can use the variables to ensure that we clamp the amount of copied payload data to the remaining space in the descriptor's buffers, even if we've used one of the buffers up in the packet-split code, and we can tell whether we have enough space for the full checksum word in this descriptor or whether we're going to need to split that to the following descriptor. I have included comments that hopefully help to make the loop logic a little clearer. Cc: [email protected] Resolves: https://gitlab.com/qemu-project/qemu/-/issues/537 Reviewed-by: Akihiko Odaki <[email protected]> Signed-off-by: Peter Maydell <[email protected]> Signed-off-by: Jason Wang <[email protected]>
…assert An assertion in e1000e_write_payload_frag_to_rx_buffers() attempts to guard against the calling code accidentally trying to write too much data to a single RX descriptor, such that the E1000EBAState::cur_idx indexes off the end of the EB1000BAState::written[] array. Unfortunately it is overzealous: it asserts that cur_idx is in range after it has been incremented. This will fire incorrectly for the case where the guest configures four buffers and exactly enough bytes are written to fill all four of them. The only places where we use cur_idx and index in to the written[] array are the functions e1000e_write_hdr_frag_to_rx_buffers() and e1000e_write_payload_frag_to_rx_buffers(), so we can rewrite this to assert before doing the array dereference, rather than asserting after updating cur_idx. Cc: [email protected] Reviewed-by: Akihiko Odaki <[email protected]> Signed-off-by: Peter Maydell <[email protected]> Signed-off-by: Jason Wang <[email protected]>
In commits like 969e50b ("net: Pad short frames to minimum size before sending from SLiRP/TAP") we switched away from requiring network devices to handle short frames to instead having the net core code do the padding of short frames out to the ETH_ZLEN minimum size. We then dropped the code for handling short frames from the network devices in a series of commits like 140eae9 ("hw/net: e1000: Remove the logic of padding short frames in the receive path"). This missed one route where the device's receive code can still see a short frame: if the device is in loopback mode and it transmits a short frame via the qemu_receive_packet() function, this will be fed back into its own receive code without being padded. Add the padding logic to qemu_receive_packet(). This fixes a buffer overrun which can be triggered in the e1000_receive_iov() logic via the loopback code path. Other devices that use qemu_receive_packet() to implement loopback are cadence_gem, dp8393x, lan9118, msf2-emac, pcnet, rtl8139 and sungem. Cc: [email protected] Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3043 Reviewed-by: Akihiko Odaki <[email protected]> Signed-off-by: Peter Maydell <[email protected]> Signed-off-by: Jason Wang <[email protected]>
From Pedro Barbuda (on Teams): > we meant to have that switched a while back. you can add me as the maintainer. Pedro Barbuda ([email protected]) Signed-off-by: Mohamed Mediouni <[email protected]> Message-id: [email protected] Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>
Currently an unpredictable movw such as movw pc, 0x123 results in the tinycode and_i32 $0x123,$0x123,$0xfffffffc mov_i32 pc,$0x123 exit_tb $0x0 which is clearly a bug: writing to a constant is incorrect and discards the result of the mask. Fix this by always doing an and_i32 and trusting the optimizer to turn this into a simple move when the mask is zero. Signed-off-by: Anton Johansson <[email protected]> Signed-off-by: Richard Henderson <[email protected]> Tested-by: Gustavo Romero <[email protected]> Reviewed-by: <[email protected]> Message-id: [email protected] [rth: Avoid an extra temp and extra move.] Signed-off-by: Richard Henderson <[email protected]> [PMM: commit message tweak] Signed-off-by: Peter Maydell <[email protected]>
cpregs.h is included twice. Signed-off-by: Osama Abdelkader <[email protected]> Reviewed-by: Alex Bennée <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]>
The documentation of the Xilinx DisplayPort subsystem at https://www.xilinx.com/support/documents/ip_documentation/v_dp_txss1/v3_1/pg299-v-dp-txss1.pdf doesn't say what happens if a guest tries to issue an AUX write command with a length greater than the amount of data in the AUX write FIFO, or tries to write more data to the write FIFO than it can hold, or issues multiple commands that put data into the AUX read FIFO without reading it such that it overflows. Currently QEMU will abort() in these guest-error situations, either in xlnx_dp.c itself or in the fifo8 code. Make these cases all be logged as guest errors instead. We choose to ignore the new data on overflow, and return 0 on underflow. This is in line with how we handled the "read from empty RX FIFO" case in commit a09ef50. Cc: [email protected] Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1418 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1419 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1424 Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Edgar E. Iglesias <[email protected]> Message-id: [email protected]
If the guest writes an invalid or unsupported value to the AV_BUF_FORMAT register, currently we abort(). Instead, log this as either a guest error or an unimplemented error and continue. The existing code treats DP_NL_VID_CB_Y0_CR_Y1 as x8b8g8r8 via a "case 0" that does not use the enum constant name for some reason; we leave that alone beyond adding a comment about the weird code. Documentation of this register seems to be at: https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/AV_BUF_FORMAT-DISPLAY_PORT-Register Cc: [email protected] Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1415 Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Edgar E. Iglesias <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected]
This commit was created with scripts/clean-includes: ./scripts/clean-includes --git cxl hw/cxl hw/mem All .c should include qemu/osdep.h first. The script performs three related cleanups: * Ensure .c files include qemu/osdep.h first. * Including it in a .h is redundant, since the .c already includes it. Drop such inclusions. * Likewise, including headers qemu/osdep.h includes is redundant. Drop these, too. Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Acked-by: Jonathan Cameron <[email protected]> Message-id: [email protected]
Correct comment typo in xen_9pfs_bh() Signed-off-by: Alano Song <[email protected]> Reviewed-by: Christian Schoenebeck <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Message-ID: <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
sys.stderr.print is dropped long ago and should not be used. Official replacement is sys.stderr.write The problem has been found debugging building on some fancy platform derived from Debian. Signed-off-by: Denis V. Lunev <[email protected]> CC: John Snow <[email protected]> CC: Cleber Rosa <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-ID: <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
vhost_virtqueue_start() can exit early if the descriptor ring address is 0, assuming the virtqueue isn’t ready to start. In this case, all cached vring information (size, physical address, pointer) is left as-is. This is OK at first startup, when that info is still initialized to 0, but after a reset, it will retain old (outdated) information. vhost_virtqueue_start() must make sure these values are (re-)set properly before exiting. (When using an IOMMU, these outdated values can stall the device: vhost_dev_start() deliberately produces an IOMMU miss event for each used vring. If used_phys contains an outdated value, the resulting lookup may fail, forcing the device to be stopped.) Cc: [email protected] Signed-off-by: Hanna Czenczek <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-ID: <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
This fixes a compiler error when higher warning levels are enabled:
../migration/postcopy-ram.c: In function ‘postcopy_temp_pages_setup’:
../migration/postcopy-ram.c:1483:50: error: ‘g_malloc0_n’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
1483 | mis->postcopy_tmp_pages = g_malloc0_n(sizeof(PostcopyTmpPage), channels);
| ^~~~~~~~~~~~~~~
../migration/postcopy-ram.c:1483:50: note: earlier argument should specify number of elements, later size of each element
Avoid also a related int/unsigned mismatch by fixing the type of
two local variables.
Signed-off-by: Stefan Weil <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
[PMD: Replace g_malloc0_n() by g_new0()]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Acked-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Stefan Weil <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Laurent Vivier <[email protected]> Message-ID: <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
This fixes some settings like the default installation path for the QEMU installation on Windows on ARM (WoA). Signed-off-by: Stefan Weil <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-ID: <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'.
This breaks the build in various files with errors such as :
error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
208 | char *pidstr = strstr(filename, "%");
| ^~~~~~
Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Signed-off-by: Cédric Le Goater <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Next commit will re-use VMSTATE_BUFFER_POINTER_UNSAFE(). This reverts commit 5834115. Suggested-by: Fiona Ebner <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
… pointer" Per https://lore.kernel.org/qemu-devel/[email protected]/: Loading a VM state taken with v10.1.2 or older doesn't work anymore, using the script [*] we get: kvm: VQ 1 size 0x100 < last_avail_idx 0x9 - used_idx 0x3e30 kvm: load of migration failed: Operation not permitted: error while loading state for instance 0x0 of device '0000:00:13.0/virtio-net': Failed to load element of type virtio for virtio: -1 qemu-system-x86_64: Missing section footer for 0000:00:13.0/virtio-net qemu-system-x86_64: Section footer error, section_id: 41 [*]: #!/bin/bash rm /tmp/disk.qcow2 args=" -netdev type=tap,id=net1,ifname=tap104i1,script=/usr/libexec/qemu-server/pve-bridge,downscript=/usr/libexec/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=BC:24:11:32:3C:69,netdev=net1,bus=pci.0,addr=0x13,id=net1 -machine type=pc-i440fx-10.1 " $1/qemu-img create -f qcow2 /tmp/disk.qcow2 1G $1/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args <<EOF {"execute": "qmp_capabilities"} {"execute": "snapshot-save", "arguments": { "job-id": "save0", "tag": "snap", "vmstate": "node0", "devices": ["node0"] } } {"execute": "quit"} EOF $2/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args -loadvm snap This reverts commit 3a9cd2a. Reported-by: Fiona Ebner <[email protected]> Suggested-by: Fiona Ebner <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
…taging Misc HW / migration / typo fixes # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmk4gN0ACgkQ4+MsLN6t # wN6wPw/9EiBPEumIFhsGQZdB4pZZBgjBgOilkazeVaitWwfjhZGWTB6l5O0+aEmH # jCeK2AAUZEashB/CrGI9irQ8Zli/CGgzV8/pF25AHDnDFyhCwR2czxeVDiZtMmcE # tOYfjqs57/85r0OiQHHzqgp7w25p/p0Toz5g9GR+7Wu8xFi5SkHVM2gblSViz9ks # JY+RLnQN4KKessqFKwGJb/m6cnBUWTf3DCscD/j+Crb9OI3WQpz2DsbQaZ06NHR7 # hlPzQ05taMhIqh6OdRAGqGS7Mud+eQ58k9qkYGuSBUkuBoJ/3/EqHJXQ4blZt9IN # reJ6EtN+xYTT+BGBhIXmAtIVERzyk1MF99hgUZJW0RDuE4Ioa7Omp5bnv82Yensz # UledFAMrGpX25SlJG2oNGnqZTYnCYoQnRQTB90AlaluJqHSpSgBBoJyfukjKQDVa # NmL+sJOthonvGsydJP8IYfmcBUC1AzmXFxzN+/xZOSJe1qmSh1kUaehsbyytdd/C # tgyav8DsvxXR8rfYBX5bSml8pAKL5pSD0DYJD3LCyvRoC0SnYROFU1kaUfMpPA+/ # H1r0RO5Lzkcub1JW253gA89GfrK0Y7ShMtoJ+GBivH/cK+ZYT4uEAZajcgUi5kJJ # FSWz/sNxOJ03s3CWQhlPOEnkLQ41/1+eqbLpmWceRIAfOmmXE00= # =vcUd # -----END PGP SIGNATURE----- # gpg: Signature made Tue 09 Dec 2025 02:04:45 PM CST # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <[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-20251209' of https://github.com/philmd/qemu: Revert "hw/net/virtio-net: make VirtIONet.vlans an array instead of a pointer" Revert "migration/vmstate: remove VMSTATE_BUFFER_POINTER_UNSAFE macro" Fix const qualifier build errors with recent glibc scripts/nsis.py: Tell makensis that WoA is 64 bit hw/pci: Fix typo in documentation migration: Fix order of function arguments vhost: Always initialize cached vring data scripts: fix broken error path in modinfo-collect.py hw/9pfs: Correct typo osdep: Undefine FSCALE definition to fix Solaris builds Signed-off-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Looks like the "$" has been forgotten here to get the contents of the FILENAME variable. Fixes: c49dda7 ("iotests: Filter out ZFS in several tests") Signed-off-by: Thomas Huth <[email protected]> Message-ID: <[email protected]> Reviewed-by: Laurent Vivier <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Kevin Wolf <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>
This reverts commit 0f142cb. Said commit changed the replay_bh_schedule_oneshot_event() in nvme_rw_cb() to aio_co_wake(), allowing the request coroutine to be entered directly (instead of only being scheduled for later execution). This can cause the device to become stalled like so: It is possible that after completion the request coroutine goes on to submit another request without yielding, e.g. a flush after a write to emulate FUA. This will likely cause a nested nvme_process_completion() call because nvme_rw_cb() itself is called from there. (After submitting a request, we invoke nvme_process_completion() through defer_call(); but the fact that nvme_process_completion() ran in the first place indicates that we are not in a call-deferring section, so defer_call() will call nvme_process_completion() immediately.) If this inner nvme_process_completion() loop then processes any completions, it will write the final completion queue (CQ) head index to the CQ head doorbell, and subsequently execution will return to the outer nvme_process_completion() loop. Even if this loop now finds no further completions, it still processed at least one completion before, or it would not have called the nvme_rw_cb() which led to nesting. Therefore, it will now write the exact same CQ head index value to the doorbell, which effectively is an unrecoverable error[1]. Therefore, nesting of nvme_process_completion() does not work at this point. Reverting said commit removes the nesting (by scheduling the request coroutine instead of entering it immediately), and so fixes the stall. On the downside, reverting said commit breaks multiqueue for nvme, but better to have single-queue working than neither. For 11.0, we will have a solution that makes both work. A side note: There is a comment in nvme_process_completion() above qemu_bh_schedule() that claims nesting works, as long as it is done through the completion_bh. I am quite sure that is not true, for two reasons: - The problem described above, which is even worse when going through nvme_process_completion_bh() because that function unconditionally writes to the CQ head doorbell, - nvme_process_completion_bh() never takes q->lock, so nvme_process_completion() unlocking it will likely abort. Given the lack of reports of such aborts, I believe that completion_bh simply is unused in practice. [1] See the NVMe Base Specification revision 2.3, page 180, figure 152: “Invalid Doorbell Write Value: A host attempted to write an invalid doorbell value. Some possible causes of this error are: [...] the value written is the same as the previously written doorbell value.” To even be notified of this error, we would need to send an Asynchronous Event Request to the admin queue (p. 178ff), which we don’t do, and then to handle it, we would need to delete and recreate the queue (p. 88, section 3.3.1.2 Queue Usage). Cc: [email protected] Reported-by: Lukáš Doktor <[email protected]> Tested-by: Lukáš Doktor <[email protected]> Signed-off-by: Hanna Czenczek <[email protected]> Message-id: [email protected] Signed-off-by: Stefan Hajnoczi <[email protected]>
During shutdown, blockdev_close_all_bdrv_states() drops any block node references that are still owned by the monitor (i.e. the user). However, in doing so, it forgot to also remove the node from monitor_bdrv_states (which qmp_blockdev_del() correctly does), which means that later calls of bdrv_first()/bdrv_next() will still return the (now stale) pointer to the node. Usually there is no such call after this point, but in some cases it can happen. In the reported case, there was an ongoing migration, and the migration thread wasn't shut down yet: migration_shutdown() called by qemu_cleanup() doesn't actually wait for the migration to be shut down, but may just move it to MIGRATION_STATUS_CANCELLING. The next time migration_iteration_finish() runs, it sees the status and tries to re-activate all block devices that migration may have previously inactivated. This is where bdrv_first()/bdrv_next() get called and the access to the already freed node happens. It is debatable if migration_shutdown() should really return before migration has settled, but leaving a dangling pointer in the list of monitor-owned block nodes is clearly a bug either way and fixing it solves the immediate problem, so fix it. Cc: [email protected] Reported-by: Thomas Huth <[email protected]> Signed-off-by: Kevin Wolf <[email protected]> Message-ID: <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Tested-by: Thomas Huth <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>
…to staging Pull request - Hanna's fix a regression that hangs the userspace NVMe block driver. # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmlAIbcACgkQnKSrs4Gr # c8iuqgf/VV2OPXW2t56uzuUmf+220pnRAaaGLw7atuWmaRJQ8/tHZU23Vxbu7JtX # ZLJfObJaoGHpCeWCFJ3RccsPabf19hsDIJyki9U6f2+B+OutWLlmcp2uLtQJ8FNw # 2jMYSuT6XsCnm6VF3UIegDBTh6lvjyjDUVNAsWeiV6wHE61Oj3RD4joif52hx5uE # xcDPii9fiF8S9tD3CKDGxR8fw7olFXiG2ojxqRZklZuHM6SfFHespWeTr9voLfgL # maBJO3qyS6YFH1mFuIJvvCykGN2EI6tT1nlQw8et3oUGF+GN45yqLcK12/b7lWKF # jTE8RCPCswFD4FF3eXJpcZRysi988A== # =Jx5T # -----END PGP SIGNATURE----- # gpg: Signature made Tue 16 Dec 2025 01:56:55 AM AEDT # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <[email protected]>" [unknown] # gpg: aka "Stefan Hajnoczi <[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: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * tag 'block-pull-request' of https://gitlab.com/stefanha/qemu: Revert "nvme: Fix coroutine waking" Signed-off-by: Richard Henderson <[email protected]>
Block layer patches - Fix crash due to BDS use after free during shutdown (in particular while migration is running) - iotests: Fix a typo that made a check to prevent overwriting a file ineffective # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmlAQOARHGt3b2xmQHJl # ZGhhdC5jb20ACgkQfwmycsiPL9YNCBAAqoWuOIdybhv44cLtrl3DZWHZnt1XbYvT # xSUWI9fQQM6WLI1gAHXzl4awsTz0yZzc7KSyYPXdoub3A5D2LoFl4kJKXDzubAwr # YP1Zmg6UWfaKfxkM42FV07xV8K4kvD11jMTimuYql6uFpzXZILwIPjl10ifdjwYg # /5c9HUct+y28CdmvFYyt5B0lxJq2VSgLPjqyF7yltzKglirqBcvc1YbMoXfiN4JY # tSvUHIiiJft839QbG1jrt5spl2xhORP6N7woqlgSiTeGKpPavp9nkWFPZO01QmkU # la6/vgFZZPCgZOlmt0lVMWy5UsWqKb0voOzi3QvDpGYNie+85JmI4OEOXtsKQvDw # 7EV+JaMtE72sjO35ruFo1KlapuFbM3yyJ97OpwpRuua1oCRXSyLYQMr5RvDO4rqf # sdSJw/h+VZ524ydza3d/kj8qlzXkOhEo2WidBQCRRMpI8va4+IcMwHB8ZuthU3LZ # MfOoEo4XayCQRUhFslHb6Y870Wsi3TxZCZ/fxpWqrCsxz5U5mNyUWoQHVdsofT6j # WrzeA5ibt1GOC42dif0178PhdowFQHySz1wDbxUEO4yKIo3ziQbH95aUmcT3hYuI # 17pSQegCA2EOCEzUXdD09qXSotJz7a+aKjiQ3hDxK7a1JokC9O4hvAwSbgOPsxCd # BbKwOhhsSM4= # =zBtX # -----END PGP SIGNATURE----- # gpg: Signature made Tue 16 Dec 2025 04:09:52 AM AEDT # gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6 # gpg: issuer "[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: block: Fix BDS use after free during shutdown tests/qemu-iotests: Fix check for existing file in _require_disk_usage() Signed-off-by: Richard Henderson <[email protected]>
A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :
../hw/i386/x86-common.c:827:11: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
827 | vmode = strstr(kernel_cmdline, "vga=");
| ^
Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
…nt glibc
A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :
../tests/vhost-user-bridge.c: In function ‘vubr_parse_host_port’:
../tests/vhost-user-bridge.c:749:15: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
749 | char *p = strchr(buf, ':');
| ^~~~~~
Fix this by using the glib g_strsplit() routine instead of strdup().
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Suggested-by: Peter Maydell <[email protected]>
Acked-by: Yodel Eldar <[email protected]>
Tested-by: Yodel Eldar <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
A recent change in glibc 2.42.9000 [1] changes the return type of
strchr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :
../monitor/hmp.c:589:7: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
589 | p = strchr(type, ':');
| ^
Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :
../gdbstub/user.c:322:21: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
322 | pid_placeholder = strstr(path, "%d");
| ^
Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
…nto staging Fix const qualifier build errors with recent glibc # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmlBXyEACgkQUaNDx8/7 # 7KHemxAAjOKuYG7LCZv6iPd0ezgErAyKuIDstgNn4x3KKA75sfEMJZINwLBaTXcy # l/DWOoZP3s9ciMJTBY1JdgkbVJ1LDDsf94rTUbZoNjrOocNSXypHNpVbYxuw3Ntf # vBhQ8gOdR62Ny/2ndmF525L0ir0pGd9lgy9I9fnZ2xQO6QxklInaJjfw8In0+l+t # mf1sUW8ltSWZs1tWpGaEUKnEyxs2iFYP83yvPSs1O0WAgPSBqPkLIkHp+QJJcdUV # f5IPfXPWrbgbjkSLyo8EbYwmegTHcXdSEvQxOm3hnSN+0HCMd5oTNcKbjdTaTcgk # DaUl39PJ09CB24orNMXEZakD7p3lFBVB5Yfr87dDujILTtpPtKAVZMt+X/b0chqj # g43L3m5pqu34zMWvGDOSgU+8azip11Wy4MG/yWsgMKVXMAPBf3oOunZVkQY/dqeI # eqX1Hvh7qXHcinuZKAKBefPUqKyoaOKDk3PtUVjW1p4iLC3f5MMOl4SKe8R/hKoe # xRz+SAcS8TJgrcnaKm1mMUDnqXorHb0IxUYCc/i0CVNJsVclmGI5rwLRMwEDAIIy # GOfMHMFUhtFzhVC+tbIcAe8QDnrzR6hvxBvEeunZ/lZtTjtlSPyZklRqKEpXjU4i # ME1Vj6wRIpI9jb5fcJCFy+ZTxQ94c8T8mHsXMfTSWcZzUlFC1/s= # =rEBR # -----END PGP SIGNATURE----- # gpg: Signature made Wed 17 Dec 2025 12:31:13 AM AEDT # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <[email protected]>" [full] # gpg: aka "Cédric Le Goater <[email protected]>" [full] * tag 'pull-glibc-20251216' of https://github.com/legoater/qemu: gdbstub: Fix const qualifier build errors with recent glibc monitor: Fix const qualifier build errors with recent glibc tests/vhost-user-bridge.c: Fix const qualifier build errors with recent glibc i386: Fix const qualifier build errors with recent glibc Signed-off-by: Richard Henderson <[email protected]>
When specifying lbr_fmt=VALUE in cpu options with an invalid VALUE, error_setg() gets triggered twice, causing an assertion failure in error_setv() which requires *errp to be NULL, preventing meaningful error messages from being displayed. Fix this by checking visit_type_uint64()'s return value and returning early on failure, consistent with other property setters like set_string(). Fixes: 18c22d7 (qdev-properties: Add a new macro with bitmask check for uint64_t property) Cc: [email protected] Signed-off-by: Zesen Liu <[email protected]> Message-ID: <[email protected]> Reviewed-by: Markus Armbruster <[email protected]> [Add Fixes: and Cc:] Signed-off-by: Markus Armbruster <[email protected]>
…nto staging Error reporting patches for 2025-12-17 # -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFAmlCbUQSHGFybWJydUBy # ZWRoYXQuY29tAAoJEDhwtADrkYZTsFsP/0UmrBVT+q57USh2V0+YJkcWdHiu+qOO # nVQewpTiKFePbJUF2d7gBuFJKd2m4rcRrAjAR93gSEmn1z8YUkNkynCvkxZ9awMj # G2fjDFNTu0P9Ypgs1l7zv4VXKqa3L0Fe/SGjpma2ytOAH/sGJ7ziWsKeRsv3V3Fn # QHp5OlInPWWVRYoLPDhd5Hf1lcs2lcA6t821kFhad8ejlSydiTFeEoAIPyo+yeu/ # U2FvsMJeTLdU3SuI8iO0tuJSI5TmqxmX2wHOP6QUFPAs/reLEtvbH6dCePGTXzLK # BjJEBxXVAL5aGTWMSA+7j+a85Lzn0wXbWxqdAXYBzHvQaoESmnQUsogUaM1OASJI # Zoxk89amoDI+oFwQjTbfpjFaSIR0ZsiqTEgeJOOOeJFgpfGwxt2cBDDcfa0qO4YD # ATpudTJLkyTgLTftAOKC0D8WiOqyVFRbfdUgeysx01tbJAwhJkZ/P5PfTz2zBsq1 # HWYuW4o5tpbeXQbEoFqlvQLj/LvhqM1s49AzOwZoD6A4d1WFKPlaciKbpsGPHely # lp40XTKDOj/BgpDptcLCH5hetjnZZKdTaNBDMyIM26wBvofuF1yfvm3NtNfCt/yR # ZRkA0MbK3/YGoZHEHqp3ps53G+mbnzHTbqelsex9W7K2yNzkBENkwzRy0ouFvSAa # tC7Za9gt7FIe # =2A+h # -----END PGP SIGNATURE----- # gpg: Signature made Wed 17 Dec 2025 07:43:48 PM AEDT # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "[email protected]" # gpg: Good signature from "Markus Armbruster <[email protected]>" [unknown] # gpg: aka "Markus Armbruster <[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: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * tag 'pull-error-2025-12-17' of https://repo.or.cz/qemu/armbru: qdev: fix error handling in set_uint64_checkmask Signed-off-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
- use vaddr instead of target_ulong for addresses. - remove useless imports. - adapt minor things to work well with qemu 10.2 - use abi_ulong where it makes sense
rmalmain
force-pushed
the
qemu_update_v10_2_0
branch
from
e78b0bc to
01c7020
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
supersets #120