qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH v1 0/6] Multi-Arch Phase 2


From: Peter Crosthwaite
Subject: [Qemu-devel] [PATCH v1 0/6] Multi-Arch Phase 2
Date: Mon, 26 Oct 2015 08:27:22 -0700

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:address@hidden
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:address@hidden
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

-- 
1.9.1




reply via email to

[Prev in Thread] Current Thread [Next in Thread]