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>
The logic in css_interpret_ccw() correctly returns -EINVAL if a
Transfer-In-Channel (TIC) CCW is command chained to another TIC CCW.
The same routine also correctly returns -EINVAL if 256 CCWs do not
perform a data transfer as part of the I/O operation [0].
What is missing, however, is a combination of these two, where a loop
can be generated that will continue processing CCWs but without
providing an opportunity to catch a breath. Fix this by capping
the number of TIC CCWs in a channel program at the same limit as
the CCWs without data transfer.
[0] See "Invalid Sequence" in z/Architecture Principles of Operation
(SA22-7832-14), p16-27
Cc: qemu-stable@nongnu.org
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20260713074708.884282-1-borntraeger@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
target-arm queue:
* hw/misc/zynq_slcr.c: drop duplicate reset value for DDRIOB_DCI_CTRL
* hw/arm/tegra241-cmdqv: Do not sync GERRORN on VCMDQ allocation
* hw/arm/smmuv3: Sanitize fields provided by guest
* hw/i2c: pmbus: clear output buffer on write
* docs/system/arm: Add some missing FEAT_FOO we already implement
* arm/virt: fix smmuv3_devices leak
* target/arm: Be more defensive for invalid tlbi_aa64_get_range
* hw/dma: don't allow weird transfer lengths for bcm2835
* hw/net/vmxnet3: Correct bounds check on tx queue index
* hw/usb/dev-wacom: Don't write off end of buffer
* hw/display/sm501: Don't let guest write off end of buffer
* hw/misc/allwinner-r40-ccu.c: Correct handling of out of range accesses
* hw/misc/stm32_rcc: Correct offset-to-irq calculation
# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmpU09QZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3ksND/9RYq9Ki0OneG6XDcjWRRz9
# 9j6fEBFZlDTD9UsK+ypjD/gLkPqmYdBm9eAk5BBKXy1nAGOYrIQQKZcUOrpdVjey
# 4HWUc2fUWqijSnyhHMrswgI/HarxZAZEBX6TcrVYyuuVwm/LIIlqfGg4R5M3JGgY
# uEmexaCt4c/fIBLAbTmhzwQ4xDUKFceoB4GiI66gdNZQ6889xAu5JPYwmqK+ljnX
# u98Y0UatBgTF3ya7TMHL1D5KkF9S7yzNQwYoh+WT654PfjUlAlsCQfdeqZ3rWAxZ
# IFvpOjljAbrohXqeKGqf5+ShX6Tmb2Xd9sHBiWwbZhQ4NMOGfoAhTdtmYAUNOS+T
# aolThLAliOf5cvXM3yrXCfYrJiDTbvlkWxOInFYk61iKCzDMm7Yb/jcrS0xr6l50
# rhrOh/ydJtJIa31Dz2wvk+22Q84ZqyBy+1RTJ1thlAxycQ8o3a35mSiAUGwzcI98
# 6VTw4gOWaKiOqpbaPvv1ofEkhDWcIUGJK6k9JdVNuCppL7BGfbJXqkKSBqxjExqn
# G3A3QdWF6Ko/7US23gaMk4GO5k9ELSDZKiysnQUs4zs1r+nr21e8hsFfKyOYJ/nq
# l+0TSzCHkpYEGRyO1AsCWDrw7b8mIvF6ty5RmE7e6B/W+WmsectLDnnlX6rTxYSU
# BGQivwgrfdDWRsVGXTr1Lw==
# =E6wg
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 13 Jul 2026 13:02:28 BST
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full]
# gpg: aka "Peter Maydell <peter@archaic.org.uk>" [unknown]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* tag 'pull-target-arm-20260713' of https://gitlab.com/pm215/qemu: (26 commits)
hw/misc/stm32_rcc: Correct offset-to-irq calculation
hw/misc/allwinner-r40-ccu.c: Correct handling of out of range accesses
hw/display/sm501: Don't allow guest to set ram size larger than it is
hw/display/sm501: Avoid overflow problems in bounds check calculations
hw/display/sm501: Catch bad coordinates for RTL operations
hw/usb/dev-wacom: Don't write off end of buffer
hw/net/vmxnet3: Correct bounds check on tx queue index
hw/dma: don't allow weird transfer lengths for bcm2835
target/arm: Be more defensive for invalid tlbi_aa64_get_range
arm/virt: fix smmuv3_devices leak
docs/system: add FEAT_HAF
docs/system: add FEAT_S2TGran[4|16|64]K features
docs/system: fix sorting of FEAT_S2[PIE|FWB]
docs/system: document FEAT_IVIPT
docs/system: document FEAT_MTE4
docs/system: document FEAT_Secure
docs/system: add big and little endian features names
docs/system: declare support for FEAT_EVT2
hw/i2c: pmbus: clear output buffer on write
hw/arm/smmuv3: Enforce alignment of L2Ptr according to the span
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The K230 machine supports direct Linux boot and firmware boot through
the SDK U-Boot, but neither path has functional test coverage.
Add one test for each boot path. Both tests use the Yocto initramfs
assets and wait for the shell prompt to confirm a successful boot.
Fetch the boot assets from the k230-boot-assets repository maintained
by Chao Liu. Pin the URLs to a repository commit and verify each asset
with its SHA-256 digest.
Signed-off-by: Junze Cao <caojunze424@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260711125320.72319-1-caojunze424@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Add a minimal dlcall plugin that lets the guest invoke host functions
through magic system calls. The plugin registers a vCPU syscall filter
callback that intercepts a reserved syscall number and dispatches a set
of pass-through operations: querying host attributes, loading and freeing
shared libraries, resolving symbols, retrieving the last library error,
and invoking a host function through a common interface.
The magic syscall number defaults to 4096 and can be overridden at load
time with the "syscall_num=N" argument; values low enough to clash with a
real syscall are rejected.
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/20260711094523.622997-2-functioner@sjtu.edu.cn
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
A number of us have moved on from IBM.
* Alexey moved to AMD in 2022.
* Andrew moved to Code Construct in 2023.
* Ben moved to Amazon in 2019.
* Cedric moved to Redhat.
* Daniel moved to Ventana in 2024.
* Greg moved to Redhat.
* Joel moved to Tenstorrent in 2025.
* Suraj moved to Amazon in 2019
Most have either stopped working on QEMU or swtiched to corp addresses.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Greg Kurz <groug@kaod.org>
Message-ID: <20260709080040.4157324-5-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Alpha has never set AT_HWCAP in linux-user emulation, so getauxval(AT_HWCAP)
always returned 0 regardless of the emulated CPU model.
The Linux kernel computes ELF_HWCAP as ~amask(-1), i.e. the set of ISA
extension bits that the amask instruction reports as supported (cleared in
its output). env->amask stores exactly those bits with the same layout
(BWX=0x1, FIX=0x2, CIX=0x4, MVI=0x100, TRAP=0x200, PREFETCH=0x1000), so
returning it directly from get_elf_hwcap matches the kernel convention.
Add HAVE_ELF_HWCAP to target_elf.h and implement get_elf_hwcap() in
elfload.c to expose the emulated CPU's capability mask to user-space
programs via the auxiliary vector.
Without this fix, programs using getauxval(AT_HWCAP) to detect BWX/FIX/CIX
(such as glibc's memcpy or JIT compilers targeting Alpha) incorrectly
concluded that no extensions were available even when emulating ev56+.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
In the STM32 RCC, there is a block of 5 "enable" registers, each of
which has 32 bits; each bit determines the level of one of the 5 * 32
= 160 enable_irq output lines. The code calculates the irq to be
worked on using
irq_offset = ((addr - STM32_RCC_AHB1_ENR) / 4) * 32;
This assumes that the registers are all consecutive; however, there
is a gap between the AHB1/2/3 registers and the APB1/2 registers, so
for the APB1/2 registers we calculate a number that is 32 too high
and can index off the end of the enable_irq[] array.
The handling of the reset registers has an identical bug.
Adjust the calculation of irq_offset to cope with the gap, and fix
the case labels so accesses to the gap fall into the default
LOG_UNIMP rather than being treated as if they were an actual
register.
Coverity CID: 1663683, 1663686
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20260709104832.1989240-1-peter.maydell@linaro.org
In allwinner_r40_ccu_write() we handle writes to a MemoryRegion of
size AW_R40_CCU_IOSIZE, and the register array is sized accordingly
at (AW_R40_CCU_IOSIZE / sizeof(uint32_t)). However, one of the cases
in the switch is a range up to AW_R40_CCU_IOSIZE, which makes
Coverity think we might index off the end of the array. We also
have a similar case in the read function, but since that returns
early it doesn't have the same issue.
Adjust the handling of out of range accesses:
- use AW_R40_CCU_IOSIZE - 4 as the upper bound, as this is the
largest value we will actually see
- return early in the write case, as we do in the read case
Coverity CID: 1663687
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Strahinja Jankovic <strahinja.p.jankovic@gmail.com>
Message-id: 20260709104802.1989086-1-peter.maydell@linaro.org
The SM501 DRAM_CONTROL register has a 7 bit Size field which allows
the guest to change the local memory size. We use the local memory
size in bounds checks calculations for 2D operations. Currently we
have no check on the validity of the value the guest programs to
this field, which means that the guest can:
- set it to a reserved value (6 or 7) which will cause
get_local_mem_size() to read outside sm501_mem_local_size[]
- set it to a value corresponding to more RAM than the card
was created with, so that the 2D bounds check will let 2D
operations access off the end of the memory region
Fix this by decoupling the value the guest reads and writes to this
field from the internal size we consider the local memory to have.
We validate changes and ignore them except for readback if they would
be reserved values or values for more memory than the card has.
Cc: qemu-stable@nongnu.org
Reported-by: Heechan Kang
Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260707150933.1410507-4-peter.maydell@linaro.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3811
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The sm501 code doesn't check whether a right-to-left operation has
specified a width greater than the x-coordinate (which would make it
extend off the left edge of the screen), or similarly a height
greater than the y-coordinate. This means the guest can misprogram
the device so that we underflow when calculating the address of the
top left pixel, which might result in accessing out of bounds
memory. Catch this as a guest error and ignore the operation.
Reported-by: Yannick Wang
Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260707150933.1410507-2-peter.maydell@linaro.org
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3920
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In usb_wacom_handle_data() we allocate a buffer with a size
determined by the transfer size requested by the guest. We then fill
it in by calling either usb_mouse_poll() or usb_wacom_poll(), both of
which functions take a length and return an actual length, which we
pass to usb_packet_copy(). However, usb_mouse_poll() doesn't check
the buffer size as it fills in the buffer, so if the guest passes an
overly short transfer size then it will write off the end of the
allocated buffer.
Check the length is at least big enough for the minimum 3 byte
packet and return nothing if it is not, as usb_wacom_poll() does.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3672
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260706182034.1003176-1-peter.maydell@linaro.org
Generally we expect a PMBus sensor to issue writes after all pending
reads have completed. If a data read needs to be resumed, this state can
be tracked in the device model and the pending data placed in the output
buffer.
Signed-off-by: Titus Rwantare <titusr@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260706230056.1888992-4-titusr@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
