Helge Deller [Sat, 17 May 2025 11:27:48 +0000 (13:27 +0200)]
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.
Helge Deller [Sat, 17 May 2025 11:20:17 +0000 (13:20 +0200)]
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 <deller@gmx.de>
(cherry picked from commit b4b49cf39dba5f993ad925f204cb820aacfc8e45) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Helge Deller [Sat, 17 May 2025 11:12:07 +0000 (13:12 +0200)]
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 <deller@gmx.de>
(cherry picked from commit 923976dfe367b0bfed45ff660c369f3fe65604a7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Xu [Tue, 13 May 2025 21:33:16 +0000 (17:33 -0400)]
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 <dave@treblig.org> Reviewed-by: Juraj Marcin <jmarcin@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit 17bec9235bb0775cf8dec4103c167757ee8898f3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Zhao Liu [Tue, 13 May 2025 14:31:31 +0000 (22:31 +0800)]
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.
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
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.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250429124421.223883-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit d3b6f1742c36e3a3c1e74cb60646ee98a4e39ea3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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 <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250429124421.223883-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 11766e17616a5a4181d4a63f88adf67ac52c553b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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 <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250429124421.223883-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit b6096103494506514d9bfa442f62fef36ffc8fba) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/riscv/kvm: fix leak in kvm_riscv_init_multiext_cfg()
'reglist' is being g-malloc'ed but never freed.
Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250429124421.223883-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 906af6de9462c5192547cca0beac2c134659a437) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Anton Blanchard [Mon, 14 Apr 2025 21:30:06 +0000 (21:30 +0000)]
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 <antonb@tenstorrent.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250414213006.3509058-1-antonb@tenstorrent.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 2669b696e243b64f8ea1a6468dcee255de99f08d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:37 +0000 (18:39 +0800)]
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 <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-10-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit db21c3eb05504c4cedaad4f7b19e588361b02385) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:36 +0000 (18:39 +0800)]
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 <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-9-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 1f090a229f85e662394267680408bd31fd0a99c9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:35 +0000 (18:39 +0800)]
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 <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-8-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 411eefd56a3921ddbfdbadca596e1a8593ce834c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:34 +0000 (18:39 +0800)]
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 <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-7-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit b5480a693e3e657108746721ffe434b3bb6e7a72) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:33 +0000 (18:39 +0800)]
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 <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-6-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit fda68acb7761af40df78db18e44ca1ff20195fe0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:32 +0000 (18:39 +0800)]
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 <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-5-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit fbeaf35838768086b435833cb4dc5182c73ec2bc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 8 Apr 2025 10:39:31 +0000 (18:39 +0800)]
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 <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-4-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 629c2a8dd7506e1cb9b6b7127604641632ac453f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Anton Blanchard [Tue, 8 Apr 2025 10:39:30 +0000 (18:39 +0800)]
target/riscv: rvv: Add CHECK arg to GEN_OPFVF_WIDEN_TRANS
Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Max Chou <max.chou@sifive.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-3-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit b0450a101d6c88789d0e8df2bcbef61bc7cd159a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Add the relevant ISA paragraphs explaining why source (and destination)
registers cannot overlap the mask register.
Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Max Chou <max.chou@sifive.com> Signed-off-by: Max Chou <max.chou@sifive.com>
Message-ID: <20250408103938.3623486-2-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 3e8d1e4a628bb234c0b5d1ccd510900047181dbd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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 <uwu@icenowy.me> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250417072206.364008-1-uwu@icenowy.me> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 22b448ccc6611a59d4aa54419f4d88c1f343cb35) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Ziqiao Kong [Tue, 15 Apr 2025 08:02:54 +0000 (16:02 +0800)]
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 <ziqiaokong@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250415080254.3667878-2-ziqiaokong@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit ad63158bdb33dab5704ea1cf740d2ea0387175df) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20250421-reset-v2-1-e4c1ead88ea1@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 0caed25cd171c611781589b5402161d27d57229c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Fabiano Rosas [Fri, 9 May 2025 17:49:38 +0000 (14:49 -0300)]
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-stable@nongnu.org Signed-off-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20250509174938.25935-1-farosas@suse.de> Fixes: 1fd396e3228 ("s390x: Register TYPE_S390_CCW_MACHINE properties as class properties") Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit bdf12f2a56bf3f13c52eb51f0a994bbfe40706b2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <5747469d3f039c53147e850b456943a1d4b5485c.1741339452.git.qemu_oss@crudebyte.com>
(cherry picked from commit 89f7b4da7662ecc6840ffb0846045f03f9714bc6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <5c622067efd66dd4ee5eca740dcf263f41db20b2.1741339452.git.qemu_oss@crudebyte.com>
(cherry picked from commit 61da38db70affd925226ce1e8a61d761c20d045b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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-stable@nongnu.org Fixes: 20d0f9cf6a41 ("i.MX: Add I2C controller emulator") Signed-off-by: Bernhard Beschow <shentey@gmail.com> Acked-by: Corey Minyard <cminyard@mvista.com>
Message-ID: <20250507124040.425773-1-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 54e54e594bc8273d210f7ff4448c165a989cbbe8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
gitlab: use --refetch in check-patch/check-dco jobs
When gitlab initializes the repo checkout for a CI job, it will have
done a shallow clone with only partial history. Periodically the objects
that are omitted cause trouble with the check-patch/check-dco jobs. This
is exhibited as reporting strange errors being unable to fetch certain
objects that are known to exist.
Passing the --refetch flag to 'git fetch' causes it to not assume the
local checkout has all common objects and thus re-fetch everything that
is needed. This appears to solve the check-patch/check-dco job failures.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250225110525.2209854-1-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit d5d028eee38d4107821c0d2cfdb0dd04b9ba5ca3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Mon, 15 Jul 2024 08:35:06 +0000 (10:35 +0200)]
target/i386: do not block singlestep for STI
STI will trigger a singlestep exception even if it has inhibit-IRQ
behavior. Do not suppress single-step for all IRQ-inhibiting
instructions, instead special case MOV SS and POP SS.
Cc: qemu-stable@nongnu.org Fixes: f0f0136abba ("target/i386: no single-step exception after MOV or POP SS", 2024-05-25) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 1e94ddc6854431064c94a7d8f2f2886def285829) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Thu, 8 May 2025 09:32:11 +0000 (11:32 +0200)]
target/i386: do not trigger IRQ shadow for LSS
Because LSS need not trigger an IRQ shadow, gen_movl_seg can't just use
the destination register to decide whether to inhibit IRQs. Add an
argument.
Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit e54ef98c8a80d16158bab4341d9a898701270528)
(back-ported to 10.0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/gpio/imx_gpio: Fix interpretation of GDIR polarity
According to the i.MX 8M Plus reference manual, a GPIO pin is
configured as an output when the corresponding bit in the GDIR
register is set. The function imx_gpio_set_int_line() is intended to
be a no-op if the pin is configured as an output, returning early in
such cases. However, it inverts the condition. Fix this by
returning early when the bit is set.
cc: qemu-stable@nongnu.org Fixes: f44272809779 ("i.MX: Add GPIO device") Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-id: 20250501183445.2389-4-shentey@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit eba837a31b9579e30cc6d7ecb4b5c2662a6ffaba) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Both calls are in arm_tr_tb_stop(), one for the
DISAS_NEXT/DISAS_TOO_MANY handling, and one for the dc->condjump
condition-failed codepath. The DISAS_NEXT handling doesn't have this
problem because arm_post_translate_insn() does the handling of "emit
the label for the condition-failed conditional execution" and so
arm_tr_tb_stop() doesn't have dc->condjump set. But for
DISAS_TOO_MANY we don't do that.
Fix the bug by making arm_post_translate_insn() handle the
DISAS_TOO_MANY case. This only affects the SB and ISB insns when
used in Thumb mode inside an IT block: only these insns specifically
set is_jmp to TOO_MANY, and their A32 encodings are unconditional.
For the major TOO_MANY case (breaking the TB because it would cross a
page boundary) we do that check and set is_jmp to TOO_MANY only after
the call to arm_post_translate_insn(); so arm_post_translate_insn()
sees is_jmp == DISAS_NEXT, and we emit the correct code for that
situation.
With this fix we generate the somewhat more sensible set of TCG ops:
brcond_i32 ZF,$0x0,ne,$L1
set_label $L1
add_i32 pc,pc,$0x4
goto_tb $0x1
exit_tb $0x7c5434001b81
(NB: the TCG optimizer doesn't optimize out the jump-to-next, but
we can't really avoid emitting it because we don't know at the
point we're emitting the handling for the condexec check whether
this insn is going to happen to be a nop for us or not.)
Cc: qemu-stable@nongnu.org Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2942 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250501125544.727038-1-peter.maydell@linaro.org
(cherry picked from commit 8ed7c0b6488a7f20318d6ba414f1cbcd0ed92afe) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The use of gnu_source_prefix in the detection of getcpu() was
ineffective because the header file that declares getcpu() when
_GNU_SOURCE is defined was not included. Pass sched.h to
has_header_symbol() so that the existence of the declaration will be
properly checked.
Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250424-buildsys-v1-1-97655e3b25d7@daynix.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 563cd698dffb977eea0ccfef3b95f6f9786766f3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Mon, 17 Mar 2025 14:28:11 +0000 (14:28 +0000)]
hw/core/cpu: gdb_arch_name string should not be freed
The documentation for the CPUClass::gdb_arch_name method claims that
the returned string should be freed with g_free(). This is not
correct: in commit a650683871ba728 we changed this method to
instead return a simple constant string, but forgot to update
the documentation.
Make the documentation match the new semantics.
Fixes: a650683871ba728 ("hw/core/cpu: Return static value with gdb_arch_name()") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250317142819.900029-2-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 56a9f0d4c4a483ce217e5290db69cb1788586787) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/core: Get default_cpu_type calling machine_class_default_cpu_type()
Since commit 62b4a227a33 the default cpu type can come from the
valid_cpu_types[] array. Call the machine_class_default_cpu_type()
instead of accessing MachineClass::default_cpu_type field.
Cc: qemu-stable@nongnu.org Fixes: 62b4a227a33 ("hw/core: Add machine_class_default_cpu_type()") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Message-Id: <20250422084114.39499-1-philmd@linaro.org>
(cherry picked from commit d5f241834be1b323ea697a469ff0f1335a1823fe) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The comment about not being able to define a field with
zero bits is out of date since 94597b6146f3
("decodetree: Allow !function with no input bits").
This fixes the missing load of imm in the disassembler.
Cc: qemu-stable@nongnu.org Fixes: 9d8caa67a24 ("target/avr: Add support for disassembling via option '-d in_asm'") Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 6b661b7ed7cd02c54a78426d5eb7dd8543b030ed) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Thu, 3 Apr 2025 19:39:54 +0000 (21:39 +0200)]
target/i386/hvf: fix lflags_to_rflags
Clear the flags before adding in the ones computed from lflags.
Cc: Wei Liu <liuwe@linux.microsoft.com> Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 94a159f3dc737d00749cc930adaec112abe07b3c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The goal was to remove the need to patch the (const) input buffer
with a recomputed UDP checksum by copying headers to a RW region and
inject the checksum there. The patch computed the checksum only from the
header fields (missing the rest of the payload) producing an invalid one
and making guests fail to acquire a DHCP lease.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2727 Cc: qemu-stable@nongnu.org Signed-off-by: Antoine Damhet <adamhet@scaleway.com> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250408145345.142947-1-adamhet@scaleway.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit e28fbd1c525db21f0502b85517f49504c9f9dcd8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In msys2 distribution objdump from gcc is using single tab character
prefix, but objdump from clang is using 4 white space characters instead.
The script will not identify any dll dependencies for a QEMU build
generated with clang. This in turn will fail the build, because there
will be no files inside dlldir and no setup file will be created.
Instead of checking for whitespace in prefix use lstrip to accommodate
for differences in outputs.
Signed-off-by: Arthur Sengileyev <arthur.sengileyev@gmail.com> Reviewed-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit b0b5af62ef9eaf25246cdd433a4eb69361298ee4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Daan De Meyer [Sun, 23 Mar 2025 21:35:54 +0000 (22:35 +0100)]
smbios: Fix buffer overrun when using path= option
We have to make sure the array of bytes read from the path= file
is null-terminated, otherwise we run into a buffer overrun later on.
Fixes: bb99f4772f54017490e3356ecbb3df25c5d4537f ("hw/smbios: support loading OEM strings values from a file")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2879
Signed-off-by: Daan De Meyer <daan.j.demeyer@gmail.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Valentin David <valentin.david@canonical.com>
Message-ID: <20250323213622.2581013-1-daan.j.demeyer@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit a7a05f5f6a4085afbede315e749b1c67e78c966b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Kevin Wolf [Mon, 7 Apr 2025 15:59:49 +0000 (17:59 +0200)]
scsi-disk: Apply error policy for host_status errors again
Originally, all failed SG_IO requests called scsi_handle_rw_error() to
apply the configured error policy. However, commit f3126d65, which was
supposed to be a mere refactoring for scsi-disk.c, broke this and
accidentally completed the SCSI request without considering the error
policy any more if the error was signalled in the host_status field.
Apart from the commit message not describing the change as intended,
errors indicated in host_status are also obviously backend errors and
not something the guest must deal with independently of the error
policy.
This behaviour means that some recoverable errors (such as a path error
in multipath configurations) were reported to the guest anyway, which
might not expect it and might consider its disk broken.
Make sure that we apply the error policy again for host_status errors,
too. This addresses an existing FIXME comment and allows us to remove
some comments warning that callbacks weren't always called. With this
fix, they are called in all cases again.
The return value passed to the request callback doesn't have more free
values that could be used to indicate host_status errors as well as SAM
status codes and negative errno. Store the value in the host_status
field of the SCSIRequest instead and use -ENODEV as the return value (if
a path hasn't been reachable for a while, blk_aio_ioctl() will return
-ENODEV instead of just setting host_status, so just reuse it here -
it's not necessarily entirely accurate, but it's as good as any errno).
Cc: qemu-stable@nongnu.org Fixes: f3126d65b393 ('scsi: move host_status handling into SCSI drivers') Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250407155949.44736-1-kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 61b6d9b749ba233784c7214cfe9585ea321159dc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Nicholas Piggin [Thu, 24 Oct 2024 15:18:12 +0000 (01:18 +1000)]
target/ppc: Fix SPRC/SPRD SPRs for P9/10
Commit 60d30cff847 ("target/ppc: Move SPR indirect registers into
PnvCore") was mismerged and moved the SPRs to power8-only, instead
of power9/10-only.
Fixes: 60d30cff847 ("target/ppc: Move SPR indirect registers into PnvCore") Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: qemu-stable@nongnu.org Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
(cherry picked from commit b3d47c8303b8be2c3693c5704012b3334741b7ed)
(Mjt: adjust context for v9.2.0-2634-gffb6440cc5 "ppc/pnv: Add new PowerPC Special Purpose Registers (RWMR)") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Nicholas Piggin [Thu, 5 Sep 2024 22:13:51 +0000 (08:13 +1000)]
target/ppc: Big-core scratch register fix
The per-core SCRATCH0-7 registers are shared between big cores, which
was missed in the big-core implementation. It is difficult to model
well with the big-core == 2xPnvCore scheme we moved to, this fix
uses the even PnvCore to store the scrach data.
Also remove a stray log message that came in with the same patch that
introduced patch.
Fixes: c26504afd5f5c ("ppc/pnv: Add a big-core mode that joins two regular cores") Cc: qemu-stable@nongnu.org Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
(cherry picked from commit 9808ce6d5cb75a4f9db76a3d9b508560efdf5ac2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In the resolved issues, incomplete dead code elimination left a load
at the top of an unreachable loop. We simply need to allocate the
stack slot to avoid crashing.
Fixes: c896fe29d6c ("TCG code generator") Reported-by: Michael Tokarev <mjt@tls.msk.ru> Reported-by: Helge Konetzka <hk@zapateado.de>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2891
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2899 Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250401144332.41615-1-philmd@linaro.org>
(cherry picked from commit e139bc4b1772575e1f2dcf8e3dbe1df2b684ef1f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/i386/amd_iommu: Assign pci-id 0x1419 for the AMD IOMMU device
Currently, the QEMU-emulated AMD IOMMU device use PCI vendor id 0x1022
(AMD) with device id zero (undefined). Eventhough this does not cause any
functional issue for AMD IOMMU driver since it normally uses information
in the ACPI IVRS table to probe and initialize the device per
recommendation in the AMD IOMMU specification, the device id zero causes
the Windows Device Manager utility to show the device as an unknown device.
Since Windows only recognizes AMD IOMMU device with device id 0x1419 as
listed in the machine.inf file, modify the QEMU AMD IOMMU model to use
the id 0x1419 to avoid the issue. This advertise the IOMMU as the AMD
IOMMU device for Family 15h (Models 10h-1fh).
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Message-Id: <20250325021140.5676-1-suravee.suthikulpanit@amd.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Yan Vugenfirer <yvugenfi@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 719255486df2fcbe1b8599786b37f4bb80272f1a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Akihiko Odaki [Wed, 8 Jan 2025 12:13:29 +0000 (21:13 +0900)]
virtio-net: Fix num_buffers for version 1
The specification says the device MUST set num_buffers to 1 if
VIRTIO_NET_F_MRG_RXBUF has not been negotiated.
Fixes: df91055db5c9 ("virtio-net: enable virtio 1.0") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20250108-buffers-v1-1-a0c85ff31aeb@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit c17ad4b11bd268a35506cd976884562df6ca69d7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Marco Cavenati [Wed, 26 Mar 2025 16:22:30 +0000 (17:22 +0100)]
migration: fix SEEK_CUR offset calculation in qio_channel_block_seek
The SEEK_CUR case in qio_channel_block_seek was incorrectly using the
'whence' parameter instead of the 'offset' parameter when calculating the
new position.
Fixes: 65cf200a51 ("migration: introduce a QIOChannel impl for BlockDriverState VMState") Signed-off-by: Marco Cavenati <Marco.Cavenati@eurecom.fr> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Message-ID: <20250326162230.3323199-1-Marco.Cavenati@eurecom.fr> Signed-off-by: Fabiano Rosas <farosas@suse.de>
(cherry picked from commit c0b32426ce56182c1ce2a12904f3a702c2ecc460) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When update_pagemask was split from helper_mtc0_pagemask,
we failed to actually write to the new parameter but continue
to write to env->CP0_PageMask. Thus the use within
page_table_walk_refill modifies cpu state and not the local
variable as expected.
Simplify by renaming to compute_pagemask and returning the
value directly. No need for either env or pointer return.
Fixes: 074cfcb4dae ("target/mips: Implement hardware page table walker for MIPS32") Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250328175526.368121-4-richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: qemu-stable@nongnu.org
(cherry picked from commit 256ba7715b109c080c0c77a3923df9e69736ba17) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Revert ee3863b9d41 and a08d60bc6c2b. The logic behind changing
the system page size because of what the Loongson kernel "prefers"
is flawed.
In the Loongson-2E manual, section 5.5, it is clear that the cpu
supports a 4k page size (along with many others). Similarly for
the Loongson-3 series CPUs, the 4k page size is mentioned in the
section 7.7 (PageMask Register). Therefore we must continue to
support a 4k page size.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250328175526.368121-2-richard.henderson@linaro.org>
[PMD: Mention Loongson-3 series CPUs] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit fca2817fdcb00e65020c2dcfcb0b23b2a20ea3c4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Currently resetting the leads to resynchronizing the Goldfish RTC
with the system clock of the host. In real hardware an RTC reset
would not change the wall time. Other RTCs like pl031 do not show
this behavior.
Move the synchronization of the RTC with the system clock to the
instance realization.
Cc: qemu-stable@nongnu.org Reported-by: Frederik Du Toit Lotter <fred.lotter@canonical.com> Fixes: 9a5b40b8427 ("hw: rtc: Add Goldfish RTC device") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250321221248.17764-1-heinrich.schuchardt@canonical.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 2542d5cf471a38c4ceb9717708178938b96ded47) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Steven Lee [Thu, 20 Mar 2025 09:25:43 +0000 (17:25 +0800)]
hw/intc/aspeed: Fix IRQ handler mask check
Updated the IRQ handler mask check to AND with select variable.
This ensures that the interrupt service routine is correctly triggered
for the interrupts within the same irq group.
For example, both `eth0` and the debug UART are handled in `GICINT132`.
Without this fix, the debug console may hang if the `eth0` ISR is not
handled.
Jamin Lin [Fri, 21 Mar 2025 09:25:58 +0000 (17:25 +0800)]
hw/misc/aspeed_hace: Fix buffer overflow in has_padding function
The maximum padding size is either 64 or 128 bytes and should always be smaller
than "req_len". If "padding_size" exceeds "req_len", then
"req_len - padding_size" underflows due to "uint32_t" data type, leading to a
large incorrect value (e.g., `0xFFXXXXXX`). This causes an out-of-bounds memory
access, potentially leading to a buffer overflow.
Added a check to ensure "padding_size" does not exceed "req_len" before
computing "pad_offset". This prevents "req_len - padding_size" from underflowing
and avoids accessing invalid memory.
Chao Liu [Mon, 10 Mar 2025 02:35:25 +0000 (10:35 +0800)]
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 <lc00631@tecorigin.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <b2649f14915150be4c602d63cd3ea4adf47e9d75.1741573286.git.lc00631@tecorigin.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 4e9e2478dfd26480bbf50367a67b9be0edafef2b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Chao Liu [Mon, 10 Mar 2025 02:35:24 +0000 (10:35 +0800)]
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 <lc00631@tecorigin.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <f575979874e323a9e0da7796aa391c7d87e56f88.1741573286.git.lc00631@tecorigin.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit e83845316abcea9024eb5402a6c5eb8b092c79d5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Michael Tokarev [Wed, 19 Feb 2025 12:58:39 +0000 (15:58 +0300)]
Makefile: "make dist" generates a .xz, not .bz2
Fixes: 9bc9e9511944 (make-release: switch to .xz format by default) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 14fb6dbbc50f43057202c685c3aa017287cca37f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Nicholas Piggin [Thu, 20 Mar 2025 11:39:59 +0000 (21:39 +1000)]
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 <rathc@linux.ibm.com> Cc: qemu-stable@nongnu.org Debugged-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@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 <npiggin@gmail.com>
(cherry picked from commit 8defe9da08135d03e054f20cb8fea4389be96e18) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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-stable@nongnu.org Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250313094705.2361997-1-harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
(cherry picked from commit 1490d0bcdfcb78b4503cae42353d3dd50f4e9d96) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Yao Zi [Fri, 14 Mar 2025 03:31:51 +0000 (03:31 +0000)]
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-stable@nongnu.org Fixes: adc8467e697 ("host/include/loongarch64: Add atomic16 load and store") Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
(cherry picked from commit ca2737d6eca7fcc62ecb7a27246837b7c18830fc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Deepak Gupta [Thu, 6 Mar 2025 06:46:36 +0000 (22:46 -0800)]
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 <ved@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250306064636.452396-2-debug@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit d2c5759c8dd4c00195d4ebecc7d009e41df6baef) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Deepak Gupta [Thu, 6 Mar 2025 06:46:35 +0000 (22:46 -0800)]
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 <azabrocki@nvidia.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250306064636.452396-1-debug@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 86c78b280607fcff787866a03374047c65037a90) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Santiago Monserrat Campanello <santimonserr@gmail.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2717 Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250305102632.91376-1-santimonserr@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 672cb29d1e811180bf1aeefbcb0936ecd5bd3853) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Add .set_vnet_le() function that always returns success, assuming that
vDPA h/w always implements LE data format. Otherwise, QEMU disables vDPA and
outputs the message:
"backend does not support LE vnet headers; falling back on userspace virtio"
Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit b027f55a994af885a7a498a40373a2dcc2d8b15e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
VDPA didn't work on a big-endian machine due to missing/incorrect
CPU<->LE data format conversions.
Signed-off-by: Konstantin Shkolnyy <kshk@linux.ibm.com>
Message-Id: <20250212164923.1971538-1-kshk@linux.ibm.com> Fixes: 10857ec0ad ("vhost: Add VhostShadowVirtqueue") Acked-by: Eugenio Pérez <eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 50e9754149066dc91f58405d3378b589098cb408) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Guo Hongyu [Thu, 19 Dec 2024 12:23:11 +0000 (20:23 +0800)]
target/loongarch: Fix vldi inst
Refer to the link below for a description of the vldi instructions:
https://jia.je/unofficial-loongarch-intrinsics-guide/lsx/misc/#synopsis_88
Fixed errors in vldi instruction implementation.
Signed-off-by: Guo Hongyu <guohongyu24@mails.ucas.ac.cn> Tested-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Xianglai Li <lixianglai@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
(cherry picked from commit 02ce6cea71be4f6774351f5e658d50044c5b53b2)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2865 Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/arm: Simplify pstate_sm check in sve_access_check
In StreamingMode, fp_access_checked is handled already.
We cannot fall through to fp_access_check lest we fall
foul of the double-check assertion.
Cc: qemu-stable@nongnu.org Fixes: 285b1d5fcef ("target/arm: Handle SME in sve_access_check") Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250307190415.982049-3-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: move declaration of 'ret' to top of block] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit cc7abc35dfa790ba6c20473c03745428c1c626b6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/arm: Make DisasContext.{fp, sve}_access_checked tristate
The check for fp_excp_el in assert_fp_access_checked is
incorrect. For SME, with StreamingMode enabled, the access
is really against the streaming mode vectors, and access
to the normal fp registers is allowed to be disabled.
C.f. sme_enabled_check.
Convert sve_access_checked to match, even though we don't
currently check the exception state.
Cc: qemu-stable@nongnu.org Fixes: 3d74825f4d6 ("target/arm: Add SME enablement checks") Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250307190415.982049-2-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 298a04998fa4a6dc977abe9234d98dfcdab98423) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Joe Komlodi [Mon, 10 Mar 2025 20:36:22 +0000 (20:36 +0000)]
util/cacheflush: Make first DSB unconditional on aarch64
On ARM hosts with CTR_EL0.DIC and CTR_EL0.IDC set, this would only cause
an ISB to be executed during cache maintenance, which could lead to QEMU
executing TBs containing garbage instructions.
This seems to be because the ISB finishes executing instructions and
flushes the pipeline, but the ISB doesn't guarantee that writes from the
executed instructions are committed. If a small enough TB is created, it's
possible that the writes setting up the TB aren't committed by the time the
TB is executed.
This function is intended to be a port of the gcc implementation
(https://github.com/gcc-mirror/gcc/blob/85b46d0795ac76bc192cb8f88b646a647acf98c1/libgcc/config/aarch64/sync-cache.c#L67)
which makes the first DSB unconditional, so we can fix the synchronization
issue by doing that as well.
Cc: qemu-stable@nongnu.org Fixes: 664a79735e4deb1 ("util: Specialize flush_idcache_range for aarch64") Signed-off-by: Joe Komlodi <komlodi@google.com>
Message-id: 20250310203622.1827940-2-komlodi@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit e6c38d2ab55d66c74ceade5699e22cabe9058d22) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Greg Kurz [Thu, 6 Mar 2025 17:41:13 +0000 (18:41 +0100)]
docs: Rename default-configs to configs
This was missed at the time.
Fixes: 812b31d3f91 ("configs: rename default-configs to configs and reorganise") Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250306174113.427116-1-groug@kaod.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 48170c2d865a5937092b1384421b01cd38113042) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Kevin Wolf [Mon, 10 Mar 2025 10:48:58 +0000 (11:48 +0100)]
block: Zero block driver state before reopening
Block drivers assume in their .bdrv_open() implementation that their
state in bs->opaque has been zeroed; it is initially allocated with
g_malloc0() in bdrv_open_driver().
bdrv_snapshot_goto() needs to make sure that it is zeroed again before
calling drv->bdrv_open() to avoid that block drivers use stale values.
One symptom of this bug is VMDK running into a double free when the user
tries to apply an internal snapshot like 'qemu-img snapshot -a test
test.vmdk'. This should be a graceful error because VMDK doesn't support
internal snapshots.
==25507== Invalid free() / delete / delete[] / realloc()
==25507== at 0x484B347: realloc (vg_replace_malloc.c:1801)
==25507== by 0x54B592A: g_realloc (gmem.c:171)
==25507== by 0x1B221D: vmdk_add_extent (../block/vmdk.c:570)
==25507== by 0x1B1084: vmdk_open_sparse (../block/vmdk.c:1059)
==25507== by 0x1AF3D8: vmdk_open (../block/vmdk.c:1371)
==25507== by 0x1A2AE0: bdrv_snapshot_goto (../block/snapshot.c:299)
==25507== by 0x205C77: img_snapshot (../qemu-img.c:3500)
==25507== by 0x58FA087: (below main) (libc_start_call_main.h:58)
==25507== Address 0x832f3e0 is 0 bytes inside a block of size 272 free'd
==25507== at 0x4846B83: free (vg_replace_malloc.c:989)
==25507== by 0x54AEAC4: g_free (gmem.c:208)
==25507== by 0x1AF629: vmdk_close (../block/vmdk.c:2889)
==25507== by 0x1A2A9C: bdrv_snapshot_goto (../block/snapshot.c:290)
==25507== by 0x205C77: img_snapshot (../qemu-img.c:3500)
==25507== by 0x58FA087: (below main) (libc_start_call_main.h:58)
This error was discovered by fuzzing qemu-img.
Cc: qemu-stable@nongnu.org Closes: https://gitlab.com/qemu-project/qemu/-/issues/2853 Closes: https://gitlab.com/qemu-project/qemu/-/issues/2851 Reported-by: Denis Rastyogin <gerben@altlinux.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250310104858.28221-1-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit b75c5f9879166b86ed7c48b772fdcd0693e8a9a3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 28 Feb 2025 19:16:51 +0000 (19:16 +0000)]
hw/net/smc91c111: Don't allow data register access to overrun buffer
For accesses to the 91c111 data register, the address within the
packet's data frame is determined by a combination of the pointer
register and the offset used to access the data register, so that you
can access data at effectively wider than byte width. The pointer
register's pointer field is 11 bits wide, which is exactly the size
to index a 2048-byte data frame.
We weren't quite getting the logic right for ensuring that we end up
with a pointer value to use in the s->data[][] array that isn't out
of bounds:
* we correctly mask when getting the initial pointer value
* for the "autoincrement the pointer register" case, we
correctly mask after adding 1 so that the pointer register
wraps back around at the 2048 byte mark
* but for the non-autoincrement case where we have to add the
low 2 bits of the data register offset, we don't account
for the possibility that the pointer register is 0x7ff
and the addition should wrap
Fix this bug by factoring out the "get the p value to use as an array
index" into a function, making it use FIELD macro names rather than
hard-coded constants, and having a utility function that does "add a
value and wrap it" that we can use both for the "autoincrement" and
"add the offset bits" codepaths.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2758 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250228191652.1957208-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 700d3d6dd41de3bd3f1153e3cfe00b93f99b1441) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 28 Feb 2025 17:48:00 +0000 (17:48 +0000)]
hw/net/smc91c111: Sanitize packet length on tx
When the smc91c111 transmits a packet, it must read a control byte
which is at the end of the data area and CRC. However, we don't
sanitize the length field in the packet buffer, so if the guest sets
the length field to something large we will try to read past the end
of the packet data buffer when we access the control byte.
As usual, the datasheet says nothing about the behaviour of the
hardware if the guest misprograms it in this way. It says only that
the maximum valid length is 2048 bytes. We choose to log the guest
error and silently drop the packet.
This requires us to factor out the "mark the tx packet as complete"
logic, so we can call it for this "drop packet" case as well as at
the end of the loop when we send a valid packet.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2742 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250228174802.1945417-3-peter.maydell@linaro.org>
[PMD: Update smc91c111_do_tx() as len > MAX_PACKET_SIZE] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit aad6f264add3f2be72acb660816588fe09110069) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 28 Feb 2025 17:47:59 +0000 (17:47 +0000)]
hw/net/smc91c111: Sanitize packet numbers
The smc91c111 uses packet numbers as an index into its internal
s->data[][] array. Valid packet numbers are between 0 and 3, but
the code does not generally check this, and there are various
places where the guest can hand us an arbitrary packet number
and cause an out-of-bounds access to the data array.
Add validation of packet numbers. The datasheet is not very
helpful about how guest errors like this should be handled:
it says nothing on the subject, and none of the documented
error conditions are relevant. We choose to log the situation
with LOG_GUEST_ERROR and silently ignore the attempted operation.
In the places where we are about to access the data[][] array
using a packet number and we know the number is valid because
we got it from somewhere that has already validated, we add
an assert() to document that belief.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250228174802.1945417-2-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 2fa3a5b9469615d06091cf473d172794148e1248) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Afterward, there is no error and the sensor_groups directory appears
under /sys/firmware/opal/.
The SLW_IMAGE_BASE address looks like a workaround to intercept firmware
memory accesses, but that does not seem to be required now (and would
have been broken by the OCC common area region mapping change anyway).
So it can be removed.
Fixes: 3a1b70b66b5cb4 ("ppc/pnv: Fix OCC common area region mapping") Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
(cherry picked from commit 29c041ca7f8d6910c894788482efff892789dcd2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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-stable@nongnu.org Reported-by: Olaf Hering <olaf@aepfle.de> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Message-Id: <20250206194915.3357743-2-edgar.iglesias@gmail.com> Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
(cherry picked from commit 68adcc784bad13421ac7211c316a751fb99fcb94) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Eugenio Pérez [Mon, 6 Jan 2025 15:57:35 +0000 (10:57 -0500)]
net: move backend cleanup to NIC cleanup
Commit a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net
structures if peer nic is present") effectively delayed the backend
cleanup, allowing the frontend or the guest to access it resources as
long as the frontend is still visible to the guest.
However it does not clean up the resources until the qemu process is
over. This causes an effective leak if the device is deleted with
device_del, as there is no way to close the vdpa device. This makes
impossible to re-add that device to this or other QEMU instances until
the first instance of QEMU is finished.
Move the cleanup from qemu_cleanup to the NIC deletion and to
net_cleanup.
Fixes: a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net structures if peer nic is present") Reported-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit e7891c575fb294618b172119a91c892b8f4384a2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Eugenio Pérez [Mon, 6 Jan 2025 15:57:34 +0000 (10:57 -0500)]
net: parameterize the removing client from nc list
This change is used in later commits so we can avoid the removal of the
netclient if it is delayed.
No functional change intended.
Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit db0d4017f9b9e87f962b35dd19a4912bbfcd3cbc)
(Mjt: pick this one up for the following change,
"net: move backend cleanup to NIC cleanup") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Mon, 10 Feb 2025 13:58:04 +0000 (13:58 +0000)]
util/qemu-timer.c: Don't warp timer from timerlist_rearm()
Currently we call icount_start_warp_timer() from timerlist_rearm().
This produces incorrect behaviour, because timerlist_rearm() is
called, for instance, when a timer callback modifies its timer. We
cannot decide here to warp the timer forwards to the next timer
deadline merely because all_cpu_threads_idle() is true, because the
timer callback we were called from (or some other callback later in
the list of callbacks being invoked) may be about to raise a CPU
interrupt and move a CPU from idle to ready.
The only valid place to choose to warp the timer forward is from the
main loop, when we know we have no outstanding IO or timer callbacks
that might be about to wake up a CPU.
For Arm guests, this bug was mostly latent until the refactoring
commit f6fc36deef6abc ("target/arm/helper: Implement
CNTHCTL_EL2.CNT[VP]MASK"), which exposed it because it refactored a
timer callback so that it happened to call timer_mod() first and
raise the interrupt second, when it had previously raised the
interrupt first and called timer_mod() afterwards.
This call seems to have originally derived from the
pre-record-and-replay icount code, which (as of e.g. commit db1a49726c3c in 2010) in this location did a call to
qemu_notify_event(), necessary to get the icount code in the vCPU
round-robin thread to stop and recalculate the icount deadline when a
timer was reprogrammed from the IO thread. In current QEMU,
everything is done on the vCPU thread when we are in icount mode, so
there's no need to try to notify another thread here.
I suspect that the other reason why this call was doing icount timer
warping is that it pre-dates commit efab87cf79077a from 2015, which
added a call to icount_start_warp_timer() to main_loop_wait(). Once
the call in timerlist_rearm() has been removed, if the timer
callbacks don't cause any CPU to be woken up then we will end up
calling icount_start_warp_timer() from main_loop_wait() when the rr
main loop code calls rr_wait_io_event().
Remove the incorrect call from timerlist_rearm().
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2703 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20250210135804.3526943-1-peter.maydell@linaro.org
(cherry picked from commit 02ae315467cee589d02dfb89e13a2a6a8de09fc5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 7 Mar 2025 10:08:21 +0000 (10:08 +0000)]
target/arm: Correct STRD atomicity
Our STRD implementation doesn't correctly implement the requirement:
* if the address is 8-aligned the access must be a 64-bit
single-copy atomic access, not two 32-bit accesses
Rewrite the handling of STRD to use a single tcg_gen_qemu_st_i64()
of a value produced by concatenating the two 32 bit source registers.
This allows us to get the atomicity right.
As with the LDRD change, now that we don't update 'addr' in the
course of performing the store we need to adjust the offset
we pass to op_addr_ri_post() and op_addr_rr_post().
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250227142746.1698904-3-peter.maydell@linaro.org
(cherry picked from commit ee786ca115045a2b7e86ac3073b0761cb99e0d49) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 7 Mar 2025 10:08:21 +0000 (10:08 +0000)]
target/arm: Correct LDRD atomicity and fault behaviour
Our LDRD implementation is wrong in two respects:
* if the address is 4-aligned and the load crosses a page boundary
and the second load faults and the first load was to the
base register (as in cases like "ldrd r2, r3, [r2]", then we
must not update the base register before taking the fault
* if the address is 8-aligned the access must be a 64-bit
single-copy atomic access, not two 32-bit accesses
Rewrite the handling of the loads in LDRD to use a single
tcg_gen_qemu_ld_i64() and split the result into the destination
registers. This allows us to get the atomicity requirements
right, and also implicitly means that we won't update the
base register too early for the page-crossing case.
Note that because we no longer increment 'addr' by 4 in the course of
performing the LDRD we must change the adjustment value we pass to
op_addr_ri_post() and op_addr_rr_post(): it no longer needs to
subtract 4 to get the correct value to use if doing base register
writeback.
STRD has the same problem with not getting the atomicity right;
we will deal with that in the following commit.
Cc: qemu-stable@nongnu.org Reported-by: Stu Grossman <stu.grossman@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250227142746.1698904-2-peter.maydell@linaro.org
(cherry picked from commit cde3247651dc998da5dc1005148302a90d72f21f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Alex Bennée [Fri, 7 Mar 2025 10:08:21 +0000 (10:08 +0000)]
hw/arm: enable secure EL2 timers for sbsa machine
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20250204125009.2281315-10-peter.maydell@linaro.org Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 9a9d9e82093efa22e3e2bdaac0f24c823f8786f7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Alex Bennée [Fri, 7 Mar 2025 10:08:21 +0000 (10:08 +0000)]
hw/arm: enable secure EL2 timers for virt machine
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20250204125009.2281315-9-peter.maydell@linaro.org Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 5dcaea8bcd82972add29eef350547f922fb4caa2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Alex Bennée [Fri, 7 Mar 2025 10:08:21 +0000 (10:08 +0000)]
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.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20250204125009.2281315-7-peter.maydell@linaro.org Cc: qemu-stable@nongnu.org Cc: Andrei Homescu <ahomescu@google.com> Cc: Arve Hjønnevåg <arve@google.com> Cc: Rémi Denis-Courmont <remi.denis.courmont@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.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit f9f99d7ca522339c1de2292f132bb8ddc3471c39)
(Mjt: CP_ACCESS_UNDEFINED -> CP_ACCESS_TRAP_UNCATEGORIZED) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 7 Mar 2025 10:08:21 +0000 (10:08 +0000)]
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-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20250204125009.2281315-6-peter.maydell@linaro.org
(cherry picked from commit 02c648a0a103a1a7b2c077ec5a81da9907f45544)
(Mjt: context fix in target/arm/internals.h) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 7 Mar 2025 10:08:20 +0000 (10:08 +0000)]
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-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20250204125009.2281315-5-peter.maydell@linaro.org
(cherry picked from commit 4aecd4b442d7abb4355896d878ffc9b028625b01) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
projects / thirdparty / qemu.git / log
