Branch: refs/heads/staging-10.0
Home: https://github.com/qemu/qemu
Commit: a03d7d6e32236d5c1b331e07b11cd7991f0d3a74
https://github.com/qemu/qemu/commit/a03d7d6e32236d5c1b331e07b11cd7991f0d3a74
Author: Aleksandr Partanen <alex.pentag...@gmail.com>
Date: 2025-05-11 (Sun, 11 May 2025)
Changed paths:
M hw/xen/xen-mapcache.c
Log Message:
-----------
xen: mapcache: Fix finding matching entry
If we have request without lock and hit unlocked or invalid
entry during the search, we remap it immediately,
even if we have matching entry in next entries in bucket.
This leads to duplication of mappings of the same size,
and to possibility of selecting the wrong element
during invalidation and underflow it's entry->lock counter
Signed-off-by: Aleksandr Partanen <alex.pentag...@gmail.com>
Reviewed-by: Stefano Stabellini <sstabell...@kernel.org>
Reviewed-by: Edgar E. Iglesias <edgar.igles...@amd.com>
Signed-off-by: Edgar E. Iglesias <edgar.igles...@amd.com>
(cherry picked from commit a4b20f737cda06bb8706a83e27f7fa89863ae689)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: bfa3f55f0fe9a4185577447faedcb5b4b302f947
https://github.com/qemu/qemu/commit/bfa3f55f0fe9a4185577447faedcb5b4b302f947
Author: Edgar E. Iglesias <edgar.igles...@amd.com>
Date: 2025-05-11 (Sun, 11 May 2025)
Changed paths:
M hw/xen/xen-mapcache.c
Log Message:
-----------
xen: mapcache: Split mapcache_grants by ro and rw
Today, we don't track write-abiliy in the cache, if a user
requests a readable mapping followed by a writeable mapping
on the same page, the second lookup will incorrectly hit
the readable entry.
Split mapcache_grants by ro and rw access. Grants will now
have separate ways in the cache depending on writeability.
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Reviewed-by: Stefano Stabellini <sstabell...@kernel.org>
Signed-off-by: Edgar E. Iglesias <edgar.igles...@amd.com>
(cherry picked from commit 88fb705600a3b612c571efc9f1a6aed923a18dcc)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 9340920c3f5d62d72c62f6e18094815ebc9f8144
https://github.com/qemu/qemu/commit/9340920c3f5d62d72c62f6e18094815ebc9f8144
Author: Bernhard Beschow <shen...@gmail.com>
Date: 2025-05-11 (Sun, 11 May 2025)
Changed paths:
M hw/i2c/imx_i2c.c
Log Message:
-----------
hw/i2c/imx: Always set interrupt status bit if interrupt condition occurs
According to the i.MX 8M Plus reference manual, the status flag
I2C_I2SR[IIF] continues to be set when an interrupt condition
occurs even when I2C interrupts are disabled (I2C_I2CR[IIEN] is
clear). However, the device model only sets the flag when I2C
interrupts are enabled which causes U-Boot to loop forever. Fix
the device model by always setting the flag and let I2C_I2CR[IIEN]
guard I2C interrupts only.
Also remove the comment in the code since it merely stated the
obvious and would be outdated now.
Cc: qemu-sta...@nongnu.org
Fixes: 20d0f9cf6a41 ("i.MX: Add I2C controller emulator")
Signed-off-by: Bernhard Beschow <shen...@gmail.com>
Acked-by: Corey Minyard <cminy...@mvista.com>
Message-ID: <20250507124040.425773-1-shen...@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
(cherry picked from commit 54e54e594bc8273d210f7ff4448c165a989cbbe8)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 5081dc508d4b60c1ed33f160bc6916048e098cad
https://github.com/qemu/qemu/commit/5081dc508d4b60c1ed33f160bc6916048e098cad
Author: Christian Schoenebeck <qemu_...@crudebyte.com>
Date: 2025-05-12 (Mon, 12 May 2025)
Changed paths:
M hw/9pfs/9p.c
M hw/9pfs/9p.h
Log Message:
-----------
9pfs: fix concurrent v9fs_reclaim_fd() calls
Even though this function is serialized to be always called from main
thread, v9fs_reclaim_fd() is dispatching the coroutine to a worker thread
in between via its v9fs_co_*() calls, hence leading to the situation where
v9fs_reclaim_fd() is effectively executed multiple times simultaniously,
which renders its LRU algorithm useless and causes high latency.
Fix this by adding a simple boolean variable to ensure this function is
only called once at a time. No synchronization needed for this boolean
variable as this function is only entered and returned on main thread.
Fixes: 7a46274529c ('hw/9pfs: Add file descriptor reclaim support')
Signed-off-by: Christian Schoenebeck <qemu_...@crudebyte.com>
Reviewed-by: Greg Kurz <gr...@kaod.org>
Message-Id:
<5c622067efd66dd4ee5eca740dcf263f41db20b2.1741339452.git.qemu_...@crudebyte.com>
(cherry picked from commit 61da38db70affd925226ce1e8a61d761c20d045b)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: a0f326228a927d65e3b2dc23eab17b88aadc1a03
https://github.com/qemu/qemu/commit/a0f326228a927d65e3b2dc23eab17b88aadc1a03
Author: Christian Schoenebeck <qemu_...@crudebyte.com>
Date: 2025-05-12 (Mon, 12 May 2025)
Changed paths:
M hw/9pfs/9p.c
Log Message:
-----------
9pfs: fix FD leak and reduce latency of v9fs_reclaim_fd()
This patch fixes two different bugs in v9fs_reclaim_fd():
1. Reduce latency:
This function calls v9fs_co_close() and v9fs_co_closedir() in a loop. Each
one of the calls adds two thread hops (between main thread and a fs driver
background thread). Each thread hop adds latency, which sums up in
function's loop to a significant duration.
Reduce overall latency by open coding what v9fs_co_close() and
v9fs_co_closedir() do, executing those and the loop itself altogether in
only one background thread block, hence reducing the total amount of
thread hops to only two.
2. Fix file descriptor leak:
The existing code called v9fs_co_close() and v9fs_co_closedir() to close
file descriptors. Both functions check right at the beginning if the 9p
request was cancelled:
if (v9fs_request_cancelled(pdu)) {
return -EINTR;
}
So if client sent a 'Tflush' message, v9fs_co_close() / v9fs_co_closedir()
returned without having closed the file descriptor and v9fs_reclaim_fd()
subsequently freed the FID without its file descriptor being closed, hence
leaking those file descriptors.
This 2nd bug is fixed by this patch as well by open coding v9fs_co_close()
and v9fs_co_closedir() inside of v9fs_reclaim_fd() and not performing the
v9fs_request_cancelled(pdu) check there.
Fixes: 7a46274529c ('hw/9pfs: Add file descriptor reclaim support')
Fixes: bccacf6c792 ('hw/9pfs: Implement TFLUSH operation')
Signed-off-by: Christian Schoenebeck <qemu_...@crudebyte.com>
Reviewed-by: Greg Kurz <gr...@kaod.org>
Message-Id:
<5747469d3f039c53147e850b456943a1d4b5485c.1741339452.git.qemu_...@crudebyte.com>
(cherry picked from commit 89f7b4da7662ecc6840ffb0846045f03f9714bc6)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 8efe15927b9692bf7202c20522c9c93267232e0d
https://github.com/qemu/qemu/commit/8efe15927b9692bf7202c20522c9c93267232e0d
Author: Fabiano Rosas <faro...@suse.de>
Date: 2025-05-16 (Fri, 16 May 2025)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390x: Fix leak in machine_set_loadparm
ASAN spotted a leaking string in machine_set_loadparm():
Direct leak of 9 byte(s) in 1 object(s) allocated from:
#0 0x560ffb5bb379 in malloc
../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
#1 0x7f1aca926518 in g_malloc ../glib/gmem.c:106
#2 0x7f1aca94113e in g_strdup ../glib/gstrfuncs.c:364
#3 0x560ffc8afbf9 in qobject_input_type_str
../qapi/qobject-input-visitor.c:542:12
#4 0x560ffc8a80ff in visit_type_str ../qapi/qapi-visit-core.c:349:10
#5 0x560ffbe6053a in machine_set_loadparm
../hw/s390x/s390-virtio-ccw.c:802:10
#6 0x560ffc0c5e52 in object_property_set ../qom/object.c:1450:5
#7 0x560ffc0d4175 in object_property_set_qobject ../qom/qom-qobject.c:28:10
#8 0x560ffc0c6004 in object_property_set_str ../qom/object.c:1458:15
#9 0x560ffbe2ae60 in update_machine_ipl_properties ../hw/s390x/ipl.c:569:9
#10 0x560ffbe2aa65 in s390_ipl_update_diag308 ../hw/s390x/ipl.c:594:5
#11 0x560ffbdee132 in handle_diag_308 ../target/s390x/diag.c:147:9
#12 0x560ffbebb956 in helper_diag ../target/s390x/tcg/misc_helper.c:137:9
#13 0x7f1a3c51c730 (/memfd:tcg-jit (deleted)+0x39730)
Cc: qemu-sta...@nongnu.org
Signed-off-by: Fabiano Rosas <faro...@suse.de>
Message-ID: <20250509174938.25935-1-faro...@suse.de>
Fixes: 1fd396e3228 ("s390x: Register TYPE_S390_CCW_MACHINE properties as class
properties")
Reviewed-by: Thomas Huth <th...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Signed-off-by: Thomas Huth <th...@redhat.com>
(cherry picked from commit bdf12f2a56bf3f13c52eb51f0a994bbfe40706b2)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 40558266b1bcea744427118fd6f848a9e31364e2
https://github.com/qemu/qemu/commit/40558266b1bcea744427118fd6f848a9e31364e2
Author: Akihiko Odaki <akihiko.od...@daynix.com>
Date: 2025-05-16 (Fri, 16 May 2025)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: Call set_features during reset
virtio-net expects set_features() will be called when the feature set
used by the guest changes to update the number of virtqueues but it is
not called during reset, which will clear all features, leaving the
queues added for VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS. Not only these
extra queues are visible to the guest, they will cause segmentation
fault during migration.
Call set_features() during reset to remove those queues for virtio-net
as we call set_status(). It will also prevent similar bugs for
virtio-net and other devices in the future.
Fixes: f9d6dbf0bf6e ("virtio-net: remove virtio queues if the guest doesn't
support multiqueue")
Buglink: https://issues.redhat.com/browse/RHEL-73842
Cc: qemu-sta...@nongnu.org
Signed-off-by: Akihiko Odaki <akihiko.od...@daynix.com>
Message-Id: <20250421-reset-v2-1-e4c1ead88...@daynix.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
(cherry picked from commit 0caed25cd171c611781589b5402161d27d57229c)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 15143814cddef24b69f3b19a9baca1b964dfe40c
https://github.com/qemu/qemu/commit/15143814cddef24b69f3b19a9baca1b964dfe40c
Author: Klaus Jensen <k.jen...@samsung.com>
Date: 2025-05-16 (Fri, 16 May 2025)
Changed paths:
M hw/nvme/subsys.c
Log Message:
-----------
hw/nvme: fix nvme hotplugging
Commit cd59f50ab017 caused a regression on nvme hotplugging for devices
with an implicit nvm subsystem.
The nvme-subsys device was incorrectly left with being marked as
non-hotpluggable. Fix this.
Cc: qemu-sta...@nongnu.org
Reported-by: Stéphane Graber <stgra...@stgraber.org>
Tested-by: Stéphane Graber <stgra...@stgraber.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2950
Fixes: cd59f50ab017 ("hw/nvme: always initialize a subsystem")
Reviewed-by: Keith Busch <kbu...@kernel.org>
Signed-off-by: Klaus Jensen <k.jen...@samsung.com>
(cherry picked from commit 0b1c23a582f7bc721a9b858c289a8d165152a6a0)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: f82dd2837c30af394fa5285523f2f517815c83a1
https://github.com/qemu/qemu/commit/f82dd2837c30af394fa5285523f2f517815c83a1
Author: Loïc Lefort <l...@rivosinc.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/pmp.c
Log Message:
-----------
target/riscv: pmp: don't allow RLB to bypass rule privileges
When Smepmp is supported, mseccfg.RLB allows bypassing locks when writing CSRs
but should not affect interpretation of actual PMP rules.
This is not the case with the current implementation where pmp_hart_has_privs
calls pmp_is_locked which implements mseccfg.RLB bypass.
This commit implements the correct behavior by removing mseccfg.RLB bypass from
pmp_is_locked.
RLB bypass when writing CSRs is implemented by adding a new pmp_is_readonly
function that calls pmp_is_locked and check mseccfg.RLB. pmp_write_cfg and
pmpaddr_csr_write are changed to use this new function.
Signed-off-by: Loïc Lefort <l...@rivosinc.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: LIU Zhiwei <zhiwei_...@linux.alibaba.com>
Message-ID: <20250313193011.720075-2-l...@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 4541d205f03cf1529439f68d2ec5056685189399)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 504dcda206464fe30ebf8224fc39a963dadad1e6
https://github.com/qemu/qemu/commit/504dcda206464fe30ebf8224fc39a963dadad1e6
Author: Loïc Lefort <l...@rivosinc.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/pmp.c
Log Message:
-----------
target/riscv: pmp: move Smepmp operation conversion into a function
Signed-off-by: Loïc Lefort <l...@rivosinc.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Reviewed-by: LIU Zhiwei <zhiwei_...@linux.alibaba.com>
Message-ID: <20250313193011.720075-3-l...@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 915b203745540e908943758f78f5da49e0a15e45)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: bc15a8db4ff857172625176b03b03138aa7624d1
https://github.com/qemu/qemu/commit/bc15a8db4ff857172625176b03b03138aa7624d1
Author: Loïc Lefort <l...@rivosinc.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/pmp.c
Log Message:
-----------
target/riscv: pmp: fix checks on writes to pmpcfg in Smepmp MML mode
With Machine Mode Lockdown (mseccfg.MML) set and RLB not set, checks on pmpcfg
writes would match the wrong cases of Smepmp truth table.
The existing code allows writes for the following cases:
- L=1, X=0: cases 8, 10, 12, 14
- L=0, RWX!=WX: cases 0-2, 4-6
This leaves cases 3, 7, 9, 11, 13, 15 for which writes are ignored.
>From the Smepmp specification: "Adding a rule with executable privileges that
either is M-mode-only or a locked Shared-Region is not possible (...)" This
description matches cases 9-11, 13 of the truth table.
This commit implements an explicit check for these cases by using
pmp_get_epmp_operation to convert between PMP configuration and Smepmp truth
table cases.
Signed-off-by: Loïc Lefort <l...@rivosinc.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: LIU Zhiwei <zhiwei_...@linux.alibaba.com>
Message-ID: <20250313193011.720075-4-l...@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 19cf1a7d9e59b71bf8d6571d4747e5c82667c3d1)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: b76d4a5657129785c037a8689804caedbb045333
https://github.com/qemu/qemu/commit/b76d4a5657129785c037a8689804caedbb045333
Author: Paolo Bonzini <pbonz...@redhat.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M hw/riscv/riscv_hart.c
Log Message:
-----------
hw/riscv: Fix type conflict of GLib function pointers
qtest_set_command_cb passed to g_once should match GThreadFunc,
which it does not. But using g_once is actually unnecessary,
because the function is called by riscv_harts_realize() under
the Big QEMU Lock.
Reported-by: Kohei Tokunaga <ktokunaga.m...@gmail.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Reviewed-by: Kohei Tokunaga <ktokunaga.m...@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Message-ID: <20250410161722.595634-1-pbonz...@redhat.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 56cde18d048e1e1f889e31f7553e1f39f03eeec5)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 156321d18ebf86a21c487f995ce077d7c602d456
https://github.com/qemu/qemu/commit/156321d18ebf86a21c487f995ce077d7c602d456
Author: Ziqiao Kong <ziqiaok...@gmail.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/cpu_helper.c
Log Message:
-----------
target/riscv: fix endless translation loop on big endian systems
On big endian systems, pte and updated_pte hold big endian host data
while pte_pa points to little endian target data. This means the branch
at cpu_helper.c:1669 will be always satisfied and restart translation,
causing an endless translation loop.
The correctness of this patch can be deduced by:
old_pte will hold value either from cpu_to_le32/64(pte) or
cpu_to_le32/64(updated_pte), both of wich is litte endian. After that,
an in-place conversion by le32/64_to_cpu(old_pte) ensures that old_pte
now is in native endian, same with pte. Therefore, the endianness of the
both side of if (old_pte != pte) is correct.
Signed-off-by: Ziqiao Kong <ziqiaok...@gmail.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-ID: <20250415080254.3667878-2-ziqiaok...@gmail.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit ad63158bdb33dab5704ea1cf740d2ea0387175df)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 70dbbc28118a66f40709f197eeea8d6cee380179
https://github.com/qemu/qemu/commit/70dbbc28118a66f40709f197eeea8d6cee380179
Author: Icenowy Zheng <u...@icenowy.me>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M common-user/host/riscv/safe-syscall.inc.S
Log Message:
-----------
common-user/host/riscv: use tail pseudoinstruction for calling tail
The j pseudoinstruction maps to a JAL instruction, which can only handle
a jump to somewhere with a signed 20-bit destination. In case of static
linking and LTO'ing this easily leads to "relocation truncated to fit"
error.
Switch to use tail pseudoinstruction, which is the standard way to
tail-call a function in medium code model (emits AUIPC+JALR).
Signed-off-by: Icenowy Zheng <u...@icenowy.me>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-ID: <20250417072206.364008-1-...@icenowy.me>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 22b448ccc6611a59d4aa54419f4d88c1f343cb35)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 336fed6bb87565b6b56dfc6de3a673b8def85fb7
https://github.com/qemu/qemu/commit/336fed6bb87565b6b56dfc6de3a673b8def85fb7
Author: Anton Blanchard <ant...@tenstorrent.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvv.c.inc
Log Message:
-----------
target/riscv: rvv: Source vector registers cannot overlap mask register
Add the relevant ISA paragraphs explaining why source (and destination)
registers cannot overlap the mask register.
Signed-off-by: Anton Blanchard <ant...@tenstorrent.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Max Chou <max.c...@sifive.com>
Signed-off-by: Max Chou <max.c...@sifive.com>
Message-ID: <20250408103938.3623486-2-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 3e8d1e4a628bb234c0b5d1ccd510900047181dbd)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 027ea4a2f5fc559499a95efa8bdccc6e81f91536
https://github.com/qemu/qemu/commit/027ea4a2f5fc559499a95efa8bdccc6e81f91536
Author: Anton Blanchard <ant...@tenstorrent.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvv.c.inc
Log Message:
-----------
target/riscv: rvv: Add CHECK arg to GEN_OPFVF_WIDEN_TRANS
Signed-off-by: Anton Blanchard <ant...@tenstorrent.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Max Chou <max.c...@sifive.com>
Signed-off-by: Max Chou <max.c...@sifive.com>
Message-ID: <20250408103938.3623486-3-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit b0450a101d6c88789d0e8df2bcbef61bc7cd159a)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: bc502d4de975aa6faf4dc2f026b73e4a159ff30d
https://github.com/qemu/qemu/commit/bc502d4de975aa6faf4dc2f026b73e4a159ff30d
Author: Max Chou <max.c...@sifive.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvv.c.inc
Log Message:
-----------
target/riscv: rvv: Apply vext_check_input_eew to vrgather instructions to
check mismatched input EEWs encoding constraint
According to the v spec, a vector register cannot be used to provide source
operands with more than one EEW for a single instruction.
The vs1 EEW of vrgatherei16.vv is 16.
Co-authored-by: Anton Blanchard <ant...@tenstorrent.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Signed-off-by: Max Chou <max.c...@sifive.com>
Message-ID: <20250408103938.3623486-4-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 629c2a8dd7506e1cb9b6b7127604641632ac453f)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 0bfd8dd14b1f8211a010f48a15dda90876a0e82a
https://github.com/qemu/qemu/commit/0bfd8dd14b1f8211a010f48a15dda90876a0e82a
Author: Max Chou <max.c...@sifive.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvv.c.inc
Log Message:
-----------
target/riscv: rvv: Apply vext_check_input_eew to
OPIVI/OPIVX/OPFVF(vext_check_ss) instructions
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard <ant...@tenstorrent.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Signed-off-by: Max Chou <max.c...@sifive.com>
Message-ID: <20250408103938.3623486-5-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit fbeaf35838768086b435833cb4dc5182c73ec2bc)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 2a0eb3c2a104dec5826b3f763814d78a14274306
https://github.com/qemu/qemu/commit/2a0eb3c2a104dec5826b3f763814d78a14274306
Author: Max Chou <max.c...@sifive.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvv.c.inc
Log Message:
-----------
target/riscv: rvv: Apply vext_check_input_eew to OPIVV/OPFVV(vext_check_sss)
instructions
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard <ant...@tenstorrent.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Signed-off-by: Max Chou <max.c...@sifive.com>
Message-ID: <20250408103938.3623486-6-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit fda68acb7761af40df78db18e44ca1ff20195fe0)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 19d107468e394f9394a69101e2bd01f8b8f6448a
https://github.com/qemu/qemu/commit/19d107468e394f9394a69101e2bd01f8b8f6448a
Author: Max Chou <max.c...@sifive.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvv.c.inc
Log Message:
-----------
target/riscv: rvv: Apply vext_check_input_eew to vector slide
instructions(OPIVI/OPIVX)
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard <ant...@tenstorrent.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Signed-off-by: Max Chou <max.c...@sifive.com>
Message-ID: <20250408103938.3623486-7-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit b5480a693e3e657108746721ffe434b3bb6e7a72)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: faaeaa955c6209814a0e912c75cb80e085c2a321
https://github.com/qemu/qemu/commit/faaeaa955c6209814a0e912c75cb80e085c2a321
Author: Max Chou <max.c...@sifive.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvv.c.inc
Log Message:
-----------
target/riscv: rvv: Apply vext_check_input_eew to vector integer extension
instructions(OPMVV)
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard <ant...@tenstorrent.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Signed-off-by: Max Chou <max.c...@sifive.com>
Message-ID: <20250408103938.3623486-8-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 411eefd56a3921ddbfdbadca596e1a8593ce834c)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: be6e117a8363734bb65f80299cbdcbe602b71f8e
https://github.com/qemu/qemu/commit/be6e117a8363734bb65f80299cbdcbe602b71f8e
Author: Max Chou <max.c...@sifive.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvbf16.c.inc
M target/riscv/insn_trans/trans_rvv.c.inc
Log Message:
-----------
target/riscv: rvv: Apply vext_check_input_eew to vector narrow/widen
instructions
Handle the overlap of source registers with different EEWs.
The vd of vector widening mul-add instructions is one of the input
operands.
Co-authored-by: Anton Blanchard <ant...@tenstorrent.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Signed-off-by: Max Chou <max.c...@sifive.com>
Message-ID: <20250408103938.3623486-9-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 1f090a229f85e662394267680408bd31fd0a99c9)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 43a4f232fa8d8cab2c748112bba363e92da1ea37
https://github.com/qemu/qemu/commit/43a4f232fa8d8cab2c748112bba363e92da1ea37
Author: Max Chou <max.c...@sifive.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvv.c.inc
Log Message:
-----------
target/riscv: rvv: Apply vext_check_input_eew to vector indexed load/store
instructions
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard <ant...@tenstorrent.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Signed-off-by: Max Chou <max.c...@sifive.com>
Message-ID: <20250408103938.3623486-10-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit db21c3eb05504c4cedaad4f7b19e588361b02385)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 7b217815625381bca49067ac6d12c10556a76e11
https://github.com/qemu/qemu/commit/7b217815625381bca49067ac6d12c10556a76e11
Author: Max Chou <max.c...@sifive.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/insn32.decode
Log Message:
-----------
target/riscv: Fix the rvv reserved encoding of unmasked instructions
According to the v spec, the encodings of vcomoress.vm and vector
mask-register logical instructions with vm=0 are reserved.
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Signed-off-by: Max Chou <max.c...@sifive.com>
Message-ID: <20250408103938.3623486-11-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 8539a1244bf240d28917effb88a140eb58e45e88)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 95c0e6e06516ec4bd552a272663f493c6faf5151
https://github.com/qemu/qemu/commit/95c0e6e06516ec4bd552a272663f493c6faf5151
Author: Anton Blanchard <ant...@tenstorrent.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/vector_helper.c
Log Message:
-----------
target/riscv: Fix vslidedown with rvv_ta_all_1s
vslidedown always zeroes elements past vl, where it should use the
tail policy.
Signed-off-by: Anton Blanchard <ant...@tenstorrent.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250414213006.3509058-1-ant...@tenstorrent.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 2669b696e243b64f8ea1a6468dcee255de99f08d)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: c5008143177703ae6d4d5786d0587f0ee9f77b27
https://github.com/qemu/qemu/commit/c5008143177703ae6d4d5786d0587f0ee9f77b27
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: minor fixes/tweaks
Remove an unused 'KVMScratchCPU' pointer argument in
kvm_riscv_check_sbi_dbcn_support().
Put kvm_riscv_reset_regs_csr() after kvm_riscv_put_regs_csr(). This will
make a future patch diff easier to read, when changes in
kvm_riscv_reset_regs_csr() and kvm_riscv_get_regs_csr() will be made.
Fixes: a6b53378f5 ("target/riscv/kvm: implement SBI debug console (DBCN) calls")
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250429124421.223883-2-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 73f81da0a3628180409a0ae90ece19534bcdf09b)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 04b855727fac1841171c28672e269f980f45de70
https://github.com/qemu/qemu/commit/04b855727fac1841171c28672e269f980f45de70
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: fix leak in kvm_riscv_init_multiext_cfg()
'reglist' is being g-malloc'ed but never freed.
Reported-by: Andrew Jones <ajo...@ventanamicro.com>
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250429124421.223883-3-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 906af6de9462c5192547cca0beac2c134659a437)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: ea8eb871aba3a22ef4cbb2bacd3021e88da43434
https://github.com/qemu/qemu/commit/ea8eb871aba3a22ef4cbb2bacd3021e88da43434
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: turn u32/u64 reg functions into macros
This change is motivated by a future change w.r.t CSRs management. We
want to handle them the same way as KVM extensions, i.e. a static array
with KVMCPUConfig objs that will be read/write during init and so on.
But to do that properly we must be able to declare a static array that
hold KVM regs.
C does not allow to init static arrays and use functions as
initializers, e.g. we can't do:
.kvm_reg_id = kvm_riscv_reg_id_ulong(...)
When instantiating the array. We can do that with macros though, so our
goal is turn kvm_riscv_reg_ulong() in a macro. It is cleaner to turn
every other reg_id_*() function in macros, and ulong will end up using
the macros for u32 and u64, so we'll start with them.
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250429124421.223883-4-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit b6096103494506514d9bfa442f62fef36ffc8fba)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 90f7e23cb7baa6f836723c3ae44039e46fee2a6d
https://github.com/qemu/qemu/commit/90f7e23cb7baa6f836723c3ae44039e46fee2a6d
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: turn kvm_riscv_reg_id_ulong() into a macro
We need the reg_id_ulong() helper to be a macro to be able to create a
static array of KVMCPUConfig that will hold CSR information.
Despite the amount of changes all of them are tedious/trivial:
- replace instances of "kvm_riscv_reg_id_ulong" with
"KVM_RISCV_REG_ID_ULONG";
- RISCV_CORE_REG(), RISCV_CSR_REG(), RISCV_CONFIG_REG() and
RISCV_VECTOR_CSR_REG() only receives one 'name' arg. Remove unneeded
'env' variables when applicable.
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250429124421.223883-5-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit 11766e17616a5a4181d4a63f88adf67ac52c553b)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 6ba14ba513a4fef01f5e49e48230c1dffaa9115d
https://github.com/qemu/qemu/commit/6ba14ba513a4fef01f5e49e48230c1dffaa9115d
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/cpu.h
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: add kvm_csr_cfgs[]
At this moment we're not checking if the host has support for any
specific CSR before doing get/put regs. This will cause problems if the
host KVM doesn't support it (see [1] as an example).
We'll use the same approach done with the CPU extensions: read all known
KVM CSRs during init() to check for availability, then read/write them
if they are present. This will be made by either using get-reglist or by
directly reading the CSRs.
For now we'll just convert the CSRs to use a kvm_csr_cfg[] array,
reusing the same KVMCPUConfig abstraction we use for extensions, and use
the array in (get|put)_csr_regs() instead of manually listing them. A
lot of boilerplate will be added but at least we'll automate the get/put
procedure for CSRs, i.e. adding a new CSR in the future will be a matter
of adding it in kvm_csr_regs[] and everything else will be taken care
of.
Despite all the code changes no behavioral change is made.
[1]
https://lore.kernel.org/qemu-riscv/CABJz62OfUDHYkQ0T3rGHStQprf1c7_E0qBLbLKhfv=+jb0s...@mail.gmail.com/
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>
Acked-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250429124421.223883-6-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit d3b6f1742c36e3a3c1e74cb60646ee98a4e39ea3)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 9ac56fb385e94c6382928d604034861e189cfb0c
https://github.com/qemu/qemu/commit/9ac56fb385e94c6382928d604034861e189cfb0c
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-05-20 (Tue, 20 May 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: do not read unavailable CSRs
[1] reports that commit 4db19d5b21 broke a KVM guest running kernel 6.6.
This happens because the kernel does not know 'senvcfg', making it
unable to boot because QEMU is reading/wriiting it without any checks.
After converting the CSRs to do "automated" get/put reg procedures in
the previous patch we can now scan for availability. Two functions are
created:
- kvm_riscv_read_csr_cfg_legacy() will check if the CSR exists by brute
forcing KVM_GET_ONE_REG in each one of them, interpreting an EINVAL
return as indication that the CSR isn't available. This will be use in
absence of KVM_GET_REG_LIST;
- kvm_riscv_read_csr_cfg() will use the existing result of get_reg_list
to check if the CSRs ids are present.
kvm_riscv_init_multiext_cfg() is now kvm_riscv_init_cfg() to reflect that
the function is also dealing with CSRs.
[1]
https://lore.kernel.org/qemu-riscv/CABJz62OfUDHYkQ0T3rGHStQprf1c7_E0qBLbLKhfv=+jb0s...@mail.gmail.com/
Fixes: 4db19d5b21 ("target/riscv/kvm: add missing KVM CSRs")
Reported-by: Andrea Bolognani <abolo...@redhat.com>
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Andrew Jones <ajo...@ventanamicro.com>
Acked-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250429124421.223883-7-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
Cc: qemu-sta...@nongnu.org
(cherry picked from commit f396c217a53d9b7960dd002fbb07cfe1d46b27aa)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 2f6357ca962568d2127ee97630997c31543bf0c0
https://github.com/qemu/qemu/commit/2f6357ca962568d2127ee97630997c31543bf0c0
Author: Xiaoyao Li <xiaoyao...@intel.com>
Date: 2025-05-22 (Thu, 22 May 2025)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
i386/tcg: Make CPUID_HT and CPUID_EXT3_CMP_LEG supported
Since commit c6bd2dd63420 ("i386/cpu: Set up CPUID_HT in
x86_cpu_expand_features() instead of cpu_x86_cpuid()") and
commit 99a637a86f55 ("i386/cpu: Set and track CPUID_EXT3_CMP_LEG in
env->features[FEAT_8000_0001_ECX]"), it gets warnings when booting the
VM with vcpus >= 2 and with tcg:
qemu-system-x86_64: warning: TCG doesn't support requested feature:
CPUID.01H:EDX.ht [bit 28]
qemu-system-x86_64: warning: TCG doesn't support requested feature:
CPUID.80000001H:ECX.cmp-legacy [bit 1]
This is because, after the two commits, CPUID_HT and CPUID_EXT3_CMP_LEG
are set in env->features[] when vcpus >=2 (in x86_cpu_expand_features())
later in x86_cpu_filter_features() it will check against the TCG supported
bits. However, current TCG doesn't mark the two bits as supported, hence
the warnings.
Fix it by adding the two bits to the supported bits of TCG since multiple
vcpus are supported by TCG.
Fixes: c6bd2dd63420 ("i386/cpu: Set up CPUID_HT in x86_cpu_expand_features()
instead of cpu_x86_cpuid()")
Fixes: 99a637a86f55 ("i386/cpu: Set and track CPUID_EXT3_CMP_LEG in
env->features[FEAT_8000_0001_ECX]")
Reported-by: Ewan Hai <ewanhai...@zhaoxin.com>
Signed-off-by: Xiaoyao Li <xiaoyao...@intel.com>
Link: https://lore.kernel.org/r/20250514031652.838763-2-xiaoyao...@intel.com
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
(cherry picked from commit 5979f50fa9fdbb3fb49e2b498f84faa7503c8ed1)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 3e59fccb03eee912867b2d58dc885d48f44cec78
https://github.com/qemu/qemu/commit/3e59fccb03eee912867b2d58dc885d48f44cec78
Author: Xiaoyao Li <xiaoyao...@intel.com>
Date: 2025-05-22 (Thu, 22 May 2025)
Changed paths:
M target/i386/hvf/x86_cpuid.c
Log Message:
-----------
i386/hvf: Make CPUID_HT supported
Since Commit c6bd2dd63420 ("i386/cpu: Set up CPUID_HT in
x86_cpu_expand_features() instead of cpu_x86_cpuid()"), CPUID_HT will be
set in env->features[] in x86_cpu_expand_features() when vcpus >= 2.
Later in x86_cpu_filter_features() it will check against the HVF
supported bits. It will trigger the warning like
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.01H:EDX.ht [bit 28]
Add CPUID_HT to HVF supported CPUID bits to fix it.
Signed-off-by: Xiaoyao Li <xiaoyao...@intel.com>
Link: https://lore.kernel.org/r/20250514031652.838763-3-xiaoyao...@intel.com
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
(cherry picked from commit 7a48612306768833f8cc87418a5a53e712f26ac1)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: cdf3fb061719f32d46ee620fadea37b8e55771d0
https://github.com/qemu/qemu/commit/cdf3fb061719f32d46ee620fadea37b8e55771d0
Author: Rakesh Jeyasingh <rakeshjb...@gmail.com>
Date: 2025-05-22 (Thu, 22 May 2025)
Changed paths:
M hw/pci-host/gt64120.c
Log Message:
-----------
hw/pci-host/gt64120: Fix endianness handling
The GT-64120 PCI controller requires special handling where:
1. Host bridge(bus 0 ,device 0) must never be byte-swapped
2. Other devices follow MByteSwap bit in GT_PCI0_CMD
The previous implementation incorrectly swapped all accesses, breaking
host bridge detection (lspci -d 11ab:4620).
Changes made:
1. Removed gt64120_update_pci_cfgdata_mapping() and moved data_mem
initialization
to gt64120_realize() for cleaner setup
2. Implemented custom read/write handlers that:
- Preserve host bridge accesses (extract32(config_reg,11,13)==0)
- apply swapping only for non-bridge devices in big-endian mode
Fixes: 145e2198 ("hw/mips/gt64xxx_pci: Endian-swap using PCI_HOST_BRIDGE
MemoryRegionOps")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2826
Signed-off-by: Rakesh Jeyasingh <rakeshjb...@gmail.com>
Tested-by: Thomas Huth <th...@redhat.com>
Link: https://lore.kernel.org/r/20250429170354.150581-2-rakeshjb...@gmail.com
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
(cherry picked from commit e5894fd6f411c113e2b5f62811e96eeb5b084381)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: ef1655962fe022b93e3f9d0aa4741e0e9e066a78
https://github.com/qemu/qemu/commit/ef1655962fe022b93e3f9d0aa4741e0e9e066a78
Author: Rakesh Jeyasingh <rakeshjb...@gmail.com>
Date: 2025-05-22 (Thu, 22 May 2025)
Changed paths:
M hw/pci/pci_host.c
M include/hw/pci-host/dino.h
M include/hw/pci/pci_host.h
Log Message:
-----------
hw/pci-host: Remove unused pci_host_data_be_ops
pci_host_data_be_ops became unused after endianness fixes
Suggested-by: Paolo Bonzini <pbonz...@redhat.com>
Signed-off-by: Rakesh Jeyasingh <rakeshjb...@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Tested-by: Thomas Huth <th...@redhat.com>
Link: https://lore.kernel.org/r/20250429170354.150581-3-rakeshjb...@gmail.com
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
(cherry picked from commit 560375cff3ccedabf1fe5ca1bc7a31b13fdc68e5)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 5e8ef1da897e8e7b30f4e0102f2832a9a73518af
https://github.com/qemu/qemu/commit/5e8ef1da897e8e7b30f4e0102f2832a9a73518af
Author: Zhao Liu <zhao1....@intel.com>
Date: 2025-05-22 (Thu, 22 May 2025)
Changed paths:
M qapi/misc-target.json
Log Message:
-----------
qapi/misc-target: Fix the doc to distinguish query-sgx and
query-sgx-capabilities
There're 2 QMP commands: query-sgx and query-sgx-capabilities, but
their outputs are very similar and the documentation lacks clear
differentiation.
>From the codes, query-sgx is used to gather guest's SGX capabilities
(including SGX related CPUIDs and EPC sections' size, in SGXInfo), and
if guest doesn't have SGX, then QEMU will report the error message.
On the other hand, query-sgx-capabilities is used to gather host's SGX
capabilities (descripted by SGXInfo as well). And if host doesn't
support SGX, then QEMU will also report the error message.
Considering that SGXInfo is already documented and both these 2 commands
have enough error messages (for the exception case in their codes).
Therefore the QAPI documentation for these two commands only needs to
emphasize that one of them applies to the guest and the other to the
host.
Fix their documentation to reflect this difference.
Reported-by: Markus Armbruster <arm...@redhat.com>
Suggested-by: Paolo Bonzini <pbonz...@redhat.com>
Signed-off-by: Zhao Liu <zhao1....@intel.com>
Acked-by: Markus Armbruster <arm...@redhat.com>
Link: https://lore.kernel.org/r/20250513143131.2008078-3-zhao1....@intel.com
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
(cherry picked from commit 7f2131c35c1781ca41c62dc26fd93282e1351323)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 7484d61bdbc88923969d8d0e2e26e8ba0935f53a
https://github.com/qemu/qemu/commit/7484d61bdbc88923969d8d0e2e26e8ba0935f53a
Author: Maciej S. Szmigiero <maciej.szmigi...@oracle.com>
Date: 2025-05-22 (Thu, 22 May 2025)
Changed paths:
M migration/multifd.c
Log Message:
-----------
migration/multifd: Don't send device state packets with zerocopy flag
If zerocopy is enabled for multifd then QIO_CHANNEL_WRITE_FLAG_ZERO_COPY
flag is forced into all multifd channel write calls via p->write_flags
that was setup in multifd_nocomp_send_setup().
However, device state packets aren't compatible with zerocopy - the data
buffer isn't getting kept pinned until multifd channel flush.
Make sure to mask that QIO_CHANNEL_WRITE_FLAG_ZERO_COPY flag in a multifd
send thread if the data being sent is device state.
Fixes: 0525b91a0b99 ("migration/multifd: Device state transfer support - send
side")
Signed-off-by: Maciej S. Szmigiero <maciej.szmigi...@oracle.com>
Reviewed-by: Fabiano Rosas <faro...@suse.de>
Link:
https://lore.kernel.org/r/3bd5f48578e29f3a78f41b1e4fbea3d4b2d9b136.1747403393.git.maciej.szmigi...@oracle.com
Signed-off-by: Peter Xu <pet...@redhat.com>
(cherry picked from commit 6be7696129b302830a9cff7e30484e08c2d64b57)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 8a48520c1760ed6a0075bc1e3f5e0fb66d35f91c
https://github.com/qemu/qemu/commit/8a48520c1760ed6a0075bc1e3f5e0fb66d35f91c
Author: Peter Xu <pet...@redhat.com>
Date: 2025-05-22 (Thu, 22 May 2025)
Changed paths:
M migration/options.c
Log Message:
-----------
migration: Allow caps to be set when preempt or multifd cap enabled
With commit 82137e6c8c ("migration: enforce multifd and postcopy preempt to
be set before incoming"), and if postcopy preempt / multifd is enabled, one
cannot setup any capability because these checks would always fail.
(qemu) migrate_set_capability xbzrle off
Error: Postcopy preempt must be set before incoming starts
To fix it, check existing cap and only raise an error if the specific cap
changed.
Fixes: 82137e6c8c ("migration: enforce multifd and postcopy preempt to be set
before incoming")
Reviewed-by: Dr. David Alan Gilbert <d...@treblig.org>
Reviewed-by: Juraj Marcin <jmar...@redhat.com>
Signed-off-by: Peter Xu <pet...@redhat.com>
(cherry picked from commit 17bec9235bb0775cf8dec4103c167757ee8898f3)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 679450c92650294c77e80104760e93c7503bea78
https://github.com/qemu/qemu/commit/679450c92650294c77e80104760e93c7503bea78
Author: Helge Deller <del...@gmx.de>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M target/hppa/int_helper.c
Log Message:
-----------
target/hppa: Copy instruction code into fr1 on FPU assist fault
The hardware stores the instruction code in the lower bits of the FP
exception register #1 on FP assist traps.
This fixes the FP exception handler on Linux, as the Linux kernel uses
the value to decide on the correct signal which should be pushed into
userspace (see decode_fpu() in Linux kernel).
Signed-off-by: Helge Deller <del...@gmx.de>
(cherry picked from commit 923976dfe367b0bfed45ff660c369f3fe65604a7)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 5f119c69ff8867ecea92f78cbc7e288efb3a23a9
https://github.com/qemu/qemu/commit/5f119c69ff8867ecea92f78cbc7e288efb3a23a9
Author: Helge Deller <del...@gmx.de>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M linux-user/hppa/cpu_loop.c
Log Message:
-----------
linux-user/hppa: Send proper si_code on SIGFPE exception
Improve the linux-user emulation to send the correct si_code depending
on overflow (TARGET_FPE_FLTOVF), underflow (TARGET_FPE_FLTUND), ...
Note that the hardware stores the relevant flags in FP exception
register #1, which is actually the lower 32-bits of the 64-bit fr[0]
register in qemu.
Signed-off-by: Helge Deller <del...@gmx.de>
(cherry picked from commit b4b49cf39dba5f993ad925f204cb820aacfc8e45)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 6966e0ba1d4a9e6fe76f618c2c9c73900107fdc8
https://github.com/qemu/qemu/commit/6966e0ba1d4a9e6fe76f618c2c9c73900107fdc8
Author: Helge Deller <del...@gmx.de>
Date: 2025-05-25 (Sun, 25 May 2025)
Changed paths:
M target/hppa/fpu_helper.c
Log Message:
-----------
target/hppa: Fix FPE exceptions
Implement FP exception register #1 (lower 32-bits of 64-bit fr[0]).
A proper implementation is necessary to allow the Linux kernel in
system mode and the qemu linux-user to send proper si_code values
on SIGFPE signal.
Always set the T-bit on taken exception, and merge over- and underflow
in system mode to just set overflow bit to mimic the behaviour I tested
on a physical machine.
The test program below can be used to verify correct behaviour. Note
that behaviour on SIGFPE may vary on different platforms. The program
should always detect the correct signal, but it may or may not be able
to sucessfully continue afterwards.
#define _GNU_SOURCE
#include <signal.h>
#include <stdio.h>
#include <fenv.h>
#include <float.h>
static void fpe_func(int sig, siginfo_t *i, void *v) {
sigset_t set;
sigemptyset(&set);
sigaddset(&set, SIGFPE);
sigprocmask(SIG_UNBLOCK, &set, NULL);
printf("GOT signal %d with si_code %ld\n", sig, i->si_code);
}
int main(int argc, char *argv[]) {
struct sigaction action = {
.sa_sigaction = fpe_func,
.sa_flags = SA_RESTART|SA_SIGINFO };
sigaction(SIGFPE, &action, 0);
feenableexcept(FE_OVERFLOW | FE_UNDERFLOW);
double x = DBL_MIN;
return printf("%lf\n", argc > 1
? 1.7976931348623158E308*1.7976931348623158E308
: x / 10);
}
Signed-off-by: Helge Deller <del...@gmx.de>
(cherry picked from commit ebd394948de4e868cb8fc5b265a8a18f0935dce1)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Compare: https://github.com/qemu/qemu/compare/827be9d37aa8...6966e0ba1d4a
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
