page_check_range() may race with pageflags_set_clear() as follows:
T1 T2
------------------------------------- --------------------------------
p = pageflags_find(start, last);
interval_tree_remove(&p->itree, ...);
p->itree.start = last + 1;
if (start < p->itree.start) {
ret = false;
interval_tree_insert(&p->itree, ...);
leading to errors like
fail indirect write 0x72f0a659aff0 (Bad address)
in vma-pthread test. I am able to reliably reproduce this on a machine
with 32 SMT threads as follows in about 25 seconds:
jobs=32; \
seq "$jobs" | \
time -p parallel \
--jobs="$jobs" \
--halt=now,done=1 \
--ungroup \
'
_={};
while ./qemu-s390x tests/tcg/s390x-linux-user/vma-pthread; do
printf .;
done
'
Also wasmtime project reported a similar failure pattern in their CI [1]
with a similar reproducer [2].
There are other races like this. In general, region bounds mutating
underneath the reader are very hard to reason about. So fix this by
preventing mutations and creating copies instead. Use RCU guards in
readers to avoid uses-after-frees.
Now, when the reader finds a node, it may fearlessly access its fields
and be certain that at some point in time the respective region had the
respective bounds and permissions. The downside is slightly more
expensive mprotect(), but complexity reduction is worth it.
Lockless field accesses should probably be wrapped in qatomic_read(),
but this is a pre-existing issue, so do not change it here.
[1] https://github.com/bytecodealliance/wasmtime/issues/10000
[2] https://gist.github.com/alexcrichton/f14f23a892ffb9df2522754572d51b1c
Cc: qemu-stable@nongnu.org
Reported-by: Alex Crichton <alex@alexcrichton.com>
Reported-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Fixes: 67ff2186b0 ("accel/tcg: Use interval tree for user-only page tracking")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260706165445.57418-2-iii@linux.ibm.com>
In 6d03226b42 we set TLB_MMIO to a non-zero value for user-only
so that we could return a non-zero value from probe_* functions
so that we could force callers like Arm SVE vector moves to use
the slow path rather than direct access. All for the sake of
exposing these accesses to plugins.
Back then, TLB_FORCE_SLOW did not exist, so TLB_MMIO seemed like
a reasonable solution. However, user-only doesn't really have
MMIO and this has knock-on effects, like forcing Arm SVE first-fault
vector loads to stop. Better to use TLB_FORCE_SLOW as a more exact
trigger for plugins.
Cc: qemu-stable@nongnu.org
Fixes: 6d03226b42 ("plugins: force slow path when plugins instrument memory ops")
Acked-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260702171057.47998-1-richard.henderson@linaro.org>
Updates for hppa architecture for qemu v11.1
A few patches to fix TLB for HP-UX 9, and a lasi irq fix,
as well as a new SeaBIOS-hppa v25 firmware.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCakp8eQAKCRD3ErUQojoP
# X0S0AP9snfMLNer3zkojMLVsUNJtNUGmcRSNpmapiEN59lHRJwEAv30x2P3CnXLZ
# ObN+XV79pTNHtrBAGRYKHUtaLPddlgQ=
# =RRlH
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 05 Jul 2026 17:47:05 CEST
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: aka "Helge Deller <deller@debian.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'hppa-fixes-for-v11.1-pull-request' of https://github.com/hdeller/qemu-hppa:
target/hppa: Update SeaBIOS-hppa to version 25
hw/misc/lasi: derive IRR from pending and unmasked requests
target/hppa: Delay MMU update until TLB protection bits were set
target/hppa: Work-around for Fast TLB insert instruction on HP-UX 9
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Now accelerators hold the 'guest debug supported' information
in their state, accessible by the common code. No need to call
a per-accelerator handler, simply check for the SSTEP_ENABLE
in AccelGdbConfig::sstep_flags.
Remove all AccelOpsClass::supports_guest_debug implementations,
inline gdb_supports_guest_debug() and remove the now unnecessary
KVMState::have_guest_debug field.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260705215729.62196-18-philmd@oss.qualcomm.com>
Hold the per-accelerator AccelGdbConfig in AccelState, set its
single @sstep_flags field in AccelClass::init_machine handlers.
Remove the AccelClass::gdbstub_supported_sstep_flags() getter
and inline the single accel_supported_gdbstub_sstep_flags() call
in gdb_init_gdbserver_state().
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260705215729.62196-15-philmd@oss.qualcomm.com>
Processor features are stored in a union containing two "banks":
union hv_partition_processor_features {
uint64_t as_uint[2];
struct {
uint64_t sse3_support:1;
...
}
}
get_proc_features() to retrieve the 2nd bank was passing a pointer that
steps over the whole union (+16B) instead of picking the 2nd bank _in_
the union. This manifests in mismatching feature bits for the 2nd bank
and possibly other side-effects caused by writing beyond the union.
We need to step over the first bank (+8B) by using as_uint64[0/1] to
correct this behaviour.
Resolves: Coverity CID 1660876
Fixes: 2f6da91e8a ("accel/mshv: store partition proc features")
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Reviewed-by: Doru Blânzeanu <dblanzeanu@linux.microsoft.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20260701130335.418156-1-magnuskulke@linux.microsoft.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Currently we handle cp15.nsacr with raw bit numbers in the few places
we need to work with it. We're about to add some more uses of this
field, so define its fields with the FIELD macro and use the macros
in the places that were previously using bit numbers.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260702184019.3431139-5-peter.maydell@linaro.org
When an AArch32 Neon or VFP insn is trapped to AArch64 EL2, bits
[19:0] of the syndrome in ESR_EL2 are RES0. However, when it is
trapped to AArch32 EL2, the HSR syndrome information defines some
extra fields:
[5] : TA
[3:0] : coproc
where the TA bit is 1 for a trapped Neon insn and 0 for a trapped
VFP insn, and the coproc field is 0b1010 when TA is 0, and 0 when
TA is 1.
We attempted to address this in commit fa33eead ("target/arm: Add
coproc parameter to syn_fp_access_trap"), but got it wrong: we
thought the RES0 condition was "is v8A" rather than "is EL2 AArch32",
and we made all insns be TA=0 coproc = 0b1010 rather than only the
VFP ones. Correct the condition we use to decide the coproc and TA
fields. We set these fields unconditionally; later on in
arm_cpu_do_interrupt_aarch64() we will squash them to zero if we are
taking the exception to AArch64.
NB: there is some disagreement between different revisions of the
Arm ARM about the exact handling of 'coproc':
* the v8A Arm ARM text says coproc is 0b1010 when TA is 1
* the v8A Arm ARM pseudocode in AArch32_CheckFPAdvSIMDTrap()
sets coproc to 0b1010 when TA is 0
* the v7A Arm ARM text says coproc is 0b1010 when TA is 0
* the v7A Arm ARM pseudocode sets coproc to 0b1010 when TA is 0
The v7A Arm ARM pseudocode also disagrees with the v7A text, v8A text
and v8A pseudocode in only setting TA to 1 for traps caused by
HCPTR.TASE; the others set Ta for all trapped AdvSIMD insns
(i.e. including traps caused by HCPTR.TCP10).
We assume that the v8A pseudocode is incorrect about coproc (as it is
the odd one out) and that the v7A pseudocode is incorrect about when
TA is set (again, as it is the odd one out).
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/1153
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260702184019.3431139-4-peter.maydell@linaro.org
Currently we have one syn_fp_access_trap() which we use for fp
traps from A64 and from VFP and Neon A32. This means that A64
has to specify arguments that are always fixed for it (coproc
and is_16bit) and A32 can't specify arguments it needs to (TA).
Split it up into syn_a64_fp_access_trap() and
syn_a32_fp_access_trap(). This is a refactor with no
behavioural change.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260702184019.3431139-3-peter.maydell@linaro.org
Currently we use vfp_access_check() for AArch32 VFP and Neon
instructions. This is not quite right:
* there are optional CPACR.ASEDIS and HCPTR.TASE controls that allow
trapping of just the Neon and not VFP instructions
* Neon instructions are supposed to report a slightly different
syndrome in HCR when they trap to AArch32 EL2
As a preliminary refactor so we have somewhere we can make this
distinction, separate out Neon access checks into a separate
neon_access_check(), which initially just calls vfp_access_check().
The set of insns this needs to cover are those described in section
E1.3.9 of the DDI0487M.b Arm ARM. For us this corresponds to
everything in neon-dp.decode and neon-ls.decode and thus in
translate-neon.c, plus three insns that we handle in translate-vfp.c:
- VDUP (general-purpose register)
- VMOV (general-purpose register to scalar) byte and halfword
- VMOV (scalar to general-purpose register) byte and halfword
(which are the ones in that file with ARM_FEATURE_NEON checks).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260702184019.3431139-2-peter.maydell@linaro.org
