[Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Hello,

Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
cpu_state_reset() function, which had been renamed as an interim solution
to free the identifier "cpu_reset" for QOM.

The interested observer may note that the earlier sh4 SH7750 patches (that
have been deferred due to time constraints for 1.1) were a test run and
serve as template for propagating xxxCPU throughout the code base:

(i) In target-specific code, accessing CPUxxxState* is a cheap pointer
dereference from xxxCPU (&cpu->env), so xxxCPU should be preferred for any
static helper functions and QOM/qdev state structs because fields in CPUState
and in xxxCPU will increase over time. In state structs this also paves
the way for QOM child<> or link<> properties.

(ii) In TCG helpers, the target's xxxCPU can be obtained via xxx_env_get_cpu().
Be aware that this incurs one QOM cast.

(iii) In generic code, the base CPU can be obtained via ENV_GET_CPU() macro.
Note that this incurs two QOM casts, so local variables should be preferred
over repeated macro usage within a function.

(iv) In generic functions, only after all usages of env have been eliminated
can the argument be changed from CPUArchState to CPUState.

(v) Opaque xxxCPU* values are assigned directly to xxxCPU*, to save QOM casts;
to CPUState* via CPU() cast, in case the casting mechanism ever gets changed.

Historically, this series has been cherry-picked from a larger CPUState
refactoring (guess why) and reordered to group subsystems and to enforce
get, pass, use order.
I had checked v1 to compile on ...
* openSUSE 12.1 x86_64 w/KVM,
* openSUSE Factory ppc w/KVM (with the AREG0 #error suppressed),
* mingw32/64 cross-builds,
* OpenBSD 5.1 amd64.
Thus I'm confident that I got order, return types and local variables right;
changes to opaque values however (keyword "pass") should be reviewed carefully.
v2 fixes the changed cpu_init macros to return NULL if CPU init failed.

Again, target maintainers are requested to start queuing their patches on their
-next branches, where available, to avoid collisions.
I've been careful to verbosely document which change is for what; the targets
are not interdependent except for the final patch, neither is linux-user.
PReP patches depend on target-ppc, so should go through the ppc tree please.
Only target-mips actually depends on a 1.1 patch (the comment drop).

Some logical next steps that were not strictly necessary for cpu_reset() have
been deferred to part 4, including s390x and some more pxa2xx refactorings.

Available for testing and cherry-picking (not pulling!) from:
git://github.com/afaerber/qemu-cpu.git qom-cpu-reset.v2
https://github.com/afaerber/qemu-cpu/commits/qom-cpu-reset.v2

Regards,
Andreas

Cc: Anthony Liguori <anthony@codemonkey.ws>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>

Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc <qemu-ppc@nongnu.org>
Cc: Blue Swirl <blauwirbel@gmail.com>
Cc: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Riku Voipio <riku.voipio@iki.fi>

v1 -> v2:
* Handle cpu_xxx_init() failure gracefully by replacing the cpu_init() macros
  with static inline functions checking the return value. Reported by Peter.

Andreas Färber (74):
  target-arm: Use cpu_reset() in cpu_arm_init()
  target-mips: Use cpu_reset() in cpu_mips_init()
  target-i386: Pass X86CPU to do_cpu_{init,sipi}()
  target-i386: Let cpu_x86_init() return X86CPU
  pc: Use cpu_x86_init() to obtain X86CPU
  pc: Pass X86CPU to pc_cpu_reset()
  target-sparc: Let cpu_sparc_init() return SPARCCPU
  sun4m: Use cpu_sparc_init() to obtain SPARCCPU
  sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
  sun4u: Use cpu_sparc_init() to obtain SPARCCPU
  sun4u: Let cpu_devinit() return SPARCCPU
  sun4u: Store SPARCCPU in ResetData
  leon3: Use cpu_sparc_init() to obtain SPARCCPU
  leon3: Store SPARCCPU in ResetData
  target-ppc: Let cpu_ppc_init() return PowerPCCPU
  ppce500_mpc8544ds: Pass PowerPCCPU to mpc8544ds_cpu_reset[_sec]
  spapr: Use cpu_ppc_init() to obtain PowerPCCPU
  spapr: Pass PowerPCCPU to spapr_cpu_reset()
  ppc440_bamboo: Use cpu_ppc_init() to obtain PowerPCCPU
  ppc440_bamboo: Pass PowerPCCPU to main_cpu_reset()
  ppc4xx_devs: Use cpu_ppc_init() to obtain PowerPCCPU
  ppc4xx_devs: Pass PowerPCCPU to ppc4xx_reset()
  ppc_newworld: Use cpu_ppc_init() to obtain PowerPCCPU
  ppc_newworld: Pass PowerPCCPU to ppc_core99_reset()
  ppc_oldworld: Use cpu_ppc_init() to obtain PowerPCCPU
  ppc_oldworld: Pass PowerPCCPU to ppc_heathrow_reset()
  ppc_prep: Use cpu_ppc_init() to obtain PowerPCCPU
  ppc_prep: Pass PowerPCCPU to ppc_prep_reset()
  virtex_ml507: Use cpu_ppc_init() to obtain PowerPCCPU
  virtex_ml507: Let ppc440_init_xilinx() return PowerPCCPU
  virtex_ml507: Pass PowerPCCPU to main_cpu_reset()
  cpu-exec: Use cpu_reset() in cpu_exec() for TARGET_PPC
  pxa2xx: Use cpu_arm_init() and store ARMCPU
  omap: Use cpu_arm_init() to store ARMCPU in omap_mpu_state_s
  armv7m: Use cpu_arm_init() to obtain ARMCPU
  armv7m: Pass ARMCPU to armv7m_reset()
  arm_boot: Pass ARMCPU to do_cpu_reset()
  target-sh4: Let cpu_sh4_init() return SuperHCPU
  r2d: Use cpu_sh4_init() to obtain SuperHCPU
  r2d: Store SuperHCPU in ResetData
  target-lm32: Let cpu_lm32_init() return LM32CPU
  lm32_boards: Use cpu_lm32_init() to obtain LM32CPU
  lm32_boards: Store LM32CPU in ResetInfo
  milkymist: Use cpu_lm32_init() to obtain LM32CPU
  milkymist: Store LM32 in ResetInfo
  target-xtensa: Let cpu_xtensa_init() return XtensaCPU
  xtensa_sim: Use cpu_xtensa_init() to obtain XtensaCPU
  xtensa_sim: Pass XtensaCPU to sim_reset()
  xtensa_lx60: Use cpu_xtensa_init() to obtain XtensaCPU
  xtensa_lx60: Pass XtensaCPU to lx60_reset()
  target-cris: Reindent cpu_cris_init()
  target-cris: Let cpu_cris_init() return CRISCPU
  axis_dev88: Use cpu_cris_init() to obtain CRISCPU
  cris-boot: Pass CRISCPU to cris_load_image()
  cris-boot: Pass CRISCPU to main_cpu_reset().
  target-microblaze: Let cpu_mb_init() return MicroBlazeCPU
  petalogix_ml605: Use cpu_mb_init() to obtain MicroBlazeCPU
  petalogix_s3adsp1800_mmu: Use cpu_mb_init() to obtain MicroBlazeCPU
  microblaze_boot: Pass MicroBlazeCPU to microblaze_load_kernel()
  target-mips: Use cpu_reset() in do_interrupt()
  target-mips: Let cpu_mips_init() return MIPSCPU
  mips_fulong2e: Use cpu_mips_cpu() to obtain MIPSCPU
  mips_fulong2e: Pass MIPSCPU to main_cpu_reset()
  mips_jazz: Use cpu_mips_init() to obtain MIPSCPU
  mips_jazz: Pass MIPSCPU to main_cpu_reset()
  mips_malta: Use cpu_mips_init() to obtain MIPSCPU
  mips_malta: Pass MIPSCPU to main_cpu_reset()
  mips_mipssim: Use cpu_mips_init() to obtain MIPSCPU
  mips_mipssim: Store MIPSCPU in ResetData
  mips_r4k: Use cpu_mips_init() to obtain MIPSCPU
  mips_r4k: Store MIPSCPU in ResetData
  bsd-user: Use cpu_reset() in after cpu_init()
  linux-user: Use cpu_reset() after cpu_init() / cpu_copy()
  Kill off cpu_state_reset()

 bsd-user/main.c               |    2 +-
 cpu-all.h                     |    1 -
 cpu-exec.c                    |    9 ++-
 hw/arm_boot.c                 |    9 ++-
 hw/armv7m.c                   |   15 ++++--
 hw/axis_dev88.c               |    6 ++-
 hw/cris-boot.c                |   10 ++--
 hw/cris-boot.h                |    2 +-
 hw/leon3.c                    |   14 +++--
 hw/lm32_boards.c              |   18 ++++---
 hw/mainstone.c                |    2 +-
 hw/microblaze_boot.c          |   16 +++---
 hw/microblaze_boot.h          |    4 +-
 hw/milkymist.c                |   12 +++--
 hw/mips_fulong2e.c            |   13 +++--
 hw/mips_jazz.c                |   13 +++--
 hw/mips_malta.c               |   15 ++++--
 hw/mips_mipssim.c             |   15 +++--
 hw/mips_r4k.c                 |   15 +++--
 hw/nseries.c                  |    6 +-
 hw/omap.h                     |    2 +-
 hw/omap1.c                    |   20 ++++---
 hw/omap2.c                    |    8 ++--
 hw/omap_sx1.c                 |    2 +-
 hw/palm.c                     |    2 +-
 hw/pc.c                       |   19 ++++---
 hw/petalogix_ml605_mmu.c      |   10 +++-
 hw/petalogix_s3adsp1800_mmu.c |   10 +++-
 hw/ppc440_bamboo.c            |   13 +++--
 hw/ppc4xx_devs.c              |   13 +++--
 hw/ppc_newworld.c             |   13 +++--
 hw/ppc_oldworld.c             |   13 +++--
 hw/ppc_prep.c                 |   13 +++--
 hw/ppce500_mpc8544ds.c        |   21 +++++---
 hw/pxa.h                      |    2 +-
 hw/pxa2xx.c                   |   40 +++++++-------
 hw/r2d.c                      |   18 ++++---
 hw/spapr.c                    |   14 +++--
 hw/spitz.c                    |    2 +-
 hw/sun4m.c                    |   20 +++++---
 hw/sun4u.c                    |   25 ++++++----
 hw/tosa.c                     |    2 +-
 hw/virtex_ml507.c             |   27 ++++++----
 hw/xtensa_lx60.c              |   15 +++--
 hw/xtensa_sim.c               |   17 ++++--
 hw/z2.c                       |    2 +-
 linux-user/main.c             |    2 +-
 linux-user/syscall.c          |    2 +-
 target-arm/helper.c           |    7 +--
 target-cris/cpu.h             |   12 ++++-
 target-cris/translate.c       |  110 ++++++++++++++++++++---------------------
 target-i386/cpu.h             |   16 +++++--
 target-i386/helper.c          |   23 ++++-----
 target-i386/kvm.c             |    6 ++-
 target-lm32/cpu.c             |    2 +-
 target-lm32/cpu.h             |   12 ++++-
 target-lm32/helper.c          |   10 +---
 target-m68k/helper.c          |    5 --
 target-microblaze/cpu.h       |   12 ++++-
 target-microblaze/translate.c |   18 ++-----
 target-mips/cpu.h             |   15 +++++-
 target-mips/helper.c          |    3 +-
 target-mips/translate.c       |    6 +-
 target-ppc/cpu.h              |   12 ++++-
 target-ppc/helper.c           |    9 +---
 target-s390x/helper.c         |    9 +---
 target-sh4/cpu.h              |   12 ++++-
 target-sh4/translate.c        |    9 +---
 target-sparc/cpu.c            |    9 +---
 target-sparc/cpu.h            |   17 +++++-
 target-xtensa/cpu.c           |    2 +-
 target-xtensa/cpu.h           |   16 +++++-
 target-xtensa/helper.c        |    9 +---
 73 files changed, 516 insertions(+), 389 deletions(-)

-- 
1.7.7

[Qemu-devel] [PATCH next v2 01/74] target-arm: Use cpu_reset() in cpu_arm_init()

[Andreas Färber]

Commit 3c30dd5a68e9fee6af67cfd0d14ed7520820f36a (target-arm: Move reset
handling to arm_cpu_reset) QOM'ified CPU reset. Complete it by replacing
cpu_state_reset() with cpu_reset().

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 target-arm/helper.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 7e1c2c0..06ebffc 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -80,7 +80,7 @@ ARMCPU *cpu_arm_init(const char *cpu_model)
         arm_translate_init();
     }
 
-    cpu_state_reset(env);
+    cpu_reset(CPU(cpu));
     if (arm_feature(env, ARM_FEATURE_NEON)) {
         gdb_register_coprocessor(env, vfp_gdb_get_reg, vfp_gdb_set_reg,
                                  51, "arm-neon.xml", 0);
-- 
1.7.7

[Qemu-devel] [PATCH next v2 02/74] target-mips: Use cpu_reset() in cpu_mips_init()

[Andreas Färber]

Commit 0f71a7095db6bc055bc5bb520d85ea650cca8a33 (target-mips: QOM'ify
CPU) hooked up cpu_state_reset() to CPUClass::reset(). Dropping the
introduction of subclasses for 1.1, due to mips_def_t the reset code
could not be QOM'ified yet, i.e. cpu_state_reset() will not forward to
CPUClass::reset().

Update cpu_mips_init() with cpu_reset() nontheless, indirectly calling
cpu_state_reset(), so that generic code can be converted to call
cpu_reset().

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 target-mips/translate.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target-mips/translate.c b/target-mips/translate.c
index f5297b0..58e044b 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -12709,7 +12709,7 @@ CPUMIPSState *cpu_mips_init (const char *cpu_model)
     fpu_init(env, def);
     mvp_init(env, def);
     mips_tcg_init();
-    cpu_state_reset(env);
+    cpu_reset(CPU(cpu));
     qemu_init_vcpu(env);
     return env;
 }
-- 
1.7.7

[Qemu-devel] [PATCH next v2 03/74] target-i386: Pass X86CPU to do_cpu_{init, sipi}()

[Andreas Färber]

Allows to use cpu_reset() in place of cpu_state_reset().

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 cpu-exec.c           |    4 ++--
 target-i386/cpu.h    |    4 ++--
 target-i386/helper.c |   13 ++++++++-----
 target-i386/kvm.c    |    6 ++++--
 4 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/cpu-exec.c b/cpu-exec.c
index 0344cd5..fbb39cb 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -287,11 +287,11 @@ int cpu_exec(CPUArchState *env)
 #if defined(TARGET_I386)
                     if (interrupt_request & CPU_INTERRUPT_INIT) {
                             svm_check_intercept(env, SVM_EXIT_INIT);
-                            do_cpu_init(env);
+                            do_cpu_init(x86_env_get_cpu(env));
                             env->exception_index = EXCP_HALTED;
                             cpu_loop_exit(env);
                     } else if (interrupt_request & CPU_INTERRUPT_SIPI) {
-                            do_cpu_sipi(env);
+                            do_cpu_sipi(x86_env_get_cpu(env));
                     } else if (env->hflags2 & HF2_GIF_MASK) {
                         if ((interrupt_request & CPU_INTERRUPT_SMI) &&
                             !(env->hflags & HF_SMM_MASK)) {
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index b5b9a50..4bff61d 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1051,8 +1051,8 @@ static inline void cpu_get_tb_cpu_state(CPUX86State *env, target_ulong *pc,
         (env->eflags & (IOPL_MASK | TF_MASK | RF_MASK | VM_MASK));
 }
 
-void do_cpu_init(CPUX86State *env);
-void do_cpu_sipi(CPUX86State *env);
+void do_cpu_init(X86CPU *cpu);
+void do_cpu_sipi(X86CPU *cpu);
 
 #define MCE_INJECT_BROADCAST    1
 #define MCE_INJECT_UNCOND_AO    2
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 0b22582..fe181be 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -1187,27 +1187,30 @@ CPUX86State *cpu_x86_init(const char *cpu_model)
 }
 
 #if !defined(CONFIG_USER_ONLY)
-void do_cpu_init(CPUX86State *env)
+void do_cpu_init(X86CPU *cpu)
 {
+    CPUX86State *env = &cpu->env;
     int sipi = env->interrupt_request & CPU_INTERRUPT_SIPI;
     uint64_t pat = env->pat;
 
-    cpu_state_reset(env);
+    cpu_reset(CPU(cpu));
     env->interrupt_request = sipi;
     env->pat = pat;
     apic_init_reset(env->apic_state);
     env->halted = !cpu_is_bsp(env);
 }
 
-void do_cpu_sipi(CPUX86State *env)
+void do_cpu_sipi(X86CPU *cpu)
 {
+    CPUX86State *env = &cpu->env;
+
     apic_sipi(env->apic_state);
 }
 #else
-void do_cpu_init(CPUX86State *env)
+void do_cpu_init(X86CPU *cpu)
 {
 }
-void do_cpu_sipi(CPUX86State *env)
+void do_cpu_sipi(X86CPU *cpu)
 {
 }
 #endif
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index e74a9e4..0d0d8f6 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -1698,6 +1698,8 @@ void kvm_arch_post_run(CPUX86State *env, struct kvm_run *run)
 
 int kvm_arch_process_async_events(CPUX86State *env)
 {
+    X86CPU *cpu = x86_env_get_cpu(env);
+
     if (env->interrupt_request & CPU_INTERRUPT_MCE) {
         /* We must not raise CPU_INTERRUPT_MCE if it's not supported. */
         assert(env->mcg_cap);
@@ -1732,11 +1734,11 @@ int kvm_arch_process_async_events(CPUX86State *env)
     }
     if (env->interrupt_request & CPU_INTERRUPT_INIT) {
         kvm_cpu_synchronize_state(env);
-        do_cpu_init(env);
+        do_cpu_init(cpu);
     }
     if (env->interrupt_request & CPU_INTERRUPT_SIPI) {
         kvm_cpu_synchronize_state(env);
-        do_cpu_sipi(env);
+        do_cpu_sipi(cpu);
     }
     if (env->interrupt_request & CPU_INTERRUPT_TPR) {
         env->interrupt_request &= ~CPU_INTERRUPT_TPR;
-- 
1.7.7

[Qemu-devel] [PATCH next v2 04/74] target-i386: Let cpu_x86_init() return X86CPU

[Andreas Färber]

Turn cpu_init macro into a static inline function returning CPUX86State
for backwards compatibility.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 target-i386/cpu.h    |   12 ++++++++++--
 target-i386/helper.c |    4 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 4bff61d..adc569c 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -785,7 +785,7 @@ typedef struct CPUX86State {
 
 #include "cpu-qom.h"
 
-CPUX86State *cpu_x86_init(const char *cpu_model);
+X86CPU *cpu_x86_init(const char *cpu_model);
 int cpu_x86_exec(CPUX86State *s);
 void x86_cpu_list (FILE *f, fprintf_function cpu_fprintf, const char *optarg);
 void x86_cpudef_setup(void);
@@ -958,7 +958,15 @@ uint64_t cpu_get_tsc(CPUX86State *env);
 #define TARGET_VIRT_ADDR_SPACE_BITS 32
 #endif
 
-#define cpu_init cpu_x86_init
+static inline CPUX86State *cpu_init(const char *cpu_model)
+{
+    X86CPU *cpu = cpu_x86_init(cpu_model);
+    if (cpu == NULL) {
+        return NULL;
+    }
+    return &cpu->env;
+}
+
 #define cpu_exec cpu_x86_exec
 #define cpu_gen_code cpu_x86_gen_code
 #define cpu_signal_handler cpu_x86_signal_handler
diff --git a/target-i386/helper.c b/target-i386/helper.c
index fe181be..4577cae 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -1157,7 +1157,7 @@ int cpu_x86_get_descr_debug(CPUX86State *env, unsigned int selector,
     return 1;
 }
 
-CPUX86State *cpu_x86_init(const char *cpu_model)
+X86CPU *cpu_x86_init(const char *cpu_model)
 {
     X86CPU *cpu;
     CPUX86State *env;
@@ -1183,7 +1183,7 @@ CPUX86State *cpu_x86_init(const char *cpu_model)
 
     qemu_init_vcpu(env);
 
-    return env;
+    return cpu;
 }
 
 #if !defined(CONFIG_USER_ONLY)
-- 
1.7.7

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 10.05.2012 02:10, schrieb Andreas Färber:
> Andreas Färber (74):
>   target-arm: Use cpu_reset() in cpu_arm_init()
>   target-mips: Use cpu_reset() in cpu_mips_init()
>   target-i386: Pass X86CPU to do_cpu_{init,sipi}()
>   target-i386: Let cpu_x86_init() return X86CPU

Sorry, apparently I ran into some server maintenance of ours while
sending - it stopped here saying that the domain us.ibm.com didn't
exist. ;) Please ignore this thread, I resent - sorry for the duplicates.

Andreas

>   pc: Use cpu_x86_init() to obtain X86CPU
>   pc: Pass X86CPU to pc_cpu_reset()
>   target-sparc: Let cpu_sparc_init() return SPARCCPU
>   sun4m: Use cpu_sparc_init() to obtain SPARCCPU
>   sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
>   sun4u: Use cpu_sparc_init() to obtain SPARCCPU
>   sun4u: Let cpu_devinit() return SPARCCPU
>   sun4u: Store SPARCCPU in ResetData
>   leon3: Use cpu_sparc_init() to obtain SPARCCPU
>   leon3: Store SPARCCPU in ResetData
>   target-ppc: Let cpu_ppc_init() return PowerPCCPU
>   ppce500_mpc8544ds: Pass PowerPCCPU to mpc8544ds_cpu_reset[_sec]
>   spapr: Use cpu_ppc_init() to obtain PowerPCCPU
>   spapr: Pass PowerPCCPU to spapr_cpu_reset()
>   ppc440_bamboo: Use cpu_ppc_init() to obtain PowerPCCPU
>   ppc440_bamboo: Pass PowerPCCPU to main_cpu_reset()
>   ppc4xx_devs: Use cpu_ppc_init() to obtain PowerPCCPU
>   ppc4xx_devs: Pass PowerPCCPU to ppc4xx_reset()
>   ppc_newworld: Use cpu_ppc_init() to obtain PowerPCCPU
>   ppc_newworld: Pass PowerPCCPU to ppc_core99_reset()
>   ppc_oldworld: Use cpu_ppc_init() to obtain PowerPCCPU
>   ppc_oldworld: Pass PowerPCCPU to ppc_heathrow_reset()
>   ppc_prep: Use cpu_ppc_init() to obtain PowerPCCPU
>   ppc_prep: Pass PowerPCCPU to ppc_prep_reset()
>   virtex_ml507: Use cpu_ppc_init() to obtain PowerPCCPU
>   virtex_ml507: Let ppc440_init_xilinx() return PowerPCCPU
>   virtex_ml507: Pass PowerPCCPU to main_cpu_reset()
>   cpu-exec: Use cpu_reset() in cpu_exec() for TARGET_PPC
>   pxa2xx: Use cpu_arm_init() and store ARMCPU
>   omap: Use cpu_arm_init() to store ARMCPU in omap_mpu_state_s
>   armv7m: Use cpu_arm_init() to obtain ARMCPU
>   armv7m: Pass ARMCPU to armv7m_reset()
>   arm_boot: Pass ARMCPU to do_cpu_reset()
>   target-sh4: Let cpu_sh4_init() return SuperHCPU
>   r2d: Use cpu_sh4_init() to obtain SuperHCPU
>   r2d: Store SuperHCPU in ResetData
>   target-lm32: Let cpu_lm32_init() return LM32CPU
>   lm32_boards: Use cpu_lm32_init() to obtain LM32CPU
>   lm32_boards: Store LM32CPU in ResetInfo
>   milkymist: Use cpu_lm32_init() to obtain LM32CPU
>   milkymist: Store LM32 in ResetInfo
>   target-xtensa: Let cpu_xtensa_init() return XtensaCPU
>   xtensa_sim: Use cpu_xtensa_init() to obtain XtensaCPU
>   xtensa_sim: Pass XtensaCPU to sim_reset()
>   xtensa_lx60: Use cpu_xtensa_init() to obtain XtensaCPU
>   xtensa_lx60: Pass XtensaCPU to lx60_reset()
>   target-cris: Reindent cpu_cris_init()
>   target-cris: Let cpu_cris_init() return CRISCPU
>   axis_dev88: Use cpu_cris_init() to obtain CRISCPU
>   cris-boot: Pass CRISCPU to cris_load_image()
>   cris-boot: Pass CRISCPU to main_cpu_reset().
>   target-microblaze: Let cpu_mb_init() return MicroBlazeCPU
>   petalogix_ml605: Use cpu_mb_init() to obtain MicroBlazeCPU
>   petalogix_s3adsp1800_mmu: Use cpu_mb_init() to obtain MicroBlazeCPU
>   microblaze_boot: Pass MicroBlazeCPU to microblaze_load_kernel()
>   target-mips: Use cpu_reset() in do_interrupt()
>   target-mips: Let cpu_mips_init() return MIPSCPU
>   mips_fulong2e: Use cpu_mips_cpu() to obtain MIPSCPU
>   mips_fulong2e: Pass MIPSCPU to main_cpu_reset()
>   mips_jazz: Use cpu_mips_init() to obtain MIPSCPU
>   mips_jazz: Pass MIPSCPU to main_cpu_reset()
>   mips_malta: Use cpu_mips_init() to obtain MIPSCPU
>   mips_malta: Pass MIPSCPU to main_cpu_reset()
>   mips_mipssim: Use cpu_mips_init() to obtain MIPSCPU
>   mips_mipssim: Store MIPSCPU in ResetData
>   mips_r4k: Use cpu_mips_init() to obtain MIPSCPU
>   mips_r4k: Store MIPSCPU in ResetData
>   bsd-user: Use cpu_reset() in after cpu_init()
>   linux-user: Use cpu_reset() after cpu_init() / cpu_copy()
>   Kill off cpu_state_reset()

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Peter Maydell]

On 10 May 2012 01:10, Andreas Färber <afaerber@suse.de> wrote:
> Again, target maintainers are requested to start queuing their patches on their
> -next branches, where available, to avoid collisions.

Please, if you have patches you want me to put into target-arm.next,
post them as their own series rather than requiring me to guess
which ones to pull out of a 74 patch series... Something this
big is just too painful to work with.

thanks
-- PMM

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 10.05.2012 22:35, schrieb Peter Maydell:
> On 10 May 2012 01:10, Andreas Färber <afaerber@suse.de> wrote:
>> Again, target maintainers are requested to start queuing their patches on their
>> -next branches, where available, to avoid collisions.
> 
> Please, if you have patches you want me to put into target-arm.next,
> post them as their own series rather than requiring me to guess
> which ones to pull out of a 74 patch series...

That's quite obvious though, isn't it? The complete v2 (i.e., the
74-patch v2) contains the following patches grouped as ARM devices:
33-37, those clearly labelled as pxa2xx, omap, armv7m, arm_boot:

>>   pxa2xx: Use cpu_arm_init() and store ARMCPU
>>   omap: Use cpu_arm_init() to store ARMCPU in omap_mpu_state_s
>>   armv7m: Use cpu_arm_init() to obtain ARMCPU
>>   armv7m: Pass ARMCPU to armv7m_reset()
>>   arm_boot: Pass ARMCPU to do_cpu_reset()

> Something this
> big is just too painful to work with.

I don't see your point. Our mailboxes have thousands of messages either
way, you've only been cc'ed on those you are in MAINTAINERS for, and
applying 5 patches from a 74-patch series is not more work than applying
5 patches from a 5-patch series, is it?

This series is put together in such a way that it achieves a goal:
removing cpu_state_reset(). I can send you these and more patches
refactoring ARM devices but then it'll be perceived as "just churn".
74 sounds like much, but the patches are pretty easy to review, no?
These 74 are a subset of a currently 138-patch series and growing -
that's why agreeing on a merge order for qom-next is so important to me.

If I send these out in series of 5 patches and wait for each to get
merged through different trees then by the current rate of applying
this'll take years, especially if we're blocked by unmaintained targets...

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Peter Maydell]

On 10 May 2012 22:05, Andreas Färber <afaerber@suse.de> wrote:
> Am 10.05.2012 22:35, schrieb Peter Maydell:
>> Something this
>> big is just too painful to work with.
>
> I don't see your point. Our mailboxes have thousands of messages either
> way, you've only been cc'ed on those you are in MAINTAINERS for, and
> applying 5 patches from a 74-patch series is not more work than applying
> 5 patches from a 5-patch series, is it?

It is, because it requires work from me to be sure that I have all
the intended patches and none of the unintended ones. A five patch
series is a small and clearly bounded set of work; a 74 patch series
is a much bigger job, because the assumption is that there are
interdependencies within it such that it doesn't make sense to
review only a small part of it, otherwise the submitter would have
split it up in the first place.

(My mail client makes no distinction between qemu-devel messages I
get cc'd on and ones I don't, incidentally.)

> This series is put together in such a way that it achieves a goal:
> removing cpu_state_reset(). I can send you these and more patches
> refactoring ARM devices but then it'll be perceived as "just churn".
> 74 sounds like much, but the patches are pretty easy to review, no?
> These 74 are a subset of a currently 138-patch series and growing -
> that's why agreeing on a merge order for qom-next is so important to me.
>
> If I send these out in series of 5 patches and wait for each to get
> merged through different trees then by the current rate of applying
> this'll take years, especially if we're blocked by unmaintained targets...

If you just want a reviewed-by from me and to put the whole series in
to the tree via some other route that's also fine by me.

-- PMM

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 10.05.2012 23:26, schrieb Peter Maydell:
> On 10 May 2012 22:05, Andreas Färber <afaerber@suse.de> wrote:
>> This series is put together in such a way that it achieves a goal:
>> removing cpu_state_reset(). I can send you these and more patches
>> refactoring ARM devices but then it'll be perceived as "just churn".
>> 74 sounds like much, but the patches are pretty easy to review, no?
>> These 74 are a subset of a currently 138-patch series and growing -
>> that's why agreeing on a merge order for qom-next is so important to me.
>>
>> If I send these out in series of 5 patches and wait for each to get
>> merged through different trees then by the current rate of applying
>> this'll take years, especially if we're blocked by unmaintained targets...
> 
> If you just want a reviewed-by from me and to put the whole series in
> to the tree via some other route that's also fine by me.

That's the main request, yes, as done by Michael for v1. :)

/-F

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Max Filippov]

On Thu, May 10, 2012 at 4:10 AM, Andreas Färber <afaerber@suse.de> wrote:
> Hello,
>
> Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
> cpu_state_reset() function, which had been renamed as an interim solution
> to free the identifier "cpu_reset" for QOM.

For the xtensa part: Acked-by: Max Filippov <jcmvbkbc@gmail.com>

-- 
Thanks.
-- Max

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 14.05.2012 22:25, schrieb Max Filippov:
> On Thu, May 10, 2012 at 4:10 AM, Andreas Färber <afaerber@suse.de> wrote:
>> Hello,
>>
>> Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
>> cpu_state_reset() function, which had been renamed as an interim solution
>> to free the identifier "cpu_reset" for QOM.
> 
> For the xtensa part: Acked-by: Max Filippov <jcmvbkbc@gmail.com>

Thanks, applied to qom-next:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Edgar E. Iglesias]

On Tue, May 15, 2012 at 12:25:11AM +0400, Max Filippov wrote:
> On Thu, May 10, 2012 at 4:10 AM, Andreas Färber <afaerber@suse.de> wrote:
> > Hello,
> >
> > Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
> > cpu_state_reset() function, which had been renamed as an interim solution
> > to free the identifier "cpu_reset" for QOM.
> 
> For the xtensa part: Acked-by: Max Filippov <jcmvbkbc@gmail.com>

CRIS too:
Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 15.05.2012 13:24, schrieb Edgar E. Iglesias:
> On Tue, May 15, 2012 at 12:25:11AM +0400, Max Filippov wrote:
>> On Thu, May 10, 2012 at 4:10 AM, Andreas Färber <afaerber@suse.de> wrote:
>>> Hello,
>>>
>>> Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
>>> cpu_state_reset() function, which had been renamed as an interim solution
>>> to free the identifier "cpu_reset" for QOM.
>>
>> For the xtensa part: Acked-by: Max Filippov <jcmvbkbc@gmail.com>
> 
> CRIS too:
> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>

Thanks, applied to qom-next:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Edgar E. Iglesias]

On Tue, May 15, 2012 at 12:25:11AM +0400, Max Filippov wrote:
> On Thu, May 10, 2012 at 4:10 AM, Andreas Färber <afaerber@suse.de> wrote:
> > Hello,
> >
> > Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
> > cpu_state_reset() function, which had been renamed as an interim solution
> > to free the identifier "cpu_reset" for QOM.
> 
> For the xtensa part: Acked-by: Max Filippov <jcmvbkbc@gmail.com>

for mb + cris:
Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 15.05.2012 15:19, schrieb Edgar E. Iglesias:
> On Tue, May 15, 2012 at 12:25:11AM +0400, Max Filippov wrote:
>> On Thu, May 10, 2012 at 4:10 AM, Andreas Färber <afaerber@suse.de> wrote:
>>> Hello,
>>>
>>> Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
>>> cpu_state_reset() function, which had been renamed as an interim solution
>>> to free the identifier "cpu_reset" for QOM.
>>
>> For the xtensa part: Acked-by: Max Filippov <jcmvbkbc@gmail.com>
> 
> for mb + cris:
> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>

Thanks, applied to qom-next:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Alexander Graf]

On 05/10/2012 02:10 AM, Andreas Färber wrote:
> Hello,
>
> Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
> cpu_state_reset() function, which had been renamed as an interim solution
> to free the identifier "cpu_reset" for QOM.
>
> The interested observer may note that the earlier sh4 SH7750 patches (that
> have been deferred due to time constraints for 1.1) were a test run and
> serve as template for propagating xxxCPU throughout the code base:
>
> (i) In target-specific code, accessing CPUxxxState* is a cheap pointer
> dereference from xxxCPU (&cpu->env), so xxxCPU should be preferred for any
> static helper functions and QOM/qdev state structs because fields in CPUState
> and in xxxCPU will increase over time. In state structs this also paves
> the way for QOM child<>  or link<>  properties.
>
> (ii) In TCG helpers, the target's xxxCPU can be obtained via xxx_env_get_cpu().
> Be aware that this incurs one QOM cast.
>
> (iii) In generic code, the base CPU can be obtained via ENV_GET_CPU() macro.
> Note that this incurs two QOM casts, so local variables should be preferred
> over repeated macro usage within a function.
>
> (iv) In generic functions, only after all usages of env have been eliminated
> can the argument be changed from CPUArchState to CPUState.
>
> (v) Opaque xxxCPU* values are assigned directly to xxxCPU*, to save QOM casts;
> to CPUState* via CPU() cast, in case the casting mechanism ever gets changed.
>
> Historically, this series has been cherry-picked from a larger CPUState
> refactoring (guess why) and reordered to group subsystems and to enforce
> get, pass, use order.
> I had checked v1 to compile on ...
> * openSUSE 12.1 x86_64 w/KVM,
> * openSUSE Factory ppc w/KVM (with the AREG0 #error suppressed),
> * mingw32/64 cross-builds,
> * OpenBSD 5.1 amd64.
> Thus I'm confident that I got order, return types and local variables right;
> changes to opaque values however (keyword "pass") should be reviewed carefully.
> v2 fixes the changed cpu_init macros to return NULL if CPU init failed.
>
> Again, target maintainers are requested to start queuing their patches on their
> -next branches, where available, to avoid collisions.
> I've been careful to verbosely document which change is for what; the targets
> are not interdependent except for the final patch, neither is linux-user.
> PReP patches depend on target-ppc, so should go through the ppc tree please.
> Only target-mips actually depends on a 1.1 patch (the comment drop).
>
> Some logical next steps that were not strictly necessary for cpu_reset() have
> been deferred to part 4, including s390x and some more pxa2xx refactorings.
>
> Available for testing and cherry-picking (not pulling!) from:
> git://github.com/afaerber/qemu-cpu.git qom-cpu-reset.v2
> https://github.com/afaerber/qemu-cpu/commits/qom-cpu-reset.v2
>
> Regards,
> Andreas
>
> Cc: Anthony Liguori<anthony@codemonkey.ws>
> Cc: Paolo Bonzini<pbonzini@redhat.com>
> Cc: Igor Mammedov<imammedo@redhat.com>
>
> Cc: Peter Maydell<peter.maydell@linaro.org>
> Cc: Alexander Graf<agraf@suse.de>
> Cc: qemu-ppc<qemu-ppc@nongnu.org>
> Cc: Blue Swirl<blauwirbel@gmail.com>
> Cc: Edgar E. Iglesias<edgar.iglesias@gmail.com>
> Cc: Max Filippov<jcmvbkbc@gmail.com>
> Cc: Michael Walle<michael@walle.cc>
> Cc: Aurelien Jarno<aurelien@aurel32.net>
> Cc: Richard Henderson<rth@twiddle.net>
> Cc: Riku Voipio<riku.voipio@iki.fi>

Very simple, nice and clean ;)

PowerPC parts are:

   Acked-by: Alexander Graf <agraf@suse.de>


Alex

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 21.05.2012 15:52, schrieb Alexander Graf:
> Very simple, nice and clean ;)
> 
> PowerPC parts are:
> 
>   Acked-by: Alexander Graf <agraf@suse.de>

Thanks, applied to qom-next:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next

David and Edgar, you two were apparently not cc'ed. Could you submit
patches to document the pseries and virtex-ml507 machines respectively
in MAINTAINERS? Thanks.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Hello,

Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
cpu_state_reset() function, which had been renamed as an interim solution
to free the identifier "cpu_reset" for QOM.

The interested observer may note that the earlier sh4 SH7750 patches (that
have been deferred due to time constraints for 1.1) were a test run and
serve as template for propagating xxxCPU throughout the code base:

(i) In target-specific code, accessing CPUxxxState* is a cheap pointer
dereference from xxxCPU (&cpu->env), so xxxCPU should be preferred for any
static helper functions and QOM/qdev state structs because fields in CPUState
and in xxxCPU will increase over time. In state structs this also paves
the way for QOM child<> or link<> properties.

(ii) In TCG helpers, the target's xxxCPU can be obtained via xxx_env_get_cpu().
Be aware that this incurs one QOM cast.

(iii) In generic code, the base CPU can be obtained via ENV_GET_CPU() macro.
Note that this incurs two QOM casts, so local variables should be preferred
over repeated macro usage within a function.

(iv) In generic functions, only after all usages of env have been eliminated
can the argument be changed from CPUArchState to CPUState.

(v) Opaque xxxCPU* values are assigned directly to xxxCPU*, to save QOM casts;
to CPUState* via CPU() cast, in case the casting mechanism ever gets changed.

Historically, this series has been cherry-picked from a larger CPUState
refactoring (guess why) and reordered to group subsystems and to enforce
get, pass, use order.
I had checked v1 to compile on ...
* openSUSE 12.1 x86_64 w/KVM,
* openSUSE Factory ppc w/KVM (with the AREG0 #error suppressed),
* mingw32/64 cross-builds,
* OpenBSD 5.1 amd64.
Thus I'm confident that I got order, return types and local variables right;
changes to opaque values however (keyword "pass") should be reviewed carefully.
v2 fixes the changed cpu_init macros to return NULL if CPU init failed.

Again, target maintainers are requested to start queuing their patches on their
-next branches, where available, to avoid collisions.
I've been careful to verbosely document which change is for what; the targets
are not interdependent except for the final patch, neither is linux-user.
PReP patches depend on target-ppc, so should go through the ppc tree please.
Only target-mips actually depends on a 1.1 patch (the comment drop).

Some logical next steps that were not strictly necessary for cpu_reset() have
been deferred to part 4, including s390x and some more pxa2xx refactorings.

Available for testing and cherry-picking (not pulling!) from:
git://github.com/afaerber/qemu-cpu.git qom-cpu-reset.v2
https://github.com/afaerber/qemu-cpu/commits/qom-cpu-reset.v2

Regards,
Andreas

Cc: Anthony Liguori <anthony@codemonkey.ws>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>

Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc <qemu-ppc@nongnu.org>
Cc: Blue Swirl <blauwirbel@gmail.com>
Cc: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Riku Voipio <riku.voipio@iki.fi>

v1 -> v2:
* Handle cpu_xxx_init() failure gracefully by replacing the cpu_init() macros
  with static inline functions checking the return value. Reported by Peter.

Andreas Färber (74):
  target-arm: Use cpu_reset() in cpu_arm_init()
  target-mips: Use cpu_reset() in cpu_mips_init()
  target-i386: Pass X86CPU to do_cpu_{init,sipi}()
  target-i386: Let cpu_x86_init() return X86CPU
  pc: Use cpu_x86_init() to obtain X86CPU
  pc: Pass X86CPU to pc_cpu_reset()
  target-sparc: Let cpu_sparc_init() return SPARCCPU
  sun4m: Use cpu_sparc_init() to obtain SPARCCPU
  sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
  sun4u: Use cpu_sparc_init() to obtain SPARCCPU
  sun4u: Let cpu_devinit() return SPARCCPU
  sun4u: Store SPARCCPU in ResetData
  leon3: Use cpu_sparc_init() to obtain SPARCCPU
  leon3: Store SPARCCPU in ResetData
  target-ppc: Let cpu_ppc_init() return PowerPCCPU
  ppce500_mpc8544ds: Pass PowerPCCPU to mpc8544ds_cpu_reset[_sec]
  spapr: Use cpu_ppc_init() to obtain PowerPCCPU
  spapr: Pass PowerPCCPU to spapr_cpu_reset()
  ppc440_bamboo: Use cpu_ppc_init() to obtain PowerPCCPU
  ppc440_bamboo: Pass PowerPCCPU to main_cpu_reset()
  ppc4xx_devs: Use cpu_ppc_init() to obtain PowerPCCPU
  ppc4xx_devs: Pass PowerPCCPU to ppc4xx_reset()
  ppc_newworld: Use cpu_ppc_init() to obtain PowerPCCPU
  ppc_newworld: Pass PowerPCCPU to ppc_core99_reset()
  ppc_oldworld: Use cpu_ppc_init() to obtain PowerPCCPU
  ppc_oldworld: Pass PowerPCCPU to ppc_heathrow_reset()
  ppc_prep: Use cpu_ppc_init() to obtain PowerPCCPU
  ppc_prep: Pass PowerPCCPU to ppc_prep_reset()
  virtex_ml507: Use cpu_ppc_init() to obtain PowerPCCPU
  virtex_ml507: Let ppc440_init_xilinx() return PowerPCCPU
  virtex_ml507: Pass PowerPCCPU to main_cpu_reset()
  cpu-exec: Use cpu_reset() in cpu_exec() for TARGET_PPC
  pxa2xx: Use cpu_arm_init() and store ARMCPU
  omap: Use cpu_arm_init() to store ARMCPU in omap_mpu_state_s
  armv7m: Use cpu_arm_init() to obtain ARMCPU
  armv7m: Pass ARMCPU to armv7m_reset()
  arm_boot: Pass ARMCPU to do_cpu_reset()
  target-sh4: Let cpu_sh4_init() return SuperHCPU
  r2d: Use cpu_sh4_init() to obtain SuperHCPU
  r2d: Store SuperHCPU in ResetData
  target-lm32: Let cpu_lm32_init() return LM32CPU
  lm32_boards: Use cpu_lm32_init() to obtain LM32CPU
  lm32_boards: Store LM32CPU in ResetInfo
  milkymist: Use cpu_lm32_init() to obtain LM32CPU
  milkymist: Store LM32 in ResetInfo
  target-xtensa: Let cpu_xtensa_init() return XtensaCPU
  xtensa_sim: Use cpu_xtensa_init() to obtain XtensaCPU
  xtensa_sim: Pass XtensaCPU to sim_reset()
  xtensa_lx60: Use cpu_xtensa_init() to obtain XtensaCPU
  xtensa_lx60: Pass XtensaCPU to lx60_reset()
  target-cris: Reindent cpu_cris_init()
  target-cris: Let cpu_cris_init() return CRISCPU
  axis_dev88: Use cpu_cris_init() to obtain CRISCPU
  cris-boot: Pass CRISCPU to cris_load_image()
  cris-boot: Pass CRISCPU to main_cpu_reset().
  target-microblaze: Let cpu_mb_init() return MicroBlazeCPU
  petalogix_ml605: Use cpu_mb_init() to obtain MicroBlazeCPU
  petalogix_s3adsp1800_mmu: Use cpu_mb_init() to obtain MicroBlazeCPU
  microblaze_boot: Pass MicroBlazeCPU to microblaze_load_kernel()
  target-mips: Use cpu_reset() in do_interrupt()
  target-mips: Let cpu_mips_init() return MIPSCPU
  mips_fulong2e: Use cpu_mips_cpu() to obtain MIPSCPU
  mips_fulong2e: Pass MIPSCPU to main_cpu_reset()
  mips_jazz: Use cpu_mips_init() to obtain MIPSCPU
  mips_jazz: Pass MIPSCPU to main_cpu_reset()
  mips_malta: Use cpu_mips_init() to obtain MIPSCPU
  mips_malta: Pass MIPSCPU to main_cpu_reset()
  mips_mipssim: Use cpu_mips_init() to obtain MIPSCPU
  mips_mipssim: Store MIPSCPU in ResetData
  mips_r4k: Use cpu_mips_init() to obtain MIPSCPU
  mips_r4k: Store MIPSCPU in ResetData
  bsd-user: Use cpu_reset() in after cpu_init()
  linux-user: Use cpu_reset() after cpu_init() / cpu_copy()
  Kill off cpu_state_reset()

 bsd-user/main.c               |    2 +-
 cpu-all.h                     |    1 -
 cpu-exec.c                    |    9 ++-
 hw/arm_boot.c                 |    9 ++-
 hw/armv7m.c                   |   15 ++++--
 hw/axis_dev88.c               |    6 ++-
 hw/cris-boot.c                |   10 ++--
 hw/cris-boot.h                |    2 +-
 hw/leon3.c                    |   14 +++--
 hw/lm32_boards.c              |   18 ++++---
 hw/mainstone.c                |    2 +-
 hw/microblaze_boot.c          |   16 +++---
 hw/microblaze_boot.h          |    4 +-
 hw/milkymist.c                |   12 +++--
 hw/mips_fulong2e.c            |   13 +++--
 hw/mips_jazz.c                |   13 +++--
 hw/mips_malta.c               |   15 ++++--
 hw/mips_mipssim.c             |   15 +++--
 hw/mips_r4k.c                 |   15 +++--
 hw/nseries.c                  |    6 +-
 hw/omap.h                     |    2 +-
 hw/omap1.c                    |   20 ++++---
 hw/omap2.c                    |    8 ++--
 hw/omap_sx1.c                 |    2 +-
 hw/palm.c                     |    2 +-
 hw/pc.c                       |   19 ++++---
 hw/petalogix_ml605_mmu.c      |   10 +++-
 hw/petalogix_s3adsp1800_mmu.c |   10 +++-
 hw/ppc440_bamboo.c            |   13 +++--
 hw/ppc4xx_devs.c              |   13 +++--
 hw/ppc_newworld.c             |   13 +++--
 hw/ppc_oldworld.c             |   13 +++--
 hw/ppc_prep.c                 |   13 +++--
 hw/ppce500_mpc8544ds.c        |   21 +++++---
 hw/pxa.h                      |    2 +-
 hw/pxa2xx.c                   |   40 +++++++-------
 hw/r2d.c                      |   18 ++++---
 hw/spapr.c                    |   14 +++--
 hw/spitz.c                    |    2 +-
 hw/sun4m.c                    |   20 +++++---
 hw/sun4u.c                    |   25 ++++++----
 hw/tosa.c                     |    2 +-
 hw/virtex_ml507.c             |   27 ++++++----
 hw/xtensa_lx60.c              |   15 +++--
 hw/xtensa_sim.c               |   17 ++++--
 hw/z2.c                       |    2 +-
 linux-user/main.c             |    2 +-
 linux-user/syscall.c          |    2 +-
 target-arm/helper.c           |    7 +--
 target-cris/cpu.h             |   12 ++++-
 target-cris/translate.c       |  110 ++++++++++++++++++++---------------------
 target-i386/cpu.h             |   16 +++++--
 target-i386/helper.c          |   23 ++++-----
 target-i386/kvm.c             |    6 ++-
 target-lm32/cpu.c             |    2 +-
 target-lm32/cpu.h             |   12 ++++-
 target-lm32/helper.c          |   10 +---
 target-m68k/helper.c          |    5 --
 target-microblaze/cpu.h       |   12 ++++-
 target-microblaze/translate.c |   18 ++-----
 target-mips/cpu.h             |   15 +++++-
 target-mips/helper.c          |    3 +-
 target-mips/translate.c       |    6 +-
 target-ppc/cpu.h              |   12 ++++-
 target-ppc/helper.c           |    9 +---
 target-s390x/helper.c         |    9 +---
 target-sh4/cpu.h              |   12 ++++-
 target-sh4/translate.c        |    9 +---
 target-sparc/cpu.c            |    9 +---
 target-sparc/cpu.h            |   17 +++++-
 target-xtensa/cpu.c           |    2 +-
 target-xtensa/cpu.h           |   16 +++++-
 target-xtensa/helper.c        |    9 +---
 73 files changed, 516 insertions(+), 389 deletions(-)

-- 
1.7.7

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 10.05.2012 02:13, schrieb Andreas Färber:
> Andreas Färber (74):
>   target-cris: Reindent cpu_cris_init()
>   target-cris: Let cpu_cris_init() return CRISCPU
>   axis_dev88: Use cpu_cris_init() to obtain CRISCPU
>   cris-boot: Pass CRISCPU to cris_load_image()
>   cris-boot: Pass CRISCPU to main_cpu_reset().
>   target-microblaze: Let cpu_mb_init() return MicroBlazeCPU
>   petalogix_ml605: Use cpu_mb_init() to obtain MicroBlazeCPU
>   petalogix_s3adsp1800_mmu: Use cpu_mb_init() to obtain MicroBlazeCPU
>   microblaze_boot: Pass MicroBlazeCPU to microblaze_load_kernel()
[...]
>   Kill off cpu_state_reset()

Ping! Edgar, can you please ack so that I can apply it to qom-next?

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 10.05.2012 02:13, schrieb Andreas Färber:
> Andreas Färber (74):
[...]
>   target-sparc: Let cpu_sparc_init() return SPARCCPU
>   sun4m: Use cpu_sparc_init() to obtain SPARCCPU
>   sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
>   sun4u: Use cpu_sparc_init() to obtain SPARCCPU
>   sun4u: Let cpu_devinit() return SPARCCPU
>   sun4u: Store SPARCCPU in ResetData
>   leon3: Use cpu_sparc_init() to obtain SPARCCPU
>   leon3: Store SPARCCPU in ResetData
[...]
>   Kill off cpu_state_reset()

Ping! Blue, can you ack please?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Blue Swirl]

On Mon, May 14, 2012 at 4:15 PM, Andreas Färber <afaerber@suse.de> wrote:
> Am 10.05.2012 02:13, schrieb Andreas Färber:
>> Andreas Färber (74):
> [...]
>>   target-sparc: Let cpu_sparc_init() return SPARCCPU
>>   sun4m: Use cpu_sparc_init() to obtain SPARCCPU
>>   sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
>>   sun4u: Use cpu_sparc_init() to obtain SPARCCPU
>>   sun4u: Let cpu_devinit() return SPARCCPU
>>   sun4u: Store SPARCCPU in ResetData
>>   leon3: Use cpu_sparc_init() to obtain SPARCCPU
>>   leon3: Store SPARCCPU in ResetData
> [...]
>>   Kill off cpu_state_reset()
>
> Ping! Blue, can you ack please?

What was again the purpose of all these changes, 00/74 only mentions
killing cpu_state_reset()? For example two CPU types (SPARCCPU vs.
CPUSPARCState) doesn't look very useful, is that needed?

Otherwise the patches look pretty safe ("if it compiles, it works").

>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 14.05.2012 21:54, schrieb Blue Swirl:
> On Mon, May 14, 2012 at 4:15 PM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 10.05.2012 02:13, schrieb Andreas Färber:
>>> Andreas Färber (74):
>> [...]
>>>   target-sparc: Let cpu_sparc_init() return SPARCCPU
>>>   sun4m: Use cpu_sparc_init() to obtain SPARCCPU
>>>   sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
>>>   sun4u: Use cpu_sparc_init() to obtain SPARCCPU
>>>   sun4u: Let cpu_devinit() return SPARCCPU
>>>   sun4u: Store SPARCCPU in ResetData
>>>   leon3: Use cpu_sparc_init() to obtain SPARCCPU
>>>   leon3: Store SPARCCPU in ResetData
>> [...]

Forgot to mention the bsd-user patch.

>>>   Kill off cpu_state_reset()
>>
>> Ping! Blue, can you ack please?
> 
> What was again the purpose of all these changes, 00/74 only mentions
> killing cpu_state_reset()?

cpu_reset(CPUState *) was renamed to cpu_state_reset(CPUArchState *) to
make room for a QOM cpu_reset(CPUState *). This we have now but we still
unneededly have cpu_state_reset() and in particular we have one instance
(mips) where cpu_state_reset() does not forward to cpu_reset(). It
should on sparc. So the goal of this series is to eliminate all callers
of cpu_state_reset(). The safest and cleanest way is to remove it
completely.
The upcoming followup series, part 4, then starts moving
CPUArchState-duplicated fields from CPU_COMMON to the one CPUState, for
which reset code needs to be added that requires cpu_reset() - rather
than cpu_state_reset() - to be called in order to be executed, e.g.
halted. A preview of that can be seen on my GitHub qom-cpu branch - I
still need a QOM-safe way of calling tlb_flush() for VMState without too
much code duplication before I'll submit.

> For example two CPU types (SPARCCPU vs.
> CPUSPARCState) doesn't look very useful, is that needed?

That is outside the scope of this series but I can explain again:
CPUSPARCState is the problematic struct I'm trying to fix:

* I introduced a CPUState struct for QOM TYPE_CPU. This is compiled
twice, once for system mode, once for user mode. This struct so far is
empty. Here common fields are supposed to go (part 4), in a way that
code can be shared across targets (e.g., 13x -softmmu, 1x qom/cpu.o).

* I introduced a SPARCCPU struct for QOM TYPE_SPARC_CPU. This is a
target-specific subclass of TYPE_CPU and is what 1.1 already uses to
create the CPU state internally. This embeds CPUSPARCState.

The way QOM and most object-oriented type systems work is by placing
common fields in the front and adding new ones in the back. As pointed
out by rth this is bad for TCG because we want small offsets to
target-specific register fields for immediate load/stores. env points to
the middle of the CPU, cpu to the front, if you will. So we still need
CPUSPARCState, just not for everything.

As common or target-specific fields get moved to or added to CPUState /
SPARCPU, it becomes difficult to "jailbreak" CPUSPARCState -
sparc_env_get_cpu() and generalized ENV_GET_CPU() macro are ways to do
so. To avoid their use and the runtime casts they bring along, I am
first propagating the use of the larger type, SPARCCPU, throughout the
parts of code that will use it. CPUSPARCState can then be cheaply
accessed through cpu->env.

The purpose as before is to speed up compilation, by factoring out
common code (using CPUState) that does not need to be compiled for each
CPUxxxState with their varying field offsets, and to allow for mixing
CPU cores (with some contraints) within one executable, by making
CPUState more self-describing.

Cf. http://wiki.qemu.org/Features/QOM/CPU

CPUSPARCState is what still makes having subclasses of SPARCCPU with
additional fields tricky - they would get added to the end after some of
the large CPU_COMMON fields, so accessing them from TCG gets ugly.

And SPARCCPU is the type that gives access to SPARCCPUClass, where
constant data specific to one type can be obtained from, i.e. what is
now sparc_def_t. There we'll (you'll) need to decide whether you want to
keep it declarative, which will lead to field duplication between
sparc_def_t/SPARCCPUInfo and SPARCCPUClass due to late instantiation, or
make it imperative, which needs closer review to not introduce errors
when rewriting all the type definitions.

HTE,

Andreas

> Otherwise the patches look pretty safe ("if it compiles, it works").

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Blue Swirl]

On Mon, May 14, 2012 at 8:59 PM, Andreas Färber <afaerber@suse.de> wrote:
> Am 14.05.2012 21:54, schrieb Blue Swirl:
>> On Mon, May 14, 2012 at 4:15 PM, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 10.05.2012 02:13, schrieb Andreas Färber:
>>>> Andreas Färber (74):
>>> [...]
>>>>   target-sparc: Let cpu_sparc_init() return SPARCCPU
>>>>   sun4m: Use cpu_sparc_init() to obtain SPARCCPU
>>>>   sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
>>>>   sun4u: Use cpu_sparc_init() to obtain SPARCCPU
>>>>   sun4u: Let cpu_devinit() return SPARCCPU
>>>>   sun4u: Store SPARCCPU in ResetData
>>>>   leon3: Use cpu_sparc_init() to obtain SPARCCPU
>>>>   leon3: Store SPARCCPU in ResetData
>>> [...]
>
> Forgot to mention the bsd-user patch.
>
>>>>   Kill off cpu_state_reset()
>>>
>>> Ping! Blue, can you ack please?
>>
>> What was again the purpose of all these changes, 00/74 only mentions
>> killing cpu_state_reset()?
>
> cpu_reset(CPUState *) was renamed to cpu_state_reset(CPUArchState *) to
> make room for a QOM cpu_reset(CPUState *). This we have now but we still
> unneededly have cpu_state_reset() and in particular we have one instance
> (mips) where cpu_state_reset() does not forward to cpu_reset(). It
> should on sparc. So the goal of this series is to eliminate all callers
> of cpu_state_reset(). The safest and cleanest way is to remove it
> completely.
> The upcoming followup series, part 4, then starts moving
> CPUArchState-duplicated fields from CPU_COMMON to the one CPUState, for
> which reset code needs to be added that requires cpu_reset() - rather
> than cpu_state_reset() - to be called in order to be executed, e.g.
> halted. A preview of that can be seen on my GitHub qom-cpu branch - I
> still need a QOM-safe way of calling tlb_flush() for VMState without too
> much code duplication before I'll submit.
>
>> For example two CPU types (SPARCCPU vs.
>> CPUSPARCState) doesn't look very useful, is that needed?
>
> That is outside the scope of this series but I can explain again:
> CPUSPARCState is the problematic struct I'm trying to fix:
>
> * I introduced a CPUState struct for QOM TYPE_CPU. This is compiled
> twice, once for system mode, once for user mode. This struct so far is
> empty. Here common fields are supposed to go (part 4), in a way that
> code can be shared across targets (e.g., 13x -softmmu, 1x qom/cpu.o).
>
> * I introduced a SPARCCPU struct for QOM TYPE_SPARC_CPU. This is a
> target-specific subclass of TYPE_CPU and is what 1.1 already uses to
> create the CPU state internally. This embeds CPUSPARCState.
>
> The way QOM and most object-oriented type systems work is by placing
> common fields in the front and adding new ones in the back. As pointed
> out by rth this is bad for TCG because we want small offsets to
> target-specific register fields for immediate load/stores. env points to
> the middle of the CPU, cpu to the front, if you will. So we still need
> CPUSPARCState, just not for everything.
>
> As common or target-specific fields get moved to or added to CPUState /
> SPARCPU, it becomes difficult to "jailbreak" CPUSPARCState -
> sparc_env_get_cpu() and generalized ENV_GET_CPU() macro are ways to do
> so. To avoid their use and the runtime casts they bring along, I am
> first propagating the use of the larger type, SPARCCPU, throughout the
> parts of code that will use it. CPUSPARCState can then be cheaply
> accessed through cpu->env.
>
> The purpose as before is to speed up compilation, by factoring out
> common code (using CPUState) that does not need to be compiled for each
> CPUxxxState with their varying field offsets, and to allow for mixing
> CPU cores (with some contraints) within one executable, by making
> CPUState more self-describing.

Excellent goals!

>
> Cf. http://wiki.qemu.org/Features/QOM/CPU
>
> CPUSPARCState is what still makes having subclasses of SPARCCPU with
> additional fields tricky - they would get added to the end after some of
> the large CPU_COMMON fields, so accessing them from TCG gets ugly.

Can't we move the TLB to common code? Why can't SPARCCPU contain
everything that CPUSPARCState had minus common items? Also, TCG
softmmu functions could use pointers to CPUTLB directly, then the slow
path could recover CPUState or others with container_of().

> And SPARCCPU is the type that gives access to SPARCCPUClass, where
> constant data specific to one type can be obtained from, i.e. what is
> now sparc_def_t. There we'll (you'll) need to decide whether you want to
> keep it declarative, which will lead to field duplication between
> sparc_def_t/SPARCCPUInfo and SPARCCPUClass due to late instantiation, or
> make it imperative, which needs closer review to not introduce errors
> when rewriting all the type definitions.
>
> HTE,
>
> Andreas
>
>> Otherwise the patches look pretty safe ("if it compiles, it works").
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 14.05.2012 23:22, schrieb Blue Swirl:
> On Mon, May 14, 2012 at 8:59 PM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 14.05.2012 21:54, schrieb Blue Swirl:
>>> On Mon, May 14, 2012 at 4:15 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 10.05.2012 02:13, schrieb Andreas Färber:
>>>>> Andreas Färber (74):
>>>> [...]
>>>>>   target-sparc: Let cpu_sparc_init() return SPARCCPU
>>>>>   sun4m: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>   sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
>>>>>   sun4u: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>   sun4u: Let cpu_devinit() return SPARCCPU
>>>>>   sun4u: Store SPARCCPU in ResetData
>>>>>   leon3: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>   leon3: Store SPARCCPU in ResetData
>>>> [...]
>>
>> Forgot to mention the bsd-user patch.
>>
>>>>>   Kill off cpu_state_reset()
>>>>
>>>> Ping! Blue, can you ack please?
>>>
>>> What was again the purpose of all these changes, 00/74 only mentions
>>> killing cpu_state_reset()?
[...]
>> Cf. http://wiki.qemu.org/Features/QOM/CPU
>>
>> CPUSPARCState is what still makes having subclasses of SPARCCPU with
>> additional fields tricky - they would get added to the end after some of
>> the large CPU_COMMON fields, so accessing them from TCG gets ugly.
> 
> Can't we move the TLB to common code?

The TLB depends on both target_ulong and target_phys_addr_t, so we get a
matrix of 32/32, 32/64, 64/64 at least, for which we don't have a
common-code compilation mechanism to date.

> Why can't SPARCCPU contain
> everything that CPUSPARCState had minus common items?

The common items I'm working on and it became clearer that cpu_copy() is
broken as it is, so I won't hold back that series any longer.

If we move all fields from CPUSPARCState to SPARCCPU, what pointer would
you pass as AREG0?

In C code a pointer to the start of the CPU would certainly be handier
but it was brought up that any large, rarely needed common fields at the
start (CPUState) would contribute to imm overflows for, e.g., SPARCCPU
fields such as GPRs etc.

> Also, TCG
> softmmu functions could use pointers to CPUTLB directly, then the slow
> path could recover CPUState or others with container_of().

Having messed in TCG code not too long ago, I would appreciate your
help. The current ppc/ppc64 code at least relies on indexed TLB loads
from AREG0 aka env. Pointer dereferences in generated code to get to an
external TLB object might impact performance...

>>> Otherwise the patches look pretty safe ("if it compiles, it works").

Was I supposed to interpret that as an Acked-by? ;)

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Blue Swirl]

On Mon, May 21, 2012 at 9:09 AM, Andreas Färber <afaerber@suse.de> wrote:
> Am 14.05.2012 23:22, schrieb Blue Swirl:
>> On Mon, May 14, 2012 at 8:59 PM, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 14.05.2012 21:54, schrieb Blue Swirl:
>>>> On Mon, May 14, 2012 at 4:15 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>>> Am 10.05.2012 02:13, schrieb Andreas Färber:
>>>>>> Andreas Färber (74):
>>>>> [...]
>>>>>>   target-sparc: Let cpu_sparc_init() return SPARCCPU
>>>>>>   sun4m: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>   sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
>>>>>>   sun4u: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>   sun4u: Let cpu_devinit() return SPARCCPU
>>>>>>   sun4u: Store SPARCCPU in ResetData
>>>>>>   leon3: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>   leon3: Store SPARCCPU in ResetData
>>>>> [...]
>>>
>>> Forgot to mention the bsd-user patch.
>>>
>>>>>>   Kill off cpu_state_reset()
>>>>>
>>>>> Ping! Blue, can you ack please?
>>>>
>>>> What was again the purpose of all these changes, 00/74 only mentions
>>>> killing cpu_state_reset()?
> [...]
>>> Cf. http://wiki.qemu.org/Features/QOM/CPU
>>>
>>> CPUSPARCState is what still makes having subclasses of SPARCCPU with
>>> additional fields tricky - they would get added to the end after some of
>>> the large CPU_COMMON fields, so accessing them from TCG gets ugly.
>>
>> Can't we move the TLB to common code?
>
> The TLB depends on both target_ulong and target_phys_addr_t, so we get a
> matrix of 32/32, 32/64, 64/64 at least, for which we don't have a
> common-code compilation mechanism to date.

Blah.

>> Why can't SPARCCPU contain
>> everything that CPUSPARCState had minus common items?
>
> The common items I'm working on and it became clearer that cpu_copy() is
> broken as it is, so I won't hold back that series any longer.
>
> If we move all fields from CPUSPARCState to SPARCCPU, what pointer would
> you pass as AREG0?
>
> In C code a pointer to the start of the CPU would certainly be handier
> but it was brought up that any large, rarely needed common fields at the
> start (CPUState) would contribute to imm overflows for, e.g., SPARCCPU
> fields such as GPRs etc.
>
>> Also, TCG
>> softmmu functions could use pointers to CPUTLB directly, then the slow
>> path could recover CPUState or others with container_of().
>
> Having messed in TCG code not too long ago, I would appreciate your
> help. The current ppc/ppc64 code at least relies on indexed TLB loads
> from AREG0 aka env. Pointer dereferences in generated code to get to an
> external TLB object might impact performance...

I was thinking about the reverse, TLB accesses in the fast (hit) path
would get the most direct pointer. Only in the slow path, perform
container_of(CPUXState, TLB, tlb) (or what was the syntax again).

>
>>>> Otherwise the patches look pretty safe ("if it compiles, it works").
>
> Was I supposed to interpret that as an Acked-by? ;)

No, but you may do so if it compiles. ;-)

>
> Thanks,
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 21.05.2012 20:20, schrieb Blue Swirl:
> On Mon, May 21, 2012 at 9:09 AM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 14.05.2012 23:22, schrieb Blue Swirl:
>>> On Mon, May 14, 2012 at 8:59 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 14.05.2012 21:54, schrieb Blue Swirl:
>>>>> On Mon, May 14, 2012 at 4:15 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>>>> Am 10.05.2012 02:13, schrieb Andreas Färber:
>>>>>>> Andreas Färber (74):
>>>>>> [...]
>>>>>>>   target-sparc: Let cpu_sparc_init() return SPARCCPU
>>>>>>>   sun4m: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>>   sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
>>>>>>>   sun4u: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>>   sun4u: Let cpu_devinit() return SPARCCPU
>>>>>>>   sun4u: Store SPARCCPU in ResetData
>>>>>>>   leon3: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>>   leon3: Store SPARCCPU in ResetData
>>>>>> [...]
>>>>
>>>> Forgot to mention the bsd-user patch.
>>>>
>>>>>>>   Kill off cpu_state_reset()
>>>>>>
>>>>>> Ping! Blue, can you ack please?
>>>>>
>>>>> Otherwise the patches look pretty safe ("if it compiles, it works").
>>
>> Was I supposed to interpret that as an Acked-by? ;)
> 
> No, but you may do so if it compiles. ;-)

Joking, are we? My cover letter indicated pretty clearly on what
platforms I had already compile-tested on, and that meant each patch.
I had also run `make check` on each and the sparc test image for sun4m,
HelenOS for sun4u and "crible" for leon3.

Applied the remainder of the series to qom-next:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next

Tristan/Fabien, could you please submit a patch to document the Leon3
machine in MAINTAINERS? No one got cc'ed on those two patches. Thanks.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Fabien Chouteau]

On 05/22/2012 02:34 AM, Andreas Färber wrote:
> Am 21.05.2012 20:20, schrieb Blue Swirl:
>> On Mon, May 21, 2012 at 9:09 AM, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 14.05.2012 23:22, schrieb Blue Swirl:
>>>> On Mon, May 14, 2012 at 8:59 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>>> Am 14.05.2012 21:54, schrieb Blue Swirl:
>>>>>> On Mon, May 14, 2012 at 4:15 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>>>>> Am 10.05.2012 02:13, schrieb Andreas Färber:
>>>>>>>> Andreas Färber (74):
>>>>>>> [...]
>>>>>>>>   target-sparc: Let cpu_sparc_init() return SPARCCPU
>>>>>>>>   sun4m: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>>>   sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
>>>>>>>>   sun4u: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>>>   sun4u: Let cpu_devinit() return SPARCCPU
>>>>>>>>   sun4u: Store SPARCCPU in ResetData
>>>>>>>>   leon3: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>>>   leon3: Store SPARCCPU in ResetData
>>>>>>> [...]
>>>>>
>>>>> Forgot to mention the bsd-user patch.
>>>>>
>>>>>>>>   Kill off cpu_state_reset()
>>>>>>>
>>>>>>> Ping! Blue, can you ack please?
>>>>>>
>>>>>> Otherwise the patches look pretty safe ("if it compiles, it works").
>>>
>>> Was I supposed to interpret that as an Acked-by? ;)
>>
>> No, but you may do so if it compiles. ;-)
> 
> Joking, are we? My cover letter indicated pretty clearly on what
> platforms I had already compile-tested on, and that meant each patch.
> I had also run `make check` on each and the sparc test image for sun4m,
> HelenOS for sun4u and "crible" for leon3.
> 
> Applied the remainder of the series to qom-next:
> http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next
> 
> Tristan/Fabien, could you please submit a patch to document the Leon3
> machine in MAINTAINERS? No one got cc'ed on those two patches. Thanks.
> 

OK, I'll send a patch.

-- 
Fabien Chouteau

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Blue Swirl]

On Tue, May 22, 2012 at 12:34 AM, Andreas Färber <afaerber@suse.de> wrote:
> Am 21.05.2012 20:20, schrieb Blue Swirl:
>> On Mon, May 21, 2012 at 9:09 AM, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 14.05.2012 23:22, schrieb Blue Swirl:
>>>> On Mon, May 14, 2012 at 8:59 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>>> Am 14.05.2012 21:54, schrieb Blue Swirl:
>>>>>> On Mon, May 14, 2012 at 4:15 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>>>>> Am 10.05.2012 02:13, schrieb Andreas Färber:
>>>>>>>> Andreas Färber (74):
>>>>>>> [...]
>>>>>>>>   target-sparc: Let cpu_sparc_init() return SPARCCPU
>>>>>>>>   sun4m: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>>>   sun4m: Pass SPARCCPU to {main,secondary}_cpu_reset()
>>>>>>>>   sun4u: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>>>   sun4u: Let cpu_devinit() return SPARCCPU
>>>>>>>>   sun4u: Store SPARCCPU in ResetData
>>>>>>>>   leon3: Use cpu_sparc_init() to obtain SPARCCPU
>>>>>>>>   leon3: Store SPARCCPU in ResetData
>>>>>>> [...]
>>>>>
>>>>> Forgot to mention the bsd-user patch.
>>>>>
>>>>>>>>   Kill off cpu_state_reset()
>>>>>>>
>>>>>>> Ping! Blue, can you ack please?
>>>>>>
>>>>>> Otherwise the patches look pretty safe ("if it compiles, it works").
>>>
>>> Was I supposed to interpret that as an Acked-by? ;)
>>
>> No, but you may do so if it compiles. ;-)
>
> Joking, are we? My cover letter indicated pretty clearly on what
> platforms I had already compile-tested on, and that meant each patch.
> I had also run `make check` on each and the sparc test image for sun4m,
> HelenOS for sun4u and "crible" for leon3.

OK,
Acked-by: Blue Swirl <blauwirbel@gmail.com>

>
> Applied the remainder of the series to qom-next:
> http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next
>
> Tristan/Fabien, could you please submit a patch to document the Leon3
> machine in MAINTAINERS? No one got cc'ed on those two patches. Thanks.
>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Igor Mammedov]

On Thu, May 10, 2012 at 02:13:38AM +0200, Andreas Färber wrote:
>   target-i386: Pass X86CPU to do_cpu_{init,sipi}()
>   target-i386: Let cpu_x86_init() return X86CPU
>   pc: Use cpu_x86_init() to obtain X86CPU
>   pc: Pass X86CPU to pc_cpu_reset()

Reviewed-by: Igor Mammedov <imammedo@redhat.com>

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 15.05.2012 17:16, schrieb Igor Mammedov:
> On Thu, May 10, 2012 at 02:13:38AM +0200, Andreas Färber wrote:
>>   target-i386: Pass X86CPU to do_cpu_{init,sipi}()
>>   target-i386: Let cpu_x86_init() return X86CPU
>>   pc: Use cpu_x86_init() to obtain X86CPU
>>   pc: Pass X86CPU to pc_cpu_reset()
> 
> Reviewed-by: Igor Mammedov <imammedo@redhat.com>

Thanks, applied to qom-next:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 10.05.2012 02:13, schrieb Andreas Färber:
> Andreas Färber (74):
[...]
>   target-sh4: Let cpu_sh4_init() return SuperHCPU
>   r2d: Use cpu_sh4_init() to obtain SuperHCPU
>   r2d: Store SuperHCPU in ResetData

Seeing that no one currently cares about sh4, I have re-tested the r2d
test image and applied these to qom-next:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next

I'm still hoping that someone will ack the remaining mips ones though...

/-F

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset

[Andreas Färber]

Am 10.05.2012 02:13, schrieb Andreas Färber:
> Andreas Färber (74):
[...]
>   target-mips: Use cpu_reset() in cpu_mips_init()
[...]
>   target-mips: Use cpu_reset() in do_interrupt()
>   target-mips: Let cpu_mips_init() return MIPSCPU
>   mips_fulong2e: Use cpu_mips_cpu() to obtain MIPSCPU
>   mips_fulong2e: Pass MIPSCPU to main_cpu_reset()
>   mips_jazz: Use cpu_mips_init() to obtain MIPSCPU
>   mips_jazz: Pass MIPSCPU to main_cpu_reset()
>   mips_malta: Use cpu_mips_init() to obtain MIPSCPU
>   mips_malta: Pass MIPSCPU to main_cpu_reset()
>   mips_mipssim: Use cpu_mips_init() to obtain MIPSCPU
>   mips_mipssim: Store MIPSCPU in ResetData
>   mips_r4k: Use cpu_mips_init() to obtain MIPSCPU
>   mips_r4k: Store MIPSCPU in ResetData

Since no one seems to care about these mips patches beyond jazz ATM,
I've applied these to qom-next:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next

If there's any issue or someone wants to add a tag after all, just let
me know.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg