Jamin Lin [Wed, 25 Feb 2026 02:12:25 +0000 (02:12 +0000)]
hw/i3c/dw-i3c: Add IBI handling
Adds handling for different IBI events that the controller can receive.
This includes:
- Handling a hot-join from a target
- Handling a secondary controller on the bus requesting to be the
primary bus controller
- Handling an interrupt request from a target.
When receiving an IBI, the controller sets an interrupt to notify
software about what happened.
When the IBI is finished being serviced, the controller pushes the
result of the IBI and any data received from the target into the IBI
queue.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Stephen Longfield <slongfield@google.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-15-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:23 +0000 (02:12 +0000)]
hw/i3c/dw-i3c: Add data TX and RX
This adds data and CCC transmission, reception, and the associated
queues required for data transmission and reception to happen.
The I3C controller transmits data by the user writing into a command
queue. When the queue has a command and an argument in it, the
controller starts executing the command.
The controller can execute 1 of 3 ways:
1. A larger data transfer that involves using the TX and RX queues. This
is the most common way the controller does transactions.
2. A small data transfer that involves sending a couple bytes passed
into the command queue argument.
3. An address assignment command. This is how the controller does
ENTDAA. When ENTDAA succeeds in assigning an address to a target, it
updates the controller's char table with the target's PID, BCR, and
DCR.
The controller determines what addresses to send by looking at the index
in the device address table specified by the argument in the command
queue. ENTDAA also uses these addresses to assign to targets on the bus.
When the controller is done executing a command, it puts a response in
the response queue indicating how command execution went.
In order for the user to send and receive data to/from the controller,
the user reads/writes to a bidirectional TX/RX port.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Stephen Longfield <slongfield@google.com> Reviewed-by: Patrick Venture <venture@google.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-14-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:19 +0000 (02:12 +0000)]
hw/i3c/dw-i3c: Use 32 bits on MMIO writes
The registers are only 32 bits wide, so we should cast the 64-bit value
passed in to only be 32 bits wide.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Titus Rwantare <titusr@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-12-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:17 +0000 (02:12 +0000)]
hw/i3c/dw-i3c: Treat more registers as read-as-zero
RESET_CTRL and INTR_FORCE are write-only.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-11-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:15 +0000 (02:12 +0000)]
hw/i3c/dw-i3c: Add register RO field masks
Adds read-only register masks for the DwC I3C controller.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-10-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:13 +0000 (02:12 +0000)]
hw/i3c/aspeed_i3c: Add register RO field masks
Adds read-only register masks for the Aspeed I3C controller registers.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-9-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:12 +0000 (02:12 +0000)]
hw/i3c/dw-i3c: Add more reset values
Adds reset values for the new registers added.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-8-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:10 +0000 (02:12 +0000)]
hw/i3c/aspeed_i3c: Add more register fields
Adds the rest of the Aspeed I3C controller register fields.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-7-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:08 +0000 (02:12 +0000)]
hw/i3c/dw-i3c: Add more register fields
Adds the rest of the Designware register fields.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-6-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:06 +0000 (02:12 +0000)]
hw/i3c: Split DesignWare I3C out of Aspeed I3C
The Aspeed I3C IP block is technically an Aspeed IP block that manages
6 DW I3C controllers.
To help reflect this better and to make it easier for other SoCs to use
the DW I3C model, we'll split out the DW portion from the Aspeed
portion.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-5-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:04 +0000 (02:12 +0000)]
hw/i3c: Add bus support
Adds an I3C bus and a target class.
The bus supports:
- I3C data transmission and reception
- CCCs (including ENTDAA)
- IBIs
- legacy I2C transactions
General usage of the bus is similar to I2C. Users are expected to
initialize a bus via i3c_init_bus, and use the bus returned from the
init function to do transactions on the bus.
In order to handle IBIs, the controller provides callbacks to handle
receiving an IBI from a target, receiving (optional) additional IBI
bytes from a target, and handling when a target is done with its IBI.
Similarly, target creation is done via i3c_target_create_simple and
users use the provided I3CTarget to handle transactions.
The target has functions provided that it can use to invoke an IBI and
send additional bytes.
Along with the send, recv, and event callbacks that are expected of an
I3C target, which are similar to I2C, there is a separate callback for
CCC handling.
This is to help encapsulate CCC handling and keep it separate from
target-specific read/write functionality.
To avoid repition for required CCCs among I3C targets, there is some
class-level CCC handling added. The CCC is then passed to the target in
case it needs to handle it in some way.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Titus Rwantare <titusr@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-4-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:01 +0000 (02:12 +0000)]
hw/misc/aspeed_i3c: Move to i3c directory
Moves the Aspeed I3C model and traces into hw/i3c and creates I3C build
files.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Titus Rwantare <titusr@google.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-2-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Tue, 24 Feb 2026 07:32:09 +0000 (07:32 +0000)]
hw/i2c/aspeed_i2c: Fix DMA64 address handling
The current code updates the upper 32 bits of dma_dram_offset only when
aic->has_dma64 is false, which is incorrect.
If aic->has_dma64 is true, the controller supports 64-bit DMA addressing
and the upper 32-bit DMA address register must be used to update the
dma_dram_offset accordingly.
Fix the condition so that the upper 32 bits are updated only when
64-bit DMA is supported.
Fixes: efea7ddb4689a1ac4bce63a9ddb32887c7f3ac50 ("hw/i2c/aspeed_i2c: Fix DMA moving data into incorrect address") Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20260224073207.985162-1-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jon Kohler [Thu, 6 Nov 2025 16:31:43 +0000 (09:31 -0700)]
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.
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 <jon@nutanix.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[DB: fix typo with missing string concat operator] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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é <berrange@redhat.com>
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 <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <richard.henderson@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <richard.henderson@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <richard.henderson@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <armbru@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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é <berrange@redhat.com>
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 <richard.henderson@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <richard.henderson@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <richard.henderson@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <dave@treblig.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <richard.henderson@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Fixes: e69ee454b5f9 (monitor: Make current monitor a per-coroutine property) Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <richard.henderson@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 <pierrick.bouvier@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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é <berrange@redhat.com>
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 <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
# -----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 <gaosong@loongson.cn>" [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 <peter.maydell@linaro.org>
hw/display/vga-pci: Do not expose the 'global-vmstate' property
The "global-vmstate" property is 'false' by default, and was only
set to 'true' in the hw_compat_2_12[] array. We removed all machines
using that array. Stop exposing that property on the PCI devices.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501230129.2596-11-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
hw/audio/hda-codec: Remove HDAAudioState::use_timer field
The HDAAudioState::use_timer boolean was only set in the
hw_compat_2_12[] array, via the 'use-timer=false' property.
We removed all machines using that array, lets remove that
property and all the code around it, like the compatibility
callbacks.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501230129.2596-10-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
[thuth: Rebased the patch to current master branch, fixed conflicts] Signed-off-by: Thomas Huth <thuth@redhat.com>
The hw_compat_2_12[] array was only used by the pc-q35-2.12,
pc-i440fx-2.12 and s390-ccw-virtio-2.12 machines, which got
removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501230129.2596-9-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
The hw_compat_2_11[] array was only used by the pc-q35-2.11,
pc-i440fx-2.11 and s390-ccw-virtio-2.11 machines, which got
removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501230129.2596-5-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
hw/input/virtio-input: Remove VirtIOInputHID::wheel_axis field
The VirtIOInputHID::wheel_axis boolean was only set in the
hw_compat_2_10[] array, via the 'wheel-axis=false' property.
We removed all machines using that array, lets remove that
property and all the code around it. There is only one
virtio_input_config[] version for each device, rename it
removing the '_v2' suffix.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501230129.2596-4-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
The hw_compat_2_10[] array was only used by the pc-q35-2.10,
pc-i440fx-2.10 and s390-ccw-virtio-2.10 machines, which got
removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501230129.2596-3-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
The pc_compat_2_12[] array was only used by the pc-q35-2.12
and pc-i440fx-2.12 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501223522.99772-9-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
hw/i386/pc: Remove deprecated pc-q35-2.12 and pc-i440fx-2.12 machines
These machines has been supported for a period of more than 6 years.
According to our versioned machine support policy (see commit ce80c4fa6ff "docs: document special exception for machine type
deprecation & removal") they can now be removed.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501223522.99772-8-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
The pc_compat_2_11[] array was only used by the pc-q35-2.11
and pc-i440fx-2.11 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501223522.99772-7-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
hw/i386/pc: Remove deprecated pc-q35-2.11 and pc-i440fx-2.11 machines
These machines has been supported for a period of more than 6 years.
According to our versioned machine support policy (see commit ce80c4fa6ff "docs: document special exception for machine type
deprecation & removal") they can now be removed.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501223522.99772-6-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
The pc_compat_2_10[] array was only used by the pc-q35-2.10
and pc-i440fx-2.10 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501223522.99772-3-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
hw/i386/pc: Remove deprecated pc-q35-2.10 and pc-i440fx-2.10 machines
These machines has been supported for a period of more than 6 years.
According to our versioned machine support policy (see commit ce80c4fa6ff "docs: document special exception for machine type
deprecation & removal") they can now be removed.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501223522.99772-2-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
hw/i386/x86-iommu: Remove X86IOMMUState::pt_supported field
The X86IOMMUState::pt_supported boolean was only set in
the hw_compat_2_9[] array, via the 'pt=off' property. We
removed all machines using that array, lets remove that
property and all the code around it, always setting the
VTD_ECAP_PT capability.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-19-philmd@linaro.org>
[thuth: Dropped the hunks that were already merged via commit 31753d5a336f] Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-16-thuth@redhat.com>
hw/pci-bridge/gen_pcie_rp: Remove GenPCIERootPort::migrate_msix field
The GenPCIERootPort::migrate_msix boolean was only set in
the hw_compat_2_9[] array, via the 'x-migrate-msix=false'
property. We removed all machines using that array, lets
remove that property and all the code around it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-18-philmd@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-15-thuth@redhat.com>
hw/net/virtio-net: Remove VirtIONet::mtu_bypass_backend field
The VirtIONet::mtu_bypass_backend boolean was only set in
the hw_compat_2_9[] array, via the 'x-mtu-bypass-backend=off'
property. We removed all machines using that array, lets remove
that property and all the code around it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-17-philmd@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
[thuth: Adjusted patch for latest changes in the master branch] Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-14-thuth@redhat.com>
hw/i386/pc: Remove deprecated pc-q35-2.9 and pc-i440fx-2.9 machines
These machines has been supported for a period of more than 6 years.
According to our versioned machine support policy (see commit ce80c4fa6ff "docs: document special exception for machine type
deprecation & removal") they can now be removed.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-14-philmd@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-11-thuth@redhat.com>
VIRTIO_PCI_FLAG_INIT_PM was only used by the hw_compat_2_8[]
array, via the 'x-pcie-pm-init=off' property. We removed all
machines using that array, lets remove all the code around
VIRTIO_PCI_FLAG_INIT_PM (see commit 9a4c0e220d8 for similar
VIRTIO_PCI_FLAG_* enum removal).
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-11-philmd@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-10-thuth@redhat.com>
VIRTIO_PCI_FLAG_INIT_LNKCTL was only used by the hw_compat_2_8[]
array, via the 'x-pcie-lnkctl-init=off' property. We removed all
machines using that array, lets remove all the code around
VIRTIO_PCI_FLAG_INIT_LNKCTL (see commit 9a4c0e220d8 for similar
VIRTIO_PCI_FLAG_* enum removal).
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-10-philmd@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-9-thuth@redhat.com>
VIRTIO_PCI_FLAG_INIT_DEVERR was only used by the hw_compat_2_8[]
array, via the 'x-pcie-deverr-init=off' property. We removed all
machines using that array, lets remove all the code around
VIRTIO_PCI_FLAG_INIT_DEVERR (see commit 9a4c0e220d8 for similar
VIRTIO_PCI_FLAG_* enum removal).
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-9-philmd@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-8-thuth@redhat.com>
QEMU_PCIE_EXTCAP_INIT was only used by the hw_compat_2_8[]
array, via the 'x-pcie-extcap-init=off' property. We removed
all machines using that array, let's remove all the code around
QEMU_PCIE_EXTCAP_INIT.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-8-philmd@linaro.org>
[thuth: Don't remove pci_set_long(), execute it always instead] Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-7-thuth@redhat.com>
hw/block/pflash: Remove PFlashCFI01::old_multiple_chip_handling field
The PFlashCFI01::old_multiple_chip_handling boolean was only set
in the hw_compat_2_8[] array, via the 'old-multiple-chip-handling=on'
property. We removed all machines using that array, let's remove that
property and all the code around it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-7-philmd@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-6-thuth@redhat.com>
hw/i386/kvm: Remove KVMClockState::mach_use_reliable_get_clock field
The KVMClockState::mach_use_reliable_get_clock boolean was only
used by the pc-q35-2.8 and pc-i440fx-2.8 machines, which got removed.
Remove it, along with the 'x-mach-use-reliable-get-clock' property.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-5-philmd@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-4-thuth@redhat.com>
hw/i386/pc: Remove deprecated pc-q35-2.8 and pc-i440fx-2.8 machines
These machines has been supported for a period of more than 6 years.
According to our versioned machine support policy (see commit ce80c4fa6ff "docs: document special exception for machine type
deprecation & removal") they can now be removed.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250501210456.89071-2-philmd@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260225092024.794595-2-thuth@redhat.com>
Kevin Wolf [Thu, 19 Feb 2026 20:24:46 +0000 (21:24 +0100)]
mirror: Fix missed dirty bitmap writes during startup
Currently, mirror disables the block layer's dirty bitmap before its own
replacement is working. This means that during startup, there is a
window in which the allocation status of blocks in the source has
already been checked, but new writes coming in aren't tracked yet,
resulting in a corrupted copy:
1. Dirty bitmap is disabled in mirror_start_job()
2. Some request are started in mirror_top_bs while s->job == NULL
3. mirror_dirty_init() -> bdrv_co_is_allocated_above() runs and because
the request hasn't completed yet, the block isn't allocated
4. The request completes, still sees s->job == NULL and skips the
bitmap, and nothing else will mark it dirty either
One ingredient is that mirror_top_opaque->job is only set after the
job is fully initialized. For the rationale, see commit 32125b1460
("mirror: Fix access of uninitialised fields during start").
Fix this by giving mirror_top_bs access to dirty_bitmap and enabling it
to track writes from the beginning. Disabling the block layer's tracking
and enabling the mirror_top_bs one happens in a drained section, so
there is no danger of races with in-flight requests any more. All of
this happens well before the block allocation status is checked, so we
can be sure that no writes will be missed.
Cc: qemu-stable@nongnu.org Closes: https://gitlab.com/qemu-project/qemu/-/issues/3273 Fixes: 32125b14606a ('mirror: Fix access of uninitialised fields during start') Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20260219202446.312493-1-kwolf@redhat.com> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> Tested-by: Jean-Louis Dupond <jean-louis@dupond.be> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Antoine Damhet [Thu, 12 Feb 2026 16:27:24 +0000 (17:27 +0100)]
block/curl: fix concurrent completion handling
curl_multi_check_completion would bail upon the first completed
transfer even if more completion messages were available thus leaving
some in flight IOs stuck.
Rework a bit the loop to make the iterations clearer and drop the breaks.
The original hang can be somewhat reproduced with the following command:
Fixes: 1f2cead32443 ("curl: Ensure all informationals are checked for completion") Cc: qemu-stable@nongnu.org Signed-off-by: Antoine Damhet <adamhet@scaleway.com>
Message-ID: <20260212162730.440855-2-adamhet@scaleway.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Peter Krempa [Wed, 4 Feb 2026 13:15:44 +0000 (14:15 +0100)]
hmp_nbd_server_start: Don't ask for backing image data
'hmp_nbd_server_start' uses only the device name from the data returned
from 'qmp_query_block', thus no backing file information. Use the new
options to suppress asking for the unused parts to save on resources.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-ID: <df71ca72a96d870758695ac57772fcfb87dc8fa0.1770210044.git.pkrempa@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Peter Krempa [Wed, 4 Feb 2026 13:15:43 +0000 (14:15 +0100)]
block: Wire up 'flat' mode also for 'query-block'
Some time ago (commit facda5443f5a8) I've added 'flat' mode (which
omits 'backing-image' key in reply) to 'query-named-block-nodes' to
minimize the size of the returned JSON for deeper backing chains.
While 'query-block' behaved slightly better it turns out that in libvirt
we do call 'query-block' to figure out some information about the
block device (e.g. throttling info) but we don't look at the backing
chain itself.
Wire up 'flat' for 'query-block' so that libvirt can ask for an
abbreviated output. The implementation is much simpler as the internals
are shared with 'query-named-block-nodes'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <f4476e9f7e8fda74c02be3f806acaa9aa2df4d9a.1770210044.git.pkrempa@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Bounds check for marker.size doesn't account for the 12-byte marker
header, allowing zlib to read past the allocated buffer.
Move the check inside the has_marker block and subtract the marker size.
Fixes: CVE-2026-2243 Reported-by: Halil Oktay (oblivionsage) <cookieandcream560@gmail.com> Signed-off-by: Halil Oktay (oblivionsage) <cookieandcream560@gmail.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
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 <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Maydell [Mon, 2 Mar 2026 14:01:46 +0000 (14:01 +0000)]
Merge tag 'pull-request-2026-03-02' of https://gitlab.com/thuth/qemu into staging
* Remove qemu-system-microblazeel (qemu-system-microblaze can be used instead)
* Improve detection of the docker/podman binary
* Prevent a null pointer dereference during zpci hot unplug
* tag 'pull-request-2026-03-02' of https://gitlab.com/thuth/qemu:
gitlab: ensure docker output is always displayed in CI
tests/docker: allow display of docker output
tests/docker: add support for podman remote access
tests/docker: improve handling of docker probes
Remove the qemu-system-microblazeel target from the build
gitlab-ci: Remove the microblazeel target from the CI jobs
tests/qtest: Remove the microblazeel target from the qtests
tests/functional: Remove the microblazeel test
tests/functional: Make sure test case .py files are executable
s390x/pci: prevent null pointer dereference during zpci hot unplug
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This combines several batch streams that:
(1) Upstream the bsd-misc.c system calls:
quoatctl, reboot, getdtablesize, uuidgen, semget, semop, semctl, msgctl
(2) common-user drop __linux__ ifdef
(3) Remove NetBSD and OpenBSD specific code for bsd-user (hasn't built in years)
(4) Fix inotify issues on FreeBSD 15
(5) Fix issues with gdb on aarch64
All of thse have been reviewed, and the only problems with the check patch line
length and about added files.
# -----BEGIN PGP SIGNATURE-----
# Comment: GPGTools - https://gpgtools.org
#
# iQIzBAABCgAdFiEEIDX4lLAKo898zeG3bBzRKH2wEQAFAmmlD6EACgkQbBzRKH2w
# EQANZw//edwiQF/H+07EBKdZNF/QJsBwsH5OwHh/rgyq6OPUHWtu00gxNDFd/e/D
# O+FisLvDbNa9v2es1RX0lDzdgXRwi2LRIc4tMW3ifEjK7Jj8np09tfWkghwc2u9Z
# RShNxlCHfg/lTFkkm5wbHEpl1W1sImcLhYSLdoXAdUhK8lQOoUiFYOtg9s6xq6LH
# 3NHH4roY+HQE2zpK6gY45BsD1Fi3qdg5VNwTHkvcducdC5jjXnJ1UikL48zM72An
# LK8EqQfGx06RVkPgPyxTeUjniJj9SyixZjBD8YzqlmhSCt3RD4e0V+5/wd8YlPpI
# dBaYqzLSfft+vtJEqUyds/SilMHqf2brvJ9e2chwIqBlghxPb9GpPjHASDqk1/t8
# +ckFaOtdtamw0H8JFp1ixzFn7WLvUp3jpQJbSzZxmKwC0hZCxl/aXFKcq+gDg3k5
# 1wt/su+1zfb1Qjp8M8tKHLWy2/aXT/yY7IeWAk2hpOel3e4L9pDU6bsgQMz4kOE8
# WO6GHDu2YA688EArVL8ErTkKw04+mGdTMmjqrF00O/MWnW8LNKNTHIHaxWtCfXVv
# mHSUyHt94CoDtScwCdLmyZslHiO0XgUFhnK+EPd+sHyaAPu2uH6ezfFMRF8F1vs8
# WXsOnZArDg+r02PnltEjbIEOJ8t+tYTZqZ/3IKn2Gecixqhqdmc=
# =yPBa
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon Mar 2 04:18:41 2026 GMT
# gpg: using RSA key 2035F894B00AA3CF7CCDE1B76C1CD1287DB01100
# gpg: Good signature from "Warner Losh <wlosh@netflix.com>" [unknown]
# gpg: aka "Warner Losh <imp@bsdimp.com>" [unknown]
# gpg: aka "Warner Losh <imp@freebsd.org>" [unknown]
# gpg: aka "Warner Losh <imp@village.org>" [unknown]
# gpg: aka "Warner Losh <wlosh@bsdimp.com>" [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: 2035 F894 B00A A3CF 7CCD E1B7 6C1C D128 7DB0 1100
* tag 'bsd-user-2026q1-upstream-pull-request' of ssh://github.com/bsdimp/qemu: (27 commits)
bsd-user: update aarch64-bsd-user.mak gdb XML list
bsd-user: Add miscellaneous BSD syscall implementations
bsd-user: Add System V message queue syscalls
bsd-user: Implement System V semaphore calls
bsd-user: Add bsd-misc.c to build
bsd-user: Add message queue implementations
bsd-user: Add do_bsd_msgctl implementation
bsd-user: Add do_bsd___semctl implementation
bsd-user: Add do_bsd_semop implementation
bsd-user: Add do_bsd_semget implementation
bsd-user: Add do_bsd_uuidgen implementation
bsd-user: Add do_bsd_quotactl, do_bsd_reboot and do_bsd_getdtablesize
bsd-user: Add semaphore operation constants and structures
bsd-user: Add host_to_target_msqid_ds for msgctl(2)
bsd-user: Add target_to_host_msqid_ds for msgctl(2)
bsd-user: Add host_to_target_semid_ds for semctl(2)
bsd-user: Add target_to_host_semid_ds for semctl(2)
bsd-user: Add host_to_target_semarray for semaphore operations
bsd-user: Add target_to_host_semarray for semaphore operations
bsd-user: Add host_to_target_uuid for uuidgen(2)
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bibo Mao [Wed, 25 Feb 2026 01:41:31 +0000 (09:41 +0800)]
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 <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
Bibo Mao [Wed, 25 Feb 2026 01:41:30 +0000 (09:41 +0800)]
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 <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
Bibo Mao [Wed, 25 Feb 2026 01:41:29 +0000 (09:41 +0800)]
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 <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
Bibo Mao [Wed, 25 Feb 2026 01:41:28 +0000 (09:41 +0800)]
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 <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
Bibo Mao [Wed, 25 Feb 2026 01:41:27 +0000 (09:41 +0800)]
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 <maobibo@loongson.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Song Gao <gaosong@loongson.cn>
Bibo Mao [Mon, 19 Jan 2026 10:07:02 +0000 (18:07 +0800)]
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 <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
Bibo Mao [Mon, 19 Jan 2026 10:07:01 +0000 (18:07 +0800)]
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 <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
Peter Maydell [Mon, 2 Mar 2026 09:13:34 +0000 (09:13 +0000)]
Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
* target/alpha: Fix for record/replay issue
* accel/nitro: New Nitro Enclaves accelerator
* generic + kvm: add support for rebuilding VMs on reset
* audio requirements cleanup
* vmmouse: Fix hypercall clobbers
* rust: use checked_div to make clippy happy
* kvm: Don't clear pending #SMI in kvm_get_vcpu_events
* target/i386/emulate: rework MMU code, many fixes
* target/i386/whpx: replace winhvemulation with target/i386/emulate
* target/i386/whpx: x2apic support
* target/i386/whpx: vapic support
* kvm: support for the "ignore guest PAT" quirk
* target/i386: add ITS_NO bit for the arch-capabilities MSR
* target/i386: add MBEC bit for nested VMX
* tag 'pull-ppc-for-11.0-20260302' of https://gitlab.com/harshpb/qemu:
MAINTAINERS: Add self as reviewer for PowerPC TCG
ppc/pnv: Add OCC FLAG registers
ppc/pnv: Support for SECURITY_SWITCH XSCOM register access
target/ppc/translate: Fix TCG debug assert translating CLRBWIBC
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
gitlab: ensure docker output is always displayed in CI
Set the new $(DOCKER_V) variable from the previous commit, so that any
CI jobs invoking docker will show the full stdout content. This improves
the ability to diagnose any build failures in CI that involve docker.
For example, when a 'docker build' command fails, it lets us see which
command in the Dockerfile failed and why.
Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260210163556.713841-5-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
The --quiet command is used with docker unless V=1 is passed to make,
and as a result stdout from docker is never visible by default, making
it hard to diagnose failures building / running containers.
Meanwhile passing V=1 is undesirable as that makes the entire build
system verbose.
Introduce a $(DOCKER_V) make variable which is initialized from $(V)
It is thus possible to display docker output without also enabling
make verbose output.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260210163556.713841-4-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
tests/docker: add support for podman remote access
When a developer's environment is already within a podman container it
is not possible to use 'podman' again to create containers. It will
usually result in wierd errors such as:
Error: fatal error, invalid internal status, unable to create a new pause process: cannot re-exec process to join the existing user namespace. Try running "podman system migrate" and if that doesn't work reboot to recover
Podman offers the ability to talk to a daemon outside the container,
however, which could be leveraged by QEMU.
This can be used by invoking "podman --remote", or equivalently the
separate "podman-remote" binary:
The current 'podman version' check is insufficient to detect the
inability to launch containers, so it is replaced with the stronger
'podman info' check.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260210163556.713841-3-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
The docker.py script has logic to guess the container command and
detects one of
* docker
* sudo -n docker
* podman
but the "docker.py probe" command then throws away the detected argv
and prints a slightly different argv based solely on the detected
argv[0]. The result is that 'probe' will print
* docker
* sudo docker
* podman
which means that if sudo was detected & the result of 'probe' were
used directly, it would end up prompting for password interaction
every time.
The 'configure' script, however, runs 'probe' and then throws away
the printed argv again, reporting only 'podman' or 'docker', which
is used to set the $(RUNC) variable for tests/docker/Makefile.include
which is in turn used to pass --engine to docker.py. So the docker.py
command will re-detect the need for 'sudo -n' and use it correctly
The problem with this is that some commands in Makefile.include do
not call docker.py at all, they invoke $(RUNC) directly. Since
configure threw away the 'sudo' command prefix Makefile.in won't
be adding either 'sudo' or 'sudo -n', it'll just run plain 'docker'
which is wrong.
This commit sanitizes things so that the 'docker.py probe' prints
out the exact detected ARGV, and configure fully preserves this
ARGV when setting $(RUNC). Since "$(RUNC)" is no longer just a bare
engine name, however, we must now also set the $(CONTAINER_ENGINE)
variable for Makefile.include so it can pass something sane to
the --engine arg for docker.py
Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260210163556.713841-2-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Thu, 26 Feb 2026 08:46:06 +0000 (09:46 +0100)]
Remove the qemu-system-microblazeel target from the build
It's been deprecated since two releases, so it should be fine to
remove this now. Users can use the qemu-system-microblaze binary
instead that can handle both endiannesses now.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260226084608.11251-5-thuth@redhat.com>
Thomas Huth [Thu, 26 Feb 2026 08:46:05 +0000 (09:46 +0100)]
gitlab-ci: Remove the microblazeel target from the CI jobs
Since we're going to remove the qemu-system-microblazeel binary,
remove the related tests from the CI jobs now (or switch to "microblaze"
where it is appropriate).
Note: Since "build-system-ubuntu" does not have as many targets as
"build-system-fedora", we turn the "microblazeel-softmmu" into a
"microblaze-softmmu" in the ubuntu job, and remove the corresponding
target from the fedora job instead, so that the load is more balanced
now.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260226084608.11251-4-thuth@redhat.com>
Thomas Huth [Thu, 26 Feb 2026 08:46:04 +0000 (09:46 +0100)]
tests/qtest: Remove the microblazeel target from the qtests
The "petalogix-ml605" boot-serial-test can be run with the
"microblaze" target. The remaining tests can simply be dropped
now that we are going to remove the "microblazeel" target.
Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260226084608.11251-3-thuth@redhat.com>
Thomas Huth [Thu, 26 Feb 2026 08:46:03 +0000 (09:46 +0100)]
tests/functional: Remove the microblazeel test
We are going to remove the microblazeel target, so the test is not
required anymore. The little endian mode is tested already via the
"microblaze" target, so we don't lose any test coverage here.
While we're at it, simplify the "microblaze" target test now (in the
file tests/functional/microblaze/test_s3adsp1800.py) since we don't
need the separate super-class here anymore.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260226084608.11251-2-thuth@redhat.com>
Peter Maydell [Thu, 12 Feb 2026 15:12:58 +0000 (15:12 +0000)]
tests/functional: Make sure test case .py files are executable
The top-level test python scripts in tests/functional are supposed to
be marked executable; "make check-functional" doesn't care about
this, but it allows them to be run as standalone executables to
exercise a single test, as docs/devel/testing/functional.rst
describes.
A couple of files have got into the tree without the executable
bit set: fix them.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260212151258.1750268-1-peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Aby Sam Ross [Fri, 13 Feb 2026 06:34:43 +0000 (01:34 -0500)]
s390x/pci: prevent null pointer dereference during zpci hot unplug
vfio-pci hostdev realize during zpci hot plug fails (in `vfio_pci_realize()`)
if the vfio group file in `/dev/vfio/` lacks appropriate permissions and the
hostdev[/properties] addition doesn't reach the point where it could be
associated with previously added zpci device (in `s390_pcihost_plug()`).
As a result, zpci iommu pointer remains null. The zpci hot unplug following the
failed hostdev addition assumes zpci iommu pointer was assigned and tries to
make use of it to end the dma count resulting in a null pointer dereference.
In the non-hotplug scenario, `qdev_unplug()` for the zpci device is not called
after hostdev addition failure and this issue is not encountered.
All other uses of zpci iommu without null check happens after both the zpci and
hostdev(pci) devices are plugged and are safe from null dereference.
Fixes: 37fa32de7073 ("s390x/pci: Honor DMA limits set by vfio") Signed-off-by: Aby Sam Ross <abysamross@ibm.com> Acked-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Suggested-by: Halil Pasic <pasic@linux.ibm.com>
Message-ID: <b45cefc3147c2c8446772dab0f53d030fb92406a.1770963150.git.abysamross@ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
projects / thirdparty / qemu.git / log
