- fix the logical CHS translation a guest selects with INITIALIZE
DEVICE PARAMETERS: reject a translation the device may not accept
instead of dying on a division by zero, report the default
translation in IDENTIFY DEVICE words 1, 3 and 6 and the one in
effect in words 54 to 58, keep those words in sync when the
translation changes, migrate both the translation and the SET
FEATURES 0xCC revert flag, and return the power-on defaults on a
hardware reset rather than on every reset
- harden the IDE and AHCI state a guest or an incoming migration
stream can reach: reject an out-of-range PIO transfer window on
load, refuse a PIO transfer with no command header, clear cur_cmd
when the command list is unmapped, treat a failed PRDT walk as a
transfer failure, reject a command header with an invalid FIS
length, and drain the ports on teardown so that a request cannot
outlive an unplug
- report ATAPI UDMA5 with a matching standard and cable
- extend the IDE/AHCI qtest coverage for all of the above
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Stefan Hajnoczi <stefanha@redhat.com>
CC: John Snow <jsnow@redhat.com>
CC: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEEC66qh9MCCtwRUOUfXgdxtstmbKsFAmqOyM4PHGRlbkBvcGVu
dnoub3JnAAoJEF4HcbbLZmyrGSUP+wR5KLZXUCKwEXDM95UnUiDFQQUNO0Ko7XGv
v8hHnTWRb3pvkIh/lJ9ECWPw0NPRKjugkSm9IGDUCndgw6+AbPOTP+tfJXFNK965
NFisLDoJCcPrrFNCL+T6EQyPBI2GG1vl9t4bg75GeT55WTUiK4Cv0710COZMV3kc
RlN3LzxCKLqc1wSGcqOLyObKTw97vL5pmB/xcOn/ciN1vOm4d5jgzvs1NqFcO1CF
btlqGisG9aRlqecKRgKGeLCGXtUoYq0MBuddsMeDSLD/H4FeZ1W0qYb/e2Zv97Bn
pdAyKb7Fs6OXV77qSUU5N1tSzALG+mn92BegHoyvuK/YRc8eDdwsiB8+OE7XHRbZ
Atewt2CVfej+lyZH5LHe72esWrNqpcHSwvTpvP26oxJq3qwUXynKh8VqUnnIwEIa
i1Y7ATnIGXNd1+w68Gk0TDu2zByUPVi4dw91hQR80YY2L9ZWwN5N2u3WCo81ZpAs
8hFk44vCAtGtfRZdLPbIboMfVLExRiBIwfNxJNy7btYQLWkvI05s8K5OmyBXeCwh
rtMQi9745BGcMVCtTIAiUjO/EHEkGtFaAs3JUdN/bdx2lzr6l8jpoofqr6rlZT2k
R3VNa+r5iw0B/otn/2AEAN6alZpQt6RInenY6LXQlfwCKREWAbD41o3VgfWZVn3P
VNrAjpDO
=8aHT
-----END PGP SIGNATURE-----
Merge tag 'pull-ide-2026-08-26' of https://gitlab.com/dlunev/qemu into staging
IDE patches
- fix the logical CHS translation a guest selects with INITIALIZE
DEVICE PARAMETERS: reject a translation the device may not accept
instead of dying on a division by zero, report the default
translation in IDENTIFY DEVICE words 1, 3 and 6 and the one in
effect in words 54 to 58, keep those words in sync when the
translation changes, migrate both the translation and the SET
FEATURES 0xCC revert flag, and return the power-on defaults on a
hardware reset rather than on every reset
- harden the IDE and AHCI state a guest or an incoming migration
stream can reach: reject an out-of-range PIO transfer window on
load, refuse a PIO transfer with no command header, clear cur_cmd
when the command list is unmapped, treat a failed PRDT walk as a
transfer failure, reject a command header with an invalid FIS
length, and drain the ports on teardown so that a request cannot
outlive an unplug
- report ATAPI UDMA5 with a matching standard and cable
- extend the IDE/AHCI qtest coverage for all of the above
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Stefan Hajnoczi <stefanha@redhat.com>
CC: John Snow <jsnow@redhat.com>
CC: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQJDBAABCgAtFiEEC66qh9MCCtwRUOUfXgdxtstmbKsFAmqOyM4PHGRlbkBvcGVu
# dnoub3JnAAoJEF4HcbbLZmyrGSUP+wR5KLZXUCKwEXDM95UnUiDFQQUNO0Ko7XGv
# v8hHnTWRb3pvkIh/lJ9ECWPw0NPRKjugkSm9IGDUCndgw6+AbPOTP+tfJXFNK965
# NFisLDoJCcPrrFNCL+T6EQyPBI2GG1vl9t4bg75GeT55WTUiK4Cv0710COZMV3kc
# RlN3LzxCKLqc1wSGcqOLyObKTw97vL5pmB/xcOn/ciN1vOm4d5jgzvs1NqFcO1CF
# btlqGisG9aRlqecKRgKGeLCGXtUoYq0MBuddsMeDSLD/H4FeZ1W0qYb/e2Zv97Bn
# pdAyKb7Fs6OXV77qSUU5N1tSzALG+mn92BegHoyvuK/YRc8eDdwsiB8+OE7XHRbZ
# Atewt2CVfej+lyZH5LHe72esWrNqpcHSwvTpvP26oxJq3qwUXynKh8VqUnnIwEIa
# i1Y7ATnIGXNd1+w68Gk0TDu2zByUPVi4dw91hQR80YY2L9ZWwN5N2u3WCo81ZpAs
# 8hFk44vCAtGtfRZdLPbIboMfVLExRiBIwfNxJNy7btYQLWkvI05s8K5OmyBXeCwh
# rtMQi9745BGcMVCtTIAiUjO/EHEkGtFaAs3JUdN/bdx2lzr6l8jpoofqr6rlZT2k
# R3VNa+r5iw0B/otn/2AEAN6alZpQt6RInenY6LXQlfwCKREWAbD41o3VgfWZVn3P
# VNrAjpDO
# =8aHT
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 26 Aug 2026 04:06:54 AM PDT
# gpg: using RSA key 0BAEAA87D3020ADC1150E51F5E0771B6CB666CAB
# gpg: issuer "den@openvz.org"
# gpg: Good signature from "Denis V. Lunev <den@openvz.org>" [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: 0BAE AA87 D302 0ADC 1150 E51F 5E07 71B6 CB66 6CAB
* tag 'pull-ide-2026-08-26' of https://gitlab.com/dlunev/qemu: (28 commits)
tests/qtest/ide-test: cover the UDMA5 identify words
hw/ide: report ATAPI UDMA5 with a matching standard and cable
tests/qtest/ahci: regression test for a request outliving an unplug
hw/ide/ahci: drain the ports on teardown
hw/ide/ahci: reject a command header with an invalid FIS length
hw/ide/ahci: treat a failed PRDT walk as a PIO transfer failure
tests/qtest/ahci: regression test for a PIO write vs. engine stop
hw/ide/ahci: clear cur_cmd when the command list is unmapped
hw/ide/ahci: refuse a PIO transfer with no command header
tests/qtest/ide-test: cover the migrated PIO transfer window
hw/ide: reject an out-of-range PIO transfer window on load
hw/ide: drop a redundant interrupt from INITIALIZE DEVICE PARAMETERS
tests/qtest/ide-test: cover the CHS translation across resets
hw/ide: revert the CHS translation on a hardware reset
tests/qtest/ide-test: cover the IDENTIFY DEVICE geometry words
tests/qtest/ide-test: cover a rejected CHS translation in the stream
tests/qtest/ide-test: cover the CHS translation across migration
hw/ide: migrate the power-on defaults revert flag
hw/ide: migrate the logical CHS translation
hw/ide: restore the power-on device state before loading
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
/ide/identify/udma and /ide/identify/udma_atapi check that a device
advertising UDMA mode 5 claims a standard that defines it and reports the
hardware reset result, on the disk and on the CD-ROM. The ATAPI case also
checks that the words obsolete in IDENTIFY PACKET DEVICE data stay
clear, and that the reset result reports a passed diagnostic, which
only the packet path does so far.
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
IDENTIFY PACKET DEVICE claims UDMA mode 5 in word 88 while word 80
reports support only up to ATA/ATAPI-4. UDMA5 first appears in
ATA/ATAPI-6; ATA/ATAPI-5 stops at mode 4. Bits 3:1 of word 80 are
obsolete in IDENTIFY PACKET DEVICE data as well, so the old 001eh
claimed three standards that mean nothing for a packet device. Report
0070h, ATA/ATAPI-4 through ATA/ATAPI-6.
Word 93 was left unset, so nothing reported the 80-conductor cable that
UDMA5 needs. Fill it in, but only for a parallel attachment: ACS-3
7.13.6.41 gives word 93 of IDENTIFY PACKET DEVICE data the meaning of
word 93 of IDENTIFY DEVICE data, where "For SATA devices, word 93 shall
be set to the value 0000h". A cleared ncq_queues is how both identify
paths already tell a parallel attachment from an AHCI one.
The device 0 reset result is 0fh rather than the 01h ide_identify()
reports: bit 3 says diagnostics passed, which they did, and bits 2:1
say the device number came from some other method, the only one of the
four encodings that is not a jumper, CSEL or reserved.
Raising word 80 has a second effect. Linux decides a device is SATA in
ata_id_is_sata(), which wants word 93 clear and word 80 at ATA/ATAPI-5
or later. An AHCI CD-ROM satisfied neither condition before and was
taken for a parallel device; now it satisfies both.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4038
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Add /ahci/io/{ncq,dma,pio}/unplug: arm a read against a null-co backend
whose latency keeps it in flight, then eject the controller through the
ACPI ejection register. Each of the three reaches the freed AHCIDevice
array by a different route, so covering one command class would leave
the other two untested.
That register is what a guest writes to finish a PCI unplug, and unlike
the pciehp attention button it reaches ahci_uninit() with no secondary
bus reset, so nothing cancels the request on the way. It also dictates
the machine: q35 has no ACPI hotplug on pcie.0, so the eject has no
effect there.
The latency is what holds the request; a blkdebug breakpoint cannot
stand in for it, because cancelling a suspended request waits for it and
the unplug would never return.
Unfixed, all three fail reliably under AddressSanitizer. On a plain build
the use-after-free only faults when the freed page has been returned, so
expect the odd pass there.
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
ahci_uninit() frees s->dev without touching the requests still in flight.
The only blk_aio_cancel() for them lives in ahci_reset_port(), which the
unplug path does not run, and the ide-hd child's own drain is deferred
through call_rcu so it happens after the free. A guest that powers the
root port slot off through SLTCTL, or writes the ACPI ejection register,
while a read is outstanding therefore leaves the completion to run
against freed memory.
A plain device_del is not affected: the pciehp attention-button flow
resets the secondary bus first, which cancels through the reset path.
Surprise removal is what skips it.
Cancelling the NCQ requests alone is not enough. IDEDMA and IDEBus are
embedded in AHCIDevice, so a plain DMA read reaches the freed array
through dma_blk_cb() and a PIO read through ide_buffered_readv_cb(),
neither of which the NCQ bookkeeping covers. ide_exit() drains nothing
and frees io_buffer, which an outstanding request may still target.
Move the NCQ cancel loop into a helper, run it from ahci_uninit() too,
and drain each port before ide_exit() so no class of request can outlive
the allocation. Delete check_bh there as well; qemu_bh_new_guarded() in
check_cmd() has no counterpart on this path either.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4069
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
AHCI 1.3.1 defines CFL in the command header as the "Length of the
Command FIS", where "A length of '0' or '1' is illegal" and "The
maximum value allowed is 10h, or 16 DW". handle_cmd() never looks at
it, so an all-zero command header is executable: its zero tbl_addr maps
a command table at guest physical address 0, and a guest that has put a
valid Register H2D FIS there gets it run.
That is the reachability a guest gains by pointing PxCLB at an MMIO
region, where the CLB is a zero-filled bounce buffer rather than
anything the guest wrote.
Reject a header whose CFL falls outside the legal range. Nothing else
consults it; the command FIS is always mapped at its full 128 bytes.
The slot is dropped without reporting anything, as the unmappable
command table beside it already is. No PxIS bit describes a malformed
command header: HBFS is for a host bus error, "such as a bad software
pointer", which is why the short mapping below raises it and this does
not.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4043
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
ahci_dma_prepare_buf() returns -1 when it cannot build a scatter-gather
list, the PRDTL of zero case among them. ahci_pio_transfer() tests the
result for truth, so a failure sets has_sglist and the transfer goes
ahead against whatever s->sg holds. AHCI 1.3.1 is explicit about the
zero case: "If this field is '0', then no data transfer shall occur
with the command."
Test for a positive byte count instead. A successful walk that yields
nothing to transfer is already handled by the size check below.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4043
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Add /ahci/io/pio/engine_stop: hold the backend write of a two-sector
PIO write with a blkdebug breakpoint, clear PxCMD.ST so the command
list is unmapped underneath it, then let the write complete. The
second DRQ phase runs from that completion and reaches
ahci_pio_transfer() with no command header.
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
ahci_unmap_clb_address() drops the CLB mapping but leaves cur_cmd
pointing into it. The cancel added by commit d9f78431d8 covers the
buffered reads, and ide_cancel_dma_sync() drains bus->dma->aiocb, but
neither reaches IDEState::pio_aiocb: a PIO write started before the
guest cleared PxCMD.ST completes afterwards and runs its second DRQ
phase against the stale header.
That is harmless while the CLB is direct RAM, because unmapping it
changes nothing. It is a use-after-free once PxCLB points at an MMIO
region, where address_space_map() hands out a bounce buffer that
dma_memory_unmap() then frees.
Clear cur_cmd after the cancel, so nothing reachable from a later
completion still refers to the freed mapping.
Reported-by: Katherine Leaver <katherine.j.leaver@gmail.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3719
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4043
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
ahci_map_clb_address() already clears cur_cmd, so every consumer of it
has to cope with there being no current command. ahci_pio_transfer(),
ahci_commit_buf() and ahci_populate_sglist() all dereference it
unconditionally instead.
Give the three of them a NULL check. Declaring the data transferred
anyway is not enough: ide_transfer_start() goes on to call the end
transfer function, and for a multi-sector write that is
ide_sector_write(), which commits an io_buffer the guest never
refilled. Clearing PxCMD.ST during a WRITE SECTOR(S) of two sectors
therefore writes the first sector's contents over the second, at a
sector the guest chose.
Let pio_transfer report that nothing was transferred and halt there, so
no callback acts on a buffer that was never filled. Only the AHCI HBA
implements the callback, so the signature change is local to it.
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
/ide/migration/pio_state_rejected leaves a drive in DRQ so the source
streams ide_drive/pio_state, rewrites cur_io_buffer_offset to the end of
the io_buffer, and expects the destination to refuse the load.
It asserts the window the source wrote before overwriting it, so a wrong
guess at the stream layout fails the test rather than passing it for the
wrong reason.
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
ide_drive_pio_post_load() validates end_transfer_fn_idx but takes
cur_io_buffer_offset and cur_io_buffer_len straight from the migration
stream, so data_ptr and data_end can be placed anywhere within +-2GB of
the 131076-byte io_buffer allocation. Both fields are signed 32-bit.
The subsection loader consumes every subsection present in the stream
without consulting needed(), so a crafted stream can inject
ide_drive/pio_state for a drive that was never in a DRQ state. Once
data_end is out of bounds, ide_data_writew() only compares the guest's
pointer against that same bogus data_end, and the resumed guest turns a
repeated outw to the data port into a controlled 16-bit heap write.
end_transfer_fn_idx picks the direction, so the read side of the same
code path leaks host heap instead.
Validate the window against io_buffer_total_len and fail the load. The
subtraction form avoids overflowing the addition.
Reported-by: XlabAI Team of Tencent Xuanwu Lab <xlabai@tencent.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4179
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3738
Cc: John Snow <jsnow@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
ide_bus_exec_cmd() raises the interrupt for every command handler that
reports the command complete, which cmd_specify() does, so the request it
raised itself was the first of two. The one from ide_bus_exec_cmd() is the
one that belongs there, being raised after BSY is cleared and after
ide_cmd_done() has let the bus master post its own completion.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
A translation the guest selected has to survive a software reset and not a
hardware one, and the two arrive at the same ide_reset(), so a fix for
either direction can break the other. Select a translation, put the drive
through a software reset and then through a machine reset, and name the
sector each translation picks along the way.
The marker read says which translation the device is addressing the disk
with, while IDENTIFY DEVICE words 55 and 56 say which one it reports. The
machine reset leaves the PCI command register cleared, so the device has
to be enabled again before the ports answer.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
A power on or hardware reset returns the device parameters to their
power-on defaults (ATA-5 9.1). A software reset keeps them unless the
guest asked with SET FEATURES 0xCC for the next reset to revert (ATA-5 9.2
and 8.16.6). ide_reset() applied the second rule to every reset, so a
translation a guest selected outlived the reset of the machine it selected
it on, and the guest that came up next addressed the disk through a
geometry it never asked for.
Neither ide_reset() nor, for AHCI, ide_bus_reset() could tell the two
apart: a guest clearing SRST in the second host to device FIS of the
software reset protocol lands in the same ahci_reset_port() as a COMRESET
or a reset of the host adapter. Pass the kind down from the callers, which
do know.
ide_drive_pre_load() stays necessary: it restores the same fields, but a
vmstate cannot depend on its device having been reset first.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Fixes: 176e4961bb ("hw/ide/core.c: Implement ATA INITIALIZE_DEVICE_PARAMETERS command")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
INITIALIZE DEVICE PARAMETERS has to leave the geometry the drive came with
in words 3 and 6 and describe the translation it selected in words 54 to
58, and the data is cached, so which of the two a guest is told depends on
when it first asked. Cover both orders, as each alone leaves half of it
untested: one test has the data built while the default is in effect and
then replaces the translation, which the cached copy has to follow, the
other replaces it before the first IDENTIFY DEVICE, where the words
describing the default have to keep doing so.
Factor the reading of the data out of test_specify_zero_sectors() for the
three of them to share.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
ide_drive_post_load() refuses a logical CHS translation that no command
could have selected, as the fields are a divisor in ide_set_sector() and a
factor in ide_get_sector(). Nothing exercised that, a fixed QEMU having no
way to produce such a stream.
Migrate a guest that selected a translation to a file, replace the number
of sectors per logical track in the subsection with a zero, and let a
destination read the result back. The load has to fail rather than take
the value, so the destination is asked not to exit on a failed incoming
migration and its migration status is what the test looks at.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Both defects here are silent: the guest addresses the disk in the
translation it selected while the device translates with another, so reads
and writes land on a sector nobody asked for. Put a marker in each of the
two candidate sectors and name the one the translation picked. CHS 0/1/1
is LBA 32 under 8 heads and 32 sectors per track and LBA 63 under the
16/63 the test drive is configured with; both markers are written by LBA,
which no translation can influence.
A translation the guest selected has to survive migration, and one it
selected after a snapshot was taken must not outlive loading that snapshot
back. The second needs a qcow2 image, so it is skipped without qemu-img.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
SET FEATURES 0xCC asks for the next reset to revert to the power-on
defaults, and 0x66 cancels that; ide_reset() restores the default CHS
translation only when the flag is set. It was in no VMStateDescription, so
it always arrived cleared.
That was invisible while the destination had the default translation
anyway. Now that the translation is migrated, the flag decides how long it
stays in effect: without it, a reset after the migration reverts the
geometry on the source and keeps it on the destination.
Send it only alongside a translation the guest replaced. On the default
geometry it reverts to what is already in effect, so such a guest need not
lose its migration to an older QEMU over a subsection that changes
nothing.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Fixes: 176e4961bb ("hw/ide/core.c: Implement ATA INITIALIZE_DEVICE_PARAMETERS command")
Signed-off-by: Denis V. Lunev <den@openvz.org>
INITIALIZE DEVICE PARAMETERS lets a guest replace the logical CHS
translation used to turn the CHS registers into an LBA, but s->heads and
s->sectors were in no VMStateDescription. The destination rebuilt them
from the drive configuration, so a guest that had selected one of its own
kept addressing the disk in it while the device translated with the
default, landing on sectors nobody asked for.
Add a subsection for it, sent only when the guest replaced the default, so
that migration to an older QEMU keeps working for every other guest.
s->cylinders is left out, as no command changes it.
Validate what is loaded in the existing post_load: ide_get_sector()
multiplies by these fields and ide_set_sector() divides by them.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Fixes: 176e4961bb ("hw/ide/core.c: Implement ATA INITIALIZE_DEVICE_PARAMETERS command")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Loading a snapshot reuses the IDEState of the machine it is loaded into:
load_snapshot() resets the machine and then feeds the stream into the
existing devices. The reset does not help, as ide_reset() restores the
logical CHS translation only when the guest asked for power-on defaults to
be reverted with SET FEATURES 0xCC.
A guest that replaced the translation with INITIALIZE DEVICE PARAMETERS
therefore keeps it across the load of a snapshot taken before it did,
while the restored guest expects the geometry of that moment. Every CHS
access then lands on a sector other than the one asked for, with no error
reported. s->reset_reverts survives a load the same way.
Add a pre_load restoring the defaults, which
docs/devel/migration/main.rst recommends for state a stream need not
carry, and which the following subsections rely on. The
RESET_TYPE_SNAPSHOT_LOAD marking that reset would be another way to
recognise the case, but no IDE controller can see it while they all use
device_class_set_legacy_reset().
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Fixes: 176e4961bb ("hw/ide/core.c: Implement ATA INITIALIZE_DEVICE_PARAMETERS command")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Bit 0 of IDENTIFY DEVICE word 53 says that words 54 to 58 describe the CHS
translation in effect, and ATA-5 8.16.8 has INITIALIZE DEVICE PARAMETERS
set words 55 and 56 to the heads and sectors per track it was given. The
data is built once and then cached, so those words kept describing
whatever was in effect when a guest first asked for IDENTIFY DEVICE: the
device reported one geometry while addressing the medium with another, and
nothing reported an error. The revert SET FEATURES 0xCC asks for on the
next reset left the same disagreement.
Do not drop the cached data on a change, as parts of it are guest state
rather than a description of the drive: SET FEATURES records the write
cache setting in word 85, which ide_drive_post_load() reads back after
migration. Refresh the affected words in place instead, the way
ide_identify_size() does for the capacity words.
An ATAPI device has no translation but does take SET FEATURES 0xCC, so
leave its IDENTIFY PACKET DEVICE data alone, where those words differ.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Fixes: 176e4961bb ("hw/ide/core.c: Implement ATA INITIALIZE_DEVICE_PARAMETERS command")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Words 54 to 58 of IDENTIFY DEVICE describe the CHS translation in effect
and the capacity it addresses. Both ide_identify() and
ide_cfata_identify() fill them the same way while building their cached
data.
Move them into ide_identify_chs(), so that the next change can refresh
them in place once the translation changes, the way ide_identify_size()
does for the capacity words.
No functional change.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Words 4, 5 and 20 have carried an "XXX: retired, remove ?" since the
device was written, and word 21 is labelled a cache size when it is a
buffer size. ATA-4 8.12.13 retired words 4 and 5, 8.12.17 retired words
20 and 21, and ATA-5 keeps all four that way.
Retired is not a reason to drop them. ATA-5 3.2.3.6 says a retired word
that is still used shall have "the meaning or functionality as described
in previous standards", and that is what these carry: ATA-1 9.9.3, 9.9.4
and 9.9.7 define the unformatted bytes per track and per sector and the
buffer type, and the ATA-1 IDENTIFY table gives word 21 as the buffer
size in 512 byte increments. Software old enough to read them gets what
it expects, so answer the question rather than leave it open.
Word 22 is obsolete rather than retired (ATA-4 8.12.18) and already
carries its ATA-1 9.9.8 name, so leave it alone.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
IDENTIFY DEVICE words 1, 3 and 6 describe the default CHS translation,
and ATA-5 8.16.8 requires INITIALIZE DEVICE PARAMETERS to leave them
alone; the translation in effect is described by words 54 to 56 instead.
Words 3 and 6 were filled from s->heads and s->sectors, which the command
replaces, so a guest that selected a translation of its own was told that
its choice was what the drive came with, and could no longer find out the
default. Word 1 is already right, as no command changes s->cylinders.
Report s->drive_heads and s->drive_sectors, which ide_init_drive() keeps
for exactly this, along with the retired word 4 derived from them. The
CompactFlash data labels those words as the default geometry too, and
INITIALIZE DEVICE PARAMETERS is accepted for CFA drives, so fix both.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Cc: qemu-stable@nongnu.org
Fixes: 176e4961bb ("hw/ide/core.c: Implement ATA INITIALIZE_DEVICE_PARAMETERS command")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The sector count register of a legacy port is eight bits wide, so
ide-test can only reach the lower end of the range the command has to
refuse. A register FIS carries a 16 bit count, which leaves AHCI as the
only way to ask for a translation of 256 sectors per logical track or
more.
Ask for 0, 256 and 65535 sectors and expect each to be aborted, then ask
for 32 and expect it to be accepted, so that the check cannot pass by
refusing everything.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
A command that transfers no data can still take an argument in the count
register of the register FIS, and a test may well expect such a command
to be aborted. AHCICommand is private to the library, so add two
setters: ahci_command_set_count() writes the count of a non-data
command, and ahci_command_expect_error() records the error register bits
the command is expected to complete with, which is what
ahci_atapi_test_ready() does inline for a sense key today.
INITIALIZE DEVICE PARAMETERS is the first user of both, so describe it
in the command properties table as well.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Ask for zero sectors per logical track via INITIALIZE DEVICE PARAMETERS
and check that the command is aborted, that IDENTIFY DEVICE still reports
the translation that was in effect before, and that a CHS read then
completes normally rather than killing QEMU with SIGFPE.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
ide_set_sector() divides by (s->heads * s->sectors) when the drive is
addressed in CHS mode. Both come from the guest via INITIALIZE DEVICE
PARAMETERS, and cmd_specify() stored them without any check, so a guest
asking for zero sectors per logical track killed QEMU with SIGFPE on the
completion of the first CHS read or write. s->heads is safe, as the
command passes a heads-1 value.
The count has an upper bound as well. The legacy sector count register is
eight bits wide, but handle_cmd() takes the count from a 16 bit field of
the register FIS, so an AHCI guest can ask for up to 65535 sectors per
track, and the CHS branch of ide_get_sector() then overflows the int it
multiplies cylinder, heads and sectors in.
ATA-5 6.2 numbers CHS sectors from one and ATA-2 D.2.8 limits IDENTIFY
DEVICE word 56 to 1 through 255, so neither end is a translation a device
may accept. ATA-5 8.16.6 requires an unsupported one to be reported as an
aborted command: do that, leave the translation in effect alone, and
refuse the value rather than checking it at every use.
Cc: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Cc: qemu-stable@nongnu.org
Fixes: 176e4961bb ("hw/ide/core.c: Implement ATA INITIALIZE_DEVICE_PARAMETERS command")
Reported-by: Zheyu Ma <zheyuma97@gmail.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2399
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The keyboard path has answered unknown commands with KBD_REPLY_RESEND
since commit 06b3611fc2 ("ps2: reject unknown commands, instead of
blindly accepting them"), but never said why. Give it the comment the
mouse path just gained, so the reasoning is written down in both
places.
Suggested-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Christian Quante <christian@quante.one>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260825075127.34876-3-christian@quante.one>
ps2_write_mouse() ends its command switch with a bare "default: break;",
so an unknown command draws no reply at all. A real PS/2 device answers
every byte it is given -- ACK (0xFA) when it understood one, resend
(0xFE) when it did not -- and a guest that gets nothing back is left
waiting out its reply timeout. The keyboard path in the same file has
answered unknown commands with KBD_REPLY_RESEND since commit
06b3611fc2 ("ps2: reject unknown commands, instead of blindly
accepting them").
Two guests were measured on this.
OS/2 probes the mouse with the vendor command 0xBB, which QEMU does not
implement, and then polls the status port until its own timeout runs
out. On a Warp 3 guest that wait costs about 25 ms of every boot under
TCG, and 2.1 s under KVM, where each of those polls leaves the guest.
With this patch the wait ends on the first read: the guest takes the
same error path an unexpected reply would, and does not retry.
Linux runs into two of them while probing the mouse: the ALPS probe
sends 0xEC (reset wrap mode), which ps2_write_mouse() only answers
while the mouse is in wrap mode, and the TrackPoint probe sends 0xE1.
Each costs libps2 a 200 ms reply timeout. Timing the psmouse detection
from a mark written to /dev/kmsg to the kernel's "input:" line, three
boots each of a 6.18.35 kernel under TCG: 426.7/428.8/441.6 ms without
this patch, 21.4/21.6/21.2 ms with it. The mouse is detected
identically either way; only the error the probe ends in changes, from
-EIO (nothing came back at all) to -EPROTO (libps2 gives up after its
second attempt).
The specification's second stage -- 0xFC (Error) when the byte after a
rejected one is invalid as well -- is deliberately left out. It would
need state that has to survive migration, no guest is known to test for
it, and the keyboard path does without it as well.
Cc: qemu-stable@nongnu.org
Signed-off-by: Christian Quante <christian@quante.one>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260825075127.34876-2-christian@quante.one>
virtio_gpu_find_check_resource() checks if the resource has backing
storage if require_backing is true, but the condition conflates backing
storage attachment with host representation; it checks
!res->iov || (!res->image && !res->blob), but !res->iov is sufficient.
Furthermore, its callers passing true as require_backing have different
requirements:
- virtio_gpu_transfer_to_host_2d() requires a non-blob with
backing storage.
- virtio_gpu_set_scanout() requires a non-blob but does not require
backing storage.
- virtio_gpu_set_scanout_blob() requires a blob with backing storage.
- virtio_gpu_resource_detach_backing() accepts any resource.
Remove the require_backing parameter and open-code checks appropriate
for each function instead.
Fixes: 25c001a403 ("virtio-gpu: Add virtio_gpu_find_check_resource")
Fixes: e0933d91b1 ("virtio-gpu: Add virtio_gpu_resource_create_blob")
Fixes: 32db3c63ae ("virtio-gpu: Add virtio_gpu_set_scanout_blob")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260825-dmabuf-v2-5-b3d64d3b9a0e@rsg.ci.i.u-tokyo.ac.jp>
Reject a blob that lacks the backing storage for
VIRTIO_GPU_CMD_UPDATE_CURSOR.
Fixes: bdd53f7392 ("virtio-gpu: Update cursor data using blob")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260825-dmabuf-v2-4-b3d64d3b9a0e@rsg.ci.i.u-tokyo.ac.jp>
Propagate udmabuf errors so that the requested operation will be
canceled instead of producing an incomplete result and the user can
notice the failure.
Fixes: e0933d91b1 ("virtio-gpu: Add virtio_gpu_resource_create_blob")
Fixes: f66767f75c ("virtio-gpu: add virtio-gpu/blob vmstate subsection")
Fixes: 4ae1c5c7d6 ("hw/display/virtio-gpu: Initialize blob mapping for ATTACH_BACKING")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260825-dmabuf-v2-3-b3d64d3b9a0e@rsg.ci.i.u-tokyo.ac.jp>
The virtio specification allows creating a blob without backing storage
attached. However, virtio-gpu attempts to create an empty udmabuf for
such a blob. The ioctl fails with EINVAL and emits a spurious warning.
Avoid the invalid ioctl.
Fixes: e0933d91b1 ("virtio-gpu: Add virtio_gpu_resource_create_blob")
Fixes: f66767f75c ("virtio-gpu: add virtio-gpu/blob vmstate subsection")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260825-dmabuf-v2-1-b3d64d3b9a0e@rsg.ci.i.u-tokyo.ac.jp>
vga_draw_text() decides whether the console surface needs a resize from
its geometry cache, but none of the cache terms observe the graphics
renderer having replaced the console surface in between:
- last_width/last_height are shared with vga_draw_graphic(), which
stores them in pixels while the text path stores characters;
- last_depth stays 0 for legacy (non-VBE) graphics modes, because
vga_get_bpp() only reports a depth when VBE is enabled, so the
"s->last_depth" term that normally forces a resize after a graphics
frame does not fire.
So a graphics frame that shrinks the console surface (e.g. 80x25
pixels) followed by a text frame with matching character geometry
(80x25 chars) skips the resize, and the glyph loop then paints
width*cw x height*cheight pixels into the smaller surface, out of
bounds, with guest-controlled (DAC palette) values, on every display
refresh.
Separate the geometry cache per renderer: text paths (vga_draw_text,
vga_update_text, and the text handling in vga_invalidate_display /
vga_common_reset) now only manipulate last_text_{width,height}, in
characters; last_{width,height} become graphics-only, in pixels.
Additionally, make the text path compare the pixel size it is about
to paint against the console surface's actual dimensions. The
surface check is the load-bearing term: caches in either unit cannot
see the other renderer swapping the surface, the surface can.
Fixes: CVE-2026-77913
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4215
Cc: qemu-stable@nongnu.org
Signed-off-by: Warisjeet Singh (sin99xx) <sinxx198@gmail.com>
Message-ID: <vga-v3-20260824.sinxx198@gmail.com>
Commit 5c102ac9 ("chardev: Consolidate yank registration") has moved
yank registration in the tcp_chr_connect_client_async() path to after
the connection is successful. If qio_channel_socket_connect_sync()
fails early, there will be no yank registered to be unregistered in
the error path, leading to assert.
Remove the now-extraneous unregister.
Cc: qemu-stable@nongnu.org
Fixes: 5c102ac9 ("chardev: Consolidate yank registration")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3528
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260603141137.1108963-1-farosas@suse.de>
Add generated-members=cv2.* to pylintrc so pylint skips member
checking on the cv2 C extension module, whose members are not
visible to static analysis.
Silence:
2026-08-15 10:42:08,710 - INFO: qemu-test.test_pylint Checking files in /home/elmarco/src/qemu.qom-qapi/tests/functional/arm with pylint
2026-08-15 10:42:10,941 - ERROR: qemu-test.test_pylint "/home/elmarco/src/qemu.qom-qapi/tests/functional/arm/test_integratorcp.py:83: E1101: Module 'cv2' has no 'imread' member (no-member)"
Note: I also tried with extension-pkg-allow-list, but that didn't work
for some reason.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260815072421.4117291-1-marcandre.lureau@redhat.com>
EGLDisplay is already a pointer type (void *), so declaring
qemu_egl_display as EGLDisplay * makes it void **, which
doesn't match any of its usages.
Fixes: 7ced9e9f6d ("ui: add egl-helpers")
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260820131933.2729240-1-marcandre.lureau@redhat.com>
ASAN detected some memory leaks when terminating. Release thread-bound
EGL state first, destroy the context and terminate the display while the
GBM device is still alive, then destroy GBM and close the render-node
fd.
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Fixes: a3cf9b55bb ("ui/egl: implement display and EGL cleanup")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260820132014.2729748-1-marcandre.lureau@redhat.com>
Add several RCU and thread-pool unit tests to the slow_tests dict,
and tag all slow tests (both qtest and unit) with a 'slow' suite so
they can be excluded or selected via meson test --suite/--no-suite.
Acked-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260512065633.3542562-1-marcandre.lureau@redhat.com>
sha.h has been deprecated. It seems we can rely on sha1.h/sha2.h
since we depend on >= 3.7.3.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4184
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Use g_try_malloc/g_try_new0 for guest-controlled allocation, so failure
returns an error to the guest rather than crashing the host (glib
behaviour).
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3898
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260805130141.211398-1-marcandre.lureau@redhat.com>
The existing validation in qxl_create_guest_primary() checks that
abs(stride) * height fits in vgamem_size and that stride is 4-byte
aligned, but never checks that abs(stride) is large enough to hold one
row of pixels for the declared width and format.
A malicious guest can create a primary surface with a stride much
smaller than width * bytes_per_pixel (e.g. stride=4 for a 64-wide 32bpp
surface). The spice server rejects this via red_validate_surface(), but
the return is void and QEMU unconditionally proceeds to set up the local
rendering state. On the next display refresh, VNC or SDL reads width *
bytes_pp per scanline from a region backed by only stride bytes per
row, causing a host-side out-of-bounds read.
Add three checks in qxl_create_guest_primary() before creating the
surface:
- reject unknown surface formats
- reject zero width or height
- reject surfaces where abs(stride) < width * bytes_per_pixel
Also fix three related issues in qxl-render.c:
- qxl_blit() used abs_stride to advance the dst pointer into the
DisplaySurface, but when stride is negative the DisplaySurface is a
packed buffer whose stride may be smaller. Use surface_stride()
instead.
- qxl_render_update_area_unlocked() uses guest_head0_width (set via
QXL_IO_MONITORS_CONFIG_ASYNC) without validating it against
abs_stride, bypassing the new validation. Clamp the effective width
to abs_stride / bytes_pp to prevent out-of-bounds access while
tolerating the normal transient where the monitor config arrives
before the primary surface is resized to match.
- Similarly, guest_head0_height bypasses qxl_create_guest_primary()
validation. Without clamping, abs_stride * height can overrun
vgamem_size, and the product can also overflow 32 bits (e.g.
abs_stride=16 MiB, height=256 wraps to zero), defeating the
qxl_phys2virt() bounds check. Clamp height to
vgamem_size / abs_stride to prevent both.
While touch it, fix some endianness issues.
Fixes: CVE-2026-16271
Fixes: a19cbfb346 ("spice: add qxl device")
Fixes: 979f7ef896 ("qxl: use guest_monitor_config for local renderer.")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3637
Reported-by: huntr bubble
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260806094028.640676-1-marcandre.lureau@redhat.com>
The MachineState fdt field is allocated by various machine types via
create_device_tree(), load_device_tree(), or similar, but was never
freed in machine_finalize(). Add the missing g_free() call.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260709111249.1107640-1-marcandre.lureau@redhat.com>
The commit 8041d17308 accidentally removed the vmlaunchupdate.c
trace events.
Fixes: 8041d17308 ("tests/qtest: add test for K230 gsdma")
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260825074114.853069-1-marcandre.lureau@redhat.com>
- Separate the UFS controller core from the PCI frontend
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUBfYMVl8eKPZB+73EuIgTA5dtgIFAmqL1G8ACgkQEuIgTA5d
tgIWthAAvynqQHh4tnILvApKh/E5ePRV/J9KtTYCJIIU1M1V/Xgr8s8R0UwfxzPM
dl0mibLBozZuyo5tQGLXtEjXCNUEuKFO3YW+UrNk+iIrNjKBiiqHTrh48g2J9wwd
OeZawTg2EEIde395pBsidCyKp8M7DGOies/MuI3m2yRifyR7dlq1zUsR4JUUDiXu
+8LvBng8yZHxPK3j3vxT+3VsxcK3qUord0u3kvFK+m+010l3B2WerxG/ZR110LG7
mL/0fijD3P25lU0x9fryA6BYIE4LppOdJwZJi5rLl6CXiEKcqRlLEBAfUQAh04a5
AtfXV5Q7iXjJSC9cZB+NXP6qn+yP6Dq6ioHtlAA4koF08DGzd+xMBsCI4k7Bib28
r1e4tjIcBa8Xn7e/Lwj1/Co2dmM6DlaRsbi4n0oPp3yp+aavIfaLeIfjPwlRVqLF
mB/I9rR1d09VVlmNBI40cnVdQzWgNU/wcot+hwZ3gyBx7ow4mOG4XmrEKHj8JaTH
iAEXZq5LEBbP5T6f+1iPqsB16NkdTc4Sl45SG+rDnOiQz4x6B76PmUU/SyDRFmzy
RVAKPdPp/xigg1clVEoDxZxVueioX5kpxHxAlmwoFjse5CBZmkLlhRtv4o1R72UP
MGKbVw8i0tW00bHNjW4IBWy8i5jlIE2gu84AnyZTsqp33Srg+Po=
=7KSJ
-----END PGP SIGNATURE-----
Merge tag 'pull-ufs-20260824' of https://gitlab.com/jeuk20.kim/qemu into staging
ufs queue
- Separate the UFS controller core from the PCI frontend
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEUBfYMVl8eKPZB+73EuIgTA5dtgIFAmqL1G8ACgkQEuIgTA5d
# tgIWthAAvynqQHh4tnILvApKh/E5ePRV/J9KtTYCJIIU1M1V/Xgr8s8R0UwfxzPM
# dl0mibLBozZuyo5tQGLXtEjXCNUEuKFO3YW+UrNk+iIrNjKBiiqHTrh48g2J9wwd
# OeZawTg2EEIde395pBsidCyKp8M7DGOies/MuI3m2yRifyR7dlq1zUsR4JUUDiXu
# +8LvBng8yZHxPK3j3vxT+3VsxcK3qUord0u3kvFK+m+010l3B2WerxG/ZR110LG7
# mL/0fijD3P25lU0x9fryA6BYIE4LppOdJwZJi5rLl6CXiEKcqRlLEBAfUQAh04a5
# AtfXV5Q7iXjJSC9cZB+NXP6qn+yP6Dq6ioHtlAA4koF08DGzd+xMBsCI4k7Bib28
# r1e4tjIcBa8Xn7e/Lwj1/Co2dmM6DlaRsbi4n0oPp3yp+aavIfaLeIfjPwlRVqLF
# mB/I9rR1d09VVlmNBI40cnVdQzWgNU/wcot+hwZ3gyBx7ow4mOG4XmrEKHj8JaTH
# iAEXZq5LEBbP5T6f+1iPqsB16NkdTc4Sl45SG+rDnOiQz4x6B76PmUU/SyDRFmzy
# RVAKPdPp/xigg1clVEoDxZxVueioX5kpxHxAlmwoFjse5CBZmkLlhRtv4o1R72UP
# MGKbVw8i0tW00bHNjW4IBWy8i5jlIE2gu84AnyZTsqp33Srg+Po=
# =7KSJ
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 23 Aug 2026 10:19:43 PM PDT
# gpg: using RSA key 5017D831597C78A3D907EEF712E2204C0E5DB602
# gpg: Good signature from "Jeuk Kim <jeuk20.kim@samsung.com>" [unknown]
# gpg: aka "Jeuk Kim <jeuk20.kim@gmail.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: 5017 D831 597C 78A3 D907 EEF7 12E2 204C 0E5D B602
* tag 'pull-ufs-20260824' of https://gitlab.com/jeuk20.kim/qemu:
hw/ufs: Add a generic SysBus frontend
hw/ufs: Separate the controller core from the PCI frontend
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* Fix IMSIC CSR write and add tests
* Parametrise debug trigger number
* Add 'svbare' satp-mode
* Fix RINTC PLIC context ID for KVM
* Avoid abort when reading vtype before env->xl is set
* Skip reset for KVM irqchip
* Skip FP/Vector sync on KVM_PUT_RUNTIME_STATE
* More FDT cleanups (PLIC)
* Make FCTL.BE in IOMMU read only 0
* Check DC.TC reserved bits in IOMMU
* Apply UXL WARL handling to vsstatus
* Set cmd_ill IOFENCE.C if rsvp bits are set in IOMMU
* Set RISCV_IOMMU_FQ_HDR_PV appropriately
* Report QEMU CPU archid as 42
* Check PMP before updating PTE
* Add the Tenstorrent Atlantis machine
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmqL2o0ACgkQr3yVEwxT
gBOC9g//Ux5snjOzJmmIgJdOFPcBlt1sRxq23Oc5uKoGp54yuDQFvhfg4t8G6w4L
pgJGdZ6MoA3D+QXsQuXS6WuVDKGuAwTcP4p4rioy+31WjFUL/2bTIOBFGkeER02x
uF2Z9fq8hF6bLjoOgyv2zyIL9hRY6Vh3cBCHaKXoLJdKmAdByhhHOOcvCpAfi17x
FmZ4pBZY7yApHIWNb3jBCR2siz8UZ2j0AvHbT2qMENHZBXW8GBrHDdMMOU5mexoB
nd+sKfiVyYpDJh0N99KzIJaxecK8rF/mt7FMghgKrf9sYMaHwundFl8O44skJ8+b
HDqAn8Cytfk659S1hiUJZF9Slt+zAAx1bKb7WWORP2hdfXkw5C5skyK0EGIEvb1R
9FK+2Y0XI8dCoPXFOKaDOWOmTEW4ihAS1QZ/xZuhqOJK1jjQs7qik+8CNbhNVyqd
GHRZlenlGGtAE1CYELs3kOWVdxPyGQG4VVr9AXk/MmCQqcNtpG7E3gMcrg9a3LVg
vmIpAyc57MzvzEqGENIVoiSQRBtuF2T8EFnaLZv3PhXsHVGM+xz/BRGWTDza4TgC
hXS3xxk+UnSwRgjcx9kcMA+S74EjMML/1NmVHviD9dlC2yBGfYk0e90wDB+fJbn5
XePzJX4moXSaLihTI+srqVmT5uvAoj6fGnmkS1XRwy1JdhWW7Tc=
=9pMS
-----END PGP SIGNATURE-----
Merge tag 'pull-riscv-to-apply-20260824-1' of https://github.com/alistair23/qemu into staging
RISC-V PR for 11.1
* Fix IMSIC CSR write and add tests
* Parametrise debug trigger number
* Add 'svbare' satp-mode
* Fix RINTC PLIC context ID for KVM
* Avoid abort when reading vtype before env->xl is set
* Skip reset for KVM irqchip
* Skip FP/Vector sync on KVM_PUT_RUNTIME_STATE
* More FDT cleanups (PLIC)
* Make FCTL.BE in IOMMU read only 0
* Check DC.TC reserved bits in IOMMU
* Apply UXL WARL handling to vsstatus
* Set cmd_ill IOFENCE.C if rsvp bits are set in IOMMU
* Set RISCV_IOMMU_FQ_HDR_PV appropriately
* Report QEMU CPU archid as 42
* Check PMP before updating PTE
* Add the Tenstorrent Atlantis machine
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmqL2o0ACgkQr3yVEwxT
# gBOC9g//Ux5snjOzJmmIgJdOFPcBlt1sRxq23Oc5uKoGp54yuDQFvhfg4t8G6w4L
# pgJGdZ6MoA3D+QXsQuXS6WuVDKGuAwTcP4p4rioy+31WjFUL/2bTIOBFGkeER02x
# uF2Z9fq8hF6bLjoOgyv2zyIL9hRY6Vh3cBCHaKXoLJdKmAdByhhHOOcvCpAfi17x
# FmZ4pBZY7yApHIWNb3jBCR2siz8UZ2j0AvHbT2qMENHZBXW8GBrHDdMMOU5mexoB
# nd+sKfiVyYpDJh0N99KzIJaxecK8rF/mt7FMghgKrf9sYMaHwundFl8O44skJ8+b
# HDqAn8Cytfk659S1hiUJZF9Slt+zAAx1bKb7WWORP2hdfXkw5C5skyK0EGIEvb1R
# 9FK+2Y0XI8dCoPXFOKaDOWOmTEW4ihAS1QZ/xZuhqOJK1jjQs7qik+8CNbhNVyqd
# GHRZlenlGGtAE1CYELs3kOWVdxPyGQG4VVr9AXk/MmCQqcNtpG7E3gMcrg9a3LVg
# vmIpAyc57MzvzEqGENIVoiSQRBtuF2T8EFnaLZv3PhXsHVGM+xz/BRGWTDza4TgC
# hXS3xxk+UnSwRgjcx9kcMA+S74EjMML/1NmVHviD9dlC2yBGfYk0e90wDB+fJbn5
# XePzJX4moXSaLihTI+srqVmT5uvAoj6fGnmkS1XRwy1JdhWW7Tc=
# =9pMS
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 23 Aug 2026 10:45:49 PM PDT
# gpg: using RSA key 6AE902B6A7CA877D6D659296AF7C95130C538013
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [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: 6AE9 02B6 A7CA 877D 6D65 9296 AF7C 9513 0C53 8013
* tag 'pull-riscv-to-apply-20260824-1' of https://github.com/alistair23/qemu: (96 commits)
target/riscv/tcg: sret in virtual user mode raises virtual instruction exception
target/riscv: Make Zcmt JVT loads endian-aware
tests/tcg/riscv64: add misa write test
riscv: csr: do not drop C bit on misa write
target/riscv: Allow UXL to be 3 in mstatus on rv128
target/riscv: Fix sstatus update in rv128
target/riscv: Restore register dump zero padding
tests/qtest: remove trace output from k230 watchdog test
target/riscv: enforce even register constraints for Zdinx fcvt pairs
target/riscv: reject FMV.X.W/FMV.W.X under Zfinx
target/riscv: honor zicbo* envcfg gating in linux-user mode
disas/riscv: Sort riscv-op.c.inc
disas/riscv: Split rvi_opcode_data
disas/riscv: Tidy decode of mop.r.n and mop.rr.n
disas/riscv: Tidy decode of c.mop.n
disas/riscv: Merge all c.mop.n to one pattern
disas/riscv: Merge all mop.rr.n to one pattern
disas/riscv: Merge all mop.r.n to one pattern
disas/riscv: Split out riscv-op.c.inc
disas/riscv: Move rv_op_illegal to riscv.c
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Add TYPE_SYSBUS_UFS as a reusable frontend for the
transport-independent UFS controller core.
Use the system memory address space for DMA, expose the controller MMIO
region and IRQ through SysBus, and provide the same properties and
migration policy as the PCI frontend. Platform-specific controllers can
derive from this type and keep only their hardware-specific behavior.
Signed-off-by: Jeuk Kim <jeuk20.kim@samsung.com>
UfsHc is currently also the PCI device instance, tying common code to
PCI-specific DMA and IRQ interfaces and preventing reuse by non-PCI
frontends.
Make UfsHc transport-independent and embed it in UfsPciState. Move the
PCI-specific handling to ufs-pci.c, pass the owning DeviceState and DMA
AddressSpace to the core, and record the core explicitly in UfsBus.
Split the common implementation into CONFIG_UFS, selected by
CONFIG_UFS_PCI. The user-visible "ufs" device and its properties remain
unchanged. No functional change is intended.
Signed-off-by: Jeuk Kim <jeuk20.kim@samsung.com>
Currently, when a `sret` is executed in virtual user mode, qemu
raise an `illegal instruction exception`, but in this case the correct
behavior is to raise a `virtual instruction exception` and the code
already contains a check to it, but it's not enough to catch. This
patch is useful to improve the correctness of the virtualization of
the risc v architecture.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3622
Signed-off-by: Christian S. Lima <christianslima@proton.me>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260808031849.59726-1-christianslima@proton.me>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The Zcmt specification says JVT table entries follow the current data
endianness. Support that behavior as described by the specification so
big-endian guests can use JVT tables stored in big-endian form.
Signed-off-by: Xu Liu <liuxu@nucleisys.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <02050B1BBB8815BE+20260817083005.2392-1-liuxu@nucleisys.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
According to spec:
> Writing misa may increase IALIGN, e.g., by disabling the "C" extension.
> If an instruction that would write misa increases IALIGN, and the
> subsequent instruction’s address is not IALIGN-bit aligned, the
> write to misa is suppressed, leaving misa unchanged.
So attempt to disable C extension if next instruction is not aligned should not
change the misa.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Vladimir Isaev <vvisaev@gmail.com>
Reviewed-by: Chao Liu <chao.liu@processmission.com>
Message-ID: <20260817150653.40357-2-vvisaev@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Valid UXL field values for mstatus were restricted to fix a
reported issue, but this inadvertently broke the experimental
rv128 support where a value of 3 validly represents 128-bit
execution.
Update the mstatus write logic to permit UXL=3 when running on
an rv128 CPU.
Fixes: dcd0285177 ("target/riscv: Apply UXL WARL handling to vsstatus")
Signed-off-by: Frédéric Pétrot <frederic.petrot@univ-grenoble-alpes.fr>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Reviewed-by: Chao Liu <chao.liu@processmission.com>
Message-ID: <20260819105655.33391-3-frederic.petrot@univ-grenoble-alpes.fr>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The sstatus register assignment was performed before the write
mask was fully constructed, leading to an incomplete update of
sstatus fields on the experimental rv128 target.
Move the sstatus write after the mask completion so the full
write mask is applied correctly.
Signed-off-by: Frédéric Pétrot <frederic.petrot@univ-grenoble-alpes.fr>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Chao Liu <chao.liu@processmission.com>
Message-ID: <20260819105655.33391-2-frederic.petrot@univ-grenoble-alpes.fr>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The register values lost their leading zeroes when the underlying type
was changed, resulting in mismatched padding and harder to read output.
Print with a runtime field width based on MXL, so values are 16 hex
digits on rv64 and 8 on rv32, matching the csr and fp dump. This avoids
adding target_ulong back into the dump.
Fixes: c4e6bc6385 ("target/riscv: Fix size of gpr and gprh")
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Reviewed-by: Max Chou <max.chou@sifive.com>
Message-ID: <20260813032421.54438-1-joel@jms.id.au>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The interrupt mode test does not depend on trace output, but passes a
trace file to QEMU. This makes startup fail when QEMU is built without
the log or simple trace backend, so qtest cannot connect.
Drop the unnecessary trace option.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4126
Signed-off-by: Chao Liu <chao.liu@processmission.com>
Reviewed-by: Bin Meng <bin.meng@processmission.com>
Message-ID: <20260813054329.35425-1-chao.liu@processmission.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
fcvt.d.h and fcvt.h.d access a 64-bit double held in a register
pair, so under Zdinx/Zhinxmin the odd-rd (fcvt.d.h) and odd-rs1
(fcvt.h.d) encodings are reserved. Add the missing REQUIRE_EVEN
checks so those encodings raise an illegal-instruction exception
instead of retiring.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4109
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: wangyang <wangyang25@otcaix.iscas.ac.cn>
Message-ID: <ea287909fd6043e0bbcdbfdcb0cc8063@wangyang25.otcaix.iscas.ac.cn>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Zfinx explicitly excludes the FMV transfer instructions, but
trans_fmv_x_w/trans_fmv_w_x used REQUIRE_ZFINX_OR_F so a Zfinx-only
CPU accepted them. Require RVF instead so the transfers trap with
an illegal instruction when only Zfinx is present.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4108
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: wangyang <wangyang25@otcaix.iscas.ac.cn>
Message-ID: <36c7cfebd27b4b6e8bcdd00e09e9dda0@wangyang25.otcaix.iscas.ac.cn>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
In user-only builds check_zicbo_envcfg() skipped the envcfg check
entirely (#if !defined(CONFIG_USER_ONLY)), so cbo.inval/cbo.flush/
cbo.zero retired unconditionally in linux-user even though the
machine-level envcfg fields are never initialized. Give the
user-mode build a senvcfg-based gate, and initialize SENVCFG_CBZE at
reset when ext_zicboz is enabled so cbo.zero stays usable while
cbo.inval/cbo.flush remain illegal, matching the user-mode view of a
typical firmware/kernel setup.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4107
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: wangyang <wangyang25@otcaix.iscas.ac.cn>
Message-ID: <9b2f22fc402b48b8ba81f72be8ed04bc@wangyang25.otcaix.iscas.ac.cn>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
To date, opcodes had to be added to the end of the list,
resulting in quite the disorder. Sort via 'LANG=C sort'.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-53-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Generate separate objects for OP() instead of collecting in a table.
Return pointers to objects directly.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-52-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Avoid performing arithmetic on rv_op_c_mop_1.
Treat the 'n' as an immediate.
Create a codec and format to match.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-49-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Avoid performing arithmetic on rv_op_mop_rr_0.
Treat the 'n' as an immediate.
Create a codec and format to match.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-48-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Avoid performing arithmetic on rv_op_mop_r_0.
Treat the 'n' as an immediate.
Create a codec and format to match.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-47-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Move rvi_opcode_data to riscv-op.c.inc and massage the lines into
OP() form. Unlike other files, keep the enumeration and the table
intact for now, but build them both from the same source.
Adjust the names of rv_*mop to include _op_ to match the general pattern.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-46-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
illegal is no longer used in other files.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-45-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Move the table to riscv-xthead-op.c.inc and massage
the lines into OP() form. Drop th.illegal as unused.
Return pointers to objects directly.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-44-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Move the table to riscv-xlrbr-op.c.inc and massage
the lines into OP() form. Drop illegal as unused.
Return pointers to objects directly.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-43-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Move the table to riscv-xventana-op.c.inc and massage
the lines into OP() form. Drop vt.illegal as unused.
Return pointers to objects directly.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-42-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
th.lbib should format the same as th.lbia, and the other
increment insns, with the address register in parenthesis.
Cc: qemu-stable@nongnu.org
Fixes: 318df7238b ("disas/riscv: Add support for XThead* instructions")
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-41-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The encoding of rev8 is different for rv32 and rv64.
Cc: qemu-stable@nongnu.org
Fixes: 02c1b569a1 ("disas/riscv: Add Zb[abcs] instructions")
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-40-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
For rv64, pack with rs2 = 0 does not encode zext.h.
Cc: qemu-stable@nongnu.org
Fixes: 02c1b569a1 ("disas/riscv: Add Zb[abcs] instructions")
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-39-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
These entire base opcodes are RV64. Reject them all at once
rather than one at a time.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-38-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260812223142.349142-37-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Rather than putting array + index into rv_decode,
return the pointer to the object directly.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-36-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Store a pointer instead of an array index.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-35-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Route "c.j" to "j" instead of "jal", etc.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-34-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The codec is never used, since we arrive into pseudos
from a decoding of another opcode.
Assert that rv_codec_illegal is never decoded.
Use rv_codec_none for rv_op_illegal.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-33-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
"mv" has already checked a condition that applies to "nop".
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-32-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
"jr" has already checked two conditions that apply to "ret".
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-31-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Use { } instead of two zeros.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-30-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The format for these will never be used -- we will use
the format from the decompressed insn.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-29-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Introduce a DECOMP macro that expands an rv_comp_data
that always succeeds.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-28-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Allow pseudo expansion to proceed in multiple steps.
Assert that we don't have simple loops.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-27-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
These were clearly intending to simplify
jal ra, foo
to
jal foo
and similarly for jalr, but the pseudo expansion looped
back to the original jal/jalr with the full format.
Add new opcode expansions dropping the implied ra.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-26-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-25-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-24-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-23-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The real insns are blt, bge, bltu, bgeu. Do not include
pseudos that unconditionally swap operands. That's fine
for an assembler but not a disassembler.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-22-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
We now distinguish compressed opcodes by isa during decode.
Therefore we don't need 3 copies of decomp_*.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-21-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Remove rvcd_imm_nz and rv_opcode_data.decomp_data as unused.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-20-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
These code points are reserved with RV32.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-19-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-18-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Zero shift immediate to c.srli and c.srai are not illegal,
but are reserved as HINTs. Go ahead and disassemble as
shifts rather than falling back to invalid.
On the other hand, shift immediate >= 32 with RV32 is
reserved for custom extensions, and we need to reject those
early so that the extension disassemblers get a look in.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-17-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-16-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
While c.addi with imm == 0 and rd == 0 is c.nop,
other c.addi with imm == 0 and rd != 0 are not illegal,
but are reserved as HINTs. Go ahead and disassemble as
c.addi rather than falling back to invalid.
Further, there's no reason to differentiate c.nop, since we have
c.addi -> addi -> nop
vs
c.nop -> addi -> nop
via decompress and pseudo translation steps.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-15-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-14-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This is mostly write-only, only used in one place;
other updates are ignored.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-13-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Individual fields should not be const, only full structures.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-12-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This allows each opcode table to be private to the decode file.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-10-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Unroll first iteration, so that always_true_p is not used,
Drop some local variables and use 'decoders' directly.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-9-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-8-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-7-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-5-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-4-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Since 758dce9c98, the only possible values for
instruction length are 2 and 4.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-3-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260812223142.349142-2-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The Zicfilp landing-pad enable (LPE, bit 2) and Zicfiss shadow-stack
enable (SSE, bit 3) controls live in the low 32 bits of menvcfg and
henvcfg, and the CFI specification defines them for both RV32 and RV64.
QEMU only adds MENVCFG_LPE/MENVCFG_SSE (and the henvcfg equivalents) to
the writable mask inside the "riscv_cpu_mxl(env) == MXL_RV64" block, so
on RV32 these bits are silently dropped and the features cannot be
enabled. This is inconsistent with write_senvcfg(), which already
handles SENVCFG_LPE/SENVCFG_SSE regardless of MXLEN.
Hoist the LPE/SSE mask handling out of the RV64-only block in
write_menvcfg() and write_henvcfg() so the bits become writable on RV32
as well. The upper-half writers (write_menvcfgh/write_henvcfgh) are
unaffected because these bits reside in the low 32 bits.
Reproducible on qemu-system-riscv32 -cpu rv32,zicfilp=true,zicfiss=true:
an M-mode write of menvcfg.{LPE,SSE} reads back as zero, while the same
program on rv64 keeps the bits set.
Fixes: 4923f672e3 ("target/riscv: Introduce elp state and enabling controls for zicfilp")
Fixes: 8205bc127a ("target/riscv: introduce ssp and enabling controls for zicfiss")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4045
Signed-off-by: A-Shehab <ahshehab24@gmail.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260726080537.13913-1-ahshehab24@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
b18e3f0e2d fixed spa_fetch() faults whose TTYP used the leaf PTE
permission instead of the original request permission. However, it kept
that request-narrowed value in iotlb->perm after a successful walk, and
riscv_iommu_translate() caches iotlb->perm for later accesses to the same
IOVA.
That means a write to an RW mapping can cache the entry as write-only.
A later read then hits the cache and faults even though the mapping allows
it, which showed up in NVMe testing as bogus completions and controller
timeouts.
Keep the requested permission in a separate req_perm and use it for all
permission checks and fault-type decisions. Accumulate the leaf
permissions separately and copy them to iotlb->perm only after the full
walk succeeds, so cached entries describe the mapping rather than the
current request. Since faults leave iotlb->perm as the original request,
the S-stage and G-stage TTYP fixes remain intact.
Fixes: b18e3f0e2d ("hw/riscv/riscv-iommu.c: fix fault type for spa_fetch() faults")
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260717144525.1154204-1-andrew.jones@oss.qualcomm.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Commit b795ea0ba4 ("hw/riscv/riscv-iommu.c: fault when !PTE_U and
no priv access") placed its check ahead of the leaf-vs-non-leaf
branch in riscv_iommu_spa_fetch(), so it fires on every PTE walked,
including non-leaf/table entries. Per the RISC-V privileged spec's
address translation algorithm (Sv39/Sv48/etc., the "leaf PTE has
been reached" step, followed separately by the U-bit permission
check), the U bit is only defined and checked for the leaf PTE
reached at the end of the walk -- non-leaf PTEs don't carry a
meaningful U bit at all.
Move the check after the leaf/non-leaf branch, alongside the other
leaf-only checks, mirroring how the G_STAGE U-bit check (added in
9158c900ab) is already correctly placed.
Fixes: b795ea0ba4 ("hw/riscv/riscv-iommu.c: fault when !PTE_U and no priv access")
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Message-ID: <20260717112340.1071148-1-andrew.jones@oss.qualcomm.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Replace shift-based operand extraction with extract32() and sextract32().
For signed immediates, use sextract32() on the field that carries the sign
bit and combine it with the remaining extract32() fields.
The RISC-V disassembler currently follows target/riscv/internals.h:
insn_len() and decodes only 16-bit or 32-bit instruction lengths, so the
converted fields are all in the low 32 bits of rv_inst.
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: TANG Tiancheng <lyndra@linux.alibaba.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260703-b4-disas-xthead-fix-riscv-next-v4-5-84c566330bc7@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
rv_codec_v_i decodes all .vi operands with operand_vimm(), which
sign-extends bits 19:15. That matches spec operands named imm, but not the
.vi forms whose operand is uimm; uimm=31 is decoded as -1 and printed by
the shared 6-bit 'u' formatter as 63.
Add rv_codec_v_i_u/operand_vuimm() for the 5-bit uimm forms: vsll.vi,
vsrl.vi, vsra.vi, vnsrl.wi, vnsra.wi, vssrl.vi, vssra.vi, vnclipu.wi,
vnclip.wi, vslideup.vi, vslidedown.vi, vrgather.vi, vaeskf1.vi,
vaeskf2.vi, vsm3c.vi, vsm4k.vi and vwsll.vi. The remaining rv_codec_v_i
entries are the signed imm forms.
Fixes: 07f4964d17 ("disas/riscv.c: rvv: Add disas support for vector instructions")
Fixes: 9d92f56d4a ("disas/riscv: Add support for vector crypto extensions")
Signed-off-by: TANG Tiancheng <lyndra@linux.alibaba.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260703-b4-disas-xthead-fix-riscv-next-v4-4-84c566330bc7@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
operand_vimm() sign-extends the 5-bit vector immediate field in bits
19:15, but returns uint32_t. This sends negative immediates through an
unsigned type before they are assigned to rv_decode.imm.
Return int32_t to match the signed value extracted by the helper.
Signed-off-by: TANG Tiancheng <lyndra@linux.alibaba.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260703-b4-disas-xthead-fix-riscv-next-v4-3-84c566330bc7@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
rv_codec_r2_imm6 is used for XThead instructions whose 6-bit
immediate field is encoded in bits 25:20. The old expression
left-shifted by 38 and then right-shifted by 60, so it kept only
bits 25:22.
Use extract32() to decode bits 25:20 directly. This fixes the
immediate printed for th.srri and th.tst.
Fixes: 318df7238b ("disas/riscv: Add support for XThead* instructions")
Suggested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: TANG Tiancheng <lyndra@linux.alibaba.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260703-b4-disas-xthead-fix-riscv-next-v4-2-84c566330bc7@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv/xthead.decode defines th.srri as funct6=000100 in
bits 31:26, with the 6-bit immediate in bits 25:20.
decode_xtheadbb() switches on bits 31:25, i.e. funct6 plus imm[5].
Therefore valid th.srri encodings are 0001000 and 0001001. The
current 0000100 and 0000101 cases use the wrong funct6 value and
decode valid th.srri instructions as illegal.
Fix the cases to match funct6=000100 with both imm[5] values.
Fixes: 318df7238b ("disas/riscv: Add support for XThead* instructions")
Signed-off-by: TANG Tiancheng <lyndra@linux.alibaba.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260703-b4-disas-xthead-fix-riscv-next-v4-1-84c566330bc7@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Add a qtest that reads the seed CSR on RV64 machine with Zkr support
and verifies that the upper 32 bits are clear.
Signed-off-by: Ivan Efremov <nendensu@ispras.ru>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260802113130.7818-3-nendensu@ispras.ru>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The SEED_OPST_* macros expanded to int expressions. When
bit 31 was present, converting a CSR seed value to target_ulong
on RV64 sign extended the value and incorrectly set the upper 32 bits.
Make the SEED_OPST_* constants unsigned so that CSR values are
zero extended on RV64.
Fixes: 77442380ec ("target/riscv: rvk: add CSR support for Zkr")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4121
Signed-off-by: Ivan Efremov <nendensu@ispras.ru>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260802113130.7818-2-nendensu@ispras.ru>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
With icount enabled, helper_raise_exception() leaves ECALL in
icount_get_raw() because it exits without restoring the current TB
state. This makes minstret count an instruction that does not retire.
Adjust only the fixed minstret baseline so that mcycle accounting
remains unchanged.
Add an RV64 softmmu regression test for the issue.
Fixes: 4fe8ae0906 ("target/riscv: Combine mhpmcounter and mhpmcounterh")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4087
Signed-off-by: Zephyr Li <fritchleybohrer@gmail.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260730032122.2564190-1-fritchleybohrer@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Cover scalar, floating-point, vector, and segmented misaligned accesses
with Zicclsm enabled and disabled. Clean up both generated test
binaries.
To build and run the tests:
make -C build/tests/tcg/riscv64-softmmu \
CC=riscv64-unknown-elf-gcc LD=riscv64-unknown-elf-ld \
test-zicclsm test-zicclsm-off
make -C build/tests/tcg/riscv64-softmmu \
run-test-zicclsm run-test-zicclsm-off
To clean the generated binaries and objects:
make -C build/tests/tcg/riscv64-softmmu clean
Signed-off-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260810055618.1175500-8-frank.chang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Update Zicclsm ISA string and expose it as a CPU property to allow user
to turn on/off Zicclsm extension.
In addition, Zicclsm extension is mandatory for the RVA22U64 profile.
Previously, Zicclsm was enabled automatically when has_priv_1_11 was true.
Now that Zicclsm has been converted to an explicit CPU option, it must be
explicitly added to the RVA22U64 profile's extension list to ensure the
profile remains compliant with the specification.
Signed-off-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260810055618.1175500-7-frank.chang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
When the Zicclsm extension is not enabled, raise misaligned load/store
exceptions for misaligned accesses from vector load/store instructions.
We will skip the host fast-path and fall back to the slow TLB-path to
raise misaligned load/store exceptions for the misaligned accesses when
Zicclsm extension is disabled.
Signed-off-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Max Chou <max.chou@sifive.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260810055618.1175500-6-frank.chang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
When the Zicclsm extension is not enabled, raise misaligned load/store
exceptions for misaligned accesses from floating-point load/store
instructions (RVF, RVD, Zfh).
Signed-off-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260810055618.1175500-5-frank.chang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
When the Zicclsm extension is not enabled, raise misaligned load/store
exceptions for misaligned accesses from scalar load/store instructions.
Signed-off-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Max Chou <max.chou@sifive.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260810055618.1175500-4-frank.chang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The SiFive U ROM reset vector data needs proper 8-byte alignment for
RV64 ld instructions. The misaligned load will cause exception when
Zicclsm is supported as SiFive U CPU doesn't support hardware misaligned
loads and stores.
Add padding to ensure start_addr and fdt_load_addr are placed at 8-byte
aligned offsets and adjust the load instruction offsets to match the new
data layout.
Signed-off-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260810055618.1175500-3-frank.chang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Add Zicclsm CPU option and enable it for the following eligible CPUs:
- Base 32 CPU (to be backward compatible)
- Base 64 CPU (to be backward compatible)
- XuanTie (T-Head) C908
- Tenstorrent Ascalon
- Ventana Veyron V1
- XiangShan Kunminghu
- MIPS P8700 (ISA doesn't include Zicclsm, but their datasheet claims that
it has unaligned load/store support in hardware)
Signed-off-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Max Chou <max.chou@sifive.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260810055618.1175500-2-frank.chang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
In riscv_trigger_unrealize(), the per-trigger QEMUTimer objects are
created in riscv_trigger_realize() using timer_new_ns(). However,
unrealize only calls timer_del() to cancel them, but never frees the
timer objects themselves. This results in a memory leak every time a
CPU instance is unrealized (e.g., during hot-unplug or machine teardown).
Fix it by replacing timer_del() with timer_free(), which internally
cancels the timer and frees its memory. The separate timer_del() call
is no longer needed.
Fixes: 820552a92e ("target/riscv: dynamic alloc of debug trigger arrays")
Signed-off-by: Zeng Chi <zengchi@kylinos.cn>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260724063927.3360599-1-zeng_chi911@163.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
According to the RISC-V spec, a 64-bit system can have M-mode in 64-bit
with S-mode being 32-bit (SXL bits or mstatus[35:34] being 1). In this
case, read_sstatus should use SXL.
QEMU doesn't allow changing the SXL bits in mstatus in M-mode. This was
because of the missing MSTATUS64_SXL mask in write_mstatus. Now, both
the SXL field in mstatus can be safely modified in M-mode and
read_sstatus correctly uses SXL not MXL.
Fixes: b550f89457 ("target/riscv: Compute mstatus.sd on demand")
Signed-off-by: Abhigyan Kumar <314abh@gmail.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260723142254.1683113-1-314abh@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Move gen_update_pc call before conditional logic to ensure consistent
PC state regardless of execution path.
Previously, the host instructions generated to update the cpu_pc were
only executed in the failure path when shadow stack validation failed.
This created inconsistent PC synchronization.
This inconsistency caused issues in CF_PCREL mode where subsequent
instructions calculated wrong relative offsets from stale pc_save
values, and could lead to incorrect exception return addresses.
This fix ensures PC is always synchronized before any helper that
might raise an exception, maintaining consistent translator state
across all execution paths.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4118
Signed-off-by: Max Chou <max.chou@sifive.com>
[ahshehab: rebased on current master; file moved to
target/riscv/tcg/insn_trans/ and the ssp load is now 64-bit wide]
Tested-by: A-Shehab <ahshehab24@gmail.com>
Signed-off-by: A-Shehab <ahshehab24@gmail.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260730181852.1622-1-ahshehab24@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
RISC-V KVM initializes secondary vCPUs in KVM_MP_STATE_STOPPED, but QEMU
does not save their runtime MP state. A destination therefore retains reset
MP state after migration and cannot reliably resume all vCPUs.
Save KVM_GET_MP_STATE in a capability-gated KVM VMState subsection and
restore it on KVM_PUT_FULL_STATE. Keep the existing reset initialization
path unchanged. Track whether the subsection was loaded so streams where
the subsection is absent retain the destination reset behavior.
Bump the RISC-V CPU VMState version and minimum version to 12 for the new
pre_load hook and KVM MP-state subsection. Keep the subsection out of KVM
migration streams when the host does not support the MP-state capability.
Signed-off-by: Xie Bo <xb@ultrarisc.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260808125157.1220511-3-xb@ultrarisc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The KVM core register synchronization currently omits the vCPU privilege
mode. As a result, env.priv can be stale when the migration stream is saved
and the destination can restore the vCPU in the wrong mode.
Read and write the KVM core mode register together with the other core
registers. The generic RISC-V CPU VMState already carries env.priv, so no
migration format change is required.
Signed-off-by: Xie Bo <xb@ultrarisc.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260808125157.1220511-2-xb@ultrarisc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The NOC address was accessed in the k230_unzip driver, but it is currently not in k230.
This commit uses create_unimplemented_device to preset the region.
Signed-off-by: Tao Ding <dingtao0430@163.com>
Reviewed-by: Junze Cao <caojunze424@gmail.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260808062227.66961-8-dingtao0430@163.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This commit adds test cases for Decomp_gzip.
A compressed data segment has been pre-set, configure GSDMA and decomp_gzip.
Compare the decompressed data with the original data
Update MAINTAINERS for this test.
Run this qtest:
$ mkdir build && cd build && ../configure --target-list="riscv64-softmmu"
$ QTEST_QEMU_BINARY=./qemu-system-riscv64 tests/qtest/k230-decomp-gzip-test
Signed-off-by: Tao Ding <dingtao0430@163.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Reviewed-by: Junze Cao <caojunze424@gmail.com>
Message-ID: <20260808062227.66961-7-dingtao0430@163.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This commit replaces the unimplemented part of Decomp_gzip in K230.
Connect to the handshake interface of GSDMA.
Signed-off-by: Tao Ding <dingtao0430@163.com>
Reviewed-by: Junze Cao <caojunze424@gmail.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260808062227.66961-6-dingtao0430@163.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This commit adds test cases for GSDMA.
Imitate the behavior of the driver, set LLT and sdma registers.
After the data transmission is completed, check the destination address data.
Update MAINTAINERS for this test.
Run this qtest:
$ mkdir build && cd build && ../configure --target-list="riscv64-softmmu"
$ QTEST_QEMU_BINARY=./qemu-system-riscv64 tests/qtest/k230-gsdma-test
Signed-off-by: Tao Ding <dingtao0430@163.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Reviewed-by: Junze Cao <caojunze424@gmail.com>
Message-ID: <20260808062227.66961-4-dingtao0430@163.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This commit replaces the unimplemented part of GSDMA in K230. And connect the interrupt to plic.
Update K230.rst.
Signed-off-by: Tao Ding <dingtao0430@163.com>
Reviewed-by: Junze Cao <caojunze424@gmail.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260808062227.66961-3-dingtao0430@163.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
K230 GSDMA includes SDMA (System Direct Memory Access) and GDMA (Graphic Direct Memory Access).
In this patch, add SDMA for k230 board. The following features have not been implemented:
1. axi protocol related
2. channel arbitration
3. lower power mode
SDMA supports transfer data between memory, in which case SDMA is the controller.
It also supports transfer data to decomp_gzip and caching it through SRAM.
In this case, decomp_gzip is the controller, which controls SDMA through handshake signals.
According to "K230 Technical Reference Manual v0.3.1" section 2.5.2.
https://download.kendryte.com/developer/k230/HDK/K230%E7%A1%AC%E4%BB%B6%E6%96%87%E6%A1%A3/K230_Technical_Reference_Manual_V0.3.1_20241118.pdf
This commit includes:
- K230 SDMA (System Direct Memory Access) model (k230_gsdma.c, k230_gsdma.h)
- GSDMA trace log (trace-events)
- Kconfig and meson.build
- update MAINTAINERS
Signed-off-by: Tao Ding <dingtao0430@163.com>
Reviewed-by: Chao Liu <chao.liu@processmission.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Reviewed-by: Junze Cao <caojunze424@gmail.com>
Message-ID: <20260808062227.66961-2-dingtao0430@163.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This adds optional UART1 to RiscV virt board if required at
runtime to simplify multicore development.
Note that UART0 remains default serial_hd(0) and it is:
- the lowest address UART
- first serial in DTB
- behind /aliases/serial0 in DTB
- the /chosen/stdout-path in DTB
Note that UART1 is placed at different page from UART0 to
support page level isolation.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <tencent_4EEBFC805F3E59863BEDC38094EF5A109206@qq.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Add qtests for DDRC and PHY reset values, register access policy, the
software-update handshake, and PHY register ownership.
Exercise PHY training and mailbox acknowledgement through the DFI
initialization sequence. Include negative coverage to ensure DFI cannot
complete before PHY training or enter Normal mode before completion is
enabled.
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Suggested-by: Chao Liu <chao.liu@processmission.com>
Signed-off-by: Junze Cao <caojunze424@gmail.com>
Message-ID: <20260807-k230-ddr-v2-v2-3-c531308ae819@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Replace the unimplemented K230 DDR configuration region with the DDRC
model and map the PHY model at 0x9a000000.
Connect the controller to the PHY so DFI status reflects PHY training and
initialization state.
Suggested-by: Chao Liu <chao.liu@processmission.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Signed-off-by: Junze Cao <caojunze424@gmail.com>
Message-ID: <20260807-k230-ddr-v2-v2-2-c531308ae819@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The K230 SDK U-Boot SPL programs K230 DDRC CFG and K230 DDR PHY
registers before DRAM can be used.
Add separate SysBus devices for both register ranges. Model controller
reset values, DFI and software-update handshakes. For the PHY, model
register ownership, the training mailbox, and DFI completion.
Include migration state for both devices.
Signed-off-by: Junze Cao <caojunze424@gmail.com>
Suggested-by: Chao Liu <chao.liu@processmission.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260807-k230-ddr-v2-v2-1-c531308ae819@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
I have been contributing to Fadump, MPIPL as well as PowerNV for quite
some time, and my daily work responsibilities includes taking care of
PowerPC RAS features. I, therefore would like to step up as a reviewer
to get notified of incoming changes in this area and help reviewing
them.
Acked-by: Aditya Gupta <adityag@linux.ibm.com>
Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260819193757.1072909-3-shivangu@linux.ibm.com
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Introduce a new "PowerPC RAS (Reliability, Availability and
Serviceability)" entry in the PowerPC Machines block, replacing the
existing Fadump/MPIPL sections. Retaining the maintainer and
reviewer entries from Fadump/MPIPL sections for this broader umbrella.
Currently most of RAS related code sits in spapr_rtas.c, So Adding
it to PowerPC RAS section. Additionally adding spapr_events.c, as it
implements RTAS error logging infrastructure and spapr_pci_vfio.c, since
its all EEH related code.
Acked-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Aditya Gupta <adityag@linux.ibm.com>
Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260819193757.1072909-2-shivangu@linux.ibm.com
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
The POWER9 Processor User's Manual, section 4.9.4, specifies that POWER9
ignores PTCR[PATS] and only supports a 64 KiB partition table. Use an
effective PATS value of 4 on POWER9; other processors keep the existing
ISA v3.0 interpretation.
The PSI model now exposes POWER9 IRQ level and pending status registers,
and keeps both updated while delivering through the existing XIVE LSI
source. This lets guests that select the POWER9 PSI LSI IRQ method
continue to receive LPC interrupts.
The blast radius is probably minimal: the PTCR change is limited to
POWER9, while the PSI change only touches POWER9 PSI state and reuses
the existing delivery path.
Acked-by: Chinmay Rath <rathc@linux.ibm.com>
Signed-off-by: Kirill A. Korinsky <kirill@korins.ky>
Reviewed-by: Aditya Gupta <adityag@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260719145559.94342-1-kirill@korins.ky
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
I have been contributing to PPC KVM and sPAPR (pseries) for some time now and
would like to get notified of incoming changes to help with code reviews.
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Acked-by: Gautam Menghani <gautam@linux.ibm.com>
Acked-by: Chinmay Rath <rathc@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Link: https://lore.kernel.org/qemu-devel/20260819050545.21232-1-amachhiw@linux.ibm.com
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
ppc_store_sdr1() had validation for 64-bit SDR1 values but lacked
corresponding checks for the 32-bit case. According to the Power ISA,
in 32-bit mode SDR1 bits 16-22 are reserved (must be zero) and
HTABMASK (bits 23-31) must consist of a consecutive string of
1-bits starting from the LSB, i.e., be of the form 2^n-1.
Add checks to reject invalid HTABMASK values and log a guest error
for non-zero reserved bits, following the same pattern used by the
existing 64-bit validation.
Reviewed-by: Chinmay Rath <rathc@linux.ibm.com>
Signed-off-by: Minhang Zhang <zhangminhang@kylinos.cn>
Link: https://lore.kernel.org/qemu-devel/tencent_8388D4B38DC5172F5EEE70436D3AD6D02006@qq.com
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
The existing compare function only make sure that we list cpus with PVR
order. However, we never compare cpu names.
As a result, while cpus are grouped per PVR, the order within a group is
non deterministic. Depending on QOM type initialization order, we get
different results for -cpu help.
For instance, previous output could be:
Available CPUs:
755_v1.0 PVR 00083100
745_v1.0 PVR 00083100
755_v1.1 PVR 00083101
745_v1.1 PVR 00083101
While a sorted output should be:
Available CPUs:
745_v1.0 PVR 00083100
755_v1.0 PVR 00083100
745_v1.1 PVR 00083101
755_v1.1 PVR 00083101
Fix it by comparing cpu names to have a stable result.
This allows us to record and compare various command line results across
versions to make sure we didn't break anything while working on
single-binary.
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260720192403.66694-1-pierrick.bouvier@oss.qualcomm.com
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEoDKM/7k6F6eZAf59TLbY7tPocTgFAmqIeGcACgkQTLbY7tPo
cTi6eA/+LTgcwLrRIRlZBJ1ExwYBAVeeI2AwfoVvL7LrNrVTeW5O3HBkkd5iW3u1
O5GGabV/8dQsrt3cTbQ6Tj1FuTaAFluNgykok4uCb9kavji/WQofkBgoek6PmDBi
4CPwseO12eh9i/OV1yyCRdKqBuUjwnk1LbJIaBRDhz+AOhvTrPZYtxZMC1XZUY/4
QPTHzo4lDyRphdq/puXe+Z4WPRMpt0tEUzSq1ev57W2Pwu3Rrf6BNM5X+uH8vTXQ
3OwzmpNDsJusMKpo0/+gc1pGuLrNSSVWfbrEzsKot6jUg3hfkqmonTEFT+ArZNSn
cqBCulWVlopJttRcnbUUSdjTaoBHIfS2yX2w10K2eVX7s2DbXy49GERhlfC23BHi
zMrBQ0JGU4njdZXobFnR8HtCqwAlaTgFHiTHIjk4+IZHRPHUCAOVAIb0rkCeFSX3
qgE1vHJhEBHLIsCv5F6Kb3aUbTiqWSzfFR67FRZctTzJp0nvJ06EiTlKURDk9CyG
krInt79qeTHgNu8zNTDwoy8WbHlbDepv0aL/S+liHcE8Drvr5X0pWA0vMWE6mgvj
Ibd8BEpw6VbLrGe/cz0eLRdu2/6tIDEKYmlAReuRX9ifP3kT41fT9aF/h9BOuJae
zKWRSDgNfPB6MNf2r/6jvOHNCVaaG69jd0HJH/9cbzxHqinMe54=
=9hRx
-----END PGP SIGNATURE-----
Merge tag 'igvm-20260821-pull-request' of https://gitlab.com/kraxel/qemu into staging
igvm + vmlaunchupdate: allow guests supply their own igvm firmware images.
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEoDKM/7k6F6eZAf59TLbY7tPocTgFAmqIeGcACgkQTLbY7tPo
# cTi6eA/+LTgcwLrRIRlZBJ1ExwYBAVeeI2AwfoVvL7LrNrVTeW5O3HBkkd5iW3u1
# O5GGabV/8dQsrt3cTbQ6Tj1FuTaAFluNgykok4uCb9kavji/WQofkBgoek6PmDBi
# 4CPwseO12eh9i/OV1yyCRdKqBuUjwnk1LbJIaBRDhz+AOhvTrPZYtxZMC1XZUY/4
# QPTHzo4lDyRphdq/puXe+Z4WPRMpt0tEUzSq1ev57W2Pwu3Rrf6BNM5X+uH8vTXQ
# 3OwzmpNDsJusMKpo0/+gc1pGuLrNSSVWfbrEzsKot6jUg3hfkqmonTEFT+ArZNSn
# cqBCulWVlopJttRcnbUUSdjTaoBHIfS2yX2w10K2eVX7s2DbXy49GERhlfC23BHi
# zMrBQ0JGU4njdZXobFnR8HtCqwAlaTgFHiTHIjk4+IZHRPHUCAOVAIb0rkCeFSX3
# qgE1vHJhEBHLIsCv5F6Kb3aUbTiqWSzfFR67FRZctTzJp0nvJ06EiTlKURDk9CyG
# krInt79qeTHgNu8zNTDwoy8WbHlbDepv0aL/S+liHcE8Drvr5X0pWA0vMWE6mgvj
# Ibd8BEpw6VbLrGe/cz0eLRdu2/6tIDEKYmlAReuRX9ifP3kT41fT9aF/h9BOuJae
# zKWRSDgNfPB6MNf2r/6jvOHNCVaaG69jd0HJH/9cbzxHqinMe54=
# =9hRx
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 21 Aug 2026 09:10:15 AM PDT
# gpg: using RSA key A0328CFFB93A17A79901FE7D4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [unknown]
# gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [unknown]
# gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.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: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138
* tag 'igvm-20260821-pull-request' of https://gitlab.com/kraxel/qemu:
Update MAINTAINERS
Add functional and unit tests for the vm-launch-update device
tests/qtest: Add small igvm files for testing purpose
docs/spec: Add a specification document for vm-launch-update device
hw/misc/vmlaunchupdate: Introduce hypervisor fw-cfg interface support
hw/misc/vmlaunchupdate: add api header
backends/igvm: add a tracepoint for qigvm_cleanup_memory
system/memory: add a tracepoint for memory_region_finalize
igvm: cleanup memory regions
igvm: track memory regions
igvm: store IgvmCfg pointer in QIgvm
MAINTAINERS: elevating myself to be a maintainer for igvm
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* target/arm: Restrict arm_do_plugin_vcpu_discon_cb() to TCG
* hw/intc: Fix kconfig handling for gicv3 when TCG disabled
* target/arm: CPU refactoring to prepare for max-v8 and max-v9
* hw/misc/iotkit-secctl.c: fix AHB secure read
* target/arm: Fix SVE2 WHILEWR/WHILERW zero diff boundary case
* hw/arm/ax3000-soc: fix heap overflow from missing class_size
* target/arm: Implement AArch32 "disable Neon" and "disable
VFP D16-D31 insns" CPACR/HCPTR/NSACR trap bits
* hw/arm: put arm_boot_info structs into machine state struct
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmqIL7YZHHBldGVyLm1h
eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3pyGD/0fIH5Hq23FdWzGBws4cJOr
q175XCXQlaxgMG+OuJBWf5aKwLeqNFmcCspjv7p07Ezjrwixb/Qsbth5WFbZ/zCi
hr8kemvaq9jUzU8GmQsGmv7SgY8yXROaQGLIb8eycOBlG6ih7u3EI5TR37nFcez5
jxg/WkBbCprHG03Bsi7ZCDpglucNHlgxerOl7O1x2O3yfT0HC9hmVsn8N986S+/y
nPmzNg1/xEuGGIgOXVijCr/t/T5PgnwNdkZ5HlnLGkYHBIxq9BlINKlMPu3TK4D2
548ujAJF+ZwNTJh6D84qS0a0Yiq2g+rLvTTZePv/0V7wIy5HOvL9m6zcj+1xAojZ
86UFY33/AaHowWCNAHEtEISFrKRjfwkiAamLPkkG6wae+8RCpA3/5arY2hNNNbfy
N1JEvQMeil/roXfei1QTKP5pCqUhUNfMm4pR8xXPb8Ke6uEKwXjjqAw/Gg6jaccn
ZRCbG/BIs5LlWzUyyYuqsiIzAY9xuuU/UeHj2N+fr+vtqgiltTpgkJ1W2V90WCuu
1NF1eiUKukyVXn9IW3IxAqcXYCHqMY9lt2D0BcijYyjsaFRfQMLYw220/PACcnsl
69tqEV92OdwRXZ8MSBwj4Xv4y1U4me9uL490+1oKgQIm+J5dj653ViEmHJ6Of4wb
fSgKhs91YewlAsZDluKi6w==
=p8ub
-----END PGP SIGNATURE-----
Merge tag 'pull-target-arm-20260821' of https://gitlab.com/pm215/qemu into staging
target-arm queue:
* target/arm: Restrict arm_do_plugin_vcpu_discon_cb() to TCG
* hw/intc: Fix kconfig handling for gicv3 when TCG disabled
* target/arm: CPU refactoring to prepare for max-v8 and max-v9
* hw/misc/iotkit-secctl.c: fix AHB secure read
* target/arm: Fix SVE2 WHILEWR/WHILERW zero diff boundary case
* hw/arm/ax3000-soc: fix heap overflow from missing class_size
* target/arm: Implement AArch32 "disable Neon" and "disable
VFP D16-D31 insns" CPACR/HCPTR/NSACR trap bits
* hw/arm: put arm_boot_info structs into machine state struct
# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmqIL7YZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3pyGD/0fIH5Hq23FdWzGBws4cJOr
# q175XCXQlaxgMG+OuJBWf5aKwLeqNFmcCspjv7p07Ezjrwixb/Qsbth5WFbZ/zCi
# hr8kemvaq9jUzU8GmQsGmv7SgY8yXROaQGLIb8eycOBlG6ih7u3EI5TR37nFcez5
# jxg/WkBbCprHG03Bsi7ZCDpglucNHlgxerOl7O1x2O3yfT0HC9hmVsn8N986S+/y
# nPmzNg1/xEuGGIgOXVijCr/t/T5PgnwNdkZ5HlnLGkYHBIxq9BlINKlMPu3TK4D2
# 548ujAJF+ZwNTJh6D84qS0a0Yiq2g+rLvTTZePv/0V7wIy5HOvL9m6zcj+1xAojZ
# 86UFY33/AaHowWCNAHEtEISFrKRjfwkiAamLPkkG6wae+8RCpA3/5arY2hNNNbfy
# N1JEvQMeil/roXfei1QTKP5pCqUhUNfMm4pR8xXPb8Ke6uEKwXjjqAw/Gg6jaccn
# ZRCbG/BIs5LlWzUyyYuqsiIzAY9xuuU/UeHj2N+fr+vtqgiltTpgkJ1W2V90WCuu
# 1NF1eiUKukyVXn9IW3IxAqcXYCHqMY9lt2D0BcijYyjsaFRfQMLYw220/PACcnsl
# 69tqEV92OdwRXZ8MSBwj4Xv4y1U4me9uL490+1oKgQIm+J5dj653ViEmHJ6Of4wb
# fSgKhs91YewlAsZDluKi6w==
# =p8ub
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 21 Aug 2026 04:00:06 AM PDT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [unknown]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [unknown]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [unknown]
# gpg: aka "Peter Maydell <peter@archaic.org.uk>" [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: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* tag 'pull-target-arm-20260821' of https://gitlab.com/pm215/qemu: (43 commits)
hw/arm: xilinx_zynq: Store boot info in the machine state
hw/arm: versatilepb: Store boot info in the machine state
hw/arm: sabrelite: Store boot info in the machine state
hw/arm: realview: Store boot info in the machine state
hw/arm: orangepi: Store boot info in the machine state
hw/arm: omap_sx1: Store boot info in the machine state
hw/arm: npcm8xx: Store boot info in the machine state
hw/arm: npcm7xx: Store boot info in the machine state
hw/arm: musicpal: Store boot info in the machine state
hw/arm: mcimx7d-sabre: Store boot info in the machine state
hw/arm: kzm: Store boot info in the board state
hw/arm: integratorcp: Store boot info in the machine state
hw/arm: imx8mm-evk: Store boot info in the machine state
hw/arm: imx25_pdk: Store boot info in the board state
hw/arm: exynos4_boards: Store boot info in the board state
hw/arm: cubieboard: Store boot info in the machine state
hw/arm: collie: Store boot info in the machine state
hw/arm: bananapi_m2u: Store boot info in the machine state
hw/arm: aspeed_ast27x0-fc: Store boot info in the machine state
hw/arm: aspeed: Store boot info in the machine state
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Move the boot info into the existing ZynqMachineState.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20260816131300.51799-21-bin.meng@processmission.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Give both machine types the same VersatileMachineState instance struct
and store the boot info there.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-20-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Move the boot info into the existing SabreliteMachineState.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260816131300.51799-19-bin.meng@processmission.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Give all four realview machine types the same RealViewMachineState
instance struct and store the boot info there.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-18-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Move it into a new OrangePiMachineState and register the machine type
explicitly instead of through the DEFINE_MACHINE_ARM macro.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Message-id: 20260816131300.51799-17-bin.meng@processmission.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Give both the sx1 and sx1-v1 machine types the same Sx1MachineState
instance struct and store the boot info there.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260816131300.51799-16-bin.meng@processmission.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object inside
npcm8xx_load_kernel().
Let the caller own the boot info: the board stores it in its
NPCM8xxMachine and passes it to npcm8xx_load_kernel(), which only
fills in the SoC specific values.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-15-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object inside
npcm7xx_load_kernel().
Let the caller own the boot info: the boards store it in their
NPCM7xxMachine and pass it to npcm7xx_load_kernel(), which only fills
in the SoC specific values.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-14-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Move it into a new MusicPalMachineState and register the machine type
explicitly instead of through the DEFINE_MACHINE_ARM macro.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-13-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a function scoped static object.
Move it into a new Mcimx7dSabreMachineState and register the machine
type explicitly instead of through the DEFINE_MACHINE_ARM macro.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-12-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
The IMX31KZM struct is already allocated per machine instance, so
move the boot info there.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-11-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Move it into a new IntegratorcpMachineState and register the machine
type explicitly instead of through the DEFINE_MACHINE_ARM macro.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-10-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a function scoped static object.
Move it into a new Imx8mmEvkMachineState and register the machine type
explicitly instead of through the DEFINE_MACHINE_AARCH64 macro.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-9-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
The IMX25PDK struct is already allocated per machine instance, so
move the boot info there.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-8-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
The Exynos4BoardState struct is already allocated per machine
instance, so move the boot info there.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260816131300.51799-7-bin.meng@processmission.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Move it into a new CubieboardMachineState and register the machine
type explicitly instead of through the DEFINE_MACHINE_ARM macro.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-6-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Move the boot info into the existing CollieMachineState.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-5-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Move it into a new Bpim2uMachineState and register the machine type
explicitly instead of through the DEFINE_MACHINE_ARM macro.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260816131300.51799-4-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Move the boot info into the existing Ast2700FCState.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260816131300.51799-3-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
arm_load_kernel() keeps a pointer to the boot info struct for the
lifetime of the VM, so the struct logically belongs to the machine
rather than to a file scoped static object.
Move the boot info into the existing AspeedMachineState.
As in the xlnx-zcu102 and raspi machines, the boot info belongs to
the machine rather than to a static object:
4d1ac883a7 ("hw/arm: xlnx-zcu102: Move arm_boot_info into XlnxZCU102")
0f15c6e338 ("hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260816131300.51799-2-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Abstract out the register check for Neon insns into a new function,
similarly to what we have for VFP. We don't have any extra checks
that we need to add here, but having a neon_dregs_ok() is cleaner and
means the Neon decode isn't oddly different to the VFP decode.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260817123838.1578060-9-peter.maydell@linaro.org
On some v7A CPUs, CPACR.D32DIS is a bit allowing the guest to make
VFP instructions that touch registers D16..D31 UNDEF. Whether the
CPU implements this or not is IMPDEF, and the only two CPUs we
implement which have this are the Cortex-A7 and Cortex-A9. In v8A
the bit is no longer defined at all.
Since the only kind of trapping that needs to be done is a simple
UNDEF, this is straightforward enough to implement.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/1499
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260817123838.1578060-8-peter.maydell@linaro.org
Currently we directly call dc_isar_feature(aa32_simd_r32, s) for VFP
insns that use D16-D31 to see if they should UNDEF. For some v7A
CPUs (Cortex-A7, Cortex-A9) there is also a CPACR.D32DIS trap bit
that will make VFP (and only VFP, not Neon) insns using D16-D31
UNDEF.
Abstract out the register check for VFP insns into a new function
which will provide us a place where we can make this check.
Since D32DIS takes precedence over traps to EL2 and EL3 and simply
makes the insns UNDEF, we are OK to check it at the same point when
we do the CPU feature check, rather than having to wait until
vfp_access_check().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260817123838.1578060-7-peter.maydell@linaro.org
When executing at AArch32, there are optional trap bits for Neon
instructions in CPACR and HCPTR. We don't currently implement these.
Now we have a separate code path for access checks for Neon insns, we
can straightforwardly add the check there. We need to track the
target EL for Neon-specific trapping in a new TB flag.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/1499
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260817123838.1578060-6-peter.maydell@linaro.org
The traps configurable via CPACR.ASEDIS and HCPTR.TASE that trap only
Neon instructions are unfortunately IMPDEF about whether they are
implemented or not, and there is no ID register field that identifies
whether they are present. In practice, they are present on every
implementation I have checked except for the Cortex-A8 (which was the
first CPU with Neon).
Add a new feature ARM_FEATURE_NEON_TRAPS which we set on every
ARM_FEATURE_NEON CPU except the Cortex-A8, and make the CPACR.ASEDIS
and HCPTR.TASE bits RAZ/WI unless the CPU has ARM_FEATURE_NEON and
ARM_FEATURE_NEON_TRAPS.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260817123838.1578060-5-peter.maydell@linaro.org
In cpacr_write() a comment says "In ARMv8 most bits of CPACR_EL1 are
RES0", and the mask value is left at 0, implying that we enforce
those RES0 bits. In fact we only enforce RES0 when ARM_FEATURE_V8 is
not implemented, and for v8 and up we allow the guest to write any
bits. The addition of architectural features in v8 and v9 has also
resulted in the addition of new bits to CPACR_EL1, so "most bits are
RES0" isn't really true any more.
Update the comment to be a bit clearer.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260817123838.1578060-4-peter.maydell@linaro.org
In cptr_el2_read() and cptr_el2_write() we have code that implements the
"HCPTR.{TCP10,TCP11} behave as RAO/WI from NonSecure when NSACR.cp10 is
0" behaviour. There is a similar requirement for HCPTR.TASE: if
NSACR.NSASEDIS is 1 then CPACR.ASEDIS behaves as RAO/WI in NS.
This doesn't matter to us yet because we don't currently implement
ASEDIS or NSASEDIS. But we're about to do that, so add the handling
to cptr_el2_read() and cptr_el2_write().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260817123838.1578060-3-peter.maydell@linaro.org
In cpacr_read() and cpacr_write() we have code that implements the
"CPACR.{cp10,cp11} behave as RAZ/WI from NonSecure when NSACR.cp10 is
0" behaviour. There is a similar requirement for CPACR.ASEDIS: if
NSACR.NSASEDIS is 1 then CPACR.ASEDIS behaves as RAO/WI in NS.
This doesn't matter to us yet because we don't currently implement
ASEDIS or NSASEDIS. But we're about to do that, so add the handling
to cpacr_read() and cpacr_write().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260817123838.1578060-2-peter.maydell@linaro.org
TYPE_AX3000_SOC declares an Ax3000SoCClass via OBJECT_DECLARE_TYPE() and
ax3000_class_init() writes to it:
Ax3000SoCClass *sc = AX3000_SOC_CLASS(oc);
sc->num_cpus = AX3000_NUM_CPUS;
but its TypeInfo omits .class_size, so type_initialize() only allocates
class_size inherited from the parent, i.e. sizeof(SysBusDeviceClass).
The store to sc->num_cpus therefore writes 4 bytes of the value 4 just
past the end of the class allocation, corrupting whatever heap block
follows it.
Fix by setting class_size.
Fixes: 33a71a68c6 ("hw/arm: Add Axiado SoC AX3000")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4197
Signed-off-by: Doug Cook <dcook@microsoft.com>
Message-id: LVXPR21MB70090B04FF7397B0F2A201C8ADA72@LVXPR21MB7009.namprd21.prod.outlook.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260811191540.79882-4-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The trans_WHILE_ptr function incorrectly handles the case where the
address difference divided by ESIZE results in zero. This happens when
the address difference is less than ESIZE but greater than zero.
Fix by dropping direct comparisons of op0 vs op1, and instead
testing the scaled diff vs 0. Merge with the bounding to the
maximum vector length via wrapping arithmetic.
Cc: qemu-stable@nongnu.org
Fixes: 14f6dad168 ("target/arm: Implement SVE2 WHILERW, WHILEWR")
Reported-by: YanjunYang <yang.yanjun1@sanechips.com.cn>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260811191540.79882-3-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Move from tcg-op-gvec.c to tcg-op.c.
Use a temporary, to cover the possibility of operand overlap.
(Cc for stable as this is a prerequisite for the bug fix
in the next commit.)
Cc: qemu-stable@nongnu.org
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260811191540.79882-2-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Annotate the minimum revion from which each feature is OPTIONAL.
Modulo some sorting of properties at the end, comment changes
only.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260812204435.295067-10-richard.henderson@linaro.org
[PMM: fixed two minor comment issues]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The function is unused without TCG, so move.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260812204435.295067-7-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260812204435.295067-6-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260812204435.295067-5-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Invert aa32_only argument to what is actually used.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260812204435.295067-4-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
There's no reason to pass Object when ARMCPU is more appropriate.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260812204435.295067-3-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Once we have eliminated hwaccel_enabled, only tcg and qtest remain.
Separate tcg from qtest initialization. Remove an assert on
aarch64_enabled that is directly protected by a preceding if.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260812204435.295067-2-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
While trying to fix the GICv3 dependency on KVM and WHPX in
commit 39a8c3941e, we missed the Kconfig ARM_GIC symbol only
selects GICv3 for TCG, not HVF and WHPX. Fix that.
Cc: qemu-stable@nongnu.org
Fixes: 39a8c3941e ("hw/intc/arm_gicv3: Fix ARM_GICV3 dependency for KVM / WHPX")
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260812220816.94034-1-philmd@oss.qualcomm.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
While 39a8c3941e may have fixed WHPX, it certainly didn't help KVM:
$ QTEST_QEMU_BINARY=./qemu-system-aarch64 ./tests/qtest/arm-cpu-features
...
qemu-system-aarch64: unknown type 'kvm-arm-gicv3'
That patch did remove a test for TARGET_AARCH64, which is fine because
it has been a long time since we supported KVM for AArch32.
Cc: qemu-stable@nongnu.org
Fixes: 39a8c3941e ("hw/intc/arm_gicv3: Fix ARM_GICV3 dependency for KVM / WHPX")
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260812200308.289238-1-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
So far TCG plugins can only be used when TCG is available.
Move the arm_do_plugin_vcpu_discon_cb() call within the
'if tcg_enabled' block and wrap the definition with #ifdef'ry.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-id: 20260814080507.23196-1-philmd@oss.qualcomm.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* rust: fix issues in bits crate
* rust: replace bilge dependency with bitfield-struct
* rust: update build system for Meson 1.12.0
* serial: fix hot-unplug issue
* target/i386: emulate: simplify flags conversion and storage
* target/i386: tcg: small fixes
* target/i386: mshv: complete migration support
* target/i386: sev: add support for SEV features
* target/i386: whpx: bugfixes
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmqGq8wUHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroPWBwf6A4w91Tr+mxm3fjcbr/KjVqFnX45k
qG8l8+60WlA+YY4lUUCJHc4CtPPH9hinOKgm8yGjPdbFrpdcJgQPor4IUgIHnTGu
Bjceu5k6wlqR7DRetF0TD+NWC2BCkTtbmFcivLd5Ua/vqZVP5j+CITP3t7v5AiuG
+jEHPTqdk/RMhPdsXcFBl+WditIGNz1/R+pxMKGYfOxF9rQ86sSLd/y2cWrAYNnc
bO5s8vBxxoNNSxt8qt48aU4gGKvBajpvVQy4/6bPoSs1Z9fwCyCWkQleYSBcBAyn
3VTRAoift8j/xEgyOtXVdsviIeaUCE4S0aUGso+TMlA+SwEwSi20P917pg==
=OXwa
-----END PGP SIGNATURE-----
Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
* dockerfiles: cleanup, update CentOS 9 container to Python 3.11
* rust: fix issues in bits crate
* rust: replace bilge dependency with bitfield-struct
* rust: update build system for Meson 1.12.0
* serial: fix hot-unplug issue
* target/i386: emulate: simplify flags conversion and storage
* target/i386: tcg: small fixes
* target/i386: mshv: complete migration support
* target/i386: sev: add support for SEV features
* target/i386: whpx: bugfixes
# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCgAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmqGq8wUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroPWBwf6A4w91Tr+mxm3fjcbr/KjVqFnX45k
# qG8l8+60WlA+YY4lUUCJHc4CtPPH9hinOKgm8yGjPdbFrpdcJgQPor4IUgIHnTGu
# Bjceu5k6wlqR7DRetF0TD+NWC2BCkTtbmFcivLd5Ua/vqZVP5j+CITP3t7v5AiuG
# +jEHPTqdk/RMhPdsXcFBl+WditIGNz1/R+pxMKGYfOxF9rQ86sSLd/y2cWrAYNnc
# bO5s8vBxxoNNSxt8qt48aU4gGKvBajpvVQy4/6bPoSs1Z9fwCyCWkQleYSBcBAyn
# 3VTRAoift8j/xEgyOtXVdsviIeaUCE4S0aUGso+TMlA+SwEwSi20P917pg==
# =OXwa
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 20 Aug 2026 12:25:00 AM PDT
# gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg: issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [unknown]
# gpg: aka "Paolo Bonzini <pbonzini@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: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1
# Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83
* tag 'for-upstream' of https://gitlab.com/bonzini/qemu: (53 commits)
rust: remove bilge crate
rust: pl011: switch from bilge to bitfield-struct
rust: update Cargo dependencies
scripts: remove now dead parts of rustc_args.py
docs: rust: update for new-style build rules
rust: use meson automatic parsing of Cargo.toml
meson: use compiler_target() to get rustc target
rust: switch to autogenerated meson rules
rust: switch to cargo subprojects
rust: update Cargo.lock
rust/bits: Use checked_ilog2() in Binary::format to avoid panic
rust/bits: Align SubAssign behavior with Sub
python, meson: update meson required for Rust to 1.12.0
dockerfiles: update CentOS Stream 9 to Python 3.11, Meson to 1.12
dockerfiles: remove packages required by Avocado
meson: make linker warnings non-fatal on Linux
serial: clear transmit retry callback on unrealize
whpx: i386: inject back db
whpx: i386: work around Hyper-V FP state oddities
whpx: i386: synchronise PAT too
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Add maintainers for vm-launch-update device and associated documentation and
test code.
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20260817142010.80693-12-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patchset adds functional and unit tests that exercize various functions
and behaviors of vm-launch-update device. It uses the IGVM files that were
introduced in the previous patch for exercizing the hypervisor interface.
CC: Alex Graf <graf@amazon.com>
CC: Gerd Hoffman <kraxel@redhat.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20260817142010.80693-11-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Needed by launchupdate-test.c. README file is added with explanation on how
to build these IGVM files.
CC: Alex Graf <graf@amazon.com>
CC: Gerd Hoffman <kraxel@redhat.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20260817142010.80693-10-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This change adds a specification document and expanation for the
vm-launch-update device.
CC: Alex Graf <graf@amazon.com>
CC: Gerd Hoffman <kraxel@redhat.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20260817142010.80693-9-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
VM launch update is a mechanism where the virtual machines can use IGVM
file bundle to boot into a trusted execution environment without
having to depend on a untrusted party to provide the IGVM bundle or firmware
image. This is particularly useful for confidential virtual machines that
are deployed in the cloud where the tenant and the cloud provider are two
different entities. In this scenario, virtual machines can bring their own
trusted IGVM file containing a trusted firmware image
bundled as a part of their filesystem and then use this hypervisor interface
to update to a trusted and deterministic boot state.
This also allows the guests to have a consistent measurements on the firmware
image.
Currently, this mechanism only works if the VM was started with IGVM in the
first place.
This change introduces support for the fw-cfg based hypervisor interface
and the corresponding device. The interface is made generic
enough so that guests are free to use their own ABI to pass required
information between initial and trusted execution contexts (where they are
running their own trusted boot state) without the hypervisor getting
involved in between.
Currently, this device is only supported for x86_64 machines. Presence of
IGVM host libraries is also required for parsing IGVM files. Hence, the device
cannot be initialized for other machine types or hosts where IGVM support
is not present. Trying to initialize it for arm for example will lead to failure:
$ ./qemu-system-arm -device vm-launch-update -machine virt
qemu-system-arm: -device vm-launch-update: This machine does not support vm-launch-update device
A document detailing the specification is added in a subsequent patch. Please
see docs/specs/vmlaunchupdate.rst.
Functional and qtests are added in a subsequent patch.
CC: Alex Graf <graf@amazon.com>
CC: Gerd Hoffman <kraxel@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20260817142010.80693-8-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add a separate header file for guest usable api definitions.
CC: Alex Graf <graf@amazon.com>
CC: Gerd Hoffman <kraxel@redhat.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20260819041105.110625-1-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
cosmetic: add a tracepoint to track when memory regions are getting freed.
Useful for debugging and tracking all freed memory regions.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20260817142010.80693-5-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This change cleans up existing memory regions that were created by the current
IGVM. The cleanup would be necessary when a new IGVM is loaded. This cleanup
function is called in a subsequent patch.
Reviewed-by: Alexander Graf <graf@amazon.com>
Tested-by: Ani Sinha <anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260817142010.80693-4-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Memory regions added by the current IGVM needs to be tracked so that they can be
freed when a new IGVM is loaded.
Reviewed-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260817142010.80693-3-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Store a pointer to IgvmCfg instead of only IgvmFile in QIgvm. Allows to
store additional state in the (persistent) IgvmCfg struct.
Reviewed-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260817142010.80693-2-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
I have worked enough on the igvm to be confident to elevate myself to a
maintainer role.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20260818090905.87090-1-anisinha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
-----BEGIN PGP SIGNATURE-----
iLMEAAEKAB0WIQS4/x2g0v3LLaCcbCxAov/yOSY+3wUCaobkOQAKCRBAov/yOSY+
39I1A/0RIRLfq4CPqkCxPA3/nXctSVB8PlGtmgQuogXsM1+t2+g1VCiPYJ/siU17
BT59kvocdLGc62MpRIRbR949cwcM/MRJS8AghQ+J4jlo4EwgC2z4QHXrUDEOcrPP
DiPBaGviLStvGZPZnS0+2ZXmWKgQKD/InB22S/J4b4vOxO9Qwg==
=qbpH
-----END PGP SIGNATURE-----
Merge tag 'pull-loongarch-20260820' of https://github.com/gaosong715/qemu into staging
pull-loongarch-20260820
# -----BEGIN PGP SIGNATURE-----
#
# iLMEAAEKAB0WIQS4/x2g0v3LLaCcbCxAov/yOSY+3wUCaobkOQAKCRBAov/yOSY+
# 39I1A/0RIRLfq4CPqkCxPA3/nXctSVB8PlGtmgQuogXsM1+t2+g1VCiPYJ/siU17
# BT59kvocdLGc62MpRIRbR949cwcM/MRJS8AghQ+J4jlo4EwgC2z4QHXrUDEOcrPP
# DiPBaGviLStvGZPZnS0+2ZXmWKgQKD/InB22S/J4b4vOxO9Qwg==
# =qbpH
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 20 Aug 2026 04:25:45 AM PDT
# gpg: using RSA key B8FF1DA0D2FDCB2DA09C6C2C40A2FFF239263EDF
# gpg: Good signature from "Song Gao <m17746591750@163.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: B8FF 1DA0 D2FD CB2D A09C 6C2C 40A2 FFF2 3926 3EDF
* tag 'pull-loongarch-20260820' of https://github.com/gaosong715/qemu:
target/loongarch: check FPE before reading fcc in bceqz/bcnez
target/loongarch: KVM disable msgint
Add dintc kvm_irqchip_in_kernel support
target/loongarch: Add kvm support dintc
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
gen_cz_bc() loads env->cf[cj] without CHECK_FPE, unlike every other
translator that touches an fcc register (trans_fcmp.c.inc and
trans_fmov.c.inc, for movcf2gr/movgr2cf/movcf2fr/movfr2cf/fsel).
A guest that manages the FPU lazily -- Linux clears CSR.EUEN.FPE in
lose_fpu() on every context switch -- relies on the next fcc access
raising a Floating-Point-Disabled exception so the kernel can restore
that task's fcc. Because bceqz and bcnez never raise it, they branch on
the condition flag left behind by whichever task last owned the FPU.
Real Loongson hardware does raise the exception, so this is TCG-only.
It surfaces as Go binaries dying at startup in runtime.check() with
"fatal error: float64nan1" -- roughly one process start in a thousand
once the guest has more runnable tasks than vCPUs -- and in general as a
conditional branch silently taking the wrong path.
With four tasks each executing 5M bcnez on a 2-vCPU guest, master
mispredicts 89 of 20000000. With this patch, 0 of 100000000 over five
runs; a Loongson-3C5000 is likewise 0 of 600000000.
CHECK_FPE is defined in trans_farith.c.inc, which translate.c includes
before trans_branch.c.inc, so it is already in scope.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4209
Cc: qemu-stable@nongnu.org
Signed-off-by: Jan Mercl <0xjnml@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260819132422.5164-1-0xjnml@gmail.com>
Signed-off-by: Song Gao <gaosong@loongson.cn>
In KVM mode, msgint is disabled by default; please enable it manually.
e.g
... -cpu max,msgint=on ...
Signed-off-by: gaosong <gaosong@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Message-ID: <20260813111000.446232-4-gaosong@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Function kvm_dintc_realize() is added if kvm_irqchip_in_kernel is
set. It is to create and initialize DINTC device in kernel mode.
and use kvm_irqchip_send_msi() to send msi to kernel.
Signed-off-by: Song Gao <gaosong@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Message-ID: <20260813111000.446232-3-gaosong@loongson.cn>
It has just been replaced with bitfield-struct.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The bilge crate is heavily reliant on traits and, because trait functions
are never const, bilge and const mix about as well as water and oil.
In addition, it has support for the zerocopy crate that only works for an
older version, and is hard to update because the implementation doesn't
like that zerocopy::FromBits and bilge::FromBits are the same name.
zerocopy is definitely something that QEMU could use in the future.
The bitfield-struct crate, instead, is built from the ground up to
support const. Its use is pretty much the same (device code does not
change at all, only register declarations do), with some things being
more verbose and others being simpler. The code for the crate itself
is much smaller, too.
It does have two disadvantages: it does not let you annotate enums
as bitfields, and it does not integrate with arbitrary-int. Thus, it
requires manual size annotations for anything that is not a bool, iNN
or uNN. Lack of support for arbitrary-int is a very small deal, while
enums are a bit more annoying because they require some repetition
and an implementation of two functions from_bits() and into_bits().
However, the latter is already provided by the "bits!" and
"#[derive(common::TryInto)]" utilities, and thus is not manual
in QEMU's case.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Update dependencies that are not used by meson, only by Cargo.
Several packages have now reached v1 and therefore updates may
be less intrusive in the future.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The logic to parse the [lints] section has been integrated
into Meson and can be removed.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Finally, automatic parsing of Cargo.toml is also possible for QEMU's own
crates, not just for subprojects. This removes the need to list the
dependencies and language editions in both Cargo.toml and meson.build
files.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The new method in Meson 1.11.x removes the need to pass the triple
via config-host.mak.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Meson can automatically generate most of the build rules for
subprojects, based on the contents of their Cargo.toml. Handwritten
snippets can be placed in meson/meson.build to replace build.rs.
Disable Meson's use of the nightly-only option "--env-set". It is
buggy and anyway it should not be there in future version.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Let Meson parse Cargo.lock and Cargo.toml and figure out the set
of Rust build dependencies. For now, the only change is that
subprojects are retrieved with "cargo_ws.subproject('NAME')"
instead of "subproject('NAME-API-rs')". However, just calling
"import('rust').workspace()" enables extra functionality that
operates by parsing Cargo.toml; it will be introduced a step
at a time in subsequent commits.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Update SubAssign to perform a bit-clear operation instead of arithmetic
subtraction, matching the behavior of Sub.
Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
Link: https://lore.kernel.org/r/20260802170346.3493821-2-phind.uet@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Meson 1.11.0 brings support for parsing Cargo.toml inside QEMU's source
tree, and Meson 1.12.0 brings support for cross-compilation of Cargo
subprojects.
Together, these two features allow QEMU to remove hundreds of lines of
manual compilation scripts.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Python 3.10, which is a requirement for Meson 1.12.0, was never packaged
for CentOS Stream 9 so update directly to 3.11.
CentOS 9 does not install meson from PyPI because configure will install
it from the bundled wheel; this way CI covers that path as well. This is
guaranteed because, when using a non-default Python, basically nothing
is installed.
The opensuse-leap-15.yml file was not in use anymore, so delete it
while touching tests/lcitool/targets/.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Make our CI containers smaller, by removing a handful of packages that
were only included as dependencies of Avocado.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
These cause a werror=true build to fail with Meson 1.12.0, as it now
makes linker warnings fatal as well.
Cc: qemu-stable@nongnu.org
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The GSource is removed when resetting but remains active (and can
cause use-after-free) on hot-unplug. Remove it before the character
device is disconnected.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4125
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
On Hyper-V looks like we need to fetch both the legacy
and new state instead of being able to rely on xsave.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Link: https://lore.kernel.org/r/20260812082814.27217-6-mohamed@unpredictable.fr
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
https://github.com/cmspam/winq-emu hints that this might be wanted for
some use-cases and it's a step towards full state sync:
> Linux uses PAT to mark virtio-gpu / Venus shared memory as
> Write-Combining. Previously the partition's PAT was not
> synchronised with the guest, so the guest's MTRR/PAT cache-type
> computation could fall back to UC for memory that should be WC.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260812082814.27217-5-mohamed@unpredictable.fr
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
x86_flags.c encodes the flags into cc_dst and cc_src with algorithms
essentially derived from Bochs; the exact details have changed but cc_dst
is Bochs result and cc_src is very close to Bochs auxbits. However,
using only two words is unnecessarily limiting because it splits SF/PF
between the two words even though *ZF* is the real nuisance (ZF=1 implies
SF=PF=0) and the one that commands usage of PD/SD delta bits.
Within TCG, the CCMP instruction would have a similar need of efficiently
encoding an arithmetic result or an EFLAGS value; it is not implemented,
but there are plans (see commit message for 5dcdbd0712, "target/i386:
tcg: use cout to commonize add/adc/sub/sbb cases", 2025-04-17) to use
an algorithm very similar to target/i386/emulate's, but with *three* words.
Then SF and PF live together in harmony, because SF can be encoded with
either parity and PF does not use the high bit where SF is stored; by
placing them in a third word their computation is isolated from ZF's
and everything becomes simpler.
In fact I'm not even sure why Bochs did it like that, and did not just
give SF/PF their own home in a third word as well; the developers believe
that the extra store is too expensive. I am not really sure about that,
but as far as QEMU is concerned, emulation proceeds one instruction at a
time so using SRC2 should actually be faster, not just easier. To convert
from the output of arithmetic operations, PD and SD disappear and DST
simply has to be stored in two places; to convert to RFLAGS, SF/PF are
easily computed from SRC2 as if PD=SD=0; conversion to LFLAGS encodes
parity in bit 0 and mixes in SF as an even-parity value with the right
sign bit.
Unlike TCG, there is a single meaning for all operand lengths, which
corresponds to either CCMPL or CCMPQ depending on sizeof(target_ulong).
So the carry-out value still needs to be split---with AF in bit 3
and CF/PO in the higher bits of the target_ulong-sized env->cc_src.
This is an acceptable tradeoff for the interpreter, in order to optimize
lflags_to_rflags.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- Use GLib wrappers during QTEST_LOG parsing
- Skip tests when 'pc' machine is not built in
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmqFvgkQHGZhcm9zYXNA
c3VzZS5kZQAKCRDHmNx0G+wxnaQuD/9itCBxx1EfDgMoyf2nhcWPIiFUnNFoU2g6
G+V3GcNXsTe3MbA/IImj01bUjjsvnyuTQqgzg1VQg1U2zCth5uLYwr82GxWkLB2W
M0l66zfwYdlu8R3q24JLd1vWweWK9GH71Wv7oRx5skR1nTqFQeitotcd7Qb6Ut8m
BHRYqrjAdaOVlx0jvaV9lksoDJkVmDlK09HoSS4+TUmht0lPZv4u3y+t4bUqi7fa
5zMjdaxgq4jltA4UkBOMy+EqvYijZbEmLHOgtx21c0obmiVWHf+NrE8jMF4rmNNS
SOk5JFIq1kyF6kLDn/BzxsFUdsX1W3ZYxjnFOuFf3CNHJB+0v9n4S96DLkHpZ4cM
+1sV98MmaoAAXN5d3Uc1ZwDAlhunkUmoic0r6q4YmNgQCRqVRjMgE9aSr7JevN2U
nRYfPuLkKj7aoE7sCK88Ft0X6wH7vFxz+lqCx7Crg1Z0t4kCAo8FemNLO8kSSUZ/
IgDzBx5eoqyL9IJRsmtwFH2O5XFSKuhs8dTZqNLV4X0saIuXxR2iofuTonxtvvHh
Q30etPmgqnll/LxhtVNrzXP4+gWXKIgpBhAOPGgIpr0xNeNv9G8qGXorMC7m117T
8iJjaExJGT1u9hyH3TCzjVapgZFylMMT2dFGLOLrSpqfebtAZDz7KoUJZDO343l/
v17mT8jcCQ==
=un2j
-----END PGP SIGNATURE-----
Merge tag 'qtest-20260819-pull-request' of https://gitlab.com/farosas/qemu into staging
QTest pull request
- Use GLib wrappers during QTEST_LOG parsing
- Skip tests when 'pc' machine is not built in
# -----BEGIN PGP SIGNATURE-----
#
# iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmqFvgkQHGZhcm9zYXNA
# c3VzZS5kZQAKCRDHmNx0G+wxnaQuD/9itCBxx1EfDgMoyf2nhcWPIiFUnNFoU2g6
# G+V3GcNXsTe3MbA/IImj01bUjjsvnyuTQqgzg1VQg1U2zCth5uLYwr82GxWkLB2W
# M0l66zfwYdlu8R3q24JLd1vWweWK9GH71Wv7oRx5skR1nTqFQeitotcd7Qb6Ut8m
# BHRYqrjAdaOVlx0jvaV9lksoDJkVmDlK09HoSS4+TUmht0lPZv4u3y+t4bUqi7fa
# 5zMjdaxgq4jltA4UkBOMy+EqvYijZbEmLHOgtx21c0obmiVWHf+NrE8jMF4rmNNS
# SOk5JFIq1kyF6kLDn/BzxsFUdsX1W3ZYxjnFOuFf3CNHJB+0v9n4S96DLkHpZ4cM
# +1sV98MmaoAAXN5d3Uc1ZwDAlhunkUmoic0r6q4YmNgQCRqVRjMgE9aSr7JevN2U
# nRYfPuLkKj7aoE7sCK88Ft0X6wH7vFxz+lqCx7Crg1Z0t4kCAo8FemNLO8kSSUZ/
# IgDzBx5eoqyL9IJRsmtwFH2O5XFSKuhs8dTZqNLV4X0saIuXxR2iofuTonxtvvHh
# Q30etPmgqnll/LxhtVNrzXP4+gWXKIgpBhAOPGgIpr0xNeNv9G8qGXorMC7m117T
# 8iJjaExJGT1u9hyH3TCzjVapgZFylMMT2dFGLOLrSpqfebtAZDz7KoUJZDO343l/
# v17mT8jcCQ==
# =un2j
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 19 Aug 2026 07:30:33 AM PDT
# gpg: using RSA key AA1B48B0A22326A5A4C364CFC798DC741BEC319D
# gpg: issuer "farosas@suse.de"
# gpg: Good signature from "Fabiano Rosas <farosas@suse.de>" [unknown]
# gpg: aka "Fabiano Almeida Rosas <fabiano.rosas@suse.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: AA1B 48B0 A223 26A5 A4C3 64CF C798 DC74 1BEC 319D
* tag 'qtest-20260819-pull-request' of https://gitlab.com/farosas/qemu:
tests/qtest/pxe-test: skip per-row cases whose machine is unavailable
tests/qtest/drive_del-test: skip pc tests when 'pc' machine is unavailable
tests/qtest/device-plug-test: skip pc tests when 'pc' machine is unavailable
tests/qtest/libqtest: Use GLib functions for proper const correctness
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
The x86 test table mixes 'pc' and 'q35' rows. When QEMU is built without
the i440fx/pc machine, the 'pc' rows fail with "unsupported machine type".
Add a per-row qtest_has_machine() check in test_batch(), mirroring the
existing per-row qtest_has_device() guard, so rows for an unavailable
machine are skipped while the others (e.g. q35) still run.
Signed-off-by: Rohitashv Kumar <roohiit@amazon.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
test_cli_device_del(), test_device_add_and_del(),
test_drive_add_device_add_and_del() and
test_blockdev_add_device_add_and_del() use "-machine pc" on i386/x86_64.
When QEMU is built without the i440fx/pc machine, these fail with
"unsupported machine type 'pc'".
Skip the x86 case when 'pc' is not available. Non-x86 architectures use
the default machine and are unaffected, and the corresponding _q35
variants already cover x86 under qtest_has_machine("q35").
Signed-off-by: Rohitashv Kumar <roohiit@amazon.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
test_pci_unplug_request() and test_pci_unplug_json_request() use
"-machine pc" on i386/x86_64. When QEMU is built without the i440fx/pc
machine, these fail with "unsupported machine type 'pc'".
Skip the x86 case when 'pc' is not available. Non-x86 architectures use
the default machine and are unaffected, and x86 unplug coverage is still
provided by the q35 variant (test_q35_pci_unplug_request), which already
guards on qtest_has_machine("q35").
Signed-off-by: Rohitashv Kumar <roohiit@amazon.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
While commit e68da5b7a2 ("tests/qtest: fix discarded const qualifier
warning") addressed the immediate strstr() warning by making 'found'
const, there's still a room for improvement: getenv() returns char *, but
environment strings are semantically read-only and should be treated as const
throughout their lifetime.
Replace getenv() with g_getenv() and strstr() with g_strstr_len() to
maintain const correctness from source to use. This approach:
- Uses g_getenv() which returns const gchar *, matching the read-only
semantics of environment variables
- Employs g_strstr_len() for consistent use of GLib string functions,
aligning with QEMU conventions
- Eliminates all const-correctness warnings with strict compilers
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Aditya Gupta <adityag@linux.ibm.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
In particular, this enables many more vector insns.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Song Gao <17746591750@163.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
In capstone v5, riscv support is spare, but v6 is pretty good.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
cap_insn_unit is designed for targets like arm thumb2
and s390x where 4 and 6-byte insns are displayed in
2-byte chunks.
For riscv, we prefer 4-byte insns to display as one
4-byte unit, rather than 2x 2-byte units. So we will
want to set cap_insn_unit to 4, but allow for insns
that are smaller than 4. Emit padding to match.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Constify the env pointer and return bool.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We already have an expansion of CTZ using RBIT+CLZ,
but use the new insn with FEAT_CSSC is present.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We already have these for vectors; replicate for integers.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Use one macro for all test templates.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
RISCV_HWPROBE_EXT_ZBKB was introduced in linux 6.10
with the rest of the hwprobe api.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
These are nearly identical to bswap, so reuse fold_bswap.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Add the plumbing, but not yet implemented for any host.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Use tcg_gen_revbit64_i64 instead of out-of-line helpers.
Reviewed-by: Anton Johansson <anjo@rev.ng>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Song Gao <17746591750@163.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Add generic expanders for reversing bits within a word.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We use an array of char for bswap_flag_name, so some
entries in the array are non-null but empty. Check that.
Fixes: 587195bd59 ("tcg: Add flags argument to bswap opcodes")
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
A vCPU hotplug may happen at any time. When the new thread is
started, the region pool may be exhausted. Do not abort.
Rename tcg_region_thread_initial_alloc to differentiate it
from tcg_region_initial_alloc__locked. The renamed function
now uses tcg_region_alloc__locked and is prepared for failure.
In tcg_tb_alloc, allow code_gen_ptr to be NULL. Treat that as
any other region exhaustion. Reorg with while instead of goto.
Tested-by: Yogesh Vyas <yvyas1991@gmail.com>
Reviewed-by: Yogesh Vyas <yvyas1991@gmail.com>
Reported-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/2984
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Invert the sense of the boolean result from 'error' to 'success'.
Tested-by: Yogesh Vyas <yvyas1991@gmail.com>
Reviewed-by: Yogesh Vyas <yvyas1991@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Invert the sense of the boolean result from 'error' to 'success'.
Tested-by: Yogesh Vyas <yvyas1991@gmail.com>
Reviewed-by: Yogesh Vyas <yvyas1991@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
record_save() assumed that a target reads the bytes of an insn as a
strictly ascending sequence of adjacent chunks, and asserted that each
read begins exactly where the previous one ended.
That assumption no longer holds for riscv. Since f9eaa1542b
("target/riscv: support atomic instruction fetch (Ziccif)"),
decode_opc() loads a full aligned word whenever pc is 4-byte aligned,
even when the insn turns out to be a 2-byte compressed one, so the
record may already hold bytes past the end of the insn being
translated. When such a compressed insn sits at page offset 0xffc,
pc_next becomes 0xffe, which is within MAX_INSN_LEN of the end of the
page, and riscv_tr_translate_insn() probes the next insn to decide
whether it would cross the page boundary. That probe reads at offset
2 while the record already covers [0,4), and the assert fires:
qemu-system-riscv32: accel/tcg/translator.c:395: record_save:
Assertion `offset == db->record_start + db->record_len' failed.
record_save() is only reached when the insn is fetched from MMIO, so
this is visible on boards that execute code from a region created with
memory_region_init_io(), such as an XIP flash window mapped over a
serial flash controller.
Both sides of the collision are correct: the wide fetch is required for
Ziccif atomicity, and the probe is required for correct fault reporting
at a page boundary, per 00c07344fa ("target/riscv: Make translator stop
before the end of a page"). Unlike a86d3352ab ("target/riscv: do not
use translator_ldl in opcode_at"), where a non-translation caller had
no business using translator_ld*, the probe here is a genuine
translation read whose bytes must be recorded.
Relax the invariant instead. Keep requiring that a read neither moves
backwards nor leaves a gap, but let a read overlapping the recorded
range extend it only by the bytes past its end.
Cc: qemu-stable@nongnu.org
Fixes: f9eaa1542b ("target/riscv: support atomic instruction fetch (Ziccif)")
Signed-off-by: Ilya Chichkov <ilya.chichkov.dev@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260814142159.3800744-1-ilya.chichkov.dev@gmail.com>
Skip s_mask computation for logical right shift.
Cc: qemu-stable@nongnu.org
Fixes: 93a967fbb5 ("tcg/optimize: Propagate sign info for shifting")
Reported-by: Jacob Young <jacobly@ziglang.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
The chunk size is an int and is shifted left by 3 before the result is
widened, so a chunk size of 1 << 28 or above overflows.
parallels passes s->cluster_size, which parallels_open() lets reach
2 GiB. With a bitmap needing two L1 entries the bogus limit makes the
"bm_size - offset" in parallels_load_bitmap_data() underflow; both
wrong values slip past the assertions in serialization_chunk() and the
resulting index lands outside the hbitmap, so a 128 KiB image memsets
unrelated memory through hbitmap_deserialize_ones().
Widen the shift. qcow2, the only other caller, never exceeds a 2 MiB
cluster.
Fixes: 35f428ba39 ("qcow2-bitmap: make bytes_covered_by_bitmap_cluster() public")
Cc: Eric Blake <eblake@redhat.com>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Message-ID: <20260811173857.396571-4-den@openvz.org>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
block-dirty-bitmap-remove refuses any readonly bitmap outright, via
the generic BDRV_BITMAP_RO check in bdrv_dirty_bitmap_check(). That
check cannot tell whether the bitmap is actually on disk, so it also
blocks dropping one that only ever existed in memory, which needs no
write at all.
Drop the blanket check and let qcow2 decide: bdrv_remove_persistent_
dirty_bitmap() already treats an absent on-disk entry as a no-op, so
such a bitmap is now released with no write attempted. For one that
is genuinely stored, qcow2_co_remove_persistent_dirty_bitmap_locked()
now checks can_write() before it would update the on-disk directory,
so removal still fails there, with a message naming the actual
reason instead of just the bitmap's readonly flag.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Eric Blake <eblake@redhat.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
CC: John Snow <jsnow@redhat.com>
CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-ID: <20260716112242.3000035-4-den@openvz.org>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
dirty_bitmap_load_start() creates an incoming migrated bitmap with
bdrv_create_dirty_bitmap() and, if the source marked it persistent,
calls bdrv_dirty_bitmap_set_persistence() without checking whether
the destination node can be written to. Same gap as
qmp_block_dirty_bitmap_add(), reached via incoming migration: a
persistent bitmap for a read-only destination (e.g. a migrated
CD-ROM-class attachment with dirty-bitmaps migration enabled) ends
up writable in memory on a node that can never store it.
Reject it the same way, with one difference from the QMP path:
every destination node is BDRV_O_INACTIVE until migration completes,
so bdrv_is_writable() would reject every incoming persistent
bitmap, not just read-only ones. Check bdrv_is_read_only() alone.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Eric Blake <eblake@redhat.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
CC: John Snow <jsnow@redhat.com>
CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-ID: <20260716112242.3000035-3-den@openvz.org>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
qmp_block_dirty_bitmap_add() marks a new bitmap persistent without
checking write access to its node. bdrv_create_dirty_bitmap() always
creates bitmaps writable, so a persistent bitmap added to an
already read-only node stays writable in memory on a node that can
never store it, and the next global inactivation fails:
Lost persistent bitmaps during inactivation of node '<node>': No write access
migration_block_inactivate: bdrv_inactivate_all() failed: -22
Forcing it read-only instead does not help: it was never stored,
so it stays unpromotable on the next reopen to read-write and can
trip bdrv_set_dirty()'s readonly assert on the first write. Reject
the add instead, for both read-only and inactive nodes -- an
already-inactive node skips qcow2_inactivate() on close, so a
bitmap added during that window would never get stored either.
Wrapped in a transaction, this denies the whole transaction, since
qmp_transaction() is already all-or-none.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Eric Blake <eblake@redhat.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
CC: John Snow <jsnow@redhat.com>
CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-ID: <20260716112242.3000035-2-den@openvz.org>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Add a regression test for the previous commit. A job that has reached
its pause point is spuriously re-entered (job_enter()) while a pause is
still pending (pause_count > 0), reproducing what an overlapping drain
does: one drain's job_resume() wakes the job while the next drain's
job_pause() is already counted. The job must stay parked - it must not
run job code or clear job->paused, or job_set_aio_context() could
observe paused == false and abort.
The test counts the job's run-loop iterations: without the fix the
re-entered job clears job->paused, runs one iteration and re-pauses, so
the counter advances; with the fix it stays parked and the counter is
unchanged. It runs in the main AioContext, so job_enter() is synchronous
and the check is deterministic.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Message-ID: <20260623152406.1180235-3-den@openvz.org>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
job_pause_point_locked() sets job->paused before yielding and clears it
unconditionally on wake, before re-checking whether a pause is still
pending. job_pause() re-enters a parked job only while it is not yet
paused, so the wake that resumes one comes from a drain *ending*
(job_resume() -> job_enter_cond()). If the next drain begins before that
wake runs, the woken coroutine clears job->paused while pause_count is
already > 0 again:
AioContext change (BQL thread) job coroutine (iothread)
----------------------------- ------------------------
parked in job_pause_point():
paused=1, pause_count=1, yielded
drain ends -> job_resume():
pause_count = 0
job_enter_cond(): queue wake ..> (wake pending)
bdrv_try_change_aio_context():
bdrv_drain_all_begin():
job_pause() per node
pause_count = N (> 0)
wake runs, leaves job_do_yield():
paused = 0 (pause_count == N)
tran_commit -> job_set_aio_context():
assert(paused || completed) --> abort: paused == 0
bdrv_try_change_aio_context() drains precisely to quiesce the job before
changing its AioContext, but that brief paused==0 window trips the
assertion. It is guest-triggerable: a virtio-blk reset
(virtio_blk_stop_ioeventfd() -> blk_set_aio_context()) racing a running
mirror/blockCopy job hits it, as do x-blockdev-set-iothread, blockdev
hot-plug/unplug and job completion.
Keep job->paused set while a pause is still pending: loop the yield
until job_should_pause_locked() is false (or the job is cancelled), and
only then clear job->paused. Drained-state consumers then never observe
a pending-pause job as unpaused.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Message-ID: <20260623152406.1180235-2-den@openvz.org>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Remove all usages of __func__ in target/i386/sev.c to align with the
general QEMU preference, and replace those with "SEV:" prefix.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/r/20260626070010.1955433-1-naveen@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Refactor check_sev_features() to consolidate SEV-SNP checks to a single
if block. This is also helpful when adding checks for future SEV
features. While at it, move the comment about the checks being done
outside of the function body and expand it to describe what this
function does. Update error_setg() invocations to use a consistent
format.
No functional change intended.
Suggested-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/cae04d88adfbcdc2997e518475f3b89091adf8a9.1779281646.git.naveen@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add support for configuring the TSC frequency when Secure TSC is enabled
in SEV-SNP guests through a new "tsc-frequency" property on SEV-SNP
guest objects, similar to the vCPU-specific property used by regular
guests and TDX. A new property is needed since SEV-SNP guests require
the TSC frequency to be specified during early SNP_LAUNCH_START command
before any vCPUs are created.
The user-provided TSC frequency is set through KVM_SET_TSC_KHZ before
issuing KVM_SEV_SNP_LAUNCH_START.
Attempts to set TSC frequency on both the SEV_SNP object and the cpu
object result in an error from KVM (on the vCPU ioctl), so do not add
separate checks for the same.
Sample command-line:
-machine q35,confidential-guest-support=sev0 \
-object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on,tsc-frequency=2500000000
Co-developed-by: Ketan Chaturvedi <Ketan.Chaturvedi@amd.com>
Signed-off-by: Ketan Chaturvedi <Ketan.Chaturvedi@amd.com>
Co-developed-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/af688610978f213a456a7753e1d9fe7d3a51e80a.1779281646.git.naveen@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add support for enabling Secure TSC VMSA SEV feature in SEV-SNP guests
through a new "secure-tsc" boolean property on SEV-SNP guest objects. By
default, KVM uses the host TSC frequency for Secure TSC.
Sample command-line:
-machine q35,confidential-guest-support=sev0 \
-object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Co-developed-by: Ketan Chaturvedi <Ketan.Chaturvedi@amd.com>
Signed-off-by: Ketan Chaturvedi <Ketan.Chaturvedi@amd.com>
Co-developed-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/9f58b92a173f319b3ef725f5ed8a2a173eed55b1.1779281646.git.naveen@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add support for enabling debug-swap VMSA SEV feature in SEV-ES and
SEV-SNP guests through a new "debug-swap" boolean property on SEV guest
objects. Though the boolean property is available for plain SEV guests,
check_sev_features() has a check that rejects attempts to enable any SEV
feature for a plain SEV guest.
Though this SEV feature is called "Debug virtualization" in the APM, KVM
calls this "debug swap" so use the same name for consistency.
Sample command-line:
-machine q35,confidential-guest-support=sev0 \
-object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,debug-swap=on
Restrict debug-swap to SEV-SNP guests at this time due to a
compatibility issue with SEV-ES pflash devices.
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/416e7b156e49f95958f8c5c8549b48a88c1995fc.1779281646.git.naveen@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In preparation for allowing SEV-ES guests to enable VMSA SEV features,
update sev_init2_required() to return true if any SEV features are
requested. This enables qemu to use KVM_SEV_INIT2 for SEV-ES guests when
necessary.
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/f2a7778ab26b11a8de90e170ff984ccd29dc05a0.1779281646.git.naveen@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
SEV features in the VMSA are only meaningful for SEV-ES and SEV-SNP
guests, as they control aspects of the encrypted guest state that are
not relevant for basic SEV guests.
Add a check in check_sev_features() to ensure that SEV-ES or SEV-SNP is
enabled when any SEV features are specified.
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/11e34ae3db91643e45e097404d1aa949a820aa0d.1779281646.git.naveen@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently, check_sev_features() is called in multiple places when
processing IGVM files: both when processing the initial VMSA SEV
features from IGVM, as well as when validating the full contents of the
VMSA. Move this to a single point in sev_common_kvm_init() to simplify
the flow, as well as to re-use this function when VMSA SEV features are
being set without using IGVM files.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/35449df94eb20c29923a7cd0e2742ddba605928c.1779281646.git.naveen@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In preparation for qemu being able to set SEV features through the cli,
add a check to ensure that SEV features are not also set if using IGVM
files.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/6939de99f13d7170af68b74e711eb9f03f32f682.1779281646.git.naveen@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Align with IGVM files providing SEV features with
SVM_SEV_FEAT_SNP_ACTIVE set by setting the same when creating a
sev-snp-guest object.
Since KVM sets this feature itself, SVM_SEV_FEAT_SNP_ACTIVE is unset
before KVM_SEV_INIT2 ioctl is invoked. Move that out of IGVM-specific
section to common code.
While at it, convert the existing SVM_SEV_FEAT_SNP_ACTIVE definition to
use the BIT() macro for consistency with upcoming feature flags.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/031de849edf2ae4eaa6e00df83b053605a3ecfea.1779281646.git.naveen@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This has been a warning before that was always raised if the machine has
a hpet. hpet_reset() will eventually result in mshv_send_msi called w/
vector 0, which we can safely drop.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-13-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
MSHV's "internal activity state" roughly maps to QEMU's env->mp_state
and cpu->halted states that describe state of APs in a guest.
We don't invoke set_mp_state as part of store_vcpu_state() b/c we would
put all BSP + APs in a RUNNABLE (0) state immediately, breaking SMP boot
Instead we store the mp state as part of the load_cleanup() routine
after a migration.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-11-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Write partition-wide synthetic MSRs. This ensures the hypercall page and
SynIC facilities are set up before vCPUs attempt to use it.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-10-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This part of Synic state is retrieved via a mem-aligned page. We declare
the required space (size reference: rust-vmm/mshv) as a buffer on the VM
state struct for inclusion in a migration.
Other than other SynIC features, STIMER doesn't depend on SCONTROL being
set.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-9-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This part SynIC state is retrieved from the hypervisor via aligned state
pages:
- Add new synic source file
- Centralize the synic_enabled() check
- r/w pages from the hyper via aligned pages
- only handle pages when synic is enabled
- add buffers for migration to VM state
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Reviewed-by: Doru Blânzeanu <dblanzeanu@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-8-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Migrate HyperV SynIC SINT MSRs. We can only read/write those if SCONTROL
is enabled in the guest, hence we have to split the SINT MSR out and
make reading/writing them dependent on that MSR.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Reviewed-by: Doru Blânzeanu <dblanzeanu@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-7-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This change implements loading and storing the hyperv lapic state as
part of the load/store routines for a vcpu.
The HyperV LAPIC is similar to the the split-irqchip in KVM. MSHV
currently keeps PIC/IOAPIC emulation in userspace, while LAPIC
interrupt injection is handled through hypercalls.
We introduced dedicated apic infra in hw/i386/mshv to handle the
migration and move lapic related functions from target/i386/mshv
there. References have been the WHPX's whpx-apic implemenation and
the mshv-ioctls crate's get_/set_lapic() impl for the mapping
between MSHV/QEMU lapic state.
We are mapping the lapic state that we receive from the hypervisor to
fields in APICCommonState. Common fields are used where feasible, with
an mshv-specific MshvAPICState object that carries mshv-specific
fields.
We have introduced a guard in pic_irq_request() that will early exit
for the mshv accelerator, because mshv cannot take part in the userland
path for legacy PIC interrupt injection.
The TSC_DEADLINE MSR is also migrated as part of LAPIC migration.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Reviewed-by: Doru Blânzeanu <dblanzeanu@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-6-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This is similar to HVF's implementation. We want to interrupt the blocking
vcpu run. The self-kick was effectively a no-op for mshv.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Reviewed-by: Doru Blânzeanu <dblanzeanu@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-5-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This is a partition-wide state for which we use a dedicated hw clock
facility, similar to KVM. We have to freeze the time for a partition
before we are allowed to set it. We register a state change handler for
the clock device and a post-load handler for migration state. In the
post-load handler we toggle a flag that will set the reference time
state on next state to "running" on the partition.
We can move the time freeze and reference-time ioctls/hvcalls to the
clock module.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Reviewed-by: Doru Blânzeanu <dblanzeanu@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-4-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This mechanism is used to handle more imperative partition-wide steps
that have to be taken as part of a migration routine. Currently it's
just a skeleton.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Reviewed-by: Doru Blânzeanu <dblanzeanu@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-3-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
MSHV exposes overlapping legacy FP/SSE state through two paths:
explicit Hyper-V FPU/XMM + registers and VP XSAVE state. There can
be subtle inconsistencies across migrations when XSAVE is written after
FPU state.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-12-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
For the time being we disable AMX TILE in partition processor features
and CPUID b/c AMX TILE XSAVE state (XTILE_DATA) is 8KB, which exceeds
the current fixed 4KB XSAVE buffer size.
For now we filter it until buffer sizing is computed dynamically from CPUID.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Reviewed-by: Doru Blânzeanu <dblanzeanu@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260710101534.664604-2-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
According to Table A-6 in Volume 3 of AMD64 Architecture Programmer's Manual,
opcodes F6 and F7 (opcode extensions group 3) with ModRM's reg field values
of 0 and 1 can be used to encode a TEST instruction.
Although Intel 64 and IA-32 Architectures Software Developer's Manual leaves
the cell 1 of opcode extensions group 3 blank in the opcode table
(Table A-6, Volume 2D), the instruction in a group 3 with reg field of ModRM
byte set to 1 actually behaves like TEST instruction on Intel CPUs.
Currently, QEMU decodes group 3 instruction as TEST only if reg field of ModRM
byte is 0. When the reg field is 1, QEMU raises a #UD exception.
This behavior does not match real Intel and AMD hardware.
This patch fixes this issue by duplicating the existing [0x00] and [0x08]
X86_OP_ENTRYrr(AND, ...) entries into slots [0x01] and [0x09] in the
opcodes_grp3 table.
Fixes: d7c41a60d0 ("target/i386: move C0-FF opcodes to new decoder (except for x87)")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3580
Signed-off-by: Andrey Polivoda <apolivodaa433@gmail.com>
Cc: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Link: https://lore.kernel.org/r/20260621032524.1138213-1-apolivodaa433@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
According to the pseudocode for the IRET instruction in both the Intel 64
and IA-32 Architectures Software Developer's Manual and the AMD64 Architecture
Programmer's Manual, a transition to virtual-8086 mode is allowed only if all
of the following conditions are met:
1. The new EFLAGS.VM bit is set to 1.
2. The Current Privilege Level (CPL) is 0.
3. The CPU is in protected mode (and not in long mode).
Currently, QEMU performs only the first check. This omission allows a
transition to virtual-8086 mode from long mode, and also enables the guest's
userspace to trigger this switch.
During a legitimate transition, the EFLAGS register is updated in a way that
allows modification of sensitive fields, such as IOPL and IF (which is expected,
as only privileged code should be able to initiate this transition).
However, due to the lack of appropriate checks, an unprivileged guest userspace
process can now force this transition and freely modify these fields.
This allows the userspace to:
1. Disable interrupts, preventing other processes from running on the CPU.
2. Gain direct hardware I/O access by elevating EFLAGS.IOPL to 3.
3. Crash the guest kernel by setting CS and SS to resemble segments with RPL = 0
and triggering an exception. Since the kernel is unaware that the process
entered virtual-8086 mode, it will misinterpret the exception as originating
from kernel space.
This patch fixes this bug by adding the missing CPL and long mode checks before
jumping to the `return_to_vm86` label.
Fixes: 90a9fdae1f ("more ring 0 operations")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3583
Signed-off-by: Andrey Polivoda <apolivodaa433@gmail.com>
Cc: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Link: https://lore.kernel.org/r/20260622082119.11903-1-apolivodaa433@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The decoding of the extrq instruction with an immediate operand (EXTRQ_i) is
incorrect. Per the AMD manual the instruction encoding looks as follows:
EXTRQ xmm1, imm8, imm8 66 0F 78 /0 ib ib
The /0 indicates that the "Reg" field of the ModR/M byte must be equal
to 0 and the XMM register operand is specified by the "R/M" field.
However, qemu incorrectly uses the "Reg" field to extract the register operand.
This patch instead extracts the XMM register operand from the "R/M"
field.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3611
Signed-off-by: Simon Scherer <scherer.simon89@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Link: https://lore.kernel.org/r/20260625155613.192643-1-scherer.simon89@gmail.com
[Check for the reg field to be 0. Make decoding of REPZ+66 consistent
between 0F 78 and 0F 79. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Supervisor state should be skipped b/c there is no slot in standard
format XSAVE buffer for it. CET State is being migrated via MSRs and
other supervisor state isn't currently migrated.
Fixes: 8612deb3f4
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Reviewed-by: Doru Blânzeanu <dblanzeanu@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260702124746.450228-1-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
helper_fcomi_ST0_FT0() and helper_fucomi_ST0_FT0() only cleared
CC_Z, CC_P, and CC_C before merging in the comparison result,
leaving CC_O, CC_S, and CC_A untouched from whatever they were
set to beforehand.
The Intel SDM documents FCOMI/FCOMIP/FUCOMI/FUCOMIP as setting OF,
SF, and AF to 0 unconditionally. The AMD manual doesn't mention them
at all. However, testing on multiple real Intel and AMD systems confirms
all three are unconditionally cleared regardless of the comparison
result or their prior value.
Since fcomi_ccval[] only ever contains CC_C, CC_Z, 0, or CC_Z|CC_P|CC_C,
and CC_O|CC_S|CC_Z|CC_A|CC_P|CC_C already covers every flag bit, CC_SRC
can be assigned from fcomi_ccval[ret + 1] directly instead of ORing it
into a masked cpu_cc_compute_all() result.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4133
Signed-off-by: Simon Scherer <scherer.simon89@gmail.com>
Link: https://lore.kernel.org/r/20260807062831.19618-1-scherer.simon89@gmail.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The x-migrate-fetch-addr-64bit compatibility properties for
sysbus-ehci-usb and pci-ehci-usb were reviewed before the QEMU 11.1
release and were therefore initially added to hw_compat_11_0.
However, the EHCI migration change was merged after the QEMU 11.1
release. As a result, these compatibility properties belong in
hw_compat_11_1 rather than hw_compat_11_0.
Move both properties to hw_compat_11_1 so that migration compatibility
is associated with the correct machine version.
Fixes: 38ed803aeb ("usb/hcd-ehci: Change descriptor addresses to 64-bit")
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260814032559.3381363-1-jamin_lin@aspeedtech.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
According to the ELF spec:
PT_LOAD
The array element specifies a loadable segment, described by
p_filesz and p_memsz. The bytes from the file are mapped to the
beginning of the memory segment. If the segment's memory
size (p_memsz) is larger than the file size (p_filesz), the
``extra'' bytes are defined to hold the value 0 and to follow the
segment's initialized area. The file size may not be larger than the
memory size. Loadable segment entries in the program header table
appear in ascending order, sorted on the p_vaddr member.
which implies while both p_filesz and p_memsz can be zero we should
never see a case where p_filesz is greater than the in memory size.
Indeed it has been reported such a hand crafted ELF can blow up, for
example during rom_reset():
address_space_set(rom->as, rom->addr + rom->datasize, 0,
rom->romsize - rom->datasize,
MEMTXATTRS_UNSPECIFIED);
which could trigger and underflow leaving QEMU slowly filling a very
large buffer.
Cc: qemu-stable@nongnu.org
Fixes: https://gitlab.com/qemu-project/qemu/-/work_items/4056
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260812081405.3811787-1-alex.bennee@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
By replacing the container_of(MonitorHMP) use in ui/ui-hmp-cmds.c
we can remove its incorrect inclusion of "monitor/monitor-internal.h"
header, using the public "monitor/monitor.h" instead.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-23-philmd@oss.qualcomm.com>
monitor_read() is a IOReadHandler handler, called by
qemu_chr_fe_set_handlers() with a Monitor* opaque argument.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-20-philmd@oss.qualcomm.com>
Mechanical change to sanitize using the following patterns:
MonitorQMP *qmp
MonitorHMP *hmp
Monitor *mon
Rename @mon (and @hmp_mon) as @hmp when the type is MonitorHMP.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-Id: <20260812211708.92824-19-philmd@oss.qualcomm.com>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Keep cpus.c focused on vCPUs handling, move code related to
VM state to runstate.c where similar code lives.
Fix few checkpatch.pl warnings:
WARNING: Block comments use a leading /* on a separate line
WARNING: Block comments use * on subsequent lines
#327: FILE: system/runstate.c:541:
+/* does a state transition even if the VM is already stopped,
+ current state is forgotten forever */
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-17-philmd@oss.qualcomm.com>
Keep cpus.c related to vCPU scheduling, move the QMP handlers
related to dumping physical memory to file to their own unit.
Fix a pair of checkpatch.pl errors doing so:
ERROR: braces {} are necessary for all arms of this statement
#185: FILE: system/physmem-qmp-cmds.c:51:
+ if (l > size)
[...]
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-16-philmd@oss.qualcomm.com>
We figured NMI relates to machines (for their machine-specific
handling), so move the 'inject-nmi' QMP handler with the rest
of machine ones, in hw/core/machine-qmp-cmds.c.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-15-philmd@oss.qualcomm.com>
No code in device_tree.c or physmem.c require declarations
from "monitor/monitor.h".
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-13-philmd@oss.qualcomm.com>
"monitor/monitor.h" don't use anything declared in the generated
"qapi/qapi-emit-events.h" header.
However the "monitor/monitor-internal.h" do:
107 struct MonitorClass {
...
116 /*
117 * If non-NULL, the monitor is able to send event
118 * notifications back to the client
119 */
120 void (*emit_event)(Monitor *mon, QAPIEvent event, QDict *qdict);
^^^^^^^^^
Move the header inclusion to "monitor/monitor-internal.h" to
avoid including / re-exposing unnecessary declarations in the
global "monitor/monitor.h" header.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-11-philmd@oss.qualcomm.com>
"monitor/monitor.h" declares monitor_set_cur() which use the
'Coroutine' type, itself declared in "qemu/coroutine-core.h".
Include the latter to avoid when refactoring unrelated headers:
In file included from ../../target/sh4/monitor.c:26:
qemu/include/monitor/monitor.h:32:26: error: unknown type name 'Coroutine'
32 | Monitor *monitor_set_cur(Coroutine *co, Monitor *mon);
| ^
Fixes: e69ee454b5 ("monitor: Make current monitor a per-coroutine property")
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-10-philmd@oss.qualcomm.com>
Files in monitor/ use the QEMU_LOCK_GUARD() macros, which
are declared in "qemu/lockable.h". Include the latter to
avoid when refactoring unrelated headers:
../monitor/fds.c:146:5: error: call to undeclared function 'QEMU_LOCK_GUARD'
146 | QEMU_LOCK_GUARD(&mon->mon_lock);
| ^
../monitor/monitor.c:176:5: error: call to undeclared function 'QEMU_LOCK_GUARD'
176 | QEMU_LOCK_GUARD(&mon->mon_lock);
| ^
../monitor/qmp.c:164:5: error: call to undeclared function 'WITH_QEMU_LOCK_GUARD'
164 | WITH_QEMU_LOCK_GUARD(&mon->mon_lock) {
| ^
Fixes: 0210c3b39b ("monitor: Use LOCK_GUARD macros")
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-9-philmd@oss.qualcomm.com>
Both monitor.c and qmp.c use types / methods declared in
"qemu/aio-wait.h". Include the latter to avoid the following
errors when refactoring unrelated headers:
../monitor/monitor.c:648:5: error: call to undeclared function 'AIO_WAIT_WHILE_UNLOCKED'
648 | AIO_WAIT_WHILE_UNLOCKED(NULL,
| ^
../monitor/qmp.c:792:9: error: call to undeclared function 'aio_wait_bh_oneshot'
792 | aio_wait_bh_oneshot(iothread_get_aio_context(mon_iothread),
| ^
Fixes: 9ce44e2ce2 ("qmp: Move dispatcher to a coroutine")
Fixes: a5df506e12 ("monitor: implement support for deleting QMP objects")
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-8-philmd@oss.qualcomm.com>
migration-hmp-cmds.c uses types / methods declared in
"block/block-global-state.h". Include the latter otherwise
we get when refactoring unrelated headers:
../migration/migration-hmp-cmds.c:911:5: error: use of undeclared identifier 'BdrvNextIterator'
911 | BdrvNextIterator it;
| ^
../migration/migration-hmp-cmds.c:918:15: error: call to undeclared function 'bdrv_first'
918 | for (bs = bdrv_first(&it); bs; bs = bdrv_next(&it)) {
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Message-Id: <20260812211708.92824-7-philmd@oss.qualcomm.com>
qmp-dispatch.c calls aio_wait_kick() and monitor_cur(). Include the
header declaring them in order to avoid the following build failure
when refactoring unrelated headers:
../qapi/qmp-dispatch.c:126:12: error: call to undeclared function 'monitor_cur'
126 | assert(monitor_cur() == NULL);
| ^
../qapi/qmp-dispatch.c:141:5: error: call to undeclared function 'aio_wait_kick'
141 | aio_wait_kick();
| ^
Fixes: 41725fa7ed ("qmp: Call monitor_set_cur() only in qmp_dispatch()")
Fixes: fc1a2ec7da ("monitor: Fix deadlock in monitor_cleanup")
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-5-philmd@oss.qualcomm.com>
test-util-sockets.c calls qemu_init_main_loop(), itself declared in
the "qemu/main-loop.h" header. Include the latter to avoid when
refactoring unrelated headers:
../tests/unit/test-util-sockets.c:553:5: error: call to undeclared function 'qemu_init_main_loop'
553 | qemu_init_main_loop(&error_abort);
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-4-philmd@oss.qualcomm.com>
The Monitor type is used in these 2 files, as a pointer.
Since the type is forward-declared in "qemu/typedefs.h",
which all source files include via "qemu/osdep.h", we do
not need to include it.
Do however include "exec/hwaddr.h" and "exec/mmu-access-type.h"
which declare the types used by hex_tlb_find_match prototype:
extern bool hex_tlb_find_match(CPUHexagonState *env, uint32_t VA,
MMUAccessType access_type, hwaddr *PA, int *prot,
^^^^^^^^^^^^^ ^^^^^^
uint64_t *size, int32_t *excp, int mmu_idx);
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812211708.92824-2-philmd@oss.qualcomm.com>
We only expect one device in the system to implement the
TYPE_NMI interface (typically the machine, but in a few cases
for e.g. m68k and ppc this is an interrupt controller or
similar device); so we don't need to keep walking the whole
QOM tree once we've found it. As no machine type creates more
than one object implementing TYPE_NMI, this is not a behaviour
change.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812121232.71958-8-philmd@oss.qualcomm.com>
Not a single handler update @errp. The single user is
nmi_inject() filling with "machine does not provide NMIs".
Remove the unused argument from the raise_nmi() callback,
simplifying the methods in hw/core/nmi.c.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812121232.71958-7-philmd@oss.qualcomm.com>
nmi_monitor_handler() is not related to the monitor,
rename it as raise_nmi().
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812121232.71958-6-philmd@oss.qualcomm.com>
nmi_monitor_handle() is not related to the monitor, rename
it as nmi_inject().
Return a boolean value indicating success / failure as
recommended by the Error API since commit e3fe3988d7
("error: Document Error API usage rules").
The 'cpu_index' argument is not used, remove it.
This officially drops the current CPU for HMP command.
Document nmi_inject() as suggested by Peter Maydell in
https://lore.kernel.org/qemu-devel/CAFEAcA-yALySmCJLbitCmYpiZKUXJNOavGJG9RYeo8fKqz7gcw@mail.gmail.com/.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-Id: <20260812121232.71958-5-philmd@oss.qualcomm.com>
Only s390x was using the 'cpu_index' argument, but since the
previous commit it isn't anymore (it use the first cpu).
Since this argument is now completely unused, remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812121232.71958-4-philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
We can trigger NMI from HMP or QMP.
QEMU maps the NMI to the s390x per-CPU 'RESTART' interrupt.
Linux guests usually setup this interrupt to trigger kdump
or crash. Such crashdump can be triggered in QEMU by HMP
"nmi" or QMP "inject-nmi" commands.
Using QMP, since we can not select a particular CPU, the first
CPU is used (CPU#0). See the documentation from commit 795dc6e4
("watchdog: Add new Virtual Watchdog action INJECT-NMI"):
@inject-nmi: a non-maskable interrupt is injected into the
first VCPU (all VCPUS on x86) (since 2.4)
While we can select a particular CPU on HMP, the guest behavior
is expected to be the same if using CPU #N or CPU #0. Since
always using CPU#0 simplifies API maintenance , update s390_nmi()
to inject NMI to the first CPU.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812121232.71958-3-philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Replace object_child_foreach() and recursion by a single
object_child_foreach_recursive() call.
Propagate the returned value so callers can check it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260812121232.71958-2-philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Current cpu_exec_realize() body only contains system-mode
related code. Move that method out of cpu-common.c to
cpu-system.c, removing the system / machine mentions in
this common file. Add an empty stub for user-mode.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260811183410.22428-9-philmd@oss.qualcomm.com>
cpu_common_realizefn() contains code only used by system mode
emulation. Extract it to a new cpu_exec_realize() helper. In
the next commit this helper will be moved to cpu-system.c where
it belongs.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260811183410.22428-8-philmd@oss.qualcomm.com>
Keep cpu_common_*() pattern for publicly exposed common methods
used by target code. Use cpu_exec_*() pattern for internal ones,
mostly to distinct between system / user mode.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260811183410.22428-7-philmd@oss.qualcomm.com>
Keep cpu_common_*() pattern for publicly exposed common methods
used by target code. Use cpu_exec_*() pattern for internal ones,
mostly to distinct between system / user mode.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260811183410.22428-6-philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Keep cpu_common_*() pattern for publicly exposed common methods
used by target code. Use cpu_exec_*() pattern for internal ones,
mostly to distinct between system / user mode.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260811183410.22428-5-philmd@oss.qualcomm.com>
Some declarations are only used within hw/core/, in particular
by the 3 cpu-{common,user,system}.c. Restrict the declarations
scope by moving them to a new "cpu-internal.h" local header.
Rename cpu_exec_initfn() -> cpu_exec_init() because we usually
have the 'fn' suffix for handler, not API entry point methods.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260811183410.22428-4-philmd@oss.qualcomm.com>
cpu_common_realize() calls accel_cpu_common_realize(),
itself declared in "qemu/accel.h". Include the latter,
otherwise we get when refactoring unrelated headers:
hw/core/cpu-common.c:233:10: error: implicit declaration of function ‘accel_cpu_common_realize’
233 | if (!accel_cpu_common_realize(cpu, errp)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260811183410.22428-3-philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The NVMe emulation code unconditionally calls spdm_socket_*() APIs. Add
a Kconfig dependency to avoid build errors when NVME_PCI is enabled
without SPDM_SOCKET.
Fixes: 4f947b10d5 ("hw/nvme: Add SPDM over DOE support")
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Klaus Jensen <k.jensen@samsung.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260810214846.76805-1-stefanha@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
pflash_post_load() did not restore the ROMD mode of the memory region.
Although cmd and wcycle are migrated, the destination retains the
default ROMD = true from realize. When the source was in a non-array
mode (e.g. ID read, cmd = 0x90), reads on the destination bypass
pflash_read() via the ROM fast path and return raw storage bytes
instead of the command-specific response.
Derive ROMD from the migrated cmd/wcycle in pflash_post_load.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4042
Cc: qemu-stable@nongnu.org
Signed-off-by: Bin Guo <guobin@linux.alibaba.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMD: Including review comments from
https://lore.kernel.org/qemu-devel/CAFEAcA-P6RH7nJK0KQ1H8576ULFA7nocB0EkhhZf6Rw3g0WCag@mail.gmail.com/
Confirming that this is correct is a bit tricky. It relies on:
* when we set romd mode to true we also set wcycle = 0, cmd = 0
(which we do, in reset and in the mode_read_array code)
* when we set romd mode to false at the top of pflash_write(),
all paths out of that function either go through the
mode_read_array path, or else update pfl->cmd to something
non-zero
* nowhere outside pflash_write() udpates cmd or wcycle except
for the "clear them to 0 and set romd mode" places
This is almost but not quite true. In pflash_read(), the default
case for the pfl->cmd switch sets wcycle = 0 cmd = 0 but doesn't
change the romd state. Luckily the "this should never happen"
comment is true -- there's no way to get a pfl->cmd that falls
into the default (except for being deliberately fed a bogus value
via inbound migration).
]
Message-ID: <20260803041808.58174-1-guobin@linux.alibaba.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
In rtl8139_transfer_frame(), if we are transmitting a frame over
loopback then we do this by calling qemu_receive_packet(). If we
have an iovec rather than a simple buffer (which happens only when
we're sending a packet where we are inserting a vlan tag), we have to
convert this into a simple buffer first using iov_to_buf(). However,
when we do this we forget to also update the 'size' local variable to
the size of the new simple buffer, so we will truncate the packet by
4 bytes (the size of the vlan tag).
Correct the logic so we don't truncate vlan-tagged packets when
sending them over loopback.
Cc: qemu-stable@nongnu.org
Reported-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Bin Meng <bin.meng@processmission.com>
Message-ID: <20260731093618.2961031-3-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The rtl8139 receive code handles VLAN tags in incoming packets by
copying the VLAN tag to a special field in the receive descriptor,
and copying only the actual payload data to the receive buffer. This
code tries to ensure that it pads out the payload to at least
MIN_BUF_SIZE bytes.
In commit 63b901bfd3 we removed the main "pad short frames" code
from this device because we switched to requiring net backends to do
the padding. However we didn't notice that this broke the VLAN tag
handling, which relied on the old code making the buffer at least
MIN_BUF_SIZE + VLAN_HLEN bytes so that it could copy MIN_BUF_SIZE
bytes into the receive buffer even after removing the VLAN tag. The
result is that the guest can make us read 4 bytes off the end of a
buffer by feeding itself a suitable short packet in loopback mode.
The old behaviour is actually not correct, because the IEEE802.1Q
standard says that the minimum ethernet frame size remains 64 bytes
including the 4 checksum bytes, and so when a tag is present the
payload data only needs to be 56 bytes. (A bridge implementation can
choose to pad tagged frames out to 68 bytes, but it doesn't have to,
and so all devices have to correctly handle incoming tagged frames
that are 64 bytes long.)
The RTL8139 datasheet isn't very communicative on this topic, but
there's nothing that suggests it adds extra padding on receive that
didn't exist in the incoming packet.
Drop the last remnants of the padding handling from this device;
this avoids overcopying into the guest when we receive a short
VLAN tagged packet.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3518
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Bin Meng <bin.meng@processmission.com>
Message-ID: <20260731093618.2961031-2-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Commit 7d2778dea3 ("hw/i386/pc:
Remove deprecated pc-q35/pc-i440fx/xenfv 3.1 machines") removed
the Xen machine type that was providing the "xenfv" alias. As a
consequence, since the tools are apparently relying on such alias,
we're getting this, as soon as one tries to start a Xen (HVM) VM:
qemu-system-i386: unsupported machine type: "xenfv"
Use -machine help to list supported machines
Reinstate the alias and let it point to the only Xen machine we
still have.
Cc: qemu-stable@nongnu.org
Fixes: 7d2778dea3 Remove deprecated pc-q35/pc-i440fx/xenfv 3.1 machines
Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260730162238.3308286-1-dfaggioli@suse.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Commit 9940b2cfbc ("qdev: New qdev_new(), qdev_realize(), etc.") says
"device state 'no QOM parent, but plugged into bus' is dangerous". In
such a case, unrealizing the bus will hang in bus_unparent():
while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) {
DeviceState *dev = kid->child;
object_unparent(OBJECT(dev));
}
object_unparent() does nothing when its argument has no QOM parent,
and the loop spins forever.
However, that commit did not completely eliminate such a situation.
When the device is not parented, device_set_realized() lets
/machine/unattached parent it, but it happens after setting parent bus.
Therefore, any failure between the two operations can leave the device
in a dangerous state.
qdev_realize() at least asserts that the device is not already realized
and prevents one realization failure pattern, but it is not
comprehensive. Besides, it will trip with a command line like the
following:
qemu-system-x86_64 -M none -nodefaults -nographic \
-device ipmi-bmc-sim,realized=on
Eliminate the dangerous state by ensuring that the device is parented
before calling qdev_set_parent_bus(). Also, stop asserting that the
device is not already realized in qdev_realize(); it is broken and
no longer serves any purpose.
Fixes: 9940b2cfbc ("qdev: New qdev_new(), qdev_realize(), etc.")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-14-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-13-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-12-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-11-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-10-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-9-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-8-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-7-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-6-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-5-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-4-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
DeviceState fields should be accessed through qdev helpers rather than
directly. Use qdev_is_realized() instead of reading
DeviceState::realized directly.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-3-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
qdev_is_realized() only reads DeviceState. Make its parameter const so a
later caller with a const DeviceState * can use it.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721-qdev-v3-2-d2e226fa002e@rsg.ci.i.u-tokyo.ac.jp>
The getter/setter use visit_type_size().
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260616-qom-qapi-v2-30-cc9396b9c18c@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
DEFINE_PROP_DMAADDR() is only used once. Since it doesn't
add much value, simply remove it, along with the header
defining it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20230203145536.17585-14-philmd@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
* Fix a guest-triggerable abort() in the usb uas code
* Fix a guest-triggerable abort() in the vmxnet3 code
* Fix a undefined behavior problem in the amd_iommu code
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmp+6F8ACgkQLtnXdP5w
LbUUCQ//dxC+zK3zIgi7/X0kEGrfosCrCQBbpEGLQi+o9NRoG5H8hWt7ucjiS2Z0
qGqqNvoEVMKxT1cCLmELOuVtxm2hG0GQP+w7MUGZaFnmm/Jl0w8AGSd8DEWSiujt
0hLgLyHBzDMnZOJMSCosyPq+QIg8yukeGBsuRksJZtgNy/VWTUG59qcT781TC8bg
il8yyPWl+U4YjwsAWwLdPJtS1Dbk9gNTpJbDwJ19S3ZKZ/6jca06ycTwHMEb+3Zf
Ht/+18XkFxn2O661ijF5RO0toFYrkUW0SHWssya3KFguwXCWTe2aMkXVkwqJRXcQ
EJIhQxIh+YtbZ4OI+SG9caYG1MXi3If6bX7NFTdD18PhvGkDTT49GkwCkM2EphYg
yRZ7l+zpe+VBYIY1e2nzVDe1pmVek4cKv4Zwd0eO8ONHQKqd7Sz2F0G/1ixgMbCS
lM9KeZ5+aoIexPorxwjC+SHXb0jQnlWuuKZEmSrbyjBP3EdgYNXBn1g/tJ8sEAxQ
KihKyKqlggm0Jg3TY8e6+0YTjQu2yVrPqkNeirxhaTIwYMsihesDs+xwZiJ4TVOf
2udZDD7clJ+JK7UFPUIYOJ1YWcg1IH4bEYOEWYD4DuVnRmXEQdyDebtSkKUVwO7O
w3hS7+KHE7INcmPgTwtE4uwqXZfAeraXptAJyhxPDGuHNZfmJyc=
=ozrV
-----END PGP SIGNATURE-----
Merge tag 'pull-request-2026-08-14' of https://gitlab.com/thuth/qemu into staging
* Some minor updates to the functional testing framework
* Fix a guest-triggerable abort() in the usb uas code
* Fix a guest-triggerable abort() in the vmxnet3 code
* Fix a undefined behavior problem in the amd_iommu code
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmp+6F8ACgkQLtnXdP5w
# LbUUCQ//dxC+zK3zIgi7/X0kEGrfosCrCQBbpEGLQi+o9NRoG5H8hWt7ucjiS2Z0
# qGqqNvoEVMKxT1cCLmELOuVtxm2hG0GQP+w7MUGZaFnmm/Jl0w8AGSd8DEWSiujt
# 0hLgLyHBzDMnZOJMSCosyPq+QIg8yukeGBsuRksJZtgNy/VWTUG59qcT781TC8bg
# il8yyPWl+U4YjwsAWwLdPJtS1Dbk9gNTpJbDwJ19S3ZKZ/6jca06ycTwHMEb+3Zf
# Ht/+18XkFxn2O661ijF5RO0toFYrkUW0SHWssya3KFguwXCWTe2aMkXVkwqJRXcQ
# EJIhQxIh+YtbZ4OI+SG9caYG1MXi3If6bX7NFTdD18PhvGkDTT49GkwCkM2EphYg
# yRZ7l+zpe+VBYIY1e2nzVDe1pmVek4cKv4Zwd0eO8ONHQKqd7Sz2F0G/1ixgMbCS
# lM9KeZ5+aoIexPorxwjC+SHXb0jQnlWuuKZEmSrbyjBP3EdgYNXBn1g/tJ8sEAxQ
# KihKyKqlggm0Jg3TY8e6+0YTjQu2yVrPqkNeirxhaTIwYMsihesDs+xwZiJ4TVOf
# 2udZDD7clJ+JK7UFPUIYOJ1YWcg1IH4bEYOEWYD4DuVnRmXEQdyDebtSkKUVwO7O
# w3hS7+KHE7INcmPgTwtE4uwqXZfAeraXptAJyhxPDGuHNZfmJyc=
# =ozrV
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 14 Aug 2026 03:05:19 AM PDT
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [unknown]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [unknown]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# gpg: aka "Thomas Huth <huth@tuxfamily.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: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5
* tag 'pull-request-2026-08-14' of https://gitlab.com/thuth/qemu:
hw/i386/amd_iommu: Avoid undefined behavior in amdvi_setevent_bits()
hw/net/vmxnet3: Do not abort if guest provides bad interrupt numbers
hw/usb/dev-uas: Don't abort if guest provided an undersized buffer for status
tests/testcase.py: passthrough monitor_address
tests/functional/qemu_test: drop *args argument from .get_vm()
tests/functional: add skipWithoutSudo() decorator
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
- fix a main-loop deadlock when an ATAPI PIO read spanning several
sectors is in flight while a drain starts: the nested sector fetch
was issued synchronously from inside the completion of the first
read and queued behind the drain, which then never finished
- read the whole ATAPI elementary transfer in one asynchronous
request instead, removing cd_read_sector_sync()
- extend the IDE/AHCI qtest coverage of ATAPI CD reads: parametrized
read helper, multi-sector DMA, raw 2352-byte READ CD on both
delivery paths, and a regression test for the deadlock above
Changes since v2:
- resend: the v2 tag was never pushed, so the tree advertised in that
pull request could not be fetched
- rebased onto current master, no code changes
Changes since v1:
- MAINTAINERS patch dropped
- spare blank line no longer added and removed within the series
NOTE: 'hw/ide: Don't divide by zero if guest specifies 0 sectors requires'
is not ready for me, skipped from this submission.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Richard Henderson <richard.henderson@linaro.org>
CC: Stefan Hajnoczi <stefanha@redhat.com>
CC: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEC66qh9MCCtwRUOUfXgdxtstmbKsFAmp+FQIACgkQXgdxtstm
bKuM9A/9HcPhTCHlS+kmZO7XofHtTcLDfU4srvMFtGwf0v9uZ5v8hD38vs1RShEv
NXwY0ENjXxkuNy+lJEwLqBIJga6l4UrmO0aSoGdWN2vbVAKA0KAkdozYQCihstxE
qlJhXoqwaPTfbT1EMCbYdaNohDatlyZQA8AsXszuU7SX4sYzPBqO3F3nWSzqqYtM
uP/nlbsEflvjCIO0P/orcwnNchEGqaIGyeeIfiR4JgqYLkz3qQ/m9ay11M8TBl4i
97Oh8Xn/0Bs+qWNoU5JugzF0YgMl+M4aDvq15hRvcn8yYtWp2xIpIAyCE69VCoLM
U6CvBh5DzaJ+zkiPvUrVms6qfSWfjJ3C9PDKf8jEVy6iEmmHNyVpGg/VM09WApnX
jxxZuT/O0WsHGCITxtpaxoNHXYBcxj6L3gbs0jyTuWBenCLSxT9jyeDgbcG8sK6x
scIKAkVb9W+0pSsJcMiHVMN3gS1Jak1wf9nU2v2Ij0E6coD0cN84miD1iGybnVDa
uT4B5bZ6VxR42B64qwSiOcp/2wkxXE5RTxpMK+/M4G7S70uUaXr3rMkONJ8JVfbq
3mAxxwwLUM0UmYmKtymzyM1yD9c2G0qMvTQ4OWM1wssRHWY1Pdb9hM/Nhu7+NiXt
JUQGPp2/RC7BP6X7/LmEyYWaLo1frFAcRKaVgDXzCyoO4vTh+Xc=
=emKZ
-----END PGP SIGNATURE-----
Merge tag 'pull-ide-2026-08-13' of https://gitlab.com/dlunev/qemu into staging
IDE patches
- fix a main-loop deadlock when an ATAPI PIO read spanning several
sectors is in flight while a drain starts: the nested sector fetch
was issued synchronously from inside the completion of the first
read and queued behind the drain, which then never finished
- read the whole ATAPI elementary transfer in one asynchronous
request instead, removing cd_read_sector_sync()
- extend the IDE/AHCI qtest coverage of ATAPI CD reads: parametrized
read helper, multi-sector DMA, raw 2352-byte READ CD on both
delivery paths, and a regression test for the deadlock above
Changes since v2:
- resend: the v2 tag was never pushed, so the tree advertised in that
pull request could not be fetched
- rebased onto current master, no code changes
Changes since v1:
- MAINTAINERS patch dropped
- spare blank line no longer added and removed within the series
NOTE: 'hw/ide: Don't divide by zero if guest specifies 0 sectors requires'
is not ready for me, skipped from this submission.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Richard Henderson <richard.henderson@linaro.org>
CC: Stefan Hajnoczi <stefanha@redhat.com>
CC: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEC66qh9MCCtwRUOUfXgdxtstmbKsFAmp+FQIACgkQXgdxtstm
# bKuM9A/9HcPhTCHlS+kmZO7XofHtTcLDfU4srvMFtGwf0v9uZ5v8hD38vs1RShEv
# NXwY0ENjXxkuNy+lJEwLqBIJga6l4UrmO0aSoGdWN2vbVAKA0KAkdozYQCihstxE
# qlJhXoqwaPTfbT1EMCbYdaNohDatlyZQA8AsXszuU7SX4sYzPBqO3F3nWSzqqYtM
# uP/nlbsEflvjCIO0P/orcwnNchEGqaIGyeeIfiR4JgqYLkz3qQ/m9ay11M8TBl4i
# 97Oh8Xn/0Bs+qWNoU5JugzF0YgMl+M4aDvq15hRvcn8yYtWp2xIpIAyCE69VCoLM
# U6CvBh5DzaJ+zkiPvUrVms6qfSWfjJ3C9PDKf8jEVy6iEmmHNyVpGg/VM09WApnX
# jxxZuT/O0WsHGCITxtpaxoNHXYBcxj6L3gbs0jyTuWBenCLSxT9jyeDgbcG8sK6x
# scIKAkVb9W+0pSsJcMiHVMN3gS1Jak1wf9nU2v2Ij0E6coD0cN84miD1iGybnVDa
# uT4B5bZ6VxR42B64qwSiOcp/2wkxXE5RTxpMK+/M4G7S70uUaXr3rMkONJ8JVfbq
# 3mAxxwwLUM0UmYmKtymzyM1yD9c2G0qMvTQ4OWM1wssRHWY1Pdb9hM/Nhu7+NiXt
# JUQGPp2/RC7BP6X7/LmEyYWaLo1frFAcRKaVgDXzCyoO4vTh+Xc=
# =emKZ
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 13 Aug 2026 12:03:30 PM PDT
# gpg: using RSA key 0BAEAA87D3020ADC1150E51F5E0771B6CB666CAB
# gpg: Good signature from "Denis V. Lunev <den@openvz.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: 0BAE AA87 D302 0ADC 1150 E51F 5E07 71B6 CB66 6CAB
* tag 'pull-ide-2026-08-13' of https://gitlab.com/dlunev/qemu:
tests/qtest/ahci: regression test for ATAPI read vs. drain
hw/ide/atapi: read the whole elementary transfer asynchronously
tests/qtest/ahci: cover raw (2352-byte) ATAPI CD reads
tests/qtest/libqos/ahci: support raw (2352-byte) READ CD
tests/qtest/ide-test: cover raw (2352-byte) ATAPI CD reads
tests/qtest/ide-test: add a multi-sector ATAPI DMA read test
tests/qtest/ide-test: parametrize the ATAPI CD-ROM read test
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This more accurately reflects that these properties are held within the class and
not the object. Update the documentation to describe the few cases where static
properties should be used.
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20260717135254.508701-7-mark.caveayland@nutanix.com>
This is so that the object_class_* property functions appear in the generated
QOM documentation at devel/qom-api.html.
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20260717135254.508701-6-mark.caveayland@nutanix.com>
This was missed when updating the parameter name in commit 36854207f0 ("object:
rename link "child" to "target"").
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Fixes: 36854207f0 ("object: rename link "child" to "target"")
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20260717135254.508701-5-mark.caveayland@nutanix.com>
This macro defines both the QOM get and set functions for the given scaler
type. Replace the combined use of OBJECT_PROPERTY_SCALAR_GETTER() and
OBJECT_PROPERTY_SCALAR_SETTER() with the new macro.
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-Id: <20260717135254.508701-4-mark.caveayland@nutanix.com>
This macro can be used to generate the boilerplate property_set_type_ptr()
QOM set function for the specified scalar type. Replace the existing scaler set
functions with the new macro.
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20260717135254.508701-3-mark.caveayland@nutanix.com>
This macro can be used to generate the boilerplate property_get_type_ptr()
QOM get function for the specified scalar type. Replace the existing scaler get
functions with the new macro.
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20260717135254.508701-2-mark.caveayland@nutanix.com>
The code in amdvi_encode_event() calls amdvi_setevent_bits() with
start = 64:
amdvi_setevent_bits(evt, addr, 64, 64);
and amdvi_setevent_bits() then calculates:
uint64_t mask = MAKE_64BIT_MASK(start, length);
but this MAKE_64BIT_MASK() macro shifts a value left by "start" bit
positions. Shifting left by more than 63 is undefined behavior and
could have unexpected results with different compilers / architectures.
Fix it by using "bitpos" instead, which was likely the original
intended behavior anyway. (bitpos is calculated as bitpos = start % 64).
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3633
Fixes: 1d5b128cbe ("hw/iommu: Fix problems reported by Coverity scan")
Reviewed-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260731140229.259272-1-thuth@redhat.com>
vmxnet3_validate_interrupts() currently aborts via hw_error() if
the guest provided bad interrupt numbers. This should not happen,
QEMU should rather refuse to activate the device in this case instead.
Thus propagate the error to the callers to handle it more gracefully
there.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/539
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260731113352.189066-1-thuth@redhat.com>
QEMU currently aborts if the guest provides an undersized buffer
for the status packet (8 bytes):
hw/usb/core.c:623: usb_packet_copy:
Assertion `p->actual_length + bytes <= iov->size' failed.
If we hit this situation, log a guest error and continue by simply
only providing the bytes that the guest asked for.
(Note: This is e.g. similar to the UAS_PIPE_ID_COMMAND case that
also clamps the length with: length = MIN(sizeof(iu), p->iov.size))
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3900
Reported-by: Feifan Qian <bea1e@proton.me>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260730163901.1154791-1-thuth@redhat.com>
We'll need it soon to implement test for cpr-exec mode of
tap-fd-migration.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260729093146.1893719-5-vsementsov@yandex-team.ru>
Signed-off-by: Thomas Huth <thuth@redhat.com>
It's redundant. Only one caller use it, and it may be simply
substituted by .add_args().
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260729093146.1893719-3-vsementsov@yandex-team.ru>
Signed-off-by: Thomas Huth <thuth@redhat.com>
To be used in the next commit: that would be a test for TAP
networking, and it will need to setup TAP device.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
Reviewed-by: Maksim Davydov <davydov-max@yandex-team.ru>
Reviewed-by: Ben Chaney <bchaney@akamai.com>
Message-ID: <20260729091334.1863155-15-vsementsov@yandex-team.ru>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Add /ahci/cdrom/drain/{pio,dma}: issue a multi-sector ATAPI read whose
byte-count limit spans two sectors so the device must rebuffer in the
middle of the DRQ burst, hold the backend read in flight with a
blkdebug delay, and fire x-blockdev-set-iothread -- which runs
bdrv_drain_all_begin() exactly like a guest reset does through
virtio_blk_stop_ioeventfd().
On the unfixed PIO path the nested sector fetch is queued behind the
drain and the main loop wedges, so the test hangs. The DMA variant
never rebuffers and serves as a sanity twin.
Signed-off-by: Denis V. Lunev <den@openvz.org>
An ATAPI PIO read whose byte-count limit spans more than one CD sector
must fetch the later sectors of a DRQ burst from inside the completion
of the first, asynchronous read. cd_read_sector_sync() did this with a
synchronous blk_pread(), which runs blk_wait_while_drained() before
issuing the request.
If a drain is in progress when that completion runs -- as happens when
a guest reset reaches virtio_blk_stop_ioeventfd() ->
bdrv_drain_all_begin() while an ATAPI read is in flight on the same
QEMU -- the nested read is queued until the drained section ends while
the outer completion still holds blk->in_flight. bdrv_drain_all_begin()
then waits forever for that in_flight count to drop: the main loop is
wedged in the drain with the BQL held, and every other QMP/monitor
operation blocks behind it.
Read the whole elementary transfer in a single asynchronous request up
front instead, so no read is ever issued in the middle of a burst.
cd_read_sector() now reads all the sectors a burst spans (the raw
2352-byte case is unpacked in place on completion) and
cd_read_sector_sync() is removed. The DMA path already batched its
reads and is unchanged.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Add /ahci/cdrom/{pio,dma}/raw: read several sectors with READ CD in
raw mode (atapi_raw), so the ATAPI 2352-byte unpack path is exercised
through the AHCI delivery, which IDE coverage does not reach. Each
sector's 2048-byte payload is verified at its in-sector offset.
The PIO case uses a byte-count limit of one raw sector per DRQ burst:
libqos asserts a one-sector PIO transfer, and the multi-sector unpack
loop is already covered by the IDE raw test.
Signed-off-by: Denis V. Lunev <den@openvz.org>
ahci_exec() always builds ATAPI commands with a 2048-byte logical
sector size, so it cannot drive a READ CD that returns full 2352-byte
raw sectors. Add an atapi_raw option that sets the READ CD
field-selector to 0xf8 and the command's sector size to 2352 before
the transfer is sized, so the derived block count stays correct while
the buffer and byte counts cover the raw sectors.
Signed-off-by: Denis V. Lunev <den@openvz.org>
READ CD with the field-selector set to 0xf8 returns full 2352-byte
raw sectors (sync + header + 2048 data + EDC/ECC), driving the ATAPI
raw read path that READ10 never touches. Add a send_scsi_cdb_read_cd()
helper and a CDROM_RAW flag to cdrom_read_impl(), then exercise both
PIO and DMA. The PIO case uses a byte-count limit spanning several
raw sectors so the device must rebuffer mid-burst, and each sector's
2048-byte payload is verified at its in-sector offset.
Signed-off-by: Denis V. Lunev <den@openvz.org>
test_cdrom_pio_large() already exercises a multi-sector PIO read.
Add the DMA counterpart through the same cdrom_read_impl() helper so
the multi-block ATAPI DMA read path gets equivalent coverage.
Signed-off-by: Denis V. Lunev <den@openvz.org>
cdrom_pio_impl() and test_cdrom_dma() duplicate the same image setup
and data-integrity check around two different transfer mechanisms.
Fold them into a single cdrom_read_impl(nblocks, flags) helper, with a
CDROM_PIO/CDROM_DMA flag selecting the transfer, so further read
coverage can be added once for both paths.
No functional change: /ide/cdrom/pio, pio_large and dma run exactly
as before.
Signed-off-by: Denis V. Lunev <den@openvz.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQNhkKjomWfgLCz0aQfewwSUazn0QUCan07bAAKCRAfewwSUazn
0ZduAP9gFsFWHI9HgdeS+y48rLpqDMTK2y8P+WTGTj61nG5UngEA0HlDV+wQGkcA
WVqq1qafvTFDi/DSYErFmLlvFhUQCA4=
=Ai1s
-----END PGP SIGNATURE-----
Merge tag 'pull-loongarch-20260813' of https://github.com/bibo-mao/qemu into staging
loongarch queue
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQQNhkKjomWfgLCz0aQfewwSUazn0QUCan07bAAKCRAfewwSUazn
# 0ZduAP9gFsFWHI9HgdeS+y48rLpqDMTK2y8P+WTGTj61nG5UngEA0HlDV+wQGkcA
# WVqq1qafvTFDi/DSYErFmLlvFhUQCA4=
# =Ai1s
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 12 Aug 2026 08:35:08 PM PDT
# gpg: using EDDSA key 0D8642A3A2659F80B0B3D1A41F7B0C1251ACE7D1
# gpg: Good signature from "bibo mao <maobibo@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: 7044 3A00 19C0 E97A 31C7 13C4 8E86 8FB7 A176 9D4C
# Subkey fingerprint: 0D86 42A3 A265 9F80 B0B3 D1A4 1F7B 0C12 51AC E7D1
* tag 'pull-loongarch-20260813' of https://github.com/bibo-mao/qemu:
target/loongarch: Set timer tick value even if disabled
tests/acpi: Update LoongArch virt MADT
hw/loongarch/virt: Set MADT revision to 6
tests/acpi: Allow LoongArch virt MADT changes
hw/intc/loongarch_pch_pic: Validate htmsi_vector before indexing parent_irq
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
v2: fixes macos build error
- Dongli's patch to add cpr-transfer support for HMP
- Fabiano's doc update for migration on security issues
- Gavin's fix for MMIO access support for memory APIs, reverting ram_device ops
- Sam's migration test build fix for !ASN1
- Peter's a few migration hardening fixes
-----BEGIN PGP SIGNATURE-----
iIgEABYKADAWIQS5GE3CDMRX2s990ak7X8zN86vXBgUCan3KARIccGV0ZXJ4QHJl
ZGhhdC5jb20ACgkQO1/MzfOr1wa76QD/eBLnPtDvmpNHNH3+bm/3XC3zwyy7v69U
bGK3ocwI3sQA/j9o5FCc7xDCA0QaW6RMeerlLXvXR0uwH46UESKKDloF
=/Jbs
-----END PGP SIGNATURE-----
Merge tag 'next-pull-request' of https://gitlab.com/peterx/qemu into staging
migration/mem pull for 11.2
v2: fixes macos build error
- Dongli's patch to add cpr-transfer support for HMP
- Fabiano's doc update for migration on security issues
- Gavin's fix for MMIO access support for memory APIs, reverting ram_device ops
- Sam's migration test build fix for !ASN1
- Peter's a few migration hardening fixes
# -----BEGIN PGP SIGNATURE-----
#
# iIgEABYKADAWIQS5GE3CDMRX2s990ak7X8zN86vXBgUCan3KARIccGV0ZXJ4QHJl
# ZGhhdC5jb20ACgkQO1/MzfOr1wa76QD/eBLnPtDvmpNHNH3+bm/3XC3zwyy7v69U
# bGK3ocwI3sQA/j9o5FCc7xDCA0QaW6RMeerlLXvXR0uwH46UESKKDloF
# =/Jbs
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 13 Aug 2026 06:43:29 AM PDT
# 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 'next-pull-request' of https://gitlab.com/peterx/qemu:
migration: Fix rare hang of migration_channel_read_peek()
migration/ram: Check for RAMBlock size mismatch when parsing
migration/multifd: Replace assert() with error_setg() in recv paths
migration/multifd: Validate next_packet_size in zlib/zstd recv
tests/qtest/migration: Only build tls_no_hostname test with TASN1
system/memory: Make ram device region directly accessible
system/memory: Use qemu_ram_move() for directly accessible regions
system/memory: Use memmove() for directly accessible regions
migration/cpr: Add HMP support for cpr-transfer
docs: Add security considerations for migration
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
In an unlikely case, when a migration stream is attached to the destination
QEMU and only send <4 bytes to the channel as magic, it's possible that
migration_channel_read_peek() may spin forever.
Fix it by adding a manual sleep for partial read.
Since the path isn't attached to a coroutine, it means when partial read
happens, there's yet not much we can do but hang the main thread, it will
happen even for len==0 case. It means monitors can hang due to this,
either partial read or no data arrived (but connection established).
Leave this for later, the hope is this is extremely rare in production.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3889
Reported-by: Feifan Qian <bea1e@proton.me>
Cc: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/r/20260812124327.2572363-1-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
Add an underflow check for the subtract of total RAMBlock size to make sure
it won't underflow. It should not happen in production systems but only if
the migration stream was hijacked, which is not a real concern since
migration channel is trusted. Still protect against it.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4013
Reported-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20260728210417.1925078-6-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
If constant timer is enabled, its tick value is remained value from
the next expired time. However if timer is not enabled, its value
should be CONSTANT_TIMER_TICK_MASK or zero.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Xianglai Li <lixianglai@loongson.cn>
Regenerate the APIC and APIC.topology test data after correcting the
LoongArch virt MADT revision.
The generated tables change only Header.Revision from 1 to 6 and the
corresponding checksum. Their lengths and interrupt controller
subtables remain unchanged.
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
The LoongArch virt machine emits Core PIC, EIO PIC, MSI PIC and BIO PIC
subtables, but advertises MADT revision 1. Revision 1 predates these
LoongArch interrupt controller structures.
ACPI 6.5 introduced the LoongArch interrupt controller structures and
defined MADT revision 6. ACPI 6.6 raises the MADT revision to 7 for the
additional RISC-V interrupt controller structures, while leaving the
LoongArch structures unchanged.
Since the virt machine emits only the LoongArch structures defined by
ACPI 6.5, set the MADT header revision to 6, the minimum revision that
describes the table contents.
Fixes: 735143f10d ("hw/loongarch: Add acpi ged support")
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
The LoongArch virt MADT revision will be corrected to match the
interrupt controller structures it contains.
Allow the APIC and APIC.topology test data to change so that the source
change can be reviewed separately from the regenerated binary tables.
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
pch_pic_update_irq() used the guest-writable htmsi_vector[irq] value as an
index into parent_irq[] without checking bounds. A value >= irq_num (64 in
the array, but only 32 are used by the virt machine) causes an out-of-bounds
read and a guest-triggerable QEMU crash.
Validate the vector before calling qemu_set_irq() in both the raise and lower
paths and log a guest error if it is out of range.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4114
Cc: qemu-stable@nongnu.org
Signed-off-by: Bin Guo <guobin@linux.alibaba.com>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
- compat machines for 11.2
- allow guest backing with 2G hugepages
- fixes to TCG (and a couple tests on them)
- hardening fixes in boot/sclp code
- regenerate s390-ccw.img
-----BEGIN PGP SIGNATURE-----
iIsEABYKADMWIQQB3Dhbwk4ZE3uUN6KmTx4R4Fx3tAUCanygMxUcZmFybWFuQGxp
bnV4LmlibS5jb20ACgkQpk8eEeBcd7RMqwEAzBhcnvUDHowDalVgBJ4QTWcbUx2D
dZgoMvFpFYB2aEsA/32H81TzvrwX4xAkJlqdGIrQbPGmtdvAOKfjketAjGMC
=lFhB
-----END PGP SIGNATURE-----
Merge tag 's390x-20260812' of https://gitlab.com/efarman/qemu into staging
First batch of s390x updates for 11.2:
- compat machines for 11.2
- allow guest backing with 2G hugepages
- fixes to TCG (and a couple tests on them)
- hardening fixes in boot/sclp code
- regenerate s390-ccw.img
# -----BEGIN PGP SIGNATURE-----
#
# iIsEABYKADMWIQQB3Dhbwk4ZE3uUN6KmTx4R4Fx3tAUCanygMxUcZmFybWFuQGxp
# bnV4LmlibS5jb20ACgkQpk8eEeBcd7RMqwEAzBhcnvUDHowDalVgBJ4QTWcbUx2D
# dZgoMvFpFYB2aEsA/32H81TzvrwX4xAkJlqdGIrQbPGmtdvAOKfjketAjGMC
# =lFhB
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 12 Aug 2026 09:32:51 AM PDT
# gpg: using EDDSA key 01DC385BC24E19137B9437A2A64F1E11E05C77B4
# gpg: issuer "farman@linux.ibm.com"
# gpg: Good signature from "Eric Farman <farman@linux.ibm.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: D2C6 0504 C9E8 F568 CFE5 87B5 3827 B212 71BF 9562
# Subkey fingerprint: 01DC 385B C24E 1913 7B94 37A2 A64F 1E11 E05C 77B4
* tag 's390x-20260812' of https://gitlab.com/efarman/qemu:
pc-bios/s390-ccw.img: update s390x bios
hw: add compat machines for 11.2
target/s390x: Allow 2G hugepages guest backing
tests/tcg/s390x: Test STCKF condition code on a faulting store
target/s390x/tcg: Set STCK/STCKF condition code after the store
pc-bios/s390-ccw: Fix off-by-one errors with loadparm and boot entries
pc-bios/s390-ccw: bound zipl menu strlen and replace VLA in zipl_print_entry
pc-bios/s390-ccw: bounds-check zipl menu entry index before array write
pc-bios/s390-ccw: fix out-of-bounds read in iso_get_file_size()
s390x/ipl: validate num_comp against iplb length before iterating
hw/char/sclpconsole-lm: avoid guest triggerable assert
tests/tcg/s390x: Test DR overflow (INT64_MIN / -1)
target/s390x: Fix DR/D INT64_MIN / -1 host crash
tests/tcg/s390x: Test PRNO TRNG interruptibility
target/s390x: Make PRNO TRNG interruptible
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Patches from Mat Turner to support the mount_setattr() syscall and to add
floating-point registers to core dumps on alpha, mips, hppa, riscv and sh4.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCanzZYQAKCRD3ErUQojoP
X+x4AP9UqX4OuUUZy+HA33eW+54JIT9xfF88VnU6VhZdQpPhlQEA3cYz393TjIpT
uXlgPvwCVa6C3/qUSq//00v3KQsF+Q0=
=4lE3
-----END PGP SIGNATURE-----
Merge tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa into staging
linux-user patches
Patches from Mat Turner to support the mount_setattr() syscall and to add
floating-point registers to core dumps on alpha, mips, hppa, riscv and sh4.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCanzZYQAKCRD3ErUQojoP
# X+x4AP9UqX4OuUUZy+HA33eW+54JIT9xfF88VnU6VhZdQpPhlQEA3cYz393TjIpT
# uXlgPvwCVa6C3/qUSq//00v3KQsF+Q0=
# =4lE3
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 12 Aug 2026 01:36:49 PM PDT
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa:
linux-user/sh4: write the floating-point registers to a core dump
linux-user/riscv: write the floating-point registers to a core dump
linux-user/hppa: write the floating-point registers to a core dump
linux-user/mips: write the floating-point registers to a core dump
linux-user/alpha: write the floating-point registers to a core dump
linux-user: support writing floating-point registers to a core dump
linux-user: implement mount_setattr(2)
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* Fixes missing Kconfig dependencies for Aspeed boards
* Adds 64-bit addressing support to the EHCI USB controller model.
Enable it on the AST2700
* Extends Aspeed SMC qtest coverage with fast-read, DOR and QOR
read modes
* Introduces a separate Aspeed2700SCUState type and shares the SCUIO,
FMC and SCU instances across the AST2700 PSP, SSP and TSP
coprocessors
* Adds Data FIFO-based flash access for the AST2700 FMC controller
* Adds the ADC128D818 12-bit 8-channel ADC sensor device with tests,
wired up on the Anacapa board
* Reworks the PCA9552/PCA9555 GPIO/LED driver: polarity inversion,
datasheet-conformant command handling, GPIO QOM properties, reset
via the Resettable interface, and extensive qtest coverage
* Reworks the PCA9554 GPIO driver: output-to-input reflection,
PCA9536 support, pin direction property, and qtest coverage
* Adds PCA9555 IO expanders and temperature sensors to the Catalina
board
* Adds AST2700 I2C master buffer mode support
* Updates ASPEED functional tests to SDK v11.03 and Zephyr SDK v03.08
* Adds AES-GCM support to the QEMU crypto cipher layer (gcrypt,
nettle, gnutls backends) with unit tests
* Adds crypto (AES) command emulation to the Aspeed HACE model:
direct access, scatter-gather, CTR, GCM modes, 64-bit DMA, with
qtest coverage on AST2500, AST2600, AST1030 and AST2700
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmp7TbQACgkQUaNDx8/7
7KGqiBAAuiozhStgwzhV1ywfStIVL1wUQsg4UiODmihJEd1eRS7KH6q37enXuydI
zKycSTjg1gJUglRbq0OUk+WNeMCwusLVZm2u6GCIF4B9m8n7Qn09vpGY9egAfTdv
XTm1/GStxLLlYp6WaXyXXbm6D5F2KjkaNyqjy2UEQwzsiOfkDcABqnH5CFNT6d3U
q2rcRZ/8exv1bWDD9PI5ip3Si/Uf1p8X8Kcrij5aQRMaJJMZnQZcccryZFz6waxe
xTeQEEE6whS0MwTfKqH6uIm1D2NlekYe3FXDjP4agePhTG/RN3leMxCL3QIwJfk4
sMKf+Mapac1rVE/EY5KHYwKbCGR2t8uRbVTXMhywiZeV8WyBGiq+tabklw8hsFvA
56Q3ez7oTT6vTaIRMSC7PrXXLEZKywhA4jICd2HWq2Dt+XEiAcT6nvM4pDp2ktXq
PtpxLKhlelZ2P7GJUAvOa8rtaeif9RiPELN8cliVqT5MrC0iodMmh+eCponYKwZl
tThzUBatZVn/BP3EFGT7GHicfr3owCblxfuHPVMZiWlX3n4ymixa/3sGk73zb+jo
foSCpi8YEAYxzhcwBfOrNE1UqQuwhOvQWugmEgFfSbjvqL7sFOeivWraYv46fcwE
EQ9+Ah35VE2rq6fNvfUHiTZqWFGDYSvMVHKGCGR0CCu8PJOwdFM=
=SS88
-----END PGP SIGNATURE-----
Merge tag 'pull-aspeed-20260811' of https://github.com/legoater/qemu into staging
aspeed queue:
* Fixes missing Kconfig dependencies for Aspeed boards
* Adds 64-bit addressing support to the EHCI USB controller model.
Enable it on the AST2700
* Extends Aspeed SMC qtest coverage with fast-read, DOR and QOR
read modes
* Introduces a separate Aspeed2700SCUState type and shares the SCUIO,
FMC and SCU instances across the AST2700 PSP, SSP and TSP
coprocessors
* Adds Data FIFO-based flash access for the AST2700 FMC controller
* Adds the ADC128D818 12-bit 8-channel ADC sensor device with tests,
wired up on the Anacapa board
* Reworks the PCA9552/PCA9555 GPIO/LED driver: polarity inversion,
datasheet-conformant command handling, GPIO QOM properties, reset
via the Resettable interface, and extensive qtest coverage
* Reworks the PCA9554 GPIO driver: output-to-input reflection,
PCA9536 support, pin direction property, and qtest coverage
* Adds PCA9555 IO expanders and temperature sensors to the Catalina
board
* Adds AST2700 I2C master buffer mode support
* Updates ASPEED functional tests to SDK v11.03 and Zephyr SDK v03.08
* Adds AES-GCM support to the QEMU crypto cipher layer (gcrypt,
nettle, gnutls backends) with unit tests
* Adds crypto (AES) command emulation to the Aspeed HACE model:
direct access, scatter-gather, CTR, GCM modes, 64-bit DMA, with
qtest coverage on AST2500, AST2600, AST1030 and AST2700
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmp7TbQACgkQUaNDx8/7
# 7KGqiBAAuiozhStgwzhV1ywfStIVL1wUQsg4UiODmihJEd1eRS7KH6q37enXuydI
# zKycSTjg1gJUglRbq0OUk+WNeMCwusLVZm2u6GCIF4B9m8n7Qn09vpGY9egAfTdv
# XTm1/GStxLLlYp6WaXyXXbm6D5F2KjkaNyqjy2UEQwzsiOfkDcABqnH5CFNT6d3U
# q2rcRZ/8exv1bWDD9PI5ip3Si/Uf1p8X8Kcrij5aQRMaJJMZnQZcccryZFz6waxe
# xTeQEEE6whS0MwTfKqH6uIm1D2NlekYe3FXDjP4agePhTG/RN3leMxCL3QIwJfk4
# sMKf+Mapac1rVE/EY5KHYwKbCGR2t8uRbVTXMhywiZeV8WyBGiq+tabklw8hsFvA
# 56Q3ez7oTT6vTaIRMSC7PrXXLEZKywhA4jICd2HWq2Dt+XEiAcT6nvM4pDp2ktXq
# PtpxLKhlelZ2P7GJUAvOa8rtaeif9RiPELN8cliVqT5MrC0iodMmh+eCponYKwZl
# tThzUBatZVn/BP3EFGT7GHicfr3owCblxfuHPVMZiWlX3n4ymixa/3sGk73zb+jo
# foSCpi8YEAYxzhcwBfOrNE1UqQuwhOvQWugmEgFfSbjvqL7sFOeivWraYv46fcwE
# EQ9+Ah35VE2rq6fNvfUHiTZqWFGDYSvMVHKGCGR0CCu8PJOwdFM=
# =SS88
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 11 Aug 2026 09:28:36 AM PDT
# gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater <clg@redhat.com>" [full]
# gpg: aka "Cédric Le Goater <clg@kaod.org>" [full]
* tag 'pull-aspeed-20260811' of https://github.com/legoater/qemu: (83 commits)
tests/qtest/aspeed-hace: Test the crypto command on the AST2700
hw/misc/aspeed_hace: Enable the crypto command on the AST2700
hw/misc/aspeed_hace: Support the AES-GCM mode for the crypto command
hw/misc/aspeed_hace: Support 64-bit DMA for the crypto command
tests/unit/test-crypto-cipher: Test AES-GCM mode
crypto/cipher-gnutls: Implement AES-GCM
crypto/cipher-nettle: Implement AES-GCM
crypto/cipher-gcrypt: Implement AES-GCM
crypto/cipher: Add setaad/gettag for AEAD modes
crypto/cipher: Add GCM to QCryptoCipherMode
tests/qtest/aspeed-hace: Test the crypto command on the AST1030
tests/qtest/aspeed-hace: Test the crypto command on the AST2600
hw/misc/aspeed_hace: Support the CTR mode for the crypto command
hw/misc/aspeed_hace: Support scatter-gather mode for the crypto command
tests/qtest/aspeed-hace: Test the crypto command on the AST2500
hw/misc/aspeed_hace: Support the crypto command in direct access mode
hw/arm/aspeed: avoid sign mismatch on sscanf for uart property
tests/functional/arm/test_aspeed_ast1060: Update ASPEED ZEPHYR PROJECT v03.07
tests/functional/arm/test_aspeed_ast1030: Update ASPEED Zephyr SDK v03.08
tests/functional/arm/test_aspeed_ast2500_sdk: Update ASPEED SDK v11.03
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
QPL and UADK multifd backends use assert() to validate wire-controlled
fields like per-page compressed lengths and packet size consistency. These
asserts will stop working with -DNDEBUG builds, so may stop working.
Replace all assert() calls in the receive path with proper error_setg() so
validation failures are reported gracefully rather than crashing or
silently ignored.
While at it, touch up an assert() in qatzip recv path too.
Cc: qemu-stable <qemu-stable@nongnu.org>
Cc: Yuan Liu <yuan1.liu@intel.com>
Cc: Yichen Wang <yichen.wang@bytedance.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20260728210417.1925078-4-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
The zlib and zstd multifd compression backends read next_packet_size from
the incoming migration stream and use it directly as the read length into a
fixed-size buffer (MULTIFD_PACKET_SIZE * 2 = 1MB). A malicious migration
source can set next_packet_size bigger than allocated, causing a heap
buffer overflow write on the destination.
Add a check against zbuff_len before reading, matching what the qatzip
backend already does. Also replace the assert(in_size == 0) for empty
packets with proper error reporting, since the value is wire-controlled,
meanwhile assert() stops working with -DNDEBUG builds.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3737
Reported-by: xlabai <xlabai@tencent.com>
Reported-by: Jules Denardou <jules.denardou@datadoghq.com>
Reported-by: Tristan Madani <tristan@talencesecurity.com>
Reported-by: david korczynski (@david1766)
Reported-by: huntr bubble (@bubblehuntr)
Cc: qemu-stable <qemu-stable@nongnu.org>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20260728210417.1925078-3-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
Guards against the bug fixed in the previous commit: boots raspi4b's
default 2 GiB configuration and checks that the guest actually sees
close to that (>1.9M kB), not the ~921 MiB the bug left it capped at.
Deliberately checks a threshold rather than the exact byte count of
either figure, since the precise number depends on how this specific
pinned kernel accounts for its own early reservations; the threshold
is comfortably between the two (943524 kB broken, 1905824 kB fixed,
confirmed by hand against this exact kernel/initrd).
Folded into the existing test_arm_raspi4_initrd test rather than a
new standalone boot, since it needs no machine state that test isn't
already setting up, and the functional-test suite is already slow
enough from how many separate guest boots it runs.
Signed-off-by: Marcelo Manzo <marcelomanzo@gmail.com>
Message-id: 20260811143539.7835-3-marcelomanzo@gmail.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
raspi4_modify_dtb() decides whether to add a second memory node above
the 1 GiB peripheral hole by checking info->ram_size -- but that field
is the boot loader's RAM budget for loading the kernel/initrd/dtb
image, itself always capped to at most UPPER_RAM_BASE - vcram_size by
raspi_base_machine_init(). Since that capped value can never exceed
UPPER_RAM_BASE by construction, the condition was never true for any
raspi4b configuration, and the second node was never added: the guest
never saw more than ~1 GiB of its nominal RAM, regardless of the
machine's actual size.
board_ram_size(info->board_id), computed one line above in the same
function, is the value that was actually needed -- the board's real
total RAM, not the boot loader's own budget for where it's allowed to
place the kernel image.
Confirmed via direct measurement inside the guest ("free -h" /
/proc/meminfo) on raspi4b's default 2 GiB configuration, before and
after:
before: MemTotal: 943524 kB (~921 MiB)
after: MemTotal: 1905824 kB (~1861 MiB)
Also verified against two real, unmodified Raspberry Pi OS releases
(Debian 11/Bullseye and Debian 13/Trixie): both now report ~1.8 GiB of
usable RAM instead of ~900 MiB, with clean boots, working SSH, and no
kernel errors on either.
Signed-off-by: Marcelo Manzo <marcelomanzo@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260811143539.7835-2-marcelomanzo@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The RSTC register's write-config bits (0x30) being set to the
"full reset" value (0x20) does not mean "reset now" -- it arms the
hardware watchdog so that a reset happens if the WDOG countdown
register is not refreshed before it expires. The previous
implementation treated any such RSTC write as an immediate reset,
regardless of the WDOG value.
This is dormant on older/lighter userspace (nothing in Bullseye's
default boot touches these registers this way), but modern systemd
(observed with Debian 13/Trixie's systemd 257) writes to RSTC as part
of routine early-boot watchdog probing. With the old code, this fires
an immediate reset a few seconds into boot; combined with -no-reboot
this looks exactly like a QEMU crash (clean exit, no panic, no guest
reboot message) with the last log line being the RSTC/WDOG write.
Fix this by actually implementing the watchdog as a QEMUTimer: writes
to RSTC/WDOG (re)compute the timeout from the WDOG register (in units
of 1/65536 s, per the real hardware) and arm a timer for that many
nanoseconds out; only when the timer actually fires do we request a
system reset or shutdown, matching real hardware behavior. Clearing
the write-config bits or the WDOG value disarms the timer, and reset
disarms it too.
Verified against real Raspberry Pi OS images under the patched
raspi4b machine: Bullseye (5.15) and Bookworm (6.12) never exercised
this path either way; Trixie (6.18, systemd 257) no longer crashes at
boot and reaches a working login/SSH state.
This is a migration compatibility break for the raspi boards.
Signed-off-by: Marcelo Manzo <marcelomanzo@gmail.com>
[PMM: bump vmstate version IDs, note migration break in commit msg]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The last valid register is the Clock Stretch Timeout (CLKT) at
offset 0x1c. Since it is a 32-bit register, the total memory
region size should be 0x1c + 4 = 0x20.
Update the size parameter in memory_region_init_io() from 0x24
to 0x20 to accurately reflect the hardware specification.
Suggested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: botszhuang <huang.botsz@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260804144611.31735-1-huang.botsz@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Page 42 of the AN547 TRM defines the AHB PPC EXP1 ports with DMA 1-3
AN547 TRM: https://developer.arm.com/documentation/dai0547/latest/
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Simon Xu <simonxhy0404@gmail.com>
Message-id: 20260805191257.11303-5-simonxhy0404@gmail.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The AN547 TRM defines them to be on ports [15:13], not [2:0].
AN547 TRM: https://developer.arm.com/documentation/dai0547/latest/
Fixes: eb09d533d8 ("hw/arm/mps2-tz: Add new mps3-an547 board")
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Simon Xu <simonxhy0404@gmail.com>
Message-id: 20260805191257.11303-4-simonxhy0404@gmail.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The SSE-300 CPU0_PPU, MGMT_PPU, DEBUG_PPU had the wrong addresses
that were the same as the SSE-200 addresses.
Page 146 of the SSE-300 TRM defines the addresses of the PPUs.
SSE-300 TRM: https://support.arm.com/documentation/101773/latest/
Fixes: 8901bb414a ("hw/arm/armsse: Add SSE-300 support")
Signed-off-by: Simon Xu <simonxhy0404@gmail.com>
Message-id: 20260805191257.11303-3-simonxhy0404@gmail.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The SSE-300 SLOWCLK Secure Watchdog Timer is only defined at address
0x5802e000 in the secure region.
Page 45 of the SSE-300 TRM specifies that "the watchdog is Secure
access only".
SSE-300 TRM: https://support.arm.com/documentation/101773/latest/
Fixes: 8901bb414a ("hw/arm/armsse: Add SSE-300 support")
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Simon Xu <simonxhy0404@gmail.com>
Message-id: 20260805191257.11303-2-simonxhy0404@gmail.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch add a new model for Cadence GPIO controller which
supports 32 pins and interrupts for level-triggered/edge-triggered type on
input pins.
Also define new trace functions for analysis purpose and new configuration to
enable this model.
Signed-off-by: Kuan-Jui Chiu <kchiu@axiado.com>
Message-id: 20260713073033.3883619-8-kchiu@axiado.com
[PMM: drop unnecessary <private> and <public> marker comments]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add EVK axiado-scm3003 built with AX3000 SoC
Signed-off-by: Kuan-Jui Chiu <kchiu@axiado.com>
Message-id: 20260713073033.3883619-7-kchiu@axiado.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: KConfig for the board has to depend on TCG && ARM]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Enable SD host controller into Axiado AX3000 SoC to load kernel and rootfs
from eMMC.
Signed-off-by: Kuan-Jui Chiu <kchiu@axiado.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713073033.3883619-6-kchiu@axiado.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch add a new model for Axiado SD host controller which is compatible
with SDHCI 3.0 spec
This device model also includes a eMMC PHY which helps to control SD/eMMC
Signed-off-by: Kuan-Jui Chiu <kchiu@axiado.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713073033.3883619-5-kchiu@axiado.com
[PMM: Use HWADDR_PRIx]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch adds a new model for Axiado AX3000 clock control which supports
to read ID and status
Signed-off-by: Kuan-Jui Chiu <kchiu@axiado.com>
Message-id: 20260713073033.3883619-3-kchiu@axiado.com
[PMM: use HWADDR_PRIx]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch adds new model for Axiado SoC AX3000 which supports
4 Cortex-A53 ARM64 CPUs
Arm Generic Interrupt Controller v3
4 Cadence UARTs
Signed-off-by: Kuan-Jui Chiu <kchiu@axiado.com>
Message-id: 20260713073033.3883619-2-kchiu@axiado.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: Kconfig for the SoC shouldn't depend on ARM]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713230244.70174-11-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713230244.70174-10-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713230244.70174-9-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713230244.70174-8-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713230244.70174-7-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713230244.70174-6-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713230244.70174-5-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713230244.70174-4-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713230244.70174-3-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260713230244.70174-2-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add HVX IEEE floating-point min/max instructions:
- vfmin_hf, vfmin_sf: IEEE floating-point minimum
- vfmax_hf, vfmax_sf: IEEE floating-point maximum
- vmax_hf, vmax_sf: qfloat IEEE maximum
- vmin_hf, vmin_sf: qfloat IEEE minimum
The Hexagon qfloat variants are similar to the IEEE-754 ones, but they
handle NaN slightly differently. See comment on hvx_ieee_fp.h
Reviewed-by: Taylor Simpson <ltaylorsimpson@gmail.com>
Signed-off-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/8e274a7a10a5aae23eb1250db0b4f4250c81f3ef.1776339451.git.matheus.bernardino@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
When cpu->cfg.ieee_fp_extension is off, IEEE FP instructions don't get
executed. Let's print that info on the "-d in_asm" output to help users.
This will generate an output like the following:
0x00020e30: 0x1f82e1c0 { V0.sf = vadd(V1.sf,V2.sf) (disabled: no ieee_fp) }
Reviewed-by: Taylor Simpson <ltaylorsimpson@gmail.com>
Signed-off-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/1bdc772e4a795ecd9f5bf2b7e7143cc4b297318c.1776339451.git.matheus.bernardino@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
This flag will be used to control the HVX IEEE float instructions, which
are only available at some Hexagon cores. When unavailable, the
instruction effectively only set the destination registers to 0.
Signed-off-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/10fb5b86db60a465e51db2cf73185307a1ec0895.1776339451.git.matheus.bernardino@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
The following encodings have become stricter since v68:
- V6_vunpackob, V6_vunpackoh: ---00 -> --000
- V6_vaddbq/hq/wq, V6_vaddbnq/hnq/wnq: ---01 -> --001
- V6_vsubbq/hq, V6_vsubwq/bnq/hnq/wnq: ---01/---10 -> --001/--010
- V6_vhist, V6_vwhist128/256, V6_vwhist128/256_sat: ---00 -> --000
- V6_vhistq, V6_vwhist128/256q, V6_vwhist128/256q_sat: ---10 -> --010
Pre v68 compilers, by default, already use "0" for the non-specified bit
that changed in v68, so unless someone is manually writing the binary
encoding, this should not cause any backwards incompatibility with
pre-v68 binaries.
Reviewed-by: Taylor Simpson <ltaylorsimpson@gmail.com>
Signed-off-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/1fe4b8a0fcae6705a591b1b5131e28f6d8062eed.1776339451.git.matheus.bernardino@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Change disassembly of control regs from C{num}/{name} to {name}
Change disassembly of system regs from S{num}/r{num} to {name}
Signed-off-by: Taylor Simpson <ltaylorsimpson@gmail.com>
Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260811032206.58501-1-ltaylorsimpson@gmail.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
ssub32_saturate() and ssub64_saturate() were declared to return bool
instead of int32_t/int64_t, and clamped to the wrong bound on overflow.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Cc: qemu-stable@nongnu.org
Fixes: 1649553313 ("host-utils: Introduce signed saturation primitives")
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260807152241.1576334-2-brian.cain@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Add the QTimer to the shared hex-subsys so both machine models pick it
up. Map its view region, wire its interrupt lines into l2vic, and link
it to the globalreg device backing HEX_SREG_TIMERLO/TIMERHI.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260806042723.3785369-17-brian.cain@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Expose l2vic as a device-tree interrupt-controller node and reference
it via interrupt-parent, so guest kernels can discover the virtio-mmio
transports.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260806042723.3785369-12-brian.cain@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Add the l2vic to the shared hex-subsys so both machine models pick it
up. Map its register banks, wire the interrupt lines to CPU[0]
and link each vCPU, globalregs.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260806042723.3785369-10-brian.cain@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Route the globalreg read/write accessors through new
get_reg_value()/set_reg_value() helpers instead of touching
s->regs[reg] directly.
This will be exploited by a subsequent patch that redirects VID/VID1
accesses to the L2VIC.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260806042723.3785369-9-brian.cain@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
The Hexagon DSP requires an L2VIC to route up to 1024 external
interrupt sources through 4 VID output groups into the core's 8
interrupt inputs. Add a device model for it.
Co-authored-by: Matheus Tavares Bernardino <quic_mathbern@quicinc.com>
Co-authored-by: Damien Hedde <damien.hedde@dahe.fr>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260806042723.3785369-8-brian.cain@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
set_bit32()/test_bit32()/etc already let devices operate on
guest-visible uint32_t register arrays without depending on the host's
'unsigned long' size. Add find_first_bit32() so callers need not cast
a uint32_t array to 'unsigned long *'.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260806042723.3785369-7-brian.cain@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
The virt and DSP machine models build the same core subsystem, let's
abstract out that part. Start with the DDR and config table ROM setup.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260806042723.3785369-2-brian.cain@oss.qualcomm.com
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
As of QEMU v11.1.0, the v5.2.0 machines are not usable anymore.
Use the latest x86 q35 machine instead, otherwise we get:
$ qemu-system-x86_64 -M pc-q35-5.2
qemu-system-x86_64: unsupported machine type: "pc-q35-5.2"
Use -machine help to list supported machines
See commit a35f8577a0 ("include/hw: add macros for deprecation
& removal of versioned machines") and f59ee04406 ("include/hw/boards:
cope with dev/rc versions in deprecation checks") for explanation
on automatically removed versioned machines.
This commit message is taken from commit 9eef3854d3 ("tests/qtest: Do
not use versioned pc-q35-5.0 machine anymore") by Philippe Mathieu-Daudé
<philmd@linaro.org>.
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20260811183144.190135-1-stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The test_precopy_tcp_tls_no_hostname test and its start hook use
TestMigrateTLSX509 and migrate_hook_start_tls_x509_common(), which
are only defined when CONFIG_TASN1 is set. This means building with
gnutls enabled but libtasn1 unavailable fails:
../tests/qtest/migration/tls-tests.c: In function 'migrate_hook_start_tls_x509_no_host':
../tests/qtest/migration/tls-tests.c:510:5: error: unknown type name 'TestMigrateTLSX509'
Guard the test with CONFIG_TASN1 like the other x509 tests.
Fixes: df9c38b19a ("tests/qtest/migration: Add a NULL parameters test for TLS")
Signed-off-by: Sam Heney <github@me.samiser.xyz>
Link: https://lore.kernel.org/r/5f24de0e-49af-45a7-927f-f79b203bb335@app.fastmail.com
Signed-off-by: Peter Xu <peterx@redhat.com>
This basically reverts 4a2e242bbb ("memory: Don't use memcpy for
ram_device regions") to make ram device region directly accessible
again. With this, the bounce buffer is bypassed in address_space_map()
when a ram device region is involved, potentially avoid to overrun
the (small) bounce buffer.
Reported-by: Julia Graham <jugraham@redhat.com>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Suggested-by: Peter Xu <peterx@redhat.com>
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Link: https://lore.kernel.org/r/20260728031731.286666-4-gshan@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
All ram device regions were turned to be indirectly accessible by commit
4a2e242bbb ("memory: Don't use memcpy for ram_device regions"). This leads
to guest hang on attempt to build 'cuda-samples' as reported by Julia. The
guest is started by the following command lines, with GH100 GPU card passed
from the host.
host$ lspci | grep GH100
0009:01:00.0 3D controller: NVIDIA Corporation GH100 [GH200 120GB / 480GB] (rev a1)
host$ /home/sandbox/gavin/qemu.main/build/qemu-system-aarch64 \
-machine virt,gic-version=host,ras=on,highmem-mmio-size=4T \
-accel kvm -cpu host -smp cpus=48 -m size=8G \
-drive file=/home/gavin/sandbox/images/disk.qcow2,if=none,id=d0 \
-device virtio-blk-pci,id=vb0,bus=pcie.0,drive=d0,num-queues=4 \
-device vfio-pci-nohotplug,host=0009:01:00.0,bus=pcie.1.0
:
guest$ cd cuda-samples/build
guest$ make -j 20 clean
guest$ make -j 20
:
[ 54%] Linking CUDA executable graphMemoryNodes
[ 54%] Built target graphMemoryNodes
<no more output afterwards, guest becomes frozen here>
guest$ qemu-system-aarch64: virtio: bogus descriptor or out of resources
[ 555.814025] virtio_blk virtio0: [vda] new size: 268435456 512-byte logical blocks (137 GB/128 GiB)
When the GPU's driver (NVidia open driver) is loaded on guest bootup,
the memory blocks residing in the PCI BAR#4 of the GH100 GPU card can
be presented to the guest through memory hot-add. The page cache can
then be allocated from the hot added memory blocks when cuda-samples
is being built. Afterwards, the page cache is sent to QEMU's virtio-blk
device as part of the DMA request, the bounce buffer has to be used to
accomodate the request as the corresponding memory region (MemoryRegion)
is an indirectly accessible ram device region in qemu. However, the max
bounce bufer size is only 4096 bytes by default and that is exhausted
quickly, leading to a reset on the virtio-blk device and frozen guest
eventually.
QEMU
====
virtio_blk_handle_output
virtio_blk_handle_vq
virtio_blk_get_request
virtqueue_pop
virtqueue_split_pop
virtqueue_map_desc
address_space_map
memory_access_is_direct # Return false
memory_region_supports_direct_access
(qemu) info mtree
memory-region: pci_bridge_pci
0000000000000000-ffffffffffffffff (prio 0, container): pci_bridge_pci
0000042000000000-0000043fffffffff (prio 1, i/o): 0009:01:00.0 base BAR 4
0000042000000000-0000043fffffffff (prio 0, i/o): 0009:01:00.0 BAR 4
0000042000000000-000004379fffffff (prio 0, ramd): 0009:01:00.0 BAR 4 mmaps[0]
This adds qemu_ram_move() where the aligned and small-sized accesses are
handled by qatomics, and fall back to memmove() otherwise. The memove()
for the directly accessible regions is replaced by qemu_ram_move() so that
the issue covered by commit 4a2e242bbb (MMIO access instructions were
optimized to SSE instructions) is fixed. This makes 'ram_device_mem_ops'
redundant, paving the way to revert that commit to make the ram device
region directly accessible again in the next patch.
Besides, this also fixes the issue of the unexpected frozen reception on
e1000 NIC in the scenario of DPDK due to the wrong Rx queue full indication
caused by the following memcpy(), which is turned to 3 consective 'strb'
instructions to the same location by glibc-2.24+ for aarch64. With this
applied, the syntax of one-byte store is strictly ensured by a one-byte
qatomic set.
QEMU
====
e1000_receive_iov
pci_dma_write
pci_dma_rw
dma_memory_rw
dma_memory_rw_relaxed
address_space_rw
address_space_write
flatview_write
flatview_write_continue
flatview_write_continue_step
memcpy # 3 consective 'strb' instructions
Reported-by: Julia Graham <jugraham@redhat.com>
Reported-by: Liu Gang <liugang24219@sangfor.com.cn>
Reported-by: Ding Hui <dinghui@sangfor.com.cn>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Suggested-by: Peter Xu <peterx@redhat.com>
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Link: https://lore.kernel.org/r/20260728031731.286666-3-gshan@redhat.com
[peterx: remove src==dst check, fix doc, enhance comments, per PeterM, add R-b]
Signed-off-by: Peter Xu <peterx@redhat.com>
Similar to what's done in commit 4a73aee881 ("softmmu: Use memmove in
flatview_write_continue"), there are more sites where the overlapping
source and destination buffer are allowed for the directly accessible
regions. Use memmove() in those sites, listed as below.
hw/remote/vfio-user-obj.c::vfu_object_mr_rw
include/system/memory.h::address_space_read
system/physmem.c::flatview_read_continue_step
Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Xu <peterx@redhat.com>
Link: https://lore.kernel.org/r/20260728031731.286666-2-gshan@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
Currently the cpr-transfer source QEMU instance cannot be driven entirely
via HMP. The source must use QMP in order to specify both the
main migration channel and the CPR channel.
Extend the HMP migrate command with an optional CPR channel URI. When the
migration mode is cpr-transfer, HMP uses this URI to build a
CPR MigrationChannel in addition to the main migration channel. The new
option is rejected unless the migration mode is cpr-transfer, so existing
HMP migrate usage is unchanged.
For example, source QEMU HMP commands can be something like below. The
"-c unix:/tmp/cpr.sock" is for CPR URI.
(qemu) migrate_set_parameter mode cpr-transfer
(qemu) migrate -c unix:/tmp/cpr.sock tcp:0:50002
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Acked-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Link: https://lore.kernel.org/r/20260728085903.173265-1-dongli.zhang@oracle.com
Signed-off-by: Peter Xu <peterx@redhat.com>
Add the security considerations that are unique to migration and that
do not already fall into one of the other categories. Some aspects are
better framed as security architecture considerations, so extend that
section to mention TLS and clarify that disk images and guest network
also need to be isolated from other processes, not just other guests.
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20260721131457.3062767-1-farosas@suse.de
Signed-off-by: Peter Xu <peterx@redhat.com>
Cover the AST2700 crypto engine, which drives 64-bit scatter-gather DMA
and adds AES-GCM on top of the ECB/CBC/CTR modes shared with the AST2600.
Add AES-128 and AES-256 GCM known-answer vectors (GCM specification /
NIST SP 800-38D, no associated data) and a dedicated GCM runner that
programs the tag buffer and reads the tag back, checking it after both
encryption and decryption. Register the AST2700 with all four modes.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-17-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
With direct/scatter-gather access, 64-bit DMA and AES-GCM all in place,
the AST2700 crypto engine is now fully modelled. Drop its temporary
interrupt-only workaround so the crypto command runs for real, like the
other HACE variants.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-16-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Implement the AES-GCM mode (HACE10[6:4] = 0b101) used by the AST2700
crypto engine: decode the GCM selection, read the 96-bit IV from the
context buffer, operate on the exact data length (GCM handles a partial
final block itself), and write the 128-bit authentication tag to the tag
buffer (HACE18/HACE8C). The hardware GCM path is only used without
associated data (the driver falls back to software otherwise), so AAD is
not modelled and a non-zero HACE14 is reported as unimplemented.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-15-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The AST2700 crypto engine addresses DRAM with 64 bits, supplying the high
half of the source, destination and context addresses through HACE80,
HACE84 and HACE88. Add those registers and a crypt_get_addr() helper that
combines the low and high halves when the SoC has 64-bit DMA, mirroring
the hash engine. SoCs without 64-bit DMA (AST2500/AST2600/AST1030) ignore
the high registers, so their behaviour is unchanged.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-14-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Exercise the new GCM mode and the setaad/gettag helpers with the
canonical AES-GCM test vectors from the GCM specification (McGrew &
Viega, also NIST SP 800-38D): AES-128 and AES-256, with and without
associated data. Each vector is run through encrypt (checking the
ciphertext and the generated tag) and decrypt (checking the recovered
plaintext and the recomputed tag).
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-13-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add the AES-GCM AEAD mode to the gnutls backend so it is available when
QEMU is built with gnutls (neither gcrypt nor nettle). GCM uses the
incremental gnutls_cipher_* API with the GNUTLS_CIPHER_AES_*_GCM
algorithms: gnutls_cipher_set_iv() sets the nonce, gnutls_cipher_add_auth()
feeds the associated data, gnutls_cipher_encrypt2()/decrypt2() process the
message, and gnutls_cipher_tag() reads back the authentication tag.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-12-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add the AES-GCM AEAD mode to the nettle backend so it is available when
QEMU is built with nettle instead of gcrypt. GCM is driven through
nettle's generic gcm_* interface, using the AES encrypt function for both
directions: gcm_set_iv() sets the (typically 96-bit) nonce, gcm_update()
feeds the associated data, gcm_encrypt()/gcm_decrypt() need not be block
aligned, and gcm_digest() produces the authentication tag.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-11-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Map QCRYPTO_CIPHER_MODE_GCM to GCRY_CIPHER_MODE_GCM and advertise it in
qcrypto_cipher_supports() for 128-bit block ciphers. Add a GCM driver
whose setiv accepts the (typically 96-bit) nonce, whose encrypt/decrypt
do not require block-aligned lengths, and which implements setaad via
gcry_cipher_authenticate() and gettag via gcry_cipher_gettag().
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-10-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
AEAD modes such as GCM authenticate optional associated data (AAD) and
produce an authentication tag, which the block-cipher encrypt/decrypt
interface cannot express. Add qcrypto_cipher_setaad() and
qcrypto_cipher_gettag() plus the matching backend driver hooks. The
generic front-end reports an error when the selected mode's driver does
not implement them, so calling them on a non-AEAD mode fails cleanly.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-9-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Introduce the GCM cipher mode so authenticated encryption can be built
on top of the existing qcrypto_cipher API. GCM is an IV-based mode, so
register it in mode_need_iv. No backend advertises it yet, so it stays
unsupported until a backend and the AAD/tag helpers are added in the
following patches.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-8-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The AST1030 reuses the AST2600 crypto engine, so it drives the same
scatter-gather transfers and supports the same ECB/CBC/CTR modes. Reuse
the crypto known-answer tests to cover it, registering the AST1030 with
the same modes and scatter-gather flag as the AST2600.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-7-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Extend the crypto known-answer tests to cover the AST2600 crypto engine,
which drives the source and destination through scatter-gather lists and
adds CTR mode on top of the ECB/CBC modes shared with the AST2500.
Add a scatter-gather runner that describes each buffer with three
non-adjacent fragments to exercise the gather/scatter path, add
AES/DES/3DES CTR vectors (verifying the counter written back to the
context buffer), and give aspeed_add_crypto_tests() a mode mask and a
scatter-gather flag so each SoC registers exactly the modes and transfer
method it supports. Register the AST2600 with ECB/CBC/CTR in
scatter-gather mode.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-6-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The AST2600, AST1030 and later crypto engines add AES/DES/3DES CTR mode
(HACE10[6:4] = 0b100) on top of the ECB/CBC modes shared with the
AST2500. Decode the CTR selection, round the working buffers up to a
whole block so the stream-like final block is still processed a block at
a time, and write the counter advanced by the number of blocks consumed
back to the context buffer so the driver can continue across requests.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-5-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The AST2600 and later crypto engines drive the source and destination
through scatter-gather lists (HACE10[18]/[19]) rather than the single
contiguous buffers used by the AST2500 direct access mode. Each SG list
entry is a length word (SG_LIST_LEN_LAST marks the final entry) followed
by a DRAM address, matching the hash engine layout.
Add a crypt_prepare_sg() helper that gathers the source into / scatters
the destination out of the bounce buffer by walking the SG list, and
select it or the existing crypt_prepare_direct() from do_crypt_operation
based on HACE10[18], mirroring the hash engine's direct/scatter-gather
dispatch.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-4-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add a crypto known-answer test harness and exercise the AST2500, which
uses the crypto engine's direct access mode. Each mode (AES/DES/3DES in
ECB and CBC) is a separate test that checks the ciphertext, the
plaintext round-trip and, for CBC, the chaining IV written back to the
context buffer.
The key/IV/plaintext/ciphertext values are taken verbatim from the Linux
kernel crypto self-test templates in crypto/testmgr.h.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-3-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The crypt command register was previously stubbed out. Implement it for
the direct access mode, where HACE00/HACE04 point directly at contiguous
source and destination buffers. AES-128/192/256, DES and 3DES are
supported in ECB and CBC modes via the qcrypto cipher API; the IV and
key are read from the context buffer (HACE08) and, for CBC, the
resulting chaining IV is written back to the context.
The completion interrupt is now raised for every HACE variant as the
hardware does, which fixes the crypt command hang on the AST2500, AST2600
and AST1030. The AST2700 crypto engine still needs 64-bit DMA and
AES-GCM, which are added later, so it keeps its temporary interrupt-only
workaround until then.
For debugging, the context, source and destination buffers are dumped
through the existing aspeed_hace_hexdump trace event (disabled by
default). CTR mode, scatter-gather mode and AES-GCM are added separately.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Kane Chen <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260811060115.1849266-2-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
using "%u" with sscanf() was likely meant to indicate that a
negative value was unexpected, but with a signed variable it
could result in undefined behaviour.
use "%d" and check for a negative input explicitly.
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260802162828.16880-1-carenas@gmail.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The AST2700 I2C controller can move master DMA payloads through its
internal SRAM pool rather than DRAM. The Linux driver calls this "buffer
mode" and selects it by default. Buffer mode reuses the master DMA
command bits (TX/RX_DMA_EN) and the DMA length registers, so the only
difference from a DRAM transfer is where the data comes from and goes
to: an offset into the pool programmed in I2CM_DMA_TX/RX_ADDR. The
I2CC_VERSION_CTRL FUNC_CFG_DMA_EN bit selects between the two.
Implement I2CC_VERSION_CTRL and, when FUNC_CFG_DMA_EN is clear, move the
payload through the pool buffer instead of DRAM.
I2CC_VERSION_CTRL resets to all ones, so guests that never program it
keep targeting DRAM and behave as before. The register sits above the
register window of the earlier SoCs, which are therefore unaffected.
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/20260804081955.1563537-2-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Model the temperature sensors described by the Catalina device tree that
have existing QEMU device models but were not yet instantiated: the four
IOB NIC TMP421 sensors behind the i2c0 PCA9546 muxes at 0x71 and 0x75, and
the FIO remote TMP75 sensor at 0x4f on the i2c1 mux.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-25-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The Catalina BMC device tree describes several IO expanders as nxp,pca9555.
These were previously instantiated as PCA9552 devices as no PCA9555 model
existed. Now that a dedicated PCA9555 device is available, use it so the
emulated IO expanders match the hardware.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-24-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The PCA9536 shares the PCA9554 register map and code path but exposes
only four pins. Add a pca9536 node and check its reset defaults and
output-to-input reflection are masked to the low nibble.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-23-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The PCA9554 selects one of its four registers with a single command byte
and does not auto-increment the register pointer, so a multi-byte I2C
transfer keeps addressing the register chosen by the command byte instead
of walking through the register map.
Add a test covering this: a two-byte read returns the addressed register
twice, and a two-byte write updates only that register, leaving its
neighbour untouched.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-22-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Verify that the polarity register inverts the value read back from the
INPUT register, both on pulled-up inputs and on output-driven pins, while
leaving the OUTPUT register itself unchanged.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-21-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Check that a pin configured as output drives its OUTPUT register level
onto the pin (push-pull) as reflected by the INPUT register, and that a
pin configured as input floats high through its pull-up.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-20-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add a qtest for the PCA9554 8-bit I/O port expander exercising the basic
register access: power-on reset defaults and read/write of the OUTPUT,
CONFIG and POLARITY registers.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-19-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The pinN properties are accessed with visit_type_str() (values "low" and
"high"), but were registered as type "bool", so introspection advertised
a boolean while the accessors require a string. Register them as "str",
matching the PCA9555 GPIO variant.
Fixes: de0c7d543b ("misc: Add a pca9554 GPIO device model")
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-18-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
pca9554_update_pin_input() derived the pin level from CONFIG | OUTPUT,
which treated an output driven high as Hi-Z and let ext_state pull it
low. The PCA9554/PCA9536 output stage is push-pull, so a pin configured
as an output drives the OUTPUT register level regardless of any external
agent. Reflect the output value directly for output pins and keep the
pull-up/ext_state behaviour for input pins, matching the PCA9555 GPIO
variant.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-17-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The pinN QOM accessors are meant to let external agents observe and
stimulate the expander's pins, but their default behaviour does not
match real hardware:
- to "drive" a pin, set_pin writes the OUTPUT register and then clears
the pin's Configuration bit to force it into output mode. On a real
device the pin direction is owned solely by the host (programmed
through the Configuration register over I2C); an external agent can
neither flip a pin's direction nor impose a level on a pin the host
drives as an output -- the latter is a voltage conflict, not a legal
operation.
- get_pin returns a CONFIG|OUTPUT composite, i.e. the guest's intent,
rather than the level actually sampled on the pin.
The PCA9555 GPIO variant (hw/gpio/pca9552.c) already models this
correctly and unconditionally: only input-configured pins can be driven
from outside, and reads return the sampled INPUT register.
Add a "hw-dir" property to bring the pca9554 pin accessors in line with
the hardware (and with the PCA9555 model), without changing the
behaviour seen by existing users:
- hw-dir=true: set_pin only drives pins the guest has configured as
inputs; a set on an output pin is refused with a LOG_UNIMP warning.
get_pin returns the sampled INPUT register.
- hw-dir=false (default): keeps the legacy, non-conformant behaviour
for backward compatibility.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-16-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The PCA9536 is a 4-bit I/O expander that's register-compatible with the
PCA9554 but only has 4 pins. Rather than duplicating the whole driver,
make the existing PCA9554 model parameterizable and register PCA9536 as
a subtype.
Introduce a PCA9554Class with a pin_count property, and replace every
hard-coded PCA9554_PIN_COUNT reference in the driver with the class
value. The reset function now computes the correct pin mask from
pin_count instead of assuming 0xFF.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-15-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The PCA9552 shares its device model with the PCA9535/PCA9555 GPIO
expanders but decodes registers differently. Add tests for the behaviour
that is specific to the LED variant and diverges from the PCA9555:
- the power-on reset defaults of the prescaler, PWM and LED-selector
registers;
- the prescaler/PWM registers (2-5), which are OUTPUT/POLARITY on the
PCA9555, as plain read/write storage;
- the auto-increment, which only advances when the AI command bit is set
and wraps modulo the full 10-register map (rather than toggling bit 0
within a register pair);
- the 4-bit command decode, where an out-of-range register reads back
0xFF instead of aliasing into the register window.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-14-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add tests for the I2C command protocol of the GPIO variant: the
auto-increment that toggles bit 0 within a register pair on reads and
writes, and the 3-bit command wrapping that aliases out-of-range register
addresses back into the register window.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-13-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add tests for the polarity inversion register: the inversion is applied
when reading the INPUT register, both for input pins (pull-up) and for
output-driven pins, and it does not affect the OUTPUT register readback.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-12-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add tests covering the pin I/O semantics of the expander: output-driven
pins reflected in the input register, the pull-up seen on input-configured
pins, and the independence of the two 8-bit ports.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-11-82a63fead90c@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Introduce a qtest for the PCA9555 16-bit I/O port expander.
This first set covers the power-on reset defaults and the read/write
behaviour of the OUTPUT, CONFIG and POLARITY register pairs.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-10-814575bc076b@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The PCA9552 exposes its LED channels as led%d QOM string properties, but
the GPIO variants (PCA9535/PCA9555) inherited the same led%d interface,
which drives the LED selector registers and is meaningless for a plain
I/O expander.
Add pin%d string properties ("low"/"high") for the GPIO variants,
mirroring the standalone pca9555 model:
- reading returns the raw pin logic level from the INPUT register;
- writing drives the external input level, but only for pins the guest
has configured as inputs (writes to output pins are ignored with a
LOG_UNIMP message).
The LED variant keeps its led%d properties.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-9-814575bc076b@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The PCA9535/PCA9555 GPIO expanders share the PCA955X command dispatch
path with the PCA9552 LED blinker, but their register access differs from
the LED variant:
- Auto-increment happens on every access and toggles bit 0 so the
pointer stays within the addressed register pair (input, output,
polarity, config); there is no AI enable bit.
- The command byte only decodes 3 bits, so addresses beyond the last
register alias back into the 8-register window instead of faulting.
Branch the auto-increment and command-decode logic on has_led_support so
the GPIO variants follow their datasheet while the PCA9552 behaviour is
left untouched.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-8-814575bc076b@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The PCA9535 polarity inversion register inverts the value read back from
the input port for every pin, regardless of its direction, and does not
affect the output drive or the physical pin level.
Store the raw pin level in the input register and apply the polarity
inversion when the input port is read, instead of XORing it into the
stored value of output-configured pins only. The interrupt output now
reflects the raw pin level, matching the datasheet.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-7-814575bc076b@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Convert the PCA9552 and PCA9535/PCA9555 reset handlers from the legacy
device reset hook to the Resettable interface: move each reset body into
a ResettableHoldPhase handler and register it through the class's
ResettableClass::phases.hold instead of device_class_set_legacy_reset().
No functional change.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-6-814575bc076b@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
PCA9555 HW is mostly identical to PCA9535.
PCA9555 HW features pull-up resistors that are not available on PCA9535.
Pull-up are not handled by current PCA955x implementation and PCA9535
already initializes input as Hi-Z.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-5-814575bc076b@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
When no description is supplied, fall back to the actual QOM type name
(pca9552 / pca9535 / pca9555) via object_get_typename() instead of the
opaque "pca-unspecified" placeholder, matching the PCA9554 model and
giving meaningful device labels in traces.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-4-814575bc076b@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Nothing outside pca9552.c uses the PCA955xState structure, its instance
checker, or the PCA955X_NR_REGS/PCA955X_PIN_COUNT_MAX defines: the board
files and qtests only rely on the TYPE_* name macros (and the register
macros in pca9552_regs.h).
Move the state structure and the size defines into pca9552.c, leaving
pca9552.h with just the type-name macros. While at it, replace the
separate DECLARE_INSTANCE_CHECKER and DECLARE_CLASS_CHECKERS declarations
with a single OBJECT_DECLARE_TYPE().
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-2-814575bc076b@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Replace the separate TypeInfo definitions and pca955x_register_types()
registration function with a single type array registered through the
DEFINE_TYPES() macro, to prepare addition of new PCA955x-derived devices.
No functional change.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260709-catalina-upgrade-v1-1-814575bc076b@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Wire up the two ADC128D818 instances that appear in the Anacapa DTS:
one on i2c8 mux channel 0 and one on i2c13 mux channel 3.
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Link: https://lore.kernel.org/qemu-devel/20260707091609.97759-9-emmanuel.blot@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The anacapa machine source contains a few comments using the U+2014 EM
DASH character. Replace them with plain ASCII hyphens so the file stays
ASCII-only.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Link: https://lore.kernel.org/qemu-devel/20260707091609.97759-8-emmanuel.blot@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Cover advanced-configuration mode selection (single-ended,
pseudo-differential pairs, and mixed) and the reset of readings on
reconfiguration, plus channel disable, one-shot conversion, deep
shutdown, BUSY_STATUS lifecycle, and conversion-rate gating.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Link: https://lore.kernel.org/qemu-devel/20260707091609.97759-6-emmanuel.blot@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Cover per-channel high- and low-limit interrupt status, the
INT_CLEAR bit gating the monitoring loop, and the temperature
high-limit alarm with hysteresis.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Link: https://lore.kernel.org/qemu-devel/20260707091609.97759-5-emmanuel.blot@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Cover single-ended voltage conversion across all channels, voltage
and temperature boundary and clamping cases, and scaling against an
external voltage reference.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Link: https://lore.kernel.org/qemu-devel/20260707091609.97759-4-emmanuel.blot@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Introduce the QOS test node and QMP property helpers for the
ADC128D818, and cover basic register access: manufacturer and
revision IDs, power-on-reset defaults, software reset, and the
ain and temperature property readback.
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Link: https://lore.kernel.org/qemu-devel/20260707091609.97759-3-emmanuel.blot@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The ADC128D818 is a TI 12-bit, 8-channel I2C ADC used on several
OpenBMC platforms for voltage and temperature monitoring.
Implement the device with:
- four operating modes
- 12-bit voltage conversion from QOM inputs
- 9-bit temperature conversion from milli-degree Celsius QOM inputs
- switchable internal or external voltage reference
- per-channel high/low limit registers
- interrupt support
- software reset
- one-shot conversion support in shutdown mode
Reviewed-by: Alexander Hansen <alexander.hansen@9elements.com>
Tested-by: Alexander Hansen <alexander.hansen@9elements.com>
Signed-off-by: Emmanuel Blot <emmanuel.blot@free.fr>
Link: https://lore.kernel.org/qemu-devel/20260707091609.97759-2-emmanuel.blot@free.fr
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add two qtest cases exercising the new AST2700 Data FIFO-based flash
access path (R_DATA_FIFO at spi_base + 0x200).
Write_page_datafifo sends the page-program command and data through
the FIFO port, then verifies the result via the regular read path.
Read_page_datafifo writes a page the regular way, then reads it back
through the FIFO port, so both directions are checked independently.
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/20260717084559.3477061-10-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
AST2700 supports a Data FIFO mode where flash accesses can be performed
directly through Data FIFO MMIO offsets. The Data FIFO start offset
increments by one for every 16MB of flash address space, allowing the
chip select (CS) to be decoded from the Data FIFO offset.
This change adds Data FIFO support to the Aspeed SMC model and introduces
a class callback to translate Data FIFO offsets into CS indices. For
AST2700, the Data FIFO offset is matched against the segment start address
of each CS to determine the target flash device.
The SMC register region size (nregs) is also extended dynamically
based on the number of supported chip selects to cover all possible
Data FIFO regions.
This breaks migration compatibility with older QEMU builds for the
affected models, even though Aspeed machines are not officially
covered by migration compatibility guarantees.
Bump version_id to 4 and minimum_version_id to 2 to reflect the
incompatible format.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260717084559.3477061-9-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
AST2700 provides a single FMC controller shared by the main CA35 processor
(PSP) and the SSP/TSP coprocessors.
>From the PSP perspective, the FMC controller is memory-mapped at
0x14000000–0x140000FF. The SSP and TSP access the same controller through
a different address window at 0x74000000–0x740000FF.
This change allows the SSP and TSP SoC models to reference the existing
PSP FMC instance instead of creating independent controllers. An MMIO
alias is added in the SSP and TSP address spaces to map their FMC access
window to the shared FMC device.
This ensures consistent FMC state across PSP, SSP, and TSP and matches
the AST2700 hardware design.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260717084559.3477061-8-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
AST2700 has a single SCUIO hardware block, memory-mapped at
0x14C02000–0x14C03FFF from the perspective of the main CA35 processor (PSP).
The SSP and TSP coprocessors access this same SCUIO block at different
addresses: 0x74C02000–0x74C03FFF.
Previously, each subsystem (PSP, SSP, and TSP) instantiated its own SCUIO
device, resulting in three independent SCUIO instances in the QEMU model.
In real hardware, however, only a single SCUIO exists and is shared among
all processors.
This commit reworks the SCUIO model to correctly reflect the hardware
behavior by allowing SSP and TSP to reference the PSP’s SCUIO instance.
The following changes are introduced:
- Add a scuio property to Aspeed27x0CoprocessorState for linking the
coprocessor to the PSP’s SCUIO instance.
- Replace per-coprocessor SCUIO instantiation with a shared SCUIO link.
- Add "MemoryRegion scuio_alias" to model address remapping for SSP and TSP.
- Create SCUIO alias regions in both SSP and TSP coprocessors and map
them at 0x74C02000 to mirror the PSP’s SCUIO registers.
- Ensure the SCUIO device in PSP is realized before SSP/TSP alias setup.
With this change, PSP, SSP, and TSP now share a consistent SCUIO state,
matching the single-SCUIO hardware design of AST2700.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260717084559.3477061-7-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Pass the realized PSP SoC to the SSP/TSP initialization helpers instead
of retrieving it from the MachineState.
This makes the dependency explicit, since the SSP and TSP coprocessors
use resources owned by the PSP SoC, including the UARTs, SRAM, SCU and
SCUIO. The PSP SoC must therefore be realized before the coprocessors
are initialized.
No functional change.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260717084559.3477061-6-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Introduce a dedicated reset handler for SCUIO.
Previously, SCU and SCUIO shared the same reset handler. This no longer
fits the AST2700 design, where SCU uses the Aspeed2700SCUState subclass
and will handle coprocessor-related control in future changes.
Since these controls are defined in SCU (not SCUIO), SCU and SCUIO
should not share the same reset logic.
This change gives SCUIO its own reset handler and prepares for upcoming
SCU-specific functionality.
No functional change.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260717084559.3477061-5-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The SCU link is only needed by the AST27x0 SSP/TSP coprocessors for their
AST2700-specific SCU alias window.
Move the link property from the common AspeedCoprocessorState into
Aspeed27x0CoprocessorState, so the generic coprocessor model no longer
contains an AST2700-specific dependency.
Also validate that the SCU link has been provided during device realize
before accessing it.
No functional change.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260717084559.3477061-4-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Now that Aspeed2700SCUState has been introduced, update the AST1700 and
AST27x0 SoCs to instantiate the AST2700-specific SCU subclass instead of
the generic AspeedSCUState.
Also update the AST27x0 FC board to link the SSP/TSP coprocessors to the
AST2700 SCU instance.
This prepares the AST2700 platform for subsequent patches that move
AST2700-specific SCU functionality into the subclass.
No functional change.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260717084559.3477061-3-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Introduce Aspeed2700SCUState as an AST2700-specific subclass of
AspeedSCUState.
Currently, AST1700 and AST2700 reuse the generic AspeedSCUState.
However, AST2700 requires SCU functionality that is specific to the
platform, particularly for interactions with its coprocessors.
Introduce a dedicated Aspeed2700SCUState to provide an extension point
for AST2700-specific functionality while keeping the generic
AspeedSCUState unchanged.
Subsequent patches will migrate AST2700 users to the new subclass and
move AST2700-specific code into it.
No functional change.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260717084559.3477061-2-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add read_page_mem_qor (CTRL_FREADMODE with QOR command and quad data
IO mode) and write_page_qor (user-mode QOR) tests.
Reviewed-by: Bin Meng <bin.meng@processmission.com>
Link: https://lore.kernel.org/qemu-devel/20260714124621.522948-5-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add read_page_mem_dor (CTRL_FREADMODE with DOR command and dual data
IO mode) and write_page_dor (user-mode DOR) tests.
Reviewed-by: Bin Meng <bin.meng@processmission.com>
Link: https://lore.kernel.org/qemu-devel/20260714124621.522948-4-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Introduce a spi_ctrl_set_fast_read() helper and add
read_page_mem_fast_read (CTRL_FREADMODE with dummy byte) and
write_page_fast_read (user-mode FAST_READ) tests.
While at it, replace the license boilerplate with SPDX identifier.
Reviewed-by: Bin Meng <bin.meng@processmission.com>
Link: https://lore.kernel.org/qemu-devel/20260714124621.522948-3-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add a functional test to verify USB EHCI support on the AST2700 A2/A1
by attaching a USB keyboard device and checking its
enumeration via lsusb.
This introduces a helper routine that runs lsusb in the guest
and validates that the emulated "QEMU USB Keyboard" is detected.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260713032704.3583103-11-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
AST2700 supports a 64-bit DRAM address space. Therefore, DMA
transactions must be capable of accessing 64-bit addresses.
Enable the "caps-64bit-addr" property for the EHCI controllers
on AST2700 so that USB DMA operations can correctly handle
64-bit memory addresses.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260713032704.3583103-10-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
On AST2700 platforms, system DRAM is mapped above 4GB with a base
address at 0x400000000.
The Linux EHCI driver programs the segment register to zero when
64-bit addressing is supported. As a result, descriptor addresses
derived from the EHCI registers do not include the DRAM base
address.
Descriptor memory is allocated through the DMA API with a 64-bit
DMA mask, allowing descriptors to reside in DRAM above 4GB. On
AST2700, EHCI queue heads (QH) and queue element transfer
descriptors (qTD) are therefore placed at addresses starting from
0x400000000.
Set the ctrldssegment-default property to "sc->memmap[ASPEED_DEV_SDRAM] >> 32"
so the upper 32 bits of descriptor addresses are adjusted accordingly. This
allows the emulated EHCI controller to construct correct system
addresses when accessing descriptors in DRAM above 4GB.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260713032704.3583103-9-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
When 64-bit addressing is supported, the Linux EHCI driver programs the
segment register to zero. See ehci_run function:
https://github.com/torvalds/linux/blob/master/drivers/usb/host/ehci-hcd.c
The driver comment also notes that descriptor structures allocated from
the DMA pool use segment zero semantics.
Descriptor memory is allocated using the DMA API. The platform driver
configures a 64-bit DMA mask so memory can be allocated above 4GB.
See ehci_platform_probe function:
https://github.com/torvalds/linux/blob/master/drivers/usb/host/ehci-platform.c
On AST2700 platforms, system DRAM is mapped above 4GB at 0x400000000.
As a result, descriptor addresses constructed directly from the guest
EHCI registers do not match the actual system address used by the
controller when fetching queue heads (QH) and queue element transfer
descriptors (qTD).
Add a ctrldssegment-default property so platforms can provide a
descriptor address offset when constructing descriptor addresses.
This allows systems where DRAM resides above 4GB to access EHCI
descriptors correctly.
The default value is zero, so existing machines are not affected.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260713032704.3583103-8-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
EHCI supports 64-bit control data structure addressing when the
64-bit Addressing Capability bit in HCCPARAMS is set. In that mode,
the CTRLDSSEGMENT register provides the upper 32 bits that are
concatenated with 32-bit link pointer values to form full 64-bit
descriptor addresses (EHCI 1.0, section 2.3.5 and Appendix B).
siTD link pointers are stored as 32-bit values and must be expanded
to full 64-bit descriptor addresses when 64-bit mode is enabled.
Update the siTD traversal path to use ehci_get_desc_addr() when
following link pointers.
When 64-bit capability is disabled, descriptor addresses remain
32-bit and existing behaviour is unchanged.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260713032704.3583103-7-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
EHCI supports 64-bit control data structure addressing when the
64-bit Addressing Capability bit in HCCPARAMS is set. In that mode,
the CTRLDSSEGMENT register provides the upper 32 bits that are
concatenated with 32-bit link pointer values to form full 64-bit
descriptor addresses (EHCI 1.0, section 2.3.5 and Appendix B).
iTD link pointers are stored as 32-bit values and must be expanded
to full 64-bit descriptor addresses when 64-bit mode is enabled.
Update the iTD traversal path to use ehci_get_desc_addr() when
following link pointers.
Appendix B also defines high dword fields for iTD buffer pointers.
Add bufptr_hi[7] to EHCIitd and use ehci_get_buf_addr() to construct
full 64-bit buffer addresses from bufptr[] and bufptr_hi[] fields
when processing isochronous transfers. This allows buffers above
4GB to be handled correctly.
When 64-bit capability is disabled, descriptor and buffer addresses
remain 32-bit and existing behaviour is unchanged.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260713032704.3583103-6-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
EHCI supports 64-bit addressing when the 64-bit Addressing Capability
bit in HCCPARAMS is set. In that mode, the CTRLDSSEGMENT register
provides the upper 32 bits that are concatenated with 32-bit link
pointer values to form 64-bit control data structure addresses
(EHCI 1.0, section 2.3.5 and Appendix B).
qTD link pointers (current_qtd/next_qtd/altnext_qtd and qTD.next)
are stored as 32-bit values in the data structures and must be
expanded to full 64-bit descriptor addresses when 64-bit mode is
enabled. Update the qTD traversal paths to use ehci_get_desc_addr()
when following link pointers.
Appendix B also defines high dword fields for qTD buffer pointers.
Add bufptr_hi[5] to EHCIqtd and extend qTD fetch and QH overlay
handling to load and propagate the high buffer pointer fields.
When 64-bit capability is disabled, descriptor and buffer addresses
remain 32-bit and existing behaviour is unchanged.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260713032704.3583103-5-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
EHCI supports 64-bit control data structure addressing when the
64-bit Addressing Capability bit in HCCPARAMS is set. In that mode,
the CTRLDSSEGMENT register supplies the upper 32 bits which are
concatenated with 32-bit link pointer fields to form full 64-bit
descriptor addresses (EHCI 1.0, section 2.3.5 and Appendix B).
The current implementation assumes 32-bit QH descriptor addresses
and directly uses link pointer values without applying the
CTRLDSSEGMENT upper dword.
Introduce a helper, ehci_get_desc_addr(), to construct full 64-bit
descriptor addresses when 64-bit capability is enabled. Update QH
traversal paths (async list walk, horizontal QH link, and periodic
schedule entry handling) to use the translated 64-bit addresses.
EHCI 64-bit buffer pointer fields are defined in Appendix B as
split 32-bit low/high parts located at separate offsets, rather
than a single contiguous 64-bit field. Therefore, the buffer
pointers cannot be represented as uint64_t bufptr[5] without
violating the descriptor layout defined by the specification.
Introduce ehci_get_buf_addr() to construct full 64-bit buffer
addresses from bufptr[] and bufptr_hi[] fields. Use this helper
when calculating transfer buffer addresses so that data buffers
above 4GB are correctly handled.
Also add bufptr_hi[5] to EHCIqh to support 64-bit buffer pointer
fields as defined in Appendix B.
When 64-bit capability is disabled, descriptor addresses remain
32-bit and existing behaviour is unchanged.
Note: Similar split 64-bit buffer pointer handling is required for
qTD, iTD and siTD descriptors, which will be addressed in follow-up
changes.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260713032704.3583103-4-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Introduce a new boolean property, "caps-64bit-addr", to control
HCCPARAMS[0] (64-bit Addressing Capability).
When enabled, the EHCI controller advertises support for 64-bit
address memory pointers as defined in the EHCI specification
(Table 2-7, HCCPARAMS). This allows software to use the 64-bit
data structure formats described in Appendix B.
When disabled (default), the controller reports 32-bit addressing
capability and uses the standard 32-bit data structures.
The EHCI CTRLDSSEGMENT register provides the upper 32 bits [63:32] used to
form 64-bit addresses for EHCI control data structures. Per EHCI 1.0
spec section 2.3.5, when the HCCPARAMS 64-bit Addressing Capability bit
is zero, CTRLDSSEGMENT is not used: software cannot write it and reads
must return zero.
Add a capability check in the operational register write handler and
reject guest writes to CTRLDSSEGMENT when 64-bit addressing is
not enabled.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260713032704.3583103-3-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Change internal EHCI descriptor addresses from uint32_t to uint64_t.
The following fields are updated:
- EHCIPacket::qtdaddr
- EHCIQueue::{qhaddr, qtdaddr}
- EHCIState::{a_fetch_addr, p_fetch_addr}
Update get_dwords() and put_dwords() to take 64-bit addresses and
propagate the type change through the descriptor traversal paths.
Adjust NLPTR_GET() to operate on 64-bit values:
#define NLPTR_GET(x) ((x) & ~0x1fULL)
so that link pointer masking works correctly when descriptor
addresses exceed 32-bit space. The previous mask (0xffffffe0)
implicitly truncated addresses to 32 bits.
This patch does not change the on-wire descriptor layout yet.
It only removes the internal 32-bit address limit and prepares
for later patches that will add full 64-bit QH/qTD/iTD/siTD support.
Update the EHCI trace-events prototypes for QH, qTD, iTD, and siTD to
use uint64_t for the address argument and print it with PRIx64. This
ensures full 64-bit addresses are shown in trace output and improves
debugging of queue heads and transfer descriptors.
Migration compatibility:
To preserve backward migration compatibility, keep the legacy 32-bit
fetch address fields (a_fetch_addr_32, p_fetch_addr_32) alongside the
new 64-bit fields.
Migration format is selected using a machine compat property
"x-migrate-fetch-addr-64bit":
- Old machine types migrate 32-bit fetch addresses
- New machine types migrate full 64-bit fetch addresses
This is implemented using VMSTATE_UINT32_TEST() and
VMSTATE_UINT64_TEST() so that only the appropriate format is migrated.
In pre_save, the 32-bit shadow fields are populated when migrating
to old machine types. In post_load, the 32-bit values are restored
into the 64-bit fields when loading old migration streams.
No functional change.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260713032704.3583103-2-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add missing Kconfig optional dependencies to avoid the
following runtime error:
qemu-system-aarch64: -device loader,force-raw=on,addr=0x400000000,file=./u-boot.bin: 'loader' is not a valid device model name
qemu-system-aarch64: -device e1000e,netdev=net1,bus=pcie.2: 'e1000e' is not a valid device model name
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260709164103.37614-4-philmd@oss.qualcomm.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add the missing Kconfig dependency on PCIE_PORT to avoid the
following runtime error:
Type 'aspeed.pcie-root-port' is missing its parent 'pcie-root-port-base'
No need to have ASPEED_SOC select PCI_EXPRESS since it is
already selected by PCI_EXPRESS_ASPEED.
Cc: qemu-stable@nongnu.org
Fixes: 2af56518fa ("hw/pci-host/aspeed: Add AST2600 PCIe Root Port and make address configurable")
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260709164103.37614-2-philmd@oss.qualcomm.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Fixes for these two bugs:
* short-circuited packets with `cmpy(Rs,Rt)` would get the wrong result
when Rs is the same register as Rt.
* some packets with slot constraints were incorrectly rejected as having
an invalid encoding/shuffle.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPWaq5HRZSCTIjOD4GlSvuOVkbDIFAmp0/fkACgkQGlSvuOVk
bDLMNBAAyqvEkchJfhrvAgY6kOkf4z9SoC8dQedyw26S3rtmjWFH8rBIQC1WYenc
O+bOfGW1apv9VpNr+8BsX9WIBfNF6yNVCu6+RxoG0/A2JOD09T7q7+vfJAKJXXk9
d0c8plnMBa0waqIwl1Pn+JIzcYBwVgqQkBAlY9BVbmtpBuf8GW9IctJcJpst9huP
9pyY8UNo6THvstPKB1d7dwNu+/35+QDuF2j9OI7ueY0kft7PmRn02sJBmgslhkx2
KPTjgyNT1jYR2y+jLXJfJUQHuJPn0pwW6QkoPB1P9zghxBjbGlETK8fxFZBuZGL7
y/c003GHsNBOhDj2fzrPfrh8foIg132ldkbV4+h4Ybpz/TPa/3aKhpfDm7wNTTHA
mQW17HZ5j9Zp3PzEL1JmZA8Ek5pFBFQSnsxwEo0eMb6ZjNjsZzaqO0rpJ0iZ3kPT
P889exq0A6qMT8v/o04R9r258VFnuiifBJNkEdQohQfNOKO+N/LcpSlvsaVR9Rid
i5/ikTlPOlFm8AvgRa37KOF7m+jzp7brvEreKtlhmeaQv5Oox2F4fBsEo6WWVA5R
xzjpTrdstc8l5NwY1iZEe2LexgcO0kxGvteFciFvwWSZ++91nl6/a99Nts06AfHc
p8Cor5pzeOfKZBbECbTnp8BGwDY+CCpo0Mg0Bsuupfj/kb/uYxQ=
=OpJQ
-----END PGP SIGNATURE-----
Merge tag 'hex-20260806-pull-request' of https://github.com/qualcomm/qemu into staging
hexagon: fix cmpy*(), same-slot packets
Fixes for these two bugs:
* short-circuited packets with `cmpy(Rs,Rt)` would get the wrong result
when Rs is the same register as Rt.
* some packets with slot constraints were incorrectly rejected as having
an invalid encoding/shuffle.
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEPWaq5HRZSCTIjOD4GlSvuOVkbDIFAmp0/fkACgkQGlSvuOVk
# bDLMNBAAyqvEkchJfhrvAgY6kOkf4z9SoC8dQedyw26S3rtmjWFH8rBIQC1WYenc
# O+bOfGW1apv9VpNr+8BsX9WIBfNF6yNVCu6+RxoG0/A2JOD09T7q7+vfJAKJXXk9
# d0c8plnMBa0waqIwl1Pn+JIzcYBwVgqQkBAlY9BVbmtpBuf8GW9IctJcJpst9huP
# 9pyY8UNo6THvstPKB1d7dwNu+/35+QDuF2j9OI7ueY0kft7PmRn02sJBmgslhkx2
# KPTjgyNT1jYR2y+jLXJfJUQHuJPn0pwW6QkoPB1P9zghxBjbGlETK8fxFZBuZGL7
# y/c003GHsNBOhDj2fzrPfrh8foIg132ldkbV4+h4Ybpz/TPa/3aKhpfDm7wNTTHA
# mQW17HZ5j9Zp3PzEL1JmZA8Ek5pFBFQSnsxwEo0eMb6ZjNjsZzaqO0rpJ0iZ3kPT
# P889exq0A6qMT8v/o04R9r258VFnuiifBJNkEdQohQfNOKO+N/LcpSlvsaVR9Rid
# i5/ikTlPOlFm8AvgRa37KOF7m+jzp7brvEreKtlhmeaQv5Oox2F4fBsEo6WWVA5R
# xzjpTrdstc8l5NwY1iZEe2LexgcO0kxGvteFciFvwWSZ++91nl6/a99Nts06AfHc
# p8Cor5pzeOfKZBbECbTnp8BGwDY+CCpo0Mg0Bsuupfj/kb/uYxQ=
# =OpJQ
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 06 Aug 2026 17:34:49 EDT
# gpg: using RSA key 3D66AAE474594824C88CE0F81A54AFB8E5646C32
# gpg: Good signature from "Brian Cain (OSS Qualcomm) <brian.cain@oss.qualcomm.com>" [unknown]
# gpg: aka "Brian Cain <bcain@kernel.org>" [unknown]
# gpg: aka "Brian Cain (QuIC) <bcain@quicinc.com>" [unknown]
# gpg: aka "Brian Cain (CAF) <bcain@codeaurora.org>" [unknown]
# gpg: aka "bcain" [unknown]
# gpg: aka "Brian Cain (QUIC) <quic_bcain@quicinc.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: 6350 20F9 67A7 7164 79EF 49E0 175C 464E 541B 6D47
# Subkey fingerprint: 3D66 AAE4 7459 4824 C88C E0F8 1A54 AFB8 E564 6C32
* tag 'hex-20260806-pull-request' of https://github.com/qualcomm/qemu:
target/hexagon: don't let an idef-parser dest clobber its own source
tests/tcg/hexagon: add slot-assignment tests
target/hexagon: accept valid packets rejected by check
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Three important small signal handling fixes for the sh4 architecture from
Mikulas Patocka.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCanXdBQAKCRD3ErUQojoP
X09PAP4winoHrCRXxCb9+P377se13P1W3b/bYmf5ju/Ptb5QTwD8C4/No2NGQBjY
6y7skdLtRn5Ztc7BOla2cTMpBUuy9wI=
=qH5w
-----END PGP SIGNATURE-----
Merge tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa into staging
linux-user sh4 signal patches
Three important small signal handling fixes for the sh4 architecture from
Mikulas Patocka.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCanXdBQAKCRD3ErUQojoP
# X09PAP4winoHrCRXxCb9+P377se13P1W3b/bYmf5ju/Ptb5QTwD8C4/No2NGQBjY
# 6y7skdLtRn5Ztc7BOla2cTMpBUuy9wI=
# =qH5w
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 07 Aug 2026 09:26:29 EDT
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: aka "Helge Deller <deller@debian.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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa:
linux-user/sh4: Fix crashes on signal delivery in conditional delay slot
linux-user/sh4: Initialize the FPSCR register on signal
linux-user/sh4: Deliver SIGILL on invalid instruction
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Allow mapping guest with 2G hugepages on hosts that support it.
Rename kvm_s390_get_hpage_1m() to kvm_s390_get_hpage() to reflect that
it is not anymore limited only to 1m hpages.
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260805103728.97602-2-imbrenda@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
STORE CLOCK [FAST] to an inaccessible address aborts QEMU:
$ qemu-s390x ./stckf
ERROR:cc_helper.c:128:cc_calc_addu: assertion failed: (carry_out <= 1)
op_stck() sets the condition code with gen_op_movi_cc() before the
output operand store, which is deferred to wout_m1_64(). Assigning a
constant condition code discards the lazy CC values, so the optimizer
drops the writes that produced them. When the store then raises an
exception, the instruction is suppressed and
s390x_restore_state_to_opc() reinstates the cc_op recorded at the start
of STCK[F], but cc_src/cc_dst now hold stale values, so the next
condition code evaluation reads garbage.
Fix by performing the store manually. The alternative of not discarding
in gen_op_movi_cc() keeps the inputs live, but results in less optimal
code.
Reported-by: Ido Plat <Ido.Plat1@ibm.com>
Fixes: 434c91a5f4 ("target-s390: Convert STCK")
Cc: qemu-stable@nongnu.org
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260714203206.363028-2-iii@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
The loadparm may optionally be used to select a boot entry, with the
intended range being 0 through 31 inclusive, for a total of 32 entries.
Previously, MAX_BOOT_ENTRIES was defined as 31, indicating that it was
intended to correspond to the index of the boot entry rather than the
count; however, some guards also used MAX_BOOT_ENTRIES as a count of the
maximum allowed entries, which resulted in a mismatch between the intended
and actual range such that index 31 could never be used in practice.
Move the definition of MAX_BOOT_ENTRIES to qipl.h so it is shared and
change the value to 32, representing a count of the maximum number of
allowed boot entries and allowing the loadparm to accept values 0 through
31 as intended. Update some instances in the netboot code where
MAX_BOOT_ENTRIES was used as the max index so that all guards treat
MAX_BOOT_ENTRIES as a count across all boot methods.
Cc: qemu-stable@nongnu.org
Fixes: 806315279d ("pc-bios/s390-ccw: Remove panics from ECKD IPL path")
Signed-off-by: Jared Rossi <jrossi@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260728223013.4047042-1-jrossi@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
menu_get_zipl_boot_index() calls strlen() on a pointer into the middle
of _s2 with no upper bound, so a stage-2 image whose blocks contain no
NUL bytes causes strlen() to walk beyond _s2. The resulting length
is then used to size a stack VLA in zipl_print_entry(), risking a stack
overflow.
Fix by:
- Implementing strnlen(), a bounded version of strlen(). s390-ccw uses
libc from SLOF, which includes strlen() but does not have an
implementation of strnlen(), so we must implement our own.
- Adding a menu_data_end parameter to menu_get_zipl_boot_index() and
replacing both strlen() calls with strnlen() bounded by the remaining
buffer space. The loop guard also checks that the pointer has not
reached menu_data_end. The function returns 0 (boot default) if
somehow menu_data reaches menu_data_end before printing any entries.
- Replacing the VLA char buf[len + 2] in zipl_print_entry() with a fixed
ZIPL_ENTRY_MAX + 2 (82-byte) buffer and truncating len before use.
- Passing s2_end (_s2 + sizeof(_s2)) as menu_data_end at the one call
site in eckd_get_boot_menu_index(), so the bound is exactly the end of
the buffer.
Fixes: f717891084 ("s390-ccw: print zipl boot menu")
Cc: qemu-stable@nongnu.org
Signed-off-by: Joshua Daley <jdaley@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260728134704.2924005-2-jdaley@linux.ibm.com
[farman@linux.ibm.com: Per list, add strnlen rationale to commit message
and added cc stable]
Signed-off-by: Eric Farman <farman@linux.ibm.com>
menu_get_zipl_boot_index() iterates NUL-separated strings from the
zipl stage-2 boot-menu block, passes each to zipl_print_entry() which
converts EBCDIC to ASCII and returns atoi(), then writes true into
valid_entries[entry]. valid_entries is a MAX_BOOT_ENTRIES element
stack array, but entry was never bounds-checked, so a crafted on-disk
value could index arbitrarily beyond the array.
Fix this in two places:
- zipl_print_entry() now validates that the first significant character
(after an optional leading space) is a digit. Entries that fail this
check return -1 without printing.
- menu_get_zipl_boot_index() skips any entry whose index is outside
[0, MAX_BOOT_ENTRIES) before writing to valid_entries[].
Fixes: 7385e947fc ("pc-bios/s390-ccw: fix non-sequential boot entries (eckd)")
Cc: qemu-stable@nongnu.org
Signed-off-by: Joshua Daley <jdaley@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260727115052.24289-5-borntraeger@linux.ibm.com
[farman@linux.ibm.com: Added qemu-stable]
Signed-off-by: Eric Farman <farman@linux.ibm.com>
In the dir_rem[level] == 0 case, level is decremented, then
a virtio_read() is issued on sec_loc[level]. If level is -1, then the
4 bytes before the static sec_loc array are read, and the virtio_read()
is issued on that garbage block number.
Guard the call to virtio_read() against the value of level to prevent
this.
Fixes: 869648e87e ("pc-bios/s390-ccw: El Torito 16-bit boot image size field workaround")
Cc: qemu-stable@nongnu.org
Signed-off-by: Joshua Daley <jdaley@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260727115052.24289-4-borntraeger@linux.ibm.com
[farman@linux.ibm.com: Fixed typo on Christian's tag, added qemu-stable]
Signed-off-by: Eric Farman <farman@linux.ibm.com>
In ipl_valid_pv_components(), the upper bound of the for loop,
ipib_pv->num_comp, is read from guest memory. Before iterating, verify
that its value will not cause a read beyond the end of the
IplParameterBlock.
Fixes: c3347ed0d2 ("s390x: protvirt: Support unpack facility")
Cc: qemu-stable@nongnu.org
Signed-off-by: Joshua Daley <jdaley@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260727115052.24289-3-borntraeger@linux.ibm.com
[farman@linux.ibm.com: Added qemu-stable]
Signed-off-by: Eric Farman <farman@linux.ibm.com>
If a guest uses incorrect message length it can trigger an assert in
process_mdb which kills the guest instead of reporting an error. Fix
this by adding the correct length check.
Fixes: 6a444f8507 ("s390/sclplmconsole: Add support for SCLP line-mode console")
Cc: qemu-stable@nongnu.org
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260727115052.24289-2-borntraeger@linux.ibm.com
[farman@linux.ibm.com: Fixed typo in commit message, added qemu-stable]
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Check that DR with a non-representable quotient raises SIGFPE rather than
crashing the emulator.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260714190351.337923-3-iii@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
helper_divs32() divides the 64-bit dividend by the 32-bit divisor as a 64-bit
host operation, guarding only against a zero divisor. INT64_MIN / -1 therefore
overflows the host division before the representability check runs; on hosts
that trap this, QEMU is killed with SIGFPE instead of raising the
fixed-point-divide exception the guest expects:
qemu-s390x: QEMU internal SIGFPE {code=INTDIV, addr=...}
helper_divs64() already guards the same case; add the missing check to
helper_divs32().
Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Fixes: b4e2bd3563 ("target-s390: Send signals for divide")
Cc: qemu-stable@nongnu.org
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260714190351.337923-2-iii@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Add a small test that issues a large PRNO TRNG request while a timer is
running, and checks that the timer interrupts it several times.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260714191948.342204-3-iii@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
fill_buf_random() writes the entire guest-requested amount of random
bytes in one go. Since the length is a full 64-bit value, a guest can
request several gigabytes and keep the vCPU spinning inside the helper,
without a chance to react to interrupts.
Do the same thing as HELPER(mvcl): check cpu_loop_exit_requested() at the
bottom of the loop, and when a return to the main loop is pending, stop
and report partial completion with condition code 3.
Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Fixes: 3dbc5fdacb ("target/s390x: support PRNO_TRNG instruction")
Cc: qemu-stable@nongnu.org
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260714191948.342204-2-iii@linux.ibm.com
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Write an NT_FPREGSET note for RISC-V, matching struct __riscv_d_ext_state
from uapi/asm/ptrace.h: f0-f31 as 64-bit values followed by fcsr.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Write an NT_FPREGSET note for MIPS and MIPS64, matching the kernel's
elf_fpregset_t layout (ELF_NFPREG = 33): fpr[0..31] hold f0-f31, and
fcsr occupies the low 32 bits of slot 32. The pad field rounds the
struct to 33 × 8 bytes = 264 bytes.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
A guest core carried only the general-purpose registers, so a debugger
opening one reported every floating-point register as unavailable --
including the arguments of the function that crashed.
Implement HAVE_ELF_CORE_FPREGS for Alpha: define target_elf_fpregset_t
to match the kernel's layout ($f0-$f30 plus the control register in the
slot $f31 would occupy) and fill it from elf_core_copy_fpregs().
Checked with lldb on a core from a program that faults with live values
in $f16 and $f17: both read back correctly, as does the control register.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Write an NT_FPREGSET note for targets that opt in: a target_elf.h that
defines HAVE_ELF_CORE_FPREGS and target_elf_fpregset_t, and supplies an
elf_core_copy_fpregs() beside the existing elf_core_copy_regs().
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
kvm_get_msrs() adds U_CET and S_CET when CET shadow stacks or IBT are
enabled, but it checks FEAT_7_0_EDX with the ECX-defined
CPUID_7_0_ECX_CET_SHSTK bit before adding the PL0-PL3 SSP MSRs.
CPUID_7_0_ECX_CET_SHSTK belongs to FEAT_7_0_ECX. The current check
therefore skips MSR_IA32_PL0_SSP through MSR_IA32_PL3_SSP even when
guest shadow stacks are enabled.
kvm_put_msrs() already uses FEAT_7_0_ECX for the same shadow-stack
condition. Use the same feature word in kvm_get_msrs() so QEMU does
not restore CET enablement with stale or zero SSP values.
Fixes: b6f85c5e45 ("i386/kvm: Add save/restore support for CET MSRs")
Cc: qemu-stable@nongnu.org
Signed-off-by: Saul Freedman <fre3dm4n@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260615033338.1563854-1-fre3dm4n@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
mount_setattr() was in the syscall tables but had no implementation, so
guests always got -ENOSYS. systemd uses it when setting up per-unit
credential mounts, which fails the affected units with EXIT_CREDENTIALS.
struct mount_attr is an extensible struct like open_how, so handle it the
same way openat2() does: reject sizes smaller than the ver0 struct and
require any unknown trailing bytes to be zero. All of its fields are
64-bit, and the MOUNT_ATTR_* and MS_* propagation values are identical on
every target, so only the byte order needs fixing up.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
If we get a signal in the delay slot, we must roll-back the PC to the
jump instruction. This was already fixed by the commit 3b894b699c
("linux-user/sh4: Fix crashes on signal delivery"), however this fix
omits a test for TB_FLAG_DELAY_SLOT_COND. TB_FLAG_DELAY_SLOT_COND is set
by the conditional delayed branches bf/s and bt/s. Qemu did not roll-back
the PC in this case, resulting in incorrect program execution.
This patch fixes it.
Cc: qemu-stable@nongnu.org
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Yoshinori Sato <yoshinori.sato@nifty.com>
Signed-off-by: Helge Deller <deller@gmx.de>
On the SH4 architecture, the instructions that perform single precision
and double precision floating point operations are encoded in the same
way. The bit PR in the FPSCR register determines if the CPU performs
single or double operation.
According to the ABI, the PR bit must be set at function entry and
function exit.
GCC generates code that flips this bit as needed during function
execution. If we get a signal, we must set the PR bit, so that the signal
handler finds the bit in the expected state. Qemu lacked this logic, so
that if the signal interrupts single-precision floating point
calculation, the PR bit would be incorrectly clear at signal handler
entry. If the signal handler performed some floating-point calculation,
it would get incorrect result.
This patch fixes the bug, by initializing the FPSCR register at signal
entry. Note that we initialize the whole register, because the Linux
kernel initializes the whole register too.
Cc: qemu-stable@nongnu.org
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Yoshinori Sato <yoshinori.sato@nifty.com>
Signed-off-by: Helge Deller <deller@gmx.de>
On invalid instruction, deliver SIGILL rather than crashing the whole
process unconditionally.
Cc: qemu-stable@nongnu.org
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Yoshinori Sato <yoshinori.sato@nifty.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Helge Deller <deller@gmx.de>
The idef-parser emitters write the destination in place, so when a packet
is short-circuited and get_result_gpr() returns hex_gpr[] itself, an
instruction naming one register as both source and destination reads back
a value it already overwrote.
`Rd32=cmpy(Rs32,Rt32):<<1:rnd:sat` with Rs == Rd is an example.
Give a source reg that aliases a destination its own copy of the
register value.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
valid-slots: packets that legally share a slot and were wrongly
rejected before the fix (load and transfer, load encoded first;
dczeroa packed last with three transfers).
invalid-slots: unassignable packets that must still be rejected:
store + duplex, load + indirect jump, three logical ops competing for
slots 2 and 3, and five ops for four slots.
Reviewed-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
has_valid_slot_assignment() rejected any packet with two instructions
assigned to the same slot. That is too strict. When a memory
instruction is encoded before a slot-flexible instruction in a packet,
the descending slot assignment places the memory op in slot 1 and the
other in slot 0, then the "mem insns to slot 0" fixup moves the memory
op to slot 0 as well, leaving both in slot 0. Such a packet is valid
and executes correctly, but the uniqueness test flagged it as
HEX_CAUSE_INVALID_PACKET, raising SIGILL in linux-user and a precise
exception in system mode.
For example this packet, with the load encoded first, was wrongly
rejected:
{ r6 = memw(r3+#-4)
r7 = #0x4ae6 }
Replace the uniqueness test with a slot-exhaustion check: walk the
instructions in encoding order handing out slots in strictly decreasing
order and fail only if an instruction has no valid slot at or below the
running slot. This accepts packets that legally share a slot while
still rejecting genuinely unassignable packets, such as a memory
instruction grouped with a duplex, or a load followed by an instruction
that requires a high slot.
Reviewed-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
- Fix missing locking in latency histogram setters
- coroutine: fix lost wakeup in qemu_co_sleep_wake()
- floppy: Fix READ/WRITE/FORMAT/READ ID behaviour with missing medium
- qcow2: Fix crash on closing a read-only image with dirty bit set
- cloop: fix integer overflow in total_sectors calculation
- dmg: Fix out of bounds accesses (CVE-2026-65929, CVE-2026-65928)
- FUSE export: fix regression with O_TRUNC when export is not growable
- iotests: Various small fixes
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmpx+c4RHGt3b2xmQHJl
ZGhhdC5jb20ACgkQfwmycsiPL9YB1A/7BBA88fhvpA1E/X+1DGpjFyAJbssRVWxq
OuKgpvVgm1EZHIl/ST5scOm971h3e4zXQLVERY0nY30wMl5mZVXrFMHOLdqP+1rv
dPjqHwgiBp+YOP3Ol2EHaObDta+bf5GM3DZ6naAHdK0Zdxqywo0qsrKwHpSG2NhG
uEWanrZC0SsaZ5sUmVdwYp8SA6iW1RtvS23kgP4szSIy6jYoFYcZYKv5AcitohCq
HejMiLcoDcqPKy1l4CnqypsNEW+SyabG2Zr0IkRattM7It2Vq+bswRuo4tKRjn2I
TBldmMiBIhW8txV3u6DglR02pXThSVhxFZV3O9DSntCii4rubz7smvqR1X3pmknW
ERE4b4fvLAlzIrugMfvVNRVZpWLVdHqx+iu0wh3QvvCxZGMuCksQ+1Kr0ayi3IH/
cBcudetL9WnYVchMJRgwYDSahDvqgm7xiMGU1X1dAjfb4LKlmVAccuuUy0iHsg/p
mSBrnxWpABIQgwN+rhUeWMLo6faVUpf5GUmfT/EwyMNrOhCo4K+qfR17S+McJeYC
a1nxUbLUKdkAFX31bTmEIQlp+395RGh1o0UGOrrQUW8pRZgAQqBCitRRmEXZiOmD
PNNeCZS1wyWMbSz0R19/vpp/uwPmMBakN/QxWmY+H3nHUrKEnZGmtPZlJGFoam+m
9qHJno8c2Ak=
=2bLV
-----END PGP SIGNATURE-----
Merge tag 'for-upstream' of https://gitlab.com/kmwolf/qemu into staging
Block layer patches
- Fix missing locking in latency histogram setters
- coroutine: fix lost wakeup in qemu_co_sleep_wake()
- floppy: Fix READ/WRITE/FORMAT/READ ID behaviour with missing medium
- qcow2: Fix crash on closing a read-only image with dirty bit set
- cloop: fix integer overflow in total_sectors calculation
- dmg: Fix out of bounds accesses (CVE-2026-65929, CVE-2026-65928)
- FUSE export: fix regression with O_TRUNC when export is not growable
- iotests: Various small fixes
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmpx+c4RHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9YB1A/7BBA88fhvpA1E/X+1DGpjFyAJbssRVWxq
# OuKgpvVgm1EZHIl/ST5scOm971h3e4zXQLVERY0nY30wMl5mZVXrFMHOLdqP+1rv
# dPjqHwgiBp+YOP3Ol2EHaObDta+bf5GM3DZ6naAHdK0Zdxqywo0qsrKwHpSG2NhG
# uEWanrZC0SsaZ5sUmVdwYp8SA6iW1RtvS23kgP4szSIy6jYoFYcZYKv5AcitohCq
# HejMiLcoDcqPKy1l4CnqypsNEW+SyabG2Zr0IkRattM7It2Vq+bswRuo4tKRjn2I
# TBldmMiBIhW8txV3u6DglR02pXThSVhxFZV3O9DSntCii4rubz7smvqR1X3pmknW
# ERE4b4fvLAlzIrugMfvVNRVZpWLVdHqx+iu0wh3QvvCxZGMuCksQ+1Kr0ayi3IH/
# cBcudetL9WnYVchMJRgwYDSahDvqgm7xiMGU1X1dAjfb4LKlmVAccuuUy0iHsg/p
# mSBrnxWpABIQgwN+rhUeWMLo6faVUpf5GUmfT/EwyMNrOhCo4K+qfR17S+McJeYC
# a1nxUbLUKdkAFX31bTmEIQlp+395RGh1o0UGOrrQUW8pRZgAQqBCitRRmEXZiOmD
# PNNeCZS1wyWMbSz0R19/vpp/uwPmMBakN/QxWmY+H3nHUrKEnZGmtPZlJGFoam+m
# 9qHJno8c2Ak=
# =2bLV
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 04 Aug 2026 10:40:14 EDT
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* tag 'for-upstream' of https://gitlab.com/kmwolf/qemu:
iotests: increase timeouts for tests to 5 minutes
hw/block/fdc: report a missing address mark on an empty drive
hw/block/fdc: select the drive named by the READ ID command
iotests: test O_TRUNC behavior for fuse exports
block/export/fuse: fix regression with O_TRUNC when export is not growable
coroutine: fix lost wakeup in qemu_co_sleep_wake()
iotests/migrate-bitmaps-postcopy-test: replace the timing assertion with a content check
iotests: skip FUSE tests when FUSE is not usable
iotests: run the test pool with the 'fork' start method
qcow2: do not try to clear the dirty bit on a read-only node
dmg: reject inconsistent UDRW chunk sector count and length (CVE-2026-65928)
dmg: refuse to open files with no chunks
dmg: fix out-of-bounds load in search_chunk() (CVE-2026-65929)
tests/unit: add reproducer for BlockAcctStats histogram locking race
block/qapi: take stats->lock when reading BlockAcctStats for query-blockstats
block/accounting: take stats->lock in latency histogram setters
block/cloop: fix integer overflow in total_sectors calculation
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
QEMU's CI pipeline involves building container images that will be used
to run builds and tests. A recent Docker change triggered the following
error:
$ docker push "$TAG"
...
error from registry: blob unknown to registry - sha256:4401f6f779caf8841cafd5f483e642fcac56a23a4e4a59523231e101c890dad9
https://gitlab.com/qemu-project/qemu/-/jobs/15701875927#L2372
This happens because Docker now pushes out-of-order and the GitLab
Container Registry rejects due to an unknown reference:
https://forum.gitlab.com/t/started-yesterday-docker-push-error-from-registry-blob-unknown-to-registry/134733/5
It is unclear at this point whether GitLab will modify the behavior of
Container Registry or whether Docker will ship a fix.
The current workaround is to disable the provenance attestation that is
involved in this issue. QEMU's CI pipeline container images are used
internally for testing and are not widely distributed. Provenance
attestation can be disabled as there are no external consumers of these
images. Expect to revert this commit in the future when GitLab or Docker
have released their own fixes.
Cc: Alex Bennée <alex.bennee@linaro.org>
Cc: Daniel P. Berrangé <berrange@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260804165414.480435-1-stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Commit 1c0e259c5a ("dump: make win_dump_available() check vmcoreinfo
for a Windows dump header") changed two things in a way that is visible
to QMP clients but not to introspection:
query-dump-guest-memory-capability now lists win-dmp only for a guest
that has published a Windows dump header through the vmcoreinfo device,
and dump-guest-memory, which shares win_dump_available(), rejects the
format otherwise. Before that, both accepted win-dmp on any x86
machine.
A client that wants to select win-dmp automatically therefore cannot
trust the capability query on its own: on an older QEMU it reports
win-dmp for every x86 guest, Linux ones included, where the resulting
dump is useless. libvirt ran into exactly this while picking a format
for on_crash and watchdog triggered dumps, and has no way to tell the
two behaviours apart.
Add an 'allowed-by-guest' feature to the win-dmp member of
DumpGuestMemoryFormat so the fixed behaviour becomes discoverable.
DumpGuestMemoryFormat is reachable from both
query-dump-guest-memory-capability's return type and
dump-guest-memory's arguments, so a single flag covers both halves of
the change. Where the feature is absent, a reported win-dmp says
nothing about the guest, and a client that needs the dump to be
loadable afterwards should fall back to elf.
CC: Eric Blake <eblake@redhat.com>
CC: Markus Armbruster <armbru@redhat.com>
CC: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260731155001.1204103-1-den@openvz.org>
virtio_gpu_reset() freed in-flight commands without unmapping the
DMA regions acquired by virtqueue_pop(). Call virtqueue_detach_element()
before g_free() in both drain loops.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3467
Cc: qemu-stable@nongnu.org
Signed-off-by: Bin Guo <guobin@linux.alibaba.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260803082158.62998-1-guobin@linux.alibaba.com>
virtio-gpu does not consistently check scanout bounds with wraparound
handling. In the unchecked virgl SET_SCANOUT path, guest dimensions
reach qemu_console_resize(), qemu_create_displaysurface(), and
ultimately qemu_pixman_image_new_shareable(..., &error_abort), so an
invalid rectangle can terminate QEMU. Implement a check with proper
wraparound handling and apply it consistently.
Fixes: 9d9e152136 ("virtio-gpu: add 3d mode and virgl rendering support.")
Fixes: 32db3c63ae ("virtio-gpu: Add virtio_gpu_set_scanout_blob")
Fixes: 7c092f17cc ("virtio-gpu: Handle resource blob commands")
Fixes: 1dcc6adbc1 ("gfxstream + rutabaga: add initial support for gfxstream")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260803-scanout-v1-1-c9831dafdab2@rsg.ci.i.u-tokyo.ac.jp>
A short control request can leave command data partially initialized.
For the common header, guest-controlled flags can then cause stale fence
metadata to be returned to the guest.
The command fill helpers detect a short copy but only log and return.
For the common header this leaves the request without any completion;
for type-specific commands the caller still completes the request but
reports VIRTIO_GPU_RESP_OK_NODATA, masking the error. Make
VIRTIO_GPU_FILL_CMD() clear the partially copied object and complete the
request with ERR_INVALID_PARAMETER. Make VUGPU_FILL_CMD() report the same
error through the existing vhost-user-gpu dispatcher. This also rejects
truncated type-specific commands.
The vhost-user-gpu common header is copied outside VUGPU_FILL_CMD(), so
clear it and complete the request directly when that copy is short.
Fixes: CVE-2026-18054
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4094
Reported-by: Ankur Saini <ankur98saini@gmail.com>
Suggested-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Ankur Saini <ankur98saini@gmail.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260803-virtio-gpu-short-header-v3-1-936c1daa8e61@gmail.com>
QAPI-generated list visitors guarantee that node->value is never NULL:
the input visitor allocates it via g_malloc0() in visit_start_struct(),
and on failure the entire list parse is aborted and freed.
Remove the unnecessary NULL checks from both callsites iterating
g->conf.outputs.
Resolves: Coverity CID 1664272
Fixes: 8dc8449a67 ("hw/display/virtio-gpu: Avoid leaking migration blocker")
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260730114751.3515083-1-marcandre.lureau@redhat.com>
virtio_gpu_scanout_blob_to_fb() computes the framebuffer offset from
guest-controlled offsets[0], r.x, r.y and stride using uint32_t
arithmetic. When the sum exceeds UINT32_MAX, silent wraparound lets
the guest steer the scanout to an arbitrary in-bounds region of the
blob instead of the intended rectangle.
Compute the offset in uint64_t, reject values exceeding UINT32_MAX
(the width of fb->offset), and only store into fb->offset once both
range checks pass.
("[PATCH] hw/display/virtio-gpu: Remove the bytes_pp field")
Fixes: 32db3c63ae ("virtio-gpu: Add virtio_gpu_set_scanout_blob")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3871
Based-on: <20260719-bpp-v1-1-9b91946d6cf3@rsg.ci.i.u-tokyo.ac.jp>
Reported-by: Cyber_black <Cyberblackk@proton.me>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260725122734.1775774-1-marcandre.lureau@redhat.com>
A malicious guest can trigger a heap buffer overflow in the
vhost-user-gpu backend by sending a VIRTIO_GPU_CMD_RESOURCE_CREATE_2D
with large width and height values (e.g. 65537x65537). The allocation
size width * height * 4 silently wraps in uint32_t arithmetic,
resulting in a much smaller allocation than expected. Subsequent
VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D writes past the heap buffer.
The in-tree virtio-gpu device (hw/display/virtio-gpu.c) already handles
this via calc_image_hostmem() with uint64_t arithmetic and an overflow
check. Apply the same approach to the vhost-user-gpu contrib backend:
- Add an overflow check in vugbm_buffer_create() rejecting dimensions
where width * height * 4 exceeds UINT32_MAX
- Promote the size arithmetic to uint64_t in mem_alloc_bo() and
udmabuf_get_size()
- Check the return value of vugbm_buffer_create() in
vg_resource_create_2d(), which was previously ignored
Fixes: CVE-2026-15264
Reported-by: "Vulnerability Report" <vr@darknavy.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3940
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
Acked-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260710134720.2317856-1-marcandre.lureau@redhat.com>
The fields last_width and last_height serve two purposes: the text
renderer counts in characters, the graphics renderer in pixels.
panning_buf reallocation is guarded by geometry-change check, so the
unit mismatch can trick it into thinking nothing changed when the
resolution actually grew.
A guest can trigger this by switching graphics -> text -> graphics:
1. Enter graphics mode with a small width (CR01=0x00, 8 pixels).
The predicate fires and panning_buf is allocated for that width.
2. Switch to text mode with a large width (CR01=0xFF, 256 chars).
The text renderer stores 256 into last_width. The text path
never touches panning_buf.
3. Switch back to graphics with a width that happens to equal 256
in pixels (CR01=0x1F, 32*8 = 256). The predicate sees
256 == 256 and skips the realloc. With horizontal pel panning
enabled, vga_draw_line4() then writes a full 256-pixel scanline
into the buffer still sized for 8 pixels -- a 960-byte heap
overflow on every scanline, every refresh.
Fix it by reallocating unconditionally panning_buf on
vga_draw_graphic().
Fixes: CVE-2026-17516
Fixes: 973a724eb0 ("vga: implement horizontal pel panning in graphics modes")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4085
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Warisjeet Singh <sinxx198@gmail.com>
[ Marc- André - drop realloc() resize condition & commit message ]
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260728151456.3704099-1-marcandre.lureau@redhat.com>
virtio_gpu_resource_create_blob() stores the guest-controlled blob_size
without checking it against the total size of the iov backing entries.
Since both values are independently guest-controlled, a malicious guest
can set blob_size much larger than the actual iov backing. Subsequent
SET_SCANOUT_BLOB checks bounds against the inflated blob_size, allowing
a pixman surface to be created over the undersized buffer. Any display
refresh then reads past the actual allocation, potentially crashing
QEMU or leaking host memory contents depending on the backing type.
Validate that the iov backing is at least as large as the declared
blob_size in create_blob (when nr_entries > 0, since the spec permits
deferred backing), attach_backing (when attaching to a blob resource),
and the blob migration load path.
Fixes: CVE-2026-66021
Fixes: e0933d91b1 ("virtio-gpu: Add virtio_gpu_resource_create_blob")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3945
Reported-by: "sundayjiang(蒋浩天)" <sundayjiang@tencent.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260729161431.1180691-1-marcandre.lureau@redhat.com>
Currently we have tests timeout set to 3 minutes, on the basis
that they're generally done in less than a minute. I've hit a
couple of random failures suggesting that's not sufficiently
pessimistic. Increase the timeout to 5 minutes to have a greater
safety net in high load scenarios.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260623160326.2346255-1-berrange@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
READ ID on a drive with no medium terminates normally and returns the
made-up sector ID left over from the "Pretend we are spinning" emulation.
The only error path is a data rate mismatch, and media_rate is assigned
solely by pick_geometry(); it is never reset when the medium is removed.
A guest that has just ejected a diskette is therefore told that one is
still present.
READ, WRITE and FORMAT have a related problem: fd_seek() answers 2 both
for "track/head out of range" and for "no medium", so the callers report
ST0 = ABNTERM with ST1 = 0x00 either way. Without ST1.MA the guest cannot
tell an absent diskette from a transient error. Give fd_seek() a return
code of its own for an absent medium, and let both switch statements
report the missing address mark for it.
The comments on the two switches were swapped: fd_seek() answers 2 for a
bad track or head and 3 for a sector past last_sect, but case 2 read
"sect too big" and case 3 "track too big". Both now say what they mean.
This is a behaviour change for FORMAT TRACK on an empty drive as well,
which now answers ST1.MA rather than ST1 = 0x00. None of the guests
tested reaches that path -- DOS gives up during media sensing and never
issues the command -- but it seemed wrong to leave fdctrl_format_sector()
falling through to "default" for a case fd_seek() now reports explicitly.
Failing READ ID does not make guests detect the removal: real hardware
never completes the command on an empty drive, because there are no index
pulses, and OS/2 for one relies on that timeout. It does stop the
controller from claiming a diskette that is not there.
tests/qtest/fdc-test.c starts QEMU with "-device floppy,id=floppy0" and
no medium, and test_read_id asserts a normal termination with a made-up
cylinder 8 / head 1. That contradicts its neighbours
test_no_media_on_start and test_media_change, which state that DSKCHG
signals an absent medium. Insert a medium before READ ID and eject it
afterwards -- the rewritten test passes before and after this change --
and add test_read_id_no_media for the empty drive.
Guests checked, reading and writing, with and without a medium: Linux
2.0.34 and 7.0, PC-DOS 7, IBM DOS 5.02, Windows for Workgroups 3.11 and
OS/2 2.11. None changes behaviour. No version of the Linux floppy driver
from 1.2.13 to master issues READ ID at all -- FD_READID is defined in the
uapi header for FDRAWCMD users and the driver never sends it -- so Linux
detects an empty drive by stepping the head and reading DSKCHG instead.
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/3971
Signed-off-by: Christian Quante <christian@quante.one>
Message-ID: <20260714164031.60551-3-christian@quante.one>
[kwolf: Added fd_seek() comment for new return value 5]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Every other command handler begins by latching the drive from the command
byte:
SET_CUR_DRV(fdctrl, fdctrl->fifo[1] & FD_DOR_SELMASK);
fdctrl_handle_readid() does not, so it works on whichever drive happened to
be selected last. A guest that issues READ ID for a drive other than the
one currently selected gets an answer about the wrong one.
It has gone unnoticed because a driver normally writes the DOR to spin up
the motor first, and that write selects the drive as a side effect. The
controller does not require it, though, and the command carries the drive
number for a reason.
Reported-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Christian Quante <christian@quante.one>
Message-ID: <20260714164031.60551-2-christian@quante.one>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The test cases for the blockdev-based export and for the file-based
export with growable=on work before commit a94a1d7699 ("fuse: Manually
process requests (without libfuse)"), then are broken until commit
"block/export/fuse: fix regression with O_TRUNC when export is
growable".
The test case for the blockdev-based export requires passwordless sudo
for losetup and chmod similar to test 108.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20260702132256.661429-3-f.ebner@proxmox.com>
[kwolf: Catch OSError when probing sudo support]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The buffer holding the ranges for the copy command is not correctly
deallocated.
Fix this.
Cc: qemu-stable@nongnu.org
Link: https://gitlab.com/qemu-project/qemu/-/work_items/4072
Fixes: 796d20681d ("hw/nvme: reimplement the copy command to allow aio cancellation")
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
nvme_ctrl_reset() freed every SQ/CQ right after nvme_ns_drain(), which
only waits out requests on a per-namespace BlockBackend. That is safe
as long as the guest first tore down I/O queues gracefully (Delete
I/O SQ/CQ), since nvme_del_sq() already cancels and waits for
anything left on a queue before freeing it.
A reset that happens without that graceful sequence first (e.g. an
abrupt/asynchronous controller reset) can still have commands
inflight on blk_aio_*. Freeing sq/cq before those complete leaves
their completion callbacks (nvme_rw_cb() and friends) to run against
already-freed NvmeRequest/NvmeSQueue/NvmeCQueue memory via
nvme_enqueue_req_completion(), causing a use-after-free/segfault.
Run nvme_sq_cancel_inflight() over every queue in nvme_ctrl_reset()
before the free loops, so no in-flight blk_aio_* callback can fire
after sq/cq memory is freed.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3398
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3883
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4068
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4072
Signed-off-by: Minwoo Im <minwoo.im@samsung.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Factor the cancel-and-wait loop used by nvme_del_sq() into
nvme_sq_cancel_inflight(), so it can be reused to drain queues on
controller reset.
Cc: qemu-stable@nongnu.org
Signed-off-by: Minwoo Im <minwoo.im@samsung.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
nvme_del_sq() asserted r->aiocb was always set when canceling a
queue's inflight requests. A pending Async Event Request has no
aiocb (nvme_aer() parks it without issuing any block I/O), so
deleting a queue with an outstanding AER trips the assert instead of
just dropping the request.
Cc: qemu-stable@nongnu.org
Signed-off-by: Minwoo Im <minwoo.im@samsung.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Before commit a94a1d7699 ("fuse: Manually process requests (without
libfuse)"), the O_TRUNC flag when open()-ing an export would be
ignored. This is because libfuse sets FUSE_CAP_ATOMIC_O_TRUNC, so the
kernel lets user space handle the O_TRUNC flag, which is ignored by
the fuse code for export. After the commit, FUSE_CAP_ATOMIC_O_TRUNC is
not set anymore, so the O_TRUNC flag is handled by the kernel, which
executes a truncate.
For blockdev-based exports, this causes a regression, because opening
with O_TRUNC would previously work, but results in an ENOTSUP after
commit a94a1d7699. For file-based exports, the fact that truncate is
executed can be considered an improvement in general. However, in
combination with growable=off, this still results in a practical
regression in combination with virt-fw-vars, which opens its output
file with O_TRUNC and previously worked with a file-based export with
growable=off. After commit a94a1d7699, the file is truncated upon open
and then cannot grow, meaning virt-fw-vars won't be able to write the
output.
To fix these regressions, while keeping the improved behavior for
file-based exports with growable=on, set the FUSE_CAP_ATOMIC_O_TRUNC
flag again if growable=off.
Cc: qemu-stable@nongnu.org
Fixes: a94a1d7699 ("fuse: Manually process requests (without libfuse)")
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20260702132256.661429-2-f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
cache_clean_timer_del_and_wait() cancels the cache-cleaner coroutine
by setting s->cache_clean_interval = 0 and calling qemu_co_sleep_wake()
to cut short its qemu_co_sleep_ns_wakeable(). qemu_co_sleep_wake() is
fire-and-forget: it reads w->to_wake and silently returns when it is
NULL. A sleeper that is between two iterations -- has just released
s->lock but has not yet set w->to_wake inside qemu_co_sleep() -- loses
the wake:
iothread0 timer coroutine main thread (qcow2 close)
------------------------- -------------------------
while-body (holding s->lock):
read interval = 600
wait_ns = 600 * NS
release s->lock
take s->lock
interval = 0
qemu_co_sleep_wake(w):
w->to_wake == NULL -> skip
return
qemu_co_queue_wait(exit, s->lock):
release s->lock
yield
qemu_co_sleep_ns_wakeable:
aio_timer_init(+600 s)
qemu_co_sleep:
cas scheduled NULL -> "qsns"
w->to_wake = co
yield [sleeps 600 s]
cache_clean_timer_del_and_wait() then blocks on cache_clean_timer_exit
until the original 600 s expiry fires, and qcow2_close() holds BQL the
whole time so the VM stalls behind it.
block_copy_kick() has the same shape. Fix the primitive once instead
of working around it in each caller.
Use a tri-state for QemuCoSleep::to_wake:
NULL - idle
co - sleeper parked
PENDING - wake delivered, no sleeper yet (sticky)
qemu_co_sleep_wake() xchgs PENDING into to_wake: a real sleeper is
woken, NULL/PENDING is left untouched so the wake stays sticky.
qemu_co_sleep() cmpxchg-publishes itself as the sleeper; if a wake
was delivered before it got there or races the publish, the cmpxchg
observes PENDING and returns without yielding. On normal resume
qemu_co_sleep() clears the PENDING the waker left behind so the next
sleep starts clean.
A double-fire (real wake plus timer callback) is harmless: the first
xchg returns the coroutine and wakes it; the second returns PENDING
and is a no-op. Cancellation latency through qemu_co_sleep_wake() is
now bounded by aio_co_wake() rather than by the sleep duration.
Fixes: f86dde9a15 ("qcow2: Fix cache_clean_timer")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Cc: Hanna Czenczek <hreitz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20260610115850.2410566-2-den@openvz.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
`downtime * 10 < postcopy_time` was an unnormalized wall-clock
heuristic (commit e80a4150a5) that fails on fast hosts, where the
bitmap payload now transfers in under a second.
Check the actual invariant instead: right after RESUME, bitmap0's
content hash on the destination must not yet match the fully
migrated value. Throttle max-bandwidth first, since all-zero chunks
skip the payload write and would otherwise let a fast host finish
the transfer before the check runs.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Hanna Reitz <hreitz@redhat.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20260715103451.1930909-4-den@openvz.org>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
file-io-error, fuse-allow-other and fuse-mmap-shared skip only when
FUSE is not compiled in. When FUSE is built in but unusable at run
time (no /dev/fuse access, fusermount lacking permissions), the
export fails to mount with "Failed to mount FUSE session to export"
and the tests report a spurious failure instead of skipping, like
NBD tests already do for missing NBD support.
Add _notrun_on_fuse_error() to common.rc and use it in the shell
tests. fuse-mmap-shared is Python, so it gets an equivalent inline
check.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Hanna Reitz <hreitz@redhat.com>
Message-ID: <20260715103451.1930909-3-den@openvz.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
run_tests_pool() shares the runner via the class attribute
TestRunner.shared_self, relying on worker processes to inherit it.
That only works with the 'fork' start method. Python 3.14 switched
the Linux default to 'forkserver', so workers see shared_self as
None and parallel runs abort with:
assert runner is not None
AssertionError
Only reproduces with Python 3.14+ and 'check -jN' (N > 1); meson
runs one test per process and never calls run_tests_pool(), so CI
is unaffected.
Request get_context('fork') explicitly; it is available on all
supported Python versions and a no-op before 3.14.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Hanna Reitz <hreitz@redhat.com>
Message-ID: <20260715103451.1930909-2-den@openvz.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
qcow2_do_close() -> qcow2_inactivate() clears the dirty bit with a
plain write to bs->file, unconditionally. A read-only node can still
be dirty, inherited from an earlier writable session, and that write
then hits a missing BLK_PERM_WRITE and asserts in
bdrv_co_write_req_prepare() (block/io.c) on an entirely ordinary
close -- closing is expected, the dirty bit on a read-only node
is not.
Skip the clear for read-only nodes, same as read access already does.
Any other still-dirty node keeps the unguarded write: it is expected
to hold write permission, and a missing one there is a bug worth
seeing.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Hanna Reitz <hreitz@redhat.com>
Message-ID: <20260716153552.3376009-1-den@openvz.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The chunk metadata contains both:
- Sector count: number of 512-byte sectors in the virtual disk
- Length: number of bytes in the image file
The UDRW chunk type indicates uncompressed data that can be accessed
directly. The code is missing input validation to verify that sector
count is consistent with length.
If sector count is larger than length, then read requests can access
beyond the end of the s->uncompressed_chunk buffer. This is an
out-of-bounds heap access that could lead to a crash or an information
leak.
While we're at it, also zero the end of the last sector when length is
unaligned. This prevents information leaks from the
s->uncompressed_chunk buffer.
Fixes: CVE-2026-65928
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3846
Reported-by: boy juju <agx1657748706@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20260723144519.364701-4-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The dmg block driver expects the disk image file to contain at least one
chunk. Refuse to open such files. This ensures that dmg block driver
state always has non-NULL s->sectors[] and related fields.
Note that the previous commit fixed the only known way to trigger a
crash. This patch is just for defense - let's avoid opening the file and
having NULL pointers in dmg block driver state.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4021
Reported-by: Tristan Madani <tristan@talencesecurity.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20260723144519.364701-3-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The binary search in search_chunk() uses s->n_chunks as the (inclusive)
upper bound. Chunk indices are in the right-open interval [0,
s->n_chunks) so it is wrong to search all the way up to s->n_chunks
rather than s->n_chunks - 1.
The worst case security scenario I can see is convincing a victim to
hotplug a malicious DMG file to a running guest, potentially causing
QEMU to crash when loading from memory beyond the end of s->sectors[] or
s->sectorscounts[]. This could be a denial of service.
Fixes: CVE-2026-65929
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3844
Reported-by: boy juju <agx1657748706@gmail.com>
Reported-by: Tristan Madani <tristan@talencesecurity.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20260723144519.364701-2-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block_latency_histogram_set() and block_latency_histograms_clear()
replace BlockLatencyHistogram's nbins/boundaries/bins without taking
stats->lock, while block_account_one_io() reads those same fields
under that lock from whatever iothread completes the I/O.
Add a test that races two real threads against
block_latency_histogram_set() and
block_acct_start()/block_acct_done() on the same BlockAcctStats.
Applied here it passes, since the previous two commits already take
the lock; reverting them locally reproduces the abort this series
fixes, in about a second.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Hanna Reitz <hreitz@redhat.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-ID: <20260724111311.4086859-4-den@openvz.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
bdrv_query_blk_stats() reads BlockAcctStats's counters, latency
histogram, and per-interval TimedAverage stats without stats->lock,
while block_account_one_io() updates the same fields under that lock
from an iothread. timed_average_min()/max()/avg() make this worse
than a stale read: they call check_expirations(), which can reset a
window's sum/count/min/max -- a write, not just a read -- so this is
a genuine race with a concurrent writer, not merely a slower reader
like the scalar counters.
Take stats->lock for the whole call, both to close the race and to
make the returned snapshot internally consistent (previously each
field could reflect a different instant relative to concurrent
updates).
block_acct_queue_depth() used to take the lock itself on every call;
since bdrv_query_blk_stats() is its only caller and now already holds
the lock, that would self-deadlock. Make it require the caller to
hold stats->lock instead (documented and asserted).
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Hanna Reitz <hreitz@redhat.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-ID: <20260724111311.4086859-3-den@openvz.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block_latency_histogram_set() and block_latency_histograms_clear()
replace BlockLatencyHistogram's nbins/boundaries/bins without taking
stats->lock, while block_account_one_io() reads those same fields
under that lock from whatever iothread completes the I/O. The result
is usual use-after-free and qemu crash.
Take stats->lock in both setters, matching the lock already held by
the reader.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Hanna Reitz <hreitz@redhat.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-ID: <20260724111311.4086859-2-den@openvz.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The total_sectors is computed as n_blocks * sectors_per_block where
both operands are uint32_t. The multiplication is performed in 32-bit
arithmetic and can overflow when the product exceeds UINT32_MAX,
producing a value much smaller than the true image size. The result
is assigned to int64_t total_sectors but the 32-bit multiplication
has already wrapped around, and the zero-extension to 64-bit does
not recover the correct value.
This causes the block layer to reject valid I/O requests (DoS) when
the reported total_sectors is smaller than the actual image.
Use 64-bit arithmetic by casting one operand to uint64_t so the
multiplication is performed in 64-bit precision.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3972
Signed-off-by: Ma Like <malike@kylinos.cn>
Message-ID: <20260713031750.58448-1-malike@kylinos.cn>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Since commit 49b2dcbd24 ("accel/accel-irq: add generic
begin_route_changes"), accel_irqchip_begin_route_changes() aborts when
no accelerator irqchip is available. This causes a fatal error when
running VFIO passthrough devices under TCG emulation:
qemu-system-aarch64: can't initiate route change, no accel irqchip available
The previous kvm_irqchip_begin_route_changes() was a simple inline
that did not have a fatal path. The VFIO code already handles the
absence of KVM MSI routing gracefully by falling back to userspace
handling, but the new generic function aborts before that fallback
can take effect.
Guard the call sites in hw/vfio/pci.c with
accel_msi_via_irqfd_enabled() so that route changes are only
initiated when an accelerator irqchip is actually present.
Fixes: 49b2dcbd24 ("accel/accel-irq: add generic begin_route_changes")
Cc: Magnus Kulke <magnuskulke@linux.microsoft.com>
Link: https://lore.kernel.org/qemu-devel/20260721105026.3932297-1-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
While working on savevm/loadvm for a new vfio device, I encountered the
crash below. Since vfio_connect_kvm_msi_virq() didn't check the ->use flag
for the vector, it would pass an unused vector down to
vfio_cpr_load_vector_fd() which would crash.
Fix this by checking the ->use flag along with the virq number to detect
whether a vector is valid or not.
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x0000555555a891ef in vfio_cpr_load_vector_fd (vdev=vdev@entry=0x0,
name=name@entry=0x555555eeb27e "kvm_interrupt", nr=nr@entry=1) at ../hw/vfio/cpr.c:44
44 g_autofree char *fdname = STRDUP_VECTOR_FD_NAME(vdev, name);
(gdb) bt
#0 0x0000555555a891ef in vfio_cpr_load_vector_fd
(vdev=vdev@entry=0x0, name=name@entry=0x555555eeb27e "kvm_interrupt", nr=nr@entry=1)
at ../hw/vfio/cpr.c:44
#1 0x0000555555ce64a1 in vfio_notifier_init
(vdev=0x0, e=e@entry=0x5555586971b4, name=name@entry=0x555555eeb27e "kvm_interrupt", nr=nr@entry=1, errp=errp@entry=0x0) at ../hw/vfio/pci.c:79
#2 0x0000555555ce721e in vfio_connect_kvm_msi_virq (vector=0x5555586971a8, nr=nr@entry=1)
at ../hw/vfio/pci.c:601
#3 0x0000555555cea5a5 in vfio_connect_kvm_msi_virq (nr=1, vector=<optimized out>)
at ../hw/vfio/pci.c:597
#4 vfio_pci_commit_kvm_msi_virq_batch (vdev=0x55555906de40) at ../hw/vfio/pci.c:822
#5 0x0000555555cea9f2 in vfio_msix_enable (vdev=vdev@entry=0x55555906de40) at ../hw/vfio/pci.c:850
#6 0x0000555555ceb152 in vfio_pci_load_config (vbasedev=0x55555906e900, f=<optimized out>)
at ../hw/vfio/pci.c:3088
#7 0x0000555555a8c765 in vfio_load_device_config_state (f=0x5555574a43d0, opaque=0x55555906e900)
at ../hw/vfio/migration.c:278
#8 0x0000555555b3a522 in vmstate_load
(f=f@entry=0x5555574a43d0, se=se@entry=0x5555591edd40, errp=errp@entry=0x7fffffffe130)
at ../migration/savevm.c:971
#9 0x0000555555b3ab1a in qemu_loadvm_section_start_full
(f=f@entry=0x5555574a43d0, type=type@entry=4 '\004', errp=errp@entry=0x7fffffffe130)
at ../migration/savevm.c:2654
#10 0x0000555555b3e1ee in qemu_loadvm_state_main
(f=f@entry=0x5555574a43d0, mis=mis@entry=0x5555571de5a0, errp=0x7fffffffe130,
errp@entry=0x555557157c10 <error_fatal>) at ../migration/savevm.c:2973
#11 0x0000555555b3f7b7 in qemu_loadvm_state
(f=f@entry=0x5555574a43d0, errp=errp@entry=0x555557157c10 <error_fatal>)
at ../migration/savevm.c:3058
#12 0x0000555555b40863 in load_snapshot
(name=0x7fffffffecc9 "foo", vmstate=vmstate@entry=0x0, has_devices=has_devices@entry=false, devices=devices@entry=0x0, errp=errp@entry=0x555557157c10 <error_fatal>) at ../migration/savevm.c:3452
#13 0x0000555555adc211 in qmp_x_exit_preconfig (errp=0x555557157c10 <error_fatal>) at ../system/vl.c:2817
#14 qmp_x_exit_preconfig (errp=0x555557157c10 <error_fatal>) at ../system/vl.c:2802
#15 0x0000555555adf8ed in qemu_init (argc=<optimized out>, argv=<optimized out>) at ../system/vl.c:3849
#16 0x00005555558903fd in main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:71
Fixes: 30edcb4d4e ("vfio-pci: preserve MSI")
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260727150038.2684512-1-tycho@kernel.org
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Removing the call to gen_compute_eflags meant we no longer
updated cc_op after computing EFLAGS.
Cc: qemu-stable@nongnu.org
Fixes: da7649c6ae ("target/i386/tcg: do not compute all flags for SAHF")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3537
Tested-by: Christian Quante <christian@quante.one>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We forgot to remove a comment about WFE/SEV only being implemented
for M-profile when we added the A-profile support for this; delete
the stale text.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260728111629.1705308-4-peter.maydell@linaro.org
The YIELD, WFI and WFE instructions are in the NOP hint space, and
were only defined to actual non-NOP instructions starting in the v6K
architecture; they are also present for all M-profile architecture
versions.
We never did check the architecture version before making these
instructions have their special behaviour. Mostly this has not been
a problem because a guest won't execute one of these insns unless it
is prepared for it to have its usual effect, and because we
implemented SEV and WFE as NOPs anyway.
Now we have implemented SEV and WFE to be more than just NOPs, it's
important that we have the same condition on the SEV as the WFE, so
that we either NOP both or else implement both. A guest probably
won't try to use SEV/WFE on CPUs that don't implement them, but it is
valid for it to do that and rely on them both being NOPs (and so a
WFE-loop falls back to a pure busy-wait loop).
Add the "only if M profile or v6K or better" check to YIELD, WFE and
WFI. This means that all the insns in the NOP-hint space for A32,
T32 and T16 have a correct feature check.
Fixes: 60e7ee5bb7 ("target/arm: implements SEV/SEVL for all modes")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260728111629.1705308-3-peter.maydell@linaro.org
When we implememented SEV to do something on A-profile rather than
being a nop, we got the condition slightly wrong, and made it only
effective from v7. In fact the instruction's Arm encoding has
non-NOP behaviour from ARMv6K.
The effect is that a kernel boot may hang on a v6K CPU like the
ARM11MPCore.
(This wouldn't have been so noticeable if we feature checked the WFE
instruction, and had made the same mistake for the condition on both
instructions. But we never have done the feature checks that we
ought on WFE, so the mistake on SEV meant that we showed the 11mpcore
guest a WFE that did something and a SEV that was a NOP.)
The v7A Arm ARM is not entirely clear about whether v6K has the Thumb
SEV encoding or not: it says "ARMv7 (executes as NOP in ARMv6T2)",
leaving v6K not stated. The 11MPCore TRM says it has at least WFI in
both Arm and Thumb, and the v7A Arm ARM uses the same condition text
for WFI, so I make the assumption that WFI, WFE, and SEV all get
their functionality for both Thumb and Arm in v6K. It's possible
that this differed between v6K CPUs -- the 1176 TRM says it has the
v6K STREXD/STREXH/STREXB etc, but the WFI is the old-style cp15 one.
Keeping the condition check the same for both Thumb and Arm encodings
is the conservative choice: if guests try to execute the Thumb SEV
insn it will be because they want SEV, not because they want a NOP.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4044
Fixes: 60e7ee5bb7 ("target/arm: implements SEV/SEVL for all modes")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260728111629.1705308-2-peter.maydell@linaro.org
These are controlled by FEAT_SVE_B16B16 not FEAT_SME_B16B16.
Cc: qemu-stable@nongnu.org
Fixes: bc65d2bd1c ("target/arm: Implement SME2 Multiple and Single SVE Destructive")
Fixes: 930760eb75 ("target/arm: Implement SME2 Multiple Vectors SVE Destructive")
Fixes: 8b61eff8e7 ("target/arm: Implement SME2 FCLAMP, SCLAMP, UCLAMP")
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Three linux-user patches, one aarch64 shadow stack fix
and two fixes for members of the target_msqid_ds struct.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCampphwAKCRD3ErUQojoP
X7D4AQDACw5DckBlNDY+3pDWE6/vYLFx+GJXgZKpF7nVf+/VugEA7QggRBMc82ch
5g4vDD+y8o6EBPHT+/vD8Ip2uYcDqgQ=
=azKH
-----END PGP SIGNATURE-----
Merge tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa into staging
linux-user patches
Three linux-user patches, one aarch64 shadow stack fix
and two fixes for members of the target_msqid_ds struct.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCampphwAKCRD3ErUQojoP
# X7D4AQDACw5DckBlNDY+3pDWE6/vYLFx+GJXgZKpF7nVf+/VugEA7QggRBMc82ch
# 5g4vDD+y8o6EBPHT+/vD8Ip2uYcDqgQ=
# =azKH
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 29 Jul 2026 16:58:47 EDT
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: aka "Helge Deller <deller@debian.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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa:
linux-user/aarch64: Fix SHADOW_STACK_SET_TOKEN
linux-user: fix incorrect msg_l[sr]pid members of target_msqid_ds
linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The token is not computed via TARGET_PAGE_SIZE, but via a fixed 12-bit field.
Cc: qemu-stable@nongnu.org
Fixes: ad1afe433f ("linux-user/aarch64: Implement map_shadow_stack syscall")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4106
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Helge Deller <deller@gmx.de>
The members are declared as __kernel_pid_t in Linux UAPI headers.
Analogous members in struct target_shmid_ds (shm_[cl]pid) are also
declared as abi_int.
Cc: qemu-stable@nongnu.org
Fixes: 1c54ff97bb ("linux-user: fix and cleanup IPCOP_msg* ipc calls handling")
Signed-off-by: no92 <leo@managarm.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Make sure that the time entries (msg_stime, msg_rtime and msg_ctime)
are defined as 64-bit time_t values, since the userspace may access
the whole 64-bit value. By this change we fix the word ordering for
32-bit big endian architectures as well.
This fixes the msgctl01 LTP testcase on hppa32.
Cc: qemu-stable@nongnu.org
Signed-off-by: Helge Deller <deller@gmx.de>
- fix a reachable assert()/process abort on a crafted image with an
inconsistent BAT vs. advertised disk size (GitLab #3804)
- fix related integer overflows capping the format's usable catalog
size below its documented maximum
- reject BAT entries pointing outside the data area in either
direction
- harden the dirty-bitmap extension loader against a reachable
abort and an unsafe allocator
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEC66qh9MCCtwRUOUfXgdxtstmbKsFAmpoy6UACgkQXgdxtstm
bKvDcA/7Bis1fqsgvsLDiLfxPmNXmaA6JwsHLCgcqnBtrlfucLpDghsE6Nr6Lthb
zgkYuWrNRtnIwbGEe4oW4jEukLb8k6hyUlwfQvIQik3rV0nnv1G4ewQMH7TmLKX+
xqFSK+TUpW5bQMphH3yOM2IShgytCXirPSZLfz1GY76eOSWcab/SgzPhANTf6bG3
o3eVZML9GrPDeDx3MuNdqfup+pX081xOM9l3Ub1hn8YRVvvZiaEmaw4HvT66Qnul
XL9/biNii0r7b4uITOj6Pvvft7W5yW5d+VL9P5hiidDvhwpC6CAjpu7/qScA3ZH2
v3MWnXwOEPLnmUE43ZR/8Vb07bHdSHuVLGgD7RPdmWGMMM2pzaCpbMRkdr9ABY5k
IdPISsijSeGt4Vi9hhXsBiL2tzBJ0w8w+x6o7YNM8RkHzKm7APWwKssJ6kIyQC7g
ImNgSVRbXBf+4bAD2MUiy3MOfkJ8li9oCXuFaC9fUx5Y4Y4DZdAmARjccUNwttMa
oixwlypndqJsXspikAsqQqMqA/cVAUd+rec2jDVx3W2nhZsV3KsMu8hD4jYeQkTx
CRi7owYuA0Z+eNLVvdsji292GcQKP7jcriM1gsSbhyyYDJUT3FHtpNKUxWOr1nFz
YWj8xSPy5rCpO9CheSXWtk7v/GKpq3riQ48KBbnfArBNxPBPNDY=
=aCB6
-----END PGP SIGNATURE-----
Merge tag 'pull-parallels-2026-07-28' of https://gitlab.com/dlunev/qemu into staging
Parallels block driver patches
- fix a reachable assert()/process abort on a crafted image with an
inconsistent BAT vs. advertised disk size (GitLab #3804)
- fix related integer overflows capping the format's usable catalog
size below its documented maximum
- reject BAT entries pointing outside the data area in either
direction
- harden the dirty-bitmap extension loader against a reachable
abort and an unsafe allocator
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEC66qh9MCCtwRUOUfXgdxtstmbKsFAmpoy6UACgkQXgdxtstm
# bKvDcA/7Bis1fqsgvsLDiLfxPmNXmaA6JwsHLCgcqnBtrlfucLpDghsE6Nr6Lthb
# zgkYuWrNRtnIwbGEe4oW4jEukLb8k6hyUlwfQvIQik3rV0nnv1G4ewQMH7TmLKX+
# xqFSK+TUpW5bQMphH3yOM2IShgytCXirPSZLfz1GY76eOSWcab/SgzPhANTf6bG3
# o3eVZML9GrPDeDx3MuNdqfup+pX081xOM9l3Ub1hn8YRVvvZiaEmaw4HvT66Qnul
# XL9/biNii0r7b4uITOj6Pvvft7W5yW5d+VL9P5hiidDvhwpC6CAjpu7/qScA3ZH2
# v3MWnXwOEPLnmUE43ZR/8Vb07bHdSHuVLGgD7RPdmWGMMM2pzaCpbMRkdr9ABY5k
# IdPISsijSeGt4Vi9hhXsBiL2tzBJ0w8w+x6o7YNM8RkHzKm7APWwKssJ6kIyQC7g
# ImNgSVRbXBf+4bAD2MUiy3MOfkJ8li9oCXuFaC9fUx5Y4Y4DZdAmARjccUNwttMa
# oixwlypndqJsXspikAsqQqMqA/cVAUd+rec2jDVx3W2nhZsV3KsMu8hD4jYeQkTx
# CRi7owYuA0Z+eNLVvdsji292GcQKP7jcriM1gsSbhyyYDJUT3FHtpNKUxWOr1nFz
# YWj8xSPy5rCpO9CheSXWtk7v/GKpq3riQ48KBbnfArBNxPBPNDY=
# =aCB6
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 28 Jul 2026 11:32:53 EDT
# gpg: using RSA key 0BAEAA87D3020ADC1150E51F5E0771B6CB666CAB
# gpg: Good signature from "Denis V. Lunev <den@openvz.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: 0BAE AA87 D302 0ADC 1150 E51F 5E07 71B6 CB66 6CAB
* tag 'pull-parallels-2026-07-28' of https://gitlab.com/dlunev/qemu:
MAINTAINERS: update parallels tree location
parallels: validate BAT capacity against advertised disk size
parallels: avoid fatal abort on large bitmap L1 table
parallels: skip loading a genuinely empty bitmap L1 table
parallels: validate bitmap L1 table size before allocating it
parallels: reject BAT entries pointing outside backed storage
parallels: fix bat_entries overflow in image creation
parallels: read header/BAT table in bounded chunks
parallels: fix integer overflow in header size calculation
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Fix potentially overflowing shift operation.
Cc: qemu-stable@nongnu.org
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Suggested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Resolves: Coverity CID 1663674
Fixes: ec917cd499 ("hw/nvme: fix FDP set FDP events")
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
The NVMe specification allows a controller with multiple namespaces to
use different LBA formats per namespace. One implication of this is that
the destination namespace may have a metadata area for PI, but the
source does not. In that case, the controller shall generate the
protection information, but the bounce buffer is erroneously allocated
without space for that, causing a buffer overflow.
Fix the allocation.
Cc: qemu-stable@nongnu.org
Fixes: d522aef88d ("hw/nvme: add cross namespace copy support")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3387
Reported-by: Jihe Wang <wangjihe.mail@gmail.com>
Reported-by: boy juju <agx1657748706@gmail.com>
Reported-by: contact <contact@xchglabs.com>
Reported-by: david korczynski <david@adalogics.com>
Reported-by: Brian Chastain (off_by_one / Curious-Keeper) <brian@scalingsuccess.io>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
When a controller is created with a MSI-X exclusive BAR, the bar0 memory region
is not used at all, and so, the iomem region is not added as a subregion of it.
However, when removing a NVMe controller, the iomem region is unconditionally
removed as a subregion of bar0, causing an assertion failure. Remove the iomem
memory region as a subregion of bar0 only if not using a MSI-X exclusive BAR.
QEMU options (requires a hotunplug-aware OS):
-M q35 -device pcie-root-port,id=rp0 \
-device nvme,serial=ctrl0,id=ctrl0,bus=rp0,msix-exclusive-bar=on
In the QEMU monitor, or by causing an ejection from the OS:
device_del ctrl0
Message in stderr:
qemu-system-x86_64: ../system/memory.c:2617: memory_region_del_subregion: Assertion `subregion->container == mr' failed.
Fixes: fa905f65c5 ("hw/nvme: add machine compatibility parameter to enable msix exclusive bar")
Fixes: 9162f10125 ("hw/nvme: fix msix_uninit with exclusive bar")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4090
Signed-off-by: Daniel Paziyski <danielpaziyski@gmail.com>
Reviewed-by: Klaus Jensen <k.jensen@samsung.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Let's use GPtrArray to build a list of blocker features and then
g_strjoinv() to build a final comma-delimited string.
While previous approach was technically correct, it is fragile
(because we need to take care of static buffer size choice) and
Coverity dislikes it too.
Note, that we use g_ptr_array_new() to allocate array which means
that GDestroyNotify callback is not set, so we can pass pointers to
a static memory like g_ptr_array_add(..., (gpointer) "SR-IOV") without
any problems as there won't be any attempt to free that memory.
Resolves: Coverity CID 1663673
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Klaus Jensen <k.jensen@samsung.com>
[k.jensen: change cast from gpointer to void ptr]
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
src.openvz.org is become unmaintained, point to the GitLab tree
instead.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels_open() copied nb_sectors, tracks, and bat_entries from the
image header without checking that the BAT actually covers the
advertised virtual disk size. An image whose header claims more
sectors than its BAT covers passes the generic block-layer bounds
check on open. A write into the gap between BAT coverage and the
advertised size then reaches allocate_clusters(), whose internal
assert(idx < s->bat_size && idx + to_allocate <= s->bat_size) aborts
the process instead of returning a normal I/O error.
Reject such images at open time by requiring
bat_size * tracks >= total_sectors, matching the invariant that
allocate_clusters() already assumes.
Reported-by: Feifan Qian <bea1e@proton.me>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3804
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Thomas Huth <thuth@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels_load_bitmap() allocated the L1 table with g_new(), which
aborts the whole process on allocation failure instead of returning
an error.
Use g_try_new() and fail the open normally.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Thomas Huth <thuth@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels_load_bitmap_data() unconditionally calls
bdrv_dirty_bitmap_deserialize_finish() even when there is nothing to
deserialize, which hits an assertion in hbitmap
(hbitmap_iter_init: 'pos < hb->size') when the bitmap itself has
zero size, i.e. the disk is a zero-sector image.
Skip allocating, populating and loading the L1 table entirely when
l1_size == 0. This is safe only because the previous commit already
guarantees l1_size == 0 exclusively means the disk has 0 size.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Thomas Huth <thuth@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels_load_bitmap() allocated the L1 table sized directly from
the untrusted l1_size field, only cross-checking it against the
bitmap's actual size after the allocation and the L1 table copy had
already happened.
Compute the expected size and reject a mismatch before touching the
allocator, instead of after.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Thomas Huth <thuth@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels_open()'s BAT scan and parallels_check_outside_image() only
checked entries against the file's upper end, matching just half of
what docs/interop/parallels.rst requires: an entry's offset must be
both >= data_start and < the file size. An entry below data_start
resolves into the header/BAT region itself, corrupting metadata on
write or losing the write silently on a partial overlap, and neither
qemu-img check nor the open-time scan ever caught it.
Check both bounds everywhere a BAT entry is resolved to a host
offset: seek_to_sector(), the open-time scan (without letting a bad
entry inflate data_end), and parallels_check_outside_image().
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Thomas Huth <thuth@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels_co_create() computed the BAT entry count directly into a
uint32_t, wrapping silently to zero at exactly 2^32 entries and
writing out a header whose BAT no longer matches its advertised
size. Compute it in an int64_t first and reject it once it no longer
fits, matching the cap parallels_open() already enforces. Also
reject cluster-size 0, and clamp header.cylinders instead of letting
it truncate the same way.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Thomas Huth <thuth@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels_open() read the whole header+BAT table with a single
bdrv_pread() call sized s->header_size. For an image whose catalog
approaches the "Catalog too large" bound (INT_MAX / sizeof(uint32_t)
entries), that size approaches BDRV_REQUEST_MAX_BYTES, and the block
layer legitimately refuses a single request that large, so the image
failed to open with a generic I/O error even though the catalog size
itself is within the format's documented limit.
Read the header and BAT table in fixed-size chunks instead, so the
maximum catalog size parallels_open() can actually address matches
the bound it already enforces, independent of the file's block-layer
alignment requirements.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Thomas Huth <thuth@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
Enable fsmount() syscalls, fix build with Linux 7.2 kernel headers and
allow full 32-bit address space on sh4.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCamhzJgAKCRD3ErUQojoP
X2WUAP9UOBDozOx0rqpDRDM1ktMQdp3zaUT+wJIyLojcNZcj8QD/aaImcmjuU4h9
Slgtdh5qtIUJynvOemumwW442Ftd3AQ=
=RFH+
-----END PGP SIGNATURE-----
Merge tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa into staging
linux-user patches
Enable fsmount() syscalls, fix build with Linux 7.2 kernel headers and
allow full 32-bit address space on sh4.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCamhzJgAKCRD3ErUQojoP
# X2WUAP9UOBDozOx0rqpDRDM1ktMQdp3zaUT+wJIyLojcNZcj8QD/aaImcmjuU4h9
# Slgtdh5qtIUJynvOemumwW442Ftd3AQ=
# =RFH+
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 28 Jul 2026 05:15:18 EDT
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: aka "Helge Deller <deller@debian.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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa:
linux-user/sh4: allow full 32-bit address space
linux-user: fix guards for the fsmount(2) syscall series
linux-user: Guard local FUTEX_CMD_MASK definition
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
In exynos4210_fimd_update(), we iterate through the enabled windows,
blitting them to the screen. We assume here that the guest has not
programmed the window's coordinates to be outside the overall LCD
screen resulation, but we never check this. This can result in the
guest being able to cause us to access outside our allocated
framebuffer backing memory.
Since all the coordinates here are unsigned, they can't be off
the left/top side of the screen, only the bottom/right. If
the top left corner of the window is out of bounds, the whole
window is invisible and we can skip it. If the bottom right
corner is out of bounds, we clamp it to the screen size so that
we only draw the visible part.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3795
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20260706173324.804340-4-peter.maydell@linaro.org
The draw_line functions currently assume the width of the line they
need to draw is w->rightbot_x - w->lefttop_x + 1, i.e. the full
width of the guest-programmed window. We want to be able to clamp
this to the overall screen size, which we can calculate in the
calling function.
Refactor to do this calculation in the caller and pass the
width as an argument to the draw_line functions.
Stable CC because this is a prerequisite for an upcoming bugfix
commit.
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20260706173324.804340-3-peter.maydell@linaro.org
Currently we hard-code the expressions for getting the global screen
width and height out of the VIDTCON2 register where we need them.
Use functions instead. Make the global_width variable in
exynos4210_fimd_update() uint32_t for consistency. (The values are
clamped to well below INT_MAX, so there is no overflow risk here.)
Stable CC because this is a prerequisite for an upcoming bugfix
commit.
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20260706173324.804340-2-peter.maydell@linaro.org
The Clock Stretch Timeout (CLKT) register for the BCM2835 I2C
controller is actually located at offset 0x1c, not 0x20.
Update the BCM2835_I2C_CLKT macro to match the hardware
specification.
Since QEMU's implementation ignores whatever value the guest
writes to this register, and Linux only writes to CLKT and
doesn't read it back, the main effect of this fix is to
avoid an incorrect GUEST_ERROR log.
Cc: qemu-stable@nongnu.org
Fixes: 9cf3bc65af ("hw/i2c: Implement Broadcom Serial Controller (BSC)")
Signed-off-by: botszhuang <botszhuang@gmail.com>
Tested-by: Nick Huang <sef1548@gmail.com>
Message-id: 20260724124220.24152-1-22925483+botszhuang@users.noreply.github.com
[PMM: removed commit message paragraph about effects which I think
is incorrect, substituted a different one]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Increase the extract32 length from 8 to 12. The Primary part number is
defined as bits[15:4] by the "SSE-310 with M85 and U55 FPGA"
documentation. For example for the mps3-an547, 0x547 is 12 bits but we
only return 8 bits right now.
Signed-off-by: Simon Xu <simonxhy0404@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260724160943.52509-3-simonxhy0404@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Change the CFG7 write function to modify the correct variable. This only
affects the an536 machine currently as only it uses cfg7 to store the
core 1 vector table base address.
Signed-off-by: Simon Xu <simonxhy0404@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260724160943.52509-2-simonxhy0404@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Describe the current OpenBMC target naming and release status for
Nuvoton machines. The latest 2.18.0 release no longer includes GSJ,
so point users at older 2.14.0 sources and explain how to find
Jenkins MTD artifacts.
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260627063208.33642-1-bin.meng@processmission.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Use the existing `rx_smb0` message buffer view for register masks instead
of the raw register array. Since all accesses now use the structured view,
remove the redundant `rx_smb0_raw` union member.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-10-shentey@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The RXIMR registers are not affected by soft reset, so their reset mask
must preserve all entries. Set the mask for the entire array instead of
only the first register.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-9-shentey@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
As indicated in the comments, the `mb[]` a.k.a. `mbs []` views should
cover 0x400 (1024) bytes. However, the `mb[]` array covers four times
the size since `sizeof(FlexcanRegsMessageBuffer)` returns the size in
bytes instead of counting the number of uint32_t fields. This shifts the
subsequent register offsets by 0xc00 which is not intended. Fix the size
and thus the offsets by dropping the now unused `mb[]` view.
Note that the different size changes the migration layout. Since the device
model is new, no change in the version fields is needed.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-8-shentey@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The mailbox reset mask initialized only the first word of the raw `mb[]`
array. Fix the initialization to cover the whole mailbox, as indicated
in the field description in the header. While at it, use the `mbs[]`
view instead in order to drop the redundant and oversized `mb[]` view in
the next commit.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-7-shentey@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Calculate mailbox indices from the `mbs[]` array layout instead of the
oversized raw `mb[]` view. This prevents accessing mailbox entries beyond
the valid array range and fixes Coverity CID 1662974.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260723070059.6332-6-shentey@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Calculate mailbox indices from the `mbs[]` array layout instead of the
oversized raw `mb[]` view. This prevents accessing mailbox entries beyond
the valid array range and fixes Coverity CID 1662974.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260723070059.6332-5-shentey@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Require `last_not_free_to_receive_mbid >= 0` before indexing `mbs[]`.
This prevents a possible `-1` array index and fixes Coverity CID
1662790.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260723070059.6332-4-shentey@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Remove the unused `FlexcanRegsRXFifo` union view now that FIFO accesses
use the underlying `mbs[]` array directly.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-3-shentey@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Implement FIFO entry shifting using the underlying `mbs[]` array instead
of the overlapping `fifo` union view. This makes it explicit that the
operation copies within a contiguous mailbox array and avoids Coverity
CID 1662971.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-2-shentey@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Use the stub library introduced in commit 0da978cdbc ("target/arm:
define stub library") to prevent symbol conflicts.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260721122135.6288-5-philmd@oss.qualcomm.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Only compile gicv5-cpuif.c when ARM_GICV5 is Kconfig-selected,
otherwise we get when building with --without-default-devices:
Undefined symbols for architecture arm64:
"_gicv5_activate", referenced from:
_gicr_cdia_read in target_arm_tcg_gicv5-cpuif.c.o
"_gicv5_deactivate", referenced from:
_gic_cddi_write in target_arm_tcg_gicv5-cpuif.c.o
"_gicv5_get_hppi", referenced from:
_gic_hppi in target_arm_tcg_gicv5-cpuif.c.o
"_gicv5_request_config", referenced from:
_gic_cdrcfg_write in target_arm_tcg_gicv5-cpuif.c.o
"_gicv5_set_enabled", referenced from:
_gic_cddis_write in target_arm_tcg_gicv5-cpuif.c.o
_gic_cden_write in target_arm_tcg_gicv5-cpuif.c.o
"_gicv5_set_handling", referenced from:
_gic_cdhm_write in target_arm_tcg_gicv5-cpuif.c.o
"_gicv5_set_pending", referenced from:
_gic_cdpend_write in target_arm_tcg_gicv5-cpuif.c.o
"_gicv5_set_priority", referenced from:
_gic_cdpri_write in target_arm_tcg_gicv5-cpuif.c.o
"_gicv5_set_target", referenced from:
_gic_cdaff_write in target_arm_tcg_gicv5-cpuif.c.o
Fixes: ee0f1ce00d ("target/arm: GICv5 cpuif: Initial skeleton and GSB barrier insns")
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260721122135.6288-4-philmd@oss.qualcomm.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The common helper.c file calls define_gicv5_cpuif_regs() which
is only defined when TCG is built:
$ git grep -w define_gicv5_cpuif_regs
target/arm/internals.h:1885:void define_gicv5_cpuif_regs(ARMCPU *cpu);
target/arm/helper.c:6334: define_gicv5_cpuif_regs(cpu);
target/arm/tcg/gicv5-cpuif.c:923:void define_gicv5_cpuif_regs(ARMCPU *cpu)
This fixes when building on macOS with --disable-tcg:
Undefined symbols for architecture arm64:
"_define_gicv5_cpuif_regs", referenced from:
_register_cp_regs_for_features in target_arm_helper.c.o
Define the GICv5 stubs in their own compilation unit, otherwise
we get the following error:
duplicate symbol '_raise_exception_ra' in:
libsystem_arm.a.p/target_arm_tcg_op_helper.c.o
libstubs_arm.a[4](target_arm_tcg-stubs.c.o)
Fixes: ee0f1ce00d ("target/arm: GICv5 cpuif: Initial skeleton and GSB barrier insns")
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260721122135.6288-3-philmd@oss.qualcomm.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
KVM and WHPX GICv3 implementations call gicv3_init_irqs_and_mmio()
which is defined in arm_gicv3_common.c, itself build when ARM_GIC
is selected. Both KVM and WHPX are conditional on ARM_GICV3,
itself selecting ARM_GIC. Only build the ARM_GICV3 accelerator
variants when ARM_GICV3 is selected.
$ git grep -w gicv3_init_irqs_and_mmio
hw/intc/arm_gicv3_common.c:314:void gicv3_init_irqs_and_mmio(GICv3State *s,
hw/intc/arm_gicv3.c:450: gicv3_init_irqs_and_mmio(s, gicv3_set_irq, gic_ops);
hw/intc/arm_gicv3_hvf.c:710: gicv3_init_irqs_and_mmio(s, hvf_gicv3_set_irq, NULL);
hw/intc/arm_gicv3_kvm.c:822: gicv3_init_irqs_and_mmio(s, kvm_arm_gicv3_set_irq, NULL);
hw/intc/arm_gicv3_whpx.c:186: gicv3_init_irqs_and_mmio(s, whpx_gicv3_set_irq, NULL);
Fixes: a7bf30342e ("hw/intc: Initial implementation of vGICv3")
Fixes: e4c95f78a4 ("hw, target, accel: whpx: change apic_in_platform to kernel_irqchip")
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260721122135.6288-2-philmd@oss.qualcomm.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
On real SH4 hardware, the address space is split between user mode
(U0, 0x00000000-0x7fffffff) and kernel mode (P1-P4, 0x80000000-0xffffffff),
so TARGET_VIRT_ADDR_SPACE_BITS was set to 31 for CONFIG_USER_ONLY.
However, qemu-user does not emulate the MMU, so this limit is not needed.
The only effect is to restrict reserved_va to 2 GB, causing OOM failures
for memory-intensive builds (e.g. webkit2gtk on Debian sh4 buildds).
Set TARGET_VIRT_ADDR_SPACE_BITS to 32 unconditionally, like most other
32-bit targets. Also fix the TASK_UNMAPPED_BASE macro to use 1ull instead
of 1u to avoid undefined behavior when shifting by 32.
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
While running remote interrupts test, without libslirp-devel installed,
facing the following panic logs.
File
...
raise VMLaunchFailure(
...<3 lines>...
) from exc
...
Output: qemu-system-ppc64: -netdev user,id=net0: network backend
'user' is not compiled into this binary
Adding netdev user requirement for this test.
Suggested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Suggested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Fixes: 63f5ba8092 ("tests/functional: Add remote interrupts test for PowerNV")
Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Message-ID: <20260728074612.42397-1-shivangu@linux.ibm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
In the SPARC CPU state, env->regwptr points into the env->regbase
array at wherever the architectural CWP (current window pointer) says
we are in the register windows. We don't migrate this directly,
since it's a host pointer, so we must ensure it is set up again
after migration load.
We also have to deal with a special case when CWP is (nwindows - 1).
In this case, while running we keep the "in" register data for this
window in a temporary location at the end of the regbase[] array, so
that generated code doesn't have to special case this "wrap around"
case. In cpu_pre_save() we call cpu_set_cwp() to force a copy of the
wrapped data from its temporary location into the architectural
location in window 0's "out" registers. We then migrate only
(nwindows * 16) entries in the regbase[] array. So on the
destination we need to copy the "in" register data back to its
temporary location again.
For 32-bit SPARC we get this right, because the CWP is in the PSR.
The get_psr() function does:
env->cwp = 0;
cpu_put_psr_raw(env, val);
which causes cpu_put_psr_raw() to call cpu_set_cwp() in a way that
sets up both regwptr and the wrapped-register data.
However, for 64-bit SPARC the CWP is not in the PSR, and
cpu_put_psr_raw() will not call cpu_set_cwp(). This leaves the guest
register state in a corrupted state, and the guest will likely crash
on the destination if it didn't happen to be executing with CWP == 0.
Fix this by adding a custom vmstate_cwp VMStateInfo with corresponding
get_cwp() and put_cwp() helpers which does the same for the 64-bit
case.
Cc: qemu-stable@nongnu.org
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260725123411.993099-1-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
rx_desc_len is migrated as a raw uint8_t from the stream but is a
derived value. Currently igb_rx_use_legacy_descriptor() is a stub
that always returns false, so rx_desc_len is always set to
sizeof(union e1000_adv_rx_desc). Recalculate it in post_load to
prevent a crafted migration stream from setting an invalid value.
Cc: qemu-stable@nongnu.org
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260722112449.1386162-3-lvivier@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
rx_desc_len is migrated as a raw uint8_t from the stream, but it
is a derived value that can be computed from the register state
in core.mac[RFCTL] and core.mac[RCTL]. A crafted migration stream
can set rx_desc_len to an invalid value (e.g. 64), causing a stack
buffer overflow in e1000e_write_packet_to_guest() which copies
rx_desc_len bytes into a 32-byte stack union.
Recalculate rx_desc_len and other derived values from the register
state in post_load, ignoring the untrusted values from the stream.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3869
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260722112449.1386162-2-lvivier@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
In Linux, the ESDHC_MIX_CTRL quirk is guarded by esdhc_is_usdhc() while
the eSDHC code path uses the standard SDHC interface. Extract the quirk
into a new `usdhc_write()` function.
Fixes file system corruption on emulated i.MX53 where Linux'
esdhc_is_usdhc() returns false. The same likely happens on e500 and
imx25-pdk machines.
Cc: qemu-stable@nongnu.org
Fixes: 75e98bc4f8 ("hw/sd/sdhci: Add TYPE_FSL_ESDHC_BE")
Reviewed-by: Bin Meng <bin.meng@processmission.com>
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-ID: <20260720201133.24796-3-shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The fsopen(), fsconfig(), fsmount() and fspick() implementations are
guarded by defined(NR_fsopen) rather than defined(__NR_fsopen). No such
macro exists, so the guard is never true and the entire series compiles
out. Guests calling any of the four get -ENOSYS, which for example makes
systemd's credential setup fail with EXIT_CREDENTIALS for most units.
The strace bits for fsconfig() have the same typo.
Check if FSCONFIG_SET_FLAG is defined to avoid build errors in the strace
code on some older distributions (Helge).
Fixes: 767c32fe69 ("linux-user: implement fsmount(2) series of syscalls")
Fixes: 6e0aa9f6c7 ("linux-user/strace: add fsmount series of syscalls")
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
The xilinx_axienet device has ethernet checksum offloading, with a
mode where the guest provides the offsets within the packet where
the data to be checksummed starts, and where the final checksum
should be written into the packet.
We don't sanity check the TX_CSINSERT offset before writing the
checksum data into it, which means the guest can pass us a value that
is larger than the packet itself and cause us to write the checksum
off the end of the buffer. We also don't explicitly check the
TX_CSBEGIN offset; this doesn't currently cause any problems because
we will pass a negative length to net_checksum_add() which does
nothing, but it's a potential trap for the future if the type
used for the length gets changed to be unsigned.
Explicitly check the offsets. The datasheet doesn't say what happens
if the guest misprograms this, so we choose to log an error and send
the packet as-is.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3599
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260706162704.787495-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Virtqueue handler functions in device emulation code often look
something like this:
while (!virtio_queue_empty(vq)) {
...pop and process virtqueue element...
}
virtio-blk, virtio-scsi, virtio-crypto, and vhost-shadow-virtqueue use
this pattern.
The device may break (i.e. hit an error that requires device reset)
during the loop. virtio_queue_empty() returns 1 for broken split vrings
but not for broken packed vrings, leading to an infinite loop.
Adjust the packed vring behavior to match split vrings and avoid
infinite loops.
Fixes: CVE-2026-16457
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3968
Reported-by: Anatol Belski <anbelski@linux.microsoft.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260721134424.196337-1-stefanha@redhat.com>
rng_backend_request_entropy() uses the requested size to allocate
a buffer with g_malloc(). With virtio-rng, this size comes from
guest-supplied descriptor lengths. A malicious guest can set a very
large descriptor length, causing QEMU to attempt a multi-gigabyte
allocation and abort.
Cap the allocation to 64 KiB. The virtio-rng queue size is
hardcoded to 8 entries, the EGD backend protocol limits requests
to 255 bytes, the Linux kernel hwrng framework requests at most
SMP_CACHE_BYTES per call (64 bytes on x86_64), and the Windows
viorng driver uses a 4 KiB buffer. The worst legitimate case is
8 x 4 KiB = 32 KiB, so 64 KiB is well above any legitimate use.
Fixes: 1441703965 ("virtio-rng: use virtqueue_get_avail_bytes, fix migration")
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3983
Reported-by: dong ling <dongling226655@outlook.com>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260715141300.2295392-1-lvivier@redhat.com>
Fix a heap-use-after-free in the virtio-rng frontend when a delayed
rng-random backend completion arrives after the virtio-rng device has been
hot-unplugged.
Fixes: CVE-2026-50624
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3917
Reported-by: Jia Jia <physicalmtea@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260724094931.3005968-1-lvivier@redhat.com>
Replace qemu_bh_new_guarded() by virtio_bh_new_guarded()
so the bus and device use the same guard. Otherwise the
DMA-reentrancy protection can be bypassed.
This update was missing in CVE-2024-3446 fix.
Fixes: CVE-2026-66022
Cc: qemu-stable@nongnu.org
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Cc: alxndr@bu.edu
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4073
Reported-by: Giovanni Vignone <gio@octane.security>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260723233555.2970619-1-lvivier@redhat.com>
Prevent a buggy driver to execute malformed invalidation operations.
Add the same assert as in vtd_iotlb_page_invalidate.
Link: https://gitlab.com/qemu-project/qemu/-/work_items/3619
Fixes: 6ebe6cf2a0 ("intel_iommu: Process PASID-based iotlb invalidation")
Reported-by: huntr bubble <bubblehuntr@gmail.com>
Signed-off-by: Clement Mathieu--Drif <clement.mathieu--drif@bull.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260724111424.376680-1-clement.mathieu--drif@bull.com>
cxl_doe_cdat_rsp() takes ent = req->entry_handle (uint16_t, fully
guest-controlled, 0..0xFFFF) and directly indexes cdat->entry[ent]
without checking ent < cdat->entry_len. For a default cxl-type3 with
one volatile memory region, entry_len = 1 + CT3_CDAT_NUM_ENTRIES = 7,
so any entry_handle >= 7 reads past the CDATEntry array into host heap.
The OOB-read base/length are then used in
memcpy(read_mbox + offset, base, len) at cxl_type3.c:298-299, leaking
host heap memory to the guest via PCI_EXP_DOE_RD_DATA_MBOX, and
potentially overflowing the 1 MiB read_mbox heap buffer when the OOB
length field is large.
The same bug exists in the cxl-upstream implementation.
Existing checks do not bound ent: assert(cdat->entry_len) only ensures
the table is loaded; the minimum-length check only guards against a
truncated CDATReq; the entry_handle ternary at line 293 only decides
the next-handle echo, not the current access; pcie_doe_get_obj_len
reads header.length, not entry_handle.
Reproduce: build QEMU with CONFIG_CXL, boot
-M q35,cxl=on -device pxb-cxl,bus_nr=52 ... -device cxl-type3,...
then send a CDATReq with entry_handle=0xFFFF via the DOE mailbox at
config offset 0x190. Under ASAN this reports SEGV in cxl_doe_cdat_rsp
at cxl_type3.c:281.
Fixes: f5ee7413d5 ("hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange")
Fixes: 882877fc35 ("hw/pci-bridge/cxl-upstream: Add a CDAT table access DOE")
Signed-off-by: Haotian Jiang <jianghaotian.sunday@gmail.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260713072336.623604-2-jianghaotian.sunday@gmail.com>
vhost_vdpa_device_set_config() receives the updated config buffer, but
forwards s->config to the vhost backend. Since s->config is refreshed by
get_config(), it may contain stale backend state.
Pass the supplied config buffer to vhost_dev_set_config() instead.
Fixes: b430a2bd23 ("vdpa: add vdpa-dev support")
Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260709073225.2341642-1-zhaoguohan@kylinos.cn>
In mch_write_config() we return early if has_smm_ranges is false.
This is slightly bug-prone because it leaves the door open to somebody
later adding non-SMM-specific code at the bottom of the function.
This case isn't as bad as the one in realize, because the function is
a lot shorter. But putting the handling of the three SMM specific
ranges into an if() rather than having an early return seems better.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260708121011.1653365-4-peter.maydell@linaro.org>
mch_realize has a large section that deals with initializing the
SMRAM-specific MemoryRegions. Currently we do an early return from
the realize function if mch->has_smm_ranges is false, but this has
the potential for bugs if somebody adds new code at the end of the
function that isn't SMM-specific. Pull the MR init code out into its
own function, so we can do the smm-ranges specific handling in the
realize function in a more obvious way.
This commit shouldn't change behaviour at all.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260708121011.1653365-3-peter.maydell@linaro.org>
The MCHPCIState::smram_region looks like it ought to be SMM-specific,
but it isn't, because its behaviour is "alias the PCI address space
into system memory at the SMRAM_C_BASE offset", and it must be
enabled for "hide SMRAM", and disabled for "show SMRAM". If the
SMRAM regions are disabled, we want "hide SMRAM", so we need to
initialize and place this MR. Do this in the minimal way, by moving
the "bail out of realize if has_smm_ranges is false" check down below
the initialization code.
This fixes a bug where disabling SMM causes the VGA screen to be
blank during seabios output, until the OS graphics driver is
initialized. This is most obvious for accelerators which have no SMM
support (e.g. NVMM, HVF, WHPX) as there smm=off is the default, but
you can also see it on KVM and TCG if you explicitly pass smm=off:
qemu-system-x86_64 -machine q35,accel=kvm,smm=off
The early return is bug-prone, so we can refactor the code to clean
it up, but this is the minimal bug fix for backports, and is what
Debian used to work around this:
6e0766f0f8
Another proposed fix for this:
https://patchew.org/QEMU/20260413170407.57574-1-mohamed@unpredictable.fr/
also moves an early return in mch_update-smram() and tweaks
mch_update_smram() accordingly. This shouldn't be necessary, because
in the no-SMM case smram_region should always be enabled and we don't
want to allow the guest to make it disabled.
NetBSD bug: https://gnats.NetBSD.org/59721
Cc: qemu-stable@nongnu.org
Fixes: b07bf7b7 ("q35: Introduce smm_ranges property for q35-pci-host")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/2608
Reported-by: Kroese (gitlab @kroese)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260708121011.1653365-2-peter.maydell@linaro.org>
Coverity points out one g_malloc0 overflow, but it seems to be a false
positive. Add a check to it regardless to fortify the code, and also add
checks for every other g_malloc0 use.
Resolves: Coverity CID 1547527
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260420-virtio-fixups-v3-2-07aef1eff9d2@linaro.org>
It must be at least sizeof(virtio_snd_pcm_status).
I haven't verified if it's possible to get an underflow, but coverity
points it out in CID 1547527 so add a check.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260420-virtio-fixups-v3-1-07aef1eff9d2@linaro.org>
Currently, within virtio-iommu, handle_command processes the command vq
without any limits on the number of entries processed.
This can easily and repeatedly enable/disable multiple memory regions.
Within the memory code, this causes an accumulation of an
unbounded number of RCU-deferred FlatViews - each of these
is supposed to be freed with call_rcu, but that never happens
because the main thread never returns to the main loop.
Given FlatView is big, it's easy to have this balloon out to multiple
Gigabytes of memory.
Limit the loop defer any remaining work to a timer.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3930
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Reported-by: Jia Jia <physicalmtea@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <eb46ab360dbe28c29cfa78812a7440dcb7444d59.1784807826.git.mst@redhat.com>
libvduse assumes that vq size (aka vq num) is below VIRTQUEUE_MAX_SIZE
and maps logs large enough based on this assumption.
However, vduse_queue_enable() accepts the vq size returned through
VDUSE_VQ_GET_INFO without validation, so a value above
VIRTQUEUE_MAX_SIZE (1024) overruns the inflight log and causes
out-of-bounds writes in vduse_queue_inflight_get().
According to the virtio spec, vq size can only be reduced, not
increased, so vq size must not exceed the previously configured
max_size, but the kernel vduse module does not validate this for us, and
we should not trust another process to follow the spec.
Validate and reject vq size values above VIRTQUEUE_MAX_SIZE.
Fixes: CVE-2026-61402
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3652
Reported-by: Jia Jia <physicalmtea@gmail.com>
Message-ID: <bf7e71b3139875e5e00fd53970c772d6c90dc2a1.1784888961.git.mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
vu_check_queue_inflights counts inflight descriptors using inflight == 1
but copies entries using inflight != 0. If the inflight field contains
an unexpected non-0/1 value, the function copies more entries than it
allocates and overflows the heap buffer.
Stop the copy pass once resubmit_num reaches the counted inuse value.
Note: the value is not guest-accessible so not a security vulnerability.
Fixes: CVE-2026-63110
Fixes: 5f9ff1eff3 ("libvhost-user: Support tracking inflight I/O in shared memory")
Cc: Xie Yongji <xieyongji@bytedance.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3974
Reported-by: BB CC <wywwzjj@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <e2315efc526c0ee918485df4be69e2b26e8b7a73.1784892981.git.mst@redhat.com>
vu_check_queue_inflights uses last_batch_head from the frontend-controlled
inflight shared memory as an index into desc[] without bounds checking.
A malicious or buggy frontend can set last_batch_head >= desc_num,
causing an out-of-bounds write.
Validate last_batch_head before using it.
Note: the value is not guest-accessible so not a security vulnerability.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3974
Fixes: 5f9ff1eff3 ("libvhost-user: Support tracking inflight I/O in shared memory")
Cc: Xie Yongji <xieyongji@bytedance.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>
Reported-by: BB CC <wywwzjj@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <8133770c75c9907578dd551f4d468140a0a75cd2.1784892981.git.mst@redhat.com>
virtio_pmem_flush submits fsync requests to the thread pool and stores a
VirtIOPMEM pointer in each request. If device is deleted e.g. by
hot-unplug, once these complete, done_cb can run after
virtio_pmem_unrealize frees the device, causing a use-after-free.
Track in-flight requests and wait in virtio_pmem_unrealize until
their completions finish before tearing the device down.
Fixes: CVE-2026-63323
Fixes: 5f503cd9f3 ("virtio-pmem: add virtio device")
Cc: David Hildenbrand <david@kernel.org>
Cc: Pankaj Gupta <pagupta@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3938
Reported-by: Jia Jia <physicalmtea@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <417b6685f37ce818c660ca3c84945992f5c30dcf.1784894206.git.mst@redhat.com>
scrub_shadow_regions() and vhost_user_add_remove_regions() use
fixed-size stack arrays sized to VHOST_USER_MAX_RAM_SLOTS and index them
with dev->mem->nregions.
nregions is calculated to never overrun these, but let's add an assert
to make sure we don't get a stack overflow if there's a bug.
Fixes: f1aeb14b08 ("Transmit vhost-user memory regions individually")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3910
Cc: Stefano Garzarella <sgarzare@redhat.com>
Cc: Raphael Norwitz <raphael.norwitz@nutanix.com>
Reported-by: Feifan Qian <bea1e@proton.me>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <48fb8411f67e525872fb19618a886e52b670ab7f.1784896199.git.mst@redhat.com>
virtio_load() attempts to load config_len bytes from the migration
stream. If that's huge (e.g. 4g) this will uselessly spin
beyond the end of the stream for seconds. Not nice.
Check qemu_file_get_error() and bail out early, instead.
Also note that config_len is int32_t but is coerced to unsigned when
used. Switch it to uint32_t to make this clearer.
Fixes: 2f5732e964 ("Allow mismatched virtio config-len")
Cc: Dr. David Alan Gilbert <dave@treblig.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3891
Reported-by: Feifan Qian <bea1e@proton.me>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <cfbefa358af5885eb386637216552bfeba5e7bbc.1784898922.git.mst@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
num_default tracks the allocation size of used_elems, set by
virtio_add_queue(). Migrating it via the ringsize subsection is
wrong: a migration stream (malicious or simply from a different
configuration) can inflate num_default so that
virtio_queue_set_num() accepts oversized values, leading to OOB
access on the used_elems array.
It is not even migrated consistently: a configuration with a
smaller num_default could thinkably migrate and work but in the
common case of num == num_default the value is not actually sent.
Stop migrating num_default: make virtio_ringsize_needed() return
false so the subsection is never sent, and use VMSTATE_UNUSED to
consume the field from old streams without applying it. The
destination keeps its local num_default from virtio_add_queue(),
which matches the actual allocation.
Also validate vring.num against num_default when loading the core
virtio state, rejecting streams that supply a queue size larger
than the locally allocated maximum.
Fixes: 46c5d0823d ("virtio: ring sizes vs. reset")
Fixes: 50e5ae4dc3 ("migration/virtio: Remove simple .get/.put use")
Cc: Cornelia Huck <cohuck@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <3e6a7c403f93acc37af6a6332fdc65049ae218fb.1784894327.git.mst@redhat.com>
virtio_add_queue() allocates used_elems for num_default entries, but
virtio_queue_set_num() accepts larger guest-supplied queue sizes up to
VIRTQUEUE_MAX_SIZE. With VIRTIO_F_IN_ORDER, this lets the guest drive
used_elems accesses past the allocation and cause out-of-bounds reads
and writes.
Reject queue sizes larger than num_default in virtio_queue_set_num()
and mark the device broken.
Fixes: e63c0ba1bc ("virtio: Add support for guest setting of queue size")
Fixes: CVE-2026-50626
Cc: Peter Maydell <peter.maydell@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3882
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3921
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3923
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3613
Reported-by: huntr bubble <bubblehuntr@gmail.com>
Reported-by: Jia Jia <physicalmtea@gmail.com>
Reported-by: Miku Hatsune <anznu1l@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <eb7cc3672a20db392f577edbece2300aa6754dd3.1784898967.git.mst@redhat.com>
virtio-mmio reports VIRTQUEUE_MAX_SIZE (1024) as QUEUE_NUM_MAX for every
queue, regardless of the size the device passes to virtio_add_queue().
This works by accident because QEMU mostly does not care about the ring
size - the guest is the one allocating memory here. But this changes
with in-order vqs where qemu is the one allocating resources.
Now, specifying a larger vq than allocated causes an OOB memory access.
To fix:
- for new machine types, report the actual max queue size to guest
- for old machine types, use a compat property to allocate 1k sized
queues
Fixes: 525d82e323 ("virtio: fix queue size validation against allocated maximum")
Fixes: CVE-2026-50626
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3882
Cc: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <8715acbb9516e67e2a776cda6f9edf105343f788.1784930765.git.mst@redhat.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Reported-by: Miku Hatsune <anznu1l@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When virtio_scsi_handle_cmd_vq() cleans up prepared requests after a
malformed element in the same batch, it drops only one reference even
though virtio_scsi_handle_cmd_req_prepare() leaves each unsubmitted
SCSIRequest with two references. This leaks the request and allows
repeated bad batches to cause unbounded host memory growth.
Add a second scsi_req_unref() and clear hba_private first.
Fixes: CVE-2026-61476
Fixes: 661e32fb3c ("virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3875
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Fam Zheng <fam@euphon.net>
Cc: Greg Kurz <groug@kaod.org>
Reported-by: Feifan Qian <bea1e@proton.me>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <5092cd4716e08d29731bfe85eea82a732b837ff4.1784895264.git.mst@redhat.com>
When vhost_commit() rebuilds the memory region table after a flatview
change, it revalidates cached host virtual addresses for active vring
parts. If a mapping is stale, QEMU abort().
This is not a security problem - only the priviledged guest
can control make it invalid - but not nice e.g. for driver debugging.
Let's call virtio_error() instead, marking the device as broken.
Fixes: 0ca1fd2d68 ("vhost: Simplify ring verification checks")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3783
Cc: Stefano Garzarella <sgarzare@redhat.com>
Cc: Dr. David Alan Gilbert <dave@treblig.org>
Reported-by: Feifan Qian <bea1e@proton.me>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <71961a7dc157f552303aeea8c99a75c5e1ce904e.1784898432.git.mst@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
The split-ring path already rejects a zero-length indirect descriptor
table since commit 7423192912 ("virtio: add checks for the size of
the indirect table"). The packed-ring path is missing the same check,
allowing a guest to trigger an assertion in address_space_cache_init()
with a packed indirect descriptor that has len=0.
Add the same !desc.len check to the packed-ring indirect validation
in both virtqueue_packed_get_avail_bytes() and virtqueue_packed_pop().
Fixes: 86044b24e8 ("virtio: basic packed virtqueue support")
Cc: jasowangio@gmail.com
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3984
Reported-by: dong ling <dongling226655@outlook.com>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260715115040.2186274-1-lvivier@redhat.com>
SET_VRING_NUM, SET_VRING_ADDR, SET_VRING_BASE, and GET_VRING_BASE
handlers all use the queue index from the message to access dev->vq[]
without checking that it is below dev->max_queues, so a malformed
message causes an out-of-bounds heap access.
Frontend is trusted so not a security problem, but
an OOB access is not a nice way to handle errors.
Check, and panic.
Fixes: 7b2e5c65f4 ("contrib: add libvhost-user")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3741
Cc: Stefano Garzarella <sgarzare@redhat.com>
Reported-by: xlabai <xlabai@tencent.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <dbba777b25f86587c8d131891a2b4b2be97e5c5b.1784899069.git.mst@redhat.com>
vu_set_inflight_fd() trusts the num_queues value from the
VHOST_USER_SET_INFLIGHT_FD message without checking it against
dev->max_queues, so an oversized value causes out-of-bounds writes to
dev->vq.
Front end is generally trusted so not a security problem, but OOB isn't
a nice way to handle frontend bugs. Let's harden this a bit:
check num_queues and panic if it's invalid.
Fixes: 5f9ff1eff3 ("libvhost-user: Support tracking inflight I/O in shared memory")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3740
Cc: Stefano Garzarella <sgarzare@redhat.com>
Reported-by: xlabai <xlabai@tencent.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <23b3f12388c1035f208550df9de9944c22d8d534.1784899127.git.mst@redhat.com>
Within virtio-net, receive_filter() reads Ethernet header fields without
any length checks.
But virtio-net sets do_not_pad in NetClientState, so backends such as
socket forward frames at the size supplied by the peer without padding
to the Ethernet minimum. A short frame thus causes an out-of-bounds
read.
Add size checks in receive_filter() and drop the truncated frames.
Fixes: CVE-2026-63320
Fixes: 3831ab2094 ("qemu:virtio-net: Enable filtering based on MAC, promisc, broadcast and allmulti (Alex Williamson)")
Cc: Jason Wang <jasowangio@gmail.com>
Cc: Alex Williamson <alex@shazbot.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3626
Reported-by: huntr bubble <bubblehuntr@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <ee5c77b96ab66b2dd518f146def8727216a5c495.1784895727.git.mst@redhat.com>
The RSC receive path parses incoming frames at guest_hdr_len byte
offsets, but the backend buffer contains only host_hdr_len bytes of vnet
header. If the lengths differ, RSC would read at the wrong offset and
cause an OOB read.
This is no longer possible after the previous patch, but the assumption
seem fragile. Along the defense in depth lines, let's validate. To
ensure we are not breaking any valid setups by mistake, warn and fall
back to the normal receive path when host_hdr_len != guest_hdr_len.
Fixes: CVE-2026-63321
Fixes: 2974e916df ("virtio-net: support RSC v4/v6 tcp traffic for Windows HCK")
Cc: Jason Wang <jasowangio@gmail.com>
Cc: Yuri Benditovich <ybendito@redhat.com>
Cc: Wei Xu <wexu@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3623
Reported-by: huntr bubble <bubblehuntr@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <f261dcd535edc890f8636d8ae5ac1007bc32b8b4.1784891251.git.mst@redhat.com>
virtio_set_features_nocheck() calls set_features_ex
with guest-supplied feature bits, without masking the value
with host features (unlike set_features which gets the
correct val & host_features).
This does not matter if the driver matches spec, but drivers
can be malicious or buggy and set bit outside the host mask.
Devices don't expect this, so unsupported guest feature bits getting set
can break the host. In virtio-net, this can enable RSC without vnet
header support and cause out-of-bounds reads from short packets.
Pass the masked features to set_features_ex, consistent with set_features.
Fixes: CVE-2026-63321
Fixes: 64a6a336f4 ("virtio: add support for negotiating extended features")
Cc: Jason Wang <jasowangio@gmail.com>
Cc: Yuri Benditovich <ybendito@redhat.com>
Cc: Paolo Abeni <pabeni@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3623
Reported-by: huntr bubble <bubblehuntr@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <dfd27c9b26e442a2076f6ddc9bb3d38363d9b2da.1784891251.git.mst@redhat.com>
parallels_open() caches bat_entry_off(s->bat_size) - a uint32_t -
in a plain int before it feeds into s->header_size. Near the
"Catalog too large" bound the value exceeds INT_MAX and overflows
on assignment.
Match the cached value's type to bat_entry_off()'s return type.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Thomas Huth <thuth@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
The function calls yield_until_fd_readable() (coroutine_fn) when in
coroutine context, and polls with qemu_poll_ns() otherwise.
Replace the migration-state proxy check with qemu_in_coroutine(),
which directly tests what matters.
Fixes: 2da776db48 ("rdma: core logic")
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
All V9fsTransport callbacks are invoked exclusively from coroutine
context (the v9fs_* PDU handlers). Annotate the function pointer
types in V9fsTransport and all implementations (virtio and xen
backends), as well as intermediate callers in 9p.c (pdu_marshal,
pdu_unmarshal, v9fs_init_qiov_from_pdu, etc.).
Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Those DEBUG_ALLOC-guarded are dead code incorrectly calling coroutine fn
from non-coroutine. Remove it.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Fixes: 70bacc4453 ("qcow2: mark more functions as coroutine_fns and GRAPH_RDLOCK")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The function was extracted without carrying the annotation.
Fixes: 23743ab282 ("block: move commit_run loop to separate function")
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Fixes: 394b9407e4 ("migration: mark mixed functions that can suspend")
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The function calls qemu_coroutine_yield(), and is called from
monitor_qmp_dispatcher_co().
Fixes: 60f4f62efe ("monitor: extract request dequeuing to a new function")
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Under some optimization, gcc produces a false-positive:
../block/blkio.c: In function ‘blkio_co_getlength’:
../block/blkio.c:943:8: error: ‘ret’ may be used uninitialized [-Werror=maybe-uninitialized]
943 | if (ret < 0) {
| ^
Replace WITH_QEMU_LOCK_GUARD with the simpler QEMU_LOCK_GUARD.
Suggested-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
virt_instance_init() built the FDT unconditionally at QOM
instance-init time, so simply instantiating the object (e.g. via
qom-test's introspection, without ever realizing the machine) leaked
the 1MB FDT blob: machine_finalize() does not free machine->fdt.
Other boards (arm/virt, riscv/virt, ...) build the FDT lazily from
their MachineClass::init callback, which only runs when the machine
is actually selected to boot. Do the same here by moving create_fdt()
into virt_init().
Fixes: 88a8bc7f43 ("hw/hexagon: Define hexagon "virt" machine")
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
docs/devel/style.rst:
* Variables declared with g_auto* MUST always be initialized,
otherwise the cleanup function will use uninitialized stack memory
Fixes: 680935c9a6 ("hw/cxl: Add a performant (and correct) path for the non interleaved cases")
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
rutabaga_cmd_get_capset_info() only fills in capset_id,
capset_max_version and capset_max_size before sending the response to
the guest. The remaining fields of struct virtio_gpu_resp_capset_info,
including hdr.fence_id, hdr.ctx_id and hdr.ring_idx, are left with
stack garbage and leaked to the guest, including host pointers useful
for an ASLR bypass.
Zero the response first, matching virgl_cmd_get_capset_info().
Not a real risk thanks to -ftrivial-auto-var-init=zero, but only with
gcc >= 12 or clang >= 16.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3609
Fixes: 1dcc6adbc1 ("gfxstream + rutabaga: add initial support for gfxstream")
Reported-by: Haotian Jiang <jianghaotian.sunday@gmail.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The migration stream encoding is not defined for Rutabaga yet.
Fixes: 1dcc6adbc1 ("gfxstream + rutabaga: add initial support for gfxstream")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260725-rutabaga-v1-1-4832b56e679d@rsg.ci.i.u-tokyo.ac.jp>
virtio_gpu_base_device_realize() leaks a migration blocker if a
check of the output list fails after adding one. Perform the check
before adding a migration blocker to avoid the leak. This also
simplifies the code by merging two loops.
Fixes: d3a4969dc5 ("Support per-head resolutions with virtio-gpu")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260725-virgl-v1-1-58bb51e60da5@rsg.ci.i.u-tokyo.ac.jp>
The documentation stated that writing to HV_X64_MSR_CRASH_CTL
unconditionally causes the guest to shutdown. In reality, it triggers
qemu_system_guest_panicked() via KVM_SYSTEM_EVENT_CRASH and the
resulting action depends on the generic panic action policy
(-action panic=...), which defaults to shutdown.
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260701122135.3168729-1-marcandre.lureau@redhat.com>
rutabaga_cmd_set_scanout() checks scanout_id < VIRTIO_GPU_MAX_SCANOUTS
(16), but does not check scanout_id < conf.max_outputs like the base
class (virtio-gpu.c) and virgl backend (virtio-gpu-virgl.c) do.
With the default max_outputs=1, virtio_gpu_base_device_realize only
initializes scanout[0].con. A guest submitting SET_SCANOUT with
scanout_id >= 1 takes the con=NULL path, and
qemu_console_set_surface(NULL, NULL) dereferences con->ds, crashing
QEMU.
Replace VIRTIO_GPU_MAX_SCANOUTS with vb->conf.max_outputs in the
CHECK, since realization already ensures max_outputs <=
VIRTIO_GPU_MAX_SCANOUTS.
Fixes: 1dcc6adbc1 ("gfxstream + rutabaga: add initial support for gfxstream")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3897
Cc: qemu-stable@nongnu.org
Message-ID: <20260720071556.106003-1-jianghaotian.sunday@gmail.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Haotian Jiang <jianghaotian.sunday@gmail.com>
gpa2hva() returns a referenced MemoryRegion via its p_mr out-parameter
(inherited from memory_region_find()), but both SEV callers were failing
to release it.
Fixes: c7f7e6970d ("sev: add sev-inject-launch-secret")
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260521145451.1831984-1-marcandre.lureau@redhat.com>
colo_rewriter_cleanup() unconditionally destroys connection_track_table,
but the table is only allocated in colo_rewriter_setup(). When the
filter-rewriter object is finalized without having been set up (e.g.
during qom-test property enumeration), the pointer is NULL and
g_hash_table_destroy() fires an assertion.
Use g_clear_pointer() to skip the destroy when the table was never
initialized.
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Zhang Chen <zhangckid@gmail.com>
Message-ID: <20260709111315.1108185-1-marcandre.lureau@redhat.com>
qxl_realize_common() registers a vm_change_state handler via
qemu_add_vm_change_state_handler() and creates three bottom halves
(update_irq, update_area_bh, cursor_bh), but none are ever cleaned up.
The return value of qemu_add_vm_change_state_handler() is discarded, so
the handler is never removed from the global list, and there is no
PCIDeviceClass.exit callback to delete the BHs.
When a secondary QXL device (hotpluggable by default) is hot-unplugged
via device_del, the PCIQXLDevice memory is freed but the vm_state
handler and BH entries remain with dangling opaque pointers. On the
next VM state change (stop/cont/migrate) or BH dispatch, the callback
dereferences freed memory, causing a use-after-free.
Fix this by storing the VMChangeStateEntry returned by
qemu_add_vm_change_state_handler() and adding a qxl_exit() callback
that deletes the vm_state handler, all three BHs, and the
guest_surfaces.cmds allocation before the device memory is freed.
Fixes: a19cbfb346 ("spice: add qxl device")
Fixes: CVE-2026-63322
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3607
Signed-off-by: Haotian Jiang <jianghaotian.sunday@gmail.com>
Cc: qemu-stable@nongnu.org
[ Marc-André - tweak commit message, add TODO ]
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260720024855.3757499-1-jianghaotian.sunday@gmail.com>
"rows" was already computed in an earlier commit 3543c2b855 ("ui/vnc:
fix OOB write in vnc_refresh_lossy_rect").
Fixes: e650e4fe0f ("ui/vnc: fix out-of-bounds write in lossy refresh dirty marking")
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
A malicious or buggy vhost-user-gpu backend can send messages with
undersized payloads, leading to out-of-bounds reads when the handler
accesses struct fields beyond the allocated buffer. However,
vhost-user-gpu is considered trusted by QEMU by design (it has access to
shared memory etc).
Add a centralized minimum payload size check in vhost_user_gpu_chr_read()
that rejects messages before dispatch, and a per-pixel bounds check in
the VHOST_USER_GPU_UPDATE handler to ensure the variable-length data
covers the declared width x height.
Fixes: 267f66465 ("hw/display: add vhost-user-vga & gpu-pci")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3866
Reported-by: Feifan Qian <bea1e@proton.me>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
virtio_gpu_do_set_scanout() validates the stride field of struct
virtio_gpu_framebuffer against the bytes_pp field, but bytes_pp in the
migration stream may be inconsistent with the format field, which
pixman_image_create_bits() uses when it accesses the framebuffer.
That validation is therefore incomplete.
To avoid the trouble of synchronizing the two fields, remove bytes_pp,
and always derive its value from format. Removing bytes_pp is safe
because no released version of QEMU uses its migrated value.
Fixes: 7b55742254 ("hw/display: check frame buffer can hold blob")
Cc: qemu-stable@nongnu.org
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
[ Marc-André - fix rebase conflict ]
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260719-bpp-v1-1-9b91946d6cf3@rsg.ci.i.u-tokyo.ac.jp>
xhci_xfer_create_sgl() can fail if a guest programmed the XHCI in
a weird way. The current code ignores this error, and this triggers
an assert() shortly afterwards:
hw/usb/core.c:612: usb_packet_copy:
Assertion `p->actual_length + bytes <= iov->size' failed.
Fix it by handling the error correctly (i.e. return with an error to
the caller).
While we're at it, change the DPRINTF statements in xhci_xfer_create_sgl()
into proper qemu_log_mask() statements, so we have a better way to detect
this situation.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3786
Reported-by: Feifan Qian <bea1e@proton.me>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260724110933.629791-1-thuth@redhat.com>
usb_packet_copy() uses assert(p->actual_length + bytes <= iov->size)
to make sure that there is enough space in the the iov. This assert()
can be triggered from do_parameter() if the guest programs the XHCI
in a weird way. Avoid the hard error by checking for the condition
in do_parameter() first and signalling a USB_RET_STALL to the guest,
just like it is done for another error condition here already some
lines earlier.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3746
Reported-by: Yunhe Wang <yunhewwww@163.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260721185140.247775-1-thuth@redhat.com>
ide_cancel_dma_sync() is called with a "IDEState *s" for one of the
two IDE drives on a bus (primary or secondary drive) to cancel all
pending DMA transfers on the drive. The code then checks
s->bus->dma->aiocb to see whether there is any IO in flight on the
*bus* and then calls blk_drain(s->blk) to wait for its completion.
However, s->bus->dma->aiocb might belong to the other drive on the
bus, and if there is no disk attached to the current drive, s->blk
is NULL. Since blk_drain() does not check its parameter for a NULL
pointer, QEMU can crash in such a case.
To fix the problem, we have to check that "blk" is not NULL before
calling blk_drain(). And we have to call blk_drain() for both drives,
otherwise the assert(s->bus->dma->aiocb == NULL) statement after
the blk_drain() might trigger if the IO in flight belongs to the
the other drive.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/905
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4052
Reported-by: dong ling
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260721070216.82984-1-thuth@redhat.com>
The stream ID is under control of the guest, and some spots in the
code currently use it for indexing into the status3[] array without
checking it for being in range first, so the code accesses the heap
beyond the limit of the status3 array.
Since our status delivery code depends on having a valid stream ID,
we must not try to generate a fake sense code in this situation.
Simply log a guest error and return early in usb_uas_command().
And to make sure that we really cannot access the status3[] array
beyond its limit anymore, add some assert() statements in the
affected functions, too.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3612
Reported-by: Reported-by: huntr bubble
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3986
Reported-by: Tristan Madani <tristan@talencesecurity.com>
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260720134809.573757-1-thuth@redhat.com>
cmd_features_set_feature() derives bytes_to_copy from the mailbox input
length and uses hdr->offset as the destination offset into per-feature
write attribute buffers.
The patrol scrub and ECS paths already reject writes where hdr->offset
plus bytes_to_copy exceeds the destination structure. Add the same check
to the soft PPR, hard PPR and memory sparing feature paths before
copying into their write attribute buffers.
Without the check, a malformed Set Feature request can write past the
selected write attribute object and corrupt adjacent CXL type 3 device
state.
Fixes: 5e5a86bab8 ("hw/cxl: Add support for Maintenance command and Post Package Repair (PPR)")
Fixes: da5cafdc4d ("hw/cxl: Add emulation for memory sparing control feature")
Signed-off-by: Feifan Qian <bea1e@proton.me>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3458
Reported-by: Jia Jia <physicalmtea@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Commit b04746bd0d unified boot completion detection on the generic
'login:' prompt but missed several SDK test files that still matched
on hostname-prefixed patterns. Apply the same fix.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4059
Fixes: b04746bd0d ("tests/functional/aspeed: unify boot completion detection on 'login:' prompt")
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260720162321.3497633-1-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Building linux-user on a host with Linux 7.2 kernel headers fails with
a macro redefinition error for FUTEX_CMD_MASK. The kernel commit
3ca9595d9fb6 ("futex: Add support for unlocking robust futexes")
expanded the mask to include the new FUTEX_ROBUST_UNLOCK and
FUTEX_ROBUST_LIST32 flags, which conflicts with QEMU's local
definition.
Add a #ifndef guard so the host definition takes precedence when
available. The local fallback is kept for older kernel headers
(pre-2.6.29) that lack FUTEX_CMD_MASK or define a mask without
FUTEX_CLOCK_REALTIME.
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Helge Deller <deller@gmx.de>
The xen-9p disconnect path has two issues:
1. It frees the Xen9pfsRing structures while in-flight PDUs may still
reference them via pdu->tag to index rings[]. This causes a UAF
in xen_9pfs_push_and_notify() when worker threads resume after
completing filesystem operations.
2. It never calls v9fs_device_unrealize_common(), which means server
state (struct LocalData, mountfd, FIDs) is never cleaned up on
disconnect, causing a resource leak on every guest-initiated
disconnect.
Fix both by draining in-flight PDUs via v9fs_reset() before tearing
down rings, and calling v9fs_device_unrealize_common() to clean up
server state.
Additionally, explicit calls of xen_9pfs_disconnect() in the error
paths of xen_9pfs_pdu_vmarshal() and xen_9pfs_pdu_vunmarshal() must
be deferred (via aio_bh_schedule_oneshot()), because
xen_9pfs_pdu_v(un)marshal() are running within a coroutine context
which makes them unsafe [1] for calling v9fs_reset() directly, as
the latter e.g. has a loop like:
while (!QLIST_EMPTY(&s->active_list)) {
aio_poll(qemu_get_aio_context(), true);
}
which would a) never terminate (as the coroutine is on the
active_list) and b) aio_poll() is marked as no_coroutine_fn.
[1] https://lore.kernel.org/qemu-devel/3351181.5fSG56mABF@weasel/
And finally, add an idempotent guard to xen_9pfs_disconnect()
for the v9fs_reset(s) and v9fs_device_unrealize_common(s) calls
specifically [2], just to be sure.
[2] https://lore.kernel.org/qemu-devel/alpine.DEB.2.22.394.2607221815520.5295@ubuntu-linux-20-04-desktop/
Fixes: b37eeb0201 ("xen/9pfs: introduce Xen 9pfs backend")
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Link: https://lore.kernel.org/qemu-devel/82bc736158e827e05d4b55da27c39d42e2062e96.1784809978.git.qemu_oss@crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
A guest can trigger a heap-use-after-free in the virtio transport
unrealize path by submitting a Treaddir request and immediately
ejecting the device via ACPI PCI hotplug. The unrealize path frees
struct LocalData while a worker thread still holds a reference
on it, causing a UAF in local_open_nofollow().
Fix this by draining all in-flight 9p PDUs by calling v9fs_reset()
before final server cleanup. This ensures all coroutines completed,
all FIDs are closed, and no worker thread still holds references
on 9p server state when it is freed.
Fixes: 6cecf09373 ("virtio-9p-device: add minimal unrealize handler")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3937
Signed-off-by: Jia Jia <physicalmtea@gmail.com>
[ Christian Schoenebeck: add commit log message. ]
Link: https://lore.kernel.org/qemu-devel/bc503aefffd20b1806941b3ef708afbd92f0aef2.1784809978.git.qemu_oss@crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Guest 9p client opening a file with O_TRUNC on a read-only 9p file
system using 9p2000.u protocol version, allowed to bypass 9p
server's read-only check, eventually causing file(s) being
truncated to empty file(s) on host's read-only export.
Root cause is that 9p server's read-only check is using Linux open
flags like O_WRONLY, O_RDWR, O_TRUNC, but checking them against
the 9p Topen request's "mode" parameter, which has a different
encoding (Otrunc = 0x10 vs. O_TRUNC = 0x200).
Fix this by checking against the "flags" variable instead of the
protocol's "mode" option. Because the "flags" variable is already
converted to Linux encoding by omode_to_uflags() for 9p2000.u and
by get_dotl_openflags() for 9p2000.L protocol version.
Only 9p2000.u was affected by this bypass, 9p2000.L uses the Linux
format on protocol level already.
Fixes: 2c74c2cb4b ("hw/9pfs: Read-only support for 9p export")
Fixes: CVE-2026-63318
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4000
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/qemu-devel/E1wk2Dq-0019kY-JK@kylie.crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
On host systems with ext4 and ea_inode capability not enabled, the max. size
for xattr values is slightly below 4k, which caused the new xattr tests to
fail on such host systems.
Reduce the xattr size for our tests to 1k to prevent them to fail on such
host systems.
Reported-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Fixes: 04a62cdfe8 ("tests/9p: add 3 xattr FID limit test cases (local fs driver)")
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Tested-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/E1wffqw-001Sc8-I9@kylie.crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
The local fs backend driver tests require that a dummy file is
created on the host side before running the xattr limit tests,
otherwise the test will fail because the file is expected to exist.
The original call of g_file_set_contents() didn't check its
return value, which might cause subsequent test checks to fail,
making it harder to identify the root cause.
Fix this by simply wrapping the call into a g_assert().
Fixes: 04a62cdfe8 ("tests/9p: add 3 xattr FID limit test cases (local fs driver)")
CID: 1660926
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/E1wfg2F-001Sfn-Rr@kylie.crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
In ide_dma_cb(), the call to prepare_buf() might return a negative
result and cause an assertion failure. This was found during fuzzing
and can be triggered with some qtest commands. Replace the assert with
proper error handling in case the result is negative, but keep the
assert for failing to respect the limit upon success. If that happens,
it is an implementation error.
Found by Linux Verification Center (linuxtesting.org) with libFuzzer.
Cc: qemu-stable@nongnu.org
Fixes: ed78352a59 ("ide: Fix incorrect handling of some PRDTs in ide_dma_cb()")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/2777
Signed-off-by: Artem Nasonov <anasonov@astralinux.ru>
Link: https://lore.kernel.org/qemu-devel/20250116111600.2570490-1-anasonov@astralinux.ru
[FE: improve commit message
keep assert for failing to respect the limit]
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Record the completion side of parameter-based control transfers when they
complete asynchronously. This lets pcap captures include descriptor
response data for requests such as GET_DESCRIPTOR from usb-host devices.
The synchronous path already recorded the completion, but the async
SETUP_STATE_PARAM path was missing it.
Signed-off-by: Ziyi Fu <ziyi.fu@cyberus-technology.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Fixes: 0f6dba145a ("usb: add pcap support.")
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Replace manual qemu_mutex_(un)lock() calls with
QEMU_LOCK_GUARD() to remove 'goto out' code
Signed-off-by: Evgeny Kolmakov <randomjack94dev@gmail.com>
Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The code in the SVGA_CMD_DEFINE_ALPHA_CURSOR handler in vmsvga_fifo_run()
basically does:
x = vmsvga_fifo_read(s);
y = vmsvga_fifo_read(s);
args = x * y;
goto badcmd;
...
badcmd:
len -= args;
if (len < 0) {
goto rewind;
}
while (args--) {
vmsvga_fifo_read(s);
}
Thus by supplying huge values for x and y that overflow the result of
the multiplication, the guest can trigger a long-running loop here
that burns the host's CPU cycles.
Add some sanity checks so that this cannot happen anymore.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3782
Reported-by: Feifan Qian <bea1e@proton.me>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4026
Reported-by: Tristan Madani <tristan@talencesecurity.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4076
Reported-by: Sunday Jiang
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Some HTTP servers and WAFs (e.g. Amazon CloudFront) reject
requests without a User-Agent header with 403 Forbidden. This
makes qemu-img info and other curl-based operations fail on
such URLs without any obvious indication of the root cause.
Set a "QEMU/<version>" User-Agent string on all curl handles
to ensure compatibility with these endpoints.
Signed-off-by: Vladimir Lobanov <lobanov-vla@yandex.ru>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Filip Hejsek <filip.hejsek@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* target/i386: helper_sysret(): Check that RCX contains a canonical address when emulating an Intel CPU
* target/i386: tcg: remove FIXME
* scsi-disk: protect against guest sending truncated data for MODE SELECT commands
* scsi-disk: fix off by one in assertion
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmpgcwoUHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroPfhwf+PLJ73Xf71TyKsRp0q+aEBHuT0v+h
KYSAzjqhKF3MvzTJXm/NBpnCQjxQ1FCypwcUvbDF/amOBjP/FQnFUORZMrFNkRIr
LQqnuI4SSLkYBsx+/uCnZ2WsoELh0te/I/WqhjuimUhjQau93qLPByBaE0p3ifl6
kWqeq7lgiLFSgJxOZPXfyFZPmYvfLQatO0LVArydkcNjIMhPi1sZ2ZEBrqbV/QnA
pEpKkbeiS2t7x/kYCQ+X2scLiReWfVz1VHnufSI6L8+8/S4UE1Y3FaQcyfuPFFBC
urgInhQqjrs+2e9BQa14yD5A4G9gYOn1+vL6yB/aJ2bYlvPxhw/u7XojNQ==
=mZw/
-----END PGP SIGNATURE-----
Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
* meson: propagate qemu_ldflags to Rust link step
* target/i386: helper_sysret(): Check that RCX contains a canonical address when emulating an Intel CPU
* target/i386: tcg: remove FIXME
* scsi-disk: protect against guest sending truncated data for MODE SELECT commands
* scsi-disk: fix off by one in assertion
# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCgAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmpgcwoUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroPfhwf+PLJ73Xf71TyKsRp0q+aEBHuT0v+h
# KYSAzjqhKF3MvzTJXm/NBpnCQjxQ1FCypwcUvbDF/amOBjP/FQnFUORZMrFNkRIr
# LQqnuI4SSLkYBsx+/uCnZ2WsoELh0te/I/WqhjuimUhjQau93qLPByBaE0p3ifl6
# kWqeq7lgiLFSgJxOZPXfyFZPmYvfLQatO0LVArydkcNjIMhPi1sZ2ZEBrqbV/QnA
# pEpKkbeiS2t7x/kYCQ+X2scLiReWfVz1VHnufSI6L8+8/S4UE1Y3FaQcyfuPFFBC
# urgInhQqjrs+2e9BQa14yD5A4G9gYOn1+vL6yB/aJ2bYlvPxhw/u7XojNQ==
# =mZw/
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 22 Jul 2026 03:36:42 EDT
# gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg: issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1
# Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83
* tag 'for-upstream' of https://gitlab.com/bonzini/qemu:
scsi-disk: fix off by one in assertion
scsi-disk: protect against guest sending truncated data for MODE SELECT commands
target/i386: helper_sysret(): Check that RCX contains a canonical address when emulating an Intel CPU
meson: propagate qemu_ldflags to Rust link step
target/i386: tcg: remove FIXME
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This is read-only variable which informs the OS about the
secure boot state. Reject any attempts to write to it.
Fixes: CVE-2026-16288
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4039
Acked-by: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260720143244.821889-7-kraxel@redhat.com>
Specifically disallow zero which can lead to an endless loop.
Fixes: CVE-2026-61406
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3899
Acked-by: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260720143244.821889-4-kraxel@redhat.com>
This was never meant to be present in production builds. It's a code
path not hit on a normal boot (OVMF wouldn't try variable updates which
are not allowed), so this went unnoticed.
Remove the function. If needed for debugging the git log is your
friend.
Fixes: CVE-2026-58582
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3615
Acked-by: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260720143244.821889-3-kraxel@redhat.com>
Verify the passed buffer has the minimal required length before
reading the size field + verifying the total length.
Fixes: CVE-2026-58581
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3614
Acked-by: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260720143244.821889-2-kraxel@redhat.com>
When documenting the invariant that mode pages need to fit the smallest
output buffer of all callers (which is SCSI_MAX_MODE_LEN), the expression
used by the assertion was incorrect.
Even though SCSI_MAX_MODE_LEN is indeed 256, using "length < 256" had
two issues: 1) it used the wrong operator, since "length < ..." is more
related to having room for extra data; 2) it missed the extra two bytes
for page number and length.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
scsi-disk has a MODE SELECT path where a truncated mode page can be
allowed by a compatibility quirk, but the parser continues to use the
page's declared length rather than the number of bytes actually remaining
in the request buffer. This means that scsi_disk_check_mode_select() and
scsi_disk_apply_mode_select() can read beyond the valid part of inbuf[],
potentially up to the emulated age's length.
Clamping page_len (the size of the page) to len (whatever the
guest provided) ensures that scsi_disk_check_mode_select() and
scsi_disk_apply_mode_select() do not access anything beyond bounds;
however, this requires care to accept and handle truncated input in
those two functions.
In particular, until scsi_disk_check_mode_select()'s first call to
mode_sense_page() the number of bytes to be cleared in mode_current[] is
unknown, so zero it completely. And for everything else, be conservative
and use len when providing inputs to other functions; but at the same time,
ensure all accesses to inbuf[] are bound by expected_len.
Note that pages longer than the emulated one are still rejected.
Fixes: 389e18eb9a ("scsi-disk: add SCSI_DISK_QUIRK_MODE_PAGE_TRUNCATED quirk for Macintosh")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4051
Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We recently started to have those failures appearing when building
documentation. It's hard to identify if it comes from a python, sphinx
or sphinx extension, but it blocks us.
Exception occurred:
File "/usr/lib/python3.13/multiprocessing/connection.py", line 399, in _recv
raise EOFError
EOFError
The full traceback has been saved in /tmp/sphinx-*.log, if you want to report the issue to the developers.
This seems to be the generic error message for "something went wrong in
sphinx multiprocess":
- https://github.com/sphinx-doc/sphinx/issues/11449
- https://github.com/sphinx-doc/sphinx/issues/14458
- https://github.com/sphinx-doc/sphinx/issues/8973
Solve the issue by simply going back to sequential builds. We didn't
notice a huge speedup anyway.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260720222717.33078-1-pierrick.bouvier@oss.qualcomm.com
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Intel and AMD CPUs implement SYSRETQ instruction differently.
One of these differences is whether a canonicality check of the address that
will be loaded to RIP is performed: Intel CPUs do this check, AMD CPUs don't.
Currently, QEMU does not perform this check when emulating Intel CPUs.
This patch corrects this by implementing the canonlicality check on a new RIP
value from RCX and performing it only when emulating Intel CPUs.
Flags and segment registers' caches are updated only after checking the new RIP
value to ensure that CPU state is not modified in case the #GP(0) exception
is raised due to the check failure.
Cc: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Fixes: 14ce26e755 ("x86_64 target support")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3223
Signed-off-by: Andrey Polivoda <apolivodaa433@gmail.com>
Link: https://lore.kernel.org/r/20260608091815.31303-1-apolivodaa433@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Sanitizer flags are added to qemu_ldflags and applied globally for
all_languages, but all_languages never includes 'rust'.
Fixes link errors like the ones below:
-Wl,-rpath,$ORIGIN/../qemu-macros:<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib"
= note: some arguments are omitted. use `--verbose` to show all linker arguments
= note: rust-lld: error: undefined symbol: __ubsan_handle_type_mismatch_v1
>>> referenced by event-loop-base.c:104 (../qemu_before_fix/event-loop-base.c:104)
>>> libevent-loop-base.a.p/event-loop-base.c.o:(event_loop_base_class_init)
>>> referenced by event-loop-base.c:105 (../qemu_before_fix/event-loop-base.c:105)
>>> libevent-loop-base.a.p/event-loop-base.c.o:(event_loop_base_class_init)
>>> referenced by event-loop-base.c:58 (../qemu_before_fix/event-loop-base.c:58)
>>> libevent-loop-base.a.p/event-loop-base.c.o:(event_loop_base_set_param)
>>> referenced 11240 more times
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260714021236.2361604-1-brian.cain@oss.qualcomm.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This isn't in practise a problem since irq->argsz is not externally
provided, it's a good hardening step nonetheless.
Fixes: ca1add1696 ("vfio-user: implement VFIO_USER_DEVICE_GET/SET_IRQ*")
Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260721122643.30985-10-thanos.makatos@nutanix.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
This isn't in practise a problem since irq->argsz is not
externally provided, it's a good hardening step nonetheless.
Fixes: ca1add1696 ("vfio-user: implement VFIO_USER_DEVICE_GET/SET_IRQ*")
Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260721122643.30985-9-thanos.makatos@nutanix.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
This isn't in practise a problem since feature->argsz is not externally
provided, it's a good hardening step nonetheless.
Fixes: e2358af583 ("vfio-user: support VFIO_USER_DEVICE_FEATURE")
Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260721122643.30985-8-thanos.makatos@nutanix.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
This isn't in practise a problem since feature->argsz is not
externally provided, it's a good hardening step nonetheless.
Fixes: e2358af583 ("vfio-user: support VFIO_USER_DEVICE_FEATURE")
Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260721122643.30985-7-thanos.makatos@nutanix.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
If the vfio-user server responds with a value larger than max_xfer_size
vfio_device_get_region_info() blindly uses it in the next loop in
g_realloc. An value larger than max_xfer_size is anyway rejected by the
check at the beginning of vfio_user_get_region_info(), however that only
happens _after_ the g_realloc, and if that value is excessively large it
can cause g_realloc to fail, so check it here.
Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
Fixes: 667866d666 ("vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFO")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260721122643.30985-5-thanos.makatos@nutanix.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
While this isn't technically a bug, it's highly unlikely that the
server wouldn't be writing an entire struct.
Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
Fixes: 667866d666 ("vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFO")
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260721122643.30985-4-thanos.makatos@nutanix.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
qemu-kvm aborts a few seconds after starting a VM with a
passed-through GPU whose PCI_INTERRUPT_PIN comes back as an
out-of-range value: vfio_intx_enable() only guards against pin == 0
and stores vdev->intx.pin = pin - 1 with no upper-bound check. That
value later reaches pci_irq_handler()'s
assert(0 <= irq_num && irq_num < PCI_NUM_PINS) via
pci_irq_deassert() -> pci_set_irq(), aborting the process.
Legal PCI_INTERRUPT_PIN values are 0 (no legacy interrupt) or
1-PCI_NUM_PINS (INTA-INTD); reject anything else before it reaches
vdev->intx.pin, whether the out-of-range value came from a read
failure (now caught by the previous commit) or was handed back as
data by the device itself.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Alex Williamson <alex@shazbot.org>
CC: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260717122232.468955-3-den@openvz.org
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
vfio_pci_read_config() signals a failed host-side read by returning
(uint32_t)-1, regardless of the requested length. vfio_intx_enable()
and vfio_pci_pre_reset() both narrowed that return value straight
into a uint8_t/uint16_t local before checking anything, which
truncates -1 into 0xff or 0xffff - values a real 1- or 2-byte
register read can legitimately produce. From that point on, a
failed read and real all-ones content are indistinguishable.
Keep the full uint32_t result and check it against (uint32_t)-1
before narrowing. In vfio_pci_pre_reset(), skip the corresponding
write-back on a failed read instead of writing back constructed
garbage to the device.
Resolves: Coverity CID 1663684
Resolves: Coverity CID 1663688
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Alex Williamson <alex@shazbot.org>
CC: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260717122232.468955-2-den@openvz.org
[ clg: Added Coverity IDs ]
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The dma-buf failure messages in vfio_region_create_dma_buf() say "PCI
BAR IOMMU mappings may fail", which suggests the BAR is broken. In
practice, only P2P DMA is affected -- normal passthrough uses the mmap
fallback.
Reword both messages to mention P2P DMA explicitly and clarify that
the mmap fallback is in use. Use warn_report_err_once() at the call
site so per-BAR repetition on mdev devices is suppressed.
Fixes: dcf1b77e834d ("hw/vfio/region: Create dmabuf for PCI BAR per region")
Cc: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
IGD does not come with a ROM BAR [1], the ROM BAR read by default from
kernel is actually the host VBIOS shadow RAM region that contains host
modifications on boot. With AI-assisted reverse engineering on VBIOS
binaries, it is observed that VBIOS saves BDSM register value on first
access and uses saved value if present.
When the image is executed in guest, since there is already a saved HPA
in VBIOS, it keeps using that value instead of the GPA programmed by
SeaBIOS in BDSM register in PCI config space, causing VBIOS to program
GTT entries with wrong address, resulting in garbled output in BIOS
POST and the error below detected by i915 driver.
i915 0000:00:02.0: [drm] *ERROR* Initial plane programming using invalid range, dma_addr=0x00000000db200000 ((null) [0x00000000baf00000-0x00000000beefffff])
The previous solution, c4c45e943e ("vfio/pci: Intel graphics legacy
mode assignment"), adjusts GTT entry addresses to (addr - host BDSM +
guest BDSM) to workaround that. But it is removed in 5aed8b0f0b
("vfio/igd: Remove GTT write quirk in IO BAR 4") due to inconsistent
values in MMIO BAR0 and IO BAR4.
Since it was a value latched into the VBIOS that breaks virtualization
(QEMU does not map the GTT at the same address in the VM), a ROM quirk
clearing the saved value in VBIOS image is introduced. It searches the
BDSM accessor routine by matching a 19-byte signature anchored on the
unique `mov $0x105e,%ax` instruction, then locates the offset of saved
BDSM and clears it. This makes the routine fall through to the PCI
config read on the first call inside the guest.
[1] 3.5.15, 4th Generation Intel Core Processor Family Datasheet Vol. 2
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/4th-gen-core-family-desktop-vol-2-datasheet.pdf
Fixes: 5aed8b0f0b ("vfio/igd: Remove GTT write quirk in IO BAR 4")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3093
Reported-by: K S Maan <kirandeepmaan45@gmail.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Tomita Moeko <tomitamoeko@gmail.com>
Reviewed-by: Alex Williamson <alex@shazbot.org>
Link: https://lore.kernel.org/qemu-devel/20260708103100.23127-1-tomitamoeko@gmail.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
With the GitLab mapping files from the previous commit, the
get_manitainer.pl script is now able to report the gitlab
handle for each maintainer/reviewer when displaying output.
For example:
$ ./scripts/get_maintainer.pl -f hw/scsi/lsi53c895a.c
Paolo Bonzini <pbonzini@redhat.com> (supporter:SCSI, gitlab:@bonzini)
Fam Zheng <fam@euphon.net> (reviewer:SCSI, gitlab:@famzheng)
qemu-devel@nongnu.org (open list:All patches CC here)
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It is desirable to be able to discover the GitLab account handle
assocaited with a real name in the MAINTAINERS file.
Rather that duplicating the same account handle multiple times,
inline with the MAINTAINERS file entries, this introduces mapping
files:
* .gitlab-map-auto - data automatically queried from GitLab
using the 'glab' tool and REST API
* .gitlab-map-manual - manual overrides/augmentation for
cases where the MAINTAINERS real name does not match the
GitLab account real name
The former would need refreshing when we add new MAINTAINERS
entries, if the person had to be added as a GitLab account
member. For this purpose scripts/gitlab-map-update can be
used, assuming the user has the 'glab' client tool present
and configured with an access token.
To audit how many maintainers have GitLab handles present/missing
scripts/gitlab-map-check can run a report.
$ ./scripts/gitlab-map-check
Missing GitLab handle for maintainer 'Akihiko Odaki'
Missing GitLab handle for maintainer 'Albert Esteve'
....
Missing GitLab handle for maintainer 'Zhenzhong Duan'
Missing GitLab handle for maintainer 'Zhuoying Cai'
GitLab handles missing: 158 / present: 68
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
c4b3d0074 removed the check that nettle or gcrypt were explicitly
requested as the crypto library to use, breaking the --enable-nettle and
--enable-gcrypt options. Re-add the logic to force usage of nettle or
gcrypt for crypto operations, while still keeping gnutls for TLS.
Fixes: c4b3d0074 (crypto: bump min gnutls to 3.7.5)
Tested-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Luc Michel <luc.michel@amd.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This avoids an interactive prompt that halts execution when
attempting to run the FreeBSD tests due to outdated 14.3
base image:
`Bootstrapping pkg from pkg+https://pkg.FreeBSD.org/FreeBSD:14:amd64/quarterly, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Installing pkg-2.6.2_1...
Newer FreeBSD version for package pkg:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1404000
- running userland: 1403000
Ignore the mismatch and continue? [y/N]:
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
FreeBSD 15 introduces a native inotify implementation rather than
requiring use of the kqueue-based libinotify package. This native
implementation does not generate the extra deleted events, so don't
expect them. However, the original implementation did have a bug that
caused IN_IGNORED to never be generated if you did not also watch for
IN_DELETE_SELF, which affects 15.0 and 15.1, but has been fixed and will
no longer apply in 15.2 / 16.0.
Note that the deleted event check is for the userspace version, since
that governs whether libinotify is being used or not, whereas the
ignored event check is both for the userspace version (to check if we're
using the native syscall) and the kernel version (to check if the kernel
has the bug or not).
All __FreeBSD_version values used here correspond to the value in-tree
at the time of the relevant commits. Since neither commit bumped the
value there will be a window of development snapshots between each
commit and the previous bump that will be incorrectly identified here,
but this is the best we can do, and something users of snapshots should
be prepared to deal with.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The gdb jobs fail on CI and although I can't replicate locally on the
machine I have access to it definitely fixes it for the gitlab CI
machines.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260720180459.2542918-1-alex.bennee@linaro.org>
[This fixes the following CI jobs: aarch64-macos-15-build and
aarch64-macos-26-build.
Removing gdb from macOS jobs skips the softmmu gdbstub tests which
currently hang on GitLab's macOS runners:
qemu-system-aarch64: -gdb unix:path=/var/folders/fc/8_hzw5tx3n7c9c04tzd6tv_40000gn/T/tmpes3paikrqemu-gdbstub/gdbstub.socket,server=on: info: QEMU waiting for connection on: disconnected:unix:/var/folders/fc/8_hzw5tx3n7c9c04tzd6tv_40000gn/T/tmpes3paikrqemu-gdbstub/gdbstub.socket,server=on
gmake[1]: *** [/Users/gitlab/builds/qemu-project/qemu/tests/tcg/multiarch/system/Makefile.softmmu-target:35: run-gdbstub-interrupt] Error 137
gmake: *** [/Users/gitlab/builds/qemu-project/qemu/tests/Makefile.include:75: run-tcg-tests-aarch64-softmmu] Error 2
The following GitLab work item tracks solving the underlying issue that
is hanging softmmu gdbstub tests:
https://gitlab.com/qemu-project/qemu/-/work_items/4063
--Stefan]
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
- [PATCH 0/3] dlcall: correct the syscall number claim and the guest (Ziyang Zhang <functioner@sjtu.edu.cn>)
Link: https://lore.kernel.org/qemu-devel/20260719074730.1520517-1-functioner@sjtu.edu.cn
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEN8FWlNi6l2Sxlz/btEQ30ZwoYt8FAmpef1oACgkQtEQ30Zwo
Yt9/RQv8CqO4yZnBiNnuSlxgz740t7N+5HZDIqP9LR4htpLbdw9FG7NLs179ZME2
aZ2gQGGMutlh8CuZHGs9A587mQT0sBd6KLmSfMcwyM9FnXw5ewzJqQsZ8YmbKwyM
nT4BB9OyYJ0RSndov7iAj1EHn7YyDXr4NoVMdRVv8QCXMin9ztgxcHph4D+AsAHe
0D+iO1aT88pSuYOWMya1XQln/NkL7cQq3NY8w7IdlMA+edDUcmv0LazQRljywxS+
IIcGvVcreUlu/v1w9bbqYrI3BualHVdqkbNAQyNuSNSqAQnHkFb9EKcpY4gpe+ZS
oeoIrHFYu0VM50C/mAE8m+I+iRgJGAlyCaNohpYVj5MQdVZ+hlZx2vpvWGV+4zHG
GrtRvjVhND88GEsYj5pigQS9HMOZ4FnrSjyQ0t6uI6lcKDeCtfTbz8Q49VUD7okA
eO3/JLYJPcrdipFjwfM/ahTXpkgejgCJypD90vCIZpO6UF8A1dp7Fl/07XFXDouz
5b6YkWGE
=i09L
-----END PGP SIGNATURE-----
Merge tag 'pbouvier/pr/plugins-20260720' of https://gitlab.com/p-b-o/qemu into staging
Changes:
- [PATCH 0/3] dlcall: correct the syscall number claim and the guest (Ziyang Zhang <functioner@sjtu.edu.cn>)
Link: https://lore.kernel.org/qemu-devel/20260719074730.1520517-1-functioner@sjtu.edu.cn
# -----BEGIN PGP SIGNATURE-----
#
# iQGzBAABCgAdFiEEN8FWlNi6l2Sxlz/btEQ30ZwoYt8FAmpef1oACgkQtEQ30Zwo
# Yt9/RQv8CqO4yZnBiNnuSlxgz740t7N+5HZDIqP9LR4htpLbdw9FG7NLs179ZME2
# aZ2gQGGMutlh8CuZHGs9A587mQT0sBd6KLmSfMcwyM9FnXw5ewzJqQsZ8YmbKwyM
# nT4BB9OyYJ0RSndov7iAj1EHn7YyDXr4NoVMdRVv8QCXMin9ztgxcHph4D+AsAHe
# 0D+iO1aT88pSuYOWMya1XQln/NkL7cQq3NY8w7IdlMA+edDUcmv0LazQRljywxS+
# IIcGvVcreUlu/v1w9bbqYrI3BualHVdqkbNAQyNuSNSqAQnHkFb9EKcpY4gpe+ZS
# oeoIrHFYu0VM50C/mAE8m+I+iRgJGAlyCaNohpYVj5MQdVZ+hlZx2vpvWGV+4zHG
# GrtRvjVhND88GEsYj5pigQS9HMOZ4FnrSjyQ0t6uI6lcKDeCtfTbz8Q49VUD7okA
# eO3/JLYJPcrdipFjwfM/ahTXpkgejgCJypD90vCIZpO6UF8A1dp7Fl/07XFXDouz
# 5b6YkWGE
# =i09L
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 20 Jul 2026 16:04:42 EDT
# gpg: using RSA key 37C15694D8BA9764B1973FDBB44437D19C2862DF
# gpg: Good signature from "Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.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: 37C1 5694 D8BA 9764 B197 3FDB B444 37D1 9C28 62DF
* tag 'pbouvier/pr/plugins-20260720' of https://gitlab.com/p-b-o/qemu:
docs/about/emulation: sharpen the dlcall boundary and its guest requirements
tests/tcg: correct why the magic syscall number is safe here
contrib/plugins/dlcall: correct the syscall number claim, note the data model
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Since commit d0e8bccafc ("hw/vfio/listener.c: remove CONFIG_KVM"),
the linux/kvm.h include is unconditional. This breaks the build on
targets that lack asm/kvm.h such as sparc and sparc64:
In file included from ../hw/vfio/listener.c:23:
linux-headers/linux/kvm.h:16:10: fatal error: asm/kvm.h: No such file or directory
This include is not needed in listener.c which only uses kvm_enabled()
and kvm_get_max_memslots(), both are declared in "system/kvm.h".
Remove it.
Fixes: d0e8bccafc ("hw/vfio/listener.c: remove CONFIG_KVM")
Cc: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>"
Suggested-by: Alex Williamson <alex@shazbot.org>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721062745.3793066-1-clg@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
CVE-2021-3611 (commit 79fa99831d) restricted the DMA engine to memories
by setting attrs.memory=true, but only applied this to intel_hda_response.
Three other DMA engine access points still use MEMTXATTRS_UNSPECIFIED,
allowing a malicious guest to trigger DMA-to-self-MMIO reentry:
- intel_hda_xfer (line 398): called from the audio timer callback
(hda_codec_xfer -> bus->xfer), so the MemReentrancyGuard does not
fire (engaged_in_io is false outside MMIO dispatch). A guest that
points a BDL entry at the HDA controller's own MMIO BAR can write
audio samples to device registers, triggering whandler side effects
such as starting/stopping streams or injecting codec commands via
CORBWP.
- intel_hda_parse_bdl (line 478): uses pci_dma_read which hardcodes
MEMTXATTRS_UNSPECIFIED. A guest-controlled BDL base address can
point at controller MMIO, allowing the DMA engine to read device
registers as BDL descriptors.
- intel_hda_corb_run (line 333): ldl_le_pci_dma reads the CORB ring
with MEMTXATTRS_UNSPECIFIED, allowing the DMA engine to read
controller MMIO as CORB entries.
Fix all three by passing {.memory = true} explicitly, matching the
fix already applied to intel_hda_response. For intel_hda_parse_bdl,
replace pci_dma_read with pci_dma_rw to pass the controlled attrs.
Fixes: 79fa99831d ("hw/audio/intel-hda: Restrict DMA engine to memories (not MMIO devices)")
Reported-by: Haotian Jiang of Tencent Security (Yunding Lab) <jianghaotian.sunday@gmail.com>
Signed-off-by: Haotian Jiang <jianghaotian.sunday@gmail.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721060941.2989396-1-jianghaotian.sunday@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
In commit 468fa450a7 ("hw/sd: Switch read/write primitive to
buf+len"), `sd_read_byte()` changed its contract to return the read size
rather than the read value (and was renamed to `sd_read_data()`
accordingly). In an error case, however, `sd_read_data()` returns 0 by
means of `dummy_byte` which is the code for the old contract. Moreover,
`sdbus_read_data()` asserts the virtual method `read_data()` (and thus
`sd_read_data()`) to return a non-zero size, i.e. to make progress and
not loop forever. Fix the code to behave like the "DAT read illegal for
command" case.
Fixes: 468fa450a7 ("hw/sd: Switch read/write primitive to buf+len")
Reviewed-by: Bin Meng <bin.meng@processmission.com>
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260720201133.24796-2-shentey@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Cadence GEM queue pointer registers are programmed with the descriptor
ring base, but reads return the descriptor currently being accessed.
The model tracked the current positions separately while continuing to
return the configured base.
The Linux macb driver uses the transmit queue pointer when recovering
from a used-buffer interrupt. A stale priority-queue pointer can make
the driver restart DMA before that queue handles its completion
interrupt, causing queue 0 to repeatedly raise TX_USED.
The primary queue has had this mismatch since the initial model.
Priority queue support later copied the same register-read behavior.
A single-queue machine usually handles TX_COMPLETE before TX_USED and
empties the software queue before the restart check, which kept the
issue hidden there.
Return the current RX and TX descriptor positions on queue-pointer reads
and clear those positions on reset.
Fixes: e9f186e514 ("cadence_gem: initial version of device model")
Fixes: 6710172501 ("cadence_gem: Add queue support")
Cc: qemu-stable@nongnu.org
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260720120731.2022475-1-bin.meng@processmission.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
In commit 1ddda5cd36 we meant to set MSSD=3, but due
to a typo we ended setting MSSD=0. Convert the two other
NATJ and MSSP keys to use hexadecimal notation to avoid
similar copy/paste typos.
Cc: qemu-stable@nongnu.org
Fixes: 1ddda5cd36 ("AppleSMC device emulation")
Reported-by: Matthew Jackson <matthew@pq.io>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-Id: <20260720115336.75063-1-philmd@oss.qualcomm.com>
When bdrv_snapshot_list() returns a negative error code, sn_tab is
uninitialized. The loop does not execute (since i=0 < negative is
false), but the code falls through to g_free(sn_tab) which frees
an uninitialized pointer.
Fixes: f6baed3d14 ("replay: implement replay-seek command")
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260719113216.1177594-1-marcandre.lureau@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The COMPILING_PER_TARGET block uses the abi_ptr type
without including the proper header.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260717232306.378988-2-richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The qxl_phys2virt() call for guest_monitors_config only validates
sizeof(QXLMonitorsConfig), which covers the fixed header (count and
max_allowed) since commit 8efec0ef8b ("hw/display/qxl: Pass requested
buffer size to qxl_phys2virt()"), but not the flexible array member
heads[]. When count == 1, heads[0] is accessed without its memory being
validated, allowing a guest to cause an out-of-bounds read.
Include sizeof(QXLHead) in the size passed to qxl_phys2virt() so that
the first head entry is validated within the guest memory slot, preventing
guest-visible memory reading.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4027
Reported-by: Tristan @TristanInSec
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260715072722.1643289-1-marcandre.lureau@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
In qemu_receive_packet() we check to see if we should pad a short
packet. This is doing the wrong test: because this function is used
when the device adds a packet to its own incoming queue (i.e. for
loopback), we should be checking the NetClientState's own do_not_pad
flag, not that for its peer.
We didn't notice this earlier, because at the moment all the real
peers of a network device (i.e. the network backends) do not set
do_not_pad, so net_peer_needs_padding() always returns true except in
the corner case where the network device has no peer at all.
The effect of this is that if a network device has no peer (e.g.
because QEMU was started with -net none or with -nodefaults) then we
can still let through the kind of "guest misprograms the network
device to loopback-transmit a short packet and then we mishandle it
in the receive path" bug like #3043 which commit a01344d9d7 was
trying to fix.
Since the distinction between "we should check nc->do_not_pad"
and "we should check nc->peer->do_not_pad" is a bit subtle, add
enough documentation commentary to make it more obvious.
Cc: qemu-stable@nongnu.org
Fixes: a01344d9d7 ("net: pad packets to minimum length in qemu_receive_packet()")
Suggested-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Bin Meng <bin.meng@processmission.com>
Message-ID: <20260629164246.2028947-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Record the same data model requirement as the plugin: guest_base == 0 is
necessary but not sufficient.
Describe the magic syscall number the way the plugin now does. It has to be a
number the guest ABI does not use and does not reject before the plugin sees
it, rather than merely a high one, so show syscall_num= being used as well.
A library is not turned into thunks, it is left alone and the thunks are
produced for it, so say that instead. Argument marshalling, callbacks and
variadic functions are also what the plugin does not do, and listing them in
its description blurs the boundary it draws. Move them to Lorelei, where they
are pointed at as a reference.
Co-authored-by: Kailiang Xu <xukl2019@sjtu.edu.cn>
Co-authored-by: Mingyuan Xia <xiamy@ultrarisc.com>
Signed-off-by: Ziyang Zhang <functioner@sjtu.edu.cn>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260719074730.1520517-4-functioner@sjtu.edu.cn
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
The comment said 4096 was picked because no ISA in Linux uses it. The same
comment already notes that mips 32 bits numbers from 4000, which makes 4096 its
getpriority.
What actually keeps this test safe is the filter, which matches on the first
argument as well, so a real syscall carrying this number is left alone. Say
that instead.
Co-authored-by: Kailiang Xu <xukl2019@sjtu.edu.cn>
Co-authored-by: Mingyuan Xia <xiamy@ultrarisc.com>
Signed-off-by: Ziyang Zhang <functioner@sjtu.edu.cn>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260719074730.1520517-3-functioner@sjtu.edu.cn
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
The comment claimed every Linux ABI keeps its syscall numbers well below the
minimum, and that the minimum is all N has to satisfy. Neither holds.
MIPS O32 bases its numbering at 4000, so the default 4096 is its getpriority.
Raising N does not rescue it either, because O32 answers numbers its table does
not define with ENOSYS before the filter runs, which leaves no number that is
both free and reachable on that ABI. arm32 bounds N from above too, with ENOSYS
or SIGILL past ARM_NR_BASE. Say all of this, so the number can be chosen with
the target in mind.
guest_base == 0 is not the only requirement either. Host pointers are written
back through the caller's out pointers, so the guest must match the host's
pointer width and endianness. Fold that into the existing warning.
Also assert the two out pointers that lacked it, and point at Lorelei for
argument marshalling, callbacks and variadic functions.
Co-authored-by: Kailiang Xu <xukl2019@sjtu.edu.cn>
Co-authored-by: Mingyuan Xia <xiamy@ultrarisc.com>
Signed-off-by: Ziyang Zhang <functioner@sjtu.edu.cn>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260719074730.1520517-2-functioner@sjtu.edu.cn
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
In c8bea1276c we moved cpu32.c and built it as a common object. The
commit message says "cpu32.c only contains CPU types used in 32-bit
system emulation". However, this is incorrect -- it contains 32-bit
CPU types used in both system and usermode emulation. (The case
where we don't need these CPUs and which we were using ifdefs to
avoid is specifically the AArch64 usermode qemu-aarch64 binary.)
The effect is that qemu-arm lost all the named CPU types except
the M-profile ones (which are in cpu-v7m.c).
This reverts commit c8bea1276c.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3962
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-id: 20260720100312.119894-1-peter.maydell@linaro.org
The hw/dma/soc_dma.c code appears to have been written with the idea
that it abstracts out DMA transfer operations from the details of a
particular DMA controller device. In practice, it's used only by the
omap_dma code and I would not today recommend trying to use it in any
new DMA device. Add the files to the OMAP section of MAINTAINERS so
that patches can be cc'd to the appropriate places.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-10-peter.maydell@linaro.org
omap_dma.h is the header file for hw/dma/omap_dma.c; it fits better
to put it in include/hw/dma/ to match where we have the .c file.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-9-peter.maydell@linaro.org
Now that transfer_mem2mem() uses physical_memory_map(), the
soc_dma_ch_s::paddr field is unused; remove it, and the code that set
it, and the memmap_entry_s::mem.base and the soc_dma_port_add_mem()
phys_base argument that were passing around host pointers to use for
setting paddr.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-8-peter.maydell@linaro.org
The soc_dma code has a fastpath for when DMA transfers are from RAM
to RAM. The current implementation of this has the caller of
soc_dma_port_add_mem() pass the underlying host address of the RAM
block that the DMA port is connected to (obtained via
memory_region_get_ram_ptr()). Then the actual transfer function does
a simple memcpy(). This has several problems.
Most importantly, no bounds checking is done on the address and size
passed by the guest, so the memcpy source and destination might be
outside the backing host RAM entirely. Secondly, because the DMA
access is done via this back door, there is no updating of the dirty
region when memory is written this way (there is a TODO comment
in omap_dma.c noting this).
Fix both of these by making the memory to memory transfer function
use physical_memory_map() to get the host addresses for the memory
copy. That function will automatically give us the bounds check that
we want and return a short length if the transfer would run off the
end of the RAM MemoryRegion it starts in. Since the OMAP DMA
documentation states that it's a guest error to misprogram the
addresses so that they fall outside the range that is valid for the
particular DMA port being addressed and that this can result in guest
memory corruption , we don't need to loop for short transfers, but
can simply log them and continue.
Note that we don't need to update addresses or bytecount here in the
transfer function, because when soc_dma_ch_update() selects
transfer_mem2mem it also sets ch->update to 1, which tells the
omap_dma_transfer_setup() code that it is responsible for updating
all the guest visible fields to match "transfer completed".
(We use physical_memory_map() here to match the use of
physical_memory_read() and physical_memory_write() in omap_dma.c;
making the DMA controller use an explicit AddressSpace would be
a separate cleanup task.)
Together with the preceding commits that fixed some integer overflow
problems, this fixes the "guest can provoke a bad memcpy() operation"
reported in issue #3204.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3204
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-7-peter.maydell@linaro.org
The worst case number of DMA bytes that omap_dma will ask us to
transfer is 0xffff * 0xffff * 4 == 0x3fff80004, which is slightly
larger than fits into a uint32_t. Move the byte count to uint64_t,
and adjust code that passes it around to also use uint64_t.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Jim MacArthur <jim.macarthur@linaro.org>
Message-id: 20260710105907.2570621-6-peter.maydell@linaro.org
In omap_dma_transfer_setup(), the maximum number of elements we can
transfer is 0xffff * 0xffff == 0xfffe0001 (because the max frame
count and max elements per frame are both 65535). However, we store
total element counts in 'int' variables, and use INT_MAX as a "bigger
than any valid value" sentinel, and when performing arithmetic with
the total count of transferred elements we are not careful about
avoiding overflows. Fix these:
- use uint32_t rather than int for the local variables tracking
various element and frame counts
- use UINT_MAX as our sentinel
- calculate new packet, element and frame counter values using
arithmetic on a local uint32_t, rather than doing it in-place
on local variables that are only 'int' because the actual
counter registers are 16 bits
- use 64-bit arithmetic when calculating how much to advance the
source and dest pointers and the total dma->bytes transferred
Note that since soc_dma_ch_s::bytes is only 'int' this can still
overflow; we'll fix that in a subsequent patch.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Jim MacArthur <jim.macarthur@linaro.org>
Message-id: 20260710105907.2570621-5-peter.maydell@linaro.org
There's only one field in the union inside memmap_entry_s now that
we've removed the soc_dma_port_fifo handling. Simplify by removing
the union.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-4-peter.maydell@linaro.org
Now we only have "mem" and "other" as soc_dma_port_type values, we
can simplify soc_dma_ch_update(): either both src and dst are mem, in
which case we use transfer_mem2mem and set update to 1 to tell
omap_dma_transfer_setup() to update all the guest-visible
src/dest/count information to indicate a completed transfer; or else
we use the omap_dma_transfer_generic() function, and we set update to
0 to tell omap_dma_transfer_setup() that the transfer function will
be updating the src/dest/count.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260710105907.2570621-3-peter.maydell@linaro.org
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Our current single OMAP SoC doesn't call the soc_dma_port_add_fifo(),
soc_dma_port_add_fifo_in() or soc_dma_port_add_fifo_out() functions.
Remove them, plus the soc_dma_port_fifo handling that only those
functions needed.
The motivation for this is that it removes a lot of code that is
careless about the fact that the largest possible DMA transfer is
more bits than will fit into an "int" variable, and which does direct
accesses to host memory pointers into guest backing RAM without doing
bounds checks. Deleting this code means we don't have to audit and
update it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-2-peter.maydell@linaro.org
MTX is always a pair of bits, one for each half of the address space.
Testing it like a boolean is incorrect.
Introduce raw_mte_check, a mirror of the similar mte_check function
that applies when MTX is passed in MTEDESC.
Fixes: 8912ceced8 ("target/arm: load on canonical tag loads ext bits")
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260717161430.37264-1-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The helper_lscbx() function isn't called anywhere. It used to be
used by the PPC 601 CPU support; we removed that in commit 005b69fdcc
in 2022 but missed this helper function.
Fixes: 005b69fdcc ("target/ppc: Remove PowerPC 601 CPUs")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Message-id: 20260709095056.1803725-1-peter.maydell@linaro.org
The ICC_APR_EL1 register values change the current running priority,
which we use in our calculations in gic_hppi(). Changing them can
affect whether we have a HPPI, and so the value of the IRQ/FIQ
outputs. We need to trigger an update in the register writefn.
Fixes: 9bd90bddb7 ("target/arm: GICv5 cpuif: Signal IRQ or FIQ")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260714091806.3568281-3-peter.maydell@linaro.org
In gicr_cdia_read() we turn a PPI interrupt ID into a register
index and a bit mask with a 1 for the bit we want to change:
ppireg = id / 64;
ppibit = 1ULL << (id % 64);
However, we used the wrong type for ppibit, making it a uint32_t. If
'id' is too large we'll shift off the end, so we won't ever update
the state of PPIs with indexes above 31.
This didn't have any visible effects because the currently allocated
architected PPIs are indexes 0..31, so you'd only see this if for
some reason a guest was manually marking as pending a PPI in 32..63.
Fix the type of ppibit to the intended 64 bit width.
Fixes: 3f79212aba ("target/arm: GICv5 cpuif: Implement GICR CDIA command")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260714091806.3568281-2-peter.maydell@linaro.org
The Marvell 88E1111 PHY register 17 (PHY Specific Status Register)
bit 10 reports real-time link status. Previously, this register
returned a fixed value of 0x8800 with bit 10 always cleared,
causing U-Boot to always detect "No link" even when the link
was up.
Signed-off-by: Jay Chang <jay.chang@sifive.com>
Reviewed-by: Frank Chang <frank.chang@sifive.com>
Message-id: 20260713064617.85374-1-jay.chang@sifive.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The imx_serial vmstate is missing the ucr2 field. This register
includes important state like the transmit enable and receive enable
bits, so it's likely that after a migration the UART will be in a
completely broken state. This bug has been present ever since
the UART code was first added to QEMU.
Add ucr2 from imx_serial to vmstate, and increment the version_id.
This is a migration compatibility break, but this UART is only used
in the various imx-based boards, where we are OK with compat breaks.
Migrating on sabrelite can reproduce this issue:
1. Prepare the U-Boot required for sabrelite. (according to sabrelite.rst)
2. Compile qemu
$ mkdir build && cd build && ../configure --target-list="arm-softmmu" && make -j4
3. Start sabrelite and prepare for migration
$ ./build/qemu-system-arm -M sabrelite \
-smp 1 -m 1G -display none -serial null -serial mon:stdio \
-kernel ~/u-boot
4. Enter qemu monitor after uboot. (ctrl + a + c)
(qemu) stop
(qemu) xp /4wx 0x021e8084
021e8084: 0x00004027 0x00000784 0x00008000 0x00000a01
(qemu) migrate -d file:vmstate
(qemu) q
Load the migrated vmstate, before repairing:
$ ./build/qemu-system-arm -M sabrelite \
-smp 1 -m 1G -display none -serial null -serial mon:stdio \
-kernel ~/u-boot -incoming file:vmstate
(ctrl + a + c)
QEMU 11.0.50 monitor - type 'help' for more information
(qemu) xp /4wx 0x021e8084
021e8084: 0x00000004 0x00000784 0x00008000 0x00000a01
(qemu) q
It can be found that the data for address 0x021e8084 (register of usr2 in imx_serial of sabrelite)
is not the data before the migration.
After being repaired:
$ ./build/qemu-system-arm -M sabrelite \
-smp 1 -m 1G -display none -serial null -serial mon:stdio \
-kernel ~/u-boot -incoming file:vmstate
(ctrl + a + c)
QEMU 11.0.50 monitor - type 'help' for more information
(qemu) xp /4wx 0x021e8084
021e8084: 0x00004027 0x00000784 0x00008000 0x00000a01
Cc: qemu-stable@nongnu.org
Fixes: 40b6f91151 ("i.MX: UART support")
Signed-off-by: Tao Ding <dingtao0430@163.com>
Message-id: 20260715131819.14827-2-dingtao0430@163.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The QEMU s390x CI gitlab-runner recently broke because qemu-iotests 108
FUSE mount leaked and prevented the setup of the gitlab-runner
environment:
chmod: cannot access '/home/gitlab-runner/builds/P3MFS4LUf/0/qemu-project/qemu/build/scratch/qcow2-file-108/fuse-export': Transport endpoint is not connected
https://gitlab.com/qemu-project/qemu/-/jobs/14796143507#L11
Always umount the FUSE export when cleaning up to prevent the leak.
Closes: https://gitlab.com/qemu-project/qemu/-/work_items/3541
Cc: Hanna Czenczek <hreitz@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260611125438.194479-1-stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
One patch for the linux-user to fix the sparc target regarding signal handling.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCal0ZRgAKCRD3ErUQojoP
X1K5AP0XoVwQ54p3sZgkQ81yHjH4Y4IUL/UKrAzDwLXQn05qbQEA3BpI+4JK03/N
bxXzomlXJbSXlggNTf2pKCwRwGu6/QA=
=odCr
-----END PGP SIGNATURE-----
Merge tag 'linux-user-for-v11.1-pull-request' of https://github.com/hdeller/qemu-hppa into staging
linux-user for v11.1 pull request
One patch for the linux-user to fix the sparc target regarding signal handling.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCal0ZRgAKCRD3ErUQojoP
# X1K5AP0XoVwQ54p3sZgkQ81yHjH4Y4IUL/UKrAzDwLXQn05qbQEA3BpI+4JK03/N
# bxXzomlXJbSXlggNTf2pKCwRwGu6/QA=
# =odCr
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 19 Jul 2026 14:36:54 EDT
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: aka "Helge Deller <deller@debian.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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'linux-user-for-v11.1-pull-request' of https://github.com/hdeller/qemu-hppa:
linux-user/sparc: Take pending signals in sparc64_set_context()
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Some machines like the microvm machine instantiate a "sysbus-xhci"
device with just 1 interrupt (by setting the "intrs" property to 1).
xhci_sysbus_realize() then only allocates the s->irq array with one
entry.
When the guest writes to the ERDP register of a corresponding XHCI
"interrupter", the generic XHCI code calls the xhci_sysbus_intr_raise()
function with n > 1, and this function then calls qemu_set_irq() with
s->irq[n] pointing to a bad heap address. The qemu_set_irq() then tries
to call an IRQ handler via a function pointer in that heap space. This
either causes QEMU to die with a segmentation fault (if it's a bad
address), or even worse runs some unexpected code if the destination
of the pointer is executable code.
Looking at the xHCI spec, it is up to the implementation of the host
controller how many interrupters are available. So if we only support
one or some few interrupters, the registers of the other interrupters
should not do anything, i.e. reads should result in zeros and writes
should be completely ignored. (big thanks to Peter Maydell for helping
with the analyzation of the correct way to fix this here)
This way, the xhci_sysbus_intr_raise() function cannot be called with
an invalid interrupt number anymore. But for good measure, also add an
assert() statement to the xhci_sysbus_intr_raise() function to prevent
that similar problems with calling arbitrary function pointers on the
heap could occur again.
Fixes: CVE-2026-16043
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4001
Reported-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260719061528.15587-1-thuth@redhat.com>
The assert() statement in xhci_find_stream() can be triggered by
the guest (see bug tickets #273, #3895 and #3988 on gitlab.com).
Turn it into a qemu_log_mask() instead to fix this problem.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/273
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260715203357.424556-1-thuth@redhat.com>
A malicious usbredir peer can send an ep_info message resetting
max_packet_size to 0 after bulk receiving has started. This causes:
- infinite loop in usbredir_buffered_bulk_packet() where the splitting
loop increments by max_packet_size (0)
- SIGFPE in usbredir_buffered_bulk_in_complete_ftdi() from modulo by 0
- SIGFPE in usbredir_handle_buffered_bulk_in_data() from division by 0
when computing bytes_per_transfer
Fix by stopping and disabling bulk receiving in usbredir_ep_info() when
max_packet_size is set to 0.
Add post-load check, and assert() for the invariant.
Fixes: CVE-2026-63319
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3995
Reported-by: Tristan @TristanInSec
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260716141107.3597076-1-marcandre.lureau@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
When usbredir_buffered_bulk_packet() splits a multi-fragment buffered
bulk packet into max-packet-size chunks, only the final fragment owns
the shared parser allocation (via free_on_destroy). If bufp_alloc()
drops the final fragment due to queue overflow, it frees the backing
buffer while earlier fragments already queued still hold interior
pointers into it. Subsequent guest bulk-IN transfers then read from
freed heap memory.
Fix this by tracking how many fragments were queued during the current
packet. When bufp_alloc() fails, remove all already-queued fragments
from the tail of the endpoint queue before breaking out of the loop.
If the dropped fragment was non-final, free the data buffer explicitly
since no fragment took ownership.
Fixes: CVE-2026-15705
Fixes: b2d1fe67d0 ("usbredir: Add support for buffered bulk input (v2)")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3808
Reported-by: Feifan Qian <bea1e@proton.me>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260714185717.1156157-1-marcandre.lureau@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Add a qtest that hot-adds an nec-usb-xhci controller, requests unplug,
resets the system to process the request, and waits for DEVICE_DELETED.
This covers the xHCI PCI host-link refcount cycle by verifying that
device_finalize() runs after unplug.
Signed-off-by: Xiangfeng Cai <caixiangfeng@bytedance.com>
Message-ID: <20260618110119.3084296-3-caixiangfeng@bytedance.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The xHCI PCI wrapper embeds an xhci-core child via object_initialize_child()
and, in usb_xhci_pci_realize(), points the child's "host" link back at the PCI
device:
object_property_set_link(OBJECT(&s->xhci), "host", OBJECT(s), NULL);
"host" is a DEFINE_PROP_LINK property, which qdev registers as an
OBJ_PROP_LINK_STRONG link. A strong link takes a reference on its target, so
this creates a refcount cycle: the PCI device owns the child, and the child's
strong link pins the PCI device.
On unplug (guest ACPI eject or QMP device_del), pci_qdev_unrealize() calls
pc->exit() but never unrealizes the no-bus child. object_unparent() then drops
only the parent/bus references, leaving the link reference in place. The PCI
device stays at refcount 1 forever, so object_finalize()/device_finalize() is
never reached. Symptom observed under gdb after eject:
p *((Object *)dev) => ref = 1, parent = 0x0, realized = false
p ((XHCIPciState *)dev)->xhci.hostOpaque => points back at dev
Fix usb_xhci_pci_exit() to tear down the embedded child explicitly: unrealize
it first (so the set-link-before-realize check passes), then clear the "host"
link. This releases the strong reference, lets the PCI device refcount reach 0,
and allows device_finalize() to run.
Fixes: 8ddab8dd3d ("usb/hcd-xhci: Split pci wrapper for xhci base model")
Signed-off-by: Xiangfeng Cai <caixiangfeng@bytedance.com>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260618110119.3084296-2-caixiangfeng@bytedance.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The xHCI endpoint context dword 0 bits 23:16 ("Interval") are written
by the guest and passed directly as the shift amount in:
epctx->interval = 1 << ((ctx[0] >> 16) & 0xff);
The shift amount can be 0-255. Shifting a 32-bit `int` left by >= 32
is undefined behaviour under C11 §6.5.7p4. With UBSan
(halt_on_error=1) this causes QEMU to abort; with aggressive compiler
optimisations that assume UB is unreachable the result is
unpredictable.
Clamp the exponent to [0, 18] with MIN() before the shift, and use
`1u` (unsigned) to avoid shifting a signed integer. The xHCI
specification defines a maximum meaningful Interval value of 18 for
most endpoint types; thus clamping to 18 is a safe fix that
preserves the full unsigned 32-bit range for any compliant value.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3703
Reported-by: Feifan Qian <bea1e@proton.me>
Signed-off-by: Feifan Qian <bea1e@proton.me>
[thuth: Clamp to 18 instead of 31]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Every callsite of block_signals() checks its return value, except
the one in sparc64_set_context(). Generally you need to check,
because the standard pattern is:
if (block_signals()) {
return -QEMU_ERESTARTSYS;
}
/* do some blocking syscall */
and we need to take any pending signal before we do the blocking
operation, not afterwards.
The use in sparc64_set_context() doesn't do this. It doesn't have to
because the operations it is doing aren't blocking, so it won't get
into "we didn't take the signal that we should have" races that
blocking syscalls do. But it does make this way of updating the
signal mask inconsistent with how we do it in do_sigprocmask().
do_sigprocmask() does the usual "return -QEMU_ERESTARTSYS", so a
pending signal that was not blocked by the old signal mask and which
will be blocked by the new mask we're about to install will be taken
before we change the mask. sparc64_set_context() doesn't check the
return value, so we won't take that pending signal. That's not
wrong, because it just means the signal lost the race with the
executing code. But it seems clearer to behave the same way as
do_sigprocmask(), not differently.
Make sparc64_set_context() check the return value of block_signals()
and return early if there's a pending signal to take. We don't need
to return a separate return code to indicate this because the main
loop handles it the same either way.
Coverity CID: 1660058
Fixes: e0f0ce88eb ("linux-user/sparc: call block_signals() before set_sigmask() in setcontext")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Add new test cases from hexagon-arch-tests to exercise exceptions,
guest mode.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Add hex_next_PC, a global mirroring CPUHexagonState::next_PC,
and ctx->need_next_pc, so that gen_write_new_pc_addr() can write the
branch target through hex_next_PC instead of hex_gpr[HEX_REG_PC]
when a later unconditional write of PC is expected. gen_end_tb()
then commits hex_next_PC into hex_gpr[HEX_REG_PC] at the end of the
packet.
Previously, non-COF instructions that still end a TB did not advance the
PC, since next_PC's value was never written back into the PC register.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Unconditionally allocate and initialize the temp to the sreg's current
value for every logged sreg write, rather than only allocating
when need_commit is set or the register is SSR.
Without this, reading a deferred sreg write within the same packet
before it is committed can observe an uninitialized temp instead
of the register's pre-packet value.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
As documented:
* @get_phys_addr_debug: Callback for obtaining a physical address.
* This must be able to handle a non-page-aligned address, and will
* return the physical address corresponding to that address.
When MMU is enabled, hexagon_cpu_get_phys_addr_debug() returns the
physical address page-aligned, not corrected to reflect the exact byte
the virtual addr maps to within the page. Let's fix that. The
MMU-disabled case is already correct.
This would break semihosting argument reads when it is added for Hexagon.
Signed-off-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Add unaligned_data.c to exercise unaligned memh/memw/memd accesses and
verify SIGBUS is raised and caught.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
hexagon-softmmu had no enforcement of alignment for scalar loads and
stores: the MO_ALIGN flag added by the previous two commits triggers
TLB_INVALID_MASK/alignment faults in cputlb.c, but Hexagon's
TCGCPUOps did not implement do_unaligned_access, so the fault was
never delivered to the guest.
Add hexagon_cpu_do_unaligned_access(), which raises
HEX_CAUSE_MISALIGNED_LOAD/_STORE via the existing HEX_EVENT_PRECISE
path, mirroring raise_tlbmiss_exception()/raise_perm_exception().
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
hexagon-linux-user had no enforcement of alignment for scalar store
exceptions, and unaligned stores silently succeeded instead of raising
SIGBUS.
Stores are logged rather than committed immediately, so both commit
paths need the fix.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
hexagon-linux-user had no enforcement of alignment for scalar load
exceptions, and unaligned loads silently succeeded instead of raising
SIGBUS.
Add MO_ALIGN to the MEM_LOAD* macros, the locked-load and
load-frame helpers in genptr.c, and the idef-parser's fLOAD.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Add a linux-user cpu_loop handler for HEX_CAUSE_MISALIGNED_LOAD and
HEX_CAUSE_MISALIGNED_STORE, raising SIGBUS for consistency with
hexswi.c's sysemu handling, even though linux-user's own alignment
check in accel/tcg/user-exec.c currently raises SIGBUS before
Hexagon's cause-code machinery is reached.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
With --disable-hexagon-idef-parser, tcg_funcs_generated.c.inc fails
to build under GCC 14 with:
error: declaration of 'HALF' shadows a previous local
[-Werror=shadow=local]
This became a hard error with GCC ced651b7757e `c23: tag compatibility
rules for enums`.
After that GCC change, DECL_FILE_SCOPE_P is false for all
enumerators, so shadowing now falls under -Wshadow=local.
Rename the local variable to tmp_half to avoid the collision.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Add hexagon-softmmu to build-system-debian's target list so that the
existing functional-system-debian job picks up hexagon functional
test.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
The debian-hexagon-cross image previously unpacked the codelinaro
clang+llvm hexagon toolchain by piping a .tar.zst archive straight
into "tar --zstd -xC". GNU tar restores the archive's stored file
modes on extraction, including lchmod() on symlinks. Under rootless
podman, where the build runs in a user namespace on overlay storage,
those chmod()/lchmod() calls are rejected with EPERM:
tar: .../libclang_rt.builtins.a: Cannot change mode to rwxrwxrwx: \
Operation not permitted
tar: .../x86_64-linux-gnu: Cannot change mode to rwxr-xr-x: \
Operation not permitted
tar: Exiting with failure status due to previous errors
tar then exits non-zero and aborts the build, so debian-hexagon-cross
only builds reliably under docker, not rootless podman.
So instead we can switch to a different packaging. clang, lld
come from LLVM Debian builds from apt.llvm.org, instead of custom ones for
hexagon. And only the hexagon linux sysroot is required, avoiding the
tar issues.
Reviewed-by: Matheus Tavares Bernardino <quic_mathbern@quicinc.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Small cleanups for the postcopy blocktime fine-grained tracking
feature:
* Remove a redundant memset() on latency_buckets after g_new0().
* Use singular "Latency" in the HMP label for postcopy non-vCPU
latency, consistent with other single-value labels.
Signed-off-by: Bin Guo <guobin@linux.alibaba.com>
Link: https://lore.kernel.org/r/20260716101952.65329-4-guobin@linux.alibaba.com
Signed-off-by: Peter Xu <peterx@redhat.com>
vcpu_faults_current[] is uint8_t. The overflow assert was checked
after the post-increment, so 255 would wrap to 0 and the assert
would pass silently. Move the check before the increment and use
< 255.
Signed-off-by: Bin Guo <guobin@linux.alibaba.com>
Link: https://lore.kernel.org/r/20260716101952.65329-2-guobin@linux.alibaba.com
Signed-off-by: Peter Xu <peterx@redhat.com>
pixman_image_create_bits() returns NULL for allocation failures and
unaligned strides, which may be supplied by the guest with
VIRTIO_GPU_CMD_SET_SCANOUT_BLOB, and virtio_gpu_do_set_scanout()
subsequently dereferences it.
Fixes: fa06e5cb7b ("virtio-gpu: fix scanout rectangles")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260717-pixman-v1-1-89ea33b50b75@rsg.ci.i.u-tokyo.ac.jp>
VIRTIO_GPU_CMD_SET_SCANOUT_BLOB supplies a guest-controlled uint32_t
stride, but some downstream consumers take it as int. They may interpret
a value greater than INT_MAX as negative and cause issues:
- pixman_image_create_bits() takes the stride as int, and Pixman may
later access memory before the blob buffer.
- eglCreateImageKHR() also takes the stride as EGLint when importing the
DMA-BUF, and Mesa rejects it.
Reject such strides before scanout.
The check in virtio_gpu_scanout_blob_to_fb() rejects unsupported blob
configurations early. The check added in virtio_gpu_do_set_scanout()
covers migration post_load.
Fixes: 32db3c63ae ("virtio-gpu: Add virtio_gpu_set_scanout_blob")
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260717-int-v1-1-8aa05e1791a0@rsg.ci.i.u-tokyo.ac.jp>
An unbounded iov_cnt from the migration stream drives two g_new()
allocations whose combined size can exceed available memory, causing
GLib to abort the process.
Switch to g_try_new() and propagate the failure as a migration error.
Fixes: 0c244e50ee ("virtio-gpu: add live migration support")
Fixes: f66767f75c ("virtio-gpu: add virtio-gpu/blob vmstate subsection")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3753
Reported-by: Feifan Qian <bea1e@proton.me>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Both virgl_cmd_submit_3d() and rutabaga_cmd_submit_3d() pass the
guest-controlled cs.size directly to malloc() without bounds checking. A
malicious guest can set cs.size to an arbitrarily large value, causing
an OOM abort that crashes the QEMU process.
Checking cs.size against the descriptor payload length (iov_size) is not
sufficient: indirect descriptor tables can repeat entries aliasing the
same guest-physical range, inflating iov_size() to nearly 4 GiB while
referring to only a small amount of unique memory.
Instead, cap cs.size at 4 MiB. With 4 KiB pages and QEMU's
VIRTQUEUE_MAX_SIZE (1024) mapped-iov limit, the Linux virtio driver
cannot carry more than ~4 MiB of inline command data, so legitimate
submissions are unaffected.
Fixes: 9d9e152136 ("virtio-gpu: add 3d mode and virgl rendering support.")
Fixes: 1dcc6adbc1 ("gfxstream + rutabaga: add initial support for gfxstream")
Fixes: d52c454aad ("contrib: add vhost-user-gpu")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3776
Reported-by: admin@fluentlogic.org
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Validate that the framebuffer stride is at least width * bytes_per_pixel
in both virtio_gpu_scanout_blob_to_fb() and virtio_gpu_do_set_scanout().
A guest can set a very small stride while using a large width. The total
size check (offset + stride * height <= blob_size) passes because
stride * height is small, but pixman reads width * bytes_per_pixel per
row, causing heap OOB reads. The leaked data is rendered to the host
display.
The check is added in virtio_gpu_do_set_scanout() to cover all paths:
blob scanout, non-blob scanout and migration post_load. The additional
early check in virtio_gpu_scanout_blob_to_fb() rejects invalid blob
configurations early.
Fixes: CVE-2026-63109
Fixes: 7b55742254 ("hw/display: check frame buffer can hold blob")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3989
Reported-by: Tristan @TristanInSec
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Snapshot chunk.data_size into a host-local variable before passing it to
qxl_phys2virt() for validation, and pass it through qxl_cursor() and
qxl_unpack_chunks() so that no subsequent code re-reads the field.
Without this, a racing vCPU can inflate data_size between the
qxl_phys2virt() validation and the memcpy in qxl_unpack_chunks(),
causing a source read past the validated region. In practice the read
stays within the guest's own VRAM mmap, so the impact is limited.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3757
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reported-by: Feifan Qian <bea1e@proton.me>
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
When virtio_gpu_create_udmabuf() succeeds but virtio_gpu_remap_udmabuf()
fails (mmap returns MAP_FAILED), virtio_gpu_init_udmabuf() returns early
without closing the dmabuf fd. Since res->blob is never set in this
path, later cleanup via virtio_gpu_cleanup_mapping() skips
virtio_gpu_fini_udmabuf() entirely, leaking the file descriptor.
Call virtio_gpu_destroy_udmabuf() before the early return to close
the fd. This function already handles partial state correctly: it
skips the munmap when res->remapped is NULL and closes the fd when
res->dmabuf_fd >= 0.
Fixes: 9b60cdf987 ("virtio-gpu: Add udmabuf helpers")
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The VNC SetPixelFormat message carries red/green/blue_max as 16-bit
values, but PixelFormat stores them as uint8_t. A client sending a
max value above 255 (e.g. 0x0100) passes the existing non-zero check
but silently truncates to 0 on assignment, leading to a division by
zero in the Tight PNG palette path.
Add explicit range checks if any channel max exceeds UINT8_MAX.
Fixes: CVE-2026-15578
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3976
Reported-by: dong ling
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
vnc_refresh_lossy_rect() marks a full VNC_STAT_RECT (64) rows of the
dirty bitmap when refreshing a lossy tile. When the display height is
not a multiple of VNC_STAT_RECT, the last tile row is a partial tile and
the loop writes past the end of vs->dirty[VNC_MAX_HEIGHT].
For example, with a 2160-pixel-high display (VNC_MAX_HEIGHT), the last
stat tile starts at y=2112. The unconditional 64-row loop writes rows
2112..2175, overflowing 16 rows (640 bytes) past the dirty bitmap into
subsequent VncState fields.
Fix by passing the effective display height into
vnc_refresh_lossy_rect() and clamping the inner loop.
Fixes: CVE-2026-61475
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3935
Reported-by: "Vulnerability Report" <vr@darknavy.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
Scanout operations need to be properly ordered to avoid tearing. The
virtio specification allows the guest to use pageflip. With pageflip,
the guest only modifies the invisible framebuffer while the host scans
out the visible framebuffer. The guest may choose not to use pageflip to
avoid its overhead, accepting the risk of tearing.
ui/gtk performs the following procedure to flush a scanout:
1) Queue a draw event.
2) The draw event gets triggered.
3) Blit the guest framebuffer to the host framebuffer.
When flushing a DMA-BUF scanout, ui/gtk blocks the device before 2) if
possible and unblocks it after 3) to enforce proper ordering. However,
blocking the device before 2) has two problems.
First, it can leave the device blocked indefinitely because GTK
sometimes decides to cancel 2) when the window is not visible for
example. ui/gtk regularly repeats 1) as a workaround, but it is not
applicable to GtkGLArea because it causes display corruption.
Second, the behavior is inconsistent with the other types of scanout
that leave the device unblocked between 1) and 2).
To fix these problems, let ui/gtk block the device only when the
queued draw event runs, immediately before 3). Blocking before that is
unnecessary since ui/gtk does not access the framebuffer yet. If the
guest does not use pageflip but instead updates the visible framebuffer
directly, ui/gtk should not add the overhead of a pre-draw block.
ui/gtk still blocks the device during 3) for DMA-BUF. Unlike the other
scanout types, 3) can happen asynchronously with the device for a
DMA-BUF, so ui/gtk needs to keep the visible guest framebuffer stable
for the blit.
With the problems fixed, the workaround to repeat 1) is no longer
necessary and is removed.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260628-gtk-v2-1-1e4839012f09@rsg.ci.i.u-tokyo.ac.jp>
Use exact-width unsigned types for the static functions that process
RFB client messages, matching the types returned by read_u8(),
read_u16(), and read_u32():
- set_pixel_format: uint8_t/uint16_t for pixel format fields
- pointer_event: uint8_t button_mask, uint16_t x/y
- key_event/ext_key_event: bool down, uint32_t sym/keycode
- do_key_event: uint32_t sym
- framebuffer_update_request: uint8_t incremental, uint16_t x/y/w/h
Drop needless declarations.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
A malicious VNC client can send a SetPixelFormat message with shift
values >= 32, causing UB mask computation
(e.g. red_max << red_shift where red_shift is 255). Apparently, this is
not covered by -fwrapv.
Reject color shifts >= bits_per_pixel || 32 before computing masks.
Fixes: 9f64916da2 ("pixman/vnc: use pixman images in vnc.")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3948
Reported-by: huntr bubble
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
vnc_refresh_lossy_rect() always marks a full VNC_STAT_RECT (64) rows
as dirty when refreshing a lossy tile. When the display height is not
a multiple of VNC_STAT_RECT (e.g. VNC_MAX_HEIGHT = 2160), the bottom
tile is partial -- the last tile at y=2112 has only 48 valid rows.
The unclamped loop writes to vs->dirty[2160..2175], past the end of
the VNC_MAX_HEIGHT-sized array.
Clamp the row count to the actual surface height so partial bottom
tiles only mark valid dirty bitmap entries.
Fixes: CVE-2026-48002
Fixes: 7d964c9d2f ("vnc: refresh lossy rect after a given timeout")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3950
Reported-by: huntr bubble
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
tdx_fetch_cpuid() only sets the output ret parameter on the error
path. GCC cannot prove that r is always initialized before use in
the caller, triggering -Werror=maybe-uninitialized.
Initialize r to -1 to silence the warning.
Fixes: 228e40f33048 ("i386/tdx: Fetch and validate CPUID of TD guest")
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
The '--engine' arg accepts either 'podman' or 'docker', which is
not sufficiently granular to map directly to a command. This
means that docker.py still has to then probe the exact command
to use.
Meanwhile the 'probe' command prints out the full command to use
but this cannot be passed back to docker.py to avoid probing
again, so the caching is only useful in the few case where we
run a container directly bypassing docker.py.
Address this by replacing --engine with --command for docker.py.
This in turn requires the --container-engine configure arg to be
replaced with --container-command.
With these changes the container command is probed at most once
during configure and never again, while running in an unconfigured
tree will still probe on demand.
Tested-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260716102515.1503404-1-berrange@redhat.com
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Executed instructions are cached in string format inside the
execlog plugin. These strings are flushed on exit of a TB, improving
performance. This causes executed instructions to be lost when an
'ecall' (riscv system call) occurs that causes the thread to terminate.
The fix in this patch registers a 'vcpu_exit' callback, and flushes
any content in the c->last_exec buffer, to ensure all instructions are
present in the final instruction log.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Tested-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Harry van Haaren <harry.vanhaaren@openchip.com>
Link: https://lore.kernel.org/qemu-devel/20260716094126.787556-3-harry.vanhaaren@openchip.com
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
The existing code in execlog was never upgraded to the Scoreboard
API, resulting in a bespoke implementation of per-vCPU datastructure
handling. This had some race-conditions, and causes segfaults with
a simple multi-threaded program and two instances of execlog running.
The patch here refactors the custom GArray and GRWLock code away, and
uses the scoreboard APIs like the other plugins. This solves the
"printing while expanding" race-condition of two plugins with multiple
threads in the guest, and hence fixes a segfault.
Output remains atomic per instruction by building the full line
(including the trailing newline) in the per-vCPU GString before making
a single qemu_plugin_outs() call, relying on QEMU's own log locking
rather than an additional mutex.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Tested-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Harry van Haaren <harry.vanhaaren@openchip.com>
Link: https://lore.kernel.org/qemu-devel/20260716094126.787556-2-harry.vanhaaren@openchip.com
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
show_netdevs() lists each conditionally-compiled netdev backend behind
its CONFIG_* guard (CONFIG_SLIRP for "user", CONFIG_L2TPV3 for
"l2tpv3", CONFIG_NET_BRIDGE for "bridge", ...). The "passt" entry was
added unconditionally, so "-netdev help" advertises passt even in
builds configured with --disable-passt. Trying to use it then fails
with "Parameter 'type' does not accept value 'passt'", since the QAPI
NetClientDriver enum member "passt" is gated by 'if': 'CONFIG_PASST'.
Guard the help entry with CONFIG_PASST so the advertised backends match
those actually compiled into the binary.
Signed-off-by: Rohitashv Kumar <roohiit@amazon.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Puranjay Mohan <puranjay@kernel.org>
Message-ID: <20260713194511.1058450-1-rohit.kuma1313@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
We've got a proper way for logging unimplemented hardware features,
so use qemu_log_mask() instead of the fprintf() here now.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260713161406.361197-4-thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The FIXME macro is only used in one case, which should hopefully
never trigger: The containing function handles all the USB_RET_*
values except for USB_RET_ADD_TO_QUEUE and USB_RET_REMOVE_FROM_QUEUE,
which are both internal return values for when an async packet needs
to be queued or dequeued, and which shouldn't still be the status by
the time we get to this function. Thus let's simplify this spot
and use a g_assert_not_reached() instead (and remove the DPRINT()
in front of it to avoid that code analyzers trip over unreachable
code here).
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260713161406.361197-3-thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The FIXME macros in xhci_alloc_device_streams() can be triggered
by a (malicious) guest. Since the macro also contains an abort()
statement, this terminates QEMU. Turn the FIXME statements into
a qemu_log_mask() instead to avoid that a guest can shoot itself
this way.
Reported-by: Feifan Qian <bea1e@proton.me>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3784
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260713161406.361197-2-thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The inner while loop in ohci_service_ed_list() could theoretically
loop forever if a malicious guest prepares a set of bad descriptors.
Add a check to the loop to avoid this situation.
Reported-by: Feifan Qian <bea1e@proton.me>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3781
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260713160458.343323-1-thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
When virtio_gpu_create_udmabuf() succeeds but virtio_gpu_remap_udmabuf()
fails (mmap returns MAP_FAILED), virtio_gpu_init_udmabuf() returns early
without closing the dmabuf fd. Since res->blob is never set in this
path, later cleanup via virtio_gpu_cleanup_mapping() skips
virtio_gpu_fini_udmabuf() entirely, leaking the file descriptor.
Call virtio_gpu_destroy_udmabuf() before the early return to close
the fd. This function already handles partial state correctly: it
skips the munmap when res->remapped is NULL and closes the fd when
res->dmabuf_fd >= 0.
Fixes: 9b60cdf987 ("virtio-gpu: Add udmabuf helpers")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260713125622.111513-1-marcandre.lureau@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
blk_getlength() returns int64_t, but niagara_init() stored it in an int,
truncating the if=pflash virtual-ramdisk size for images >= 2 GiB. A ~4 GiB
image truncated to 0/negative, failed the `size > 0` check, and exit(1)'d
before the CPU ran, ending with:
qemu-system-sparc64: could not load ram disk
Signed-off-by: Dmitry Pimenov <sun4qemu@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260710222350.9185-1-sun4qemu@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Snapshot chunk.data_size into a host-local variable before passing it to
qxl_phys2virt() for validation, and pass it through qxl_cursor() and
qxl_unpack_chunks() so that no subsequent code re-reads the field.
Without this, a racing vCPU can inflate data_size between the
qxl_phys2virt() validation and the memcpy in qxl_unpack_chunks(),
causing a source read past the validated region. In practice the read
stays within the guest's own VRAM mmap, so the impact is limited.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3757
Reported-by: Feifan Qian <bea1e@proton.me>
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260710134352.2313675-1-marcandre.lureau@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Add a comment to explain the endianness of the pvscsi device. We have
no information about the endianness should be little-endian or CPU
native endian because the current driver code is designed to work only
on x86 and is not endianness aware. We assume that the pvscsi device is
implicitly little-endian.
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260710-pvscsi-endianness-v3-2-27fe1c4d1f6e@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
This patch improves the implementation of the pvscsi device by
translating the endianness of the data sent or received from the guest.
This ensures pvscsi can work on big-endian hosts with little-endian
guests.
This patch assumes, although not having found any specifications, that
the pvscsi device is little-endian, since pvscsi seems to be used only
on x86 platforms, which are little-endian.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
Message-ID: <20260710-pvscsi-endianness-v3-1-27fe1c4d1f6e@gmail.com>
[PMD: Rebased on top of commit cb30b8758d physmem API conversion]
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Document the boundary between SPI/SSI controller models and SPI flash
models when representing fast-read dummy cycles. It explains that
flash models own command semantics, while controllers own
hardware-generated dummy transfers and cycle-to-byte conversion.
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260707083431.219671-11-bin.meng@processmission.com>
[PMD: Update MAINTAINERS]
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
ivshmem_exit() frees s->peers and s->msi_vectors but does not clear
the chardev handlers registered in ivshmem_common_realize(). Those
handlers are only removed later in object_finalize() via release_chr,
which runs after ivshmem_exit().
Between exit and finalize, ivshmem_read() can fire on pending chardev
data and process_msg_connect() dereferences the freed s->peers.
Additionally, s->peers, s->nb_peers, and s->msi_vectors are not
zeroed after free, leaving dangling pointers that make the UAF code
paths reachable.
Fix by clearing chardev handlers at the beginning of ivshmem_exit(),
before any resources they access are freed, and nullifying freed
pointers.
Cc: qemu-stable@nongnu.org
Fixes: f64a078d45 ("ivshmem: fix pci_ivshmem_exit()")
Link: https://gitlab.com/qemu-project/qemu/-/work_items/3594
Reported-by: Haotian Jiang <sundayjiang@tencent.com>
Signed-off-by: Haotian Jiang <sundayjiang@tencent.com>
Message-ID: <tencent_3105EC28797360A155078F53@qq.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
When trying to plug a PCI device to a Sparc64 machine, you currently
have to specify the right bus ("bus=pciB"), otherwise you get this error:
$ qemu-system-sparc64 -device virtio-scsi-pci
qemu-system-sparc64: -device virtio-scsi-pci: PCI: no slot/function
available for virtio-scsi-pci, all in use or reserved
This is quite annoying for the unexperienced users, and it also breaks
e.g. the iotests ("make check-block") when running with qemu-system-sparc64.
Mark the non-usable PCI busses as full now, so that QEMU can automatically
plug new PCI devices to the right "pciB" bus.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260309181452.83702-1-thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Orphaned isn't a state, Orphan is.
Fixes: fb7001e458 (MAINTAINERS: Remove PhilMD from firmware sections, 2026-04-17)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260710111403.2953873-1-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
qmp_device_list_properties() skips properties whose name starts with
"legacy-". This is a flawed test for "is a legacy property".
The test is flawed because non-legacy properties can and do start with
"legacy-". Back when it was added, no such properties existed. Right
now, three such properties do: property "legacy-cmb" of device "nvme",
and properties "legacy-cache" and "legacy-multi-node" of devices
"x86_64-cpu", "i386-cpu", and its children.
This affects QMP command "device-list-properties", HMP command
"device_add T,help", and command line option "-device T,help".
Legacy properties are gone since commit a61383f7ab (qdev: Legacy
properties are now unused internally, drop, 2025-10-22). This makes
the fix easy: delete the code that skips them.
Reproducer: -device nvme,help doesn't show legacy-cmb before the
patch, and does after.
Fixes: f4eb32b590 (qmp: show QOM properties in device-list-properties, 2014-05-20)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260708140948.2622814-1-armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Section tags are case sensitive and end with a colon. Screwing up
either gets them interpreted as ordinary paragraph. Fix a few.
Fixes: 4e88e7e340 (qapi/qom: Define cache enumeration and properties for machine, 2024-11-01)
Fixes: 8eb6d39e22 (qom: qom-list-get, 2025-07-11)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260701061136.798815-1-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Standard printf has no %ud conversion; glibc treats it as %u followed
by a literal 'd', so postcopy userfaultfd error messages printed event
values like "5d" instead of "5". The same typo existed in two postcopy
discard trace format strings.
Also rename the misspelled ram_save_iterate_big_wait() trace argument
milliconds to milliseconds.
Fixes: 00fa4fc85b ("postcopy: Allow registering of fd handler")
Signed-off-by: yujun <yujun@kylinos.cn>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20260630031324.43453-1-yujun@kylinos.cn
Signed-off-by: Peter Xu <peterx@redhat.com>
2026-06-30 10:57:49 -04:00
891 changed files with 32992 additions and 10676 deletions
