vfio queue:
* Fixes ROM read issues in vfio/pci: information leak, error
propagation, and uninitialized state
* Validates VERSION replies in vfio-user and updates the spec
for DMA access mode bits
* Merges .dma_map_file() into .dma_map() in the iommufd backend
* Reworks switchover-ack to be re-usable and implements the
VFIO_PRECOPY_INFO_REINIT feature for additional pre-copy
iterations before switchover
* Adds ATS support for passthrough devices via iommufd
* Fixes translated_addr for non-identity-mapped RAM sections in
the VFIO listener
* Reject invalid MSI-X Table and PBA BIR values
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmpMkQ8ACgkQUaNDx8/7
# 7KHM0Q/9H4sFijvDZbLkwSK+lkDBpiuIfQ/2WS6P5jZFIH47q3drqA0GIChNbqMv
# W0ikOGEw09lVYYM1z8+90PRNMgps9TcuCo2PB+bWrlibMbwNZCROjhxzaRvX2u7l
# +VhMpQ7BdpddZt4xuEWzvN3NRUc881iSMjlP60qCRbCfx1enK1XFQapi3pnqBL8C
# h9XPBdbEKiW6q8BBvzGUmHsdfUb/uVMw6/imTaLoFNd1QE0lkNP/JmwZe+SCBmU6
# B44GSQ9XrUaoEZ+jxCtKwOxAr0Z/qwbTVtSI7lzlFB6oi/vZqMgc9l9TE7IlYnaz
# v+7SzTAxzgdsZiaGggsYPg+Nu7AYTa2A7zEDwfcqG6Xtc8Vtx3vGyNXNVrX4Voen
# a6PqdpO8LoVRGt/1V+SXKtyB0IuzHVI76XsZvJTDHHq9hnu3RLTIbTnqz0qJ6lm9
# ii0VqGpsXLX9ru4fVsmLJzvllowYT3aAAJWz5fVCsxLBw1qVXRMWK0Vks0d2m1SW
# HH/4qn/m4u+RrF9f/Ns2AWhuFEOZJvmQXIcgl3ciCuaJaPzhbQO25OKjCl/wBrUe
# jtT6Hqgt6n6+k6iL4qfkA3q6b6ns8Mi4+GsjMeCbNR7UrNlPXwOWq6PrWMAc1V4/
# aW2gK3o9dtL5oguBLCTkNpxgmbKmxB5n5oOp06M7dPM59HeSWpg=
# =flhm
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 07 Jul 2026 07:39:27 CEST
# 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]
# Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1
* tag 'pull-vfio-20260707' of https://github.com/legoater/qemu: (27 commits)
vfio/pci: Reject invalid MSI-X Table and PBA BIR values
backends/iommufd: Fix dev_id and type order in viommu trace
vfio/listener: Fix translated_addr for non-identity-mapped RAM sections
vfio/pci: Propagate errors in vfio_pci_load_rom() using Error API
vfio/pci: Add ats property
iommufd: Introduce handler for device ATS support
migration: Fix "switchover" used as a verb in comments and docs
migration: Refactor migration_completion_precopy() to return bool
migration: Enable new switchover-ack
vfio/migration: Check VFIO_PRECOPY_INFO_REINIT during switchover
vfio/migration: Implement VFIO_PRECOPY_INFO_REINIT feature
vfio/migration: Add new switchover-ack mechanism
vfio/migration: Add Error ** parameter to vfio_migration_init()
vfio/migration: Extract VFIO_MIG_FLAG_DEV_INIT_DATA_SENT sending to helper
migration: Fail migration if switchover-ack is requested after switchover decision
migration: Make switchover-ack re-usable
migration: Rename switchover-ack code to legacy
migration: Replace switchover_ack_needed SaveVMHandler
migration: Log the approver in qemu_loadvm_approve_switchover()
migration: Run final save_query_pending at switchover
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This reverts commit f95c4bffdc.
The m25p80 model now accounts for fast-read dummy bytes in its
command decoder. In ASPEED SMC model user mode, guest software
already sends the complete byte stream, including any dummy
bytes needed by the flash. Hence the model should just forward
exactly the bytes supplied by the guest without the need of
decoding guest-supplied flash op codes to inject extra dummy
transfers.
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20260707083431.219671-10-bin.meng@processmission.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
m25p80 now consumes fast-read dummy phases as byte counts. The
ASPEED SMC direct-read path still treated the CEx dummy field as
raw cycles and emitted field * 8 SSI transfers. Convert the
ASPEED dummy field to SSI byte transfers using the selected
direct-read data width.
Fixes: ac2810defa ("aspeed/smc: handle dummy bytes when doing fast reads in command mode")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20260707083431.219671-8-bin.meng@processmission.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The ZynqMP generic FIFO encodes dummy phases as a number of
dummy cycles. QEMU's SSI bus transfers whole bytes, so the
controller model must convert the programmed cycle count to the
number of SSI byte transfers needed for the selected SPI, dual SPI
or quad SPI mode.
The legacy Xilinx QSPI snoop paths had the opposite problem after
the m25p80 dummy handling was fixed. They still treated each dummy
byte queued through the FIFO as a request to generate several SSI
transfers based on the current link width. The flash model now
consumes dummy phases as byte counts, so the manual FIFO path should
forward one SSI transfer per dummy byte.
Update the Xilinx QSPI dummy accounting consistently for the generic
FIFO, manual FIFO and LQSPI direct-read paths. Also make the command
table report the dummy byte counts consumed by m25p80 for dual and
quad output reads, and account for the mode byte before LQSPI data
reads begin.
This matches the ZynqMP TRM (ug1085, v2.2 [1]) description of the
generic FIFO dummy cycle entry and keeps the controller side aligned
with the flash model's dummy byte ownership.
The description of the generic command fifo register says:
When [receive, transmit, data_xfer] = [0,0,1], the [immediate_data]
field represents the number of dummy cycle sent on the SPI interface.
[1] https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
table 24‐22, an example of Generic FIFO Contents for Quad I/O Read Command (EBh)
Fixes: ef06ca3946 ("xilinx_spips: Add support for RX discard and RX drain")
Fixes: c95997a39d ("xilinx_spips: Add support for the ZynqMP Generic QSPI")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20260707083431.219671-7-bin.meng@processmission.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Change send_dummy_bits() to send_dummy_bytes() as the FIU register
fields are programmed from spi_mem_op.dummy.nbytes, so they already
describe byte transfers.
Verified the changes by booting OpenBMC image on `gbs` machine all
the way to the Linux login shell:
$ qemu-system-arm -machine quanta-gbs-bmc -nographic \
-drive file=image.mtd,if=mtd,bus=0,unit=0,format=raw
Fixes: b821242c7b ("hw/ssi: NPCM7xx Flash Interface Unit device model")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20260707083431.219671-6-bin.meng@processmission.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The emcraft-sf2 board set spansion-cr2nv to 1, which the old m25p80
code treated as a byte count. With the dummy cycle to byte conversion
fix, CR2V=1 at SPI x1 is 1 bit, not byte-aligned, and triggers an
assertion. Use the S25FL128S default of 0x8 (8 cycles = 1 byte at
SPI x1), preserving the same runtime behavior.
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Bin Meng <bin.meng@processmission.com>
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-Id: <20d58663-a8d1-41ff-9348-cae4982c30f0@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Numonyx/Micron flashes [1] do not use one fixed dummy-phase width for all
fast-read commands. The volatile configuration register stores a number
of dummy clock cycles, and QEMU must convert that value to the number of
SSI bytes consumed by the flash model.
Keep the existing default: 10 dummy clocks in Quad I/O mode and 8 dummy
clocks otherwise. In Quad I/O and Dual I/O protocol modes, all command
phases are transferred on 4 or 2 lines, so the dummy clock count still
needs to be scaled by that bus width.
Standard SPI, also called extended SPI in the Micron datasheet, is more
subtle. Quad Output Fast Read (6Bh) and Dual Output Fast Read (3Bh) keep
the opcode and address phases on DQ0; their dummy phase is just a clock
gap before data is returned on four or two output lines. Do not scale the
dummy count for those output-only commands. Only Quad I/O Fast Read
(EBh) and Dual I/O Fast Read (BBh) transfer the address and dummy phases
on the 4-bit or 2-bit bus, so keep scaling those commands.
[1] https://docs.rs-online.com/cad7/0900766b8121bd3c.pdf
Fixes: 23af268566 ("hw/block/m25p80: Fix Numonyx fast read dummy cycle count")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20260707083431.219671-3-bin.meng@processmission.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The m25p80 model uses s->needed_bytes to track how many bytes a
controller must send after an opcode before the flash model can enter
the data phase. For address-bearing commands this includes the address
bytes. For fast-read commands it also includes the dummy phase.
The tricky part is that flash datasheets describe the dummy phase in
clock cycles, while the QEMU SSI interface advances the flash model one
transferred byte at a time. The dummy clock count therefore has to be
converted to the number of SSI bytes that the controller will actually
emit.
Some controllers have drivers that push these dummy bytes into a FIFO.
Other controllers are programmed with a dummy-cycle count and generate
the clocks themselves. The flash model still has to use the same byte
count that a FIFO-style controller or the Linux spi-mem layer would use,
otherwise the model waits too long and drops the first data bytes.
Let's fix the inconsistency from the flash side first. We start from an
easy one, the Winbond flashes.
Per the Windbond W25Q256JV datasheet [1] instruction set table
(chapter 8.1.2, 8.1.3, 8.1.4, 8.1.5), fix the wrong number of
dummy bytes needed for fast read commands.
[1] https://www.winbond.com/resource-files/w25q256jv%20spi%20revb%2009202016.pdf
Fixes: fe84770528 ("m25p80: Fix QIOR/DIOR handling for Winbond")
Fixes: 3830c7a460 ("m25p80: Fix WINBOND fast read command handling")
Fixes: cf6f1efe0b ("m25p80: Fast read commands family changes")
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20260707083431.219671-2-bin.meng@processmission.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
When wiring struct FlexcanState to the clock control module, it is
currently necessary to reach into its private data. Moreover, when
forgetting to wire the clock control module, QEMU will crash after the
guest has already started. Fix both by letting struct FlexcanState
expose a link property whose sanity is checked at realize time.
Suggested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Acked-by: Pavel Pisa <pisa@fel.cvut.cz>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>
Message-ID: <20260702184038.178196-2-shentey@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
qxl_render_cursor() maps the guest-provided QXLCursor object using the
guest-controlled cursor->chunk.data_size.
For a mono cursor, qxl_cursor() then validates the expected bitmap size
against cursor->data_size, but it does not validate that the first chunk
actually contains that many bytes.
A guest could set cursor->data_size to the correct full mono cursor size
while setting cursor->chunk.data_size to zero. In that case, cursor_set_mono()
reads the AND/XOR masks starting at cursor->chunk.data. If the cursor object
is placed at the end of the QXL RAM BAR, those reads cross the mapped RAM
region and could crash the QEMU process (e.g. under ASan).
Fix it by double-checking cursor->chunk.data_size for the correct size.
This patch is based on the suggested changes by the reporter in the bug
ticket.
Reported-by: huntr bubble
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3646
Signed-off-by: Thomas Huth <thuth@redhat.com>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260630101022.379057-1-thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The hyperv_find_cpu() function finds a CPU from a CPU index; this is
basically a wrapper around qemu_get_cpu(). It is allowed to fail, in
which case it returns NULL, which its caller handles. However, it
includes an assertion check which accidentally assumes the CPU
pointer is non-NULL.
We could assert only if cs != NULL, but the assertion here is not
doing anything interesting -- hyperv_vp_index() is a trivial wrapper
returning cs->cpu_index, so this is effectively asserting that
qemu_get_cpu() did what it claims to do, i.e. returned us the CPU
matching the index we gave it. qemu_get_cpu() is a simple "iterate
through list and find matching CPU" which is unlikely to be buggy,
and we don't feel the need to sanity-check it in any of our other
many uses of it. Drop the assertion entirely.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3568
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260630084855.2319838-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Currently the mptsas reset function clears intr_status, but it
doesn't reset the doorbell state machine. This means that the state
machine and the interrupt state get out of sync, and the guest can
trigger an assertion failure in mptsas_doorbell_read() where
s->doorbell_state is still DOORBELL_READ but s->intr_status does not
have MPI_HIS_DOORBELL_INTERRUPT set.
Fix this by having reset also reset the doorbell state. Strictly
speaking we don't need to also clear doorbell_reply_idx and
doorbell_reply_size, because those are only read when in
DOORBELL_READ state, and the code always sets them up before
transitioning into that state. But it's less confusing to clear them
out on reset.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/304
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260629185035.2138238-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
When a guest transmits a short Ethernet frame, iov_size() returns the
padded wire length including any bytes added to reach the Ethernet
minimum frame size of 60 bytes. net_tx_pkt_rebuild_payload() uses
this inflated size as payload_len. net_tx_pkt_update_ip_hdr_checksum()
then overwrites the IPv4 Total Length field with payload_len +
l3_hdr_len, inflating it by the padding. The receiver interprets
Ethernet padding as IP payload, producing a malformed packet.
Fix by removing the ip_len write from net_tx_pkt_update_ip_hdr_checksum()
so it only recomputes the checksum, and moving the ip_len assignment
into net_tx_pkt_update_ip_checksums() where it is only performed for
TSO (where ip_len must be derived from payload_len since the guest sets
ip_len=0 per Intel 82574 datasheet §7.3.4 for super-packets the host
will segment).
Both e1000e and igb already call net_tx_pkt_update_ip_hdr_checksum()
from their IXSM paths, so both are corrected by this single common-
layer change.
Signed-off-by: Sanjeeva Yerrapureddy <y.sanjeevreddy@gmail.com>
Reivewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260629-net-tx-pkt-ip-length-padding-v5-1-16760e30252e@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The i8257 DMA controller has a "verify" mode, which the datasheet
describes like this:
> DMA verify, which does not actually involve the transfer of data.
> When an 8257 channel is in the DMA verify mode, it will respond the
> same as described for transfer operations, except that no memory or
> I/O read/write control signals will be generated. When an 8257
> channel is in the DMA verify mode, it will respond the same as
> described for transfer operations, except that no memory or I/O read
> /write control signals will be generated, thus preventing the
> transfer of data. The 8257, however, will gain control of the system
> bus and will acknowledge the peripheral's DMA request for each DMA
> cycle. The perihperal can use these acknowledge signals to enable an
> internal access of each byte of a data block in order to execute some
> verification procedure, such as the accumulation of a CRC check word.
In practice, for QEMU's purposes the only real user of this is the
floppy controller, which can be made to perform a "read data from
floppy disk and check the checksum" by telling the fdc to do a read
and the DMA controller to do a verify. This causes the fdc to do all
the usual read actions including the checksum, but the data is never
written to memory. However, it is possible for a guest doing
something silly to program the DMA controller to do a verify
operation for a device that wants to read from memory. Currently we
simply return early from i8257_dma_read_memory() without writing to
the buffer. None of the callers (the GUS, sb16 and cs4231a sound
cards, plus the fdc) expect this, so they will take the uninitialized
data as if it were from the guest. This can cause us to leak host
data off the stack into the guest.
Make i8257_dma_read_memory() fill the buffer with zeroes rather
than leaving it untouched for a verify operation.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3487
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260629140128.1900095-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
pca955x_get_led() and pca955x_set_led() accept led indices equal to
pin_count, but valid indices are 0..pin_count-1. For a 16-pin device,
led16 passes the current check and then accesses an LS register past
max_reg.
Use the same >= pin_count bounds check as pca9554_set_pin() and the
gpio input handler assert in this file.
Fixes: a90d8f8467 ("misc/pca9552: Add qom set and get")
Signed-off-by: yujun <yujun@kylinos.cn>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Message-ID: <20260629074133.187549-1-yujun@kylinos.cn>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
ATAPI CD reads are issued through ide_buffered_readv()
(cd_read_sector() and ide_atapi_cmd_read_dma_cb() in hw/ide/atapi.c).
The PIO path discards the returned aiocb; the DMA path stores it in
s->bus->dma->aiocb.
A guest can stop and restart a port's command engine
(PxCMD.ST 1 -> 0 -> 1) while such a read is still in flight. Stopping
the engine unmaps the command list (ahci_unmap_clb_address()) and
restarting it re-maps the list and clears AHCIDevice.cur_cmd to NULL,
but nothing tears down the outstanding read. This path does not run
ide_reset(), so the drive's transfer state is preserved and the read
still completes. Its callbacks then dereference the stale or NULL
cur_cmd in the AHCI transfer helpers:
PIO: cd_read_sector_cb() -> ide_atapi_cmd_reply_end() ->
ide_transfer_start_norecurse() -> ahci_pio_transfer()
DMA: ide_atapi_cmd_read_dma_cb() -> ahci_dma_rw_buf() ->
ahci_populate_sglist()
Both crash with a NULL cur_cmd; the PIO variant has been seen in the
field.
Cancel the outstanding I/O when the command list is unmapped, reusing
ide_cancel_dma_sync() as the ATAPI DEVICE RESET command does. It runs
the completion callback with -ECANCELED (which tears down
s->bus->dma->aiocb for the DMA case) and orphans the buffered request,
so the eventual asynchronous completion is a no-op. Merely setting the
orphaned flag is not enough: it would leave s->bus->dma->aiocb pointing
at a freed aiocb that a later reset would cancel.
Fixes: 1d8c11d631 ("ide: add support for IDEBufferedRequest")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Message-ID: <20260619112158.304782-2-den@openvz.org>
[PMD: Use ide_bus_active_if()]
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
ati_bpp_from_datatype() returns 0 for unrecognized dp_datatype nibble
values (0, 1, or >= 7). ati_host_data_flush() only guards against the
bpp == 24 case but not bpp == 0, leading to:
1. Division by zero at "pix_count /= ctx.bpp" (SIGFPE) when
src_datatype is SRC_COLOR.
2. g_assert_not_reached() in stn_he_p() when bypp (= bpp/8 = 0)
hits the default case of the size switch.
Both are guest-triggerable via MMIO writes to the dp_datatype register
while a HOST_DATA blit is active.
Add an explicit bpp == 0 check with LOG_GUEST_ERROR before proceeding
with the blit, consistent with the existing check in ati_2d_do_blt().
Cc: qemu-stable@nongnu.org
Reported-by: Feifan Qian <bea1e@proton.me>
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Reviewed-by: Chad Jablonski <chad@jablonski.xyz>
Message-ID: <20260519023937.439077-3-junjie.cao@intel.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The AST2700 SSP/TSP firmware accesses OTP MMIO regions that
are not yet implemented in QEMU.
This change adds unimplemented MMIO devices for the OTP and maps them to
their corresponding physical addresses in the SSP/TSP address space.
These stub devices allow QEMU to safely handle firmware
accesses and prevent spurious exceptions, while accurately reflecting
the hardware memory map.
No functional changes.
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/20260706052701.1141740-6-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The AST2700 SSP/TSP firmware accesses Privilege Controller MMIO regions that
are not yet implemented in QEMU.
This change adds unimplemented MMIO devices for the Privilege Controller
blocks and maps them to their corresponding physical addresses in the SSP/TSP
address space. These stub devices allow QEMU to safely handle firmware
accesses and prevent spurious exceptions, while accurately reflecting
the hardware memory map.
No functional changes.
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/20260706052701.1141740-5-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Implement basic behavior for RNG_CTRL and RNG_DATA:
- RNG_CTRL allows guest to enable/disable the RNG via the DIS bit.
Only bits [0:3] and bit 5 are writable; other bits are masked.
- The VLD bit (bit 31) is updated by the model to reflect the RNG
enable state, and is not writable by the guest.
- When RNG is enabled, reads from RNG_DATA return a newly generated
random value.
- When RNG is disabled, RNG_DATA return 0.
This provides a minimal functional model of the RNG sufficient for
software that expects readable random data without modeling full
hardware behavior.
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/20260706052701.1141740-4-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The AST2700 SCU/SCUIO read handlers currently emit LOG_GUEST_ERROR
messages for all registers that are not explicitly handled.
However, most SCU registers are simple read-back registers without
side effects, and do not require explicit handling in the read path.
Returning the stored register value is sufficient.
Emitting "Unhandled read" logs for these cases generates excessive
and misleading noise during normal guest operation, making it harder
to spot real issues.
Remove the default unhandled read logging from the SCU and SCUIO read
handlers to reduce log noise and align with common QEMU device model
behavior for passive registers.
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/20260706052701.1141740-3-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
pca955x_get_led() and pca955x_set_led() accept led indices equal to
pin_count, but valid indices are 0..pin_count-1. For a 16-pin device,
led16 passes the current check and then accesses an LS register past
max_reg.
Use the same >= pin_count bounds check as pca9554_set_pin() and the
gpio input handler assert in this file.
Fixes: a90d8f8467 ("misc/pca9552: Add qom set and get")
Signed-off-by: yujun <yujun@kylinos.cn>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260629074133.187549-1-yujun@kylinos.cn
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The Aspeed INTC records an interrupt source in the pending bitmap when
the source is masked or another status bit is still being handled. When
the guest later clears the status register, the model promotes all saved
pending bits back to status unconditionally.
This is not correct for level-triggered sources. A source can deassert
while another source connected to the same OR gate keeps the aggregated
INTC line asserted. Promoting the stale bit later makes the guest demux
a child interrupt whose device status has already been cleared.
This is visible on AST2700 I2C, where the I2C buses are aggregated
through INTCIO GICINT194 before reaching the GIC. A stale I2C source bit
can be promoted back to the INTCIO status register, causing Linux to run
the corresponding I2C ISR with an empty I2C interrupt status register.
For example, the Linux aspeed-i2c debug ring shows a transfer that first
receives a valid status interrupt, then receives a spurious ISR with both
isr and raw status equal to zero. The zero-status ISR clears the saved
command error and the transfer completes with ret=0:
event=start isr=0x00000000 raw=0x00000000 cmd_err=0 msgs_idx=0
event=isr isr=0x00010011 raw=0x00010011 cmd_err=0 msgs_idx=0
event=isr isr=0x00000000 raw=0x00000000 cmd_err=1 msgs_idx=1
event=complete ret=0 cmd_err=0 msgs_idx=1
A normal command can then be reported as zero transferred messages, which
is converted to -EIO by Linux i2c_smbus_xfer_emulated(). The race is
more likely when multiple I2C buses are accessed concurrently.
Drop pending bits that no longer correspond to an asserted and enabled
source before they can be promoted back to status.
Signed-off-by: Jian Zhang <zhangjian.3032@bytedance.com>
Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20260612060857.1842819-1-zhangjian.3032@bytedance.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Today, if a RPCIT instruction is presented from the guest whose range
exceeds the previously-registered IOAT, QEMU will process the range
so long as 1) the specified range at least partially overlaps with
what was previously registered and 2) the guest has valid IOAT entries
in its table. If the entries are not present (invalid), then the
RPCIT will unnecessarily spend time reporting the invalid
region/segment entries.
Optimize this path by exiting immediately if the requested range falls
completely outside of the previously-registered range or if the
requested range ends before it starts (which would only occur if the
guest-specified address + length would overflow a u64). Otherwise,
clamp the request to only the portion of the range that overlaps with
what was previously registered, effectively ignoring the portion
outside of the registered range.
Cc: qemu-stable@nongnu.org
Fixes: 5d1abf2344 ("s390x/pci: enforce zPCI state checking")
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20260707070728.147203-4-borntraeger@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
In vfio_listener_region_del(), when dirty tracking is active and a
writable RAM section is deleted, a synthetic IOMMUTLBEntry is built to
flush dirty pages. Setting translated_addr to the IOVA (GPA) is only
correct for identity-mapped regions where GPA == ram_addr_t.
For RAM sections with GPA far above main RAM (e.g., nested VT-d interrupt
remapping table at 58 TB), translated_addr is too large, causing a crash
in physical_memory_set_dirty_lebitmap() when indexing beyond the allocated
dirty memory blocks array :
bitmap_set_atomic(map=NULL, start=1, nr=1)
physical_memory_set_dirty_range(start=0x380004040000, length=4096)
physical_memory_set_dirty_lebitmap(start=0x380004040000, pages=3)
vfio_container_query_dirty_bitmap(translated_addr=0x380004040000)
vfio_legacy_dma_unmap_one(iova=0x380004040000, size=12288)
vfio_listener_region_del()
Fix this by setting translated_addr to the ram_addr_t of the section, which
is consistent with other vfio dirty tracking code:
translated_addr = memory_region_get_ram_addr(section->mr) +
section->offset_within_region;
Cc: Zhenzhong Duan <zhenzhong.duan@intel.com>
Fixes: 6e360c0617 ("vfio/listener: Add missing dirty tracking in region_del")
Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Tested-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Link: https://lore.kernel.org/qemu-devel/20260625134352.3122572-1-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Add an "ats" OnOffAuto property to vfio-pci. When the device has an ATS
extended capability in config space but we should not expose it (ats=off,
or ats=auto and kernel reports IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED), mask
the capability so the guest does not see it.
If ATS is explicitly requested but not supported by the kernel, fail
device realize.
This aligns with the kernel's per-device effective ATS reporting and allows
vfio-pci to mask ATS when the host kernel reports ATS as unsupported.
Emit a warning when ats=on is requested but the physical device does not
advertise ATS, since ATS cannot be exposed to the guest in this case.
Emit a warning when ats=auto, ats cap is present on the physical device,
but kernel reports ATS as unsupported.
Suggested-by: Shameer Kolothum <skolothumtho@nvidia.com>
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260623204943.989903-3-nathanc@nvidia.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
