In replay_char_read_all_load() we get a buffer and size from the
replay log. We know the size has to fit an int because of how we
write the log. However the way we assert this is wrong: we cast the
size_t from replay_get_array() to an int and then check that it is
non-negative. This misses cases where an over-large size is
truncated into a positive value by the cast.
Replace the assertion with checking that the size is in-range
before doing the cast.
Coverity complained about the possible overflow: CID 1643440.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251124173407.50124-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The error message changes from
vhost-vsock: failed to open vhost device: REASON
to
Could not open '/dev/vhost-vsock': REASON
I think the exact file name is more useful to know than the file's
purpose.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251121121438.1249498-8-armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The error message changes from
vhost-scsi: open vhost char device failed: REASON
to
Could not open '/dev/vhost-scsi': REASON
I think the exact file name is more useful to know than the file's
purpose.
We could put back the "vhost-scsi: " prefix with error_prepend(). Not
worth the bother.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251121121438.1249498-7-armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The error message changes from
open FILENAME failed
to
Could not create 'FILENAME': REASON
where REASON is the value of strerror(errno).
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251121121438.1249498-3-armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
"Unsupported 'parameter=1' SMP configuration" was proposed to be
deprecated in the commit 54c4ea8f3a ("hw/core/machine-smp: Deprecate
unsupported "parameter=1" SMP configurations").
But the related code was reverted later in the commit 9d7950edb0
("hw/core: allow parameter=1 for SMP topology on any machine").
Thus, this SMP behavior is still valid and is not actually deprecated.
Remove outdated document descriptions.
Reported-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20251121084416.1031466-1-zhao1.liu@intel.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
msix_init() and msix_init_exclusive_bar() take an "unsigned short"
argument for the number of MSI-X vectors to try to use. This is big
enough for the maximum permitted number of vectors, which is 2048.
Unfortunately, we have several devices (most notably virtio) which
allow the user to specify the desired number of vectors, and which
use uint32_t properties for this. If the user sets the property to a
value that is too big for a uint16_t, the value will be truncated
when it is passed to msix_init(), and msix_init() may then return
success if the truncated value is a valid one.
The resulting mismatch between the number of vectors the msix code
thinks the device has and the number of vectors the device itself
thinks it has can cause assertions, such as the one in issue 2631,
where "-device virtio-mouse-pci,vectors=19923041" is interpreted by
msix as "97 vectors" and by the virtio-pci layer as "19923041
vectors"; a guest attempt to access vector 97 thus passes the
virtio-pci bounds checking and hits an essertion in
msix_vector_use().
Avoid this by making msix_init() and its wrapper function
msix_init_exclusive_bar() take the number of vectors as a uint32_t.
The erroneous command line will now produce the warning
qemu-system-i386: -device virtio-mouse-pci,vectors=19923041:
warning: unable to init msix vectors to 19923041
and proceed without crashing. (The virtio device warns and falls
back to not using MSIX, rather than complaining that the option is
not a valid value this is the same as the existing behaviour for
values that are beyond the MSI-X maximum possible value but fit into
a 16-bit integer, like 2049.)
To ensure this doesn't result in potential overflows in calculation
of the BAR size in msix_init_exclusive_bar(), we duplicate the
nentries error-check from msix_init() at the top of
msix_init_exclusive_bar(), so we know nentries is sane before we
start using it.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2631
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251107131044.1321637-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Currently the code that reads the qtest protocol commands insists
that every input line has a command. If it receives a line with
nothing but whitespace it will trip an assertion in
qtest_process_command().
This is a little awkward for the case where we are feeding qtest a
set of bug-reproduction commands via standard input or a file,
because it means you need to be careful not to leave a blank line at
the start or the end when cutting and pasting the command sequence
from a bug report.
Change the code to allow and ignore blank lines in the input.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20251106151959.1088095-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
This qemu-iotests test case is based on the reproducer that Jean-Louis
Dupond <jean-louis@dupond.be> shared in
https://gitlab.com/qemu-project/qemu/-/issues/3127.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20251007141700.71891-4-stefanha@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Since commit 5634622bcb ("file-posix: allow BLKZEROOUT with -t
writeback"), qemu-img create errors out on a Linux loop block device
with a 4 KB sector size:
# dd if=/dev/zero of=blockfile bs=1M count=1024
# losetup --sector-size 4096 /dev/loop0 blockfile
# qemu-img create -f raw /dev/loop0 1G
Formatting '/dev/loop0', fmt=raw size=1073741824
qemu-img: /dev/loop0: Failed to clear the new image's first sector: Invalid argument
Use the pwrite_zeroes_alignment block limit to avoid misaligned
fallocate(2) or ioctl(BLKZEROOUT) in the block/file-posix.c block
driver.
Cc: qemu-stable@nongnu.org
Fixes: 5634622bcb ("file-posix: allow BLKZEROOUT with -t writeback")
Reported-by: Jean-Louis Dupond <jean-louis@dupond.be>
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/3127
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20251007141700.71891-3-stefanha@redhat.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Linux block devices require write zeroes alignment whereas files do not.
It may come as a surprise that block devices opened in buffered I/O mode
require the alignment for write zeroes requests although normal
read/write requests do not.
Therefore it is necessary to populate the pwrite_zeroes_alignment field.
Cc: qemu-stable@nongnu.org
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20251007141700.71891-2-stefanha@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
When new requests arrive at a BlockBackend that is currently drained,
these requests are queued until the drain section ends.
There is a race window between blk_root_drained_end() waking up a queued
request in an iothread from the main thread and blk_wait_while_drained()
actually being woken up in the iothread and calling blk_inc_in_flight().
If the BlockBackend is drained again during this window, drain won't
wait for this request and it will sneak in when the BlockBackend is
already supposed to be quiesced. This causes assertion failures in
bdrv_drain_all_begin() and can have other unintended consequences.
Fix this by increasing the in_flight counter immediately when scheduling
the request to be resumed so that the next drain will wait for it to
complete.
Cc: qemu-stable@nongnu.org
Reported-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20251119172720.135424-1-kwolf@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Tested-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
When there is no display device on qemu machine,
and user only access qemu by remote vnc.
At the same time user input `info vnc` by QMP,
the qemu will abort.
To avoid the abort above, I add display device check,
when query vnc info in qmp_query_vnc_servers().
Reviewed-by: Marc-AndréLureau <marcandre.lureau@redhat.com>
Signed-off-by: Alano Song <AlanoSong@163.com>
[ Marc-André - removed useless Error *err ]
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20251125131955.7024-1-AlanoSong@163.com>
Per the PCI spec 3.0, in section 6.2.5.1, "Address Maps":
A 32-bit register can be implemented to support a single
memory size that is a power of 2 from 16 bytes to 2 GB.
Add a check in nvme_init_pmr(), returning an error if the
PMR region size is too small; and update the QTest.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Klaus Jensen <k.jensen@samsung.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Set the protection information format (pif) only in the formats that can
support the larger guard types, and update the current in-use format
information when the user changes it.
Signed-off-by: Keith Busch <kbusch@kernel.org>
[k.jensen: fix missing braces and wrong indentation]
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Coverity complains about a possible copy-paste error in the verification
of the namespace atomic parameters (CID 1642811). While the check is
correct, the code (and the intention) is unclear.
Fix this by reworking how the parameters are verified. Peter also
identified that the realize function was not correctly erroring out if
parameters were misconfigured, so fix that too.
Lastly, change the error messages to be more describing.
Coverity: CID 1642811
Fixes: bce51b8370 ("hw/nvme: add atomic boundary support")
Fixes: 3b41acc962 ("hw/nvme: enable ns atomic writes")
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
'in' will be -1 when file->in is unset. Let's not try to close
invalid fd.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Coverity: CID 1630444
Fixes: 69620c091d "chardev: qemu_chr_open_fd(): add errp"
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20251014145029.949285-1-vsementsov@yandex-team.ru>
Since commit f626116f ("ui/vdagent: factor out clipboard peer
registration"), the QEMU clipboard serial is reset whenever the vdagent
chardev receives the guest caps. This triggers a CHR_EVENT_CLOSED which
is handled by virtio_serial_close() to notify the guest.
The "reconnection logic" is there to reset the agent when a
client (dbus, spice etc) reconnects, or the agent is restarted.
It is required to sync the clipboard serials and to prevent races or
loops due to clipboard managers on both ends (but this is not
implemented by windows vdagent).
The Unix agent has been reconnecting without resending caps, thus
working with this approach.
However, the Windows agent does not seem to have a way to handle
VIRTIO_CONSOLE_PORT_OPEN=0 event and do not receive further data...
Let's not trigger this disconnection/reset logic if the agent does not
support VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL.
Fixes: f626116f ("ui/vdagent: factor out clipboard peer registration")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reported-by: Lucas Kornicki <lucas.kornicki@nutanix.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Tested-by: Lucas Kornicki <lucas.kornicki@nutanix.com>
With the latest updates the last year has been made possible by:
Top changeset contributors by employer
Linaro 2959 (37.0%)
Red Hat 1919 (24.0%)
Intel 313 (3.9%)
(None) 308 (3.9%)
ASPEED Technology Inc. 231 (2.9%)
Loongson Technology 227 (2.8%)
IBM 192 (2.4%)
Oracle 187 (2.3%)
Nutanix 133 (1.7%)
Academics (various) 99 (1.2%)
Top lines changed by employer
Linaro 109812 (31.8%)
Red Hat 91050 (26.4%)
ASPEED Technology Inc. 11811 (3.4%)
Intel 10606 (3.1%)
IBM 10146 (2.9%)
(None) 8965 (2.6%)
Oracle 8574 (2.5%)
Loongson Technology 7614 (2.2%)
Nutanix 7404 (2.1%)
Microsoft 6927 (2.0%)
Employers with the most hackers (total 433)
Red Hat 54 (12.5%)
IBM 30 (6.9%)
Intel 17 (3.9%)
(None) 13 (3.0%)
AMD 13 (3.0%)
Google 11 (2.5%)
Rivos Inc 10 (2.3%)
Linaro 9 (2.1%)
Oracle 8 (1.8%)
Huawei 8 (1.8%)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmkkKsAACgkQ+9DbCVqe
KkRbcQgAhc2I0HQa9fqFnp8vAZPMEEp3FFuPf1Dhwl4SWP95uZe/giooFyUhoZjw
fmLu3V+Tza1oX9ymgHcbGu465jgIORotIG9c2jfTNStbWQWMLT+3fsS3+/9oNgry
TtTNrSR2RpcUvnOWbMCPm68FiekQEmm4lbzNjh5uuGb6IddFyP/gZatbdMw3KzaX
kYKnlV6Ul5wBjzfH68paRfC1ZcM0/iPy5EbK3FhPVozpA3fV729ZR535WnFHNjc9
Gk6+oN2o4KQnvgSBY00NNnKUMcvMnvg3LSgmd2YUWh3O5jfVBbzaebP06HgfjLI3
WwBdlAnhAQRFZqJhiH7mCVmJhuwigQ==
=OPEI
-----END PGP SIGNATURE-----
Merge tag 'pull-10.2-gitdm-241125-1' of https://gitlab.com/stsquad/qemu into staging
gitdm updates for 2025
With the latest updates the last year has been made possible by:
Top changeset contributors by employer
Linaro 2959 (37.0%)
Red Hat 1919 (24.0%)
Intel 313 (3.9%)
(None) 308 (3.9%)
ASPEED Technology Inc. 231 (2.9%)
Loongson Technology 227 (2.8%)
IBM 192 (2.4%)
Oracle 187 (2.3%)
Nutanix 133 (1.7%)
Academics (various) 99 (1.2%)
Top lines changed by employer
Linaro 109812 (31.8%)
Red Hat 91050 (26.4%)
ASPEED Technology Inc. 11811 (3.4%)
Intel 10606 (3.1%)
IBM 10146 (2.9%)
(None) 8965 (2.6%)
Oracle 8574 (2.5%)
Loongson Technology 7614 (2.2%)
Nutanix 7404 (2.1%)
Microsoft 6927 (2.0%)
Employers with the most hackers (total 433)
Red Hat 54 (12.5%)
IBM 30 (6.9%)
Intel 17 (3.9%)
(None) 13 (3.0%)
AMD 13 (3.0%)
Google 11 (2.5%)
Rivos Inc 10 (2.3%)
Linaro 9 (2.1%)
Oracle 8 (1.8%)
Huawei 8 (1.8%)
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmkkKsAACgkQ+9DbCVqe
# KkRbcQgAhc2I0HQa9fqFnp8vAZPMEEp3FFuPf1Dhwl4SWP95uZe/giooFyUhoZjw
# fmLu3V+Tza1oX9ymgHcbGu465jgIORotIG9c2jfTNStbWQWMLT+3fsS3+/9oNgry
# TtTNrSR2RpcUvnOWbMCPm68FiekQEmm4lbzNjh5uuGb6IddFyP/gZatbdMw3KzaX
# kYKnlV6Ul5wBjzfH68paRfC1ZcM0/iPy5EbK3FhPVozpA3fV729ZR535WnFHNjc9
# Gk6+oN2o4KQnvgSBY00NNnKUMcvMnvg3LSgmd2YUWh3O5jfVBbzaebP06HgfjLI3
# WwBdlAnhAQRFZqJhiH7mCVmJhuwigQ==
# =OPEI
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 24 Nov 2025 01:52:00 AM PST
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [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: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-10.2-gitdm-241125-1' of https://gitlab.com/stsquad/qemu:
contrib/gitdm: add more individual contributors
contrib/gitdm: add mapping for Nutanix
contrib/gitdm: add mapping for Eviden
contrib/gitdm: add University of Tokyo to academic group
contrib/gitdm: add group-map for Microsoft
contrib/gitdm: add group-map for Huawei
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
In fimd_update_memory_section() we attempt ot find and map part of
the RAM MR which backs the framebuffer, based on guest-configurable
size and start address.
If the guest configures framebuffer settings which result in a
zero-sized framebuffer, we hit an assertion(), because
memory_region_find() will return a NULL mem_section.mr.
Explicitly check for the zero-size case and treat this as a
guest error.
Because we now have a code path which can reach error_return without
calling memory_region_find to set w->mem_section, we must NULL out
w->mem_section.mr after the unref of the old MR, so that error_return
does not incorrectly double-unref the old MR.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1407
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20251107143913.1341358-1-peter.maydell@linaro.org
For M-profile cores which support TrustZone, there are some memory
areas which are "NS aliases" -- a Secure access to these addresses
really performs an NS access to a different part of the device. We
implement these using MemoryRegionOps read and write functions which
pass the access on with adjusted attributes using
memory_region_dispatch_read() and memory_region_dispatch_write().
Since the MR we are dispatching to is owned by the same device that
owns the NS-alias MR (the TYPE_ARMV7M container object), this trips
the reentrancy-guard that is applied by access_with_adjusted_size().
Mark the NS alias MemoryRegions as disable_reentrancy_guard; this is
safe because v7m_sysreg_ns_read() and v7m_sysreg_ns_write() do not
touch any of the device's state. (Any further reentrancy attempts by
the underlying MR will still be caught.)
Without this fix, an attempt to read from an address like 0xe002e010,
which is a register in the NS systick alias, will fail and provoke
qemu-system-arm: warning: Blocked re-entrant IO on MemoryRegion: v7m_systick at addr: 0x0
We didn't notice this earlier because almost all code accesses
the registers and systick via the non-alias addresses; the NS
aliases are only need for the rarer case of Secure code that needs
to manage the NS timer or system state on behalf of NS code.
Note that although the v7m_systick_ops read and write functions
also call memory_region_dispatch_{read,write}, this MR does not
need to have the reentrancy-guard disabled because the underlying
MR that it forwards to is owned by a different device (the
TYPE_SYSTICK timer device).
Reported via a stackoverflow question:
https://stackoverflow.com/questions/79808107/what-this-error-is-even-about-qemu-system-arm-warning-blocked-re-entrant-io
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20251114155304.2662414-1-peter.maydell@linaro.org
FIMD_VIDWADD0_END is defined twice, keep only one.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20251121093509.25088-1-philmd@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
I only add names explicitly acked as individual contributors.
Acked-by: Sean Wei <me@sean.taipei>
Acked-by: William Kosasih <kosasihwilliam4@gmail.com>
Message-ID: <20251119113953.1432303-10-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
We have a number of hackers from Nutanix, make sure they are grouped
together.
Reviewed-by: Jon Kohler <jon@nutanix.com>
Reviewed-by: John Levon <john.levon@nutanix.com>
Message-ID: <20251119113953.1432303-8-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
From Akihiko:
I and my colleagues use QEMU for academic microarchitecture
researches so it is indeed to appropriate to have an entry here.
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20251119113953.1432303-6-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
While we do see contributions from the top-level domain we want to
catch the linux.microsoft subdomain and those contributors also post
via other addresses.
Cc: Magnus Kulke <magnuskulke@linux.microsoft.com>
Acked-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20251119113953.1432303-4-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
While we do see contributions from the top-level domain some
contributors also post via other addresses.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Message-ID: <20251119113953.1432303-3-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
This patch updates the ASPEED PCIe Root Port capability layout and interrupt
handling to match the hardware-defined capability structure as documented in
the PCI Express Controller (PCIE) chapter of the ASPEED SoC datasheet.
The following capability offsets and fields are now aligned with the actual
hardware implementation (validated using EVB config-space dumps via
'lspci -s <bdf> -vvv'):
- Added MSI capability at offset 0x50 and enabled 1-vector MSI support
- Added PCI Express Capability structure at offset 0x80
- Added Secondary Subsystem Vendor ID (SSVID) at offset 0xC0
- Added AER capability at offset 0x100
- Implemented aer_vector() callback and MSI init/uninit hooks
- Updated Root Port SSID to 0x1150 to reflect the platform default
Enabling MSI is required for proper PCIe Hotplug event signaling. This change
improves correctness and ensures QEMU Root Port behavior matches the behavior
of ASPEED hardware and downstream kernel expectations.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Fixes: 2af56518fa ("hw/pci-host/aspeed: Add AST2600 PCIe Root Port and make address configurable")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Nabih Estefan <nabihestefan@google.com>
Tested-by: Nabih Estefan <nabihestefan@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20251121050108.3407445-2-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
It did not connect SPI IRQ to the Interrupt Controller, so even the SPI
model raised the IRQ, the interrupt was not received. The CPU therefore
did not trigger an interrupt via the controller, and the firmware never
received the interrupt.
Fixes: 356b230ed1 ("aspeed/soc: Add AST1030 support")
Fixes: f25c0ae107 ("aspeed/soc: Add AST2600 support")
Fixes: 5dd883ab06 ("aspeed/soc: Add AST2700 support")
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/20251106084925.1253704-2-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
- Zhijian's COLO regression fix (since 10.0)
- Matthew's fix to avoid crash on wrong list manipulations
- Markus's error report leak fix and cleanups
- Peter's qtest changes to merge memory_backend and use_shmem
-----BEGIN PGP SIGNATURE-----
iIgEABYKADAWIQS5GE3CDMRX2s990ak7X8zN86vXBgUCaSEDHxIccGV0ZXJ4QHJl
ZGhhdC5jb20ACgkQO1/MzfOr1wZSAAEAmixKaiIm+w0vp7YiNNTeq22+y6Eo7ran
K7g5jCswEH8BAOTPeh7AHBN3L2Zi3tw58Rqyh08kiY/x0/s8DE7sL0wM
=3a75
-----END PGP SIGNATURE-----
Merge tag 'staging-pull-request' of https://gitlab.com/peterx/qemu into staging
Migration pull for rc2
- Zhijian's COLO regression fix (since 10.0)
- Matthew's fix to avoid crash on wrong list manipulations
- Markus's error report leak fix and cleanups
- Peter's qtest changes to merge memory_backend and use_shmem
# -----BEGIN PGP SIGNATURE-----
#
# iIgEABYKADAWIQS5GE3CDMRX2s990ak7X8zN86vXBgUCaSEDHxIccGV0ZXJ4QHJl
# ZGhhdC5jb20ACgkQO1/MzfOr1wZSAAEAmixKaiIm+w0vp7YiNNTeq22+y6Eo7ran
# K7g5jCswEH8BAOTPeh7AHBN3L2Zi3tw58Rqyh08kiY/x0/s8DE7sL0wM
# =3a75
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 21 Nov 2025 04:26:07 PM PST
# gpg: using EDDSA key B9184DC20CC457DACF7DD1A93B5FCCCDF3ABD706
# gpg: issuer "peterx@redhat.com"
# gpg: Good signature from "Peter Xu <xzpeter@gmail.com>" [unknown]
# gpg: aka "Peter Xu <peterx@redhat.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: B918 4DC2 0CC4 57DA CF7D D1A9 3B5F CCCD F3AB D706
* tag 'staging-pull-request' of https://gitlab.com/peterx/qemu:
tests/migration-test: Use MEM_TYPE_MEMFD for memory_backend
tests/migration-test: Add MEM_TYPE_SHMEM
tests/migration-test: Merge shmem_opts into memory_backend
tests/migration-test: Introduce MemType
migration/postcopy-ram: Improve error reporting after loadvm failure
migration: Use warn_reportf_err() where appropriate
migration: Plug memory leaks after migrate_set_error()
migration: set correct list pointer when removing notifier
migration: Fix transition to COLO state from precopy
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
The only two users of memory_backend as of now (cpr-exec, cpr-transfer)
uses memfd as backend, now we fully support it. We can move memory_backend
usage to mem_type and drop it.
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20251117223908.415965-5-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
Add memfd support for mem_type. Will be used to replace memory_backend.
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20251117223908.415965-4-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
The two parameters are more or less duplicated in migrate_args(). They all
describe the memory type. When one is used, the other is not.
mem_type currently uses numa parameter to specify the memory backend, while
memory_backend (the two users of such uses "-machine memory-backend=ID").
This patch merges the use of the two variables so that we always generate a
memory object string and put it into "memory_backend" variable. Now we can
drop shmem_opts parameter in the function.
Meanwhile we always use a memory-backend-* no matter which mem type is
used. This brings mem_type to be aligned with memory_backend usage, then
we stick with this as this is flexible enough.
This paves way that we merge mem_type and memory_backend in MigrateStart.
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20251117223908.415965-3-peterx@redhat.com
[peterx: move MEM_TYPE_ANON case upper, per juraj]
Signed-off-by: Peter Xu <peterx@redhat.com>
Some migration tests need to be run with shmem, the rest by default use
anonymous memory.
Introduce MemType and replace use_shmem with such a enumeration. This
prepares for a 3rd type of memory to be tested for migration.
Careful readers may also already notice that MigrateStart has another field
called memory_backend, which makes the whole "memory type" definition
convoluted. That'll be merged into MemType soon in a follow up patch.
When doing this, introduce some migrate_mem_type_*() helpers to do the
work for each memory type.
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20251117223908.415965-2-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
One of two error messages show __func__. Drop it; it doesn't help
users, and developers can grep for the message. This also permits
de-duplicating the code to prepend to the error message.
Both error messages show a numeric error code. I doubt that's
helpful, but I'm leaving it alone.
Use error_append_hint() for explaining that some dirty bitmaps may be
lost. Polish the prose.
Don't faff around with g_clear_pointer(), it's not worth its keep
here.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20251115083500.2753895-4-armbru@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
migrate_set_error(s, err) stores a copy of @err in @s. The original
@err is not freed. Most callers free it immediately. Some callers
free it later, or pass it on. And some leak it. Fix those.
Perhaps migrate_set_error(s, err) should take ownership of @err. The
callers that free it immediately would become simpler, and avoid a
copy and a deallocation. The others would have to pass
error_copy(err).
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Link: https://lore.kernel.org/r/20251115083500.2753895-2-armbru@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
In migration_remove_notifier(), g_slist_remove() will search for and
potentially remove an entry from the specified list. The return value
should be used to update the potentially-changed head pointer of the
list that was just searched (migration_state_notifiers[mode]) instead
of the migration blockers list.
Fixes: dc79c7d5e1 ("migration: multi-mode notifier")
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/r/20251113213545.513453-1-mjrosato@linux.ibm.com
Signed-off-by: Peter Xu <peterx@redhat.com>
Commit 4881411136 ("migration: Always set DEVICE state") set a new DEVICE
state before completed during migration, which broke the original transition
to COLO. The migration flow for precopy has changed to:
active -> pre-switchover -> device -> completed.
This patch updates the transition state to ensure that the Pre-COLO
state corresponds to DEVICE state correctly.
Cc: qemu-stable <qemu-stable@nongnu.org>
Fixes: 4881411136 ("migration: Always set DEVICE state")
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Zhang Chen <zhangckid@gmail.com>
Tested-by: Zhang Chen <zhangckid@gmail.com>
Link: https://lore.kernel.org/r/20251104013606.1937764-1-lizhijian@fujitsu.com
Signed-off-by: Peter Xu <peterx@redhat.com>
