On 2/22/21 6:29 PM, Alex Bennée wrote: > > Claudio Fontana <cfont...@suse.de> writes: > >> From: Claudio Fontana <cfont...@centriq4.arch.suse.de> >> >> Signed-off-by: Claudio Fontana <cfont...@suse.de> >> --- >> target/arm/internals.h | 9 ++- >> target/arm/cpu-softmmu.c | 134 +++++++++++++++++++++++++++++++++++++++ >> target/arm/cpu.c | 95 --------------------------- >> target/arm/meson.build | 1 + >> 4 files changed, 143 insertions(+), 96 deletions(-) >> create mode 100644 target/arm/cpu-softmmu.c >> >> diff --git a/target/arm/internals.h b/target/arm/internals.h >> index 6384461177..6589b63ebc 100644 >> --- a/target/arm/internals.h >> +++ b/target/arm/internals.h >> @@ -1196,4 +1196,11 @@ static inline uint64_t >> useronly_maybe_clean_ptr(uint32_t desc, uint64_t ptr) >> return ptr; >> } >> >> -#endif >> +#ifndef CONFIG_USER_ONLY >> +void arm_cpu_set_irq(void *opaque, int irq, int level); >> +void arm_cpu_kvm_set_irq(void *opaque, int irq, int level); >> +bool arm_cpu_virtio_is_big_endian(CPUState *cs); >> +uint64_t a15_l2ctlr_read(CPUARMState *env, const ARMCPRegInfo *ri); >> +#endif /* !CONFIG_USER_ONLY */ >> + >> +#endif /* TARGET_ARM_INTERNALS_H */ >> diff --git a/target/arm/cpu-softmmu.c b/target/arm/cpu-softmmu.c >> new file mode 100644 >> index 0000000000..263d1fc588 >> --- /dev/null >> +++ b/target/arm/cpu-softmmu.c >> @@ -0,0 +1,134 @@ >> +/* >> + * QEMU ARM CPU > > I guess apropos the discussion earlier it's really cpu-sysemu.c and we > could expand the header comment. > > QEMU ARM CPU - Helpers for system emulation and KVM only > > <snip> > > Otherwise: > > Reviewed-by: Alex Bennée <alex.ben...@linaro.org> >
Should I rename all *softmmu in the series to "sysemu"? I wonder if we should take the issue of sysemu/system/softmmu topic into a separate series. Currently basically starting from the build system already, "softmmu", sysemu and system are treated as a single thing, and the convention from build system and directories seems to be "softmmu", while from the header files we get "sysemu/". I agree that this is not a sufficient model to account for the new feature that Richard wants to develop, I just suggest we could also consider tackling this separately, with a pass through the whole code, gathering more input in the context of a dedicated series. What do you think? Also Paolo, any comments, since softmmu is all over meson? Ciao, Claudio