Branch: refs/heads/staging-9.2
Home: https://github.com/qemu/qemu
Commit: 298340c152babd5cfad6532e09114539b69cbc6f
https://github.com/qemu/qemu/commit/298340c152babd5cfad6532e09114539b69cbc6f
Author: Alexander Graf <g...@amazon.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/virtio/virtio-nsm.c
Log Message:
-----------
hw/virtio/virtio-nsm: Respond with correct length
When we return a response packet from NSM, we need to indicate its
length according to the content of the response. Prior to this patch, we
returned the length of the source buffer, which may confuse guest code
that relies on the response size.
Fix it by returning the response payload size instead.
Fixes: bb154e3e0cc715 ("device/virtio-nsm: Support for Nitro Secure Module
device")
Reported-by: Vikrant Garg <vikrant1g...@gmail.com>
Signed-off-by: Alexander Graf <g...@amazon.com>
Message-Id: <20250213114541.67515-1-g...@amazon.com>
Reviewed-by: Dorjoy Chowdhury <dorjoychy...@gmail.com>
Fixes: bb154e3e0cc715 ("device/virtio-nsm: Support for Nitro Secure Module
device")<br>
Reported-by: Vikrant Garg <vikrant1g...@gmail.com>
Signed-off-by: Alexander Graf <g...@amazon.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Tested-by: Vikrant Garg <vikrant1g...@gmail.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
(cherry picked from commit 131fe64e63c88ec52c45a5946a478c0edeb31b78)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: dc203a598765b11bd667ae925c2953443f7a60ee
https://github.com/qemu/qemu/commit/dc203a598765b11bd667ae925c2953443f7a60ee
Author: Matias Ezequiel Vara Larsen <mvara...@redhat.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/virtio/vhost-user-snd.c
Log Message:
-----------
vhost-user-snd: correct the calculation of config_size
Use virtio_get_config_size() rather than sizeof(struct
virtio_snd_config) for the config_size in the vhost-user-snd frontend.
The frontend shall rely on device features for the size of the device
configuration space. The presence of `controls` in the config space
depends on VIRTIO_SND_F_CTLS according to the specification (v1.3):
`
5.14.4 Device Configuration Layout
...
controls
(driver-read-only) indicates a total number of all available control
elements if VIRTIO_SND_F_CTLS has been negotiated.
`
This fixes an issue introduced by commit ab0c7fb2 ("linux-headers:
update to current kvm/next") in which the optional field `controls` is
added to the virtio_snd_config structure. This breaks vhost-user-device
backends that do not implement the `controls` field.
Fixes: ab0c7fb22b ("linux-headers: update to current kvm/next")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2805
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Suggested-by: Stefano Garzarella <sgarz...@redhat.com>
Signed-off-by: Matias Ezequiel Vara Larsen <mvara...@redhat.com>
Message-Id: <20250217131255.829892-1-mvara...@redhat.com>
Cc: qemu-sta...@nongnu.org
Reviewed-by: Stefano Garzarella <sgarz...@redhat.com>
Reviewed-by: Dorinda Bassey <dbas...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
(cherry picked from commit e87b6efb11be9f5ff213461f5ecdbae47d9402b9)
(Mjt: context fix for 9.2)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 7f667fc7fe0ee5f6ac21ea3434d27b5b9582298b
https://github.com/qemu/qemu/commit/7f667fc7fe0ee5f6ac21ea3434d27b5b9582298b
Author: Bibo Mao <maob...@loongson.cn>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/loongarch/gdbstub.c
Log Message:
-----------
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-sta...@nongnu.org
Fixes: ca61e75071c6 ("target/loongarch: Add gdb support.")
Signed-off-by: Bibo Mao <maob...@loongson.cn>
Reviewed-by: Bibo Mao <maob...@loongson.cn>
(cherry picked from commit 7bd4eaa847fcdbc4505d9ab95dafa21791d8302a)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 44a7e0aaf7b59e90ae50c0a9149a0bfc990d7906
https://github.com/qemu/qemu/commit/44a7e0aaf7b59e90ae50c0a9149a0bfc990d7906
Author: Paolo Bonzini <pbonz...@redhat.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M system/physmem.c
Log Message:
-----------
physmem: replace assertion with error
It is possible to start QEMU with a confidential-guest-support object
even in TCG mode. While there is already a check in qemu_machine_creation_done:
if (machine->cgs && !machine->cgs->ready) {
error_setg(errp, "accelerator does not support confidential guest %s",
object_get_typename(OBJECT(machine->cgs)));
exit(1);
}
the creation of RAMBlocks happens earlier, in qemu_init_board(), if
the command line does not override the default memory backend with
-M memdev. Then the RAMBlock will try to use guest_memfd (because
machine_require_guest_memfd correctly returns true; at least correctly
according to the current implementation) and trigger the assertion
failure for kvm_enabled(). This happend with a command line as
simple as the following:
qemu-system-x86_64 -m 512 -nographic -object
sev-snp-guest,reduced-phys-bits=48,id=sev0 \
-M q35,kernel-irqchip=split,confidential-guest-support=sev0
qemu-system-x86_64: ../system/physmem.c:1871: ram_block_add: Assertion
`kvm_enabled()' failed.
Cc: Xiaoyao Li <xiaoyao...@intel.com>
Cc: qemu-sta...@nongnu.org
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Reviewed-by: Daniel P. Berrangé <berra...@redhat.com>
Reviewed-by: David Hildenbrand <da...@redhat.com>
Reviewed-by: Pankaj Gupta <pankaj.gu...@amd.com>
Reviewed-by: Xiaoyao Li <xiaoyao...@intel.com>
Link: https://lore.kernel.org/r/20250217120812.396522-1-pbonz...@redhat.com
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
(cherry picked from commit 6debfb2cb1795427d2dc6a741c7430a233c76695)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 576338eea1fcdae1d41edc6c1b092bca3e8efb62
https://github.com/qemu/qemu/commit/576338eea1fcdae1d41edc6c1b092bca3e8efb62
Author: Joelle van Dyne <j...@getutm.app>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/hvf/hvf.c
Log Message:
-----------
target/arm/hvf: Disable SME feature
macOS 15.2's Hypervisor.framework exposes SME feature on M4 Macs.
However, QEMU's hvf accelerator code does not properly support it
yet, causing QEMU to fail to start when hvf accelerator is used on
these systems, with the error message:
qemu-aarch64-softmmu: cannot disable sme4224
All SME vector lengths are disabled.
With SME enabled, at least one vector length must be enabled.
Ideally we would have SME support on these hosts; however, until that
point, we must suppress the SME feature in the ID registers, so that
users can at least run non-SME guests.
Cc: qemu-sta...@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2665
Signed-off-by: Joelle van Dyne <j...@getutm.app>
Message-id: 20250224165735.36792-...@getutm.app
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
[PMM: expanded commit message, comment]
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit fd207677a83087454b8afef31651985a1df0d2dd)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 16549930bb813c36ddf5b8902239b6920eea7687
https://github.com/qemu/qemu/commit/16549930bb813c36ddf5b8902239b6920eea7687
Author: Joelle van Dyne <j...@getutm.app>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/hvf/hvf.c
Log Message:
-----------
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-sta...@nongnu.org
Signed-off-by: Joelle van Dyne <j...@getutm.app>
Message-id: 20250224184123.50780-...@getutm.app
[PMM: Drop an unnecessary check on 'len'; expand commit message]
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit 12c365315ab25d364cff24dfeea8d7ff1e752b9f)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 39408f6f145de8401675501d7ee1ff34268523d9
https://github.com/qemu/qemu/commit/39408f6f145de8401675501d7ee1ff34268523d9
Author: Max Chou <max.c...@sifive.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/riscv/vector_helper.c
Log Message:
-----------
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.c...@sifive.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Message-ID: <20250124101452.2519171-1-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit ffd455963f230c7dc04965609d6675da687a5a78)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 1fc0a58a982c821100a353edf2e5fca76effb1a2
https://github.com/qemu/qemu/commit/1fc0a58a982c821100a353edf2e5fca76effb1a2
Author: Max Chou <max.c...@sifive.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/riscv/cpu.c
Log Message:
-----------
target/riscv: rvv: Fix incorrect vlen comparison in prop_vlen_set
In prop_vlen_set function, there is an incorrect comparison between
vlen(bit) and vlenb(byte).
This will cause unexpected error when user applies the `vlen=1024` cpu
option with a vendor predefined cpu type that the default vlen is
1024(vlenb=128).
Fixes: 4f6d036ccc ("target/riscv/cpu.c: remove cpu->cfg.vlen")
Signed-off-by: Max Chou <max.c...@sifive.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Message-ID: <20250124090539.2506448-1-max.c...@sifive.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit bf3adf93f16730ca5aaa6c26cf969e64eeff6e7b)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 1408266d1c6aa0e197fede7781c090db0502f5ca
https://github.com/qemu/qemu/commit/1408266d1c6aa0e197fede7781c090db0502f5ca
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/riscv/debug.c
Log Message:
-----------
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 <dbarb...@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Message-ID: <20250121170626.1992570-2-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit 3fba76e61caa46329afc399b3ecaaba70c8b0a4e)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 426beec96a54f89fe4fcbf16adaac64810c32ffb
https://github.com/qemu/qemu/commit/426beec96a54f89fe4fcbf16adaac64810c32ffb
Author: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/riscv/cpu_helper.c
Log Message:
-----------
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().
[1] https://gitlab.com/qemu-project/qemu/-/issues/2627
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2627
Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-ID: <20250121170626.1992570-3-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit c86edc547692d812d1dcc04220c38310be2c00c3)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 56e190d73ebf7ebd421504a0dd1e16fbc8899404
https://github.com/qemu/qemu/commit/56e190d73ebf7ebd421504a0dd1e16fbc8899404
Author: Rodrigo Dias Correa <r...@drigo.nl>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/rtc/goldfish_rtc.c
Log Message:
-----------
goldfish_rtc: Fix tick_offset migration
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.fran...@wdc.com>
Message-ID: <20250114212150.228241-...@drigo.nl>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit 3521f9cadc29c7d68b73b325ddb46a7acebf6212)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 007ea6d6ed16cf9a548535afc272a9f04683ad38
https://github.com/qemu/qemu/commit/007ea6d6ed16cf9a548535afc272a9f04683ad38
Author: Denis Rastyogin <ger...@altlinux.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M block/qed.c
Log Message:
-----------
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 <ger...@altlinux.org>
Message-ID: <20250304083927.37681-1-ger...@altlinux.org>
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
(cherry picked from commit 2ad638a3d160923ef3dbf87c73944e6e44bdc724)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 80f66f3d225f10d547fb5925fe8234b9a16e70a1
https://github.com/qemu/qemu/commit/80f66f3d225f10d547fb5925fe8234b9a16e70a1
Author: Markus Armbruster <arm...@redhat.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M docs/about/build-platforms.rst
Log Message:
-----------
docs/about/build-platforms: Correct minimum supported Python version
Fixes: ca056f4499c2 (Python: Drop support for Python 3.7)
Signed-off-by: Markus Armbruster <arm...@redhat.com>
Message-ID: <20250227080757.3978333-2-arm...@redhat.com>
Reviewed-by: Daniel P. Berrangé <berra...@redhat.com>
(cherry picked from commit 87c8b4fc3c1c89ec52540bfb74f9b0518f247323)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 413f7ba6a863dd341a05efcd21ea06990bb43355
https://github.com/qemu/qemu/commit/413f7ba6a863dd341a05efcd21ea06990bb43355
Author: Patrick Venture <vent...@google.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/gpio/npcm7xx_gpio.c
Log Message:
-----------
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-sta...@nongnu.org
Fixes: 526dbbe0874 ("hw/gpio: Add GPIO model for Nuvoton NPCM7xx")
Signed-off-by: Patrick Venture <vent...@google.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Message-id: 20250226024603.493148-1-vent...@google.com
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit 3b2e22c0bbe2ce07123d93961d52f17644562cd7)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: cefb009762737577b65da9304a0e91ed9df213b0
https://github.com/qemu/qemu/commit/cefb009762737577b65da9304a0e91ed9df213b0
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Apply correct timer offset when calculating deadlines
When we are calculating timer deadlines, the correct definition of
whether or not to apply an offset to the physical count is described
in the Arm ARM DDI4087 rev L.a section D12.2.4.1. This is different
from when the offset should be applied for a direct read of the
counter sysreg.
We got this right for the EL1 physical timer and for the EL1 virtual
timer, but got all the rest wrong: they should be using a zero offset
always.
Factor the offset calculation out into a function that has a comment
documenting exactly which offset it is calculating and which gets the
HYP, SEC, and HYPVIRT cases right.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Message-id: 20250204125009.2281315-2-peter.mayd...@linaro.org
(cherry picked from commit db6c2192839ee0282d38f6f6666a87e0629fcd13)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 033367d0af198728ba50af169f2a84b7fe03102b
https://github.com/qemu/qemu/commit/033367d0af198728ba50af169f2a84b7fe03102b
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Don't apply CNTVOFF_EL2 for EL2_VIRT timer
The CNTVOFF_EL2 offset register should only be applied for accessses
to CNTVCT_EL0 and for the EL1 virtual timer (CNTV_*). We were
incorrectly applying it for the EL2 virtual timer (CNTHV_*).
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Message-id: 20250204125009.2281315-3-peter.mayd...@linaro.org
(cherry picked from commit 5709038aa8b4d58b8c201ed53c327074173a35c6)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: b692aea8039700d784d42344bea1b2dfd7185445
https://github.com/qemu/qemu/commit/b692aea8039700d784d42344bea1b2dfd7185445
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Make CNTPS_* UNDEF from Secure EL1 when Secure EL2 is enabled
When we added Secure EL2 support, we missed that this needs an update
to the access code for the EL3 physical timer registers. These are
supposed to UNDEF from Secure EL1 when Secure EL2 is enabled.
(Note for stable backporting: for backports to branches where
CP_ACCESS_UNDEFINED is not defined, the old name to use instead
is CP_ACCESS_TRAP_UNCATEGORIZED.)
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Message-id: 20250204125009.2281315-4-peter.mayd...@linaro.org
(cherry picked from commit bdd641541fbef0a27bf9f60e7eba6f8a31d4706c)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 69b4ed0259f89925640556751e7018f3acd715f1
https://github.com/qemu/qemu/commit/69b4ed0259f89925640556751e7018f3acd715f1
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Always apply CNTVOFF_EL2 for CNTV_TVAL_EL02 accesses
Currently we handle CNTV_TVAL_EL02 by calling gt_tval_read() for the
EL1 virt timer. This is almost correct, but the underlying
CNTV_TVAL_EL0 register behaves slightly differently. CNTV_TVAL_EL02
always applies the CNTVOFF_EL2 offset; CNTV_TVAL_EL0 doesn't do so if
we're at EL2 and HCR_EL2.E2H is 1.
We were getting this wrong, because we ended up in
gt_virt_cnt_offset() and did the E2H check.
Factor out the tval read/write calculation from the selection of the
offset, so that we can special case gt_virt_tval_read() and
gt_virt_tval_write() to unconditionally pass CNTVOFF_EL2.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Message-id: 20250204125009.2281315-5-peter.mayd...@linaro.org
(cherry picked from commit 4aecd4b442d7abb4355896d878ffc9b028625b01)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 739dabb1ad26c750fdf6df469e442ab8591c3090
https://github.com/qemu/qemu/commit/739dabb1ad26c750fdf6df469e442ab8591c3090
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/helper.c
M target/arm/internals.h
M target/arm/tcg/op_helper.c
Log Message:
-----------
target/arm: Refactor handling of timer offset for direct register accesses
When reading or writing the timer registers, sometimes we need to
apply one of the timer offsets. Specifically, this happens for
direct reads of the counter registers CNTPCT_EL0 and CNTVCT_EL0 (and
their self-synchronized variants CNTVCTSS_EL0 and CNTPCTSS_EL0). It
also applies for direct reads and writes of the CNT*_TVAL_EL*
registers that provide the 32-bit downcounting view of each timer.
We currently do this with duplicated code in gt_tval_read() and
gt_tval_write() and a special-case in gt_virt_cnt_read() and
gt_cnt_read(). Refactor this so that we handle it all in a single
function gt_direct_access_timer_offset(), to parallel how we handle
the offset for indirect accesses.
The call in the WFIT helper previously to gt_virt_cnt_offset() is
now to gt_direct_access_timer_offset(); this is the correct
behaviour, but it's not immediately obvious that it shouldn't be
considered an indirect access, so we add an explanatory comment.
This commit should make no behavioural changes.
(Cc to stable because the following bugfix commit will
depend on this one.)
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Message-id: 20250204125009.2281315-6-peter.mayd...@linaro.org
(cherry picked from commit 02c648a0a103a1a7b2c077ec5a81da9907f45544)
(Mjt: context fix in target/arm/internals.h)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: ab37d6bd8917da6130a22a11c5d6e32b31f7d5d4
https://github.com/qemu/qemu/commit/ab37d6bd8917da6130a22a11c5d6e32b31f7d5d4
Author: Alex Bennée <alex.ben...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M include/hw/arm/bsa.h
M target/arm/cpu.c
M target/arm/cpu.h
M target/arm/gtimer.h
M target/arm/helper.c
Log Message:
-----------
target/arm: Implement SEL2 physical and virtual timers
When FEAT_SEL2 was implemented the SEL2 timers were missed. This
shows up when building the latest Hafnium with SPMC_AT_EL=2. The
actual implementation utilises the same logic as the rest of the
timers so all we need to do is:
- define the timers and their access functions
- conditionally add the correct system registers
- create a new accessfn as the rules are subtly different to the
existing secure timer
Fixes: e9152ee91c (target/arm: add ARMv8.4-SEL2 system registers)
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Message-id: 20250204125009.2281315-7-peter.mayd...@linaro.org
Cc: qemu-sta...@nongnu.org
Cc: Andrei Homescu <ahome...@google.com>
Cc: Arve Hjønnevåg <a...@google.com>
Cc: Rémi Denis-Courmont <remi.denis.courm...@huawei.com>
[PMM: CP_ACCESS_TRAP_UNCATEGORIZED -> CP_ACCESS_UNDEFINED;
offset logic now in gt_{indirect,direct}_access_timer_offset() ]
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit f9f99d7ca522339c1de2292f132bb8ddc3471c39)
(Mjt: CP_ACCESS_UNDEFINED -> CP_ACCESS_TRAP_UNCATEGORIZED)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 472a4207618c561df0e8ad0d40a87d48afa6655c
https://github.com/qemu/qemu/commit/472a4207618c561df0e8ad0d40a87d48afa6655c
Author: Alex Bennée <alex.ben...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
hw/arm: enable secure EL2 timers for virt machine
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Message-id: 20250204125009.2281315-9-peter.mayd...@linaro.org
Cc: qemu-sta...@nongnu.org
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit 5dcaea8bcd82972add29eef350547f922fb4caa2)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 3c84a63e2c9e9f152414981ed87376380aeef8f0
https://github.com/qemu/qemu/commit/3c84a63e2c9e9f152414981ed87376380aeef8f0
Author: Alex Bennée <alex.ben...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/arm/sbsa-ref.c
Log Message:
-----------
hw/arm: enable secure EL2 timers for sbsa machine
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Message-id: 20250204125009.2281315-10-peter.mayd...@linaro.org
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit 9a9d9e82093efa22e3e2bdaac0f24c823f8786f7)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: f72e697f2401ade6163e0b8bc367d0b13fe5f626
https://github.com/qemu/qemu/commit/f72e697f2401ade6163e0b8bc367d0b13fe5f626
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/tcg/translate.c
Log Message:
-----------
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-sta...@nongnu.org
Reported-by: Stu Grossman <stu.gross...@gmail.com>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-id: 20250227142746.1698904-2-peter.mayd...@linaro.org
(cherry picked from commit cde3247651dc998da5dc1005148302a90d72f21f)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: ec36d522ce00c2851db9c5637f8c5600110ed22d
https://github.com/qemu/qemu/commit/ec36d522ce00c2851db9c5637f8c5600110ed22d
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/tcg/translate.c
Log Message:
-----------
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-sta...@nongnu.org
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-id: 20250227142746.1698904-3-peter.mayd...@linaro.org
(cherry picked from commit ee786ca115045a2b7e86ac3073b0761cb99e0d49)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 5cf3b48094e98c241fb86c5ea27c4c2e6f79a072
https://github.com/qemu/qemu/commit/5cf3b48094e98c241fb86c5ea27c4c2e6f79a072
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M util/qemu-timer.c
Log Message:
-----------
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-sta...@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2703
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Tested-by: Alex Bennée <alex.ben...@linaro.org>
Message-id: 20250210135804.3526943-1-peter.mayd...@linaro.org
(cherry picked from commit 02ae315467cee589d02dfb89e13a2a6a8de09fc5)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 9e00d74a9a6b16e2486b9ab55e1df09f62edf009
https://github.com/qemu/qemu/commit/9e00d74a9a6b16e2486b9ab55e1df09f62edf009
Author: Eugenio Pérez <epere...@redhat.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M net/net.c
Log Message:
-----------
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....@oracle.com>
Acked-by: Jason Wang <jasow...@redhat.com>
Signed-off-by: Eugenio Pérez <epere...@redhat.com>
Signed-off-by: Jason Wang <jasow...@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 <m...@tls.msk.ru>
Commit: aeade0a2510672cc8a92ab46ad2df395a533ce61
https://github.com/qemu/qemu/commit/aeade0a2510672cc8a92ab46ad2df395a533ce61
Author: Eugenio Pérez <epere...@redhat.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M net/net.c
M net/vhost-vdpa.c
Log Message:
-----------
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 <leiy...@redhat.com>
Signed-off-by: Eugenio Pérez <epere...@redhat.com>
Signed-off-by: Jonah Palmer <jonah.pal...@oracle.com>
Signed-off-by: Jason Wang <jasow...@redhat.com>
(cherry picked from commit e7891c575fb294618b172119a91c892b8f4384a2)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: c96b8c0e39330e15ad020d332f1fbf458a3ab047
https://github.com/qemu/qemu/commit/c96b8c0e39330e15ad020d332f1fbf458a3ab047
Author: Stefano Stabellini <stefano.stabell...@amd.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/xen/xen-mapcache.c
Log Message:
-----------
xen: No need to flush the mapcache for grants
On IOREQ_TYPE_INVALIDATE we need to invalidate the mapcache for regular
mappings. Since recently we started reusing the mapcache also to keep
track of grants mappings. However, there is no need to remove grant
mappings on IOREQ_TYPE_INVALIDATE requests, we shouldn't do that. So
remove the function call.
Fixes: 9ecdd4bf08 (xen: mapcache: Add support for grant mappings)
Cc: qemu-sta...@nongnu.org
Reported-by: Olaf Hering <o...@aepfle.de>
Reviewed-by: Edgar E. Iglesias <edgar.igles...@amd.com>
Signed-off-by: Stefano Stabellini <stefano.stabell...@amd.com>
Signed-off-by: Edgar E. Iglesias <edgar.igles...@amd.com>
Reviewed-by: Anthony PERARD <anthony.per...@vates.tech>
Message-Id: <20250206194915.3357743-2-edgar.igles...@gmail.com>
Signed-off-by: Anthony PERARD <anthony.per...@vates.tech>
(cherry picked from commit 68adcc784bad13421ac7211c316a751fb99fcb94)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: f3da6934cdbb1599918ae31c33f957c5cd9070dd
https://github.com/qemu/qemu/commit/f3da6934cdbb1599918ae31c33f957c5cd9070dd
Author: Nicholas Piggin <npig...@gmail.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/ppc/pnv_occ.c
Log Message:
-----------
ppc/pnv/occ: Fix common area sensor offsets
The commit to fix the OCC common area sensor mappings didn't update the
register offsets to match.
Before this change, skiboot reports:
[ 0.347100086,3] OCC: Chip 0 sensor data invalid
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 <npig...@gmail.com>
(cherry picked from commit 29c041ca7f8d6910c894788482efff892789dcd2)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: e9f6c32339038787a3535969456bab021ec31200
https://github.com/qemu/qemu/commit/e9f6c32339038787a3535969456bab021ec31200
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
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-sta...@nongnu.org
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Message-ID: <20250228174802.1945417-2-peter.mayd...@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
(cherry picked from commit 2fa3a5b9469615d06091cf473d172794148e1248)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: e8fd97fc1e5062798cbb586eaacd21c7894a7890
https://github.com/qemu/qemu/commit/e8fd97fc1e5062798cbb586eaacd21c7894a7890
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
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-sta...@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2742
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Message-ID: <20250228174802.1945417-3-peter.mayd...@linaro.org>
[PMD: Update smc91c111_do_tx() as len > MAX_PACKET_SIZE]
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
(cherry picked from commit aad6f264add3f2be72acb660816588fe09110069)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 6620335418f31a2eeeafab88a885b17efaa42fcc
https://github.com/qemu/qemu/commit/6620335418f31a2eeeafab88a885b17efaa42fcc
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
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-sta...@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2758
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Message-ID: <20250228191652.1957208-1-peter.mayd...@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
(cherry picked from commit 700d3d6dd41de3bd3f1153e3cfe00b93f99b1441)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 704eaf82193d133f75216c5739aef387c40dedcc
https://github.com/qemu/qemu/commit/704eaf82193d133f75216c5739aef387c40dedcc
Author: Philippe Mathieu-Daudé <phi...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M include/hw/xen/arch_hvm.h
Log Message:
-----------
hw/xen/hvm: Fix Aarch64 typo
There is no TARGET_ARM_64 definition. Luckily enough,
when TARGET_AARCH64 is defined, TARGET_ARM also is.
Fixes: 733766cd373 ("hw/arm: introduce xenpvh machine")
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouv...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-Id: <20250305153929.43687-2-phi...@linaro.org>
(cherry picked from commit 3a11b653a63fee0e43f4ab84b93f068b961d8fe7)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 490c737bc7eb2af72abe4b3d34a0e1e73edb6dca
https://github.com/qemu/qemu/commit/490c737bc7eb2af72abe4b3d34a0e1e73edb6dca
Author: Kevin Wolf <kw...@redhat.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M block/snapshot.c
Log Message:
-----------
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-sta...@nongnu.org
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2853
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2851
Reported-by: Denis Rastyogin <ger...@altlinux.org>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Message-ID: <20250310104858.28221-1-kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
(cherry picked from commit b75c5f9879166b86ed7c48b772fdcd0693e8a9a3)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 0c85c9746f7c1c6f378b52e19a2c75e3c1b290f5
https://github.com/qemu/qemu/commit/0c85c9746f7c1c6f378b52e19a2c75e3c1b290f5
Author: Greg Kurz <gr...@kaod.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M docs/devel/build-system.rst
M docs/devel/kconfig.rst
Log Message:
-----------
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 <gr...@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Message-ID: <20250306174113.427116-1-gr...@kaod.org>
Signed-off-by: Thomas Huth <th...@redhat.com>
(cherry picked from commit 48170c2d865a5937092b1384421b01cd38113042)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: cf8bd64d4fbc53dc7b85fb0d6925043f8e9b4164
https://github.com/qemu/qemu/commit/cf8bd64d4fbc53dc7b85fb0d6925043f8e9b4164
Author: Joe Komlodi <koml...@google.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M util/cacheflush.c
Log Message:
-----------
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-sta...@nongnu.org
Fixes: 664a79735e4deb1 ("util: Specialize flush_idcache_range for aarch64")
Signed-off-by: Joe Komlodi <koml...@google.com>
Message-id: 20250310203622.1827940-2-koml...@google.com
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit e6c38d2ab55d66c74ceade5699e22cabe9058d22)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: a75e415ca55df01d6d9e0e1698d8bc0c620dcc85
https://github.com/qemu/qemu/commit/a75e415ca55df01d6d9e0e1698d8bc0c620dcc85
Author: Richard Henderson <richard.hender...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/tcg/translate-a64.c
M target/arm/tcg/translate-a64.h
M target/arm/tcg/translate.h
Log Message:
-----------
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-sta...@nongnu.org
Fixes: 3d74825f4d6 ("target/arm: Add SME enablement checks")
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
Message-id: 20250307190415.982049-2-richard.hender...@linaro.org
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit 298a04998fa4a6dc977abe9234d98dfcdab98423)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: d08e538de8cfe9e3de4de60a6663996ce9048cc8
https://github.com/qemu/qemu/commit/d08e538de8cfe9e3de4de60a6663996ce9048cc8
Author: Richard Henderson <richard.hender...@linaro.org>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/arm/tcg/translate-a64.c
Log Message:
-----------
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-sta...@nongnu.org
Fixes: 285b1d5fcef ("target/arm: Handle SME in sve_access_check")
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
Message-id: 20250307190415.982049-3-richard.hender...@linaro.org
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
[PMM: move declaration of 'ret' to top of block]
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit cc7abc35dfa790ba6c20473c03745428c1c626b6)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: bb50cc9e75dc6078bbe90fca804f6d49b6eb4a2a
https://github.com/qemu/qemu/commit/bb50cc9e75dc6078bbe90fca804f6d49b6eb4a2a
Author: Guo Hongyu <guohongy...@mails.ucas.ac.cn>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M target/loongarch/tcg/insn_trans/trans_vec.c.inc
Log Message:
-----------
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 <guohongy...@mails.ucas.ac.cn>
Tested-by: Xianglai Li <lixiang...@loongson.cn>
Signed-off-by: Xianglai Li <lixiang...@loongson.cn>
Reviewed-by: Bibo Mao <maob...@loongson.cn>
Signed-off-by: Bibo Mao <maob...@loongson.cn>
(cherry picked from commit 02ce6cea71be4f6774351f5e658d50044c5b53b2)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2865
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: cda37a6bd719193020e749a88991fd995e619442
https://github.com/qemu/qemu/commit/cda37a6bd719193020e749a88991fd995e619442
Author: Konstantin Shkolnyy <k...@linux.ibm.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M hw/virtio/vhost-shadow-virtqueue.c
Log Message:
-----------
vdpa: Fix endian bugs in shadow virtqueue
VDPA didn't work on a big-endian machine due to missing/incorrect
CPU<->LE data format conversions.
Signed-off-by: Konstantin Shkolnyy <k...@linux.ibm.com>
Message-Id: <20250212164923.1971538-1-k...@linux.ibm.com>
Fixes: 10857ec0ad ("vhost: Add VhostShadowVirtqueue")
Acked-by: Eugenio Pérez <epere...@redhat.com>
Tested-by: Lei Yang <leiy...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
(cherry picked from commit 50e9754149066dc91f58405d3378b589098cb408)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: bcf9282f53f27da6b45d4f14c6e6f2daaadf7f23
https://github.com/qemu/qemu/commit/bcf9282f53f27da6b45d4f14c6e6f2daaadf7f23
Author: Konstantin Shkolnyy <k...@linux.ibm.com>
Date: 2025-03-18 (Tue, 18 Mar 2025)
Changed paths:
M net/vhost-vdpa.c
Log Message:
-----------
vdpa: Allow vDPA to work on big-endian machine
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 <m...@redhat.com>
Acked-by: Eugenio Pérez <epere...@redhat.com>
Signed-off-by: Konstantin Shkolnyy <k...@linux.ibm.com>
Signed-off-by: Jason Wang <jasow...@redhat.com>
(cherry picked from commit b027f55a994af885a7a498a40373a2dcc2d8b15e)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 9c3273c16ebd7cb766ebc6d1f3e76495ca52cecc
https://github.com/qemu/qemu/commit/9c3273c16ebd7cb766ebc6d1f3e76495ca52cecc
Author: Santiago Monserrat Campanello <santimons...@gmail.com>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M docs/about/emulation.rst
Log Message:
-----------
docs/about/emulation: Fix broken link
semihosting link to risc-v changed
Signed-off-by: Santiago Monserrat Campanello <santimons...@gmail.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2717
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Reviewed-by: Thomas Huth <th...@redhat.com>
Message-ID: <20250305102632.91376-1-santimons...@gmail.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit 672cb29d1e811180bf1aeefbcb0936ecd5bd3853)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 68a90134c0310a1e4e707906b766c893af3cec85
https://github.com/qemu/qemu/commit/68a90134c0310a1e4e707906b766c893af3cec85
Author: Deepak Gupta <de...@rivosinc.com>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M target/riscv/csr.c
Log Message:
-----------
target/riscv: fix access permission checks for CSR_SSP
Commit:8205bc1 ("target/riscv: introduce ssp and enabling controls for
zicfiss") introduced CSR_SSP but it mis-interpreted the spec on access
to CSR_SSP in M-mode. Gated to CSR_SSP is not gated via `xSSE`. But
rather rules clearly specified in section "22.2.1. Shadow Stack Pointer
(ssp) CSR access contr" in the priv spec.
Fixes: 8205bc127a83 ("target/riscv: introduce ssp and enabling controls
for zicfiss". Thanks to Adam Zabrocki for bringing this to attention.
Reported-by: Adam Zabrocki <azabro...@nvidia.com>
Signed-off-by: Deepak Gupta <de...@rivosinc.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250306064636.452396-1-de...@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit 86c78b280607fcff787866a03374047c65037a90)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 803a6864efd2513fa560e3e9a840b87d5b44dc3f
https://github.com/qemu/qemu/commit/803a6864efd2513fa560e3e9a840b87d5b44dc3f
Author: Deepak Gupta <de...@rivosinc.com>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvzicfiss.c.inc
Log Message:
-----------
target/riscv: fixes a bug against `ssamoswap` behavior in M-mode
Commit f06bfe3dc38c ("target/riscv: implement zicfiss instructions") adds
`ssamoswap` instruction. `ssamoswap` takes the code-point from existing
reserved encoding (and not a zimop like other shadow stack instructions).
If shadow stack is not enabled (via xenvcfg.SSE) and effective priv is
less than M then `ssamoswap` must result in an illegal instruction
exception. However if effective priv is M, then `ssamoswap` results in
store/AMO access fault. See Section "22.2.3. Shadow Stack Memory
Protection" of priv spec.
Fixes: f06bfe3dc38c ("target/riscv: implement zicfiss instructions")
Reported-by: Ved Shanbhogue <v...@rivosinc.com>
Signed-off-by: Deepak Gupta <de...@rivosinc.com>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250306064636.452396-2-de...@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit d2c5759c8dd4c00195d4ebecc7d009e41df6baef)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: d83b61f59c809d3447127f880dd65944180ce478
https://github.com/qemu/qemu/commit/d83b61f59c809d3447127f880dd65944180ce478
Author: Richard Henderson <richard.hender...@linaro.org>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user/riscv: Fix handling of cpu mask in riscv_hwprobe syscall
The third argument of the syscall contains the size of the
cpu mask in bytes, not bits. Nor is the size rounded up to
a multiple of sizeof(abi_ulong).
Cc: qemu-sta...@nongnu.org
Reported-by: Andreas Schwab <sch...@suse.de>
Fixes: 9e1c7d982d7 ("linux-user/riscv: Add syscall riscv_hwprobe")
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
Reviewed-by: Alistair Francis <alistair.fran...@wdc.com>
Message-ID: <20250308225902.1208237-3-richard.hender...@linaro.org>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit 1a010d22b7adecf0fb1c069e1e535af1aa51e9cf)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 73768dae4a50496a389c74e7b3b35138f37cc509
https://github.com/qemu/qemu/commit/73768dae4a50496a389c74e7b3b35138f37cc509
Author: Yao Zi <zi...@disroot.org>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M host/include/loongarch64/host/atomic128-ldst.h
M host/include/loongarch64/host/bufferiszero.c.inc
M host/include/loongarch64/host/load-extract-al16-al8.h.inc
Log Message:
-----------
host/include/loongarch64: Fix inline assembly compatibility with Clang
Clang on LoongArch only accepts fp register names in the dollar-prefixed
form, while GCC allows omitting the dollar. Change registers in ASM
clobbers to the dollar-prefixed form to make user emulators buildable
with Clang on loongarch64. No functional change invovled.
Cc: qemu-sta...@nongnu.org
Fixes: adc8467e697 ("host/include/loongarch64: Add atomic16 load and store")
Signed-off-by: Yao Zi <zi...@disroot.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Reviewed-by: Bibo Mao <maob...@loongson.cn>
Signed-off-by: Bibo Mao <maob...@loongson.cn>
(cherry picked from commit ca2737d6eca7fcc62ecb7a27246837b7c18830fc)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 64e16e388648948758c7dca533be541131a0e64b
https://github.com/qemu/qemu/commit/64e16e388648948758c7dca533be541131a0e64b
Author: Harsh Prateek Bora <hars...@linux.ibm.com>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
ppc/spapr: fix default cpu for pre-9.0 machines.
When POWER10 CPU was made as default, we missed keeping POWER9 as
default for older pseries releases (pre-9.0) at that time.
This caused breakge in default cpu evaluation for older pseries
machines and hence this fix.
Fixes: 51113013f3 ("ppc/spapr: change pseries machine default to POWER10 CPU")
Cc: qemu-sta...@nongnu.org
Signed-off-by: Harsh Prateek Bora <hars...@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berra...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Message-ID: <20250313094705.2361997-1-hars...@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npig...@gmail.com>
(cherry picked from commit 1490d0bcdfcb78b4503cae42353d3dd50f4e9d96)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 6726d4874bde0e0d7867912d7771231407d1e070
https://github.com/qemu/qemu/commit/6726d4874bde0e0d7867912d7771231407d1e070
Author: Nicholas Piggin <npig...@gmail.com>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M target/ppc/translate/vmx-impl.c.inc
M target/ppc/translate/vsx-impl.c.inc
Log Message:
-----------
target/ppc: Fix facility interrupt checks for VSX
Facility interrupt checks in general should come after the ISA version
check, because the facility interrupt and facility type themselves are
ISA dependent and should not appear on CPUs where the instruction does
not exist at all.
This resolves a QEMU crash booting NetBSD/macppc due to
qemu: fatal: Raised an exception without defined vector 94
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2741
Cc: Chinmay Rath <ra...@linux.ibm.com>
Cc: qemu-sta...@nongnu.org
Debugged-by: Richard Henderson <richard.hender...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Fixes: aa0f34ec3fc7 ("target/ppc: implement vrlq")
Fixes: 7419dc5b2b5b ("target/ppc: Move VSX vector storage access insns to
decodetree.")
Signed-off-by: Nicholas Piggin <npig...@gmail.com>
(cherry picked from commit 8defe9da08135d03e054f20cb8fea4389be96e18)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 3e7d8d2233a4b4782f03ca3f0609defdd5718894
https://github.com/qemu/qemu/commit/3e7d8d2233a4b4782f03ca3f0609defdd5718894
Author: Nicholas Piggin <npig...@gmail.com>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M target/ppc/cpu_init.c
Log Message:
-----------
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 <r...@sysgo.com>
Cc: qemu-sta...@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2768
Fixes: 0e3bf4890906 ("ppc: add DBCR based debugging")
Signed-off-by: Nicholas Piggin <npig...@gmail.com>
(cherry picked from commit 73c0c904fc99e2ceecbbded84ec76d40d3f2daae)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 154ed561b32e5930984f28676f3aa4b604669b64
https://github.com/qemu/qemu/commit/154ed561b32e5930984f28676f3aa4b604669b64
Author: Michael Tokarev <m...@tls.msk.ru>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M Makefile
Log Message:
-----------
Makefile: "make dist" generates a .xz, not .bz2
Fixes: 9bc9e9511944 (make-release: switch to .xz format by default)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
(cherry picked from commit 14fb6dbbc50f43057202c685c3aa017287cca37f)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 7f5f3e5acd630c8b11b2a91f6d8ba2a0c6ab5524
https://github.com/qemu/qemu/commit/7f5f3e5acd630c8b11b2a91f6d8ba2a0c6ab5524
Author: Chao Liu <lc00...@tecorigin.com>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M target/riscv/vcrypto_helper.c
M target/riscv/vector_helper.c
M target/riscv/vector_internals.c
M target/riscv/vector_internals.h
Log Message:
-----------
target/riscv: refactor VSTART_CHECK_EARLY_EXIT() to accept vl as a parameter
Some vector instructions are special, such as the vlm.v instruction,
where setting its vl actually sets evl = (vl + 7) >> 3. To improve
maintainability, we will uniformly use VSTART_CHECK_EARLY_EXIT() to
check for the condition vstart >= vl. This function will also handle
cases involving evl.
Fixes: df4252b2ec ("target/riscv/vector_helpers: do early exit when
vstart >= vl")
Signed-off-by: Chao Liu <lc00...@tecorigin.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Message-ID:
<f575979874e323a9e0da7796aa391c7d87e56f88.1741573286.git.lc00...@tecorigin.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit e83845316abcea9024eb5402a6c5eb8b092c79d5)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 3cdd1f45aa55d77c6a04a546013de911eec3cced
https://github.com/qemu/qemu/commit/3cdd1f45aa55d77c6a04a546013de911eec3cced
Author: Chao Liu <lc00...@tecorigin.com>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M target/riscv/vector_helper.c
Log Message:
-----------
target/riscv: fix handling of nop for vstart >= vl in some vector instruction
Recently, when I was writing a RISCV test, I found that when VL is set to 0, the
instruction should be nop, but when I tested it, I found that QEMU will treat
all elements as tail elements, and in the case of VTA=1, write all elements
to 1.
After troubleshooting, it was found that the vext_vx_rm_1 function was called in
the vext_vx_rm_2, and then the vext_set_elems_1s function was called to process
the tail element, but only VSTART >= vl was checked in the vext_vx_rm_1
function, which caused the tail element to still be processed even if it was
returned in advance.
So I've made the following change:
Put VSTART_CHECK_EARLY_EXIT(env) at the beginning of the vext_vx_rm_2 function,
so that the VSTART register is checked correctly.
Fixes: df4252b2ec ("target/riscv/vector_helpers: do early exit when
vstart >= vl")
Signed-off-by: Chao Liu <lc00...@tecorigin.com>
Reviewed-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Message-ID:
<b2649f14915150be4c602d63cd3ea4adf47e9d75.1741573286.git.lc00...@tecorigin.com>
Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
(cherry picked from commit 4e9e2478dfd26480bbf50367a67b9be0edafef2b)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Compare: https://github.com/qemu/qemu/compare/e7453f0cd3b9...3cdd1f45aa55
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
