monitor: Do not check TARGET_I386 to build 'info sev' command
This command is filtered at build-time for i386/x86_64 binaries.
By using the recently introduced HMPCommand::arch_bitmask flag
we can filter it at runtime, making it possible to compile
hmp-commands-info.hx once.
Since the method depends on the CONFIG_SEV definition, define it
in its own stub file.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260427080738.77138-17-philmd@linaro.org>
monitor: Do not check TARGET_I386 to build 'info sgx' command
This command is filtered at build-time for i386/x86_64 binaries.
By using the recently introduced HMPCommand::arch_bitmask flag
we can filter it at runtime, making it possible to compile
hmp-commands-info.hx once.
Since the method depends on the CONFIG_SGX definition, define it
in its own stub file.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260427080738.77138-16-philmd@linaro.org>
monitor: Do not check TARGET_I386 to build target/i386/ commands
These commands are filtered at build-time for i386/x86_64 binaries.
By using the recently introduced HMPCommand::arch_bitmask flag
we can filter them at runtime, making it possible to compile
hmp-commands[-info].hx files once.
Since these methods are used inconditionally within target/i386/,
define them in the same stub file.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260427080738.77138-15-philmd@linaro.org>
monitor: Do not check TARGET_S390X to build s390x commands
These commands are filtered at build-time for s390x binary.
By using the recently introduced HMPCommand::arch_bitmask flag
we can filter them at runtime, making it possible to compile
hmp-commands[-info].hx files once.
Since the methods are used inconditionally within hw/s390x/,
define them in the same stub file.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20260427080738.77138-14-philmd@linaro.org>
We want to make the HMP commands available for all targets,
move the declarations to "monitor/hmp.h" where all other
are, and only include the monitor headers in the source files.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20260427080738.77138-13-philmd@linaro.org>
Add the @arch_bitmask field to the HMPCommand structure,
allowing to restrict a command to a set of target
architectures (represented by the QEMU_ARCH_* enum constants).
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260427080738.77138-12-philmd@linaro.org>
system: Expose 'arch_init.h' as 'qemu/base-arch-defs.h'
We already have a file unit outside of the local system'
folder which include "system/arch_init.h". We want more files
to use it, so make it official it is a generic header by moving
it under include. Rename as "qemu/base-arch-defs.h" which is
more descriptive.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260427080738.77138-11-philmd@linaro.org>
In order to build hmp-commands.hx once we need to stop using
device target-specific check. Use the generic pattern to make
the command available on all targets, providing a stub with
kind error message when the feature is not available.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260427080738.77138-10-philmd@linaro.org>
In order to build hmp-commands-info.hx once we need to stop
using device target-specific check. Use the generic pattern
to make the command available on all targets, providing a
stub with kind error message when the device is not available.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260427080738.77138-9-philmd@linaro.org>
As mentioned in commit 755f196898e ("qapi: Convert the cpu
command") 15 years ago, the monitor_set_cpu() method is a
temporary bridge between QMP -> HMP and shouldn't be used
elsewhere. Make its scope internal to monitor/.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260427080738.77138-8-philmd@linaro.org>
monitor/meson: Use SPICE with migration HMP commands
When moving code around in commit 27be86351ec ("migration: Move
the QMP command from monitor/ to migration/") we forgot to update
the meson rule about SPICE pkg-config flags.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260427080738.77138-7-philmd@linaro.org>
We use 'HMP' for Human monitor and 'QMP' for 'Machine protocol'.
These files aren't about human monitor but QMP, so rename them
for clarity using the 'qmp-' prefix instead of 'monitor-'.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20260427080738.77138-6-philmd@linaro.org>
target/mips: Check alignment for microMIPS pre-R6 LD/ST multiple
Pre-REL6 microMIPS requires alignment while REL6 microMIPS does not.
Use @default_tcg_memop_mask in gen_ldst_multiple(), it is set to
MO_UNALN for REL6 but MO_ALIGN for pre-REL6.
Fixes: 3c824109da0 ("target-mips: microMIPS ASE support") Reported-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260417035734.32334-5-philmd@linaro.org>
target/mips: Inline cpu_ld/st_mmuidx_ra() calls in LD/ST Multiple
In preparation of removing the cpu_ld*_mmuidx_ra() and
cpu_st*_mmuidx_ra() calls, inline them. Expand MO_TE to
mo_endian_env(env) in gen_ldst_multiple().
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260417035734.32334-4-philmd@linaro.org>
target/mips: Remove unnecessary target_ulong uses in LD/ST Multiple
@do_r31 is a boolean, @base_reglist an unsigned size
and @i an unsigned index.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260417035734.32334-3-philmd@linaro.org>
target/mips: Pass MemOpIdx argument to Load/Store Multiple helpers
In preparation of using the MemOp content in the next commit,
pass it as MemOpIdx. Include the access size.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260417035734.32334-2-philmd@linaro.org>
target/i386: Replace target_ulong -> uint64_t for TARGET_X86_64
These registers are only available on 64-bit builds, thus
always handled as 64-bit. This isn't even a migration break
because they are migrated as 64-bit since the beginning
(see commit 02536f8b1f9 "x86_64 save/restore").
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng>
Message-Id: <20260315165319.39727-1-philmd@linaro.org>
Commits f50d0f335a6 and a522b04bb9c ("target/riscv,i386: Remove
AccelCPUClass::cpu_class_init need") removed the last uses of
the CPUClass::init_accel_cpu hook. Remove it as unused.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260412212547.29645-1-philmd@linaro.org>
VMSTATE_VARRAY_MULTIPLY() seems to be an "optimized" version
of VMSTATE_UINTTL_ARRAY(), and is only used once. Prefer the
generic macro. Bump the SPARC CPU migration stream version.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260325211728.89204-10-philmd@linaro.org>
target/avr: Avoid target-specific migration headers in machine.c
machine.c doesn't use any target-specific macro defined by
the "migration/cpu.h" header. Use the minimum headers required:
"migration/qemu-file-types.h" and "migration/vmstate.h", which
are not target-specific. This allows to build this file as
common object.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260325211728.89204-2-philmd@linaro.org>
target/loongarch: Avoid target-specific migration headers in machine.c
machine.c doesn't use any target-specific macro defined by
the "migration/cpu.h" header. Use the minimum header required:
"migration/qemu-file-types.h" which is not target-specific.
This allows to build this file as common object.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260325211728.89204-3-philmd@linaro.org>
configs/targets: Restrict the legacy ldst_phys() API on LoongArch64
The LoongArch64 target doesn't use the legacy ldst_phys() API
anymore. Set the TARGET_NOT_USING_LEGACY_LDST_PHYS_API variable
to hide the legacy API to the qemu-system-loongarch64 binary,
avoiding further API uses to creep in.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng>
Message-Id: <20260319104944.66690-3-philmd@linaro.org>
Prefer the address_space_ld/st API over the legacy ld/st_phys()
because it allow checking for bus access fault (although the
modified code doesn't check that). There is no logical change.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng>
Message-Id: <20260319104944.66690-2-philmd@linaro.org>
monitor: Remove MonitorDef::type field and MD_TLONG / MD_I32
None of the few targets still using MonitorDef use MD_TLONG,
they either use MD_I32 or the %get_value handler. Remove the
MonitorDef::type and its definitions altogether: simply check
for the %get_value handler, if NULL then consider 32-bit.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260320091019.59902-3-philmd@linaro.org>
hash32_load_hpte() helpers are only used within mmu-hash32.c,
no need to have each file including "mmu-hash32.h" to compile
them. Move their definition to this source file.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Message-Id: <20260319111936.68041-5-philmd@linaro.org>
Peter Maydell [Tue, 17 Mar 2026 17:50:30 +0000 (17:50 +0000)]
target/mips: Move count_clock to MIPSCPU struct
The count_clock pointer is not something we can do a shallow copy of,
as linux-user cpu_copy() does, and although it is a system-mode piece
of state we unconditionally create it, so it is present also in
user-mode.
There isn't any need to keep this in the env struct rather than the
CPU struct, so move it to avoid possible memory leaks or
double-usage. This also puts it next to the other Clocks that this
CPU has.
I haven't seen any sanitizer reports about this field, so this is
averting a possible problem rather than correcting an observed one.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260317175031.3035740-4-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Peter Maydell [Tue, 17 Mar 2026 17:50:29 +0000 (17:50 +0000)]
target/mips: Free mvp in unrealize
We allocate memory for cpu->mvp in mips_cpu_realizefn(), but we
never free it, which causes memory leaks like this:
Direct leak of 24 byte(s) in 2 object(s) allocated from:
#0 0x5f9458e61c8d in calloc (/home/pm215/qemu/build/san/qemu-mips+0x4d8c8d) (BuildId: 4153e33b3d08657a71ce2a04a82d0c2954966d9c)
#1 0x74761891a771 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x63771) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3)
#2 0x5f94590687aa in mvp_init /home/pm215/qemu/build/san/../../target/mips/cpu-defs.c.inc:1037:16
#3 0x5f94590687aa in mips_cpu_realizefn /home/pm215/qemu/build/san/../../target/mips/cpu.c:489:5
#4 0x5f9459366a3a in device_set_realized /home/pm215/qemu/build/san/../../hw/core/qdev.c:523:13
#5 0x5f9459380a49 in property_set_bool /home/pm215/qemu/build/san/../../qom/object.c:2376:5
#6 0x5f945937bace in object_property_set /home/pm215/qemu/build/san/../../qom/object.c:1450:5
#7 0x5f945938816c in object_property_set_qobject /home/pm215/qemu/build/san/../../qom/qom-qobject.c:28:10
#8 0x5f94592cc100 in cpu_copy /home/pm215/qemu/build/san/../../linux-user/main.c:240:25
#9 0x5f9459309931 in do_syscall1 /home/pm215/qemu/build/san/../../linux-user/syscall.c
#10 0x5f94593058d8 in do_syscall /home/pm215/qemu/build/san/../../linux-user/syscall.c:14422:15
#11 0x5f945905c73e in cpu_loop /home/pm215/qemu/build/san/../../linux-user/mips/cpu_loop.c:124:23
for linux-user, where each new guest thread is a new CPU object that
we need to destroy on thread exit.
Add an unrealize method which frees this memory.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260317175031.3035740-3-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Peter Maydell [Tue, 17 Mar 2026 17:50:28 +0000 (17:50 +0000)]
target/mips: Move 'mvp' field from CPUMIPSState to MIPSCPU
The 'mvp' field in the CPUMIPSState is a pointer to memory allocated
in mvp_init(). This is in theory fine, but in practice it clashes
with the current linux-user implementation of cpu_copy(), which
assumes it can do a shallow memcpy() copy of the CPU env struct in
order to clone the CPU when creating a new thread.
Almost all of the MIPS env struct is actually memcpy() copyable;
one of the exceptions is the mvp pointer. We don't need this
to be in the env struct; move it to the CPU object struct instead.
At the moment the memcpy() of the env->mvp pointer doesn't have any
obvious ill-effects, because we never free the memory and it
doesn't contain anything that varies at runtime for user-mode.
So thread 2 ends up pointing at thread 1's mvp struct, but it
still works OK. However, we would like to free the mvp memory to
avoid a leak when a user-mode thread exits, and unless we avoid
the shallow copy this will end up with a double-free when both
thread 1 and thread 2 free the same mvp struct.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260317175031.3035740-2-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
target/cpu: Do not include 'exec/cpu-defs.h' anymore
Nothing in all our target "cpu.h" directly uses definitions
from "exec/cpu-defs.h": no need to include it there. This
remove a lot of target-specificities, simplifying inclusion
of target "cpu.h" by common code.
target/s390x/tcg: Include missing '*cpu.h' headers
The "hw/core/cpu.h" header (declaring run_on_cpu_data) and
"target/s390x/cpu.h" are indirectly included. Include them
explicitly otherwise we get when refactoring unrelated headers:
../target/s390x/tcg/tcg_s390x.h:17:44: error: unknown type name 'CPUS390XState'; did you mean 'CPUSH4State'?
17 | G_NORETURN void tcg_s390_program_interrupt(CPUS390XState *env,
| ^~~~~~~~~~~~~
| CPUSH4State
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260313062055.2188-18-philmd@linaro.org>
target/sparc: Include missing 'exec/target_long.h' header
The "exec/target_long.h" header is indirectly included, pulled
via "exec/cpu-defs.h". Include it explicitly otherwise we'd get
when removing the latter:
../target/sparc/cpu.h:615:1: error: unknown type name 'target_ulong'
615 | target_ulong cpu_get_fsr(CPUSPARCState *);
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260313062055.2188-15-philmd@linaro.org>
target/riscv: Include missing 'exec/target_long.h' header
The "exec/target_long.h" header is indirectly included, pulled
via "exec/cpu-defs.h". Include it explicitly otherwise we'd get
when removing the latter:
../target/riscv/cpu.h:605:1: error: unknown type name ‘target_ulong’
605 | target_ulong riscv_cpu_get_geilen(CPURISCVState *env);
| ^~~~~~~~~~~~
../target/riscv/pmp.h:73:1: error: unknown type name 'target_ulong'
73 | target_ulong mseccfg_csr_read(CPURISCVState *env);
| ^
../target/riscv/debug.h:139:1: error: unknown type name 'target_ulong'
139 | target_ulong tselect_csr_read(CPURISCVState *env);
| ^
../hw/misc/riscv_cmgcr.c:112:15: error: unknown type name 'target_ulong'
112 | static inline target_ulong get_exception_base(RISCVGCRVPState *vps)
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260313062055.2188-14-philmd@linaro.org>
target/ppc: Include missing 'exec/target_long.h' header
The "exec/target_long.h" header is indirectly included, pulled
via "exec/cpu-defs.h". Include it explicitly otherwise we'd get
when removing the latter:
target/ppc/cpu.h:1281:5: error: unknown type name 'target_ulong'
1281 | target_ulong gpr[32]; /* general purpose registers */
| ^
hw/ppc/spapr_ovec.h:76:44: error: unknown type name 'target_ulong'
76 | SpaprOptionVector *spapr_ovec_parse_vector(target_ulong table_addr, int vector);
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260313062055.2188-13-philmd@linaro.org>
target/mips: Include missing 'exec/target_long.h' header
The "exec/target_long.h" header is indirectly included, pulled
via "exec/cpu-defs.h". Include it explicitly otherwise we'd get
when removing the latter:
target/mips/cpu.h:462:5: error: unknown type name 'target_ulong'
462 | target_ulong gpr[32];
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260313062055.2188-12-philmd@linaro.org>
target/m68k: Include missing 'exec/target_long.h' header
The "exec/target_long.h" header is indirectly included, pulled
via "exec/cpu-defs.h". Include it explicitly otherwise we'd get
when removing the latter:
../target/m68k/m68k-semi.c:53:5: error: use of undeclared identifier 'target_ulong'
53 | target_ulong args = env->dregs[1];
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260313062055.2188-11-philmd@linaro.org>
target/i386: Include missing 'exec/target_long.h' header
The "exec/target_long.h" header is indirectly included, pulled
via "exec/cpu-defs.h". Include it explicitly otherwise we'd get
when removing the latter:
../target/i386/cpu.h:2777:43: error: unknown type name 'target_ulong'
2777 | void cpu_x86_update_cr3(CPUX86State *env, target_ulong new_cr3);
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260313062055.2188-10-philmd@linaro.org>
target/hppa: Include missing 'exec/target_long.h' header
The "exec/target_long.h" header is indirectly included, pulled
via "exec/cpu-defs.h". Include it explicitly otherwise we'd get
when removing the latter:
target/hppa/cpu.h:375:1: error: unknown type name 'target_ulong'
375 | target_ulong cpu_hppa_get_psw(CPUHPPAState *env);
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260313062055.2188-9-philmd@linaro.org>
target/hexagon: Include missing 'exec/target_long.h' header
The "exec/target_long.h" header is indirectly included, pulled
via "exec/cpu-defs.h". Include it explicitly otherwise we'd get
when removing the latter:
../target/hexagon/cpu.h:76:5: error: unknown type name ‘target_ulong’
76 | target_ulong gpr[TOTAL_PER_THREAD_REGS];
| ^~~~~~~~~~~~
../target/hexagon/mmvec/mmvec.h:69:5: error: unknown type name ‘target_ulong’
69 | target_ulong va[MAX_VEC_SIZE_BYTES];
| ^~~~~~~~~~~~
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260313062055.2188-8-philmd@linaro.org>
The "exec/target_long.h" header is indirectly included, pulled
via "cpu.h" -> "exec/cpu-defs.h". Include it explicitly otherwise
we'd get when removing the latter:
../target-info-stub.c:39:23: error: use of undeclared identifier 'TARGET_PAGE_BITS'
39 | .page_bits_init = TARGET_PAGE_BITS,
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260313062055.2188-6-philmd@linaro.org>
monitor/hmp: : Include missing 'exec/target_long.h' header
The "exec/target_long.h" header is indirectly included, pulled
via "cpu.h" -> "exec/cpu-defs.h". Include it explicitly otherwise
we'd get when removing the latter:
monitor/hmp-target.h:35:5: error: type name requires a specifier or qualifier
35 | target_long (*get_value)(Monitor *mon, const struct MonitorDef *md,
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260427080738.77138-2-philmd@linaro.org>
The generation of the guest workloads for migration-test is all
broken:
1) We moved code around and forgot to update the includes from the guest
workloads at qtest/migration/<ARCH>/.
2) Since this code doesn't build by default due to the need for cross
compilation, we also broke the s390x code entirely by removing the
libc implementation from sclp.c.
3) The build adds a blank line at the end of the header files due to
how the sed command used to remove extra variable declarations is
written.
4) Must be too long since we last built this thing that powerpc
compilers would output BE by default. Nowadays we need -mbig-endian to
force it.
5) Format of comments needs fixing to please checkpatch.
Fix everything. Most changes are trivial, except for s390x where I had
to reimplement some of the routines from sclp.c. Compiling that object
file in doesn't work because of its various includes that this
standalone code can't provide.
Testing this change (assuming x86 host):
$ cd build
$ pushd tests/qtest/migration
$ make clean
$ make i386
$ make CROSS_PREFIX=your-favorite-cross-compiler- s390x
$ make CROSS_PREFIX=your-favorite-cross-compiler- aarch64
$ make CROSS_PREFIX=your-favorite-cross-compiler- ppc64
$ popd
$ make -j$(nproc) # must build the tests again
$ QTEST_QEMU_BINARY=./qemu-system-<ARCH> migration-test
Fixes: 9f4278837d ("pc-bios/s390-ccw: Use the libc from SLOF and remove sclp prints") Fixes: e1803dabdc ("tests/qtest/migration: Move common test code") Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20260429231025.30818-1-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
CJ Chen [Tue, 28 Apr 2026 09:33:39 +0000 (10:33 +0100)]
system/memory: assert on invalid MemoryRegionOps .unaligned combo
When it comes to this pattern: .valid.unaligned = false and
impl.unaligned = true, is effectlvely contradictory. The .valid
structure indicates that unaligned access should be rejected at
the access validation phase, yet .impl suggests the underlying
device implementation can handle unaligned operations. As a result,
the upper-layer code will never even reach the .impl logic.
Add an assertion that the MemoryRegionOps doesn't specify
this invalid combination.
Signed-off-by: CJ Chen <cjchen@igel.co.jp> Tested-by: CJ Chen <cjchen@igel.co.jp> Suggested-by: Peter Xu <peterx@redhat.com> Acked-by: Tomoyuki Hirose <hrstmyk811m@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
[PMM: tweaked commit message] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Link: https://lore.kernel.org/r/20260428093339.2087081-5-peter.maydell@linaro.org Signed-off-by: Peter Xu <peterx@redhat.com>
The xtensa mx-pic interrupt controller has a rather odd register
setup, where some registers are 32 bits but are decoded at offsets
only one apart from each other. The QEMU implementation handles this
correctly, but it did not set .impl.unaligned = true. This has
worked up til now because QEMU has entirely ignored .impl.unaligned,
and just allowed through unaligned accesses when
.valid.unaligned is set.
To allow the possibility of properly implementing synthesis of
unaligned accesses by the memory subsystem when they are valid but
the device doesn't implement them, and for clarity of intention,
state explicitly that this MR's read and write functions directly
handle unaligned accesses, by setting .impl.unaligned = true.
While we are adjusting the MemoryRegionOps, we set also the minimum
and maximum allowed access sizes. Since the only way to get at this
device is via the CPU's RER and WER instructions, which always
operate at 32-bit sizes (see the HELPER(rer) and HELPER(wer)
functions in target/xtensa/op_helper.c), we know we will always get
32-bit accesses. Specify explicitly that that is what is valid and
implemented for the MR.
Add a comment to clarify that the hardware behaviour here is not
"true memory-mapped registers", so the odd-looking implementation is
correct.
Peter Maydell [Tue, 28 Apr 2026 09:33:37 +0000 (10:33 +0100)]
hw/npcm7xx_fiu: Specify .impl for npcm7xx_fiu_flash_ops
Currently npcm7xx_fiu_flash_ops provides no .impl substruct; this
means that it gets the default of "implements 1, 2 and 4 byte aligned
accesses". This is more constrained than the device permits in its
.valid substruct, and also narrower than the functions are written to
handle.
Add a .impl substruct matching the .valid substruct; this means that
all guest accesses are handled directly by the read and write
functions, and are never synthesized by the memory subsystem
performing multiple accesses to the device (which would not behave
correctly, as these read and write fucntions have side effects).
The riscv_iommu_trap_ops MemoryRegionOps specifies that
unaligned accesses are not valid for this device but that
it does implement them. This doesn't make much sense, and
we want to add an assertion that registered MRs don't specify
this invalid combination of settings.
Drop .impl.unaligned = true, with no behaviour change.
Signed-off-by: CJ Chen <cjchen@igel.co.jp> Acked-by: Tomoyuki Hirose <hrstmyk811m@gmail.com> Reported-by: Tomoyuki Hirose <hrstmyk811m@gmail.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
[PMM: reworded commit message] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/r/20260428093339.2087081-2-peter.maydell@linaro.org Signed-off-by: Peter Xu <peterx@redhat.com>
Peter Xu [Tue, 21 Apr 2026 20:21:09 +0000 (16:21 -0400)]
migration/qapi: Update unit for avail-switchover-bandwidth
Add ", in bytes per second". Unfortunately indentations need to be updated
completely, but no change on the rest.
Cc: Markus Armbruster <armbru@redhat.com> Suggested-by: Juraj Marcin <jmarcin@redhat.com> Reviewed-by: Juraj Marcin <jmarcin@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Link: https://lore.kernel.org/r/20260421202110.306051-16-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
Currently, mgmt can only query for remaining RAM using QMP command
"query-migrate" and monitor the "ram" section. There's no way to report
system-wide remaining data including VFIO devices. It was not a problem
before, because for a very long time RAM was the only part that matters.
After VFIO migrations landed upstream, it may not be enough. There can be
GPU devices that contain GBs of device states. Mgmt may want to know how
much remaining for special devices like VFIO, because all of them will be
accounted as VM data to migrate and will contribute to downtime in the
switchover phase.
Add a new "remaining" field in query-migrate results on the top level,
reflecting system-wide remaining data, which will include everything like
VFIO devices.
This information will be useful for mgmt to implement generic way of stall
detection that covers all system resources. For example, when system-wide
remaining data (especially, if sampled right after each migration
iteration) does not decrease anymore for a relatively long period of time,
then it may imply there is a challenge of converging, mgmt can react based
on how this value changes over time.
Before this patch, "expected_downtime" almost played this role. For
example, by monitoring "expected_downtime" at the beginning of each
iteration can in most cases also reflect the progress of migration
system-wide.
Said that, "expected_downtime" was always calculated based on a bandwidth
value that can fluctuate if avail-switchover-bandwidth is not used. This
new "remaining" field will remove that part of uncertainty for mgmt no
matter if avail-switchover-bandwidth is used by the mgmt.
With the new field, HMP "info migrate" now reports this:
(qemu) info migrate
Status: active
Time (ms): total=12080, setup=14, exp_down=300
Remaining: 1.36 GiB <--- this is the new line
RAM info:
Throughput (Mbps): 840.50
Sizes: pagesize=4 KiB, total=4.02 GiB
Transfers: transferred=1.18 GiB, remain=1.36 GiB
Channels: precopy=1.18 GiB, multifd=0 B, postcopy=0 B
Page Types: normal=307923, zero=388148
Page Rates (pps): transfer=25660
Others: dirty_syncs=1
When VFIO is not involved, the value reported in the new field should be
approximately the same as reported in the "remaining" field of the RAM
section. It is only approximately because the system-wide remaining data
is a cached value, which gets frequently updated by migration core. OTOH,
the RAM's remaining data is accurate.
When VFIO is involved, the new value reported should normally be larger,
because it will include the size of VFIO remaining data too.
Cc: Aseef Imran <aimran@redhat.com> Reviewed-by: Juraj Marcin <jmarcin@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI schema Link: https://lore.kernel.org/r/20260421202110.306051-15-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
Peter Xu [Tue, 21 Apr 2026 20:21:07 +0000 (16:21 -0400)]
migration: Remember total dirty bytes in mig_stats
Introduce this new counter to remember the total dirty bytes for the whole
system. It will be used for query-migrate command to fetch system-wise
remaining data.
A prior attempt was made to not use this counter but query directly from
all the modules in a QMP handler, but it exposed some complexity not only
on migration state machine race conditions (where the query may be invoked
anytime of the state machine), or on locking implications (where some of
the query hooks may take BQL, which is illegal at least in a QMP handler).
For more information, see:
This oneliner will resolve everything, except that it is not as accurate.
The hope is it is a worthwhile trade-off solution, after knowing above
challenges.
Now, there is one more reason we should make each invocation of
save_live_iterate() to be lightweight, because this counter will only get
updated once for each loop over all save_live_iterate() hooks when present.
But that's always the goal.
Peter Xu [Tue, 21 Apr 2026 20:21:06 +0000 (16:21 -0400)]
migration: Fix calculation of expected_downtime to take VFIO info
QEMU will provide an expected downtime for the whole system during
migration, by remembering the total dirty RAM that we synced the last time,
divides the estimated switchover bandwidth.
That was flawed when VFIO is taking into account: consider there is a VFIO
GPU device that contains GBs of data to migrate during stop phase. Those
will not be accounted in this math.
Fix it by updating dirty_bytes_last_sync properly only when we go to the
next iteration, rather than hide this update in the RAM code. Meanwhile,
fetch the total (rather than RAM-only) portion of dirty bytes, so as to
include GPU device states too.
Update the comment of the field to reflect its new meaning.
Now after this change, the expected-downtime to be read from query-migrate
should be very accurate even with VFIO devices involved.
Peter Xu [Tue, 21 Apr 2026 20:21:05 +0000 (16:21 -0400)]
migration: Calculate expected downtime on demand
This value does not need to be calculated as frequent. Only calculate it
on demand when query-migrate happened. With that we can remove the
variable in MigrationState.
This paves way for fixing this value to include all modules (not only RAM
but others too).
Peter Xu [Tue, 21 Apr 2026 20:21:03 +0000 (16:21 -0400)]
migration: Move iteration counter out of RAM
It used to hide in RAM dirty sync path. Now with more modules being able
to slow sync on dirty information, keeping it there may not be good anymore
because it's not RAM's own concept for iterations: all modules should
follow.
More importantly, mgmt may try to query dirty info (to make policy
decisions like adjusting downtime) by listening to iteration count changes
via QMP events. So we must make sure the boost of iterations only happens
_after_ the dirty sync operations with whatever form (RAM's dirty bitmap
sync, or VFIO's different ioctls to fetch latest dirty info from kernel).
Move this to core migration path to manage, together with the event
generation, so that it can be well ordered with the sync operations for all
modules.
This brings a good side effect that we should have an old issue regarding
to cpu_throttle_dirty_sync_timer_tick() which can randomly boost iteration
counts (because it invokes sync ops). Now it won't, which is actually the
right behavior.
Said that, we have code (not only QEMU, but likely mgmt too) assuming the
1st iteration will always shows dirty count to 1. Make it initialized with
1 this time, because we'll miss the dirty sync for setup() on boosting this
counter now.
Peter Xu [Tue, 21 Apr 2026 20:21:02 +0000 (16:21 -0400)]
vfio/migration: Fix incorrect reporting for VFIO pending data
VFIO reports different things in its fast/slow version of query pending
results. It was because it wants to make sure precopy data can reach 0,
which is needed to make sure sync queries will happen periodically over
time.
Now with stopcopy size reporting facility it doesn't need this hack
anymore. Fix this by reporting the same values in fast/slow versions of
query pending request, except that the slow version will do a slow sync
with the hardwares.
When at it, removing the special casing for vfio_device_state_is_precopy()
which may reporting nothing in a fast query. Then ther reporting will be
consistent to VFIO devices that do not support precopy phase.
Copy stable might be too much; just skip it and skip the Fixes.
Peter Xu [Tue, 21 Apr 2026 20:21:01 +0000 (16:21 -0400)]
migration: Introduce stopcopy_bytes in save_query_pending()
Allow modules to report data that can only be migrated after VM is stopped.
When this concept is introduced, we will need to account stopcopy size to
be part of pending_size as before.
However, when there're data only can be migrated in stopcopy phase, it
means the old "pending_size" may not always be able to reach low enough to
kickoff an slow version of query sync.
It used to be almost guaranteed to happen as all prior iterative modules
doesn't have stopcopy only data. VFIO may change that fact by having some
data that must be copied during stop phase.
So we need to make sure QEMU will kickoff a synchronized version of query
pending when all precopy data is migrated. This might be important to VFIO
to keep making progress even if the downtime cannot yet be satisfied.
So far, this patch should introduce no functional change, as no module yet
report stopcopy size.
This paves way for VFIO to properly report its pending data sizes, which
will start to include stop-only data.
Peter Xu [Tue, 21 Apr 2026 20:21:00 +0000 (16:21 -0400)]
migration: Use the new save_query_pending() API directly
It's easier to use the new API directly in the migration iterations. This
also paves way for follow up patches to add new data to report directly to
the iterator function.
These two APIs are a slight duplication. For example, there're a few users
that directly pass in the same function.
It might also be error prone to provide two hooks, so that it's easier to
happen one module report different things via the two hooks.
In reality, they should always report the same thing, only about whether we
should use a fast-path when the slow path might be too slow, as QEMU may
query these information quite frequently during migration process.
Merge it into one API, provide a bool showing if the query is an exact
query or not. No functional change intended.
Export qemu_savevm_query_pending(). We should use the new API here
provided when there're new users to do the query. This will happen very
soon.
Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Eric Farman <farman@linux.ibm.com> Cc: Matthew Rosato <mjrosato@linux.ibm.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Ilya Leoshkevich <iii@linux.ibm.com> Cc: David Hildenbrand <david@kernel.org> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Cc: John Snow <jsnow@redhat.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Juraj Marcin <jmarcin@redhat.com> Reviewed-by: Avihai Horon <avihaih@nvidia.com> Acked-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Link: https://lore.kernel.org/r/20260421202110.306051-6-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
Peter Xu [Tue, 21 Apr 2026 20:20:58 +0000 (16:20 -0400)]
vfio/migration: Cache stop size in VFIOMigration
Add a field to cache stop size. Note that there's an initial value change
in vfio_save_setup for the stop size default, but it shouldn't matter if it
is followed with a math of MIN() against VFIO_MIG_DEFAULT_DATA_BUFFER_SIZE.
Document that all the three sizes we read from VFIO's uAPI on dirty or stop
sizes are estimates, so QEMU needs to always remember they can be anything.
Peter Xu [Tue, 21 Apr 2026 20:20:57 +0000 (16:20 -0400)]
migration/qapi: Rename MigrationStats to MigrationRAMStats
This stats is only about RAM, make it accurate. This paves way for
statistics for all devices.
Thanks to Markus, who pointed out that docs/devel/qapi-code-gen.rst has a
section "Compatibility considerations" stated:
Since type names are not visible in the Client JSON Protocol, types
may be freely renamed. Even certain refactorings are invisible, such
as splitting members from one type into a common base type.
Hence this change is not ABI violation according to the document.
While at it, touch up the lines to make it read better, correct the
restriction on migration status being 'active' or 'completed': over time we
grew too many new status that will also report "ram" section.
Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: devel@lists.libvirt.org Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Juraj Marcin <jmarcin@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Link: https://lore.kernel.org/r/20260421202110.306051-4-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
Peter Xu [Tue, 21 Apr 2026 20:20:56 +0000 (16:20 -0400)]
migration: Fix low possibility downtime violation
When QEMU queried the estimated version of pending data and thinks it's
ready to converge, it'll send another accurate query to make sure of it.
It is needed to make sure we collect the latest reports and that equation
still holds true.
However we missed one tiny little difference here on "<" v.s. "<=" when
comparing pending_size (A) to threshold_size (B)..
QEMU src only re-query if A<B, but will kickoff switchover if A<=B.
I think it means it is possible to happen if A (as an estimate only so far)
accidentally equals to B, then re-query won't happen and switchover will
proceed without considering new dirtied data.
It turns out it was an accident in my commit 7aaa1fc072 when refactoring
the code around. Fix this by using the same equation in both places.
Fixes: 7aaa1fc072 ("migration: Rewrite the migration complete detect logic") Cc: qemu-stable@nongnu.org Reviewed-by: Juraj Marcin <jmarcin@redhat.com> Link: https://lore.kernel.org/r/20260421202110.306051-3-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
Samuel Zhang [Mon, 27 Apr 2026 03:14:01 +0000 (11:14 +0800)]
migration/rdma: add x-rdma-chunk-size parameter
The default 1MB RDMA chunk size causes slow live migration because
each chunk triggers a write_flush (ibv_post_send). For 8GB RAM,
1MB chunk size produces ~15000 flushes vs ~3700 with 1024MB chunk size.
Add x-rdma-chunk-size parameter to configure the RDMA chunk size for
faster migration.
Usage: `migrate_set_parameter x-rdma-chunk-size 1024M`
Performance with RDMA live migration of 8GB RAM VM:
Signed-off-by: Samuel Zhang <guoqing.zhang@amd.com> Acked-by: Markus Armbruster <armbru@redhat.com> Acked-by: Li Zhijian <lizhijian@fujitsu.com> Tested-by: Li Zhijian <lizhijian@fujitsu.com> Acked-by: Fabiano Rosas <farosas@suse.de> Acked-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20260427031401.3895523-1-guoqing.zhang@amd.com Signed-off-by: Peter Xu <peterx@redhat.com>
migration: Use QAPI_CLONE_MEMBERS in migrate_params_test_apply
Use QAPI_CLONE_MEMBERS instead of making an assignment. The QAPI
method makes the handling of the TLS strings more intuitive because it
clones them as well.
This also fixes a segfault when a NULL TLS option is accessed as part
of a validation check for another option (e.g. in the zero-copy +
multifd compression case). Details follow:
Currently, after copying s->parameters to the temporary
MigrationParameters object before migrate_params_check(), the
references in temporary object to the TLS options are dropped, either
because:
a) the user set a new option, in which case that's fine as
s->parameters still holds the reference to the old memory or,
b) the user did not set a new option, in which case keeping the
references in the temporary object would later cause them to be
freed along with it, leading to double-free when s->parameters is
also freed later on.
In this second case, it was overlooked that the TLS options can be
accessed already during migrate_params_check() as part of validation
of another option. Those pointers should not have been cleared.
Using QAPI_CLONE_MEMBERS fixes the issue because the temporary object
is not stealing a reference from s->parameters anymore.
migration: Fix blocking in POSTCOPY_DEVICE during package load
The package_loaded event is not set in case MIG_RP_MSG_PONG does not
arrive on the source from the destination in the return path thread. The
migration thread would then be blocked waiting for package_loaded event
indefinitely in POSTCOPY_DEVICE state. Where as, in such a condition the
source VM can safely resume as the destination has not yet started. The
pong message can get lost in case of a network failure or destination
crash before sending the pong.
This patch removes the package_loaded event and uses rp_sem, instead of
kicking multiple events. The error is detected in case of network
failure or destination crash and rp_sem is set in the out path of the
return path thread. This will kick the migration thread out from a
condition of indefinitely waiting for rp_sem. The migration thread then
fails early and breaks from the migration loop to resume the vm on the
source side.
Fixes: 7b842fe354c6 ("migration: Introduce POSTCOPY_DEVICE state") Signed-off-by: Pranav Tyagi <prtyagi@redhat.com> Reviewed-by: Juraj Marcin <jmarcin@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20260423094438.43556-1-prtyagi@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
* tag 'pull-misc-2026-05-05' of https://repo.or.cz/qemu/armbru:
qdev-monitor: Fix qdev ID validation regression
qemu-print: Document qemu_fprintf(), qemu_vfprintf() failure
error: Restore error_printf()'s function comment
error: Fix "to current monitor if we have one" comments
hw/core: Deprecate query-kvm
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'pull-target-arm-20260505' of https://gitlab.com/pm215/qemu: (29 commits)
hvf: arm: enable vGIC by default for virt-11.1 and later
hvf: enable nested virtualisation support
hvf: arm: physical timer emulation
hvf: arm: disable SME when nested virt is active
target/arm: hvf: pass through CNTHCTL_EL2 and MDCCINT_EL1
hvf: sync registers used at EL2
hvf: arm: override HV_SYS_REG_MDCR_EL2
target/arm: hvf: add asserts for code paths not leveraged when using the vGIC
hvf: arm: allow exposing minimal PMU for kernel-irqchip=on
hvf: gate ARM_FEATURE_PMU register emulation when using the Apple vGIC
hvf: only call hvf_sync_vtimer() when running without the platform vGIC
hw/arm, target/arm: nested virtualisation on HVF
target/arm: hvf: instantiate GIC early
accel, hw/arm, include/system/hvf: infrastructure changes for HVF vGIC
hw/intc: arm_gicv3_hvf: save/restore Apple GIC state
hw/intc: Add hvf vGIC interrupt controller support
target/arm/kvm: Cache host CPU probe failure
hw/intc/arm_gicv3: Fix NS write to ICC_AP1Rn_EL1 when prebits < 7
hw/net/allwinner-sun8i-emac: Flush queued packets when rx is enabled
docs/devel/decodetree: Fix formatting in "field examples" table
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The monitor screen can be cluttered after executing commands
like `info qtree`. It is useful to have a command to clear
current screen, just like linux `clear` command do.
This patch has been tested under monitors using stdio, vc,
tcp socket, unix socket and serial interfaces.
Signed-off-by: Alano Song <AlanoSong@163.com> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
Message-ID: <20260504174914.122607-5-dave@treblig.org> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Error if a '.name' is seen after another '.name' without an intervening
SRST, this normally indicates missing or misplaced docs.
We can't check DEF (as used in command line options) because those
often have multiple DEF per doc.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Markus Armbruster <armbru@redhat.com>
With the two minor tidy ups from Thomas's review
Message-ID: <20260504174914.122607-4-dave@treblig.org> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Split the SRST/ERST case and add some checks.
This is mainly to make it easier to add some checks in following
patches.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260504174914.122607-3-dave@treblig.org> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Move the docs for the info subcommand from the separate hx
into the top level file next to the 'info' command itself.
That makes every command in the top level file have a RST section.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260504174914.122607-2-dave@treblig.org> Signed-off-by: Markus Armbruster <armbru@redhat.com>
User-created qdevs with ID show up at /machine/peripheral/ID.
When we restricted QemOpts IDs to letters, digits, '-', '.', '_',
starting with a letter in commit b560a9ab9be: (qemu-option: Reject
anti-social IDs) a long time ago, this also covered qdev IDs. Looks
like this:
(qemu) device_add usb-mouse,id=/
qemu-system-x86_64: Parameter 'id' expects an identifier
Identifiers consist of letters, digits, '-', '.', '_', starting with a letter.
Try "help device_add" for more information
Lost in commit 397d30e9401 (qemu-error: remove dependency of stubs on
monitor) many moons ago.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260114124713.3308719-3-armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[Trivial conflict with commit a582a5784e5f (monitor: move
error_vprintf back to error-report.c) resolved]
error: Fix "to current monitor if we have one" comments
A number of print functions are documented to print to "current
monitor if we have one, else stderr". Wrong, they print to the
current monitor only when it's HMP. This is the case since commit 4ad417baa43 (error: Print error_report() to stderr if using qmp).
Fix the comments to say "current HMP monitor if we have one".
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260114124713.3308719-2-armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[Commit a582a5784e5f (monitor: move error_vprintf back to
error-report.c) lost a comment this commit fixes, restore it]
query-accelerators covers all accelerators, and should be used
instead.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260108131455.2240598-2-armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
[Rebased, missing section title markup fixed]
target/arm: hvf: pass through CNTHCTL_EL2 and MDCCINT_EL1
HVF traps accesses to CNTHCTL_EL2. For nested guests, HVF traps accesses to MDCCINT_EL1.
Pass through those accesses to the Hypervisor.framework library.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260429190532.26538-12-mohamed@unpredictable.fr Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When starting up the VM at EL2, more sysregs are available. Sync the state of those.
In addition, sync the state of the EL1 physical timer when the vGIC is used, even
if running at EL1. However, no OS running at EL1 is expected to use those registers.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260429190532.26538-11-mohamed@unpredictable.fr Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hvf: arm: allow exposing minimal PMU for kernel-irqchip=on
When running with the Apple vGIC, a minimum PMU is exposed by Hypervisor.framework
if a valid PMUVer register value is set. That PMU isn't exposed otherwise.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260429190532.26538-9-mohamed@unpredictable.fr Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hvf: gate ARM_FEATURE_PMU register emulation when using the Apple vGIC
From Apple documentation:
> When EL2 is disabled, PMU register accesses trigger "Trapped MSR, MRS, or
> System Instruction" exceptions. When this happens, hv_vcpu_run() returns, and the
> hv_vcpu_exit_t object contains the information about this exception.
> When EL2 is enabled, the handling of PMU register accesses is determined by the PMUVer
> field of ID_AA64DFR0_EL1 register.
> If the PMUVer field value is zero or is invalid, PMU register accesses generate "Undefined"
> exceptions, which are sent to the guest.
> If the PMUVer field value is non-zero and valid, PMU register accesses are emulated by the framework.
> The ID_AA64DFR0_EL1 register can be modified via hv_vcpu_set_sys_reg API.
However, despite what that documentation says this is actually gated on using the Apple vGIC
instead of nested virtualisation per se. Apple introduced both at the same time.
projects / thirdparty / qemu.git / log
