Jamin Lin [Fri, 21 Mar 2025 09:25:58 +0000 (17:25 +0800)]
hw/misc/aspeed_hace: Fix buffer overflow in has_padding function
The maximum padding size is either 64 or 128 bytes and should always be smaller
than "req_len". If "padding_size" exceeds "req_len", then
"req_len - padding_size" underflows due to "uint32_t" data type, leading to a
large incorrect value (e.g., `0xFFXXXXXX`). This causes an out-of-bounds memory
access, potentially leading to a buffer overflow.
Added a check to ensure "padding_size" does not exceed "req_len" before
computing "pad_offset". This prevents "req_len - padding_size" from underflowing
and avoids accessing invalid memory.
Nicholas Piggin [Thu, 20 Mar 2025 12:24:40 +0000 (22:24 +1000)]
target/ppc: Fix e200 duplicate SPRs
DSRR0/1 registers are in the BookE ISA not e200 specific, so
remove the duplicate e200 register definitions.
Cc: Roman Kapl <rka@sysgo.com> Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2768 Fixes: 0e3bf4890906 ("ppc: add DBCR based debugging") Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
(cherry picked from commit 73c0c904fc99e2ceecbbded84ec76d40d3f2daae)
(Mjt: context fix for v9.0.0-935-g581eea5d656b "target/ppc: Split off common embedded TLB init") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Santiago Monserrat Campanello <santimonserr@gmail.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2717 Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250305102632.91376-1-santimonserr@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 672cb29d1e811180bf1aeefbcb0936ecd5bd3853) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Add .set_vnet_le() function that always returns success, assuming that
vDPA h/w always implements LE data format. Otherwise, QEMU disables vDPA and
outputs the message:
"backend does not support LE vnet headers; falling back on userspace virtio"
Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit b027f55a994af885a7a498a40373a2dcc2d8b15e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
VDPA didn't work on a big-endian machine due to missing/incorrect
CPU<->LE data format conversions.
Signed-off-by: Konstantin Shkolnyy <kshk@linux.ibm.com>
Message-Id: <20250212164923.1971538-1-kshk@linux.ibm.com> Fixes: 10857ec0ad ("vhost: Add VhostShadowVirtqueue") Acked-by: Eugenio Pérez <eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 50e9754149066dc91f58405d3378b589098cb408) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Guo Hongyu [Thu, 19 Dec 2024 12:23:11 +0000 (20:23 +0800)]
target/loongarch: Fix vldi inst
Refer to the link below for a description of the vldi instructions:
https://jia.je/unofficial-loongarch-intrinsics-guide/lsx/misc/#synopsis_88
Fixed errors in vldi instruction implementation.
Signed-off-by: Guo Hongyu <guohongyu24@mails.ucas.ac.cn> Tested-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Xianglai Li <lixianglai@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
(cherry picked from commit 02ce6cea71be4f6774351f5e658d50044c5b53b2)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2865 Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/arm: Simplify pstate_sm check in sve_access_check
In StreamingMode, fp_access_checked is handled already.
We cannot fall through to fp_access_check lest we fall
foul of the double-check assertion.
Cc: qemu-stable@nongnu.org Fixes: 285b1d5fcef ("target/arm: Handle SME in sve_access_check") Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250307190415.982049-3-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: move declaration of 'ret' to top of block] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit cc7abc35dfa790ba6c20473c03745428c1c626b6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/arm: Make DisasContext.{fp, sve}_access_checked tristate
The check for fp_excp_el in assert_fp_access_checked is
incorrect. For SME, with StreamingMode enabled, the access
is really against the streaming mode vectors, and access
to the normal fp registers is allowed to be disabled.
C.f. sme_enabled_check.
Convert sve_access_checked to match, even though we don't
currently check the exception state.
Cc: qemu-stable@nongnu.org Fixes: 3d74825f4d6 ("target/arm: Add SME enablement checks") Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250307190415.982049-2-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 298a04998fa4a6dc977abe9234d98dfcdab98423) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Joe Komlodi [Mon, 10 Mar 2025 20:36:22 +0000 (20:36 +0000)]
util/cacheflush: Make first DSB unconditional on aarch64
On ARM hosts with CTR_EL0.DIC and CTR_EL0.IDC set, this would only cause
an ISB to be executed during cache maintenance, which could lead to QEMU
executing TBs containing garbage instructions.
This seems to be because the ISB finishes executing instructions and
flushes the pipeline, but the ISB doesn't guarantee that writes from the
executed instructions are committed. If a small enough TB is created, it's
possible that the writes setting up the TB aren't committed by the time the
TB is executed.
This function is intended to be a port of the gcc implementation
(https://github.com/gcc-mirror/gcc/blob/85b46d0795ac76bc192cb8f88b646a647acf98c1/libgcc/config/aarch64/sync-cache.c#L67)
which makes the first DSB unconditional, so we can fix the synchronization
issue by doing that as well.
Cc: qemu-stable@nongnu.org Fixes: 664a79735e4deb1 ("util: Specialize flush_idcache_range for aarch64") Signed-off-by: Joe Komlodi <komlodi@google.com>
Message-id: 20250310203622.1827940-2-komlodi@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit e6c38d2ab55d66c74ceade5699e22cabe9058d22) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
These warnings are breaking some build configurations since 2 months
now (https://gitlab.com/qemu-project/qemu/-/issues/2575):
ui/cocoa.m:662:14: error: 'CVDisplayLinkCreateWithCGDisplay' is deprecated: first deprecated in macOS 15.0 - use NSView.displayLink(target:selector:), NSWindow.displayLink(target:selector:), or NSScreen.displayLink(target:selector:) [-Werror,-Wdeprecated-declarations]
662 | if (!CVDisplayLinkCreateWithCGDisplay(display, &displayLink)) {
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:89:20: note: 'CVDisplayLinkCreateWithCGDisplay' has been explicitly marked deprecated here
89 | CV_EXPORT CVReturn CVDisplayLinkCreateWithCGDisplay(
| ^
ui/cocoa.m:663:29: error: 'CVDisplayLinkGetNominalOutputVideoRefreshPeriod' is deprecated: first deprecated in macOS 15.0 - use NSView.displayLink(target:selector:), NSWindow.displayLink(target:selector:), or NSScreen.displayLink(target:selector:) [-Werror,-Wdeprecated-declarations]
663 | CVTime period = CVDisplayLinkGetNominalOutputVideoRefreshPeriod(displayLink);
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:182:18: note: 'CVDisplayLinkGetNominalOutputVideoRefreshPeriod' has been explicitly marked deprecated here
182 | CV_EXPORT CVTime CVDisplayLinkGetNominalOutputVideoRefreshPeriod( CVDisplayLinkRef CV_NONNULL displayLink );
| ^
ui/cocoa.m:664:13: error: 'CVDisplayLinkRelease' is deprecated: first deprecated in macOS 15.0 - use NSView.displayLink(target:selector:), NSWindow.displayLink(target:selector:), or NSScreen.displayLink(target:selector:) [-Werror,-Wdeprecated-declarations]
664 | CVDisplayLinkRelease(displayLink);
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:249:16: note: 'CVDisplayLinkRelease' has been explicitly marked deprecated here
249 | CV_EXPORT void CVDisplayLinkRelease( CV_RELEASES_ARGUMENT CVDisplayLinkRef CV_NULLABLE displayLink );
| ^
3 errors generated.
For the next release, ignore the warnings using #pragma directives.
At least until we figure the correct new API usage.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu> Tested-by: Phil Dennis-Jordan <phil@philjordan.eu>
Message-Id: <20241121131954.98949-1-philmd@linaro.org>
(cherry picked from commit 9cf6e41fe293dd56089faac94c36ff5cb3d96726) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Greg Kurz [Thu, 6 Mar 2025 17:41:13 +0000 (18:41 +0100)]
docs: Rename default-configs to configs
This was missed at the time.
Fixes: 812b31d3f91 ("configs: rename default-configs to configs and reorganise") Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250306174113.427116-1-groug@kaod.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 48170c2d865a5937092b1384421b01cd38113042)
(Mjt: context fix in docs/devel/kconfig.rst) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Kevin Wolf [Mon, 10 Mar 2025 10:48:58 +0000 (11:48 +0100)]
block: Zero block driver state before reopening
Block drivers assume in their .bdrv_open() implementation that their
state in bs->opaque has been zeroed; it is initially allocated with
g_malloc0() in bdrv_open_driver().
bdrv_snapshot_goto() needs to make sure that it is zeroed again before
calling drv->bdrv_open() to avoid that block drivers use stale values.
One symptom of this bug is VMDK running into a double free when the user
tries to apply an internal snapshot like 'qemu-img snapshot -a test
test.vmdk'. This should be a graceful error because VMDK doesn't support
internal snapshots.
==25507== Invalid free() / delete / delete[] / realloc()
==25507== at 0x484B347: realloc (vg_replace_malloc.c:1801)
==25507== by 0x54B592A: g_realloc (gmem.c:171)
==25507== by 0x1B221D: vmdk_add_extent (../block/vmdk.c:570)
==25507== by 0x1B1084: vmdk_open_sparse (../block/vmdk.c:1059)
==25507== by 0x1AF3D8: vmdk_open (../block/vmdk.c:1371)
==25507== by 0x1A2AE0: bdrv_snapshot_goto (../block/snapshot.c:299)
==25507== by 0x205C77: img_snapshot (../qemu-img.c:3500)
==25507== by 0x58FA087: (below main) (libc_start_call_main.h:58)
==25507== Address 0x832f3e0 is 0 bytes inside a block of size 272 free'd
==25507== at 0x4846B83: free (vg_replace_malloc.c:989)
==25507== by 0x54AEAC4: g_free (gmem.c:208)
==25507== by 0x1AF629: vmdk_close (../block/vmdk.c:2889)
==25507== by 0x1A2A9C: bdrv_snapshot_goto (../block/snapshot.c:290)
==25507== by 0x205C77: img_snapshot (../qemu-img.c:3500)
==25507== by 0x58FA087: (below main) (libc_start_call_main.h:58)
This error was discovered by fuzzing qemu-img.
Cc: qemu-stable@nongnu.org Closes: https://gitlab.com/qemu-project/qemu/-/issues/2853 Closes: https://gitlab.com/qemu-project/qemu/-/issues/2851 Reported-by: Denis Rastyogin <gerben@altlinux.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250310104858.28221-1-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit b75c5f9879166b86ed7c48b772fdcd0693e8a9a3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 28 Feb 2025 19:16:51 +0000 (19:16 +0000)]
hw/net/smc91c111: Don't allow data register access to overrun buffer
For accesses to the 91c111 data register, the address within the
packet's data frame is determined by a combination of the pointer
register and the offset used to access the data register, so that you
can access data at effectively wider than byte width. The pointer
register's pointer field is 11 bits wide, which is exactly the size
to index a 2048-byte data frame.
We weren't quite getting the logic right for ensuring that we end up
with a pointer value to use in the s->data[][] array that isn't out
of bounds:
* we correctly mask when getting the initial pointer value
* for the "autoincrement the pointer register" case, we
correctly mask after adding 1 so that the pointer register
wraps back around at the 2048 byte mark
* but for the non-autoincrement case where we have to add the
low 2 bits of the data register offset, we don't account
for the possibility that the pointer register is 0x7ff
and the addition should wrap
Fix this bug by factoring out the "get the p value to use as an array
index" into a function, making it use FIELD macro names rather than
hard-coded constants, and having a utility function that does "add a
value and wrap it" that we can use both for the "autoincrement" and
"add the offset bits" codepaths.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2758 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250228191652.1957208-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 700d3d6dd41de3bd3f1153e3cfe00b93f99b1441) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 28 Feb 2025 17:48:00 +0000 (17:48 +0000)]
hw/net/smc91c111: Sanitize packet length on tx
When the smc91c111 transmits a packet, it must read a control byte
which is at the end of the data area and CRC. However, we don't
sanitize the length field in the packet buffer, so if the guest sets
the length field to something large we will try to read past the end
of the packet data buffer when we access the control byte.
As usual, the datasheet says nothing about the behaviour of the
hardware if the guest misprograms it in this way. It says only that
the maximum valid length is 2048 bytes. We choose to log the guest
error and silently drop the packet.
This requires us to factor out the "mark the tx packet as complete"
logic, so we can call it for this "drop packet" case as well as at
the end of the loop when we send a valid packet.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2742 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250228174802.1945417-3-peter.maydell@linaro.org>
[PMD: Update smc91c111_do_tx() as len > MAX_PACKET_SIZE] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit aad6f264add3f2be72acb660816588fe09110069) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 28 Feb 2025 17:47:59 +0000 (17:47 +0000)]
hw/net/smc91c111: Sanitize packet numbers
The smc91c111 uses packet numbers as an index into its internal
s->data[][] array. Valid packet numbers are between 0 and 3, but
the code does not generally check this, and there are various
places where the guest can hand us an arbitrary packet number
and cause an out-of-bounds access to the data array.
Add validation of packet numbers. The datasheet is not very
helpful about how guest errors like this should be handled:
it says nothing on the subject, and none of the documented
error conditions are relevant. We choose to log the situation
with LOG_GUEST_ERROR and silently ignore the attempted operation.
In the places where we are about to access the data[][] array
using a packet number and we know the number is valid because
we got it from somewhere that has already validated, we add
an assert() to document that belief.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250228174802.1945417-2-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 2fa3a5b9469615d06091cf473d172794148e1248) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 7 Feb 2025 15:11:57 +0000 (15:11 +0000)]
hw/net/smc91c111: Ignore attempt to pop from empty RX fifo
The SMC91C111 includes an MMU Command register which permits
the guest to remove entries from the RX FIFO. The datasheet
does not specify what happens if the guest tries to do this
when the FIFO is already empty; there are no status registers
containing error bits which might be applicable.
Currently we don't guard at all against pop of an empty
RX FIFO, with the result that we allow the guest to drive
the rx_fifo_len index to negative values, which will cause
smc91c111_receive() to write to the rx_fifo[] array out of
bounds when we receive the next packet.
Instead ignore attempts to pop an empty RX FIFO.
Cc: qemu-stable@nongnu.org Fixes: 80337b66a8e7 ("NIC emulation for qemu arm-softmmu")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2780 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250207151157.3151776-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 937df81af6757638a7f1908747560dd342947213) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Afterward, there is no error and the sensor_groups directory appears
under /sys/firmware/opal/.
The SLW_IMAGE_BASE address looks like a workaround to intercept firmware
memory accesses, but that does not seem to be required now (and would
have been broken by the OCC common area region mapping change anyway).
So it can be removed.
Fixes: 3a1b70b66b5cb4 ("ppc/pnv: Fix OCC common area region mapping") Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
(cherry picked from commit 29c041ca7f8d6910c894788482efff892789dcd2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Eugenio Pérez [Mon, 6 Jan 2025 15:57:35 +0000 (10:57 -0500)]
net: move backend cleanup to NIC cleanup
Commit a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net
structures if peer nic is present") effectively delayed the backend
cleanup, allowing the frontend or the guest to access it resources as
long as the frontend is still visible to the guest.
However it does not clean up the resources until the qemu process is
over. This causes an effective leak if the device is deleted with
device_del, as there is no way to close the vdpa device. This makes
impossible to re-add that device to this or other QEMU instances until
the first instance of QEMU is finished.
Move the cleanup from qemu_cleanup to the NIC deletion and to
net_cleanup.
Fixes: a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net structures if peer nic is present") Reported-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit e7891c575fb294618b172119a91c892b8f4384a2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Eugenio Pérez [Mon, 6 Jan 2025 15:57:34 +0000 (10:57 -0500)]
net: parameterize the removing client from nc list
This change is used in later commits so we can avoid the removal of the
netclient if it is delayed.
No functional change intended.
Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit db0d4017f9b9e87f962b35dd19a4912bbfcd3cbc)
(Mjt: pick this one up for the following change,
"net: move backend cleanup to NIC cleanup") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Mon, 10 Feb 2025 13:58:04 +0000 (13:58 +0000)]
util/qemu-timer.c: Don't warp timer from timerlist_rearm()
Currently we call icount_start_warp_timer() from timerlist_rearm().
This produces incorrect behaviour, because timerlist_rearm() is
called, for instance, when a timer callback modifies its timer. We
cannot decide here to warp the timer forwards to the next timer
deadline merely because all_cpu_threads_idle() is true, because the
timer callback we were called from (or some other callback later in
the list of callbacks being invoked) may be about to raise a CPU
interrupt and move a CPU from idle to ready.
The only valid place to choose to warp the timer forward is from the
main loop, when we know we have no outstanding IO or timer callbacks
that might be about to wake up a CPU.
For Arm guests, this bug was mostly latent until the refactoring
commit f6fc36deef6abc ("target/arm/helper: Implement
CNTHCTL_EL2.CNT[VP]MASK"), which exposed it because it refactored a
timer callback so that it happened to call timer_mod() first and
raise the interrupt second, when it had previously raised the
interrupt first and called timer_mod() afterwards.
This call seems to have originally derived from the
pre-record-and-replay icount code, which (as of e.g. commit db1a49726c3c in 2010) in this location did a call to
qemu_notify_event(), necessary to get the icount code in the vCPU
round-robin thread to stop and recalculate the icount deadline when a
timer was reprogrammed from the IO thread. In current QEMU,
everything is done on the vCPU thread when we are in icount mode, so
there's no need to try to notify another thread here.
I suspect that the other reason why this call was doing icount timer
warping is that it pre-dates commit efab87cf79077a from 2015, which
added a call to icount_start_warp_timer() to main_loop_wait(). Once
the call in timerlist_rearm() has been removed, if the timer
callbacks don't cause any CPU to be woken up then we will end up
calling icount_start_warp_timer() from main_loop_wait() when the rr
main loop code calls rr_wait_io_event().
Remove the incorrect call from timerlist_rearm().
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2703 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20250210135804.3526943-1-peter.maydell@linaro.org
(cherry picked from commit 02ae315467cee589d02dfb89e13a2a6a8de09fc5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 7 Mar 2025 10:08:21 +0000 (10:08 +0000)]
target/arm: Correct STRD atomicity
Our STRD implementation doesn't correctly implement the requirement:
* if the address is 8-aligned the access must be a 64-bit
single-copy atomic access, not two 32-bit accesses
Rewrite the handling of STRD to use a single tcg_gen_qemu_st_i64()
of a value produced by concatenating the two 32 bit source registers.
This allows us to get the atomicity right.
As with the LDRD change, now that we don't update 'addr' in the
course of performing the store we need to adjust the offset
we pass to op_addr_ri_post() and op_addr_rr_post().
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250227142746.1698904-3-peter.maydell@linaro.org
(cherry picked from commit ee786ca115045a2b7e86ac3073b0761cb99e0d49) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 7 Mar 2025 10:08:21 +0000 (10:08 +0000)]
target/arm: Correct LDRD atomicity and fault behaviour
Our LDRD implementation is wrong in two respects:
* if the address is 4-aligned and the load crosses a page boundary
and the second load faults and the first load was to the
base register (as in cases like "ldrd r2, r3, [r2]", then we
must not update the base register before taking the fault
* if the address is 8-aligned the access must be a 64-bit
single-copy atomic access, not two 32-bit accesses
Rewrite the handling of the loads in LDRD to use a single
tcg_gen_qemu_ld_i64() and split the result into the destination
registers. This allows us to get the atomicity requirements
right, and also implicitly means that we won't update the
base register too early for the page-crossing case.
Note that because we no longer increment 'addr' by 4 in the course of
performing the LDRD we must change the adjustment value we pass to
op_addr_ri_post() and op_addr_rr_post(): it no longer needs to
subtract 4 to get the correct value to use if doing base register
writeback.
STRD has the same problem with not getting the atomicity right;
we will deal with that in the following commit.
Cc: qemu-stable@nongnu.org Reported-by: Stu Grossman <stu.grossman@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250227142746.1698904-2-peter.maydell@linaro.org
(cherry picked from commit cde3247651dc998da5dc1005148302a90d72f21f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Patrick Venture [Fri, 7 Mar 2025 10:08:19 +0000 (10:08 +0000)]
hw/gpio: npcm7xx: fixup out-of-bounds access
The reg isn't validated to be a possible register before
it's dereferenced for one case. The mmio space registered
for the gpio device is 4KiB but there aren't that many
registers in the struct.
Cc: qemu-stable@nongnu.org Fixes: 526dbbe0874 ("hw/gpio: Add GPIO model for Nuvoton NPCM7xx") Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250226024603.493148-1-venture@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 3b2e22c0bbe2ce07123d93961d52f17644562cd7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
docs/about/build-platforms: Correct minimum supported Python version
Fixes: ca056f4499c2 (Python: Drop support for Python 3.7) Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250227080757.3978333-2-armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 87c8b4fc3c1c89ec52540bfb74f9b0518f247323) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Denis Rastyogin [Tue, 4 Mar 2025 08:39:10 +0000 (11:39 +0300)]
block/qed: fix use-after-free by nullifying timer pointer after free
This error was discovered by fuzzing qemu-img.
In the QED block driver, the need_check_timer timer is freed in
bdrv_qed_detach_aio_context, but the pointer to the timer is not
set to NULL. This can lead to a use-after-free scenario
in bdrv_qed_drain_begin().
The need_check_timer pointer is set to NULL after freeing the timer.
Which helps catch this condition when checking in bdrv_qed_drain_begin().
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2852 Signed-off-by: Denis Rastyogin <gerben@altlinux.org>
Message-ID: <20250304083927.37681-1-gerben@altlinux.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 2ad638a3d160923ef3dbf87c73944e6e44bdc724) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Instead of migrating the raw tick_offset, goldfish_rtc migrates a
recalculated value based on QEMU_CLOCK_VIRTUAL. As QEMU_CLOCK_VIRTUAL
stands still across a save-and-restore cycle, the guest RTC becomes out
of sync with the host RTC when the VM is restored.
As described in the bug description, it looks like this calculation was
copied from pl031 RTC, which had its tick_offset migration fixed by
Commit 032cfe6a79c8 ("pl031: Correctly migrate state when using -rtc
clock=host").
Migrate the tick_offset directly, adding it as a version-dependent field
to VMState. Keep the old behavior when migrating from previous versions.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2033 Signed-off-by: Rodrigo Dias Correa <r@drigo.nl> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250114212150.228241-1-r@drigo.nl> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 3521f9cadc29c7d68b73b325ddb46a7acebf6212) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/riscv: throw debug exception before page fault
In the RISC-V privileged ISA section 3.1.15 table 15, it is determined
that a debug exception that is triggered from a load/store has a higher
priority than a possible fault that this access might trigger.
This is not the case ATM as shown in [1]. Adding a breakpoint in an
address that deliberately will fault is causing a load page fault
instead of a debug exception. The reason is that we're throwing in the
page fault as soon as the fault occurs (end of riscv_cpu_tlb_fill(),
raise_mmu_exception()), not allowing the installed watchpoints to
trigger.
Call cpu_check_watchpoint() in the page fault path to search and execute
any watchpoints that might exist for the address, never returning back
to the fault path. If no watchpoints are found cpu_check_watchpoint()
will return and we'll fall-through the regular path to
raise_mmu_exception().
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2627 Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250121170626.1992570-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit c86edc547692d812d1dcc04220c38310be2c00c3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/riscv/debug.c: use wp size = 4 for 32-bit CPUs
The mcontrol select bit (19) is always zero, meaning our triggers will
always match virtual addresses. In this condition, if the user does not
specify a size for the trigger, the access size defaults to XLEN.
At this moment we're using def_size = 8 regardless of CPU XLEN. Use
def_size = 4 in case we're running 32 bits.
Fixes: 95799e36c1 ("target/riscv: Add initial support for the Sdtrig extension") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250121170626.1992570-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 3fba76e61caa46329afc399b3ecaaba70c8b0a4e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Fri, 24 Jan 2025 10:14:47 +0000 (18:14 +0800)]
target/riscv: rvv: Fix unexpected behavior of vector reduction instructions when vl is 0
According to the Vector Reduction Operations section in the RISC-V "V"
Vector Extension spec,
"If vl=0, no operation is performed and the destination register is not
updated."
The vd should be updated when vl is larger than 0.
Fixes: fe5c9ab1fc ("target/riscv: vector single-width integer reduction instructions") Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR") Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20250124101452.2519171-1-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit ffd455963f230c7dc04965609d6675da687a5a78) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Joelle van Dyne [Mon, 24 Feb 2025 18:41:23 +0000 (10:41 -0800)]
target/arm/hvf: sign extend the data for a load operation when SSE=1
In the syndrome value for a data abort, bit 21 is SSE, which is
set to indicate that the abort was on a sign-extending load. When
we handle the data abort from the guest via address_space_read(),
we forgot to handle this and so would return the wrong value if
the guest did a sign-extending load to an MMIO region. Add the
sign-extension of the returned data.
Cc: qemu-stable@nongnu.org Signed-off-by: Joelle van Dyne <j@getutm.app>
Message-id: 20250224184123.50780-1-j@getutm.app
[PMM: Drop an unnecessary check on 'len'; expand commit message] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 12c365315ab25d364cff24dfeea8d7ff1e752b9f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Bibo Mao [Tue, 18 Feb 2025 03:20:27 +0000 (11:20 +0800)]
target/loongarch/gdbstub: Fix gdbstub incorrectly handling some registers
Write operation with R32 (orig_a0) and R34 (CSR_BADV) is discarded on
gdbstub implementation for LoongArch system. And return value should
be register size rather than 0, since it is used to calculate offset of
next register such as R33 (PC) in function handle_write_all_regs().
Cc: qemu-stable@nongnu.org Fixes: ca61e75071c6 ("target/loongarch: Add gdb support.") Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
(cherry picked from commit 7bd4eaa847fcdbc4505d9ab95dafa21791d8302a)
(Mjt: context fix due to missing v9.1.0-913-g2a99b2af2c
"target/loongarch: Use explicit little-endian LD/ST API") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
cryptodev/vhost: allocate CryptoDevBackendVhost using g_mem0()
The function `vhost_dev_init()` expects the `struct vhost_dev`
(passed as a parameter) to be fully initialized. This is important
because some parts of the code check whether `vhost_dev->config_ops`
is NULL to determine if it has been set (e.g. later via
`vhost_dev_set_config_notifier`).
To ensure this initialization, it’s better to allocate the entire
`CryptoDevBackendVhost` structure (which includes `vhost_dev`) using
`g_mem0()`, following the same approach used for other vhost devices,
such as in `vhost_net_init()`.
Fixes: 042cea274c ("cryptodev: add vhost-user as a new cryptodev backend") Cc: qemu-stable@nongnu.org Reported-by: myluo24@m.fudan.edu.cn Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Message-Id: <20250211135523.101203-1-sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 83cb18ac4500f3a14067b19408705068647cb0c5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Sairaj Kodilkar [Fri, 7 Feb 2025 04:53:54 +0000 (10:23 +0530)]
amd_iommu: Use correct bitmask to set capability BAR
AMD IOMMU provides the base address of control registers through
IVRS table and PCI capability. Since this base address is of 64 bit,
use 32 bits mask (instead of 16 bits) to set BAR low and high.
Fixes: d29a09ca68 ("hw/i386: Introduce AMD IOMMU") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20250207045354.27329-3-sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 3684717b7407cc395dc9bf522e193dbc85293dee) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Sairaj Kodilkar [Fri, 7 Feb 2025 04:53:53 +0000 (10:23 +0530)]
amd_iommu: Use correct DTE field for interrupt passthrough
Interrupt passthrough is determine by the bits 191,190,187-184.
These bits are part of the 3rd quad word (i.e. index 2) in DTE. Hence
replace dte[3] by dte[2].
Fixes: b44159fe0 ("x86_iommu/amd: Add interrupt remap support when VAPIC is not enabled") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20250207045354.27329-2-sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 63dc0b8647391b372f3bb38ff1066f6b4a5e6ea1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Kconfig: Extract CONFIG_USB_CHIPIDEA from CONFIG_IMX
TYPE_CHIPIDEA models an IP block which is also used in TYPE_ZYNQ_MACHINE which
itself is not an IMX device. CONFIG_ZYNQ selects CONFIG_USB_EHCI_SYSBUS while
TYPE_CHIPIDEA is a separate compilation unit, so only works by accident if
CONFIG_IMX is given. Fix that by extracting CONFIG_USB_CHIPIDEA from CONFIG_IMX.
cc: qemu-stable@nongnu.org Fixes: 616ec12d0fcc "hw/arm/xilinx_zynq: Fix USB port instantiation" Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-id: 20250209103604.29545-1-shentey@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 464ce71a963b3dfc290cd59c3d1bfedf11c004df)
(Mjt: context fixup due to missing v9.1.0-609-ge02491903d50 "hw/usb: Remove tusb6010 USB controller", v9.2.0-1303-g1b326f278d05 "hw/pci-host/designware: Expose MSI IRQ") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 30 Jan 2025 18:23:02 +0000 (18:23 +0000)]
target/arm: Honour SDCR.TDCC and SCR.TERR in AArch32 EL3 non-Monitor modes
There are not many traps in AArch32 which should trap to Monitor
mode, but these trap bits should trap not just lower ELs to Monitor
mode but also the non-Monitor modes running at EL3 (i.e. Secure
System, Secure Undef, etc).
We get this wrong because the relevant access functions implement the
AArch64-style logic of
if (el < 3 && trap_bit_set) {
return CP_ACCESS_TRAP_EL3;
}
which won't trap the non-Monitor modes at EL3.
Correct this error by using arm_is_el3_or_mon() instead, which
returns true when the CPU is at AArch64 EL3 or AArch32 Monitor mode.
(Since the new callsites are compiled also for the linux-user mode,
we need to provide a dummy implementation for CONFIG_USER_ONLY.)
This affects only:
* trapping of ERRIDR via SCR.TERR
* trapping of the debug channel registers via SDCR.TDCC
* trapping of GICv3 registers via SCR.IRQ and SCR.FIQ
(which we already used arm_is_el3_or_mon() for)
This patch changes the handling of SCR.TERR and SDCR.TDCC. This
patch only changes guest-visible behaviour for "-cpu max" on
the qemu-system-arm binary, because SCR.TERR
and SDCR.TDCC (and indeed the entire SDCR register) only arrived
in Armv8, and the only guest CPU we support which has any v8
features and also starts in AArch32 EL3 is the 32-bit 'max'.
Other uses of CP_ACCESS_TRAP_EL3 don't need changing:
* uses in code paths that can't happen when EL3 is AArch32:
access_trap_aa32s_el1, cpacr_access, cptr_access, nsacr_access
* uses which are in accessfns for AArch64-only registers:
gt_stimer_access, gt_cntpoff_access, access_hxen, access_tpidr2,
access_smpri, access_smprimap, access_lor_ns, access_pauth,
access_mte, access_tfsr_el2, access_scxtnum, access_fgt
* trap bits which exist only in the AArch64 version of the
trap register, not the AArch32 one:
access_tpm, pmreg_access, access_dbgvcr32, access_tdra,
access_tda, access_tdosa (TPM, TDA and TDOSA exist only in
MDCR_EL3, not in SDCR, and we enforce this in sdcr_write())
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250130182309.717346-8-peter.maydell@linaro.org
(cherry picked from commit 4d436fb05c2a1fff7befc815ebcbb04a14977448) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 30 Jan 2025 18:23:01 +0000 (18:23 +0000)]
hw/intc/arm_gicv3_cpuif: Don't downgrade monitor traps for AArch32 EL3
In the gicv3_{irq,fiq,irqfiq}_access() functions, there is a check
which downgrades a CP_ACCESS_TRAP_EL3 to CP_ACCESS_TRAP if EL3 is not
AArch64. This has been there since the GIC was first implemented,
but it isn't right: if we are trapping because of SCR.IRQ or SCR.FIQ
then we definitely want to be going to EL3 (doing
AArch32.TakeMonitorTrapException() in pseudocode terms). We might
want to not take a trap at all, but we don't ever want to go to the
default target EL, because that would mean, for instance, taking a
trap to Hyp mode if the trapped access was made from Hyp mode.
(This might have been an attempt to work around our failure to
properly implement Monitor Traps.)
Remove the bogus check.
Cc: qemu-stable@nongnu.org Fixes: 359fbe65e01e ("hw/intc/arm_gicv3: Implement GICv3 CPU interface registers") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250130182309.717346-7-peter.maydell@linaro.org
(cherry picked from commit d04c6c3c000ab3e588a2b91641310aeea89408f7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 30 Jan 2025 18:23:00 +0000 (18:23 +0000)]
target/arm: Make CP_ACCESS_TRAPs to AArch32 EL3 be Monitor traps
In system register access pseudocode the common pattern for
AArch32 registers with access traps to EL3 is:
at EL1 and EL2:
if HaveEL(EL3) && !ELUsingAArch32(EL3) && (SCR_EL3.TERR == 1) then
AArch64.AArch32SystemAccessTrap(EL3, 0x03);
elsif HaveEL(EL3) && ELUsingAArch32(EL3) && (SCR.TERR == 1) then
AArch32.TakeMonitorTrapException();
at EL3:
if (PSTATE.M != M32_Monitor) && (SCR.TERR == 1) then
AArch32.TakeMonitorTrapException();
(taking as an example the ERRIDR access pseudocode).
This implements the behaviour of (in this case) SCR.TERR that
"Accesses to the specified registers from modes other than Monitor
mode generate a Monitor Trap exception" and of SCR_EL3.TERR that
"Accesses of the specified Error Record registers at EL2 and EL1
are trapped to EL3, unless the instruction generates a higher
priority exception".
In QEMU we don't implement this pattern correctly in two ways:
* in access_check_cp_reg() we turn the CP_ACCESS_TRAP_EL3 into
an UNDEF, not a trap to Monitor mode
* in the access functions, we check trap bits like SCR.TERR
only when arm_current_el(env) < 3 -- this is correct for
AArch64 EL3, but misses the "trap non-Monitor-mode execution
at EL3 into Monitor mode" case for AArch32 EL3
In this commit we fix the first of these two issues, by
making access_check_cp_reg() handle CP_ACCESS_TRAP_EL3
as a Monitor trap. This is a kind of exception that we haven't
yet implemented(!), so we need a new EXCP_MON_TRAP for it.
This diverges from the pseudocode approach, where every access check
function explicitly checks for "if EL3 is AArch32" and takes a
monitor trap; if we wanted to be closer to the pseudocode we could
add a new CP_ACCESS_TRAP_MONITOR and make all the accessfns use it
when appropriate. But because there are no non-standard cases in the
pseudocode (i.e. where either it raises a Monitor trap that doesn't
correspond to an AArch64 SystemAccessTrap or where it raises a
SystemAccessTrap that doesn't correspond to a Monitor trap), handling
this all in one place seems less likely to result in future bugs
where we forgot again about this special case when writing an
accessor.
(The cc of stable here is because "hw/intc/arm_gicv3_cpuif: Don't
downgrade monitor traps for AArch32 EL3" which is also cc:stable
will implicitly use the new EXCP_MON_TRAP code path.)
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250130182309.717346-6-peter.maydell@linaro.org
(cherry picked from commit 4cf4948651615181c5bc3d0e4a9f5c46be576bb2)
(Mjt: context fix due to missing v9.0.0-151-gb36a32ead159 "target/arm: Add support for Non-maskable Interrupt") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 30 Jan 2025 18:22:59 +0000 (18:22 +0000)]
target/arm: Report correct syndrome for UNDEFINED LOR sysregs when NS=0
The pseudocode for the accessors for the LOR sysregs says they
are UNDEFINED if SCR_EL3.NS is 0. We were reporting the wrong
syndrome value here; use CP_ACCESS_TRAP_UNCATEGORIZED.
Cc: qemu-stable@nongnu.org Fixes: 2d7137c10faf ("target/arm: Implement the ARMv8.1-LOR extension") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250130182309.717346-5-peter.maydell@linaro.org
(cherry picked from commit 707d478ed8f2da6f2327e5af780890c1fd9c371a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 30 Jan 2025 18:22:58 +0000 (18:22 +0000)]
target/arm: Report correct syndrome for UNDEFINED S1E2 AT ops at EL3
The pseudocode for AT S1E2R and AT S1E2W says that they should be
UNDEFINED if executed at EL3 when EL2 is not enabled. We were
incorrectly using CP_ACCESS_TRAP and reporting the wrong exception
syndrome as a result. Use CP_ACCESS_TRAP_UNCATEGORIZED.
Cc: qemu-stable@nongnu.org Fixes: 2a47df953202e1 ("target-arm: Wire up AArch64 EL2 and EL3 address translation ops") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250130182309.717346-4-peter.maydell@linaro.org
(cherry picked from commit ccda792945d650bce4609c8dbce8814a220df1bb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 30 Jan 2025 18:22:57 +0000 (18:22 +0000)]
target/arm: Report correct syndrome for UNDEFINED AT ops with wrong NSE, NS
R_NYXTL says that these AT insns should be UNDEFINED if they
would operate on an EL lower than EL3 and SCR_EL3.{NSE,NS} is
set to the Reserved {1, 0}. We were incorrectly reporting
them with the wrong syndrome; use CP_ACCESS_TRAP_UNCATEGORIZED
so they are reported as UNDEFINED.
Cc: qemu-stable@nongnu.org Fixes: 1acd00ef1410 ("target/arm/helper: Check SCR_EL3.{NSE, NS} encoding for AT instructions") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250130182309.717346-3-peter.maydell@linaro.org
(cherry picked from commit 1960d9701ef7ed8d24e98def767bbf05d63e6992) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 30 Jan 2025 18:22:56 +0000 (18:22 +0000)]
target/arm: Report correct syndrome for UNDEFINED CNTPS_*_EL1 from EL2 and NS EL1
The access pseudocode for the CNTPS_TVAL_EL1, CNTPS_CTL_EL1 and
CNTPS_CVAL_EL1 secure timer registers says that they are UNDEFINED
from EL2 or NS EL1. We incorrectly return CP_ACCESS_TRAP from the
access function in these cases, which means that we report the wrong
syndrome value to the target EL.
Use CP_ACCESS_TRAP_UNCATEGORIZED, which reports the correct syndrome
value for an UNDEFINED instruction.
Cc: qemu-stable@nongnu.org Fixes: b4d3978c2fd ("target-arm: Add the AArch64 view of the Secure physical timer") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250130182309.717346-2-peter.maydell@linaro.org
(cherry picked from commit b819fd6994243aee6f9613edbbacedce4f511c32) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Fabiano Rosas [Thu, 13 Feb 2025 14:35:58 +0000 (11:35 -0300)]
elfload: Fix alignment when unmapping excess reservation
When complying with the alignment requested in the ELF and unmapping
the excess reservation, having align_end not aligned to the guest page
causes the unmap to be rejected by the alignment check at
target_munmap and later brk adjustments hit an EEXIST.
Fix by aligning the start of region to be unmapped.
Fixes: c81d1fafa6 ("linux-user: Honor elf alignment when placing images")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1913 Signed-off-by: Fabiano Rosas <farosas@suse.de>
[rth: Align load_end as well.] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250213143558.10504-1-farosas@suse.de>
(cherry picked from commit 4b7b20a3b72c5000ea71bef505c16e6e628268b6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
linux-user: Honor elf alignment when placing images
Most binaries don't actually depend on more than page alignment,
but any binary can request it. Not honoring this was a bug.
This became obvious when gdb reported
Failed to read a valid object file image from memory
when examining some vdso which are marked as needing more
than page alignment.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit c81d1fafa6233448bcc2d8fcd2ba63a4ae834f3a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The gdbstub implementation for the Sparc architecture would
incorrectly calculate the the floating point register offset.
This resulted in, for example, registers f32 and f34 to point to
the same value.
The issue was caused by the confusion between even register numbers
and even register indexes. For example, the register index of f32 is 64
and f34 is 65.
Cc: qemu-stable@nongnu.org Fixes: 30038fd81808 ("target-sparc: Change fpr representation to doubles.") Signed-off-by: Mikael Szreder <git@miszr.win> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250214070343.11501-1-git@miszr.win>
(cherry picked from commit 7a74e468089a58756b438d31a2a9a97f183780d7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Volker Rümelin [Tue, 31 Dec 2024 11:59:50 +0000 (12:59 +0100)]
ui/sdl2: reenable the SDL2 Windows keyboard hook procedure
Windows only:
The libSDL2 Windows message loop needs the libSDL2 Windows low
level keyboard hook procedure to grab the left and right Windows
keys correctly. Reenable the SDL2 Windows keyboard hook procedure.
Since SDL2 2.30.4 the SDL2 keyboard hook procedure also filters
out the special left Control key event for every Alt Gr key event
on keyboards with an international layout. This means the QEMU low
level keyboard hook procedure is no longer needed. Remove the QEMU
Windows keyboard hook procedure.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2139
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2323 Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Link: https://lore.kernel.org/r/20241231115950.6732-1-vr_qemu@t-online.de Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 4dafba778aa3e5f5fd3b2c6333afd7650dcf54e2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fix in ui/sdl2.c and adaptation in ui/meson.build)
Thomas Huth [Tue, 11 Feb 2025 11:47:18 +0000 (12:47 +0100)]
gitlab-ci.d/cirrus: Update the FreeBSD job to v14.2
The FreeBSD job started to fail since the 14-1 image disappeared
from the cloud. Update the job to v14.2 to fix it.
Message-ID: <20250211120817.35050-1-thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 66a1b4991c32e370a4e0ddabf496aa1563aff286) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Khem Raj [Fri, 7 Feb 2025 16:09:20 +0000 (16:09 +0000)]
linux-user: Do not define struct sched_attr if libc headers do
glibc 2.41+ has added [1] definitions for sched_setattr and
sched_getattr functions and struct sched_attr. Therefore, it needs
to be checked for here as well before defining sched_attr, to avoid
a compilation failure.
Define sched_attr conditionally only when SCHED_ATTR_SIZE_VER0 is
not defined.
Ilya Leoshkevich [Tue, 28 Jan 2025 00:12:42 +0000 (01:12 +0100)]
target/s390x: Fix MVC not always invalidating translation blocks
Node.js crashes in qemu-system-s390x with random SIGSEGVs / SIGILLs.
The v8 JIT used by Node.js can garbage collect and overwrite unused
code. Overwriting is performed by WritableJitAllocation::CopyCode(),
which ultimately calls memcpy(). For certain sizes, memcpy() uses the
MVC instruction.
QEMU implements MVC and other similar instructions using helpers. While
TCG store ops invalidate affected translation blocks automatically,
helpers must do this manually by calling probe_access_flags(). The MVC
helper does this using the access_prepare() -> access_prepare_nf() ->
s390_probe_access() -> probe_access_flags() call chain.
At the last step of this chain, the store size is replaced with 0. This
causes the probe_access_flags() -> notdirty_write() ->
tb_invalidate_phys_range_fast() chain to miss some translation blocks.
When this happens, QEMU executes a mix of old and new code. This
quickly leads to either a SIGSEGV or a SIGILL in case the old code
ends in the middle of a new instruction.
Fix by passing the true size.
Reported-by: Berthold Gunreben <azouhr@opensuse.org> Cc: Sarah Kriesch <ada.lovelace@gmx.de> Cc: qemu-stable@nongnu.org Closes: https://bugzilla.opensuse.org/show_bug.cgi?id=1235709 Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Fixes: e2faabee78ff ("accel/tcg: Forward probe size on to notdirty_write")
Message-ID: <20250128001338.11474-1-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit e43ced8be18dda77c229ab09f85136a4d600d40d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
qemu_ram_alloc_from_fd allocates space if file_size == 0. If non-zero,
it uses the existing space and verifies it is large enough, but the
verification was broken when the offset parameter was introduced. As
a result, a file smaller than offset passes the verification and causes
errors later. Fix that, and update the error message to include offset.
With the fix, the error message is:
qemu-system-x86_64: mem1 backing store size 0x4000000 is too small for 'size' option 0x8000000 plus 'offset' option 0x8000000
Hongren Zheng [Mon, 13 Jan 2025 09:38:56 +0000 (17:38 +0800)]
hw/usb/canokey: Fix buffer overflow for OUT packet
When USBPacket in OUT direction has larger payload
than the ep_out_buffer (of size 512), a buffer overflow
would occur.
It could be fixed by limiting the size of usb_packet_copy
to be at most buffer size. Further optimization gets rid
of the ep_out_buffer and directly uses ep_out as the target
buffer.
This is reported by a security researcher who artificially
constructed an OUT packet of size 2047. The report has gone
through the QEMU security process, and as this device is for
testing purpose and no deployment of it in virtualization
environment is observed, it is triaged not to be a security bug.
Cc: qemu-stable@nongnu.org Fixes: d7d34918551dc48 ("hw/usb: Add CanoKey Implementation") Reported-by: Juan Jose Lopez Jaimez <thatjiaozi@gmail.com> Signed-off-by: Hongren Zheng <i@zenithal.me>
Message-id: Z4TfMOrZz6IQYl_h@Sun Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 664280abddcb3cacc9c6204706bb739fcc1316f7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 24 Jan 2025 16:27:23 +0000 (16:27 +0000)]
target/arm: arm_reset_sve_state() should set FPSR, not FPCR
The pseudocode ResetSVEState() does:
FPSR = ZeroExtend(0x0800009f<31:0>, 64);
but QEMU's arm_reset_sve_state() called vfp_set_fpcr() by accident.
Before the advent of FEAT_AFP, this was only setting a collection of
RES0 bits, which vfp_set_fpsr() would then ignore, so the only effect
was that we didn't actually set the FPSR the way we are supposed to
do. Once FEAT_AFP is implemented, setting the bottom bits of FPSR
will change the floating point behaviour.
Call vfp_set_fpsr(), as we ought to.
(Note for stable backports: commit 7f2a01e7368f9 moved this function
from sme_helper.c to helper.c, but it had the same bug before the
move too.)
Cc: qemu-stable@nongnu.org Fixes: f84734b87461 ("target/arm: Implement SMSTART, SMSTOP") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250124162836.2332150-4-peter.maydell@linaro.org
(cherry picked from commit 1edc3d43f20df0d04f8d00b906ba19fed37512a5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This assertion always happens when we sanitize the CXL memory device.
$ echo 1 > /sys/bus/cxl/devices/mem0/security/sanitize
It is incorrect to register an MSIX number beyond the device's capability.
Increase the device's MSIX number to cover the mailbox msix number(9).
Fixes: 43efb0bfad2b ("hw/cxl/mbox: Wire up interrupts for background completion") Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Message-Id: <20250115075834.167504-1-lizhijian@fujitsu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 1ce979e7269a34d19ea1a65808df014d8b2acbf6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20250115125342.3883374-4-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 9fb1c9a1bb26e111ee5fa5538070cd684de14c08) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: rebuild acpi tables for 8.2)
Igor Mammedov [Wed, 15 Jan 2025 12:53:41 +0000 (13:53 +0100)]
pci: acpi: Windows 'PCI Label Id' bug workaround
Current versions of Windows call _DSM(func=7) regardless
of whether it is supported or not. It leads to NICs having bogus
'PCI Label Id = 0', where none should be set at all.
Also presence of 'PCI Label Id' triggers another Windows bug
on localized versions that leads to hangs. The later bug is fixed
in latest updates for 'Windows Server' but not in consumer
versions of Windows (and there is no plans to fix it
as far as I'm aware).
Given it's easy, implement Microsoft suggested workaround
(return invalid Package) so that affected Windows versions
could boot on QEMU.
This would effectvely remove bogus 'PCI Label Id's on NICs,
but MS teem confirmed that flipping 'PCI Label Id' should not
change 'Network Connection' ennumeration, so it should be safe
for QEMU to change _DSM without any compat code.
Smoke tested with WinXP and WS2022
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/774 Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20250115125342.3883374-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 0b053391985abcc40b16ac8fc4a7f6588d1d95c1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Igor Mammedov [Wed, 15 Jan 2025 12:53:40 +0000 (13:53 +0100)]
tests: acpi: whitelist expected blobs
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20250115125342.3883374-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 1ad32644fe4c9fb25086be15a66dde1d55d3410f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: drop x86/ subdir and tables not relevant for 8.2)
Nicholas Piggin [Thu, 12 Dec 2024 12:04:02 +0000 (22:04 +1000)]
pci/msix: Fix msix pba read vector poll end calculation
The end vector calculation has a bug that results in polling fewer
than required vectors when reading at a non-zero offset in PBA memory.
Fixes: bbef882cc193 ("msi: add API to get notified about pending bit poll") Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-Id: <20241212120402.1475053-1-npiggin@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 42e2a7a0ab23784e44fcb18369e06067abc89305) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Sebastian Ott [Tue, 3 Dec 2024 12:19:28 +0000 (13:19 +0100)]
pci: ensure valid link status bits for downstream ports
PCI hotplug for downstream endpoints on arm fails because Linux'
PCIe hotplug driver doesn't like the QEMU provided LNKSTA:
pcieport 0000:08:01.0: pciehp: Slot(2): Card present
pcieport 0000:08:01.0: pciehp: Slot(2): Link Up
pcieport 0000:08:01.0: pciehp: Slot(2): Cannot train link: status 0x2000
There's 2 cases where LNKSTA isn't setup properly:
* the downstream device has no express capability
* max link width of the bridge is 0
Move the sanity checks added via 88c869198aa63
("pci: Sanity test minimum downstream LNKSTA") outside of the
branch to make sure downstream ports always have a valid LNKSTA.
Signed-off-by: Sebastian Ott <sebott@redhat.com> Tested-by: Zhenyu Zhang <zhenyzha@redhat.com>
Message-Id: <20241203121928.14861-1-sebott@redhat.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 694632fd44987cc4618612a38ad151047524a590) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/usb/hcd-xhci-pci: Use modulo to select MSI vector as per spec
QEMU would crash with a failed assertion if the XHCI controller
attempted to raise the interrupt on an interrupter corresponding
to a MSI vector with a higher index than the highest configured
for the device by the guest driver.
This behaviour is correct on the MSI/PCI side: per PCI 3.0 spec,
devices must ensure they do not send MSI notifications for
vectors beyond the range of those allocated by the system/driver
software. Unlike MSI-X, there is no generic way for handling
aliasing in the case of fewer allocated vectors than requested,
so the specifics are up to device implementors. (Section
6.8.3.4. "Sending Messages")
It turns out the XHCI spec (Implementation Note in section 4.17,
"Interrupters") requires that the host controller signal the MSI
vector with the number computed by taking the interrupter number
modulo the number of enabled MSI vectors.
This change introduces that modulo calculation, fixing the
failed assertion. This makes the device work correctly in MSI mode
with macOS's XHCI driver, which only allocates a single vector.
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250112210056.16658-2-phil@philjordan.eu> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit bb5b7fced6b5d3334ab20702fc846e47bb1fb731) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
tests/qtest/boot-serial-test: Correct HPPA machine name
Commit 7df6f751176 ("hw/hppa: Split out machine creation")
renamed the 'hppa' machine as 'B160L', but forgot to update
the boot serial test, which ended being skipped.
Cc: qemu-stable@nongnu.org Fixes: 7df6f751176 ("hw/hppa: Split out machine creation") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20250102100340.43014-2-philmd@linaro.org>
(cherry picked from commit a87077316ed2f1c1c8ba8faf05feed9dbf0f2fee) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Han Han [Thu, 19 Dec 2024 08:51:38 +0000 (16:51 +0800)]
target/i386/cpu: Fix notes for CPU models
Fixes: 644e3c5d812 ("missing vmx features for Skylake-Server and Cascadelake-Server") Signed-off-by: Han Han <hhan@redhat.com> Reviewed-by: Chenyi Qiang <chenyi.qiang@intel.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 93dcc9390e5ad0696ae7e9b7b3a5b08c2d1b6de6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
TCG trace-events were deprecated before the v6.2 release,
and removed for v7.0.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit b4859e8f33a7d9c793a60395f792c10190cb4f78) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Bibo Mao [Thu, 12 Dec 2024 08:22:34 +0000 (16:22 +0800)]
target/loongarch: Use actual operand size with vbsrl check
Hardcoded 32 bytes is used for vbsrl emulation check, there is
problem when options lsx=on,lasx=off is used for vbsrl.v instruction
in TCG mode. It injects LASX exception rather LSX exception.
Here actual operand size is used.
Cc: qemu-stable@nongnu.org Fixes: df97f338076 ("target/loongarch: Implement xvreplve xvinsve0 xvpickve") Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit d41989e7548397b469ec9c7be4cee699321a317e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Let's handle that in a better way by rejecting such weird RAM sizes
right from the start:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: ram size must be multiples of 1 MiB
Message-ID: <20241219144115.2820241-2-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com>
(cherry picked from commit 14e568ab4836347481af2e334009c385f456a734) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Albert Esteve [Tue, 22 Oct 2024 12:46:14 +0000 (14:46 +0200)]
vhost-user: fix shared object return values
VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
in the spec that they return 0 for successful
operations, non-zero otherwise. However,
implementation relies on the return types
of the virtio-dmabuf library, with opposite
semantics (true if everything is correct,
false otherwise). Therefore, current
implementation violates the specification.
Revert the logic so that the implementation
of the vhost-user handling methods matches
the specification.
Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce Fixes: 160947666276c5b7f6bca4d746bcac2966635d79 Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Albert Esteve <aesteve@redhat.com>
Message-Id: <20241022124615.585596-1-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit eea5aeef84e1b74f515b474d3a86377701f93750) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: remove changes fixing v8.2.0-2279-g043e127a126b
"hw/virtio: check owner for removing objects")
Thomas Huth [Wed, 18 Dec 2024 06:21:59 +0000 (07:21 +0100)]
meson.build: Disallow libnfs v6 to fix the broken macOS build
The macOS builds in our CI (and possibly other very recent distros)
are currently broken since the update to libnfs version 6 there.
That version apparently comes with a big API breakage. v5.0.3 was
the final release of the old API (see the libnfs commit here:
https://github.com/sahlberg/libnfs/commit/4379837 ).
Disallow version 6.x for now to get the broken CI job working
again. Once somebody had enough time to adapt our code in
block/nfs.c, we can revert this change again.
Message-ID: <20241218065157.209020-1-thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit e2d98f257138b83b6a492d1da5847a7fe0930d10) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 13 Dec 2024 18:23:37 +0000 (18:23 +0000)]
hw/intc/arm_gicv3_its: Zero initialize local DTEntry etc structs
In the GICv3 ITS model, we have a common coding pattern which has a
local C struct like "DTEntry dte", which is a C representation of an
in-guest-memory data structure, and we call a function such as
get_dte() to read guest memory and fill in the C struct. These
functions to read in the struct sometimes have cases where they will
leave early and not fill in the whole struct (for instance get_dte()
will set "dte->valid = false" and nothing else for the case where it
is passed an entry_addr implying that there is no L2 table entry for
the DTE). This then causes potential use of uninitialized memory
later, for instance when we call a trace event which prints all the
fields of the struct. Sufficiently advanced compilers may produce
-Wmaybe-uninitialized warnings about this, especially if LTO is
enabled.
Rather than trying to carefully separate out these trace events into
"only the 'valid' field is initialized" and "all fields can be
printed", zero-init all the structs when we define them. None of
these structs are large (the biggest is 24 bytes) and having
consistent behaviour is less likely to be buggy.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2718 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241213182337.3343068-1-peter.maydell@linaro.org
(cherry picked from commit 9678b9c505725732353baefedb88b53c2eb8a184) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Gerd Hoffmann [Wed, 27 Mar 2024 10:24:45 +0000 (11:24 +0100)]
edk2: get version + date from git submodule
Turned out hard-coding version and date in the Makefile wasn't a bright
idea. Updating it on edk2 updates is easily forgotten. Fetch the info
from git instead. Store in edk2-version, so this can be committed to
the repo and is present in tarballs too.
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20240327102448.61877-2-kraxel@redhat.com>
(cherry picked from commit 6539c73dccfa8fff1f83d40f1c4477a233876071) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
If the binary loaded via -kernel is *not* a linux kernel (in which
case protocol == 0), do not patch the linux kernel header fields.
It's (a) pointless and (b) might break binaries by random patching
and (c) changes the binary hash which in turn breaks secure boot
verification.
Background: OVMF happily loads and runs not only linux kernels but
any efi binary via direct kernel boot.
Note: Breaking the secure boot verification is a problem for linux
kernels too, but fixed that is left for another day ...
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20240905141211.1253307-3-kraxel@redhat.com>
(cherry picked from commit 57e2cc9abf5da38f600354fe920ff20e719607b4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: it is in hw/i386/x86.c not hw/i386/x86-common.c in 8.2.x)
Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20240527040711.311865-1-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit e7fca81e170530104c36bd8f3e1d7e7c11011481) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)")
caused a regression with security_model=passthrough. When handling a
'Tmknod' request there was a side effect that 'Tmknod' request could fail
as 9p server was trying to adjust permissions:
#6 close_if_special_file (fd=30) at ../hw/9pfs/9p-util.h:140
#7 openat_file (mode=<optimized out>, flags=2228224,
name=<optimized out>, dirfd=<optimized out>) at
../hw/9pfs/9p-util.h:181
#8 fchmodat_nofollow (dirfd=dirfd@entry=31,
name=name@entry=0x5555577ea6e0 "mysocket", mode=493) at
../hw/9pfs/9p-local.c:360
#9 local_set_cred_passthrough (credp=0x7ffbbc4ace10, name=0x5555577ea6e0
"mysocket", dirfd=31, fs_ctx=0x55555811f528) at
../hw/9pfs/9p-local.c:457
#10 local_mknod (fs_ctx=0x55555811f528, dir_path=<optimized out>,
name=0x5555577ea6e0 "mysocket", credp=0x7ffbbc4ace10) at
../hw/9pfs/9p-local.c:702
#11 v9fs_co_mknod (pdu=pdu@entry=0x555558121140,
fidp=fidp@entry=0x5555574c46c0, name=name@entry=0x7ffbbc4aced0,
uid=1000, gid=1000, dev=<optimized out>, mode=49645,
stbuf=0x7ffbbc4acef0) at ../hw/9pfs/cofs.c:205
#12 v9fs_mknod (opaque=0x555558121140) at ../hw/9pfs/9p.c:3711
That's because server was opening the special file to adjust permissions,
however it was using O_PATH and it would have not returned the file
descriptor to guest. So the call to close_if_special_file() on that branch
was incorrect.
Let's lift the restriction introduced by f6b0de53fb8 such that it would
allow to open special files on host if O_PATH flag is supplied, not only
for 9p server's own operations as described above, but also for any client
'Topen' request.
It is safe to allow opening special files with O_PATH on host, because
O_PATH only allows path based operations on the resulting file descriptor
and prevents I/O such as read() and write() on that file descriptor.
Fixes: f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2337 Reported-by: Dirk Herrendorfer <d.herrendoerfer@de.ibm.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Dirk Herrendorfer <d.herrendoerfer@de.ibm.com>
Message-Id: <E1tJWbk-007BH4-OB@kylie.crudebyte.com>
(cherry picked from commit d06a9d843fb65351e0e4dc42ba0c404f01ea92b3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
.gitlab-ci.d/cirrus: Drop support for macOS 13 (Ventura)
macOS 15 "Sequoia" was released on September 16, 2024 [1].
According to QEMU's support policy, we stop supporting
the previous major release two years after the the new
major release has been published. Time to remove support
for macOS 13 (Ventura, released on October 2022, [2]).
Promote the macOS 14 job, which was only built manually,
to be run by default.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240917085058.1740-3-philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit de11da6448ca4278197fb2923af06c50e2385259)
[thuth: Pick some changes from 9094f7c934, too] Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Thomas Huth [Fri, 26 Apr 2024 11:37:42 +0000 (13:37 +0200)]
.gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs
During the past months, the netbsd and openbsd jobs in the Cirrus-CI
were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
from gitlab via the cirrus-run script was very fragile, and since the
jobs were not run by default, it used to bitrot very fast.
Now Cirrus-CI also introduce a limit on the amount of free CI minutes
that you get there, so it is not appealing at all anymore to run
these BSDs in this setup - it's better to run the checks locally via
"make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
remove these CI jobs now.
Message-ID: <20240426113742.654748-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit cc6cb422e09592158586279fddeef107df05ecbb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 28 Nov 2024 10:38:31 +0000 (10:38 +0000)]
target/riscv: Avoid bad shift in riscv_cpu_do_interrupt()
In riscv_cpu_do_interrupt() we use the 'cause' value we got out of
cs->exception as a shift value. However this value can be larger
than 31, which means that "1 << cause" is undefined behaviour,
because we do the shift on an 'int' type.
This causes the undefined behaviour sanitizer to complain
on one of the check-tcg tests:
$ UBSAN_OPTIONS=print_stacktrace=1:abort_on_error=1:halt_on_error=1 ./build/clang/qemu-system-riscv64 -M virt -semihosting -display none -device loader,file=build/clang/tests/tcg/riscv64-softmmu/issue1060
../../target/riscv/cpu_helper.c:1805:38: runtime error: shift exponent 63 is too large for 32-bit type 'int'
#0 0x55f2dc026703 in riscv_cpu_do_interrupt /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../target/riscv/cpu_helper.c:1805:38
#1 0x55f2dc3d170e in cpu_handle_exception /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../accel/tcg/cpu-exec.c:752:9
In this case cause is RISCV_EXCP_SEMIHOST, which is 0x3f.
Use 1ULL instead to ensure that the shift is in range.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Fixes: 1697837ed9 ("target/riscv: Add M-mode virtual interrupt and IRQ filtering support.") Fixes: 40336d5b1d ("target/riscv: Add HS-mode virtual interrupt and IRQ filtering support.") Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20241128103831.3452572-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 5311599cdc48337f2f27b1b51a80d46d75b05ed0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Ahmad Fatoum [Thu, 22 Aug 2024 16:38:38 +0000 (18:38 +0200)]
hw/openrisc/openrisc_sim: keep serial@90000000 as default
We used to only have a single UART on the platform and it was located at
address 0x90000000. When the number of UARTs was increased to 4, the
first UART remained at it's location, but instead of being the first one
to be registered, it became the last.
This caused QEMU to pick 0x90000300 as the default UART, which broke
software that hardcoded the address of 0x90000000 and expected it's
output to be visible when the user configured only a single console.
This caused regressions[1] in the barebox test suite when updating to a
newer QEMU. As there seems to be no good reason to register the UARTs in
inverse order, let's register them by ascending address, so existing
software can remain oblivious to the additional UART ports.
Changing the order of uart registration alone breaks Linux which
was choosing the UART at 0x90000300 as the default for ttyS0. To fix
Linux we fix three things in the device tree:
1. Define stdout-path only one time for the first registered UART
instead of incorrectly defining for each UART.
2. Change the UART alias name from 'uart0' to 'serial0' as almost all
Linux tty drivers look for an alias starting with "serial".
3. Add the UART nodes so they appear in the final DTB in the
order starting with the lowest address and working upwards.
In summary these changes mean that the QEMU default UART (serial_hd(0))
is now setup where:
* serial_hd(0) is the lowest-address UART
* serial_hd(0) is listed first in the DTB
* serial_hd(0) is the /chosen/stdout-path one
* the /aliases/serial0 alias points at serial_hd(0)
Fixes: 777784bda468 ("hw/openrisc: support 4 serial ports in or1ksim") Cc: qemu-stable@nongnu.org Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
[stafford: Change to serial0 alias and update change message, reverse
uart registration order] Signed-off-by: Stafford Horne <shorne@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 26dcf2be7e153defa289d20317707af034aca692) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Klaus Jensen [Mon, 11 Nov 2024 11:14:49 +0000 (12:14 +0100)]
hw/nvme: take a reference on the subsystem on vf realization
Make sure we grab a reference on the subsystem when a VF is realized.
Otherwise, the subsytem will be unrealized automatically when the VFs
are unregistered and unreffed.
This fixes a latent bug but was not exposed until commit 08f632848008
("pcie: Release references of virtual functions"). This was then fixed
(or rather, hidden) by commit c613ad25125b ("pcie_sriov: Do not manually
unrealize"), but that was then reverted (due to other issues) in commit b0fdaee5d1ed, exposing the bug yet again.
Cc: qemu-stable@nongnu.org Fixes: 08f632848008 ("pcie: Release references of virtual functions") Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit 6651f8f2e5051f6750c2534ab3151339b3c476a2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Klaus Jensen [Sun, 10 Nov 2024 13:04:27 +0000 (14:04 +0100)]
hw/nvme: fix msix_uninit with exclusive bar
Commit fa905f65c554 introduced a machine compatibility parameter to
enable an exclusive bar for msix. It failed to account for this when
cleaning up. Make sure that if an exclusive bar is enabled, we use the
proper cleanup routine.
Cc: qemu-stable@nongnu.org Fixes: fa905f65c554 ("hw/nvme: add machine compatibility parameter to enable msix exclusive bar") Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit 9162f101257639cc4c7e20f72f77268b1256dd79) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Nicholas Piggin [Mon, 11 Nov 2024 06:37:49 +0000 (16:37 +1000)]
target/ppc: Fix non-maskable interrupt while halted
The ppc (pnv and spapr) NMI injection code does not go through the
asynchronous interrupt path and set a bit in env->pending_interrupts
and raise an interrupt request that the cpu_exec() loop can see.
Instead it injects the exception directly into registers.
This can lead to cpu_exec() missing that the thread has work to do,
if a NMI is injected while it was idle.
Fix this by clearing halted when injecting the interrupt. Probably
NMI injection should be reworked to use the interrupt request interface,
but this seems to work as a minimal fix.
Fixes: 3431648272d3 ("spapr: Add support for new NMI interface") Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
(cherry picked from commit fa416ae6157a933ad3f7106090684759baaaf3c9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
With a valid file ID (FID) of an open file, it should be possible to send
a 'Tgettattr' 9p request and successfully receive a 'Rgetattr' response,
even if the file has been removed in the meantime. Currently this would
fail with ENOENT.
I.e. this fixes the following misbehaviour with a 9p Linux client:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename") = 0
fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory)
This is because 9p server is always using a path name based lstat() call
which fails as soon as the file got removed. So to fix this, use fstat()
whenever we have an open file descriptor already.
Fixes: 00ede4c2529b ("virtio-9p: getattr server implementation...")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/103 Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <4c41ad47f449a5cc8bfa9285743e029080d5f324.1732465720.git.qemu_oss@crudebyte.com>
(cherry picked from commit c81e7219e0736f80bfd3553676a19e2992cff41d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The comment claims that we'd only support basic Tgetattr fields. This is
no longer true, so remove this comment.
Fixes: e06a765efbe3 ("hw/9pfs: Add st_gen support in getattr reply") Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <fb364d12045217a4c6ccd0dd6368103ddb80698b.1732465720.git.qemu_oss@crudebyte.com>
(cherry picked from commit 3bc4db44430f53387d17145bb52b330a830a03fe) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: pick it to stable so the next commit applies cleanly)
After removing a file from the file system, we should still be able to
work with the file if we already had it open before removal.
As a first step we verify that it is possible to write to an unlinked
file, as this is what already works. This test is extended later on
after having fixed other use cases after unlink that are not working
yet.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <3d6449d4df25bcdd3e807eff169f46f1385e5257.1732465720.git.qemu_oss@crudebyte.com>
(cherry picked from commit 462db8fb1d405391b83a0d3099fdb9bfb85c2d92) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fix, pick it to stable so the next patch in this place applies)
'Tgetattr' 9p request and its 'Rgetattr' response types are already used
by test client, however this response type is yet missing in function
rmessage_name(), so add it.
Fixes: a6821b828404 ("tests/9pfs: compare QIDs in fs_walk_none() test") Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <e183da80d390cfd7d55bdbce92f0ff6e3e5cdced.1732465720.git.qemu_oss@crudebyte.com>
(cherry picked from commit 4ec984965079b51a9afce339af75edea6de973a2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Guenter Roeck [Tue, 28 Feb 2023 17:11:29 +0000 (09:11 -0800)]
scsi: megasas: Internal cdbs have 16-byte length
Host drivers do not necessarily set cdb_len in megasas io commands.
With commits 6d1511cea0 ("scsi: Reject commands if the CDB length
exceeds buf_len") and fe9d8927e2 ("scsi: Add buf_len parameter to
scsi_req_new()"), this results in failures to boot Linux from affected
SCSI drives because cdb_len is set to 0 by the host driver.
Set the cdb length to its actual size to solve the problem.
Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Link: https://lore.kernel.org/r/20230228171129.4094709-1-linux@roeck-us.net Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 3abb67323aeecf06a27191076ab50424ec21f334) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Jakub Jelen [Wed, 13 Nov 2024 12:55:23 +0000 (12:55 +0000)]
ssh: Do not switch session to non-blocking mode
The libssh does not handle non-blocking mode in SFTP correctly. The
driver code already changes the mode to blocking for the SFTP
initialization, but for some reason changes to non-blocking mode.
This used to work accidentally until libssh in 0.11 branch merged
the patch to avoid infinite looping in case of network errors:
Since then, the ssh driver in qemu fails to read files over SFTP
as the first SFTP messages exchanged after switching the session
to non-blocking mode return SSH_AGAIN, but that message is lost
int the SFTP internals and interpretted as SSH_ERROR, which is
returned to the caller:
This is indeed an issue in libssh that we should address in the
long term, but it will require more work on the internals. For
now, the SFTP is not supported in non-blocking mode.
Fixes: https://gitlab.com/libssh/libssh-mirror/-/issues/280 Signed-off-by: Jakub Jelen <jjelen@redhat.com> Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Message-ID: <20241113125526.2495731-1-rjones@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit fbdea3d6c13d5a75895c287a004c6f1a6bf6c164) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Kevin Wolf [Tue, 19 Nov 2024 12:03:53 +0000 (13:03 +0100)]
qdev: Fix set_pci_devfn() to visit option only once
pci_devfn properties accept either a string or an integer as input. To
implement this, set_pci_devfn() first tries to visit the option as a
string, and if that fails, it visits it as an integer instead. While the
QemuOpts visitor happens to accept this, it is invalid according to the
visitor interface. QObject input visitors run into an assertion failure
when this is done.
QObject input visitors are used with the JSON syntax version of -device
on the command line:
The proper way to accept both strings and integers is using the
alternate mechanism, which tells us the type of the input before it's
visited. With this information, we can directly visit it as the right
type.
This fixes set_pci_devfn() by using the alternate mechanism.
Cc: qemu-stable@nongnu.org Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20241119120353.57812-1-kwolf@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 5102f9df4a9a7adfbd902f9515c3f8f53dba288e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Akihiko Odaki [Fri, 22 Nov 2024 05:03:08 +0000 (14:03 +0900)]
virtio-net: Fix size check in dhclient workaround
work_around_broken_dhclient() accesses IP and UDP headers to detect
relevant packets and to calculate checksums, but it didn't check if
the packet has size sufficient to accommodate them, causing out-of-bound
access hazards. Fix this by correcting the size requirement.
Fixes: 1d41b0c1ec66 ("Work around dhclient brokenness") Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit a8575f7fb2f213e6690b23160b04271d47fdfaa8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Ilya Leoshkevich [Wed, 20 Nov 2024 21:26:44 +0000 (22:26 +0100)]
linux-user: Fix strace output for s390x mmap()
print_mmap() assumes that mmap() receives arguments via memory if
mmap2() is present. s390x (as opposed to s390) does not fit this
pattern: it does not have mmap2(), but mmap() still receives arguments
via memory.
Fix by sharing the detection logic between syscall.c and strace.c.
Cc: qemu-stable@nongnu.org Fixes: d971040c2d16 ("linux-user: Fix strace output for old_mmap") Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-ID: <20241120212717.246186-1-iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit d95fd9838b540e69da9b07538ec8ad6ab9eab260) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: compensate for chris architecture removal by v9.1.0-282-gbff4b02ca1f4
"linux-user: Remove support for CRIS target")
projects / thirdparty / qemu.git / log
