Now we made sure all helpers and helper_info are defined and used using
HELPER/HELPER_INFO macros, we are ready to introduce a target prefix.
We can't reuse TARGET_ARCH since it's not defined for common code, and
it's also poisoned. So introduce a new TARGET_ARCH_PREFIX which is
defined for all target code (whether it's common or target specific),
and use it as prefix.
On some hosts (found it on sparc), predefined macros exist for the base
architecture names we use, and their value is 1. (#define sparc 1). So,
we can't use them directly or it would create a illformed identifier for
function names. So to prevent any problem, use additional "target",
which gives -DTARGET_ARCH_PREFIX=target_<TARGET_ARCH>.
Finally there is one last catch: beyond target helpers, tcg also has
common helpers. For those ones, we want an empty prefix, since they are
defined on tcg side and not target side.
With this, we now have target prefixed helpers, preventing symbol
conflicts when linking targets together.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Link: https://lore.kernel.org/qemu-devel/20261024163249.77855-5-pierrick.bouvier@oss.qualcomm.com
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
There was a complex bug with gUSA wherein:
* decode_gusa calls gen_restart_exclusive
* gen_restart_exclusive generates code that sets TB_FLAG_GUSA_EXCLUSIVE
and generates a call to helper_exclusive
* when the code is executed, TB_FLAG_GUSA_EXCLUSIVE is set
* helper_exclusive calls cpu_loop_exit_atomic, this makes cpu_exec exit
with EXCP_ATOMIC
* we go to cpu_loop, we execute cpu_exec_step_atomic
* suppose that exit request is set, cpu_exec_step_atomic does nothing, it
leaves the CPU in the same state as it was before
* we go back to cpu_loop
* suppose that no signal is delivered, so the gUSA is not rewound
* cpu_loop goes to cpu_exec
* there is one difference - now, TB_FLAG_GUSA_EXCLUSIVE is set and it was
clear before - so cpu_exec will not use the TB that calls
helper_exclusive, it will instead use the TB that performs the atomic
operation (both of these TBs have the same PC, they only differ in flags)
* the TB that performs the atomic operation is executed inside cpu_exec
=> race condition
Fix the bug by managing the "are we in cpu_exec_step_atomic" flag
from cpu_exec_step_atomic itself, rather from the translator.
Cc: qemu-stable@nongnu.org
Fixes: 4bfa602bc2 ("target/sh4: Handle user-space atomics")
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Allow the two pages of translation to be non-contiguous.
As long as the target translator wraps pc properly, this
allows address space wraparound to function correctly.
This avoids an assert on a valid i386 system-mode test case.
Reported-by: Tao Cui <cui.tao@linux.dev>
Reviewed-by: Jim MacArthur <jim.macarthur@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
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>
Move the following TCG-specific cpu_loop_exit_*() declarations
out of the generic "exec/cpu-common.h" header, to the recently
created "accel/tcg/cpu-loop.h" one, documenting them:
- cpu_loop_exit_noexc()
- cpu_loop_exit_atomic()
- cpu_loop_exit_restore()
- cpu_loop_exit()
Include "accel/tcg/cpu-loop.h" where appropriate.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260617171438.75914-11-philmd@oss.qualcomm.com>
Move the TCG-specific cpu_restore_state() declaration out
of the generic "exec/cpu-common.h" header, to the recently
created "accel/tcg/cpu-loop.h" one.
Include "accel/tcg/cpu-loop.h" where appropriate.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260617171438.75914-8-philmd@oss.qualcomm.com>
Move the TCG-specific cpu_unwind_state_data() declaration out
of the generic "exec/cpu-common.h" header, to the recently
created "accel/tcg/cpu-loop.h" one.
Include "accel/tcg/cpu-loop.h" where appropriate.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260617171438.75914-7-philmd@oss.qualcomm.com>
Move the TCG-specific cpu_exec_step_atomic() declaration out
of the generic "exec/cpu-common.h" header, to the recently
created "accel/tcg/cpu-loop.h" one.
Include "accel/tcg/cpu-loop.h" where appropriate.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260617171438.75914-6-philmd@oss.qualcomm.com>
In order to keep TCG-specific functions under a TCG
API namespace, add the "accel/tcg/cpu-loop.h" header
and move cpu_exec() declaration to it. Add a bit of
documentation.
Include "accel/tcg/cpu-loop.h" where appropriate.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260617171438.75914-5-philmd@oss.qualcomm.com>
Since commit efe25c260c ("include/exec: Split out
accel/tcg/cpu-mmu-index.h") the "exec/cpu-common.h" isn't using
anything defined in "tcg/debug-assert.h".
Include it in target/loongarch/tcg/tcg_cpu.c however, where it
is required but included indirectly, otherwise we'd get:
target/loongarch/tcg/tcg_cpu.c:291:5: error: call to undeclared function 'tcg_debug_assert'
291 | tcg_debug_assert(!tcg_cflags_has(cs, CF_PCREL));
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260617160426.64461-5-philmd@oss.qualcomm.com>
The following cpu_physical_memory_*() methods do not involve any
vCPU but only access physical memory:
- cpu_physical_memory_read()
- cpu_physical_memory_write()
- cpu_physical_memory_map()
- cpu_physical_memory_unmap()
Rename them removing the 'cpu_' prefix, and move then to the
"system/physmem.h" header with the other methods involved in
global physical address space.
Mechanical change using sed, then adding missing headers manually.
No logical change intended.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260616020839.19104-7-philmd@oss.qualcomm.com>
Document the following methods use the global address space
and discard success/failure access information:
- cpu_physical_memory_read()
- cpu_physical_memory_write()
- cpu_physical_memory_map()
- cpu_physical_memory_unmap()
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260616020839.19104-2-philmd@oss.qualcomm.com>
With TCG_ADDRESS_BITS mechanism, it's now possible to specify which
variant every source file is written for. Compared to before, it means
that addr_type will now vary per tb translation, where it was constant
for a given target previously.
Thus, we add new a parameter to translator_loop().
This will allow us to convert targets one by one.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260407222208.271838-15-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
'CPUTLBEntryFull.xlat_section' stores section_index in last 12 bits to
find the correct section when CPU access the IO region over the IOTLB.
However, section_index is only unique inside single AddressSpace. If
address space translation is over IOMMUMemoryRegion, it could return
section from other AddressSpace. 'iotlb_to_section()' API only finds the
sections from CPU's AddressSpace so that it couldn't find section in
other AddressSpace. Thus, using 'iotlb_to_section()' API will find the
wrong section and QEMU will have wrong load/store access.
To fix this bug of iotlb_to_section(), store complete MemoryRegionSection
pointer in CPUTLBEntryFull to replace the section_index in xlat_section.
Rename 'xlat_section' to 'xlat' as we remove last 12 bits section_index
inside. Also, since we directly use section pointer in the
CPUTLBEntryFull (full->section), we can remove the unused functions:
iotlb_to_section(), memory_region_section_get_iotlb().
This bug occurs only when
(1) IOMMUMemoryRegion is in the path of CPU access.
(2) IOMMUMemoryRegion returns different target_as and the section is in
the IO region.
Common IOMMU devices don't have this issue since they are only in the
path of DMA access. Currently, the bug only occurs when ARM MPC device
(hw/misc/tz-mpc.c) returns 'blocked_io_as' to emulate blocked access
handling. Upcoming RISC-V wgChecker [1] and IOPMP [2] devices are also
affected by this bug.
[1] RISC-V WG:
https://patchew.org/QEMU/20251021155548.584543-1-jim.shu@sifive.com/
[2] RISC-V IOPMP:
https://patchew.org/QEMU/20250312093735.1517740-1-ethan84@andestech.com/
Signed-off-by: Jim Shu <jim.shu@sifive.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Mark Burton <mburton@qti.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-ID: <20260128152348.2095427-3-jim.shu@sifive.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Guard the native endian definitions we want to remove by surrounding
them with TARGET_NOT_USING_LEGACY_NATIVE_ENDIAN_API #ifdef'ry.
Once a target gets cleaned we'll set the definition in the
target config, then the target won't be able to use the legacy
API anymore.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260109165058.59144-20-philmd@linaro.org>
Guard the native endian APIs we want to remove by surrounding
them with TARGET_NOT_USING_LEGACY_NATIVE_ENDIAN_API #ifdef'ry.
Once a target gets cleaned we'll set the definition in the
target config, then the target won't be able to use the legacy
API anymore.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260109165058.59144-19-philmd@linaro.org>
Guard the native endian APIs we want to remove by surrounding
them with TARGET_NOT_USING_LEGACY_NATIVE_ENDIAN_API #ifdef'ry.
Once a target gets cleaned we'll set the definition in the
target config, then the target won't be able to use the legacy
API anymore.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260109165058.59144-18-philmd@linaro.org>
Currently we can not build files including "exec/watchpoint.h"
as meson common objects because the CONFIG_USER_ONLY definition
is poisoned. We can easily fix that by un-inlining the
user-emulation stubs.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-ID: <20260106231908.16756-5-philmd@linaro.org>
Move RAMBlock functions out of ram_addr.h and cpu-common.h;
move memory API headers out of include/exec and into include/system.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
For Arm, we need 3 cases: (1) the alignment required when accessing
Normal memory, (2) the alignment required when accessing Device memory,
and (3) the atomicity of the access.
When we added TLB_CHECK_ALIGNED, we assumed that cases 2 and 3 were
identical, and thus used memop_atomicity_bits for TLB_CHECK_ALIGNED.
This is incorrect for multiple reasons, including that the atomicity
of the access is adjusted depending on whether or not we are executing
within a serial context.
For Arm, what is true is that there is an underlying alignment
requirement of the access, and for that access Normal memory
will support unalignement.
Introduce MO_ALIGN_TLB_ONLY to indicate that the alignment
specified in MO_AMASK only applies when the TLB entry has
TLB_CHECK_ALIGNED set; otherwise no alignment required.
Introduce memop_tlb_alignment_bits with an additional bool
argument that specifies whether TLB_CHECK_ALIGNED is set.
All other usage of memop_alignment_bits assumes it is not.
Remove memop_atomicity_bits as unused; it didn't properly
support MO_ATOM_SUBWORD anyway.
Update target/arm finalize_memop_atom to set MO_ALIGN_TLB_ONLY
when strict alignment isn't otherwise required.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3171
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Set and clear PAGE_DONTDUMP, and honor that in vma_dump_size.
Signed-off-by: Jon Wilson <jonwilson030981@gmail.com>
[rth: Use new page_set_flags semantics; also handle DODUMP]
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Expand the interface of page_set_flags to separate the
set of flags to be set and the set of flags to be cleared.
This allows us to replace PAGE_RESET with the PAGE_VALID
bit within clear_flags.
Replace PAGE_TARGET_STICKY with TARGET_PAGE_NOTSTICKY;
aarch64-linux-user is the only user.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
