Multi-Arch Phase 2
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest6 patches 3 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/6 | target-*: Don't redefine cpu_exec()bsd-user/ include/ linux-user/ +18 more | +20 | 0 replies | |
| 2/6 | target-*: cpu.h: Undefine core code symbolsinclude/ target-alpha/ target-arm/ +16 more | +57 | 0 replies | |
| 3/6 | arm: cpu: static inline cpu_arm_init()target-arm/ target-arm/ | +5 | 0 replies | |
| 4/6 | target-arm: Split cp helper API to new C filetarget-arm/ target-arm/ target-arm/ | +329 | 0 replies | |
| 5/6 | hw: arm: Explicitly include cpu.h for consumershw/ include/ include/ +3 more | +13 | 0 replies | |
| 6/6 | hw: mb: boot Explicitly include cpu.h for consumershw/ | +2 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Qemu-devel] [PATCH v1 0/6] Multi-Arch Phase 2
This is the second set of patches needed to enable Multi-arch system emulation. For full context refer to RFCv3:
[PATCH v3 00/35] Multi Architecture System Emulation
https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg03929.html
Phase 1 was mostly merged:
[PATCH v1 00/15] Multi-Arch Phase 1
https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg03054.html
This pack contains no functional diff, but contains some of the higher diff refactorings that prepare MA support. It makes a start on the arch-specific changes needed touching Microblaze and ARM and giving an idea of what an Arches hw/<arch> and target-<arch> are going to look like after conversion.
Original cover, as well as overall series state below for further information.
Regards,
Peter
Original Multi-arch arch patch series cover:
***
This is target-multi, a system-mode build that can support multiple cpu-types.
Two architectures are initially converted. Microblaze and ARM. Step by step conversion in done for each. A microblaze is added to Xilinx Zynq platform as a test case. This will be elaborted more in future spins. This use case is valid, as Microblazes can be added (any number of them!) in Zynq FPGA programmable logic configuration.
The general approach (radically different to approach in V1 RFC) is to build and prelink an object (arch-obj.o) per-arch containing:
1: target-foo/*
2: All uses of env internals and CPU_GET_ENV
* cputlb, translate-all, cpu-exec
* TCG backend
This means cputlb and friends are compiled multiple times fo each arch. The symbols for each of these pre-links are then localised to avoid link time name collisions. This is based on Paolo's suggestion to templatify cputlb and friends. Just the net of what to multi-compile is widened to include the TCG stuff as well now.
Despite being some "major surgery" this approach actually solves many of big the problems raised in V1. Big problems sovled:
1: With the multi-compile TCG backends there are now multiple tcg_ctx's for each architecture. This solves the issue PMM raised WRT false positives on TB hashing as archs no longer share translation context.
2: There is no longer a need to reorder the CPU_COMMON within the ENV or the ENV within the CPU. This was flagged as a performance issue by multiple people in V1.
All users of the env internals as well as ENV_GET_CPU are now in multi-compile code and so multi-arch does not need to define a generic ENV nor does in need to def the problematic ENV_GET_CPU.
3: With the prelink symbol localisation, link time namespace collision of helpers from multiple arches is no longer an issue. No need to bloat all the function names with arch specific prefixes.
4: The architecture specifics used/defined by cpu-defs can now vary from arch to arch (incl. target_ulong) greatly reducing coversion effort needed. The list of restrictions for multi-arch capability is much reduced since V1. No target_long issues anymore.
include/exec/*.h and some of the common code needs some refactoring to setup this single vs multi compile split. Mostly code movements.
Some functions (like tcg_enabled) need to be listified for each of the now-multiple TCG engines.
The interface between the multi compile and single compiled files needs to be virtualised using QOM cpu functions. But this is now a very low footprint change as most of the virtualised hooks are now in mutli-compiled code (they only exist as text once). There are more new hooks than before, but the per target change pattern is reduced.
For the implementation of the series, the trickiest part is (still) cpu.h inclusion management. There are now more than one cpu.h's and different parts of the tree need a different include scheme. target-multi defines it's own cpu.h which is bare minimum defs as needed by core code only. target-foo/cpu.h are mostly the same but refactored to avoid collisions with other cpu.h's. Inclusion scheme goes something like
this (for the multi-arch build):
*: Core code includes only target-multi/cpu.h
*: target-foo/ implementation code includes target-foo/cpu.h locally *: System level code (e.g. mach models) can use multiple target-foo/cpu.h's
The hardest unasnwered Q is (still) what to do about bootloading. Currently each arch has it's own architecture specific bootloading which may assume a single architecture. I have applied some hacks to at least get this RFC testable using a -kernel -firmware split but going forward being able to associate an elf/image with a cpu explictitly needs to be solved.
No support for KVM, im not sure if a mix of TCG and KVM is supported even for a single arch? (which would be prerequisite to MA KVM).
***
Current review state of full multi-arch work in progress branch:
target-*: Don't redefine cpu_exec()
target-*: cpu.h: Undefine core code symbols
arm: cpu: static inline cpu_arm_init()
target-arm: Split cp helper API to new C file
hw: arm: Explicitly include cpu.h for consumers
hw: mb: Explicitly include cpu.h for consumers
translate: Listify tcg_exec_init() R:[email protected]
cpus: Listify cpu_list() function
translate-common: Listify tcg_enabled()
core: Convert tcg_enabled() uses to any/all variants
exec-all: Move cpu_can_do_io() to qom/cpu.h R:[email protected]
cpu-common: Define tb_page_addr_t for everyone include/exec: Split target_long def to new header
cpu-defs: Allow multiple inclusions Makefile.target: Introduce arch-obj
core: virtualise CPU interfaces completely
core: Introduce multi-arch build
arm: register cpu_list() function
arm: enable multi-arch
microblaze: enable multi-arch
arm: boot: Don't assume all CPUs are ARM
arm: xilinx_zynq: Add a Microblaze
HACK: mb: boot: Assume using -firmware for mb software
HACK: mb: boot: Disable dtb load in multi-arch
Peter Crosthwaite (6):
target-*: Don't redefine cpu_exec() target-*: cpu.h: Undefine core code symbols
arm: cpu: static inline cpu_arm_init()
target-arm: Split cp helper API to new C file
hw: arm: Explicitly include cpu.h for consumers
hw: mb: boot Explicitly include cpu.h for consumers
bsd-user/main.c | 4 +- hw/arm/strongarm.h | 2 + hw/microblaze/boot.h | 2 + include/exec/cpu-all.h | 2 + include/exec/cpu-defs-clear.h | 33 +++++ include/hw/arm/arm.h | 3 + include/hw/arm/digic.h | 2 + include/hw/arm/exynos4210.h | 2 + include/hw/arm/omap.h | 2 + include/hw/arm/pxa.h | 2 + linux-user/main.c | 32 ++-- target-alpha/cpu.h | 3 +- target-arm/Makefile.objs | 1 + target-arm/cp.c | 328 +++++++++++++++++++++++++++++++++++++++++ target-arm/cpu.h | 9 +- target-arm/helper.c | 329 ------------------------------------------ target-cris/cpu.h | 3 +- target-i386/cpu.h | 3 +- target-lm32/cpu.h | 4 +- target-m68k/cpu.h | 4 +- target-microblaze/cpu.h | 3 +- target-mips/cpu.h | 4 +- target-moxie/cpu.h | 3 +- target-openrisc/cpu.h | 4 +- target-ppc/cpu.h | 3 +- target-s390x/cpu.h | 3 +- target-sh4/cpu.h | 3 +- target-sparc/cpu.h | 3 +- target-tilegx/cpu.h | 3 +- target-tricore/cpu.h | 3 +- target-unicore32/cpu.h | 3 +- target-xtensa/cpu.h | 4 +- 32 files changed, 426 insertions(+), 383 deletions(-) create mode 100644 include/exec/cpu-defs-clear.h create mode 100644 target-arm/cp.c
Signature · 1 line
1.9.1