From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zqjmu-0005Up-QD for qemu-devel@nongnu.org; Mon, 26 Oct 2015 11:34:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zqjmq-0002kz-1B for qemu-devel@nongnu.org; Mon, 26 Oct 2015 11:34:20 -0400 Received: from mail-pa0-x233.google.com ([2607:f8b0:400e:c03::233]:35217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zqjmp-0002ks-PL for qemu-devel@nongnu.org; Mon, 26 Oct 2015 11:34:15 -0400 Received: by pasz6 with SMTP id z6so191518249pas.2 for ; Mon, 26 Oct 2015 08:34:15 -0700 (PDT) Sender: Paolo Bonzini References: From: Paolo Bonzini Message-ID: <562E47F0.4040804@redhat.com> Date: Mon, 26 Oct 2015 16:34:08 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1 0/6] Multi-Arch Phase 2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite , qemu-devel@nongnu.org Cc: Peter Maydell , Peter Crosthwaite On 26/10/2015 16:27, Peter Crosthwaite wrote: > 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/ and target- 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:rth@twiddle.net > 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:rth@twiddle.net > 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 > I think we can merge all patches except 2 in 2.5, but it depends on Peter as they would go through his tree (only patch 1 is generic, everything else is ARM). They definitely were posted before soft freeze. Paolo