Branch: refs/heads/staging
Home: https://github.com/qemu/qemu
Commit: 42dbb60bce9aff9e686a99d51f12f5a5118ee135
https://github.com/qemu/qemu/commit/42dbb60bce9aff9e686a99d51f12f5a5118ee135
Author: Bibo Mao <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/loongarch/loongarch-qmp-cmds.c
Log Message:
-----------
target/loongarch: Add missing vCPU features with QMP method
Feature msgint and ptw is missing with QMP method, such as:
query-cpu-model-expansion type=static model={"name":"max"}
Here add missing features in cpu_model_advertised_features array.
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
Commit: bedadea8a4b59f1f450072c7f7527f39d24f4f21
https://github.com/qemu/qemu/commit/bedadea8a4b59f1f450072c7f7527f39d24f4f21
Author: Bibo Mao <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/loongarch/loongarch-qmp-cmds.c
Log Message:
-----------
target/loongarch: Add full type support with query-cpu-model-expansion
On LoongArch with QMP command query-cpu-model-expansion, only static
type is supported, full type is not supported. Here add full type support
with QMP cpu model query command.
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
Commit: 84fd24d691c672cb48a5c5e6ae60fcfa752c9d4c
https://github.com/qemu/qemu/commit/84fd24d691c672cb48a5c5e6ae60fcfa752c9d4c
Author: Bibo Mao <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/loongarch/loongarch-qmp-cmds.c
Log Message:
-----------
target/loongarch: Add property set with query-cpu-model-expansion
On LoongArch with QMP command query-cpu-model-expansion, property
setting is not supported witch command such as:
query-cpu-model-expansion type=static
model={"name":"max","props":{"lasx":false}}
Here add property setting support with QMP command.
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
Commit: d8684f3b213f3283c8d4b1d5552a35c16446cf04
https://github.com/qemu/qemu/commit/d8684f3b213f3283c8d4b1d5552a35c16446cf04
Author: Bibo Mao <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/loongarch/cpu.c
M target/loongarch/cpu.h
Log Message:
-----------
target/loongarch: Add detailed information with CPU Product ID
CPUCFG0 is LoongArch CPU Product ID, it is a combination of Vendor ID,
Series ID and Product ID, here is the layout:
+-------------+----------------+------------+----------------+
| Reserved | Vendor ID | Series ID | Product ID |
+-------------+----------------+------------+----------------+
31 24 23 16 15 12 11 0
Here adds detailed information with CPUCFG0, it is convenient to add
such information with host or LA664 CPU type in future.
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Song Gao <[email protected]>
Commit: ce386d1313d9c84506d9a410de8ecddfcf92da68
https://github.com/qemu/qemu/commit/ce386d1313d9c84506d9a410de8ecddfcf92da68
Author: Bibo Mao <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/loongarch/cpu.c
Log Message:
-----------
target/loongarch: Add default cpucfg3 with LA464 CPU
The features shown in cpucfg3 mostly are relative with cache capability,
QEMU does not support cache emulation and discard these features.
However it will be better if it is the same with host machine.
Here add default cpucfg3 feature information with LA464 CPU.
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
Commit: 371c06fdff3f23134994bc620da9a9336db5ffe8
https://github.com/qemu/qemu/commit/371c06fdff3f23134994bc620da9a9336db5ffe8
Author: Bibo Mao <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M hw/loongarch/virt.c
M target/loongarch/cpu.c
M target/loongarch/cpu.h
Log Message:
-----------
target/loongarch: Add generic CPU model information
On LoongArch system, CPU model name comes from IOCSR register
LOONGARCH_IOCSR_VENDOR and LOONGARCH_IOCSR_CPUNAME. Its value
can be initialized when CPU is created.
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
Commit: e7aab4856dfb54e8cfc3a049e24dfd9761552282
https://github.com/qemu/qemu/commit/e7aab4856dfb54e8cfc3a049e24dfd9761552282
Author: Bibo Mao <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/loongarch/cpu.c
Log Message:
-----------
target/loongarch: Add host CPU model in kvm mode
Host CPU model is basically the same with max CPU model, except Product
ID and CPU model name. With host CPU model, Product ID comes from
cpucfg0 and CPU model comes from /proc/cpuinfo.
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
Commit: 45e3ef638e73799815a07a31041afe162d856dc3
https://github.com/qemu/qemu/commit/45e3ef638e73799815a07a31041afe162d856dc3
Author: Bibo Mao <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/loongarch/cpu.c
M target/loongarch/cpu.h
Log Message:
-----------
target/loongarch: Add some CPUCFG bits with host CPU model
Some CPUCFG capability bits depend on KVM host hypervsior and they
are detected on QEMU. However some CPUCFG bits are irrelative with
hypervsior, here these bits are checked from host machine and set
for VM with host CPU model.
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
Commit: 79773cd123a69583a1e09419cb99835f67d42748
https://github.com/qemu/qemu/commit/79773cd123a69583a1e09419cb99835f67d42748
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M scripts/checkpatch.pl
Log Message:
-----------
scripts: detect another GPL license boilerplate variant
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 163cd0ae1182e67509b271f244a73dfd938337b9
https://github.com/qemu/qemu/commit/163cd0ae1182e67509b271f244a73dfd938337b9
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M include/io/task.h
M io/channel-tls.c
M io/channel-websock.c
M io/task.c
M tests/unit/test-io-task.c
Log Message:
-----------
io: separate freeing of tasks from marking them as complete
The original design of QIOTask was intended to simplify lifecycle
management by automatically freeing it when the task was marked as
complete. This overlooked the fact that when a QIOTask is used in
combination with a GSource, there may be times when the source
callback is never invoked. This is typically when a GSource is
released before any I/O event arrives. In such cases it is not
desirable to mark a QIOTask as complete, but it still needs to be
freed. To satisfy this, the task must be released manually.
Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: cd02a4411928ab8921e5997ae32448117f49049b
https://github.com/qemu/qemu/commit/cd02a4411928ab8921e5997ae32448117f49049b
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M io/channel-tls.c
Log Message:
-----------
io: fix cleanup for TLS I/O source data on cancellation
The TLS code will create a GSource for tracking completion of the
handshake process, passing a QIOChannelTLSData struct that contains
various data items. The data struct is freed by the callback when
it completes, which means when a source is cancelled, nothing is
free'ing the data struct or its contents.
Switch to provide a data free callback to the GSource, which ensures
the QIOChannelTLSData struct is always freed even when the main event
callback never fires.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/3114
Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 77ae9dd7f5bf9ca1561b0f9d818fb1f88052bb0e
https://github.com/qemu/qemu/commit/77ae9dd7f5bf9ca1561b0f9d818fb1f88052bb0e
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M io/channel-websock.c
Log Message:
-----------
io: fix cleanup for websock I/O source data on cancellation
The websock code will create a GSource for tracking completion of the
handshake process, passing a QIOTask which is freed by the callback
when it completes, which means when a source is cancelled, nothing is
free'ing the task.
Switch to provide a data free callback to the GSource, which ensures
the QIOTask is always freed even when the main event callback never
fires.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/3114
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 216c87b5a8aede1a402b6cafbbc427493f6fd1f3
https://github.com/qemu/qemu/commit/216c87b5a8aede1a402b6cafbbc427493f6fd1f3
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M docs/system/cpu-models-x86.rst.inc
Log Message:
-----------
docs: simplify DiamondRapids CPU docs
This aligns the first line of the docs with the style used for previous
CPU models, and simplifies the text in the remaining docs.
Reviewed-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Zhao Liu <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 4c18c6a85f7b9e21bbfe5c80d8468cab2ede6242
https://github.com/qemu/qemu/commit/4c18c6a85f7b9e21bbfe5c80d8468cab2ede6242
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M qemu-options.hx
Log Message:
-----------
qemu-options: remove extraneous [] around arg values
There are quite a few inappropriate uses of [...] around argument
values. The [] are intended to indicate optionality, but in some
cases it is used to wrap a set of enum values. In other cases it
is being used to show the value is entirely optional, which was
common behaviour for boolean values in the past. QEMU has deprecated
short-form boolean options for quite a while though, and we should
thus not advertize this possibility in the docs.
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: a83edc330491a086022b049ee05223dc5e254b26
https://github.com/qemu/qemu/commit/a83edc330491a086022b049ee05223dc5e254b26
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M include/qemu/compiler.h
Log Message:
-----------
include: define constant for early constructor priority
Functions marked with __attribute__((__constructor__)) will be
invoked in linker order. In theory this is well defined, but
in practice, it is hard to determine what this order will be
with the layers of indirection through meson, ninja and the
static libraries QEMU builds.
Notably, the order currently appears different between Linux
and Windows (as tested with Wine on Linux). This can cause
problems when certain QEMU constructors have a dependancy on
other QEMU constructors.
To address this define a QEMU_CONSTRUCTOR_EARLY constant which
provides a priority value that will run before other default
constructors. This is to be used for QEMU constructors that
are themselves self-contained, but may be relied upon by other
constructors.
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Dr. David Alan Gilbert <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 3530bcc1ee3cd2912f70c55753f2d949da6c3f4a
https://github.com/qemu/qemu/commit/3530bcc1ee3cd2912f70c55753f2d949da6c3f4a
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M monitor/monitor.c
Log Message:
-----------
monitor: initialize global data from a constructor
Some monitor functions, most notably, monitor_cur() rely on global
data being initialized by 'monitor_init_globals()'. The latter is
called relatively late in startup. If code triggers error_report()
before monitor_init_globals() is called, QEMU will abort when
accessing the uninitialized monitor mutex.
The critical monitor global data must be initialized from a
constructor function, to improve the guarantee that it is done
before any possible calls to monitor_cur(). Not only that, but
the constructor must be marked to run before the default
constructor in case any of them trigger error reporting.
Note in particular that the RCU constructor will spawn a background
thread so we might even have non-constructor QEMU code running
concurrently with other constructors.
As a general note, constructors should be extrememly careful
about what QEMU code they invoke, as it cannot be guaranteed that
the process is fully initialized and so not all normal QEMU API
rules apply.
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Dr. David Alan Gilbert <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Fixes: e69ee454b5f9 (monitor: Make current monitor a per-coroutine property)
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 84b4ca3f047f6fa67e112f3c0b41c7abcaf8f23c
https://github.com/qemu/qemu/commit/84b4ca3f047f6fa67e112f3c0b41c7abcaf8f23c
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M docs/about/deprecated.rst
M include/qemu/thread.h
M system/vl.c
M util/qemu-thread-posix.c
M util/qemu-thread-win32.c
Log Message:
-----------
system: unconditionally enable thread naming
When thread naming was introduced years ago, it was disabled by
default and put behind a command line flag:
commit 8f480de0c91a18d550721f8d9af969ebfbda0793
Author: Dr. David Alan Gilbert <[email protected]>
Date: Thu Jan 30 10:20:31 2014 +0000
Add 'debug-threads' suboption to --name
This was done based on a concern that something might depend
on the historical thread naming. Thread names, however, were
never promised to be part of QEMU's public API. The defaults
will vary across platforms, so no assumptions should ever be
made about naming.
An opt-in behaviour is also unfortunately incompatible with
RCU which creates its thread from an constructor function
which is run before command line args are parsed. Thus the
RCU thread lacks any name.
libvirt has unconditionally enabled debug-threads=yes on all
VMs it creates for 10 years. Interestingly this DID expose a
bug in libvirt, as it parsed /proc/$PID/stat and could not
cope with a space in the thread name. This was a latent
pre-existing bug in libvirt though, and not a part of QEMU's
API.
Having thread names always available, will allow thread names
to be included in error reports and log messags QEMU prints
by default, which will improve ability to triage QEMU bugs.
Reviewed-by: Dr. David Alan Gilbert <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: b4d204a459c0ae3c10002647b4bcc564b4354dba
https://github.com/qemu/qemu/commit/b4d204a459c0ae3c10002647b4bcc564b4354dba
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M util/qemu-thread-win32.c
Log Message:
-----------
util: fix race setting thread name on Win32
The call to set the thread name on Win32 platforms is done by the parent
thread, after _beginthreadex() returns. At this point the new child
thread is potentially already executing its start method. To ensure the
thread name is guaranteed to be set before any "interesting" code starts
executing, it must be done in the start method of the child thread itself.
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Dr. David Alan Gilbert <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 0580e861e4e4165b7244fe122dcea3ef7ad19262
https://github.com/qemu/qemu/commit/0580e861e4e4165b7244fe122dcea3ef7ad19262
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M include/qemu/thread.h
M util/qemu-thread-posix.c
M util/qemu-thread-win32.c
Log Message:
-----------
util: expose qemu_thread_set_name
The ability to set the thread name needs to be used in a number
of places, so expose the current impls as public methods.
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Dr. David Alan Gilbert <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: cf3cab39d306972fa11baf81a7d2fdd215467dee
https://github.com/qemu/qemu/commit/cf3cab39d306972fa11baf81a7d2fdd215467dee
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M audio/jackaudio.c
Log Message:
-----------
audio: make jackaudio use qemu_thread_set_name
This has greater portability than directly call pthread_setname_np,
which is only 1 out of 3 possible functions for pthreads that can
set the name.
The new API requires a trampoline function, since it can only set
the name of the current thread.
Reviewed-by: Christian Schoenebeck <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: e12889441275042616fcfd722ecd5b650447c026
https://github.com/qemu/qemu/commit/e12889441275042616fcfd722ecd5b650447c026
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M util/qemu-thread-win32.c
Log Message:
-----------
util: set the name for the 'main' thread on Windows
The default main thread name is undefined, so use a constructor to
explicitly set it to 'main'. This constructor is marked to run early
as the thread name is intended to be used in error reporting / logs
which may be triggered very early in QEMU execution.
This is only done on Windows platforms, because on Linux (and possibly
other POSIX platforms) changing the main thread name has a side effect
of changing the process name reported by tools like 'ps' which fetch
from the file /proc/self/task/tid/comm, expecting it to be the binary
name.
The subsequent patch will address POSIX platforms in a different way.
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Dr. David Alan Gilbert <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 4aff30cbbcab7d5c53f298639dc9762c88fa491d
https://github.com/qemu/qemu/commit/4aff30cbbcab7d5c53f298639dc9762c88fa491d
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M include/qemu/thread.h
M meson.build
M util/qemu-thread-posix.c
M util/qemu-thread-win32.c
Log Message:
-----------
util: add API to fetch the current thread name
This will be used to include the thread name in error reports
in a later patch. It returns a const string stored in a thread
local to avoid memory allocation when it is called repeatedly
in a single thread. The thread name should be set at the very
start of the thread execution, which is the case when using
qemu_thread_create.
This uses the official thread APIs for fetching thread names,
so that it captures names of threads spawned by code in 3rd
party libraries, not merely QEMU spawned thrads.
This also addresses the gap from the previous patch for setting
the name of the main thread. A constructor is used to initialize
the 'namebuf' thread-local in the main thread only.
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: e9336908a2f712baf69f6ec413e3bc222cbf18d1
https://github.com/qemu/qemu/commit/e9336908a2f712baf69f6ec413e3bc222cbf18d1
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M include/qemu/log-for-trace.h
M include/qemu/log.h
M rust/util/src/log.rs
Log Message:
-----------
util: introduce some API docs for logging APIs
There is a gotcha with qemu_log() usage in a threaded process.
If fragments of a log message are output via qemu_log() it is
possible for messages from two threads to get mixed up. To
prevent this qemu_log_trylock() should be used, along with
fprintf(f) calls.
This is a subtle problem that needs to be explained in the
API docs to ensure correct usage.
In the Rust code, the log_mask_ln method which is conceptually
equivalent to the C qemu_log() call will unconditionally append
a newline so must only ever be used for complete log messages.
Reported-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 83f237d388a699df499151a3d092ed2ff9d41552
https://github.com/qemu/qemu/commit/83f237d388a699df499151a3d092ed2ff9d41552
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M include/qemu/log.h
M util/log.c
Log Message:
-----------
util: avoid repeated prefix on incremental qemu_log calls
There are three general patterns to QEMU log output
1. Single complete message calls
qemu_log("Some message\n");
2. Direct use of fprintf
FILE *f = qemu_log_trylock()
fprintf(f, "...");
fprintf(f, "...");
fprintf(f, "...\n");
qemu_log_unlock(f)
3. Mixed use of qemu_log_trylock/qemu_log()
FILE *f = qemu_log_trylock()
qemu_log("....");
qemu_log("....");
qemu_log("....\n");
qemu_log_unlock(f)
When message prefixes are enabled, the timestamp will be
unconditionally emitted for all qemu_log() calls. This
works fine in the 1st case, and has no effect in the 2nd
case. In the 3rd case, however, we get the timestamp
printed over & over in each fragment.
One can suggest that pattern (3) is pointless as it is
functionally identical to (2) but with extra indirection
and overhead. None the less we have a fair bit of code
that does this.
The qemu_log() call itself is nothing more than a wrapper
which does pattern (2) with a single fprintf() call.
One might question whether (2) should include the message
prefix in the same way that (1), but there are scenarios
where this could be inappropriate / unhelpful such as the
CPU register dumps or linux-user strace output.
This patch fixes the problem in pattern (3) by keeping
track of the call depth of qemu_log_trylock() and then
only emitting the the prefix when the starting depth
was zero. In doing this qemu_log_trylock_context() is
also introduced as a variant of qemu_log_trylock()
that emits the prefix. Callers doing to batch output
can thus choose whether a prefix is appropriate or
not.
Fixes: 012842c07552 (log: make '-msg timestamp=on' apply to all qemu_log usage)
Reported-by: Richard Henderson <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: c2303d442b18f70140ee0929e1893ffe2136eec5
https://github.com/qemu/qemu/commit/c2303d442b18f70140ee0929e1893ffe2136eec5
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M util/log.c
Log Message:
-----------
util/log: add missing error reporting in qemu_log_trylock_with_err
One codepath that could return NULL failed to populate the errp
object.
Reported-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 34e6b490845dd123275980d71a04fbb728cc8b74
https://github.com/qemu/qemu/commit/34e6b490845dd123275980d71a04fbb728cc8b74
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M include/ui/console.h
M include/ui/qemu-spice-module.h
M tests/functional/generic/test_vnc.py
M ui/spice-core.c
M ui/spice-module.c
M ui/ui-qmp-cmds.c
M ui/vnc-stubs.c
M ui/vnc.c
Log Message:
-----------
ui: add proper error reporting for password changes
Neither the VNC or SPICE code for password changes provides error
reporting at source, leading the callers to report a largely useless
generic error message.
Fixing this removes one of the two remaining needs for the undesirable
error_printf_unless_qmp() method.
While fixing this the error message hint is improved to recommend the
'password-secret' option which allows securely passing a password at
startup.
Reported-by: Markus Armbruster <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 86f28e74642f5b6d477163bb278e28f5f196b24c
https://github.com/qemu/qemu/commit/86f28e74642f5b6d477163bb278e28f5f196b24c
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M ui/vnc.c
Log Message:
-----------
ui: remove redundant use of error_printf_unless_qmp()
The vnc_display_print_local_addr() method is intended to print the VNC
listening address on the console at startup, so the user can see the
auto-chosen port address when using the 'to=' flag. This is only called
by vnc_display_open() which is in the QEMU startup callpath. The check
for not being in QMP is thus redundant and can be removed.
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 8bcae6f40e63e4bdf740aaa8347a2a7b3823b877
https://github.com/qemu/qemu/commit/8bcae6f40e63e4bdf740aaa8347a2a7b3823b877
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M include/monitor/monitor.h
M monitor/monitor.c
M stubs/error-printf.c
Log Message:
-----------
monitor: remove redundant error_[v]printf_unless_qmp
The only callers of these functions have been removed. Adding any
new usage of them is highly undesirable, so they should be entirely
removed.
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 191fc11d3375375a976a8adf5dcc0c8a68c92dbd
https://github.com/qemu/qemu/commit/191fc11d3375375a976a8adf5dcc0c8a68c92dbd
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M monitor/monitor.c
Log Message:
-----------
monitor: refactor error_vprintf()
The monitor_vprintf() code will return -1 if either the monitor
is NULL, or the monitor is QMP. The error_vprintf() code can
take advantage of this to avoid having to duplicate the same
checks, and instead simply look at the return value.
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 2dc862e65a1267483ae35d078e9cd9b529dcacc8
https://github.com/qemu/qemu/commit/2dc862e65a1267483ae35d078e9cd9b529dcacc8
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M monitor/monitor.c
R stubs/error-printf.c
M stubs/meson.build
M stubs/monitor-core.c
M util/error-report.c
Log Message:
-----------
monitor: move error_vprintf back to error-report.c
The current unit tests rely on monitor.o not being linked, such
that the monitor stubs get linked instead. Since error_vprintf
is in monitor.o this allows a stub error_vprintf impl to be used
that calls g_test_message.
This takes a different approach, with error_vprintf moving
back to error-report.c such that it is always linked into the
tests. The monitor_vprintf() stub is then changed to use
g_test_message if QTEST_SILENT_ERRORS is set, otherwise it will
return -1 and trigger error_vprintf to call vfprintf.
The end result is functionally equivalent for the purposes of
the unit tests.
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: c9c17b8697a20be50c0428731785611406f14d4d
https://github.com/qemu/qemu/commit/c9c17b8697a20be50c0428731785611406f14d4d
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M util/error-report.c
Log Message:
-----------
util: fix interleaving of error & trace output
The monitor_cur_hmp() function will acquire/release mutex locks, which
will trigger trace probes, which can in turn trigger qemu_log() calls.
vreport() calls monitor_cur() multiple times through its execution
both directly and indirectly via error_vprintf().
The result is that the prefix information printed by vreport() gets
interleaved with qemu_log() output, when run outside the context of
an HMP command dispatcher. This can be seen with:
$ qemu-system-x86_64 \
-msg timestamp=on,guest-name=on \
-display none \
-object tls-creds-x509,id=f,dir=fish \
-name fish \
-d trace:qemu_mutex*
2025-09-10T16:30:42.514374Z qemu_mutex_unlock released mutex 0x560b0339b4c0
(/var/home/berrange/src/virt/qemu/include/qemu/lockable.h:56)
2025-09-10T16:30:42.514400Z qemu_mutex_lock waiting on mutex 0x560b033983e0
(/var/home/berrange/src/virt/qemu/include/qemu/lockable.h:56)
2025-09-10T16:30:42.514402Z qemu_mutex_locked taken mutex 0x560b033983e0
(/var/home/berrange/src/virt/qemu/include/qemu/lockable.h:56)
2025-09-10T16:30:42.514404Z qemu_mutex_unlock released mutex 0x560b033983e0
(/var/home/berrange/src/virt/qemu/include/qemu/lockable.h:56)
2025-09-10T16:30:42.516716Z qemu_mutex_lock waiting on mutex 0x560b03398560
(../monitor/monitor.c:91)
2025-09-10T16:30:42.516723Z qemu_mutex_locked taken mutex 0x560b03398560
(../monitor/monitor.c:91)
2025-09-10T16:30:42.516726Z qemu_mutex_unlock released mutex 0x560b03398560
(../monitor/monitor.c:96)
2025-09-10T16:30:42.516728Z qemu_mutex_lock waiting on mutex 0x560b03398560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842057Z qemu_mutex_locked taken mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842058Z qemu_mutex_unlock released mutex 0x564f5e401560
(../monitor/monitor.c:96)
2025-09-10T16:31:04.842055Z 2025-09-10T16:31:04.842060Z qemu_mutex_lock
waiting on mutex 0x564f5e401560 (../monitor/monitor.c:91)
2025-09-10T16:31:04.842061Z qemu_mutex_locked taken mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842062Z qemu_mutex_unlock released mutex 0x564f5e401560
(../monitor/monitor.c:96)
2025-09-10T16:31:04.842064Z qemu_mutex_lock waiting on mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842065Z qemu_mutex_locked taken mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842066Z qemu_mutex_unlock released mutex 0x564f5e401560
(../monitor/monitor.c:96)
fish 2025-09-10T16:31:04.842068Z qemu_mutex_lock waiting on mutex
0x564f5e401560 (../monitor/monitor.c:91)
2025-09-10T16:31:04.842069Z qemu_mutex_locked taken mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842070Z qemu_mutex_unlock released mutex 0x564f5e401560
(../monitor/monitor.c:96)
2025-09-10T16:31:04.842072Z qemu_mutex_lock waiting on mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842097Z qemu_mutex_locked taken mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842099Z qemu_mutex_unlock released mutex 0x564f5e401560
(../monitor/monitor.c:96)
qemu-system-x86_64:2025-09-10T16:31:04.842100Z qemu_mutex_lock waiting on
mutex 0x564f5e401560 (../monitor/monitor.c:91)
2025-09-10T16:31:04.842102Z qemu_mutex_locked taken mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842103Z qemu_mutex_unlock released mutex 0x564f5e401560
(../monitor/monitor.c:96)
2025-09-10T16:31:04.842105Z qemu_mutex_lock waiting on mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842106Z qemu_mutex_locked taken mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842107Z qemu_mutex_unlock released mutex 0x564f5e401560
(../monitor/monitor.c:96)
Unable to access credentials fish/ca-cert.pem: No such file or
directory2025-09-10T16:31:04.842109Z qemu_mutex_lock waiting on mutex
0x564f5e401560 (../monitor/monitor.c:91)
2025-09-10T16:31:04.842110Z qemu_mutex_locked taken mutex 0x564f5e401560
(../monitor/monitor.c:91)
2025-09-10T16:31:04.842111Z qemu_mutex_unlock released mutex 0x564f5e401560
(../monitor/monitor.c:96)
To avoid this interleaving (as well as reduce the huge number of
mutex lock/unlock calls) we need to ensure that monitor_cur_is_hmp()
is only called once at the start of vreport(), and if no HMP is
present, no further monitor APIs can be called.
This implies error_[v]printf() cannot be called from vreport().
Instead we must introduce error_[v]printf_mon() which accept a
pre-acquired Monitor object. In some cases, however, fprintf
can be called directly as output will never be directed to the
monitor.
$ qemu-system-x86_64 \
-msg timestamp=on,guest-name=on \
-display none \
-object tls-creds-x509,id=f,dir=fish \
-name fish \
-d trace:qemu_mutex*
2025-09-10T16:31:22.701691Z qemu_mutex_unlock released mutex 0x5626fd3b84c0
(/var/home/berrange/src/virt/qemu/include/qemu/lockable.h:56)
2025-09-10T16:31:22.701728Z qemu_mutex_lock waiting on mutex 0x5626fd3b53e0
(/var/home/berrange/src/virt/qemu/include/qemu/lockable.h:56)
2025-09-10T16:31:22.701730Z qemu_mutex_locked taken mutex 0x5626fd3b53e0
(/var/home/berrange/src/virt/qemu/include/qemu/lockable.h:56)
2025-09-10T16:31:22.701732Z qemu_mutex_unlock released mutex 0x5626fd3b53e0
(/var/home/berrange/src/virt/qemu/include/qemu/lockable.h:56)
2025-09-10T16:31:22.703989Z qemu_mutex_lock waiting on mutex 0x5626fd3b5560
(../monitor/monitor.c:91)
2025-09-10T16:31:22.703996Z qemu_mutex_locked taken mutex 0x5626fd3b5560
(../monitor/monitor.c:91)
2025-09-10T16:31:22.703999Z qemu_mutex_unlock released mutex 0x5626fd3b5560
(../monitor/monitor.c:96)
2025-09-10T16:31:22.704000Z fish qemu-system-x86_64: Unable to access
credentials fish/ca-cert.pem: No such file or directory
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 3f208b3037e95c48076b207677fb859b7198a108
https://github.com/qemu/qemu/commit/3f208b3037e95c48076b207677fb859b7198a108
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M stubs/monitor-core.c
M tests/unit/test-util-sockets.c
M util/error-report.c
Log Message:
-----------
util: don't skip error prefixes when QMP is active
The vreport() function will print to HMP if available, otherwise
to stderr. In the event that vreport() is called during execution
of a QMP command, it will print to stderr, but mistakenly omit the
message prefixes (timestamp, guest name, program name).
This new usage of monitor_is_cur_qmp() from vreport() requires that
we add a stub to satisfy linking of non-system emulator binaries.
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 9539f2c08260baa2663ab4f2490760b297d31f43
https://github.com/qemu/qemu/commit/9539f2c08260baa2663ab4f2490760b297d31f43
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M util/error-report.c
Log Message:
-----------
util: fix interleaving of error prefixes
The vreport() function will optionally emit an prefix for error
messages which is output to stderr incrementally. In the event
that two vreport() calls execute concurrently, there is a risk
that the prefix output will interleave. To address this it is
required to take a lock on 'stderr' when outputting errors.
Reported-by: Markus Armbruster <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 51ee57086c606c1b1e11d769eac231e41b7c947c
https://github.com/qemu/qemu/commit/51ee57086c606c1b1e11d769eac231e41b7c947c
Author: Markus Armbruster <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M scripts/checkpatch.pl
Log Message:
-----------
scripts/checkpatch: Fix MAINTAINERS update warning with --terse
We recently improved the MAINTAINERS update warning to show the files
that trigger it. Example:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#105:
deleted file mode 100644
improved to
WARNING: added, moved or deleted file(s):
migration/threadinfo.h
migration/threadinfo.c
Does MAINTAINERS need updating?
Unfortunately, this made things worse with --terse, as only the first
line of each warning is shown then.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
became
WARNING: added, moved or deleted file(s):
Adjust the warning text to
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
migration/threadinfo.h
migration/threadinfo.c
so we get the exact same warning as we used to with --terse.
Fixes: 1d745e6d9635 (scripts/checkpatch: use new hook for MAINTAINERS update
check)
Signed-off-by: Markus Armbruster <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
[DB: fix typo with missing string concat operator]
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 192f59773a6a8fd1e0d3c1d9c9c3f5f59a62c087
https://github.com/qemu/qemu/commit/192f59773a6a8fd1e0d3c1d9c9c3f5f59a62c087
Author: Jon Kohler <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M util/oslib-posix.c
Log Message:
-----------
util/oslib-posix: increase memprealloc thread count to 32
Increase MAX_MEM_PREALLOC_THREAD_COUNT from 16 to 32. This was last
touched in 2017 [1] and, since then, physical machine sizes and VMs
therein have continue to get even bigger, both on average and on the
extremes.
For very large VMs, using 16 threads to preallocate memory can be a
non-trivial bottleneck during VM start-up and migration. Increasing
this limit to 32 threads reduces the time taken for these operations.
Test results from quad socket Intel 8490H (4x 60 cores) show a fairly
linear gain of 50% with the 2x thread count increase.
---------------------------------------------
Idle Guest w/ 2M HugePages | Start-up time
---------------------------------------------
240 vCPU, 7.5TB (16 threads) | 2m41.955s
---------------------------------------------
240 vCPU, 7.5TB (32 threads) | 1m19.404s
---------------------------------------------
Note: Going above 32 threads appears to have diminishing returns at
the point where the memory bandwidth and context switching costs
appear to be a limiting factor to linear scaling. For posterity, on
the same system as above:
- 32 threads: 1m19s
- 48 threads: 1m4s
- 64 threads: 59s
- 240 threads: 50s
Additional thread counts also get less interesting as the amount of
memory is to be preallocated is smaller. Putting that all together,
32 threads appears to be a sane number with a solid speedup on fairly
modern hardware. To go faster, we'd either need to improve the hardware
(CPU/memory) itself or improve clear_pages_*() on the kernel side to
be more efficient.
[1] 1e356fc14bea ("mem-prealloc: reduce large guest start-up and migration
time.")
Signed-off-by: Jon Kohler <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Commit: 1752ca55c18b58b1fe59a02bc59755d9c0d3f4bd
https://github.com/qemu/qemu/commit/1752ca55c18b58b1fe59a02bc59755d9c0d3f4bd
Author: Peter Maydell <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M hw/loongarch/virt.c
M target/loongarch/cpu.c
M target/loongarch/cpu.h
M target/loongarch/loongarch-qmp-cmds.c
Log Message:
-----------
Merge tag 'pull-loongarch-20260302' of https://github.com/gaosong715/qemu
into staging
pull-loongarch-20260302
# -----BEGIN PGP SIGNATURE-----
#
# iLMEAAEKAB0WIQTKRzxE1qCcGJoZP81FK5aFKyaCFgUCaaVgvwAKCRBFK5aFKyaC
# FsyvA/oD4HhxbCjv6ukdYHkSj3rMxo0aTV9RzNSUGhdrC4v6LPnRf2JeEV9K65BU
# HEctYSMI64iasQBQx1FruFlVMJz+mYhHwv+FvE94TrZq1lTmbYdO1qOTChO+m+60
# B2qtT3pORejLLeawHighD9d8MkbNlXsysSMFRn4PwRYvFmYY9w==
# =CYNU
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon Mar 2 10:04:47 2026 GMT
# gpg: using RSA key CA473C44D6A09C189A193FCD452B96852B268216
# gpg: Good signature from "Song Gao <[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: CA47 3C44 D6A0 9C18 9A19 3FCD 452B 9685 2B26 8216
* tag 'pull-loongarch-20260302' of https://github.com/gaosong715/qemu:
target/loongarch: Add some CPUCFG bits with host CPU model
target/loongarch: Add host CPU model in kvm mode
target/loongarch: Add generic CPU model information
target/loongarch: Add default cpucfg3 with LA464 CPU
target/loongarch: Add detailed information with CPU Product ID
target/loongarch: Add property set with query-cpu-model-expansion
target/loongarch: Add full type support with query-cpu-model-expansion
target/loongarch: Add missing vCPU features with QMP method
Signed-off-by: Peter Maydell <[email protected]>
Commit: 76ba6587eeae19f454222055ddf6fc007a350fed
https://github.com/qemu/qemu/commit/76ba6587eeae19f454222055ddf6fc007a350fed
Author: Peter Maydell <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M audio/jackaudio.c
M docs/about/deprecated.rst
M docs/system/cpu-models-x86.rst.inc
M include/io/task.h
M include/monitor/monitor.h
M include/qemu/compiler.h
M include/qemu/log-for-trace.h
M include/qemu/log.h
M include/qemu/thread.h
M include/ui/console.h
M include/ui/qemu-spice-module.h
M io/channel-tls.c
M io/channel-websock.c
M io/task.c
M meson.build
M monitor/monitor.c
M qemu-options.hx
M rust/util/src/log.rs
M scripts/checkpatch.pl
R stubs/error-printf.c
M stubs/meson.build
M stubs/monitor-core.c
M system/vl.c
M tests/functional/generic/test_vnc.py
M tests/unit/test-io-task.c
M tests/unit/test-util-sockets.c
M ui/spice-core.c
M ui/spice-module.c
M ui/ui-qmp-cmds.c
M ui/vnc-stubs.c
M ui/vnc.c
M util/error-report.c
M util/log.c
M util/oslib-posix.c
M util/qemu-thread-posix.c
M util/qemu-thread-win32.c
Log Message:
-----------
Merge tag 'next-pr-pull-request' of https://gitlab.com/berrange/qemu into
staging
* Increase pre-alloc max thread count to 32
* Fix checkpatch warning for new/removed files with --terse
* Detect more GPL boilerplate in checkpatch
* Fix lean of data in TLS/websock GSource cancellation
* Tweak CPU docs for DiamondRapids
* Unconditionally enable thread naming
* Fix race setting thread naming on Win32
* Add API docs for logging APIs
* Fix interleaved error/trace output
* Fix missing error prefixes with warn_report
* Add detailed error reporting for VNC passworrd changes
* Refactoring of error_vprintf & related funcs
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE2vOm/bJrYpEtDo4/vobrtBUQT98FAmmm+JkACgkQvobrtBUQ
# T9/nQBAAjgMN+DrvjHswL5JUfWHVBftWKgNj8RFuER1j0ln2JylAEjB2HCP9cBVi
# pJmrrIztG8GetE8fCm9z2Ob6WtDeeroDo3iPg51XCIima5oIqrI9d/sFVfNq1k3C
# 1c+DMTkfvf7VT0lkDYSel3X4Tul4mGZGgVPIxV7zHfaFyeLvjSybjnFK86SgvvBa
# maLF8nNKI0D1CP3CDWAOYwegeBdrJGKbNWu1qJr+Pz1EQfRRoCFYloMSo0+4Vhrl
# oT39pukw/R0Di+Ux7MUP10/oXvcdETEU4JNRT11/7LeXTDVk407/eVOkJLqdpj0u
# n1Axt8bMFf2SmCoI7/+2e6ISlvEW2v2gHCQx9BfczNabO433z6Tn1sIEu3rwqln8
# 0pszpy5yKNtGmD9FGW2bPkh1mQADKh4lB5ujfMA4X1Nw1xLWHJE/xXqszgO7GYJQ
# Fp63NuZd7989NUgX2RrSbS8HmO70kK74kXZKXIW4jEkCHglAk4Quva6x0Wtvx2Xi
# a4JGpzKUUDHBGwUXUSqtmqnosqTW/r3NrlwiEGOwCagY1YpUln1HuSdJRpKpRVoA
# R3ThhV4+QM5p97lTnlPKvLLEbcEYzWXJORFUWsm8aUxaWAao/vhbUd1/uYWQOKPo
# iKXMjRSjVb3CAFPJpFhCThduIm80ozFWi/Djc7lUghUDYaHPUzM=
# =NOVq
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue Mar 3 15:04:57 2026 GMT
# gpg: using RSA key DAF3A6FDB26B62912D0E8E3FBE86EBB415104FDF
# gpg: Good signature from "Daniel P. Berrange <[email protected]>" [full]
# gpg: aka "Daniel P. Berrange <[email protected]>" [full]
# Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF
* tag 'next-pr-pull-request' of https://gitlab.com/berrange/qemu: (27 commits)
util/oslib-posix: increase memprealloc thread count to 32
scripts/checkpatch: Fix MAINTAINERS update warning with --terse
util: fix interleaving of error prefixes
util: don't skip error prefixes when QMP is active
util: fix interleaving of error & trace output
monitor: move error_vprintf back to error-report.c
monitor: refactor error_vprintf()
monitor: remove redundant error_[v]printf_unless_qmp
ui: remove redundant use of error_printf_unless_qmp()
ui: add proper error reporting for password changes
util/log: add missing error reporting in qemu_log_trylock_with_err
util: avoid repeated prefix on incremental qemu_log calls
util: introduce some API docs for logging APIs
util: add API to fetch the current thread name
util: set the name for the 'main' thread on Windows
audio: make jackaudio use qemu_thread_set_name
util: expose qemu_thread_set_name
util: fix race setting thread name on Win32
system: unconditionally enable thread naming
monitor: initialize global data from a constructor
...
Signed-off-by: Peter Maydell <[email protected]>
Compare: https://github.com/qemu/qemu/compare/3fb456e9a0e9...76ba6587eeae
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
