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>
qcrypto_get_x509_cert_fingerprint() reports gnutls_strerror(ret) when
gnutls_x509_crt_init() fails, but ret is still the initial value -1.
Store the gnutls return code before formatting the error, matching
other gnutls call sites in the tree.
Fixes: 2183ab6251 ("crypto/x509-utils: Check for error from gnutls_x509_crt_init()")
Signed-off-by: yujun <yujun@kylinos.cn>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260629111026.281185-1-yujun@kylinos.cn>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
trace_ebpf_rss_set_data() passes its third and fourth arguments to
the toeplitz-ptr and indirection-ptr fields defined in trace-events.
ebpf_rss_set_all() passed indirections_table and toeplitz_key in the
opposite order, so tracing mislabeled the two pointers.
Match the argument order already used by trace_ebpf_rss_mmap().
Fixes: f5cae19d10 ("ebpf: improve trace event coverage to all key operations")
Signed-off-by: yujun <yujun@kylinos.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260629090116.266561-1-yujun@kylinos.cn>
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>
Add a regression test for the crash that occurs when a buffered ATAPI
read completes after the command engine has been restarted. Issue an
ATAPI READ_10 against a blkdebug-backed CD, suspend the backend read so
it stays in flight, stop and restart the port's command engine (which
re-maps the command list and clears cur_cmd), then release the read.
The PIO and DMA reply paths fault in different AHCI helpers
(ahci_pio_transfer() vs ahci_dma_rw_buf()), so cover both. The DMA
variant is the reliable guard: on engine restart check_cmd() can re-arm
cur_cmd before the old read completes, so the PIO variant does not fault
in every build.
The test only asserts that qemu survives a subsequent register access;
if the blkdebug breakpoint ever failed to park the read it would pass
without exercising the bug, as with the existing break/resume tests.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Message-ID: <20260619112158.304782-3-den@openvz.org>
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>
In kvm_loongarch_get_cpucfg() and kvm_loongarch_put_cpucfg(), ret is
overwritten on each iteration, so only the last register's result is
returned and earlier failures are lost. On a failed read, env->cpucfg[i]
is stored from a stale or uninitialized val.
Accumulate errors with ret |=, matching kvm_loongarch_get_csr()/put_csr(),
and only update env->cpucfg[i] on a successful read. Keep the cpucfg2
negotiation check in put_cpucfg() on a separate variable so its early
return does not overwrite the accumulated result.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Message-ID: <20260626052742.810726-5-cui.tao@linux.dev>
Signed-off-by: Song Gao <gaosong@loongson.cn>
kvm_get_one_reg() and kvm_set_one_reg() already trace on failure, so the
trace_kvm_failed_get_cpucfg()/trace_kvm_failed_put_cpucfg() calls in
kvm_loongarch_get_cpucfg() and kvm_loongarch_put_cpucfg() duplicate that.
Remove the calls and the now-unused trace events.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Message-ID: <20260626052742.810726-4-cui.tao@linux.dev>
Signed-off-by: Song Gao <gaosong@loongson.cn>
kvm_vcpu_ioctl() is variadic and reads its argument as a pointer, but
kvm_get_stealtime(), kvm_set_stealtime() and kvm_set_pv_features() pass
the local struct kvm_device_attr by value. It currently works because of
how the calling convention passes large structs; pass &attr so the
argument is passed as intended.
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Message-ID: <20260626052742.810726-3-cui.tao@linux.dev>
Signed-off-by: Song Gao <gaosong@loongson.cn>
kvm_check_cpucfg2() discards the return value of KVM_GET_DEVICE_ATTR and
uses the local val (the host cpucfg2 mask) without checking whether the
read succeeded. val is also declared without an initializer, so on a GET
failure env->cpucfg[2] &= val reads an uninitialized value.
The &= mask is best-effort feature negotiation: if KVM_HAS_DEVICE_ATTR
succeeds, a GET failure is most likely a copy_{from,to}_user issue, not a
reason to fail the whole register sync. Check the GET return value, warn and
skip the mask on failure (the guest keeps the cpucfg2 it already has), and
initialize val to 0.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Message-ID: <20260626052742.810726-2-cui.tao@linux.dev>
Signed-off-by: Song Gao <gaosong@loongson.cn>
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 boot completion check in AspeedTest waits for the systemd
"Hostname set to" message, which occasionally causes intermittent test
timeouts, e.g. on ast2500 SoC machines. The root cause seems to be
console output interleaving of both systemd and the getty login
process. This results in the expected pattern string being broken up.
Unify and simplify all boot completion checks by looking for the
generic 'login:' substring in AspeedTest.wait_for_boot_complete().
With the override gone, remove the redundant FacebookAspeedTest class
and update the Anacapa, Bletchley, and Catalina tests to inherit
directly from AspeedTest. Also drop the now-dead image_hostname
parameter from do_test_arm_aspeed_openbmc().
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3117
Reviewed-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260617042718.2883655-1-clg@redhat.com
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>
