[PATCH v2 3/5] target/mips: Demacro helpers for .

[Aleksandar Markovic]

Remove function definitions via macros to achieve better code clarity.

Signed-off-by: Aleksandar Markovic 
---
 target/mips/fpu_helper.c | 104 ---
 1 file changed, 81 insertions(+), 23 deletions(-)

diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
index b3c7154..6cc956c 100644
--- a/target/mips/fpu_helper.c
+++ b/target/mips/fpu_helper.c
@@ -1475,29 +1475,87 @@ uint64_t helper_float_mulr_ps(CPUMIPSState *env, 
uint64_t fdt0, uint64_t fdt1)
 return ((uint64_t)fsth2 << 32) | fstl2;
 }
 
-#define FLOAT_MINMAX(name, bits, minmaxfunc)\
-uint ## bits ## _t helper_float_ ## name(CPUMIPSState *env, \
- uint ## bits ## _t fs, \
- uint ## bits ## _t ft) \
-{   \
-uint ## bits ## _t fdret;   \
-\
-fdret = float ## bits ## _ ## minmaxfunc(fs, ft,\
-   >active_fpu.fp_status); \
-update_fcr31(env, GETPC()); \
-return fdret;   \
-}
-
-FLOAT_MINMAX(max_s, 32, maxnum)
-FLOAT_MINMAX(max_d, 64, maxnum)
-FLOAT_MINMAX(maxa_s, 32, maxnummag)
-FLOAT_MINMAX(maxa_d, 64, maxnummag)
-
-FLOAT_MINMAX(min_s, 32, minnum)
-FLOAT_MINMAX(min_d, 64, minnum)
-FLOAT_MINMAX(mina_s, 32, minnummag)
-FLOAT_MINMAX(mina_d, 64, minnummag)
-#undef FLOAT_MINMAX
+
+uint32_t helper_float_max_s(CPUMIPSState *env, uint32_t fs, uint32_t ft)
+{
+uint32_t fdret;
+
+fdret = float32_maxnum(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_max_d(CPUMIPSState *env, uint64_t fs, uint64_t ft)
+{
+uint64_t fdret;
+
+fdret = float64_maxnum(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint32_t helper_float_maxa_s(CPUMIPSState *env, uint32_t fs, uint32_t ft)
+{
+uint32_t fdret;
+
+fdret = float32_maxnummag(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_maxa_d(CPUMIPSState *env, uint64_t fs, uint64_t ft)
+{
+uint64_t fdret;
+
+fdret = float64_maxnummag(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint32_t helper_float_min_s(CPUMIPSState *env, uint32_t fs, uint32_t ft)
+{
+uint32_t fdret;
+
+fdret = float32_minnum(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_min_d(CPUMIPSState *env, uint64_t fs, uint64_t ft)
+{
+uint64_t fdret;
+
+fdret = float64_minnum(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint32_t helper_float_mina_s(CPUMIPSState *env, uint32_t fs, uint32_t ft)
+{
+uint32_t fdret;
+
+fdret = float32_minnummag(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_mina_d(CPUMIPSState *env, uint64_t fs, uint64_t ft)
+{
+uint64_t fdret;
+
+fdret = float64_minnummag(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
 
 /* ternary operations */
 
-- 
2.7.4

[PATCH v2 2/5] target/mips: Demacro helpers for MF.

[Aleksandar Markovic]

Remove function definitions via macros to achieve better code clarity.

Signed-off-by: Aleksandar Markovic 
---
 target/mips/fpu_helper.c | 63 +++-
 1 file changed, 46 insertions(+), 17 deletions(-)

diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
index f851723..b3c7154 100644
--- a/target/mips/fpu_helper.c
+++ b/target/mips/fpu_helper.c
@@ -1666,25 +1666,54 @@ uint64_t helper_float_nmsub_ps(CPUMIPSState *env, 
uint64_t fdt0,
 }
 
 
-#define FLOAT_FMADDSUB(name, bits, muladd_arg)  \
-uint ## bits ## _t helper_float_ ## name(CPUMIPSState *env, \
- uint ## bits ## _t fs, \
- uint ## bits ## _t ft, \
- uint ## bits ## _t fd) \
-{   \
-uint ## bits ## _t fdret;   \
-\
-fdret = float ## bits ## _muladd(fs, ft, fd, muladd_arg,\
- >active_fpu.fp_status);   \
-update_fcr31(env, GETPC()); \
-return fdret;   \
+uint32_t helper_float_maddf_s(CPUMIPSState *env, uint32_t fs,
+  uint32_t ft, uint32_t fd)
+{
+uint32_t fdret;
+
+fdret = float32_muladd(fs, ft, fd, 0,
+   >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_maddf_d(CPUMIPSState *env, uint64_t fs,
+  uint64_t ft, uint64_t fd)
+{
+uint64_t fdret;
+
+fdret = float64_muladd(fs, ft, fd, 0,
+   >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint32_t helper_float_msubf_s(CPUMIPSState *env, uint32_t fs,
+  uint32_t ft, uint32_t fd)
+{
+uint32_t fdret;
+
+fdret = float32_muladd(fs, ft, fd, float_muladd_negate_product,
+   >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_msubf_d(CPUMIPSState *env, uint64_t fs,
+  uint64_t ft, uint64_t fd)
+{
+uint64_t fdret;
+
+fdret = float64_muladd(fs, ft, fd, float_muladd_negate_product,
+   >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
 }
 
-FLOAT_FMADDSUB(maddf_s, 32, 0)
-FLOAT_FMADDSUB(maddf_d, 64, 0)
-FLOAT_FMADDSUB(msubf_s, 32, float_muladd_negate_product)
-FLOAT_FMADDSUB(msubf_d, 64, float_muladd_negate_product)
-#undef FLOAT_FMADDSUB
 
 /* compare operations */
 #define FOP_COND_D(op, cond)   \
-- 
2.7.4

[PATCH v2 5/5] MAINTAINERS: Remove myself

[Aleksandar Markovic]

I have been working on project other than QEMU for some time, and would
like to devote myself to that project. It is imposible for me to find
enough time to perform maintainer's duties with needed meticulousness
and patience.

I wish prosperous future to QEMU and all colegues in QEMU community.

Signed-off-by: Aleksandar Markovic 
---
 MAINTAINERS | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e9d85cc..426f52c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -221,11 +221,10 @@ F: hw/microblaze/
 F: disas/microblaze.c
 
 MIPS TCG CPUs
-M: Aleksandar Markovic 
 R: Aurelien Jarno 
 R: Jiaxun Yang 
 R: Aleksandar Rikalo 
-S: Maintained
+S: Orphaned
 F: target/mips/
 F: default-configs/*mips*
 F: disas/*mips*
@@ -387,7 +386,6 @@ F: target/arm/kvm.c
 
 MIPS KVM CPUs
 M: Huacai Chen 
-M: Aleksandar Markovic 
 S: Odd Fixes
 F: target/mips/kvm.c
 
@@ -1124,10 +1122,9 @@ F: hw/display/jazz_led.c
 F: hw/dma/rc4030.c
 
 Malta
-M: Aleksandar Markovic 
 M: Philippe Mathieu-Daudé 
 R: Aurelien Jarno 
-S: Maintained
+S: Odd Fixes
 F: hw/isa/piix4.c
 F: hw/acpi/piix4.c
 F: hw/mips/malta.c
@@ -1137,14 +1134,12 @@ F: tests/acceptance/linux_ssh_mips_malta.py
 F: tests/acceptance/machine_mips_malta.py
 
 Mipssim
-M: Aleksandar Markovic 
 R: Aleksandar Rikalo 
-S: Odd Fixes
+S: Orphaned
 F: hw/mips/mipssim.c
 F: hw/net/mipsnet.c
 
 R4000
-M: Aleksandar Markovic 
 R: Aurelien Jarno 
 R: Aleksandar Rikalo 
 S: Obsolete
@@ -1153,7 +1148,6 @@ F: hw/mips/r4k.c
 Fuloong 2E
 M: Huacai Chen 
 M: Philippe Mathieu-Daudé 
-M: Aleksandar Markovic 
 R: Jiaxun Yang 
 S: Odd Fixes
 F: hw/mips/fuloong2e.c
@@ -2821,12 +2815,11 @@ F: tcg/i386/
 F: disas/i386.c
 
 MIPS TCG target
-M: Aleksandar Markovic 
 R: Aurelien Jarno 
 R: Huacai Chen 
 R: Jiaxun Yang 
 R: Aleksandar Rikalo 
-S: Maintained
+S: Orphaned
 F: tcg/mips/
 
 PPC TCG target
@@ -3167,7 +3160,7 @@ S: Odd Fixes
 F: scripts/git-submodule.sh
 
 UI translations
-M: Aleksandar Markovic 
+S: Orphaned
 F: po/*.po
 
 Sphinx documentation configuration and build machinery
-- 
2.7.4

[PATCH v2 4/5] target/mips: Refactor helpers for fp comparison instructions

[Aleksandar Markovic]

This change causes slighlty better performance of emulation of fp
comparison instructions via better compiler optimization of refactored
code. The functionality is otherwise unchanged.

Signed-off-by: Aleksandar Markovic 
---
 target/mips/fpu_helper.c | 56 +++-
 1 file changed, 32 insertions(+), 24 deletions(-)

diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
index 6cc956c..8d48a5b 100644
--- a/target/mips/fpu_helper.c
+++ b/target/mips/fpu_helper.c
@@ -1780,11 +1780,12 @@ void helper_cmp_d_ ## op(CPUMIPSState *env, uint64_t 
fdt0, \
 {  \
 int c; \
 c = cond;  \
-update_fcr31(env, GETPC());\
-if (c) \
+if (c) {   \
 SET_FP_COND(cc, env->active_fpu);  \
-else   \
+} else {   \
 CLEAR_FP_COND(cc, env->active_fpu);\
+}  \
+update_fcr31(env, GETPC());\
 }  \
 void helper_cmpabs_d_ ## op(CPUMIPSState *env, uint64_t fdt0,  \
 uint64_t fdt1, int cc) \
@@ -1793,11 +1794,12 @@ void helper_cmpabs_d_ ## op(CPUMIPSState *env, uint64_t 
fdt0,  \
 fdt0 = float64_abs(fdt0);  \
 fdt1 = float64_abs(fdt1);  \
 c = cond;  \
-update_fcr31(env, GETPC());\
-if (c) \
+if (c) {   \
 SET_FP_COND(cc, env->active_fpu);  \
-else   \
+} else {   \
 CLEAR_FP_COND(cc, env->active_fpu);\
+}  \
+update_fcr31(env, GETPC());\
 }
 
 /*
@@ -1859,11 +1861,12 @@ void helper_cmp_s_ ## op(CPUMIPSState *env, uint32_t 
fst0, \
 {  \
 int c; \
 c = cond;  \
-update_fcr31(env, GETPC());\
-if (c) \
+if (c) {   \
 SET_FP_COND(cc, env->active_fpu);  \
-else   \
+} else {   \
 CLEAR_FP_COND(cc, env->active_fpu);\
+}  \
+update_fcr31(env, GETPC());\
 }  \
 void helper_cmpabs_s_ ## op(CPUMIPSState *env, uint32_t fst0,  \
 uint32_t fst1, int cc) \
@@ -1872,11 +1875,12 @@ void helper_cmpabs_s_ ## op(CPUMIPSState *env, uint32_t 
fst0,  \
 fst0 = float32_abs(fst0);  \
 fst1 = float32_abs(fst1);  \
 c = cond;  \
-update_fcr31(env, GETPC());\
-if (c) \
+if (c) {   \
 SET_FP_COND(cc, env->active_fpu);  \
-else   \
+} else {   \
 CLEAR_FP_COND(cc, env->active_fpu);\
+}  \
+update_fcr31(env, GETPC());\
 }
 
 /*
@@ -1944,15 +1948,17 @@ void helper_cmp_ps_ ## op(CPUMIPSState *env, uint64_t 
fdt0, \
 fsth1 = fdt1 >> 32; \
 cl = condl; \
 ch = condh; \
-update_fcr31(env, GETPC()); \
-if (cl) \
+if (cl) {   \
 S

[PATCH v2 1/5] target/mips: Demacro helpers for .

[Aleksandar Markovic]

Remove function definitions via macros to achieve better code clarity.

Signed-off-by: Aleksandar Markovic 
---
 target/mips/fpu_helper.c | 61 +++-
 1 file changed, 40 insertions(+), 21 deletions(-)

diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
index 56beda4..f851723 100644
--- a/target/mips/fpu_helper.c
+++ b/target/mips/fpu_helper.c
@@ -983,27 +983,46 @@ uint32_t helper_float_floor_2008_w_s(CPUMIPSState *env, 
uint32_t fst0)
 }
 
 /* unary operations, not modifying fp status  */
-#define FLOAT_UNOP(name)   \
-uint64_t helper_float_ ## name ## _d(uint64_t fdt0)\
-{  \
-return float64_ ## name(fdt0); \
-}  \
-uint32_t helper_float_ ## name ## _s(uint32_t fst0)\
-{  \
-return float32_ ## name(fst0); \
-}  \
-uint64_t helper_float_ ## name ## _ps(uint64_t fdt0)   \
-{  \
-uint32_t wt0;  \
-uint32_t wth0; \
-   \
-wt0 = float32_ ## name(fdt0 & 0X); \
-wth0 = float32_ ## name(fdt0 >> 32);   \
-return ((uint64_t)wth0 << 32) | wt0;   \
-}
-FLOAT_UNOP(abs)
-FLOAT_UNOP(chs)
-#undef FLOAT_UNOP
+
+uint64_t helper_float_abs_d(uint64_t fdt0)
+{
+   return float64_abs(fdt0);
+}
+
+uint32_t helper_float_abs_s(uint32_t fst0)
+{
+return float32_abs(fst0);
+}
+
+uint64_t helper_float_abs_ps(uint64_t fdt0)
+{
+uint32_t wt0;
+uint32_t wth0;
+
+wt0 = float32_abs(fdt0 & 0X);
+wth0 = float32_abs(fdt0 >> 32);
+return ((uint64_t)wth0 << 32) | wt0;
+}
+
+uint64_t helper_float_chs_d(uint64_t fdt0)
+{
+   return float64_chs(fdt0);
+}
+
+uint32_t helper_float_chs_s(uint32_t fst0)
+{
+return float32_chs(fst0);
+}
+
+uint64_t helper_float_chs_ps(uint64_t fdt0)
+{
+uint32_t wt0;
+uint32_t wth0;
+
+wt0 = float32_chs(fdt0 & 0X);
+wth0 = float32_chs(fdt0 >> 32);
+return ((uint64_t)wth0 << 32) | wt0;
+}
 
 /* MIPS specific unary operations */
 uint64_t helper_float_recip_d(CPUMIPSState *env, uint64_t fdt0)
-- 
2.7.4

[PATCH v2 0/5] target/mips: Misc patches

[Aleksandar Markovic]

A set of several, mostly FP, refactorings and improvements.

v1->v2:

  - added a patch on MAINTAINERS

Aleksandar Markovic (5):
  target/mips: Demacro helpers for .
  target/mips: Demacro helpers for MF.
  target/mips: Demacro helpers for .
  target/mips: Refactor helpers for fp comparison instructions
  MAINTAINERS: Remove myself

 target/mips/fpu_helper.c | 276 +--
 MAINTAINERS  |  17 +--
 2 files changed, 200 insertions(+), 93 deletions(-)

-- 
2.7.4

Re: [PATCH 03/16] target/mips/cp0_timer: Explicit unit in variable name

[Aleksandar Markovic]

On Monday, September 28, 2020, Philippe Mathieu-Daudé 
wrote:

> Name variables holding nanoseconds with the '_ns' suffix.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---


Reviewed-by: Aleksandar Markovic 


>  target/mips/cp0_timer.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/target/mips/cp0_timer.c b/target/mips/cp0_timer.c
> index 9c38e9da1c8..5194c967ae3 100644
> --- a/target/mips/cp0_timer.c
> +++ b/target/mips/cp0_timer.c
> @@ -32,13 +32,14 @@
>  /* MIPS R4K timer */
>  static void cpu_mips_timer_update(CPUMIPSState *env)
>  {
> -uint64_t now, next;
> +uint64_t now_ns, next_ns;
>  uint32_t wait;
>
> -now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
> -wait = env->CP0_Compare - env->CP0_Count - (uint32_t)(now /
> TIMER_PERIOD);
> -next = now + (uint64_t)wait * TIMER_PERIOD;
> -timer_mod(env->timer, next);
> +now_ns = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
> +wait = env->CP0_Compare - env->CP0_Count -
> +   (uint32_t)(now_ns / TIMER_PERIOD);
> +next_ns = now_ns + (uint64_t)wait * TIMER_PERIOD;
> +timer_mod(env->timer, next_ns);
>  }
>
>  /* Expire the timer.  */
> @@ -56,16 +57,16 @@ uint32_t cpu_mips_get_count(CPUMIPSState *env)
>  if (env->CP0_Cause & (1 << CP0Ca_DC)) {
>  return env->CP0_Count;
>  } else {
> -uint64_t now;
> +uint64_t now_ns;
>
> -now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
> +now_ns = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
>  if (timer_pending(env->timer)
> -&& timer_expired(env->timer, now)) {
> +&& timer_expired(env->timer, now_ns)) {
>  /* The timer has already expired.  */
>  cpu_mips_timer_expire(env);
>  }
>
> -return env->CP0_Count + (uint32_t)(now / TIMER_PERIOD);
> +return env->CP0_Count + (uint32_t)(now_ns / TIMER_PERIOD);
>  }
>  }
>
> --
> 2.26.2
>
>

Re: [PATCH 02/16] target/mips: Move cpu_mips_get_random() with CP0 helpers

[Aleksandar Markovic]

On Monday, September 28, 2020, Philippe Mathieu-Daudé 
wrote:

> The get_random() helper uses the CP0_Wired register, which is
> unrelated to the CP0_Count register use as timer.
> Commit e16fe40c872 ("Move the MIPS CPU timer in a separate file")
> incorrectly moved this get_random() helper with timer specific
> code. Move it back to generic CP0 helpers.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---


Reviewed-by: Aleksandar Markovic 


>  target/mips/internal.h   |  2 +-
>  target/mips/cp0_helper.c | 25 +
>  target/mips/cp0_timer.c  | 25 -
>  3 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/target/mips/internal.h b/target/mips/internal.h
> index 7f159a9230c..087cabaa6d4 100644
> --- a/target/mips/internal.h
> +++ b/target/mips/internal.h
> @@ -144,6 +144,7 @@ void r4k_helper_tlbr(CPUMIPSState *env);
>  void r4k_helper_tlbinv(CPUMIPSState *env);
>  void r4k_helper_tlbinvf(CPUMIPSState *env);
>  void r4k_invalidate_tlb(CPUMIPSState *env, int idx, int use_extra);
> +uint32_t cpu_mips_get_random(CPUMIPSState *env);
>
>  void mips_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr,
>  vaddr addr, unsigned size,
> @@ -209,7 +210,6 @@ void cpu_state_reset(CPUMIPSState *s);
>  void cpu_mips_realize_env(CPUMIPSState *env);
>
>  /* cp0_timer.c */
> -uint32_t cpu_mips_get_random(CPUMIPSState *env);
>  uint32_t cpu_mips_get_count(CPUMIPSState *env);
>  void cpu_mips_store_count(CPUMIPSState *env, uint32_t value);
>  void cpu_mips_store_compare(CPUMIPSState *env, uint32_t value);
> diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c
> index de64add038b..12143ac55b9 100644
> --- a/target/mips/cp0_helper.c
> +++ b/target/mips/cp0_helper.c
> @@ -203,6 +203,31 @@ static void sync_c0_entryhi(CPUMIPSState *cpu, int tc)
>  *tcst |= asid;
>  }
>
> +/* XXX: do not use a global */
> +uint32_t cpu_mips_get_random(CPUMIPSState *env)
> +{
> +static uint32_t seed = 1;
> +static uint32_t prev_idx;
> +uint32_t idx;
> +uint32_t nb_rand_tlb = env->tlb->nb_tlb - env->CP0_Wired;
> +
> +if (nb_rand_tlb == 1) {
> +return env->tlb->nb_tlb - 1;
> +}
> +
> +/* Don't return same value twice, so get another value */
> +do {
> +/*
> + * Use a simple algorithm of Linear Congruential Generator
> + * from ISO/IEC 9899 standard.
> + */
> +seed = 1103515245 * seed + 12345;
> +idx = (seed >> 16) % nb_rand_tlb + env->CP0_Wired;
> +} while (idx == prev_idx);
> +prev_idx = idx;
> +return idx;
> +}
> +
>  /* CP0 helpers */
>  target_ulong helper_mfc0_mvpcontrol(CPUMIPSState *env)
>  {
> diff --git a/target/mips/cp0_timer.c b/target/mips/cp0_timer.c
> index bd7efb152dd..9c38e9da1c8 100644
> --- a/target/mips/cp0_timer.c
> +++ b/target/mips/cp0_timer.c
> @@ -29,31 +29,6 @@
>
>  #define TIMER_PERIOD 10 /* 10 ns period for 100 Mhz frequency */
>
> -/* XXX: do not use a global */
> -uint32_t cpu_mips_get_random(CPUMIPSState *env)
> -{
> -static uint32_t seed = 1;
> -static uint32_t prev_idx = 0;
> -uint32_t idx;
> -uint32_t nb_rand_tlb = env->tlb->nb_tlb - env->CP0_Wired;
> -
> -if (nb_rand_tlb == 1) {
> -return env->tlb->nb_tlb - 1;
> -}
> -
> -/* Don't return same value twice, so get another value */
> -do {
> -/*
> - * Use a simple algorithm of Linear Congruential Generator
> - * from ISO/IEC 9899 standard.
> - */
> -seed = 1103515245 * seed + 12345;
> -idx = (seed >> 16) % nb_rand_tlb + env->CP0_Wired;
> -} while (idx == prev_idx);
> -prev_idx = idx;
> -return idx;
> -}
> -
>  /* MIPS R4K timer */
>  static void cpu_mips_timer_update(CPUMIPSState *env)
>  {
> --
> 2.26.2
>
>

Re: [PATCH v3 1/1] accel/tcg: Fix computing of is_write for MIPS

[Aleksandar Markovic]

On Sunday, September 27, 2020, Kele Huang  wrote:

> Sorry about that, I only got maintainers by './scripts/get_maintainer.pl
> -f accel/tcg/user-exec.c' and missed your advice about maintainers.
> In another words, I thought I had Cc'ed the TCG MIPS maintainers. 
> And sorry to maintainers. 
>
>>
>>
This is fine, Kele. :)

The granularity of get_maintainer.py is at file level, so this is one of
the cases where you can use your own judgement and include more email
addresses, even though get_maintainer.py doesn't list them.
get_maintainer.py is good most of the time, but not always. But not a big
deal.

Thanks for the patch! :)

I expect Richard is going to include it in his next tcg queue.

Yours,
Aleksandar


> On Sun, 27 Sep 2020 at 16:41, Philippe Mathieu-Daudé 
> wrote:
>
>> On 9/27/20 10:20 AM, Kele Huang wrote:
>> > Detect all MIPS store instructions in cpu_signal_handler for all
>> available
>> > MIPS versions, and set is_write if encountering such store instructions.
>> >
>> > This fixed the error while dealing with self-modified code for MIPS.
>> >
>> > Reviewed-by: Richard Henderson 
>> > Signed-off-by: Kele Huang 
>> > Signed-off-by: Xu Zou 
>>
>> I already Cc'ed the TCG MIPS maintainers twice for you,
>> but you don't mind, so this time I won't insist.
>>
>> > ---
>> >  accel/tcg/user-exec.c | 39 ++-
>> >  1 file changed, 38 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
>> > index bb039eb32d..9ecda6c0d0 100644
>> > --- a/accel/tcg/user-exec.c
>> > +++ b/accel/tcg/user-exec.c
>> > @@ -702,6 +702,10 @@ int cpu_signal_handler(int host_signum, void
>> *pinfo,
>> >
>> >  #elif defined(__mips__)
>> >
>> > +#if defined(__misp16) || defined(__mips_micromips)
>> > +#error "Unsupported encoding"
>> > +#endif
>> > +
>> >  int cpu_signal_handler(int host_signum, void *pinfo,
>> > void *puc)
>> >  {
>> > @@ -709,9 +713,42 @@ int cpu_signal_handler(int host_signum, void
>> *pinfo,
>> >  ucontext_t *uc = puc;
>> >  greg_t pc = uc->uc_mcontext.pc;
>> >  int is_write;
>> > +uint32_t insn;
>> >
>> > -/* XXX: compute is_write */
>> > +/* Detect all store instructions at program counter. */
>> >  is_write = 0;
>> > +insn = *(uint32_t *)pc;
>> > +switch((insn >> 26) & 077) {
>> > +case 050: /* SB */
>> > +case 051: /* SH */
>> > +case 052: /* SWL */
>> > +case 053: /* SW */
>> > +case 054: /* SDL */
>> > +case 055: /* SDR */
>> > +case 056: /* SWR */
>> > +case 070: /* SC */
>> > +case 071: /* SWC1 */
>> > +case 074: /* SCD */
>> > +case 075: /* SDC1 */
>> > +case 077: /* SD */
>> > +#if !defined(__mips_isa_rev) || __mips_isa_rev < 6
>> > +case 072: /* SWC2 */
>> > +case 076: /* SDC2 */
>> > +#endif
>> > +is_write = 1;
>> > +break;
>> > +case 023: /* COP1X */
>> > +/* Required in all versions of MIPS64 since
>> > +   MIPS64r1 and subsequent versions of MIPS32r2. */
>> > +switch (insn & 077) {
>> > +case 010: /* SWXC1 */
>> > +case 011: /* SDXC1 */
>> > +case 015: /* SDXC1 */
>> > +is_write = 1;
>> > +}
>> > +break;
>> > +}
>> > +
>> >  return handle_cpu_signal(pc, info, is_write, >uc_sigmask);
>> >  }
>> >
>> >
>>
>>

Re: [PATCH 1/9] scripts/performance: Refactor topN_perf.py

[Aleksandar Markovic]

On Friday, August 28, 2020, Ahmed Karaman 
wrote:

> - Apply pylint and flake8 formatting rules to the script.
> - Use 'tempfile' instead of '/tmp' for creating temporary files.
>
> Signed-off-by: Ahmed Karaman 
> ---


Hello, folks.

This series seems forgotten. Can some of you perhaps take a look, review,
and possibly integrate some patches in a pull request?

Ahmed invested quite of time to improve the functionality and quality of
scripts, and they are truly useful for developers interested in performance
measurement.

Thanks,
Aleksandar




>  scripts/performance/topN_perf.py | 174 +++
>  1 file changed, 87 insertions(+), 87 deletions(-)
>
> diff --git a/scripts/performance/topN_perf.py b/scripts/performance/topN_
> perf.py
> index 07be195fc8..56b100da87 100755
> --- a/scripts/performance/topN_perf.py
> +++ b/scripts/performance/topN_perf.py
> @@ -1,72 +1,77 @@
>  #!/usr/bin/env python3
>
> -#  Print the top N most executed functions in QEMU using perf.
> -#  Syntax:
> -#  topN_perf.py [-h] [-n]   -- \
> -#[] \
> -#[]
> -#
> -#  [-h] - Print the script arguments help message.
> -#  [-n] - Specify the number of top functions to print.
> -#   - If this flag is not specified, the tool defaults to 25.
> -#
> -#  Example of usage:
> -#  topN_perf.py -n 20 -- qemu-arm coulomb_double-arm
> -#
> -#  This file is a part of the project "TCG Continuous Benchmarking".
> -#
> -#  Copyright (C) 2020  Ahmed Karaman 
> -#  Copyright (C) 2020  Aleksandar Markovic  com>
> -#
> -#  This program is free software: you can redistribute it and/or modify
> -#  it under the terms of the GNU General Public License as published by
> -#  the Free Software Foundation, either version 2 of the License, or
> -#  (at your option) any later version.
> -#
> -#  This program is distributed in the hope that it will be useful,
> -#  but WITHOUT ANY WARRANTY; without even the implied warranty of
> -#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> -#  GNU General Public License for more details.
> -#
> -#  You should have received a copy of the GNU General Public License
> -#  along with this program. If not, see <https://www.gnu.org/licenses/>.
> +"""
> +Print the top N most executed functions in QEMU using perf.
> +
> +Syntax:
> +topN_perf.py [-h] [-n ] -- \
> +  [] \
> +  []
> +
> +[-h] - Print the script arguments help message.
> +[-n] - Specify the number of top functions to print.
> + - If this flag is not specified, the tool defaults to 25.
> +
> +Example of usage:
> +topN_perf.py -n 20 -- qemu-arm coulomb_double-arm
> +
> +This file is a part of the project "TCG Continuous Benchmarking".
> +
> +Copyright (C) 2020  Ahmed Karaman 
> +Copyright (C) 2020  Aleksandar Markovic 
> +
> +This program is free software: you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation, either version 2 of the License, or
> +(at your option) any later version.
> +
> +This program is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with this program. If not, see <https://www.gnu.org/licenses/>.
> +"""
>
>  import argparse
>  import os
>  import subprocess
>  import sys
> +import tempfile
>
>
>  # Parse the command line arguments
> -parser = argparse.ArgumentParser(
> -usage='topN_perf.py [-h] [-n] 
> -- '
> +PARSER = argparse.ArgumentParser(
> +usage='topN_perf.py [-h] [-n ] -- '
>' [] '
>' []')
>
> -parser.add_argument('-n', dest='top', type=int, default=25,
> +PARSER.add_argument('-n', dest='top', type=int, default=25,
>  help='Specify the number of top functions to print.')
>
> -parser.add_argument('command', type=str, nargs='+',
> help=argparse.SUPPRESS)
> +PARSER.add_argument('command', type=str, nargs='+',
> help=argparse.SUPPRESS)
>
> -args = parser.parse_args()
> +ARGS = PARSER.parse_args()
>
>  # Extract the needed variables from the args
> -command = args.command
> -top = args.top
> +COMMAND = ARGS.command
> +TOP = ARGS.top
>
>  # Insure that perf is installed
> -check_perf_presence = subprocess.run(["which", "perf"],
> - stdout=subprocess.DEVNULL)
> -if check_perf_presence.returncode:
> +CH

Re: [PATCH V9 0/6] mips: Add Loongson-3 machine support

[Aleksandar Markovic]

On Wednesday, September 16, 2020, Huacai Chen  wrote:

> Loongson-3 CPU family include Loongson-3A R1/R2/R3/R4 and Loongson-3B
> R1/R2. Loongson-3A R1 is the oldest and its ISA is the smallest, while
> Loongson-3A R4 is the newest and its ISA is almost the superset of all
> others. To reduce complexity, in QEMU we just define two CPU types:
>
> 1, "Loongson-3A1000" CPU which is corresponding to Loongson-3A R1. It is
>suitable for TCG because Loongson-3A R1 has fewest ASE.
> 2, "Loongson-3A4000" CPU which is corresponding to Loongson-3A R4. It is
>suitable for KVM because Loongson-3A R4 has the VZ ASE.
>
> Loongson-3 lacks English documents. I've tried to translated them with
> translate.google.com, and the machine translated documents (together
> with their original Chinese versions) are available here.
>
> Loongson-3A R1 (Loongson-3A1000)
> User Manual Part 1:
> http://ftp.godson.ac.cn/lemote/3A1000_p1.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A1000_processor_user_manual_P1.pdf
> (Chinese Version)
> User Manual Part 2:
> http://ftp.godson.ac.cn/lemote/3A1000_p2.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A1000_processor_user_manual_P2.pdf
> (Chinese Version)
>
> Loongson-3A R2 (Loongson-3A2000)
> User Manual Part 1:
> http://ftp.godson.ac.cn/lemote/3A2000_p1.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A2000_user1.pdf (Chinese Version)
> User Manual Part 2:
> http://ftp.godson.ac.cn/lemote/3A2000_p2.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A2000_user2.pdf (Chinese Version)
>
> Loongson-3A R3 (Loongson-3A3000)
> User Manual Part 1:
> http://ftp.godson.ac.cn/lemote/3A3000_p1.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A3000_3B3000usermanual1.pdf
> (Chinese Version)
> User Manual Part 2:
> http://ftp.godson.ac.cn/lemote/3A3000_p2.pdf
> http://ftp.godson.ac.cn/lemote/Loongson3A3000_3B3000usermanual2.pdf
> (Chinese Version)
>
> Loongson-3A R4 (Loongson-3A4000)
> User Manual Part 1:
> http://ftp.godson.ac.cn/lemote/3A4000_p1.pdf
> http://ftp.godson.ac.cn/lemote/3A4000user.pdf (Chinese Version)
> User Manual Part 2:
> I'm sorry that it is unavailable now.
>
> And human-translated documents (W.I.P) are available here now:
> https://github.com/loongson-community/docs/tree/master/
> English-translation-of-Loongson-manual
>
> Both KVM and TCG are available now!
>
> We now already have a full functional Linux kernel (based on Linux-5.4.x
> LTS, the kvm host side and guest side have both been upstream for Linux-
> 5.9, but Linux-5.9 has not been released yet) here:
>
> https://github.com/chenhuacai/linux
>
> Of course the upstream kernel is also usable (though it is "unstable"
> now):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> How to use QEMU/Loongson-3?
> 1, Download kernel source from the above URL;
> 2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
> 3, Boot a Loongson-3A4000 host with this kernel (for KVM mode);
> 4, Build QEMU-master with this patchset;
> 5, modprobe kvm (only necessary for KVM mode);
> 6, Use QEMU with TCG:
>qemu-system-mips64el -M loongson3-virt,accel=tcg -cpu
> Loongson-3A1000 -kernel  -append ...
>Use QEMU with KVM:
>qemu-system-mips64el -M loongson3-virt,accel=kvm -cpu
> Loongson-3A4000 -kernel  -append ...
>
>The "-cpu" parameter is optional here and QEMU will use the correct
> type for TCG/KVM automatically.
>
> V1 -> V2:
> 1, Add a cover letter;
> 2, Improve CPU definitions;
> 3, Remove LS7A-related things (Use GPEX instead);
> 4, Add a description of how to run QEMU/Loongson-3.
>
> V2 -> V3:
> 1, Fix all possible checkpatch.pl errors and warnings.
>
> V3 -> V4:
> 1, Sync code with upstream;
> 2, Remove merged patches;
> 3, Fix build failure without CONFIG_KVM;
> 4, Add Reviewed-by: Aleksandar Markovic .
>
> V4 -> V5:
> 1, Improve coding style;
> 2, Remove merged patches;
> 3, Rename machine name from "loongson3" to "loongson3-virt";
> 4, Rework the "loongson3-virt" machine to drop any ISA things;
> 5, Rework "hw/mips: Implement the kvm_type() hook in MachineClass";
> 6, Add Jiaxun Yang as a reviewer of Loongson-3.
>
> V5 -> V6:
> 1, Fix license preamble;
> 2, Improve commit messages;
> 3, Add hw/intc/loongson_liointc.c to MAINTAINERS;
> 4, Fix all possible checkpatch.pl errors and warnings.
>
> V7 and V8 have only one patch (machine definition) with some minor
> improvements.
>
> V8 -> V9:
> 1, Update KVM type definition from kernel;
> 2, Fix PageMask with variable page size for TCG;
> 3, Add TCG support (add Loongson-EXT instructions).
>
> 

Re: [PATCH 7/9] tests/performance: Add nightly tests

[Aleksandar Markovic]

On Wednesday, September 2, 2020, Alex Bennée  wrote:

>
> Ahmed Karaman  writes:
>
> > A nightly performance testing system to monitor any change in QEMU
> > performance across seventeen different targets.
> >
> > The system includes eight different benchmarks to provide a variety
> > of testing workloads.
> >
> > dijkstra_double:
> > Find the shortest path between the source node and all other nodes
> > using Dijkstra’s algorithm. The graph contains n nodes where all nxn
> > distances are double values. The value of n can be specified using
> > the -n flag. The default value is 2000.
> >
> > dijkstra_int32:
> > Find the shortest path between the source node and all other nodes
> > using Dijkstra’s algorithm. The graph contains n nodes where all nxn
> > distances are int32 values. The value of n can be specified using
> > the -n flag. The default value is 2000.
> >
> > matmult_double:
> > Standard matrix multiplication of an n*n matrix of randomly generated
> > double numbers from 0 to 100. The value of n is passed as an argument
> > with the -n flag. The default value is 200.
> >
> > matmult_int32:
> > Standard matrix multiplication of an n*n matrix of randomly generated
> > integer numbers from 0 to 100. The value of n is passed as an
> > argument with the -n flag. The default value is 200.
> >
> > qsort_double:
> > Quick sort of an array of n randomly generated double numbers from 0
> > to 1000. The value of n is passed as an argument with the -n flag.
> > The default value is 30.
> >
> > qsort_int32:
> > Quick sort of an array of n randomly generated integer numbers from 0
> > to 5000. The value of n is passed as an argument with the -n
> > flag.The default value is 30.
> >
> > qsort_string:
> > Quick sort of an array of 1 randomly generated strings of size 8
> > (including null terminating character). The sort process is repeated
> > n number of times. The value of n is passed as an argument with the
> > -n flag. The default value is 20.
> >
> > search_string:
> > Search for the occurrence of a small string in a much larger random
> > string (“needle in a hay”). The search process is repeated n number
> > of times and each time, a different large random string (“hay”) is
> > generated. The value of n can be specified using the -n flag. The
> > default value is 20.
> >
> > Syntax:
> > nightly_tests_core.py [-h] [-r REF]
> > Optional arguments:
> > -h, --helpShow this help message and exit
> > -r REF, --reference REF
> > Reference QEMU version - Default is v5.1.0
> > Example of usage:
> > nightly_tests_core.py -r v5.1.0 2>log.txt
> >
> > The following report includes detailed setup and execution details
> > of the system:
> > https://ahmedkrmn.github.io/TCG-Continuous-Benchmarking/
> QEMU-Nightly-Performance-Tests/
> >
> > Signed-off-by: Ahmed Karaman 
> > ---
> >  tests/performance/nightly-tests/README.md | 243 +
> >  .../source/dijkstra_double/dijkstra_double.c  | 194 
> >  .../source/dijkstra_int32/dijkstra_int32.c| 192 
> >  .../source/matmult_double/matmult_double.c| 123 +++
> >  .../source/matmult_int32/matmult_int32.c  | 121 +++
> >  .../source/qsort_double/qsort_double.c| 104 ++
> >  .../source/qsort_int32/qsort_int32.c  | 103 ++
> >  .../source/qsort_string/qsort_string.c| 122 +++
> >  .../source/search_string/search_string.c  | 110 +++
> >  .../scripts/nightly_tests_core.py | 920 ++
> >  .../scripts/run_nightly_tests.py  | 135 +++
> >  .../nightly-tests/scripts/send_email.py   |  56 ++
> >  12 files changed, 2423 insertions(+)
> >  create mode 100644 tests/performance/nightly-tests/README.md
> >  create mode 100644 tests/performance/nightly-tests/benchmarks/source/
> dijkstra_double/dijkstra_double.c
> >  create mode 100644 tests/performance/nightly-tests/benchmarks/source/
> dijkstra_int32/dijkstra_int32.c
> >  create mode 100644 tests/performance/nightly-tests/benchmarks/source/
> matmult_double/matmult_double.c
> >  create mode 100644 tests/performance/nightly-tests/benchmarks/source/
> matmult_int32/matmult_int32.c
> >  create mode 100644 tests/performance/nightly-
> tests/benchmarks/source/qsort_double/qsort_double.c
> >  create mode 100644 tests/performance/nightly-
> tests/benchmarks/source/qsort_int32/qsort_int32.c
> >  create mode 100644 tests/performance/nightly-
> tests/benchmarks/source/qsort_string/qsort_string.c
> >  create mode 100644
> > tests/performance/nightly-tests/benchmarks/source/
> search_string/search_string.c
>
> Perhaps we could compress these paths down to:
>
>   tests/tcg/benchmarks/foo.c
>   tests/tcg/benchmarks/bar.c
>
> and then we can also ensure they are built using the existing TCG tests
> cross compile framework.
>
>
Hi,

May I just bring some alternative views on this topic of
benchmarks/multiple cross-compiling/nightly tests?

Having a known source code of any benchmark 

Re: [REPORT] Nightly Performance Tests - Sunday, September 13, 2020

[Aleksandar Markovic]

On Mon, Sep 14, 2020 at 12:52 PM Ahmed Karaman 
wrote:

> On Mon, Sep 14, 2020 at 8:46 AM Philippe Mathieu-Daudé 
> wrote:
> >
> > Hi Ahmed,
> >
> > On 9/14/20 12:07 AM, Ahmed Karaman wrote:
> > > Host CPU : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
> > > Host Memory  : 15.49 GB
> > >
> > > Start Time (UTC) : 2020-09-13 21:35:01
> > > End Time (UTC)   : 2020-09-13 22:07:44
> > > Execution Time   : 0:32:42.230467
> > >
> > > Status   : SUCCESS
> > >
> > > Note:
> > > Changes denoted by '-' are less than 0.01%.
> > >
> > > 
> > > SUMMARY REPORT - COMMIT f00f57f3
> > > 
> >
> > (Maybe this was already commented earlier but I missed it).
> >
> > What change had a so significant impact on the m68k target?
> > At a glance I only see mostly changes in softfloat:
> >
> > $ git log --oneline v5.1.0..f00f57f3 tcg target/m68k fpu
> > fe4b0b5bfa9 tcg: Implement 256-bit dup for tcg_gen_gvec_dup_mem
> > 6a17646176e tcg: Eliminate one store for in-place 128-bit dup_mem
> > e7e8f33fb60 tcg: Fix tcg gen for vectorized absolute value
> > 5ebf5f4be66 softfloat: Define misc operations for bfloat16
> > 34f0c0a98a5 softfloat: Define convert operations for bfloat16
> > 8282310d853 softfloat: Define operations for bfloat16
> > 0d93d8ec632 softfloat: Add fp16 and uint8/int8 conversion functions
> > fbcc38e4cb1 softfloat: add xtensa specialization for pickNaNMulAdd
> > 913602e3ffe softfloat: pass float_status pointer to pickNaN
> > cc43c692511 softfloat: make NO_SIGNALING_NANS runtime property
> > 73ebe95e8e5 target/ppc: add vmulld to INDEX_op_mul_vec case
> >
> > > 
> > > 
> > > Test Program: matmult_double
> > > 
> > > Target  Instructions  Latest  v5.1.0
> > > --    --  --
> > > aarch641 412 412 599   - +0.311%
> > > alpha  3 233 957 639   - +7.472%
> > > arm8 545 302 995   -  +1.09%
> > > hppa   3 483 527 330   - +4.466%
> > > m68k   3 919 110 506   -+18.433%
> > > mips   2 344 641 840   - +4.085%
> > > mipsel 3 329 912 425   - +5.177%
> > > mips64 2 359 024 910   - +4.075%
> > > mips64el   3 343 650 686   - +5.166%
> > > ppc3 209 505 701   - +3.248%
> > > ppc64  3 287 495 266   - +3.173%
> > > ppc64le3 287 135 580   - +3.171%
> > > riscv641 221 617 903   - +0.278%
> > > s390x  2 874 160 417   - +5.826%
> > > sh43 544 094 841   -  +6.42%
> > > sparc643 426 094 848   - +7.138%
> > > x86_64 1 249 076 697   - +0.335%
> > > 
> > ...
> > > 
> > > Test Program: qsort_double
> > > 
> > > Target  Instructions  Latest  v5.1.0
> > > --    --  --
> > > aarch642 709 839 947   - +2.423%
> > > alpha  1 969 432 086   - +3.679%
> > > arm8 323 168 267   - +2.589%
> > > hppa   3 188 316 726   -   +2.9%
> > > m68k   4 953 947 225   -+15.153%
> > > mips   2 123 789 120   - +3.049%
> > > mipsel 2 124 235 492   - +3.049%
> > > mips64 1 999 025 951   - +3.404%
> > > mips64el   1 996 433 190   - +3.409%
> > > ppc2 819 299 843   - +5.436%
> > > ppc64  2 768 177 037   - +5.512%
> > > ppc64le2 724 766 044   - +5.602%
> > > riscv641 638 324 190   - +4.021%
> > > s390x  2 519 117 806   - +3.364%
> > > sh42 595 696 102   -   +3.0%
> > > sparc643 988 892 763   - +2.744%
> > > x86_64 2 033 624 062   - +3.242%
> > > 
>
> Hi Mr. Philippe,
> The performance degradation from v5.1.0 of all targets, and especially
> m68k, was introduced between the two nightly tests below:
>
> [REPORT] Nightly Performance Tests - Thursday, August 20, 2020:
> https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg04923.html
>
> [REPORT] Nightly Performance Tests - Saturday, August 22, 2020
> 

[PATCH 4/4] target/mips: Refactor helpers for fp comparison instructions

[Aleksandar Markovic]

This change causes slighlty better performance of emulation of fp
comparison instructions via better compiler optimization of refactored
code. The functionality is otherwise unchanged.

Signed-off-by: Aleksandar Markovic 
---
 target/mips/fpu_helper.c | 56 +++-
 1 file changed, 32 insertions(+), 24 deletions(-)

diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
index f480c7296e..22d533322b 100644
--- a/target/mips/fpu_helper.c
+++ b/target/mips/fpu_helper.c
@@ -1780,11 +1780,12 @@ void helper_cmp_d_ ## op(CPUMIPSState *env, uint64_t 
fdt0, \
 {  \
 int c; \
 c = cond;  \
-update_fcr31(env, GETPC());\
-if (c) \
+if (c) {   \
 SET_FP_COND(cc, env->active_fpu);  \
-else   \
+} else {   \
 CLEAR_FP_COND(cc, env->active_fpu);\
+}  \
+update_fcr31(env, GETPC());\
 }  \
 void helper_cmpabs_d_ ## op(CPUMIPSState *env, uint64_t fdt0,  \
 uint64_t fdt1, int cc) \
@@ -1793,11 +1794,12 @@ void helper_cmpabs_d_ ## op(CPUMIPSState *env, uint64_t 
fdt0,  \
 fdt0 = float64_abs(fdt0);  \
 fdt1 = float64_abs(fdt1);  \
 c = cond;  \
-update_fcr31(env, GETPC());\
-if (c) \
+if (c) {   \
 SET_FP_COND(cc, env->active_fpu);  \
-else   \
+} else {   \
 CLEAR_FP_COND(cc, env->active_fpu);\
+}  \
+update_fcr31(env, GETPC());\
 }
 
 /*
@@ -1859,11 +1861,12 @@ void helper_cmp_s_ ## op(CPUMIPSState *env, uint32_t 
fst0, \
 {  \
 int c; \
 c = cond;  \
-update_fcr31(env, GETPC());\
-if (c) \
+if (c) {   \
 SET_FP_COND(cc, env->active_fpu);  \
-else   \
+} else {   \
 CLEAR_FP_COND(cc, env->active_fpu);\
+}  \
+update_fcr31(env, GETPC());\
 }  \
 void helper_cmpabs_s_ ## op(CPUMIPSState *env, uint32_t fst0,  \
 uint32_t fst1, int cc) \
@@ -1872,11 +1875,12 @@ void helper_cmpabs_s_ ## op(CPUMIPSState *env, uint32_t 
fst0,  \
 fst0 = float32_abs(fst0);  \
 fst1 = float32_abs(fst1);  \
 c = cond;  \
-update_fcr31(env, GETPC());\
-if (c) \
+if (c) {   \
 SET_FP_COND(cc, env->active_fpu);  \
-else   \
+} else {   \
 CLEAR_FP_COND(cc, env->active_fpu);\
+}  \
+update_fcr31(env, GETPC());\
 }
 
 /*
@@ -1944,15 +1948,17 @@ void helper_cmp_ps_ ## op(CPUMIPSState *env, uint64_t 
fdt0, \
 fsth1 = fdt1 >> 32; \
 cl = condl; \
 ch = condh; \
-update_fcr31(env, GETPC()); \
-if (cl) \
+if (cl) {   \
 S

[PATCH 2/4] target/mips: Demacro helpers for MF.

[Aleksandar Markovic]

Remove function definitions via macros to achieve better code clarity.

Signed-off-by: Aleksandar Markovic 
---
 target/mips/fpu_helper.c | 63 +---
 1 file changed, 46 insertions(+), 17 deletions(-)

diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
index f89213947f..98313951cb 100644
--- a/target/mips/fpu_helper.c
+++ b/target/mips/fpu_helper.c
@@ -1666,25 +1666,54 @@ uint64_t helper_float_nmsub_ps(CPUMIPSState *env, 
uint64_t fdt0,
 }
 
 
-#define FLOAT_FMADDSUB(name, bits, muladd_arg)  \
-uint ## bits ## _t helper_float_ ## name(CPUMIPSState *env, \
- uint ## bits ## _t fs, \
- uint ## bits ## _t ft, \
- uint ## bits ## _t fd) \
-{   \
-uint ## bits ## _t fdret;   \
-\
-fdret = float ## bits ## _muladd(fs, ft, fd, muladd_arg,\
- >active_fpu.fp_status);   \
-update_fcr31(env, GETPC()); \
-return fdret;   \
+uint32_t helper_float_maddf_s(CPUMIPSState *env, uint32_t fs,
+  uint32_t ft, uint32_t fd)
+{
+uint32_t fdret;
+
+fdret = float32_muladd(fs, ft, fd, 0,
+   >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_maddf_d(CPUMIPSState *env, uint64_t fs,
+  uint64_t ft, uint64_t fd)
+{
+uint64_t fdret;
+
+fdret = float64_muladd(fs, ft, fd, 0,
+   >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint32_t helper_float_msubf_s(CPUMIPSState *env, uint32_t fs,
+  uint32_t ft, uint32_t fd)
+{
+uint32_t fdret;
+
+fdret = float32_muladd(fs, ft, fd, float_muladd_negate_product,
+   >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_msubf_d(CPUMIPSState *env, uint64_t fs,
+  uint64_t ft, uint64_t fd)
+{
+uint64_t fdret;
+
+fdret = float64_muladd(fs, ft, fd, float_muladd_negate_product,
+   >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
 }
 
-FLOAT_FMADDSUB(maddf_s, 32, 0)
-FLOAT_FMADDSUB(maddf_d, 64, 0)
-FLOAT_FMADDSUB(msubf_s, 32, float_muladd_negate_product)
-FLOAT_FMADDSUB(msubf_d, 64, float_muladd_negate_product)
-#undef FLOAT_FMADDSUB
 
 /* compare operations */
 #define FOP_COND_D(op, cond)   \
-- 
2.20.1

[PATCH 1/4] target/mips: Demacro helpers for .

[Aleksandar Markovic]

Remove function definitions via macros to achieve better code clarity.

Signed-off-by: Aleksandar Markovic 
---
 target/mips/fpu_helper.c | 61 ++--
 1 file changed, 40 insertions(+), 21 deletions(-)

diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
index 7a3a61cab3..f89213947f 100644
--- a/target/mips/fpu_helper.c
+++ b/target/mips/fpu_helper.c
@@ -983,27 +983,46 @@ uint32_t helper_float_floor_2008_w_s(CPUMIPSState *env, 
uint32_t fst0)
 }
 
 /* unary operations, not modifying fp status  */
-#define FLOAT_UNOP(name)   \
-uint64_t helper_float_ ## name ## _d(uint64_t fdt0)\
-{  \
-return float64_ ## name(fdt0); \
-}  \
-uint32_t helper_float_ ## name ## _s(uint32_t fst0)\
-{  \
-return float32_ ## name(fst0); \
-}  \
-uint64_t helper_float_ ## name ## _ps(uint64_t fdt0)   \
-{  \
-uint32_t wt0;  \
-uint32_t wth0; \
-   \
-wt0 = float32_ ## name(fdt0 & 0X); \
-wth0 = float32_ ## name(fdt0 >> 32);   \
-return ((uint64_t)wth0 << 32) | wt0;   \
-}
-FLOAT_UNOP(abs)
-FLOAT_UNOP(chs)
-#undef FLOAT_UNOP
+
+uint64_t helper_float_abs_d(uint64_t fdt0)
+{
+   return float64_abs(fdt0);
+}
+
+uint32_t helper_float_abs_s(uint32_t fst0)
+{
+return float32_abs(fst0);
+}
+
+uint64_t helper_float_abs_ps(uint64_t fdt0)
+{
+uint32_t wt0;
+uint32_t wth0;
+
+wt0 = float32_abs(fdt0 & 0X);
+wth0 = float32_abs(fdt0 >> 32);
+return ((uint64_t)wth0 << 32) | wt0;
+}
+
+uint64_t helper_float_chs_d(uint64_t fdt0)
+{
+   return float64_chs(fdt0);
+}
+
+uint32_t helper_float_chs_s(uint32_t fst0)
+{
+return float32_chs(fst0);
+}
+
+uint64_t helper_float_chs_ps(uint64_t fdt0)
+{
+uint32_t wt0;
+uint32_t wth0;
+
+wt0 = float32_chs(fdt0 & 0X);
+wth0 = float32_chs(fdt0 >> 32);
+return ((uint64_t)wth0 << 32) | wt0;
+}
 
 /* MIPS specific unary operations */
 uint64_t helper_float_recip_d(CPUMIPSState *env, uint64_t fdt0)
-- 
2.20.1

[PATCH 3/4] target/mips: Demacro helpers for .

[Aleksandar Markovic]

Remove function definitions via macros to achieve better code clarity.

Signed-off-by: Aleksandar Markovic 
---
 target/mips/fpu_helper.c | 104 ++-
 1 file changed, 81 insertions(+), 23 deletions(-)

diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
index 98313951cb..f480c7296e 100644
--- a/target/mips/fpu_helper.c
+++ b/target/mips/fpu_helper.c
@@ -1475,29 +1475,87 @@ uint64_t helper_float_mulr_ps(CPUMIPSState *env, 
uint64_t fdt0, uint64_t fdt1)
 return ((uint64_t)fsth2 << 32) | fstl2;
 }
 
-#define FLOAT_MINMAX(name, bits, minmaxfunc)\
-uint ## bits ## _t helper_float_ ## name(CPUMIPSState *env, \
- uint ## bits ## _t fs, \
- uint ## bits ## _t ft) \
-{   \
-uint ## bits ## _t fdret;   \
-\
-fdret = float ## bits ## _ ## minmaxfunc(fs, ft,\
-   >active_fpu.fp_status); \
-update_fcr31(env, GETPC()); \
-return fdret;   \
-}
-
-FLOAT_MINMAX(max_s, 32, maxnum)
-FLOAT_MINMAX(max_d, 64, maxnum)
-FLOAT_MINMAX(maxa_s, 32, maxnummag)
-FLOAT_MINMAX(maxa_d, 64, maxnummag)
-
-FLOAT_MINMAX(min_s, 32, minnum)
-FLOAT_MINMAX(min_d, 64, minnum)
-FLOAT_MINMAX(mina_s, 32, minnummag)
-FLOAT_MINMAX(mina_d, 64, minnummag)
-#undef FLOAT_MINMAX
+
+uint32_t helper_float_max_s(CPUMIPSState *env, uint32_t fs, uint32_t ft)
+{
+uint32_t fdret;
+
+fdret = float32_maxnum(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_max_d(CPUMIPSState *env, uint64_t fs, uint64_t ft)
+{
+uint64_t fdret;
+
+fdret = float64_maxnum(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint32_t helper_float_maxa_s(CPUMIPSState *env, uint32_t fs, uint32_t ft)
+{
+uint32_t fdret;
+
+fdret = float32_maxnummag(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_maxa_d(CPUMIPSState *env, uint64_t fs, uint64_t ft)
+{
+uint64_t fdret;
+
+fdret = float64_maxnummag(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint32_t helper_float_min_s(CPUMIPSState *env, uint32_t fs, uint32_t ft)
+{
+uint32_t fdret;
+
+fdret = float32_minnum(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_min_d(CPUMIPSState *env, uint64_t fs, uint64_t ft)
+{
+uint64_t fdret;
+
+fdret = float64_minnum(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint32_t helper_float_mina_s(CPUMIPSState *env, uint32_t fs, uint32_t ft)
+{
+uint32_t fdret;
+
+fdret = float32_minnummag(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
+uint64_t helper_float_mina_d(CPUMIPSState *env, uint64_t fs, uint64_t ft)
+{
+uint64_t fdret;
+
+fdret = float64_minnummag(fs, ft, >active_fpu.fp_status);
+
+update_fcr31(env, GETPC());
+return fdret;
+}
+
 
 /* ternary operations */
 
-- 
2.20.1

[PATCH 0/4] target/mips: Misc patches

[Aleksandar Markovic]

A set of several, mostly FP, refactorings and improvements.

Aleksandar Markovic (4):
  target/mips: Demacro helpers for .
  target/mips: Demacro helpers for MF.
  target/mips: Demacro helpers for .
  target/mips: Refactor helpers for fp comparison instructions

 target/mips/fpu_helper.c | 276 +++
 1 file changed, 195 insertions(+), 81 deletions(-)

-- 
2.20.1

[PATCH 1/4] target/mips: Demacro helpers for .

[Aleksandar Markovic]

Remove function definitions via macros to achieve better code clarity.

Signed-off-by: Aleksandar Markovic 
---
 target/mips/fpu_helper.c | 61 ++--
 1 file changed, 40 insertions(+), 21 deletions(-)

diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
index 7a3a61cab3..f89213947f 100644
--- a/target/mips/fpu_helper.c
+++ b/target/mips/fpu_helper.c
@@ -983,27 +983,46 @@ uint32_t helper_float_floor_2008_w_s(CPUMIPSState *env, 
uint32_t fst0)
 }
 
 /* unary operations, not modifying fp status  */
-#define FLOAT_UNOP(name)   \
-uint64_t helper_float_ ## name ## _d(uint64_t fdt0)\
-{  \
-return float64_ ## name(fdt0); \
-}  \
-uint32_t helper_float_ ## name ## _s(uint32_t fst0)\
-{  \
-return float32_ ## name(fst0); \
-}  \
-uint64_t helper_float_ ## name ## _ps(uint64_t fdt0)   \
-{  \
-uint32_t wt0;  \
-uint32_t wth0; \
-   \
-wt0 = float32_ ## name(fdt0 & 0X); \
-wth0 = float32_ ## name(fdt0 >> 32);   \
-return ((uint64_t)wth0 << 32) | wt0;   \
-}
-FLOAT_UNOP(abs)
-FLOAT_UNOP(chs)
-#undef FLOAT_UNOP
+
+uint64_t helper_float_abs_d(uint64_t fdt0)
+{
+   return float64_abs(fdt0);
+}
+
+uint32_t helper_float_abs_s(uint32_t fst0)
+{
+return float32_abs(fst0);
+}
+
+uint64_t helper_float_abs_ps(uint64_t fdt0)
+{
+uint32_t wt0;
+uint32_t wth0;
+
+wt0 = float32_abs(fdt0 & 0X);
+wth0 = float32_abs(fdt0 >> 32);
+return ((uint64_t)wth0 << 32) | wt0;
+}
+
+uint64_t helper_float_chs_d(uint64_t fdt0)
+{
+   return float64_chs(fdt0);
+}
+
+uint32_t helper_float_chs_s(uint32_t fst0)
+{
+return float32_chs(fst0);
+}
+
+uint64_t helper_float_chs_ps(uint64_t fdt0)
+{
+uint32_t wt0;
+uint32_t wth0;
+
+wt0 = float32_chs(fdt0 & 0X);
+wth0 = float32_chs(fdt0 >> 32);
+return ((uint64_t)wth0 << 32) | wt0;
+}
 
 /* MIPS specific unary operations */
 uint64_t helper_float_recip_d(CPUMIPSState *env, uint64_t fdt0)
-- 
2.20.1

[PATCH 0/4] target/mips: Misc patches

[Aleksandar Markovic]

A set of several, mostly FP, refactorings and improvements.

Aleksandar Markovic (4):
  target/mips: Demacro helpers for .
  target/mips: Demacro helpers for MF.
  target/mips: Demacro helpers for .
  target/mips: Refactor helpers for fp comparison instructions

 target/mips/fpu_helper.c | 276 +++
 1 file changed, 195 insertions(+), 81 deletions(-)

-- 
2.20.1

[PATCH 2/9] scripts/performance: Refactor topN_callgrind.py

[Aleksandar Markovic]

On Friday, August 28, 2020, Ahmed Karaman 
wrote:

> - Apply pylint and flake8 formatting rules to the script.
> - Use 'tempfile' instead of '/tmp' for creating temporary files.
>
>
Reviewed-by: Aleksandar Markovic 
Reply
Reply all
Forward
View Gmail in: *Mobile* | Older version
<https://mail.google.com/mail/mu/mp/966/#> | Desktop
<https://mail.google.com/mail/mu/mp/966/#>
© 2020 Google


> Signed-off-by: Ahmed Karaman 
> ---
>  scripts/performance/topN_callgrind.py | 169 +-
>  1 file changed, 87 insertions(+), 82 deletions(-)
>
> diff --git a/scripts/performance/topN_callgrind.py
> b/scripts/performance/topN_callgrind.py
> index 67c59197af..f8a554f393 100755
> --- a/scripts/performance/topN_callgrind.py
> +++ b/scripts/performance/topN_callgrind.py
> @@ -1,113 +1,122 @@
>  #!/usr/bin/env python3
>
> -#  Print the top N most executed functions in QEMU using callgrind.
> -#  Syntax:
> -#  topN_callgrind.py [-h] [-n]   -- \
> -#[] \
> -#[]
> -#
> -#  [-h] - Print the script arguments help message.
> -#  [-n] - Specify the number of top functions to print.
> -#   - If this flag is not specified, the tool defaults to 25.
> -#
> -#  Example of usage:
> -#  topN_callgrind.py -n 20 -- qemu-arm coulomb_double-arm
> -#
> -#  This file is a part of the project "TCG Continuous Benchmarking".
> -#
> -#  Copyright (C) 2020  Ahmed Karaman 
> -#  Copyright (C) 2020  Aleksandar Markovic  om>
> -#
> -#  This program is free software: you can redistribute it and/or modify
> -#  it under the terms of the GNU General Public License as published by
> -#  the Free Software Foundation, either version 2 of the License, or
> -#  (at your option) any later version.
> -#
> -#  This program is distributed in the hope that it will be useful,
> -#  but WITHOUT ANY WARRANTY; without even the implied warranty of
> -#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> -#  GNU General Public License for more details.
> -#
> -#  You should have received a copy of the GNU General Public License
> -#  along with this program. If not, see <https://www.gnu.org/licenses/>.
> +"""
> +Print the top N most executed functions in QEMU using callgrind.
> +
> +Syntax:
> +topN_callgrind.py [-h] [-n ] -- \
> +  [] \
> +  []
> +
> +[-h] - Print the script arguments help message.
> +[-n] - Specify the number of top functions to print.
> + - If this flag is not specified, the tool defaults to 25.
> +
> +Example of usage:
> +topN_callgrind.py -n 20 -- qemu-arm coulomb_double-arm
> +
> +This file is a part of the project "TCG Continuous Benchmarking".
> +
> +Copyright (C) 2020  Ahmed Karaman 
> +Copyright (C) 2020  Aleksandar Markovic 
> +
> +This program is free software: you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation, either version 2 of the License, or
> +(at your option) any later version.
> +
> +This program is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with this program. If not, see <https://www.gnu.org/licenses/>.
> +"""
>
>  import argparse
>  import os
>  import subprocess
>  import sys
> +import tempfile
>
>
>  # Parse the command line arguments
> -parser = argparse.ArgumentParser(
> -usage='topN_callgrind.py [-h] [-n]  functions>  -- '
> +PARSER = argparse.ArgumentParser(
> +usage='topN_callgrind.py [-h] [-n]  functions> -- '
>' [] '
>' []')
>
> -parser.add_argument('-n', dest='top', type=int, default=25,
> +PARSER.add_argument('-n', dest='top', type=int, default=25,
>  help='Specify the number of top functions to print.')
>
> -parser.add_argument('command', type=str, nargs='+',
> help=argparse.SUPPRESS)
> +PARSER.add_argument('command', type=str, nargs='+',
> help=argparse.SUPPRESS)
>
> -args = parser.parse_args()
> +ARGS = PARSER.parse_args()
>
>  # Extract the needed variables from the args
> -command = args.command
> -top = args.top
> +COMMAND = ARGS.command
> +TOP = ARGS.top
>
>  # Insure that valgrind is installed
> -check_valgrind_presence = subprocess.run(["which", "valgrind"],
> - stdout=subprocess.DEVNULL)
> -if check_valgrind_presence

Re: [PATCH 1/9] scripts/performance: Refactor topN_perf.py

[Aleksandar Markovic]

On Friday, August 28, 2020, Ahmed Karaman 
wrote:

> - Apply pylint and flake8 formatting rules to the script.
> - Use 'tempfile' instead of '/tmp' for creating temporary files.
>
>
Reviewed-by: Aleksandar Markovic 
Reply
Reply all
Forward
View Gmail in: *Mobile* | Older version
<https://mail.google.com/mail/mu/mp/966/#> | Desktop
<https://mail.google.com/mail/mu/mp/966/#>
© 2020 Google


> Signed-off-by: Ahmed Karaman 
> ---
>  scripts/performance/topN_perf.py | 174 +++
>  1 file changed, 87 insertions(+), 87 deletions(-)
>
> diff --git a/scripts/performance/topN_perf.py b/scripts/performance/topN_
> perf.py
> index 07be195fc8..56b100da87 100755
> --- a/scripts/performance/topN_perf.py
> +++ b/scripts/performance/topN_perf.py
> @@ -1,72 +1,77 @@
>  #!/usr/bin/env python3
>
> -#  Print the top N most executed functions in QEMU using perf.
> -#  Syntax:
> -#  topN_perf.py [-h] [-n]   -- \
> -#[] \
> -#[]
> -#
> -#  [-h] - Print the script arguments help message.
> -#  [-n] - Specify the number of top functions to print.
> -#   - If this flag is not specified, the tool defaults to 25.
> -#
> -#  Example of usage:
> -#  topN_perf.py -n 20 -- qemu-arm coulomb_double-arm
> -#
> -#  This file is a part of the project "TCG Continuous Benchmarking".
> -#
> -#  Copyright (C) 2020  Ahmed Karaman 
> -#  Copyright (C) 2020  Aleksandar Markovic  com>
> -#
> -#  This program is free software: you can redistribute it and/or modify
> -#  it under the terms of the GNU General Public License as published by
> -#  the Free Software Foundation, either version 2 of the License, or
> -#  (at your option) any later version.
> -#
> -#  This program is distributed in the hope that it will be useful,
> -#  but WITHOUT ANY WARRANTY; without even the implied warranty of
> -#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> -#  GNU General Public License for more details.
> -#
> -#  You should have received a copy of the GNU General Public License
> -#  along with this program. If not, see <https://www.gnu.org/licenses/>.
> +"""
> +Print the top N most executed functions in QEMU using perf.
> +
> +Syntax:
> +topN_perf.py [-h] [-n ] -- \
> +  [] \
> +  []
> +
> +[-h] - Print the script arguments help message.
> +[-n] - Specify the number of top functions to print.
> + - If this flag is not specified, the tool defaults to 25.
> +
> +Example of usage:
> +topN_perf.py -n 20 -- qemu-arm coulomb_double-arm
> +
> +This file is a part of the project "TCG Continuous Benchmarking".
> +
> +Copyright (C) 2020  Ahmed Karaman 
> +Copyright (C) 2020  Aleksandar Markovic 
> +
> +This program is free software: you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation, either version 2 of the License, or
> +(at your option) any later version.
> +
> +This program is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with this program. If not, see <https://www.gnu.org/licenses/>.
> +"""
>
>  import argparse
>  import os
>  import subprocess
>  import sys
> +import tempfile
>
>
>  # Parse the command line arguments
> -parser = argparse.ArgumentParser(
> -usage='topN_perf.py [-h] [-n] 
> -- '
> +PARSER = argparse.ArgumentParser(
> +usage='topN_perf.py [-h] [-n ] -- '
>' [] '
>' []')
>
> -parser.add_argument('-n', dest='top', type=int, default=25,
> +PARSER.add_argument('-n', dest='top', type=int, default=25,
>  help='Specify the number of top functions to print.')
>
> -parser.add_argument('command', type=str, nargs='+',
> help=argparse.SUPPRESS)
> +PARSER.add_argument('command', type=str, nargs='+',
> help=argparse.SUPPRESS)
>
> -args = parser.parse_args()
> +ARGS = PARSER.parse_args()
>
>  # Extract the needed variables from the args
> -command = args.command
> -top = args.top
> +COMMAND = ARGS.command
> +TOP = ARGS.top
>
>  # Insure that perf is installed
> -check_perf_presence = subprocess.run(["which", "perf"],
> - stdout=subprocess.DEVNULL)
> -if check_perf_presence.returncode:
> +CHECK_PERF_PRESENCE = subprocess.run(["which", "perf"],
> + 

Re: [PATCH 3/9] scripts/performance: Refactor dissect.py

[Aleksandar Markovic]

On Friday, August 28, 2020, Ahmed Karaman 
wrote:

> - Apply pylint and flake8 formatting rules to the script.
> - Move syntax and usage exmaple to main() docstring.
> - Update get_jit_line() to only detect the main jit call.
> - Use mypy for specifying parameters and return types in functions.
>
>

Reviewed-by: Aleksandar Markovic 


> Signed-off-by: Ahmed Karaman 
> ---
>  scripts/performance/dissect.py | 123 ++---
>  1 file changed, 68 insertions(+), 55 deletions(-)
>
> diff --git a/scripts/performance/dissect.py b/scripts/performance/dissect.
> py
> index bf24f50922..d4df884b75 100755
> --- a/scripts/performance/dissect.py
> +++ b/scripts/performance/dissect.py
> @@ -1,34 +1,27 @@
>  #!/usr/bin/env python3
>
> -#  Print the percentage of instructions spent in each phase of QEMU
> -#  execution.
> -#
> -#  Syntax:
> -#  dissect.py [-h] --  [] \
> -#[]
> -#
> -#  [-h] - Print the script arguments help message.
> -#
> -#  Example of usage:
> -#  dissect.py -- qemu-arm coulomb_double-arm
> -#
> -#  This file is a part of the project "TCG Continuous Benchmarking".
> -#
> -#  Copyright (C) 2020  Ahmed Karaman 
> -#  Copyright (C) 2020  Aleksandar Markovic  com>
> -#
> -#  This program is free software: you can redistribute it and/or modify
> -#  it under the terms of the GNU General Public License as published by
> -#  the Free Software Foundation, either version 2 of the License, or
> -#  (at your option) any later version.
> -#
> -#  This program is distributed in the hope that it will be useful,
> -#  but WITHOUT ANY WARRANTY; without even the implied warranty of
> -#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> -#  GNU General Public License for more details.
> -#
> -#  You should have received a copy of the GNU General Public License
> -#  along with this program. If not, see <https://www.gnu.org/licenses/>.
> +"""
> +Print the percentage of instructions spent in each phase of QEMU
> +execution.
> +
> +This file is a part of the project "TCG Continuous Benchmarking".
> +
> +Copyright (C) 2020  Ahmed Karaman 
> +Copyright (C) 2020  Aleksandar Markovic 
> +
> +This program is free software: you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation, either version 2 of the License, or
> +(at your option) any later version.
> +
> +This program is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with this program. If not, see <https://www.gnu.org/licenses/>.
> +"""
>
>  import argparse
>  import os
> @@ -36,23 +29,26 @@ import subprocess
>  import sys
>  import tempfile
>
> +from typing import List
> +
>
> -def get_JIT_line(callgrind_data):
> +def get_jit_line(callgrind_data: List[str]) -> int:
>  """
>  Search for the first instance of the JIT call in
>  the callgrind_annotate output when ran using --tree=caller
>  This is equivalent to the self number of instructions of JIT.
>
>  Parameters:
> -callgrind_data (list): callgrind_annotate output
> +callgrind_data (List[str]): callgrind_annotate output
>
>  Returns:
>  (int): Line number
>  """
>  line = -1
> -for i in range(len(callgrind_data)):
> -if callgrind_data[i].strip('\n') and \
> -callgrind_data[i].split()[-1] == "[???]":
> +for (i, callgrind_datum) in enumerate(callgrind_data):
> +if callgrind_datum.strip('\n') and \
> +callgrind_datum.split()[-1] == "[???]" and \
> +callgrind_datum.split()[1] == "*":
>  line = i
>  break
>  if line == -1:
> @@ -61,6 +57,18 @@ def get_JIT_line(callgrind_data):
>
>
>  def main():
> +"""
> +Parse the command line arguments then start the execution.
> +Syntax:
> +dissect.py [-h] --  [] \
> +  []
> +
> +[-h] - Print the script arguments help message.
> +
> +Example of usage:
> +dissect.py -- qemu-arm coulomb_double-arm
> +"""
> +
>  # Parse the command line arguments
>  parser = argparse.ArgumentParser(
>  usage='dissect.py [-h] -- '
> @@ -76,7 +84,7 @@ def main():
>
>  # Insure 

Re: [PATCH 8/9] MAINTAINERS: Add 'tests/performance' to 'Performance Tools and Tests' subsection

[Aleksandar Markovic]

On Friday, August 28, 2020, Ahmed Karaman 
wrote:

> Add a new 'tests/performance' directory under the 'Performance Tools
> and Tests' subsection.
>
>
Reviewed-by: Aleksandar Markovic 



> Signed-off-by: Ahmed Karaman 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5a22c8be42..8923307642 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3124,3 +3124,4 @@ Performance Tools and Tests
>  M: Ahmed Karaman 
>  S: Maintained
>  F: scripts/performance/
> +F: tests/performance/
> --
> 2.17.1
>
>

Re: [PATCH 7/9] tests/performance: Add nightly tests

[Aleksandar Markovic]

On Friday, August 28, 2020, Ahmed Karaman 
wrote:

> A nightly performance testing system to monitor any change in QEMU
> performance across seventeen different targets.
>
>
Reviewed-by: Aleksandar Markovic 



> The system includes eight different benchmarks to provide a variety
> of testing workloads.
>
> dijkstra_double:
> Find the shortest path between the source node and all other nodes
> using Dijkstra’s algorithm. The graph contains n nodes where all nxn
> distances are double values. The value of n can be specified using
> the -n flag. The default value is 2000.
>
> dijkstra_int32:
> Find the shortest path between the source node and all other nodes
> using Dijkstra’s algorithm. The graph contains n nodes where all nxn
> distances are int32 values. The value of n can be specified using
> the -n flag. The default value is 2000.
>
> matmult_double:
> Standard matrix multiplication of an n*n matrix of randomly generated
> double numbers from 0 to 100. The value of n is passed as an argument
> with the -n flag. The default value is 200.
>
> matmult_int32:
> Standard matrix multiplication of an n*n matrix of randomly generated
> integer numbers from 0 to 100. The value of n is passed as an
> argument with the -n flag. The default value is 200.
>
> qsort_double:
> Quick sort of an array of n randomly generated double numbers from 0
> to 1000. The value of n is passed as an argument with the -n flag.
> The default value is 30.
>
> qsort_int32:
> Quick sort of an array of n randomly generated integer numbers from 0
> to 5000. The value of n is passed as an argument with the -n
> flag.The default value is 30.
>
> qsort_string:
> Quick sort of an array of 1 randomly generated strings of size 8
> (including null terminating character). The sort process is repeated
> n number of times. The value of n is passed as an argument with the
> -n flag. The default value is 20.
>
> search_string:
> Search for the occurrence of a small string in a much larger random
> string (“needle in a hay”). The search process is repeated n number
> of times and each time, a different large random string (“hay”) is
> generated. The value of n can be specified using the -n flag. The
> default value is 20.
>
> Syntax:
> nightly_tests_core.py [-h] [-r REF]
> Optional arguments:
> -h, --helpShow this help message and exit
> -r REF, --reference REF
> Reference QEMU version - Default is v5.1.0
> Example of usage:
> nightly_tests_core.py -r v5.1.0 2>log.txt
>
> The following report includes detailed setup and execution details
> of the system:
> https://ahmedkrmn.github.io/TCG-Continuous-Benchmarking/
> QEMU-Nightly-Performance-Tests/
>
> Signed-off-by: Ahmed Karaman 
> ---
>  tests/performance/nightly-tests/README.md | 243 +
>  .../source/dijkstra_double/dijkstra_double.c  | 194 
>  .../source/dijkstra_int32/dijkstra_int32.c| 192 
>  .../source/matmult_double/matmult_double.c| 123 +++
>  .../source/matmult_int32/matmult_int32.c  | 121 +++
>  .../source/qsort_double/qsort_double.c| 104 ++
>  .../source/qsort_int32/qsort_int32.c  | 103 ++
>  .../source/qsort_string/qsort_string.c| 122 +++
>  .../source/search_string/search_string.c  | 110 +++
>  .../scripts/nightly_tests_core.py | 920 ++
>  .../scripts/run_nightly_tests.py  | 135 +++
>  .../nightly-tests/scripts/send_email.py   |  56 ++
>  12 files changed, 2423 insertions(+)
>  create mode 100644 tests/performance/nightly-tests/README.md
>  create mode 100644 tests/performance/nightly-tests/benchmarks/source/
> dijkstra_double/dijkstra_double.c
>  create mode 100644 tests/performance/nightly-tests/benchmarks/source/
> dijkstra_int32/dijkstra_int32.c
>  create mode 100644 tests/performance/nightly-tests/benchmarks/source/
> matmult_double/matmult_double.c
>  create mode 100644 tests/performance/nightly-tests/benchmarks/source/
> matmult_int32/matmult_int32.c
>  create mode 100644 tests/performance/nightly-
> tests/benchmarks/source/qsort_double/qsort_double.c
>  create mode 100644 tests/performance/nightly-
> tests/benchmarks/source/qsort_int32/qsort_int32.c
>  create mode 100644 tests/performance/nightly-
> tests/benchmarks/source/qsort_string/qsort_string.c
>  create mode 100644 tests/performance/nightly-tests/benchmarks/source/
> search_string/search_string.c
>  create mode 100755 tests/performance/nightly-tests/scripts/nightly_tests_
> core.py
>  create mode 100755 tests/performance/nightly-tests/scripts/run_nightly_
> tests.py
>  create mode 100644 tests/performance/nightly-tests/scripts

Re: [REPORT] Nightly Performance Tests - Wednesday, August 19, 2020

[Aleksandar Markovic]

On Saturday, August 22, 2020, Ahmed Karaman 
wrote:

> Thanks Mr. Aleksandar,
>
> "Reference" and "latest" already each has its own results directory.
>
>
I meant also source directories of these two should be separate. Name
reference source directory qemu-ref or qemu-5.1, let's say.

I will try re-running the tests tonight from scratch as you've suggested to
> see how things will go.
>
> I will also add the "---" line at the beginning as you've suggested.
>
> Best regards,
> Ahmed
>
> On Sat, Aug 22, 2020, 2:21 PM Aleksandar Markovic <
> aleksandar.qemu.de...@gmail.com> wrote:
>
>>
>>
>> On Saturday, August 22, 2020, Aleksandar Markovic <
>> aleksandar.qemu.de...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wednesday, August 19, 2020, Ahmed Karaman <
>>> ahmedkhaledkara...@gmail.com> wrote:
>>>
>>>> Host CPU : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
>>>> Host Memory  : 15.49 GB
>>>>
>>>> Start Time (UTC) : 2020-08-19 21:00:01
>>>> End Time (UTC)   : 2020-08-19 21:32:15
>>>> Execution Time   : 0:32:14.021998
>>>>
>>>> Status   : SUCCESS
>>>>
>>>> 
>>>>
>>>>
>>>> I see we did not receive nightly report last night. The cause is most
>>> likely the change of our build system that happened yesterday.
>>>
>>> I think the best approach for you is to start tonight "from scratch".
>>> So, with source code tree and all past data deleted - as if you execute the
>>> nighlies for the first time ever. This will cause a fresh checkout, and a
>>> recreation of 5.1 and 'latest' perfirmace data.
>>>
>>>
>> Sorry, I envision some problems with the approach I described. I think
>> you should better create a separate source directory for reference 5.1
>> measurements, and another source directory for all measurements from
>> tonight on. That way you will avoid switching between build systems from
>> within the same directory.
>>
>> Thanks,
>> Aleksandar
>>
>>
>>
>>
>>> Unrelated hint:
>>>
>>> Please include the following (or similar) text right before the tables
>>> with results:
>>>
>>> "'-' denotes difference less than 0.01%."
>>>
>>> This way the readers will not be confused with '-' meaning.
>>>
>>> Yours,
>>> Aleksandar
>>>
>>>
>>>>
>>>> SUMMARY REPORT - COMMIT 672b2f26
>>>> 
>>>> AVERAGE RESULTS
>>>> 
>>>> Target  Instructions  Latest  v5.1.0
>>>> --    --  --
>>>> aarch642 118 484 879   -   -
>>>> alpha  1 838 407 216   -   -
>>>> arm7 887 992 884   -   -
>>>> hppa   4 124 996 474   -   -
>>>> m68k   2 453 421 671   -   -
>>>> mips   1 812 636 995   -   -
>>>> mipsel 1 947 725 352   -   -
>>>> mips64 1 862 495 613   -   -
>>>> mips64el   1 984 211 702   -   -
>>>> ppc2 394 319 834   -   -
>>>> ppc64  2 488 040 622   -   -
>>>> ppc64le2 470 198 016   -   -
>>>> riscv641 367 774 718   -   -
>>>> s390x  3 058 498 362   -   -
>>>> sh42 278 490 061   -   -
>>>> sparc643 186 999 246   -   -
>>>> x86_64 1 734 475 394   -   -
>>>> 
>>>>
>>>>DETAILED RESULTS
>>>> 
>>>> Test Program: dijkstra_double
>>>> 
>>>> Target  Instructions  Latest  v5.1.0
>>>> --    -

Re: [REPORT] Nightly Performance Tests - Wednesday, August 19, 2020

[Aleksandar Markovic]

On Saturday, August 22, 2020, Aleksandar Markovic <
aleksandar.qemu.de...@gmail.com> wrote:

>
>
> On Wednesday, August 19, 2020, Ahmed Karaman 
> wrote:
>
>> Host CPU : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
>> Host Memory  : 15.49 GB
>>
>> Start Time (UTC) : 2020-08-19 21:00:01
>> End Time (UTC)   : 2020-08-19 21:32:15
>> Execution Time   : 0:32:14.021998
>>
>> Status   : SUCCESS
>>
>> 
>>
>>
>> I see we did not receive nightly report last night. The cause is most
> likely the change of our build system that happened yesterday.
>
> I think the best approach for you is to start tonight "from scratch". So,
> with source code tree and all past data deleted - as if you execute the
> nighlies for the first time ever. This will cause a fresh checkout, and a
> recreation of 5.1 and 'latest' perfirmace data.
>
>
Sorry, I envision some problems with the approach I described. I think you
should better create a separate source directory for reference 5.1
measurements, and another source directory for all measurements from
tonight on. That way you will avoid switching between build systems from
within the same directory.

Thanks,
Aleksandar




> Unrelated hint:
>
> Please include the following (or similar) text right before the tables
> with results:
>
> "'-' denotes difference less than 0.01%."
>
> This way the readers will not be confused with '-' meaning.
>
> Yours,
> Aleksandar
>
>
>>
>> SUMMARY REPORT - COMMIT 672b2f26
>> 
>> AVERAGE RESULTS
>> 
>> Target  Instructions  Latest  v5.1.0
>> --    --  --
>> aarch642 118 484 879   -   -
>> alpha  1 838 407 216   -   -
>> arm7 887 992 884   -   -
>> hppa   4 124 996 474   -   -
>> m68k   2 453 421 671   -   -
>> mips   1 812 636 995   -   -
>> mipsel 1 947 725 352   -   -
>> mips64 1 862 495 613   -   -
>> mips64el   1 984 211 702   -   -
>> ppc2 394 319 834   -   -
>> ppc64  2 488 040 622   -   -
>> ppc64le2 470 198 016   -   -
>> riscv641 367 774 718   -   -
>> s390x  3 058 498 362   -   -
>> sh42 278 490 061   -   -
>> sparc643 186 999 246   -   -
>> x86_64 1 734 475 394   -   -
>> 
>>
>>DETAILED RESULTS
>> 
>> Test Program: dijkstra_double
>> 
>> Target  Instructions  Latest  v5.1.0
>> --    --  --
>> aarch643 019 613 303   -   -
>> alpha  3 078 110 233   -   -
>> arm   15 982 079 823   -   -
>> hppa   7 012 014 505   -   -
>> m68k   3 914 631 319   -   -
>> mips   2 979 137 836   -   -
>> mipsel 3 141 391 810   -   -
>> mips64 3 163 713 203   -   -
>> mips64el   3 314 105 619   -   -
>> ppc4 692 148 212   -   -
>> ppc64  4 875 585 404   -   -
>> ppc64le4 859 857 200   -   -
>> riscv642 150 267 230   -   -
>> s390x  4 455 507 359   -   -
>> sh43 816 841 775   -   -
>> sparc644 399 783 149   -   -
>> x86_64 2 441 371 746   -   -
>> 
>> 
>> Test Program: dijkstra_int32
>> 
>> Target  Instructions  La

Re: [PATCH V7 for-5.2] hw/mips: Add Loongson-3 machine support (with KVM)

[Aleksandar Markovic]

On Friday, August 7, 2020, Huacai Chen  wrote:

> Add Loongson-3 based machine support, it use liointc as the interrupt
> controler and use GPEX as the pci controller. Currently it can only work
> with KVM, but we will add TCG support in future.
>
>
Huacai,

We changed our build system yesterday, so please rebase and adjust this
patch. The needed changes shpukd be straightforward. Also, I think an
update of our documentation would be appropriate in case if this patch.

Yours,
Aleksandar






> As the machine model is not based on any exiting physical hardware, the
> name of the machine is "loongson3-virt". It may be superseded in future
> by a real machine model. If this happens, then a regular deprecation
> procedure shall occur for "loongson3-virt" machine.
>
> We now already have a full functional Linux kernel (based on Linux-5.4.x
> LTS, the kvm host side and guest side have both been upstream for Linux-
> 5.9, but Linux-5.9 has not been released yet) here:
>
> https://github.com/chenhuacai/linux
>
> Of course the upstream kernel is also usable (though it is "unstable"
> now):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> How to use QEMU/Loongson-3?
> 1, Download kernel source from the above URL;
> 2, Build a kernel with arch/mips/configs/loongson3_defconfig;
> 3, Boot the a Loongson-3A4000 host with this kernel;
> 4, Build QEMU-master with this patchset;
> 5, modprobe kvm;
> 6, Use QEMU with TCG (available in future):
>qemu-system-mips64el -M loongson3-virt,accel=tcg -cpu
> Loongson-3A1000 -kernel  -append ...
>Use QEMU with KVM (available at present):
>qemu-system-mips64el -M loongson3-virt,accel=kvm -cpu
> Loongson-3A4000 -kernel  -append ...
>
>The "-cpu" parameter is optional here and QEMU will use the correct
> type for TCG/KVM automatically.
>
> Signed-off-by: Huacai Chen 
> Co-developed-by: Jiaxun Yang 
> ---
>  default-configs/mips64el-softmmu.mak |   1 +
>  hw/mips/Kconfig  |  11 +
>  hw/mips/Makefile.objs|   1 +
>  hw/mips/loongson3_virt.c | 965 ++
> +
>  4 files changed, 978 insertions(+)
>  create mode 100644 hw/mips/loongson3_virt.c
>
> diff --git a/default-configs/mips64el-softmmu.mak
> b/default-configs/mips64el-softmmu.mak
> index 9f8a3ef..26c660a 100644
> --- a/default-configs/mips64el-softmmu.mak
> +++ b/default-configs/mips64el-softmmu.mak
> @@ -3,6 +3,7 @@
>  include mips-softmmu-common.mak
>  CONFIG_IDE_VIA=y
>  CONFIG_FULOONG=y
> +CONFIG_LOONGSON3V=y
>  CONFIG_ATI_VGA=y
>  CONFIG_RTL8139_PCI=y
>  CONFIG_JAZZ=y
> diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
> index 67d39c5..cc5609b 100644
> --- a/hw/mips/Kconfig
> +++ b/hw/mips/Kconfig
> @@ -45,6 +45,17 @@ config FULOONG
>  bool
>  select PCI_BONITO
>
> +config LOONGSON3V
> +bool
> +select PCKBD
> +select SERIAL
> +select GOLDFISH_RTC
> +select LOONGSON_LIOINTC
> +select PCI_EXPRESS_GENERIC_BRIDGE
> +select VIRTIO_VGA
> +select QXL if SPICE
> +select MSI_NONBROKEN
> +
>  config MIPS_CPS
>  bool
>  select PTIMER
> diff --git a/hw/mips/Makefile.objs b/hw/mips/Makefile.objs
> index 739e2b7..0993852 100644
> --- a/hw/mips/Makefile.objs
> +++ b/hw/mips/Makefile.objs
> @@ -4,5 +4,6 @@ obj-$(CONFIG_MALTA) += gt64xxx_pci.o malta.o
>  obj-$(CONFIG_MIPSSIM) += mipssim.o
>  obj-$(CONFIG_JAZZ) += jazz.o
>  obj-$(CONFIG_FULOONG) += fuloong2e.o
> +obj-$(CONFIG_LOONGSON3V) += loongson3_virt.o
>  obj-$(CONFIG_MIPS_CPS) += cps.o
>  obj-$(CONFIG_MIPS_BOSTON) += boston.o
> diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c
> new file mode 100644
> index 000..dec3b91
> --- /dev/null
> +++ b/hw/mips/loongson3_virt.c
> @@ -0,0 +1,963 @@
> +/*
> + * Generic Loongson-3 Platform support
> + *
> + * Copyright (c) 2017-2020 Huacai Chen (che...@lemote.com)
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see .
> + */
> +
> +/*
> + * Generic virtualized PC Platform based on Loongson-3 CPU (MIPS64R2 with
> + * extensions, 800~2000MHz)
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu-common.h"
> +#include "qemu/units.h"
> +#include "qapi/error.h"
> +#include "cpu.h"
> +#include "elf.h"
> +#include "kvm_mips.h"
> +#include "hw/boards.h"
> +#include "hw/char/serial.h"
> +#include "hw/mips/mips.h"
> +#include "hw/mips/cpudevs.h"
> 

Re: [REPORT] Nightly Performance Tests - Wednesday, August 19, 2020

[Aleksandar Markovic]

On Wednesday, August 19, 2020, Ahmed Karaman 
wrote:

> Host CPU : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
> Host Memory  : 15.49 GB
>
> Start Time (UTC) : 2020-08-19 21:00:01
> End Time (UTC)   : 2020-08-19 21:32:15
> Execution Time   : 0:32:14.021998
>
> Status   : SUCCESS
>
> 
>
>
> I see we did not receive nightly report last night. The cause is most
likely the change of our build system that happened yesterday.

I think the best approach for you is to start tonight "from scratch". So,
with source code tree and all past data deleted - as if you execute the
nighlies for the first time ever. This will cause a fresh checkout, and a
recreation of 5.1 and 'latest' perfirmace data.

Unrelated hint:

Please include the following (or similar) text right before the tables with
results:

"'-' denotes difference less than 0.01%."

This way the readers will not be confused with '-' meaning.

Yours,
Aleksandar


>
>
> SUMMARY REPORT - COMMIT 672b2f26
> 
> AVERAGE RESULTS
> 
> Target  Instructions  Latest  v5.1.0
> --    --  --
> aarch642 118 484 879   -   -
> alpha  1 838 407 216   -   -
> arm7 887 992 884   -   -
> hppa   4 124 996 474   -   -
> m68k   2 453 421 671   -   -
> mips   1 812 636 995   -   -
> mipsel 1 947 725 352   -   -
> mips64 1 862 495 613   -   -
> mips64el   1 984 211 702   -   -
> ppc2 394 319 834   -   -
> ppc64  2 488 040 622   -   -
> ppc64le2 470 198 016   -   -
> riscv641 367 774 718   -   -
> s390x  3 058 498 362   -   -
> sh42 278 490 061   -   -
> sparc643 186 999 246   -   -
> x86_64 1 734 475 394   -   -
> 
>
>DETAILED RESULTS
> 
> Test Program: dijkstra_double
> 
> Target  Instructions  Latest  v5.1.0
> --    --  --
> aarch643 019 613 303   -   -
> alpha  3 078 110 233   -   -
> arm   15 982 079 823   -   -
> hppa   7 012 014 505   -   -
> m68k   3 914 631 319   -   -
> mips   2 979 137 836   -   -
> mipsel 3 141 391 810   -   -
> mips64 3 163 713 203   -   -
> mips64el   3 314 105 619   -   -
> ppc4 692 148 212   -   -
> ppc64  4 875 585 404   -   -
> ppc64le4 859 857 200   -   -
> riscv642 150 267 230   -   -
> s390x  4 455 507 359   -   -
> sh43 816 841 775   -   -
> sparc644 399 783 149   -   -
> x86_64 2 441 371 746   -   -
> 
> 
> Test Program: dijkstra_int32
> 
> Target  Instructions  Latest  v5.1.0
> --    --  --
> aarch642 177 687 656   -   -
> alpha  1 462 693 182   -   -
> arm8 048 440 634   -   -
> hppa   5 053 362 217   -   -
> m68k   1 683 346 196   -   -
> mips   1 473 265 047   -   -
> mipsel 1 475 326 892   -   -
> mips64 1 683 560 350   -   -
> mips64el   1 663 467 060   -   -
> ppc1 978 581 291   -   -
> ppc64  2 160 088 877   -   -
> ppc64le2 151 841 575   -   -
> riscv641 323 226 597   -   -
> s390x  2 880 509 792   -   -
> sh41 938 787 291   -   -
> sparc642 768 217 627   -   -
> x86_64 1 521 

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#6] Performance Comparison of Two QEMU Builds

[Aleksandar Markovic]

Hi, Ahmed.

The report, and the topic in general, look quite interesting. However, I
would suggest two improvements:

- The title should reflect the content in a clearer way. Let's say,
"Compilers and QEMU performance" would be IMHO better. The expression "two
builds" is just missing the central motivation of the report, which is
comparing gcc-built QEMU and clang-built QEMU, performance-wise.

- At the end, a section "Useful links" would be handy, akin to the similar
section in Report 1. There were many people that analysed (and posted their
results on the internet) gcc vs clang in terms of performance of produced
executables (in contexts other than QEMU). Having the most useful and
informative ones (3-5 links with a short summary for each one would be more
than sufficient) listed in this report would enhance it significantly.

Yours,
Aleksandar


On Monday, July 27, 2020, Ahmed Karaman 
wrote:

> Hi everyone,
>
> The sixth report of the TCG Continuous Benchmarking project presents a
> performance comparison between two different QEMU builds, GCC and Clang.
>
> The report also presents five new benchmarks to allow for a variety of
> test workloads. Each of the five benchmarks is executed for seventeen
> different QEMU targets on both the GCC and Clang builds.
>
> The resulting ten tables are then summarized then analyzed using the
> list_helpers.py and list_fn_callees.py scripts. The entire workflow is
> automated using Python scripts that are posted in the report.
>
> Report link:
> https://ahmedkrmn.github.io/TCG-Continuous-Benchmarking/
> Performance-Comparison-of-Two-QEMU-Builds/
>
> Previous reports:
> Report 1 - Measuring Basic Performance Metrics of QEMU:
> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg06692.html
> Report 2 - Dissecting QEMU Into Three Main Parts:
> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg09441.html
> Report 3 - QEMU 5.0 and 5.1-pre-soft-freeze Dissect Comparison:
> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01978.html
> Report 4 - Listing QEMU Helpers and Function Callees:
> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg04227.html
> Report 5 - Finding Commits Affecting QEMU Performance:
> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05769.html
>
> Best regards,
> Ahmed Karaman
>

Re: [PATCH] linux-user: warn if trying to use qemu-mipsn32[el] with non n32 ELF

[Aleksandar Markovic]

On Saturday, August 22, 2020, Laurent Vivier  wrote:

> Le 22/08/2020 à 00:28, Carlo Marcelo Arenas Belón a écrit :
> > While technically compatible will (depending on the CPU) hopefully fail
> > later with a cryptic error:
> >
> >   qemu: Unexpected FPU mode
> >
> > Provide an earlier hint of what the problem might be by detecting if the
> > binary might not be using the n32 ABI and print a warning.
> >
> > Signed-off-by: Carlo Marcelo Arenas Belón 
> > ---
> >  linux-user/elfload.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> > index fe9dfe795d..64c3921cd9 100644
> > --- a/linux-user/elfload.c
> > +++ b/linux-user/elfload.c
> > @@ -2390,6 +2390,13 @@ static void load_elf_image(const char
> *image_name, int image_fd,
> >  if (!elf_check_ehdr(ehdr)) {
> >  goto exit_errmsg;
> >  }
> > +#ifdef TARGET_ABI_MIPSN32
> > +/* from arch/mips/include/asm/elf.h */
> > +#define EF_MIPS_ABI2 0x0020
>
> This is already defined in include/elf.h
>
> > +if (!(ehdr->e_flags & EF_MIPS_ABI2)) {
> > +fprintf(stderr, "warning: ELF binary missing n32 flag\n");
>
> I think an exit would be more appropriate:
>
> errmsg = "warning: ELF binary missing n32 flag";
> goto exit_errmsg;
>

Carlo, Laurent,

I agree with both Laurent's remarks above.

At the same time, I also support the spirit of Carlo's patch - but please,
Carlo, if possible, send the v2 that is going to address Laurent's concerns.

Moreover, Carlo, please consider doing more cleanup in this area. For
example, is the case "attempt passing n32 executable to non-n32 qemu"
handled in a user-friendly manner? What about "passing 64-bit executable to
32-bit qemu"? What about opposite endians? Are all user visible messages
clear and appropriate? Could you do a thourough analysis in this area?
There are 36 combinations (6x6, given 6 mips supported ABIs).

I would prefer a complete solution for all these mips combinations
"executable vs qemu" in linux user. Perhaps you can send a series of
patches on this topic, this one being, let's say, just the first one in
that series.

Yours,
Aleksandar




> > +}
> > +#endif
> >
> >  i = ehdr->e_phnum * sizeof(struct elf_phdr);
> >  if (ehdr->e_phoff + i <= BPRM_BUF_SIZE) {
> >
>
> CC'ing mips maintainers (and Maciej as he sent a patch on the N32 topic
> 2 years ago...)
>
> Thanks,
> Laurent
>
>

Re: [PATCH 1/2] target/mips: Coding style update to fix checkpatch errors

[Aleksandar Markovic]

On Thursday, August 13, 2020, Kaige Li  wrote:

> This will help ensure that style guidelines are being maintained during
> subsequent changes.
>
> Signed-off-by: Kaige Li 
> ---


Agreed.

Reviewed-by: Aleksandar Markovic 


>  target/mips/translate_init.inc.c | 61 --
> --
>  1 file changed, 31 insertions(+), 30 deletions(-)
>
> diff --git a/target/mips/translate_init.inc.c
> b/target/mips/translate_init.inc.c
> index 637cacc..0740819 100644
> --- a/target/mips/translate_init.inc.c
> +++ b/target/mips/translate_init.inc.c
> @@ -53,8 +53,7 @@
>
>  /***
> **/
>  /* MIPS CPU definitions */
> -const mips_def_t mips_defs[] =
> -{
> +const mips_def_t mips_defs[] = {
>  {
>  .name = "4Kc",
>  .CP0_PRid = 0x00018000,
> @@ -766,8 +765,8 @@ const mips_def_t mips_defs[] =
>  .name = "Loongson-2E",
>  .CP0_PRid = 0x6302,
>  /* 64KB I-cache and d-cache. 4 way with 32 bit cache line size.
> */
> -.CP0_Config0 = (0x1<<17) | (0x1<<16) | (0x1<<11) | (0x1<<8) |
> -   (0x1<<5) | (0x1<<4) | (0x1<<1),
> +.CP0_Config0 = (0x1 << 17) | (0x1 << 16) | (0x1 << 11) | (0x1 <<
> 8) |
> +   (0x1 << 5) | (0x1 << 4) | (0x1 << 1),
>  /* Note: Config1 is only used internally,
> Loongson-2E has only Config0.  */
>  .CP0_Config1 = (1 << CP0C1_FP) | (47 << CP0C1_MMU),
> @@ -786,8 +785,8 @@ const mips_def_t mips_defs[] =
>  .name = "Loongson-2F",
>  .CP0_PRid = 0x6303,
>  /* 64KB I-cache and d-cache. 4 way with 32 bit cache line size.
> */
> -.CP0_Config0 = (0x1<<17) | (0x1<<16) | (0x1<<11) | (0x1<<8) |
> -   (0x1<<5) | (0x1<<4) | (0x1<<1),
> +.CP0_Config0 = (0x1 << 17) | (0x1 << 16) | (0x1 << 11) | (0x1 <<
> 8) |
> +   (0x1 << 5) | (0x1 << 4) | (0x1 << 1),
>  /* Note: Config1 is only used internally,
> Loongson-2F has only Config0.  */
>  .CP0_Config1 = (1 << CP0C1_FP) | (47 << CP0C1_MMU),
> @@ -932,19 +931,19 @@ void mips_cpu_list(void)
>  }
>
>  #ifndef CONFIG_USER_ONLY
> -static void no_mmu_init (CPUMIPSState *env, const mips_def_t *def)
> +static void no_mmu_init(CPUMIPSState *env, const mips_def_t *def)
>  {
>  env->tlb->nb_tlb = 1;
>  env->tlb->map_address = _mmu_map_address;
>  }
>
> -static void fixed_mmu_init (CPUMIPSState *env, const mips_def_t *def)
> +static void fixed_mmu_init(CPUMIPSState *env, const mips_def_t *def)
>  {
>  env->tlb->nb_tlb = 1;
>  env->tlb->map_address = _mmu_map_address;
>  }
>
> -static void r4k_mmu_init (CPUMIPSState *env, const mips_def_t *def)
> +static void r4k_mmu_init(CPUMIPSState *env, const mips_def_t *def)
>  {
>  env->tlb->nb_tlb = 1 + ((def->CP0_Config1 >> CP0C1_MMU) & 63);
>  env->tlb->map_address = _map_address;
> @@ -956,40 +955,41 @@ static void r4k_mmu_init (CPUMIPSState *env, const
> mips_def_t *def)
>  env->tlb->helper_tlbinvf = r4k_helper_tlbinvf;
>  }
>
> -static void mmu_init (CPUMIPSState *env, const mips_def_t *def)
> +static void mmu_init(CPUMIPSState *env, const mips_def_t *def)
>  {
>  env->tlb = g_malloc0(sizeof(CPUMIPSTLBContext));
>
>  switch (def->mmu_type) {
> -case MMU_TYPE_NONE:
> -no_mmu_init(env, def);
> -break;
> -case MMU_TYPE_R4000:
> -r4k_mmu_init(env, def);
> -break;
> -case MMU_TYPE_FMT:
> -fixed_mmu_init(env, def);
> -break;
> -case MMU_TYPE_R3000:
> -case MMU_TYPE_R6000:
> -case MMU_TYPE_R8000:
> -default:
> -cpu_abort(env_cpu(env), "MMU type not supported\n");
> +case MMU_TYPE_NONE:
> +no_mmu_init(env, def);
> +break;
> +case MMU_TYPE_R4000:
> +r4k_mmu_init(env, def);
> +break;
> +case MMU_TYPE_FMT:
> +fixed_mmu_init(env, def);
> +break;
> +case MMU_TYPE_R3000:
> +case MMU_TYPE_R6000:
> +case MMU_TYPE_R8000:
> +default:
> +cpu_abort(env_cpu(env), "MMU type not supported\n");
>  }
>  }
>  #endif /* CONFIG_USER_ONLY */
>
> -static void fpu_init (CPUMIPSState *env, const mips_def_t *def)
> +static void fpu_init(C

Re: [PATCH v2 2/2] scripts/performance: Add list_helpers.py script

[Aleksandar Markovic]

On Tuesday, July 28, 2020, Aleksandar Markovic <
aleksandar.qemu.de...@gmail.com> wrote:

>
>
> On Tuesday, July 28, 2020, Aleksandar Markovic <
> aleksandar.qemu.de...@gmail.com> wrote:
>
>>
>>
>> On Thursday, July 16, 2020, Ahmed Karaman 
>> wrote:
>>
>>> Python script that prints executed helpers of a QEMU invocation.
>>>
>>>
>> Hi, Ahmed.
>>
>> You outlined the envisioned user workflow regarding this script in your
>> report. As I understand it, it generally goes like this:
>>
>> 1) The user first discovers helpers, and their performance data.
>> 2) The user examines the callees of a particular helper of choice
>> (usually, the most instruction-consuming helper).
>> 3) The user perhaps further examines a callee of a particular callee of
>> the particular helper.
>> 4) The user continues this way until the conclusion can be drawn, or
>> maximal depth is reached.
>>
>> The procedure might be time consuming since each step requires running an
>> emulation of the test program.
>>
>> This makes me think that the faster and easier tool for the user (but, to
>> some, not that great, extent, harder for you) would be improved
>> list_helpers.py (and list_fn_calees.py) that provides list of all callees
>> for all helpers, in the tree form (so, callees of callees, callees of
>> callees of callees, etc.), rather than providing just a list of immediate
>> callees, like it currently does.
>>
>> I think you can provide such functionality relatively easily using
>> recursion. See, let's say:
>>
>> https://realpython.com/python-thinking-recursively/
>>
>>
> For printing trees like this:
>
> foo
> ├── bar
> │ ├── a
> │ └── b
> ├── baz
> └── qux
> └── c⏎
> d
>
> you can potentialy use tree-format library:
>
> https://pypi.org/project/tree-format/ .
>
>

Aah, probably you can't - license incompatibility.

However, you can write your own function for tree-like outputing, it is
really not that difficult - and, in that case, you have the full output
control, maybe that is the best approach.

Thanks,
Aleksandar



> Perhaps you can have a switch (let's say, --tree ) that specifies
>> whether the script outputs just immediate callee list, or entire callee
>> tree.
>>
>> Thanks,
>> Aleksandar
>>
>>
>>> Syntax:
>>> list_helpers.py [-h] -- \
>>> [] \
>>> []
>>>
>>> [-h] - Print the script arguments help message.
>>>
>>> Example of usage:
>>> list_helpers.py -- qemu-mips coulomb_double-mips -n10
>>>
>>> Example output:
>>>  Total number of instructions: 108,933,695
>>>
>>>  Executed QEMU Helpers:
>>>
>>>  No. Ins Percent  Calls Ins/Call Helper Name Source File
>>>  --- --- --- --  
>>> ---
>>>1 183,021  0.168%  1,305  140 helper_float_sub_d
>>> /target/mips/fpu_helper.c
>>>2 177,111  0.163%770  230 helper_float_madd_d
>>>  /target/mips/fpu_helper.c
>>>3 171,537  0.157%  1,014  169 helper_float_mul_d
>>> /target/mips/fpu_helper.c
>>>4 157,298  0.144%  2,443   64 helper_lookup_tb_ptr
>>> /accel/tcg/tcg-runtime.c
>>>5 138,123  0.127%897  153 helper_float_add_d
>>> /target/mips/fpu_helper.c
>>>6  47,083  0.043%207  227 helper_float_msub_d
>>>  /target/mips/fpu_helper.c
>>>7  24,062  0.022%487   49 helper_cmp_d_lt
>>>  /target/mips/fpu_helper.c
>>>8  22,910  0.021%150  152 helper_float_div_d
>>> /target/mips/fpu_helper.c
>>>9  15,497  0.014%321   48 helper_cmp_d_eq
>>>  /target/mips/fpu_helper.c
>>>   10   9,100  0.008% 52  175 helper_float_trunc_w_d
>>> /target/mips/fpu_helper.c
>>>   11   7,059  0.006% 10  705 helper_float_sqrt_d
>>>  /target/mips/fpu_helper.c
>>>   12   3,000  0.003% 40   75 helper_cmp_d_ule
>>> /target/mips/fpu_helper.c
>>>   13   2,720  0.002% 20  136 helper_float_cvtd_w
>>>  /target/mips/fpu_helper.c
>>>   14   2,477  0.002% 27   91 helper_swl
>>> /target/mips/op_helper.c
>>>   15   2,000  0.002% 40   50 helper_cmp_d_le
>>>  /target/mips/fpu_helper.c
>>>   16   1,800  0.002% 40   45 helper_cmp_d_un
>>>  /target/mips/fpu_helper.c
>>>   17   1,164  0.001% 12 

Re: [PATCH v2 2/2] scripts/performance: Add list_helpers.py script

[Aleksandar Markovic]

On Tuesday, July 28, 2020, Aleksandar Markovic <
aleksandar.qemu.de...@gmail.com> wrote:

>
>
> On Thursday, July 16, 2020, Ahmed Karaman 
> wrote:
>
>> Python script that prints executed helpers of a QEMU invocation.
>>
>>
> Hi, Ahmed.
>
> You outlined the envisioned user workflow regarding this script in your
> report. As I understand it, it generally goes like this:
>
> 1) The user first discovers helpers, and their performance data.
> 2) The user examines the callees of a particular helper of choice
> (usually, the most instruction-consuming helper).
> 3) The user perhaps further examines a callee of a particular callee of
> the particular helper.
> 4) The user continues this way until the conclusion can be drawn, or
> maximal depth is reached.
>
> The procedure might be time consuming since each step requires running an
> emulation of the test program.
>
> This makes me think that the faster and easier tool for the user (but, to
> some, not that great, extent, harder for you) would be improved
> list_helpers.py (and list_fn_calees.py) that provides list of all callees
> for all helpers, in the tree form (so, callees of callees, callees of
> callees of callees, etc.), rather than providing just a list of immediate
> callees, like it currently does.
>
> I think you can provide such functionality relatively easily using
> recursion. See, let's say:
>
> https://realpython.com/python-thinking-recursively/
>
>
For printing trees like this:

foo
├── bar
│ ├── a
│ └── b
├── baz
└── qux
└── c⏎
d

you can potentialy use tree-format library:

https://pypi.org/project/tree-format/ .


> Perhaps you can have a switch (let's say, --tree ) that specifies
> whether the script outputs just immediate callee list, or entire callee
> tree.
>
> Thanks,
> Aleksandar
>
>
>> Syntax:
>> list_helpers.py [-h] -- \
>> [] \
>> []
>>
>> [-h] - Print the script arguments help message.
>>
>> Example of usage:
>> list_helpers.py -- qemu-mips coulomb_double-mips -n10
>>
>> Example output:
>>  Total number of instructions: 108,933,695
>>
>>  Executed QEMU Helpers:
>>
>>  No. Ins Percent  Calls Ins/Call Helper Name Source File
>>  --- --- --- --  
>> ---
>>1 183,021  0.168%  1,305  140 helper_float_sub_d
>> /target/mips/fpu_helper.c
>>2 177,111  0.163%770  230 helper_float_madd_d
>>  /target/mips/fpu_helper.c
>>3 171,537  0.157%  1,014  169 helper_float_mul_d
>> /target/mips/fpu_helper.c
>>4 157,298  0.144%  2,443   64 helper_lookup_tb_ptr
>> /accel/tcg/tcg-runtime.c
>>5 138,123  0.127%897  153 helper_float_add_d
>> /target/mips/fpu_helper.c
>>6  47,083  0.043%207  227 helper_float_msub_d
>>  /target/mips/fpu_helper.c
>>7  24,062  0.022%487   49 helper_cmp_d_lt
>>  /target/mips/fpu_helper.c
>>8  22,910  0.021%150  152 helper_float_div_d
>> /target/mips/fpu_helper.c
>>9  15,497  0.014%321   48 helper_cmp_d_eq
>>  /target/mips/fpu_helper.c
>>   10   9,100  0.008% 52  175 helper_float_trunc_w_d
>> /target/mips/fpu_helper.c
>>   11   7,059  0.006% 10  705 helper_float_sqrt_d
>>  /target/mips/fpu_helper.c
>>   12   3,000  0.003% 40   75 helper_cmp_d_ule
>> /target/mips/fpu_helper.c
>>   13   2,720  0.002% 20  136 helper_float_cvtd_w
>>  /target/mips/fpu_helper.c
>>   14   2,477  0.002% 27   91 helper_swl
>> /target/mips/op_helper.c
>>   15   2,000  0.002% 40   50 helper_cmp_d_le
>>  /target/mips/fpu_helper.c
>>   16   1,800  0.002% 40   45 helper_cmp_d_un
>>  /target/mips/fpu_helper.c
>>   17   1,164  0.001% 12   97 helper_raise_exception_
>> /target/mips/op_helper.c
>>   18 720  0.001% 10   72 helper_cmp_d_ult
>> /target/mips/fpu_helper.c
>>   19 560  0.001%1404 helper_cfc1
>>  /target/mips/fpu_helper.c
>>
>> Signed-off-by: Ahmed Karaman 
>> ---
>>  scripts/performance/list_helpers.py | 207 
>>  1 file changed, 207 insertions(+)
>>  create mode 100755 scripts/performance/list_helpers.py
>>
>> diff --git a/scripts/performance/list_helpers.py
>> b/scripts/performance/list_helpers.py
>> new file mode 100755
>> index 00..a97c7ed4fe
>> --- /dev/null
>> +++ b/scripts/performance/list_helpers.py
>> @@ -0,0 +1,207 @@
>> +#!/usr/bin/env python3
>> +
>&g

[PATCH v2 2/2] scripts/performance: Add list_helpers.py script

[Aleksandar Markovic]

On Thursday, July 16, 2020, Ahmed Karaman 
wrote:

> Python script that prints executed helpers of a QEMU invocation.
>
>
Hi, Ahmed.

You outlined the envisioned user workflow regarding this script in your
report. As I understand it, it generally goes like this:

1) The user first discovers helpers, and their performance data.
2) The user examines the callees of a particular helper of choice (usually,
the most instruction-consuming helper).
3) The user perhaps further examines a callee of a particular callee of the
particular helper.
4) The user continues this way until the conclusion can be drawn, or
maximal depth is reached.

The procedure might be time consuming since each step requires running an
emulation of the test program.

This makes me think that the faster and easier tool for the user (but, to
some, not that great, extent, harder for you) would be improved
list_helpers.py (and list_fn_calees.py) that provides list of all callees
for all helpers, in the tree form (so, callees of callees, callees of
callees of callees, etc.), rather than providing just a list of immediate
callees, like it currently does.

I think you can provide such functionality relatively easily using
recursion. See, let's say:

https://realpython.com/python-thinking-recursively/

Perhaps you can have a switch (let's say, --tree ) that specifies
whether the script outputs just immediate callee list, or entire callee
tree.

Thanks,
Aleksandar


> Syntax:
> list_helpers.py [-h] -- \
> [] \
> []
>
> [-h] - Print the script arguments help message.
>
> Example of usage:
> list_helpers.py -- qemu-mips coulomb_double-mips -n10
>
> Example output:
>  Total number of instructions: 108,933,695
>
>  Executed QEMU Helpers:
>
>  No. Ins Percent  Calls Ins/Call Helper Name Source File
>  --- --- --- --  
> ---
>1 183,021  0.168%  1,305  140 helper_float_sub_d
> /target/mips/fpu_helper.c
>2 177,111  0.163%770  230 helper_float_madd_d
>  /target/mips/fpu_helper.c
>3 171,537  0.157%  1,014  169 helper_float_mul_d
> /target/mips/fpu_helper.c
>4 157,298  0.144%  2,443   64 helper_lookup_tb_ptr
> /accel/tcg/tcg-runtime.c
>5 138,123  0.127%897  153 helper_float_add_d
> /target/mips/fpu_helper.c
>6  47,083  0.043%207  227 helper_float_msub_d
>  /target/mips/fpu_helper.c
>7  24,062  0.022%487   49 helper_cmp_d_lt
>  /target/mips/fpu_helper.c
>8  22,910  0.021%150  152 helper_float_div_d
> /target/mips/fpu_helper.c
>9  15,497  0.014%321   48 helper_cmp_d_eq
>  /target/mips/fpu_helper.c
>   10   9,100  0.008% 52  175 helper_float_trunc_w_d
> /target/mips/fpu_helper.c
>   11   7,059  0.006% 10  705 helper_float_sqrt_d
>  /target/mips/fpu_helper.c
>   12   3,000  0.003% 40   75 helper_cmp_d_ule
> /target/mips/fpu_helper.c
>   13   2,720  0.002% 20  136 helper_float_cvtd_w
>  /target/mips/fpu_helper.c
>   14   2,477  0.002% 27   91 helper_swl
> /target/mips/op_helper.c
>   15   2,000  0.002% 40   50 helper_cmp_d_le
>  /target/mips/fpu_helper.c
>   16   1,800  0.002% 40   45 helper_cmp_d_un
>  /target/mips/fpu_helper.c
>   17   1,164  0.001% 12   97 helper_raise_exception_
> /target/mips/op_helper.c
>   18 720  0.001% 10   72 helper_cmp_d_ult
> /target/mips/fpu_helper.c
>   19 560  0.001%1404 helper_cfc1
>  /target/mips/fpu_helper.c
>
> Signed-off-by: Ahmed Karaman 
> ---
>  scripts/performance/list_helpers.py | 207 
>  1 file changed, 207 insertions(+)
>  create mode 100755 scripts/performance/list_helpers.py
>
> diff --git a/scripts/performance/list_helpers.py
> b/scripts/performance/list_helpers.py
> new file mode 100755
> index 00..a97c7ed4fe
> --- /dev/null
> +++ b/scripts/performance/list_helpers.py
> @@ -0,0 +1,207 @@
> +#!/usr/bin/env python3
> +
> +#  Print the executed helpers of a QEMU invocation.
> +#
> +#  Syntax:
> +#  list_helpers.py [-h] -- \
> +#  [] \
> +#  []
> +#
> +#  [-h] - Print the script arguments help message.
> +#
> +#  Example of usage:
> +#  list_helpers.py -- qemu-mips coulomb_double-mips
> +#
> +#  This file is a part of the project "TCG Continuous Benchmarking".
> +#
> +#  Copyright (C) 2020  Ahmed Karaman 
> +#  Copyright (C) 2020  Aleksandar Markovic  om>
> +#
> +#  This program is free software: you can redistribute it and/or modify
> +#  it under the terms of the GNU General Public License as published by
> +#  the Free Software Foundation, either version 2 of the License,

Re: [PATCH 1/1] scripts/performance: Add bisect.py script

[Aleksandar Markovic]

On Monday, July 27, 2020, John Snow  wrote:

> On 7/25/20 8:31 AM, Aleksandar Markovic wrote:
>
>>
>>
>> On Wednesday, July 22, 2020, Ahmed Karaman > <mailto:ahmedkhaledkara...@gmail.com>> wrote:
>>
>> Python script that locates the commit that caused a performance
>> degradation or improvement in QEMU using the git bisect command
>> (binary search).
>>
>> Syntax:
>> bisect.py [-h] -s,--start START [-e,--end END] [-q,--qemu QEMU] \
>> --target TARGET --tool {perf,callgrind} -- \
>>  []
>>
>> [-h] - Print the script arguments help message
>> -s,--start START - First commit hash in the search range
>> [-e,--end END] - Last commit hash in the search range
>>  (default: Latest commit)
>> [-q,--qemu QEMU] - QEMU path.
>>  (default: Path to a GitHub QEMU clone)
>> --target TARGET - QEMU target name
>> --tool {perf,callgrind} - Underlying tool used for measurements
>>
>> Example of usage:
>> bisect.py --start=fdd76fecdd --qemu=/path/to/qemu --target=ppc \
>> --tool=perf -- coulomb_double-ppc -n 1000
>>
>> Example output:
>> Start Commit Instructions: 12,710,790,060
>> End Commit Instructions:   13,031,083,512
>> Performance Change:-2.458%
>>
>> Estimated Number of Steps: 10
>>
>> *BISECT STEP 1*
>> Instructions:13,031,097,790
>> Status:  slow commit
>> *BISECT STEP 2*
>> Instructions:12,710,805,265
>> Status:  fast commit
>> *BISECT STEP 3*
>> Instructions:13,031,028,053
>> Status:  slow commit
>> *BISECT STEP 4*
>> Instructions:12,711,763,211
>> Status:  fast commit
>> *BISECT STEP 5*
>> Instructions:13,031,027,292
>> Status:  slow commit
>> *BISECT STEP 6*
>> Instructions:12,711,748,738
>> Status:  fast commit
>> *BISECT STEP 7*
>> Instructions:12,711,748,788
>> Status:  fast commit
>> *BISECT STEP 8*
>> Instructions:13,031,100,493
>> Status:  slow commit
>> *BISECT STEP 9*
>> Instructions:12,714,472,954
>> Status:  fast commit
>> BISECT STEP 10*
>> Instructions:12,715,409,153
>> Status:  fast commit
>> BISECT STEP 11*
>> Instructions:12,715,394,739
>> Status:  fast commit
>>
>> *BISECT RESULT*
>> commit 0673ecdf6cb2b1445a85283db8cbacb251c46516
>> Author: Richard Henderson > <mailto:richard.hender...@linaro.org>>
>> Date:   Tue May 5 10:40:23 2020 -0700
>>
>>  softfloat: Inline float64 compare specializations
>>
>>  Replace the float64 compare specializations with inline functions
>>  that call the standard float64_compare{,_quiet} functions.
>>  Use bool as the return type.
>> ***
>>
>> Signed-off-by: Ahmed Karaman > <mailto:ahmedkhaledkara...@gmail.com>>
>> ---
>>   scripts/performance/bisect.py | 374 ++
>> 
>>   1 file changed, 374 insertions(+)
>>   create mode 100755 scripts/performance/bisect.py
>>
>> diff --git a/scripts/performance/bisect.py
>> b/scripts/performance/bisect.py
>> new file mode 100755
>> index 00..869cc69ef4
>> --- /dev/null
>> +++ b/scripts/performance/bisect.py
>> @@ -0,0 +1,374 @@
>> +#!/usr/bin/env python3
>> +
>> +#  Locate the commit that caused a performance degradation or
>> improvement in
>> +#  QEMU using the git bisect command (binary search).
>> +#
>> +#  Syntax:
>> +#  bisect.py [-h] -s,--start START [-e,--end END] [-q,--qemu QEMU] \
>> +#  --target TARGET --tool {perf,callgrind} -- \
>> +#   []
>> +#
>>  

Re: [PATCH 1/1] scripts/performance: Add bisect.py script

[Aleksandar Markovic]

On Saturday, July 25, 2020, Ahmed Karaman 
wrote:

> On Sat, Jul 25, 2020 at 2:31 PM Aleksandar Markovic <
> aleksandar.qemu.de...@gmail.com> wrote:
>
>>
>> Hi, Ahmed.
>>
>> Yes, somewhat related to John's hints on these comments, it is customary
>> to have just a brief description before "Copyright" lines. This means one
>> sentence, or a short paragraph (3-4 sentences max). The lenghty syntax
>> commemt should be, in my opinion, moved after the license preamble, just
>> before the start of real Python code.
>>
>
> Thanks Mr. John and Aleksandar for your feedback. I will update the script
> accordingly.
>
>
>>
>> One question:
>>
>> What is the behavior in case of the executable architecture and "target"
>> command line option mismatch (for example, one specifies m68k target, but
>> passes hppa executable? Would that be detected before bisect search, or the
>> bisect procedure will be applied even though such cases do not make sense?
>>
>
> The script will exit with an error of something along the lines of
> "Invalid ELF image for this architecture".
> This is done before starting "bisect" and after the initial "configure"
> and "make".
>
>
This is good enough (the moment of detection). However, are all cleanups
done? Is temporary directory deleted?

The same questions for the scenario where the user specifies non-existant
commit ID as the start or the end commit.

Does the script work if user specifies a tag, instead of commit ID? I think
it should work. For example, can the user specify v3.1.0 as start commit,
and v4.2.0 as the end commit, in order to detect degradation/improvement
between QEMU 3.1 and QEMU 4.2? Please test if such scenario works. If it
works, I think you should insert "commit ID or tag ID" instead of "commit"
only in the commit massage and applicable code comments (including also the
user-visible help outputed on "-h").

Lastly, what happens if specified start and end commits are existant, but
in the wrong order (end is "before" start)?

Thanks,
Aleksandar





>
>> Yours, Aleksandar
>>
>>
>>
>>> +#  This program is free software: you can redistribute it and/or modify
>>> +#  it under the terms of the GNU General Public License as published by
>>> +#  the Free Software Foundation, either version 2 of the License, or
>>> +#  (at your option) any later version.
>>> +#
>>> +#  This program is distributed in the hope that it will be useful,
>>> +#  but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> +#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> +#  GNU General Public License for more details.
>>> +#
>>> +#  You should have received a copy of the GNU General Public License
>>> +#  along with this program. If not, see <https://www.gnu.org/licenses/
>>> >.
>>> +
>>> +import argparse
>>> +import multiprocessing
>>> +import tempfile
>>> +import os
>>> +import shutil
>>> +import subprocess
>>> +import sys
>>> +
>>> +
>>> + GIT WRAPPERS 
>>> +def git_bisect(qemu_path, command, args=None):
>>> +"""
>>> +Wrapper function for running git bisect.
>>> +
>>> +Parameters:
>>> +qemu_path (str): QEMU path.
>>> +command (str):   bisect command (start|fast|slow|reset).
>>> +args (list): Optional arguments.
>>> +
>>> +Returns:
>>> +(str):   git bisect stdout.
>>> +"""
>>> +process = ["git", "bisect", command]
>>> +if args:
>>> +process += args
>>> +bisect = subprocess.run(process,
>>> +cwd=qemu_path,
>>> +stdout=subprocess.PIPE,
>>> +stderr=subprocess.PIPE)
>>> +if bisect.returncode:
>>> +sys.exit(bisect.stderr.decode("utf-8"))
>>> +return bisect.stdout.decode("utf-8")
>>> +
>>> +
>>> +def git_checkout(commit, qemu_path):
>>> +"""
>>> +Wrapper function for checking out a given git commit.
>>> +
>>> +Parameters:
>>> +commit (str):Commit hash of a git commit.
>>> +qemu_path (str): QEMU path.
>>> +"""
>>> +checkout_commit = sub

Re: [PATCH 1/1] scripts/performance: Add bisect.py script

[Aleksandar Markovic]

On Wednesday, July 22, 2020, Ahmed Karaman 
wrote:

> Python script that locates the commit that caused a performance
> degradation or improvement in QEMU using the git bisect command
> (binary search).
>
> Syntax:
> bisect.py [-h] -s,--start START [-e,--end END] [-q,--qemu QEMU] \
> --target TARGET --tool {perf,callgrind} -- \
>  []
>
> [-h] - Print the script arguments help message
> -s,--start START - First commit hash in the search range
> [-e,--end END] - Last commit hash in the search range
> (default: Latest commit)
> [-q,--qemu QEMU] - QEMU path.
> (default: Path to a GitHub QEMU clone)
> --target TARGET - QEMU target name
> --tool {perf,callgrind} - Underlying tool used for measurements
>
> Example of usage:
> bisect.py --start=fdd76fecdd --qemu=/path/to/qemu --target=ppc \
> --tool=perf -- coulomb_double-ppc -n 1000
>
> Example output:
> Start Commit Instructions: 12,710,790,060
> End Commit Instructions:   13,031,083,512
> Performance Change:-2.458%
>
> Estimated Number of Steps: 10
>
> *BISECT STEP 1*
> Instructions:13,031,097,790
> Status:  slow commit
> *BISECT STEP 2*
> Instructions:12,710,805,265
> Status:  fast commit
> *BISECT STEP 3*
> Instructions:13,031,028,053
> Status:  slow commit
> *BISECT STEP 4*
> Instructions:12,711,763,211
> Status:  fast commit
> *BISECT STEP 5*
> Instructions:13,031,027,292
> Status:  slow commit
> *BISECT STEP 6*
> Instructions:12,711,748,738
> Status:  fast commit
> *BISECT STEP 7*
> Instructions:12,711,748,788
> Status:  fast commit
> *BISECT STEP 8*
> Instructions:13,031,100,493
> Status:  slow commit
> *BISECT STEP 9*
> Instructions:12,714,472,954
> Status:  fast commit
> BISECT STEP 10*
> Instructions:12,715,409,153
> Status:  fast commit
> BISECT STEP 11*
> Instructions:12,715,394,739
> Status:  fast commit
>
> *BISECT RESULT*
> commit 0673ecdf6cb2b1445a85283db8cbacb251c46516
> Author: Richard Henderson 
> Date:   Tue May 5 10:40:23 2020 -0700
>
> softfloat: Inline float64 compare specializations
>
> Replace the float64 compare specializations with inline functions
> that call the standard float64_compare{,_quiet} functions.
> Use bool as the return type.
> ***
>
> Signed-off-by: Ahmed Karaman 
> ---
>  scripts/performance/bisect.py | 374 ++
>  1 file changed, 374 insertions(+)
>  create mode 100755 scripts/performance/bisect.py
>
> diff --git a/scripts/performance/bisect.py b/scripts/performance/bisect.py
> new file mode 100755
> index 00..869cc69ef4
> --- /dev/null
> +++ b/scripts/performance/bisect.py
> @@ -0,0 +1,374 @@
> +#!/usr/bin/env python3
> +
> +#  Locate the commit that caused a performance degradation or improvement
> in
> +#  QEMU using the git bisect command (binary search).
> +#
> +#  Syntax:
> +#  bisect.py [-h] -s,--start START [-e,--end END] [-q,--qemu QEMU] \
> +#  --target TARGET --tool {perf,callgrind} -- \
> +#   []
> +#
> +#  [-h] - Print the script arguments help message
> +#  -s,--start START - First commit hash in the search range
> +#  [-e,--end END] - Last commit hash in the search range
> +# (default: Latest commit)
> +#  [-q,--qemu QEMU] - QEMU path.
> +#  (default: Path to a GitHub QEMU clone)
> +#  --target TARGET - QEMU target name
> +#  --tool {perf,callgrind} - Underlying tool used for measurements
> +
> +#  Example of usage:
> +#  bisect.py --start=fdd76fecdd --qemu=/path/to/qemu --target=ppc
> --tool=perf \
> +#  -- coulomb_double-ppc -n 1000
> +#
> +#  This file is a part of the project "TCG Continuous Benchmarking".
> +#
> +#  Copyright (C) 2020  Ahmed Karaman 
> +#  Copyright (C) 2020  Aleksandar Markovic  com>
> +#


Hi, Ahmed.

Yes, somewhat related to John's hints on these comments, it is customary to
have just a brief description before "Copyright" lines. This means one
sentence, or a short paragraph (3-4 sentences max). The lenghty syntax
commemt should be, in my opinio

Re: [PATCH v5 2/2] hw: hyperv: vmbus: Fix 32bit compilation

[Aleksandar Markovic]

On Wednesday, July 15, 2020, Jon Doron  wrote:

> Signed-off-by: Jon Doron 
> ---
>  hw/hyperv/vmbus.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/hyperv/vmbus.c b/hw/hyperv/vmbus.c
> index 34392e892a..c28bb4201b 100644
> --- a/hw/hyperv/vmbus.c
> +++ b/hw/hyperv/vmbus.c
> @@ -383,7 +383,8 @@ static ssize_t gpadl_iter_io(GpadlIter *iter, void
> *buf, uint32_t len)
>  }
>  }
>
> -p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) |
> off_in_page);
> +p = (void *)(uintptr_t)(((uintptr_t)iter->map &
> TARGET_PAGE_MASK) |
> +off_in_page);
>  if (iter->dir == DMA_DIRECTION_FROM_DEVICE) {
>  memcpy(p, buf, cplen);
>  } else {
> --
> 2.24.1
>
>
>
Tested-by: Aleksandar Markovic 
Reviewed-by: Aleksandar Markovic 

It looks to me this patch should definitely be selected for 5.1.?

[PULL 0/3] MIPS + TCG Continuous Benchmarking queue for July 7th, 2020

[Aleksandar Markovic]

On Tuesday, July 7, 2020, Paolo Bonzini  wrote:

> I haven't looked at the disassembler code; assuming it comes from an
> upstream code base I don't think we should treat it differently from the
> ARM disassembler (or for that matter the binutils ones) and basically
> handle it as a black box for which we don't really care about the code
> quality or style. It's not security sensitive code, and forking the
> upstream is probably not justified. On the other hand the pull request
> should have explained the provenance of the code (even if only in the
> subject line of the relevant patch).
>
> Regarding the recommendation of a "vacation" after last week's facts,
> QEMU's enforcing of behavior standards so far has been informal, therefore
> my suggestion cannot be anything more than a suggestion, though a strongly
> recommended one. I can also understand the soft freeze pressure. I defer
> to Peter as to whether to merge this pull request or not due to Thomas's
> objections, but I do wish to reinforce that taking some time off to cool
> down can often times be a good idea.
>
>
Sure, I respect the opinion of both Paolo and Thomas. I already reflected
on everything, and will not be an obstacle in any way in qemu community.

There is truly no ulterior motive from my side regarding this pull request
- I was just trying to integrate some code before soft-freeze.

Peter, please discard this pull request, I will send a new one, as soon as
I can, most likely tomorrow, that will fully follow Paolo's and Thomas'
recommendations, no need to worry.

Thanks,
Aleksamdar



> Thanks,
>
> Paolo
>
> Il mar 7 lug 2020, 22:20 Thomas Huth  ha scritto:
>
>> On 07/07/2020 18.40, Aleksandar Markovic wrote:
>> > The following changes since commit 710fb08fd297d7a92163debce1959f
>> ae8f3b6ed7:
>> >
>> >   Merge remote-tracking branch 
>> > 'remotes/huth-gitlab/tags/pull-request-2020-07-06'
>> into staging (2020-07-07 12:41:15 +0100)
>> >
>> > are available in the git repository at:
>> >
>> >   https://github.com/AMarkovic/qemu tags/mips-queue-jul-07-2020
>> >
>> > for you to fetch changes up to fa6e7da119b6da4067e757924e165b
>> c737bb1260:
>> >
>> >   scripts/performance: Add dissect.py script (2020-07-07 18:32:20 +0200)
>> >
>> > 
>> >
>> > MIPS + TCG Continuous Benchmarking queue for July 7th, 2020
>> >
>> >   Highlights:
>> >
>> >  - Fix for a regression in FPU emulation add.s.
>> >  - Add Loongson 2F disassembler.
>> >  - Add a script for a GSoC project.
>> >
>> >   Note:
>> >
>> >  - A checkpatch error and a checkpatch warning are known and
>> >  should be ignored.
>> >
>> > 
>> >
>> > Ahmed Karaman (1):
>> >   scripts/performance: Add dissect.py script
>> >
>> > Alex Richardson (1):
>> >   target/mips: fpu: Fix recent regression in add.s after 1ace099f2a
>> >
>> > Stefan Brankovic (1):
>> >   disas: mips: Add Loongson 2F disassembler
>> >
>> >  configure  |1 +
>> >  disas/loongson2f.h | 2562 +
>> >  include/disas/dis-asm.h|1 +
>> >  include/exec/poison.h  |1 +
>> >  target/mips/cpu.c  |6 +
>> >  target/mips/fpu_helper.c   |2 +-
>> >  MAINTAINERS|1 +
>> >  disas/Makefile.objs|1 +
>> >  disas/loongson2f.cpp   | 8154 ++
>> ++
>>
>> Honestly, no. Peter, please don't merge this pull request.
>>
>> That disassembler source code is really huge, and I think someone should
>> give this a *proper* review first before we include this in our repo. I
>> just had a quick look at it, and I don't think that it is in the right
>> shape already. For example, there are hard-coded magic numbers there,
>> like:
>>
>> bool ADD::disas_output(disassemble_info *info)
>> +{
>> +char alias1[5];
>> +char alias2[5];
>> +char alias3[5];
>> ...
>>
>> and in a completely different function, this hard-coded 5 is used again:
>>
>> +void Instruction32::getAlias(char *buffer, int regNo)
>> +{
>> +switch (regNo) {
>> +case 0:
>> +strncpy(buffer, "zero", 5);
>> +break;
>> +case 1:
>> +strncpy(buffer, "at", 5);
>> ...
>>
>> That definitely needs to be turned into a proper #define or the length
>> needs to be passed as parameter to the function.
>>
>> Also the coding style is weird in a couple of places, and there were
>> checkpatch warnings.
>>
>> Apart from that, Paolo asked you to take a break from MIPS
>> maintainership for a while, Aleksandar. I strongly support that
>> suggestion. Your derogatory behavior during the last weeks, especially
>> in the last one, looked completely unacceptable to me. In my opinion you
>> really need some time to reflect yourself. You, and we all as a
>> community, now cannot continue just like nothing happened.
>>
>>  Thanks,
>>   Thomas
>>
>>

[PULL 3/3] scripts/performance: Add dissect.py script

[Aleksandar Markovic]

From: Ahmed Karaman 

Python script that dissects QEMU execution into three main phases:
code generation, JIT execution and helpers execution.

Syntax:
dissect.py [-h] --  [] \
  []

[-h] - Print the script arguments help message.

Example of usage:
dissect.py -- qemu-arm coulomb_double-arm

Example output:
Total Instructions:4,702,865,362

Code Generation: 115,819,309 2.463%
JIT Execution: 1,081,980,52823.007%
Helpers:   3,505,065,52574.530%

Signed-off-by: Ahmed Karaman 
Signed-off-by: Aleksandar Markovic 
Reviewed-by: Aleksandar Markovic 
Message-Id: <20200702142942.4887-2-ahmedkhaledkara...@gmail.com>
---
 scripts/performance/dissect.py | 165 +
 1 file changed, 165 insertions(+)
 create mode 100755 scripts/performance/dissect.py

diff --git a/scripts/performance/dissect.py b/scripts/performance/dissect.py
new file mode 100755
index 000..8c2967d
--- /dev/null
+++ b/scripts/performance/dissect.py
@@ -0,0 +1,165 @@
+#!/usr/bin/env python3
+
+#  Print the percentage of instructions spent in each phase of QEMU
+#  execution.
+#
+#  Syntax:
+#  dissect.py [-h] --  [] \
+#[]
+#
+#  [-h] - Print the script arguments help message.
+#
+#  Example of usage:
+#  dissect.py -- qemu-arm coulomb_double-arm
+#
+#  This file is a part of the project "TCG Continuous Benchmarking".
+#
+#  Copyright (C) 2020  Ahmed Karaman 
+#  Copyright (C) 2020  Aleksandar Markovic 
+#
+#  This program is free software: you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation, either version 2 of the License, or
+#  (at your option) any later version.
+#
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+#  GNU General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+import argparse
+import os
+import subprocess
+import sys
+
+
+def get_JIT_line(callgrind_data):
+"""
+Search for the first instance of the JIT call in
+the callgrind_annotate output when ran using --tree=caller
+This is equivalent to the self number of instructions of JIT.
+
+Parameters:
+callgrind_data (list): callgrind_annotate output
+
+Returns:
+(int): Line number
+   """
+line = -1
+for i in range(len(callgrind_data)):
+if callgrind_data[i].strip('\n') and \
+callgrind_data[i].split()[-1] == "[???]":
+line = i
+break
+if line == -1:
+sys.exit("Couldn't locate the JIT call ... Exiting.")
+return line
+
+
+def main():
+# Parse the command line arguments
+parser = argparse.ArgumentParser(
+usage='dissect.py [-h] -- '
+' [] '
+' []')
+
+parser.add_argument('command', type=str, nargs='+', help=argparse.SUPPRESS)
+
+args = parser.parse_args()
+
+# Extract the needed variables from the args
+command = args.command
+
+# Insure that valgrind is installed
+check_valgrind = subprocess.run(
+["which", "valgrind"], stdout=subprocess.DEVNULL)
+if check_valgrind.returncode:
+sys.exit("Please install valgrind before running the script.")
+
+# Run callgrind
+callgrind = subprocess.run((["valgrind",
+ "--tool=callgrind",
+ "--callgrind-out-file=/tmp/callgrind.data"]
++ command),
+   stdout=subprocess.DEVNULL,
+   stderr=subprocess.PIPE)
+if callgrind.returncode:
+sys.exit(callgrind.stderr.decode("utf-8"))
+
+# Save callgrind_annotate output to /tmp/callgrind_annotate.out
+with open("/tmp/callgrind_annotate.out", "w") as output:
+callgrind_annotate = subprocess.run(
+["callgrind_annotate", "/tmp/callgrind.data", "--tree=caller"],
+stdout=output,
+stderr=subprocess.PIPE)
+if callgrind_annotate.returncode:
+os.unlink('/tmp/callgrind.data')
+output.close()
+os.unlink('/tmp/callgrind_annotate.out')
+sys.exit(callgrind_annotate.stderr.decode("utf-8"))
+
+# Read the callgrind_annotate output to callgrind_data[]
+callgrind_data = []
+with open('/tmp/callgrind_annotate.out', 'r') as data:
+callgrind_data = data.readlines()
+
+# Line number with the total number of instructions

[PULL 0/3] MIPS + TCG Continuous Benchmarking queue for July 7th, 2020

[Aleksandar Markovic]

The following changes since commit 710fb08fd297d7a92163debce1959fae8f3b6ed7:

  Merge remote-tracking branch 
'remotes/huth-gitlab/tags/pull-request-2020-07-06' into staging (2020-07-07 
12:41:15 +0100)

are available in the git repository at:

  https://github.com/AMarkovic/qemu tags/mips-queue-jul-07-2020

for you to fetch changes up to fa6e7da119b6da4067e757924e165bc737bb1260:

  scripts/performance: Add dissect.py script (2020-07-07 18:32:20 +0200)



MIPS + TCG Continuous Benchmarking queue for July 7th, 2020

  Highlights:

 - Fix for a regression in FPU emulation add.s.
 - Add Loongson 2F disassembler.
 - Add a script for a GSoC project.

  Note:

 - A checkpatch error and a checkpatch warning are known and
 should be ignored.



Ahmed Karaman (1):
  scripts/performance: Add dissect.py script

Alex Richardson (1):
  target/mips: fpu: Fix recent regression in add.s after 1ace099f2a

Stefan Brankovic (1):
  disas: mips: Add Loongson 2F disassembler

 configure  |1 +
 disas/loongson2f.h | 2562 +
 include/disas/dis-asm.h|1 +
 include/exec/poison.h  |1 +
 target/mips/cpu.c  |6 +
 target/mips/fpu_helper.c   |2 +-
 MAINTAINERS|1 +
 disas/Makefile.objs|1 +
 disas/loongson2f.cpp   | 8154 
 scripts/performance/dissect.py |  165 +
 10 files changed, 10893 insertions(+), 1 deletion(-)
 create mode 100644 disas/loongson2f.h
 create mode 100644 disas/loongson2f.cpp
 create mode 100755 scripts/performance/dissect.py

-- 
2.7.4

Re: [PATCH] Fix MIPS add.s after 1ace099f2acb952eaaef0ba7725879949a7e4406

[Aleksandar Markovic]

On Fri, Jul 3, 2020 at 6:33 PM Alex Richardson
 wrote:
>
> After merging latest QEMU upstream into our CHERI fork, I noticed that
> some of the FPU tests in our MIPS baremetal testsuite
> (https://github.com/CTSRD-CHERI/cheritest) started failing. It turns out
> this commit accidentally changed add.s into a subtract.
>
> Signed-off-by: Alex Richardson 
> ---

Applied to MIPS + TCG Continuous Benchmarking queue.

>  target/mips/fpu_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
> index 7a3a61cab3..56beda49d8 100644
> --- a/target/mips/fpu_helper.c
> +++ b/target/mips/fpu_helper.c
> @@ -1221,7 +1221,7 @@ uint32_t helper_float_add_s(CPUMIPSState *env,
>  {
>  uint32_t wt2;
>
> -wt2 = float32_sub(fst0, fst1, >active_fpu.fp_status);
> +wt2 = float32_add(fst0, fst1, >active_fpu.fp_status);
>  update_fcr31(env, GETPC());
>  return wt2;
>  }
> --
> 2.27.0
>
>

[PULL 1/3] target/mips: fpu: Fix recent regression in add.s after 1ace099f2a

[Aleksandar Markovic]

From: Alex Richardson 

After merging latest QEMU upstream into our CHERI fork, I noticed
that some of the FPU tests in our MIPS baremetal testsuite
(https://github.com/CTSRD-CHERI/cheritest) started failing
It turns out that commit 1ace099f2a accidentally changed add.s
into a subtract.

Fixes: 1ace099f2a ("target/mips: fpu: Demacro ADD.")
Signed-off-by: Alex Richardson 
Signed-off-by: Aleksandar Markovic 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20200703161515.25966-1-alexander.richard...@cl.cam.ac.uk>
---
 target/mips/fpu_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
index 7a3a61c..56beda4 100644
--- a/target/mips/fpu_helper.c
+++ b/target/mips/fpu_helper.c
@@ -1221,7 +1221,7 @@ uint32_t helper_float_add_s(CPUMIPSState *env,
 {
 uint32_t wt2;
 
-wt2 = float32_sub(fst0, fst1, >active_fpu.fp_status);
+wt2 = float32_add(fst0, fst1, >active_fpu.fp_status);
 update_fcr31(env, GETPC());
 return wt2;
 }
-- 
2.7.4

Re: [PATCH v2 1/1] disas: mips: Add Loongson 2F disassembler

[Aleksandar Markovic]

On Sunday, July 5, 2020, Aleksandar Markovic <
aleksandar.qemu.de...@gmail.com> wrote:

>
>
> On Saturday, July 4, 2020, Aleksandar Markovic <
> aleksandar.qemu.de...@gmail.com> wrote:
>
>>
>>
>> On Friday, July 3, 2020, Stefan Brankovic 
>> wrote:
>>
>>> Add disassembler for Loongson 2F instruction set.
>>>
>>> Testing is done by comparing qemu disassembly output, obtained by
>>> using -d in_asm command line option, with appropriate objdump output.
>>>
>>> This disassembler is written as a generic disassembler that can be
>>> integrated into other projects. In this case, it is integrated into
>>> QEMU. One of initial key requirements was that it uses C++ as its
>>> language.
>>>
>>> Signed-off-by: Stefan Brankovic 
>>> ---
>>
>>
>>
> I did some basic tests, and the output matches objdump's.
>
> Apart from the mentioned cosmetic changes with ALIAS_MAX_LEN, there is one
> function invocation that should be under "ifdef", similar to the nanomips
> counterpart case.
>
> Otherwise:
>
> Reviewed-by: Aleksandar Markovic 
>
>
I plan to select this patch for the next MIPS + TCG Continuous Benchmarking
pull request.


>
>
>> Thank you, Stefan!
>>
>> I am going to dor some independant testing in next few days, including
>> building on systems without g++ (build should be successful, and the
>> disassembler should fallback on the current one).
>>
>> I noticed some cosmetic improvements may still be done, like, for
>> example, using [ALIAS_MAX_LEN] instead of [5] in numerous places. But,
>> there is no need to respin (send a new version) just for this. Overall, the
>> code looks well-organized and clean.
>>
>> An interesting topic for future work would be the automation of QEMU
>> disassembler testing. Not only for this dissasembler, but for any supported
>> disassembler in QEMU. I don't say you should do it, this is just a
>> brainstorming idea, somebody may hopefully pick it up.
>>
>> Congratulations on this interesting work!
>>
>> Aleksandar
>>
>>
>>
>>
>>>  MAINTAINERS |1 +
>>>  configure   |1 +
>>>  disas/Makefile.objs |1 +
>>>  disas/loongson2f.cpp| 8154 +++
>>>  disas/loongson2f.h  | 2562 
>>>  include/disas/dis-asm.h |1 +
>>>  include/exec/poison.h   |1 +
>>>  target/mips/cpu.c   |4 +
>>>  8 files changed, 10725 insertions(+)
>>>  create mode 100644 disas/loongson2f.cpp
>>>  create mode 100644 disas/loongson2f.h
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 3abe3faa4e..913ed2a6d3 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -219,6 +219,7 @@ S: Maintained
>>>  F: target/mips/
>>>  F: default-configs/*mips*
>>>  F: disas/*mips*
>>> +F: disas/loongson*
>>>  F: docs/system/cpu-models-mips.rst.inc
>>>  F: hw/intc/mips_gic.c
>>>  F: hw/mips/
>>> diff --git a/configure b/configure
>>> index 597e909b53..e163dac53e 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -8102,6 +8102,7 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
>>>  disas_config "MIPS"
>>>  if test -n "${cxx}"; then
>>>disas_config "NANOMIPS"
>>> +  disas_config "LOONGSON2F"
>>>  fi
>>>;;
>>>moxie*)
>>> diff --git a/disas/Makefile.objs b/disas/Makefile.objs
>>> index 3c1cdce026..0d5ee1e038 100644
>>> --- a/disas/Makefile.objs
>>> +++ b/disas/Makefile.objs
>>> @@ -14,6 +14,7 @@ common-obj-$(CONFIG_I386_DIS) += i386.o
>>>  common-obj-$(CONFIG_M68K_DIS) += m68k.o
>>>  common-obj-$(CONFIG_MICROBLAZE_DIS) += microblaze.o
>>>  common-obj-$(CONFIG_MIPS_DIS) += mips.o
>>> +common-obj-$(CONFIG_LOONGSON2F_DIS) += loongson2f.o
>>>  common-obj-$(CONFIG_NANOMIPS_DIS) += nanomips.o
>>>  common-obj-$(CONFIG_NIOS2_DIS) += nios2.o
>>>  common-obj-$(CONFIG_MOXIE_DIS) += moxie.o
>>> diff --git a/disas/loongson2f.cpp b/disas/loongson2f.cpp
>>> new file mode 100644
>>> index 00..e84a2c0f09
>>> --- /dev/null
>>> +++ b/disas/loongson2f.cpp
>>> @@ -0,0 +1,8154 @@
>>> +/*
>>> + *  Source file for Loongson 2F disassembler component of QEMU
>>> + *
>>> + *  Copyright (C) 2020  Stef

Re: [PATCH v2 1/1] disas: mips: Add Loongson 2F disassembler

[Aleksandar Markovic]

On Saturday, July 4, 2020, Aleksandar Markovic <
aleksandar.qemu.de...@gmail.com> wrote:

>
>
> On Friday, July 3, 2020, Stefan Brankovic 
> wrote:
>
>> Add disassembler for Loongson 2F instruction set.
>>
>> Testing is done by comparing qemu disassembly output, obtained by
>> using -d in_asm command line option, with appropriate objdump output.
>>
>> This disassembler is written as a generic disassembler that can be
>> integrated into other projects. In this case, it is integrated into
>> QEMU. One of initial key requirements was that it uses C++ as its
>> language.
>>
>> Signed-off-by: Stefan Brankovic 
>> ---
>
>
>
I did some basic tests, and the output matches objdump's.

Apart from the mentioned cosmetic changes with ALIAS_MAX_LEN, there is one
function invocation that should be under "ifdef", similar to the nanomips
counterpart case.

Otherwise:

Reviewed-by: Aleksandar Markovic 



> Thank you, Stefan!
>
> I am going to dor some independant testing in next few days, including
> building on systems without g++ (build should be successful, and the
> disassembler should fallback on the current one).
>
> I noticed some cosmetic improvements may still be done, like, for example,
> using [ALIAS_MAX_LEN] instead of [5] in numerous places. But, there is no
> need to respin (send a new version) just for this. Overall, the code looks
> well-organized and clean.
>
> An interesting topic for future work would be the automation of QEMU
> disassembler testing. Not only for this dissasembler, but for any supported
> disassembler in QEMU. I don't say you should do it, this is just a
> brainstorming idea, somebody may hopefully pick it up.
>
> Congratulations on this interesting work!
>
> Aleksandar
>
>
>
>
>>  MAINTAINERS |1 +
>>  configure   |1 +
>>  disas/Makefile.objs |1 +
>>  disas/loongson2f.cpp| 8154 +++
>>  disas/loongson2f.h  | 2562 
>>  include/disas/dis-asm.h |1 +
>>  include/exec/poison.h   |1 +
>>  target/mips/cpu.c   |4 +
>>  8 files changed, 10725 insertions(+)
>>  create mode 100644 disas/loongson2f.cpp
>>  create mode 100644 disas/loongson2f.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 3abe3faa4e..913ed2a6d3 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -219,6 +219,7 @@ S: Maintained
>>  F: target/mips/
>>  F: default-configs/*mips*
>>  F: disas/*mips*
>> +F: disas/loongson*
>>  F: docs/system/cpu-models-mips.rst.inc
>>  F: hw/intc/mips_gic.c
>>  F: hw/mips/
>> diff --git a/configure b/configure
>> index 597e909b53..e163dac53e 100755
>> --- a/configure
>> +++ b/configure
>> @@ -8102,6 +8102,7 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
>>  disas_config "MIPS"
>>  if test -n "${cxx}"; then
>>disas_config "NANOMIPS"
>> +  disas_config "LOONGSON2F"
>>  fi
>>;;
>>moxie*)
>> diff --git a/disas/Makefile.objs b/disas/Makefile.objs
>> index 3c1cdce026..0d5ee1e038 100644
>> --- a/disas/Makefile.objs
>> +++ b/disas/Makefile.objs
>> @@ -14,6 +14,7 @@ common-obj-$(CONFIG_I386_DIS) += i386.o
>>  common-obj-$(CONFIG_M68K_DIS) += m68k.o
>>  common-obj-$(CONFIG_MICROBLAZE_DIS) += microblaze.o
>>  common-obj-$(CONFIG_MIPS_DIS) += mips.o
>> +common-obj-$(CONFIG_LOONGSON2F_DIS) += loongson2f.o
>>  common-obj-$(CONFIG_NANOMIPS_DIS) += nanomips.o
>>  common-obj-$(CONFIG_NIOS2_DIS) += nios2.o
>>  common-obj-$(CONFIG_MOXIE_DIS) += moxie.o
>> diff --git a/disas/loongson2f.cpp b/disas/loongson2f.cpp
>> new file mode 100644
>> index 00..e84a2c0f09
>> --- /dev/null
>> +++ b/disas/loongson2f.cpp
>> @@ -0,0 +1,8154 @@
>> +/*
>> + *  Source file for Loongson 2F disassembler component of QEMU
>> + *
>> + *  Copyright (C) 2020  Stefan Brankovic 
>> + *
>> + *  This program is free software: you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License as published by
>> + *  the Free Software Foundation, either version 2 of the License, or
>> + *  (at your option) any later version.
>> + *
>> + *  This program is distributed in the hope that it will be useful,
>> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *  GNU General Public License for more details.
>> + *
>> + *  You should have 

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#2] Dissecting QEMU Into Three Main Parts

[Aleksandar Markovic]

On Saturday, July 4, 2020, Alex Bennée  wrote:

>
> Aleksandar Markovic  writes:
>
> > On Wednesday, July 1, 2020, Alex Bennée  wrote:
> >
> >>
> >> Ahmed Karaman  writes:
> >>
> >> > On Mon, Jun 29, 2020 at 6:03 PM Alex Bennée 
> >> wrote:
> >> >>
> >> >> Assuming your test case is constant execution (i.e. runs the same
> each
> >> >> time) you could run in through a plugins build to extract the number
> of
> >> >> guest instructions, e.g.:
> >> >>
> >> >>   ./aarch64-linux-user/qemu-aarch64 -plugin tests/plugin/libinsn.so
> -d
> >> plugin ./tests/tcg/aarch64-linux-user/sha1
> >> >>   SHA1=15dd99a1991e0b3826fede3deffc1feba42278e6
> >> >>   insns: 158603512
> >> >>
> >> >> --
> >> >> Alex Bennée
> >> >
> >> > Hi Mr. Alex,
> >> > I've created a plugins build as you've said using "--enable-plugins"
> >> option.
> >> > I've searched for "libinsn.so" plugin that you've mentioned in your
> >> > command but it isn't in that path.
> >>
> >> make plugins
> >>
> >> and you should find them in tests/plugins/
> >>
> >>
> > Hi, both Alex and Ahmed,
> >
> > Ahmed showed me tonight the first results with number of guest
> > instructions. It was almost eye-opening to me. The thing is, by now, I
> had
> > only vague picture that, on average, "many" host instructions are
> generated
> > per one guest instruction. Now, I could see exact ratio for each target,
> > for a particular example.
> >
> > A question for Alex:
> >
> > - What would be the application of this new info? (Except that one has
> nice
> > feeling, like I do, of knowing the exact ratio host/guest instruction
> for a
> > particular scenario.)
>
> Well I think the total number of guest instructions is important because
> some architectures are more efficient than others and this will an
> impact on the total executed instructions.
>
> > I just have a feeling there is more significance of this new data that I
> > currently see. Could it be that it can be used in analysis of
> performance?
> > Or measuring quality of emulation (TCG operation)? But how exactly? What
> > conclusion could potentially be derived from knowing number of guest
> > instructions?
>
> Knowing the ratio (especially as it changes between workloads) means you
> can better pin point where the inefficiencies lie. You don't want to
> spend your time chasing down an inefficiency that is down to the guest
> compiler ;-)
>
>
Yes, it is definitely worth having the exact number of guest instructions!

Ahmed and I knew from the outset, like everybody else for that matter, that
workload and guest compiler and architecture itself immensly impact any
measurement.

However, if we keep the same guest, guest compiler, and workload as well,
and change just qemu, than we should be able to draw conclusion on
qemu-specific issues, and hopefully remove some inefficiencies. I hope you
will see that approach in next Ahmed's reports.

Aleksandar





> >
> > Sorry for a "stupid" question.
> >
> > Aleksandar
> >
> >
> >
> >
> >> >
> >> > Are there any other options that I should configure my build with?
> >> > Thanks in advance.
> >> >
> >> > Regards,
> >> > Ahmed Karaman
> >>
> >>
> >> --
> >> Alex Bennée
> >>
>
>
> --
> Alex Bennée
>

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#2] Dissecting QEMU Into Three Main Parts

[Aleksandar Markovic]

On Saturday, July 4, 2020, Alex Bennée  wrote:

>
> Aleksandar Markovic  writes:
>
> > On Wednesday, July 1, 2020, Alex Bennée  wrote:
> >
> >>
> >> Ahmed Karaman  writes:
> >>
> >> > On Mon, Jun 29, 2020 at 6:03 PM Alex Bennée 
> >> wrote:
> >> >>
> >> >> Assuming your test case is constant execution (i.e. runs the same
> each
> >> >> time) you could run in through a plugins build to extract the number
> of
> >> >> guest instructions, e.g.:
> >> >>
> >> >>   ./aarch64-linux-user/qemu-aarch64 -plugin tests/plugin/libinsn.so
> -d
> >> plugin ./tests/tcg/aarch64-linux-user/sha1
> >> >>   SHA1=15dd99a1991e0b3826fede3deffc1feba42278e6
> >> >>   insns: 158603512
> >> >>
> >> >> --
> >> >> Alex Bennée
> >> >
> >> > Hi Mr. Alex,
> >> > I've created a plugins build as you've said using "--enable-plugins"
> >> option.
> >> > I've searched for "libinsn.so" plugin that you've mentioned in your
> >> > command but it isn't in that path.
> >>
> >> make plugins
> >>
> >> and you should find them in tests/plugins/
> >>
> >>
> > Hi, both Alex and Ahmed,
> >
> > Ahmed showed me tonight the first results with number of guest
> > instructions. It was almost eye-opening to me. The thing is, by now, I
> had
> > only vague picture that, on average, "many" host instructions are
> generated
> > per one guest instruction. Now, I could see exact ratio for each target,
> > for a particular example.
> >
> > A question for Alex:
> >
> > - What would be the application of this new info? (Except that one has
> nice
> > feeling, like I do, of knowing the exact ratio host/guest instruction
> for a
> > particular scenario.)
>
> Well I think the total number of guest instructions is important because
> some architectures are more efficient than others and this will an
> impact on the total executed instructions.
>
> > I just have a feeling there is more significance of this new data that I
> > currently see. Could it be that it can be used in analysis of
> performance?
> > Or measuring quality of emulation (TCG operation)? But how exactly? What
> > conclusion could potentially be derived from knowing number of guest
> > instructions?
>
> Knowing the ratio (especially as it changes between workloads) means you
> can better pin point where the inefficiencies lie. You don't want to
> spend your time chasing down an inefficiency that is down to the guest
> compiler ;-)
>
>
Thanks, Alex.

I am still thinking, looking at broader picture, maybe that ratio, if
applied on appropriate set of diverse workloads and averaged, could be the
considered something like "efficiency of QEMU" - and that measure could
possibly be used when making some TCG changes, aimed to achieve better
performance.

Interesting!

A.



> >
> > Sorry for a "stupid" question.
> >
> > Aleksandar
> >
> >
> >
> >
> >> >
> >> > Are there any other options that I should configure my build with?
> >> > Thanks in advance.
> >> >
> >> > Regards,
> >> > Ahmed Karaman
> >>
> >>
> >> --
> >> Alex Bennée
> >>
>
>
> --
> Alex Bennée
>

Re: [PATCH v2 1/1] disas: mips: Add Loongson 2F disassembler

[Aleksandar Markovic]

On Friday, July 3, 2020, Stefan Brankovic 
wrote:

> Add disassembler for Loongson 2F instruction set.
>
> Testing is done by comparing qemu disassembly output, obtained by
> using -d in_asm command line option, with appropriate objdump output.
>
> This disassembler is written as a generic disassembler that can be
> integrated into other projects. In this case, it is integrated into
> QEMU. One of initial key requirements was that it uses C++ as its
> language.
>
> Signed-off-by: Stefan Brankovic 
> ---


Thank you, Stefan!

I am going to do some independant testing in next few days, including
building on systems without g++ (build should be successful, and the
disassembler should fallback on the current one).

I noticed some cosmetic improvements may still be done, like, for example,
using [ALIAS_MAX_LEN] instead of [5] in numerous places. But, there is no
need to respin (send a new version) just for this. Overall, the code looks
well-organized and clean.

An interesting topic for future work would be the automation of QEMU
disassembler testing. Not only for this dissasembler, but for any supported
disassembler in QEMU. I don't say you should do it, this is just a
brainstorming idea, somebody may hopefully pick it up.

Congratulations on this interesting work!

Aleksandar




>  MAINTAINERS |1 +
>  configure   |1 +
>  disas/Makefile.objs |1 +
>  disas/loongson2f.cpp| 8154 +++
>  disas/loongson2f.h  | 2562 
>  include/disas/dis-asm.h |1 +
>  include/exec/poison.h   |1 +
>  target/mips/cpu.c   |4 +
>  8 files changed, 10725 insertions(+)
>  create mode 100644 disas/loongson2f.cpp
>  create mode 100644 disas/loongson2f.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3abe3faa4e..913ed2a6d3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -219,6 +219,7 @@ S: Maintained
>  F: target/mips/
>  F: default-configs/*mips*
>  F: disas/*mips*
> +F: disas/loongson*
>  F: docs/system/cpu-models-mips.rst.inc
>  F: hw/intc/mips_gic.c
>  F: hw/mips/
> diff --git a/configure b/configure
> index 597e909b53..e163dac53e 100755
> --- a/configure
> +++ b/configure
> @@ -8102,6 +8102,7 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
>  disas_config "MIPS"
>  if test -n "${cxx}"; then
>disas_config "NANOMIPS"
> +  disas_config "LOONGSON2F"
>  fi
>;;
>moxie*)
> diff --git a/disas/Makefile.objs b/disas/Makefile.objs
> index 3c1cdce026..0d5ee1e038 100644
> --- a/disas/Makefile.objs
> +++ b/disas/Makefile.objs
> @@ -14,6 +14,7 @@ common-obj-$(CONFIG_I386_DIS) += i386.o
>  common-obj-$(CONFIG_M68K_DIS) += m68k.o
>  common-obj-$(CONFIG_MICROBLAZE_DIS) += microblaze.o
>  common-obj-$(CONFIG_MIPS_DIS) += mips.o
> +common-obj-$(CONFIG_LOONGSON2F_DIS) += loongson2f.o
>  common-obj-$(CONFIG_NANOMIPS_DIS) += nanomips.o
>  common-obj-$(CONFIG_NIOS2_DIS) += nios2.o
>  common-obj-$(CONFIG_MOXIE_DIS) += moxie.o
> diff --git a/disas/loongson2f.cpp b/disas/loongson2f.cpp
> new file mode 100644
> index 00..e84a2c0f09
> --- /dev/null
> +++ b/disas/loongson2f.cpp
> @@ -0,0 +1,8154 @@
> +/*
> + *  Source file for Loongson 2F disassembler component of QEMU
> + *
> + *  Copyright (C) 2020  Stefan Brankovic 
> + *
> + *  This program is free software: you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation, either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program.  If not, see  >.
> + *
> + */
> +
> +extern "C" {
> +#include "qemu/osdep.h"
> +#include "qemu/bitops.h"
> +#include "disas/dis-asm.h"
> +}
> +
> +#include "loongson2f.h"
> +
> +int print_insn_loongson2f(bfd_vma addr, disassemble_info *info)
> +{
> +bfd_byte buffer[4];
> +uint32_t insn32;
> +int status;
> +Decoder *decoder = new Decoder();
> +
> +status = info->read_memory_func(addr, buffer, 4, info);
> +if (status != 0) {
> +info->memory_error_func(status, addr, info);
> +return -1;
> +}
> +if (info->endian == BFD_ENDIAN_BIG) {
> +insn32 = bfd_getb32(buffer);
> +} else {
> +insn32 = bfd_getl32(buffer);
> +}
> +
> +status = decoder->decode32(info, insn32);
> +
> +delete decoder;
> +
> +return status == 0 ? -1 : 4;
> +}
> +
> +int Fields32RdRsRt::getRd()
> +{
> +return this->rd;
> +}
> +
> +int Fields32RdRsRt::getRs()
> +{
> +return this->rs;
> +}
> +
> +int Fields32RdRsRt::getRt()
> +{
> +return this->rt;
> +}
> +
> +int 

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#2] Dissecting QEMU Into Three Main Parts

[Aleksandar Markovic]

On Wednesday, July 1, 2020, Alex Bennée  wrote:

>
> Ahmed Karaman  writes:
>
> > On Mon, Jun 29, 2020 at 6:03 PM Alex Bennée 
> wrote:
> >>
> >> Assuming your test case is constant execution (i.e. runs the same each
> >> time) you could run in through a plugins build to extract the number of
> >> guest instructions, e.g.:
> >>
> >>   ./aarch64-linux-user/qemu-aarch64 -plugin tests/plugin/libinsn.so -d
> plugin ./tests/tcg/aarch64-linux-user/sha1
> >>   SHA1=15dd99a1991e0b3826fede3deffc1feba42278e6
> >>   insns: 158603512
> >>
> >> --
> >> Alex Bennée
> >
> > Hi Mr. Alex,
> > I've created a plugins build as you've said using "--enable-plugins"
> option.
> > I've searched for "libinsn.so" plugin that you've mentioned in your
> > command but it isn't in that path.
>
> make plugins
>
> and you should find them in tests/plugins/
>
>
Hi, both Alex and Ahmed,

Ahmed showed me tonight the first results with number of guest
instructions. It was almost eye-opening to me. The thing is, by now, I had
only vague picture that, on average, "many" host instructions are generated
per one guest instruction. Now, I could see exact ratio for each target,
for a particular example.

A question for Alex:

- What would be the application of this new info? (Except that one has nice
feeling, like I do, of knowing the exact ratio host/guest instruction for a
particular scenario.)

I just have a feeling there is more significance of this new data that I
currently see. Could it be that it can be used in analysis of performance?
Or measuring quality of emulation (TCG operation)? But how exactly? What
conclusion could potentially be derived from knowing number of guest
instructions?

Sorry for a "stupid" question.

Aleksandar




> >
> > Are there any other options that I should configure my build with?
> > Thanks in advance.
> >
> > Regards,
> > Ahmed Karaman
>
>
> --
> Alex Bennée
>

Re: [PATCH] Fix MIPS add.s after 1ace099f2acb952eaaef0ba7725879949a7e4406

[Aleksandar Markovic]

On Friday, July 3, 2020, Alex Richardson 
wrote:

> After merging latest QEMU upstream into our CHERI fork, I noticed that
> some of the FPU tests in our MIPS baremetal testsuite
> (https://github.com/CTSRD-CHERI/cheritest) started failing. It turns out
> this commit accidentally changed add.s into a subtract.
>
>
Alex, all you said sounds very probable to me. I currently don't have any
dev system, at hand, but as soon as I get it, I will confirm/disconfirm
(but again, most likely confirm) this problem, and than we'll give you
green lifght for your patch.

Yours,
Aleksandar




> Signed-off-by: Alex Richardson 
> ---
>  target/mips/fpu_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/mips/fpu_helper.c b/target/mips/fpu_helper.c
> index 7a3a61cab3..56beda49d8 100644
> --- a/target/mips/fpu_helper.c
> +++ b/target/mips/fpu_helper.c
> @@ -1221,7 +1221,7 @@ uint32_t helper_float_add_s(CPUMIPSState *env,
>  {
>  uint32_t wt2;
>
> -wt2 = float32_sub(fst0, fst1, >active_fpu.fp_status);
> +wt2 = float32_add(fst0, fst1, >active_fpu.fp_status);
>  update_fcr31(env, GETPC());
>  return wt2;
>  }
> --
> 2.27.0
>
>

Re: [PATCH v2 1/1] scripts/performance: Add dissect.py script

[Aleksandar Markovic]

On Thursday, July 2, 2020, Ahmed Karaman 
wrote:

> Python script that dissects QEMU execution into three main phases:
> code generation, JIT execution and helpers execution.
>
> Syntax:
> dissect.py [-h] --  [] \
>   []
>
> [-h] - Print the script arguments help message.
>
> Example of usage:
> dissect.py -- qemu-arm coulomb_double-arm
>
> Example output:
> Total Instructions:4,702,865,362
>
> Code Generation: 115,819,309 2.463%
> JIT Execution: 1,081,980,52823.007%
> Helpers:   3,505,065,52574.530%
>
> Signed-off-by: Ahmed Karaman 
> ---


A very good script! Hopefully there will be some script in near future that
will, for example, list all hepers used in the test program.

Reviewed-by: Aleksandar Markovic 



>  scripts/performance/dissect.py | 165 +
>  1 file changed, 165 insertions(+)
>  create mode 100755 scripts/performance/dissect.py
>
> diff --git a/scripts/performance/dissect.py b/scripts/performance/dissect.
> py
> new file mode 100755
> index 00..8c2967d082
> --- /dev/null
> +++ b/scripts/performance/dissect.py
> @@ -0,0 +1,165 @@
> +#!/usr/bin/env python3
> +
> +#  Print the percentage of instructions spent in each phase of QEMU
> +#  execution.
> +#
> +#  Syntax:
> +#  dissect.py [-h] --  [] \
> +#[]
> +#
> +#  [-h] - Print the script arguments help message.
> +#
> +#  Example of usage:
> +#  dissect.py -- qemu-arm coulomb_double-arm
> +#
> +#  This file is a part of the project "TCG Continuous Benchmarking".
> +#
> +#  Copyright (C) 2020  Ahmed Karaman 
> +#  Copyright (C) 2020  Aleksandar Markovic  com>
> +#
> +#  This program is free software: you can redistribute it and/or modify
> +#  it under the terms of the GNU General Public License as published by
> +#  the Free Software Foundation, either version 2 of the License, or
> +#  (at your option) any later version.
> +#
> +#  This program is distributed in the hope that it will be useful,
> +#  but WITHOUT ANY WARRANTY; without even the implied warranty of
> +#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +#  GNU General Public License for more details.
> +#
> +#  You should have received a copy of the GNU General Public License
> +#  along with this program. If not, see <https://www.gnu.org/licenses/>.
> +
> +import argparse
> +import os
> +import subprocess
> +import sys
> +
> +
> +def get_JIT_line(callgrind_data):
> +"""
> +Search for the first instance of the JIT call in
> +the callgrind_annotate output when ran using --tree=caller
> +This is equivalent to the self number of instructions of JIT.
> +
> +Parameters:
> +callgrind_data (list): callgrind_annotate output
> +
> +Returns:
> +(int): Line number
> +   """
> +line = -1
> +for i in range(len(callgrind_data)):
> +if callgrind_data[i].strip('\n') and \
> +callgrind_data[i].split()[-1] == "[???]":
> +line = i
> +break
> +if line == -1:
> +sys.exit("Couldn't locate the JIT call ... Exiting.")
> +return line
> +
> +
> +def main():
> +# Parse the command line arguments
> +parser = argparse.ArgumentParser(
> +usage='dissect.py [-h] -- '
> +' [] '
> +' []')
> +
> +parser.add_argument('command', type=str, nargs='+',
> help=argparse.SUPPRESS)
> +
> +args = parser.parse_args()
> +
> +# Extract the needed variables from the args
> +command = args.command
> +
> +# Insure that valgrind is installed
> +check_valgrind = subprocess.run(
> +["which", "valgrind"], stdout=subprocess.DEVNULL)
> +if check_valgrind.returncode:
> +sys.exit("Please install valgrind before running the script.")
> +
> +# Run callgrind
> +callgrind = subprocess.run((["valgrind",
> + "--tool=callgrind",
> + "--callgrind-out-file=/tmp/
> callgrind.data"]
> ++ command),
> +   stdout=subprocess.DEVNULL,
> +   stderr=subprocess.PIPE)
> +if callgrind.returncode:
> +sys.exit(callgrind.stderr.decode("utf-8"))
> +
> +# Save callgrind_annotate output to /tmp/callgrind_annotate.out
> +with open("/tmp/callgrind_annotate.out", "w") as output:
> +callgrind_annotate = subproces

Re: [PATCH v4 28/40] tests/acceptance: skip multicore mips_malta tests on GitLab

[Aleksandar Markovic]

On Wed, Jul 1, 2020 at 4:03 PM Alex Bennée  wrote:
>
> For some reason these tests fail all the time on GitLab. I can
> re-create the hang around 3% of the time locally but it doesn't seem
> to be MTTCG related. For now skipIf on GITLAB_CI.
>
> Signed-off-by: Alex Bennée 
> Cc: Aleksandar Markovic 
> ---

Alex,

Thanks for having this test at all. I will review its content, but
here is my stupid question:

How can I, as a regular developer, repro the test in question? I am
not familiar with GitLab at all.

Thanks,
Aleksandar

>  tests/acceptance/machine_mips_malta.py | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/tests/acceptance/machine_mips_malta.py 
> b/tests/acceptance/machine_mips_malta.py
> index 92b4f28a112..7c9a4ee4d2d 100644
> --- a/tests/acceptance/machine_mips_malta.py
> +++ b/tests/acceptance/machine_mips_malta.py
> @@ -15,6 +15,7 @@ from avocado import skipUnless
>  from avocado_qemu import Test
>  from avocado_qemu import wait_for_console_pattern
>  from avocado.utils import archive
> +from avocado import skipIf
>
>
>  NUMPY_AVAILABLE = True
> @@ -99,6 +100,7 @@ class MaltaMachineFramebuffer(Test):
>  """
>  self.do_test_i6400_framebuffer_logo(1)
>
> +@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
>  def test_mips_malta_i6400_framebuffer_logo_7cores(self):
>  """
>  :avocado: tags=arch:mips64el
> @@ -108,6 +110,7 @@ class MaltaMachineFramebuffer(Test):
>  """
>  self.do_test_i6400_framebuffer_logo(7)
>
> +@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
>  def test_mips_malta_i6400_framebuffer_logo_8cores(self):
>  """
>  :avocado: tags=arch:mips64el
> --
> 2.20.1
>

Re: [PATCH v2 2/2] MAINTAINERS: Adjust MIPS maintainership

[Aleksandar Markovic]

On Wednesday, July 1, 2020, Aurelien Jarno  wrote:

> Hi Aleksandar,
>
> I know you have sent a v3 of this patch in the meantime, but I would
> still like to comment on it.
>
> First of all I confirm, that I do not have time to contribute to QEMU
> anymore and that I said I would like to resign from QEMU maintainership.
> We discussed that in person in Lyon back in October. I am happy to see
> that people are interested to take the maintainership.
>
> It happens that I known Huacai Chen from the time he was upstreaming the
> Loongson 3 support to the kernel, I have been testing and reviewing his
> patches. I also know Jiaxun Yang from the #debian-mips IRC channel. I
> know that they are both very competent and have a good knowledge of the
> open source world. I therefore agree that they are good additions to
> maintain and/or review the MIPS part of QEMU.
>
> All that said, they have been contributing only relatively recently to
> QEMU, and only to some areas. While I do support adding them to those
> areas, I wonder for example why adding them to the MIPS TCG target or
> to the Jazz board. That's probably something that should be done in a
> second step if they have an interest in doing so.
>
> I am fully aware that you posted a v3, that fixes exactly that after you
> got pointed out. However, I am still concerned by the way things
> happened.
>
>
Sure, I understand your point.

I am glad you respond in a reasonable, civilized, way, about a reasonable
topic, and I find talking to you a very pleasant experience - even if we
disagree, it doesn't make a difference at all.

The point of the segments you described is:

You have to throw somebody in unkown water, on purpose, in order to teach
him how to swim in the best way, and get out of him the best, his best.

That is all what I meant. No ulterior motive whatsoever.

Somebody like it, somebody does not.

Huacai doesn't, and I respect it, as shown in v3.

If you were here, all will be easier - we could talk, consult each other,
advice each other. I would enjoy working with you. I have also strong
feeling we would find common interest outside technical world, probably in
various intelectual realms. Perhaps this is not known to you, but french
thinkers are much appreciated and understood here in Serbia. We are
frankofilles.

But you choose not to be here. And what can I do? I can't force you to be
somewhere you don't want to be. I felt the loss of you not being here
throughout all my online presence.

Mixed feelings, ha?

Truly yours,
Aleksandar




> Regards,
> Aurelien
>
>
> On 2020-06-30 18:46, Aleksandar Markovic wrote:
> > Paul Burton and Aurelien Jarno removed for not being present.
> >
> > Huacai Chen and Jiaxun Yang step in as new energy.
> >
> > CC: Paul Burton 
> > CC: Aurelien Jarno 
> > Signed-off-by: Aleksandar Markovic 
> > ---
> >  MAINTAINERS | 15 ++-
> >  1 file changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5d8acf8d31..7fc16e21c9 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -213,7 +213,8 @@ F: disas/microblaze.c
> >
> >  MIPS TCG CPUs
> >  M: Aleksandar Markovic 
> > -R: Aurelien Jarno 
> > +M: Huacai Chen 
> > +R: Jiaxun Yang 
> >  R: Aleksandar Rikalo 
> >  S: Maintained
> >  F: target/mips/
> > @@ -377,6 +378,7 @@ F: target/arm/kvm.c
> >
> >  MIPS KVM CPUs
> >  M: Aleksandar Markovic 
> > +M: Huacai Chen 
> >  S: Odd Fixes
> >  F: target/mips/kvm.c
> >
> > @@ -1052,6 +1054,7 @@ MIPS Machines
> >  -
> >  Jazz
> >  M: Hervé Poussineau 
> > +M: Huacai Chen 
> >  R: Aleksandar Rikalo 
> >  S: Maintained
> >  F: hw/mips/jazz.c
> > @@ -1060,8 +1063,8 @@ F: hw/dma/rc4030.c
> >
> >  Malta
> >  M: Aleksandar Markovic 
> > +M: Huacai Chen 
> >  M: Philippe Mathieu-Daudé 
> > -R: Aurelien Jarno 
> >  S: Maintained
> >  F: hw/isa/piix4.c
> >  F: hw/acpi/piix4.c
> > @@ -1073,6 +1076,7 @@ F: tests/acceptance/machine_mips_malta.py
> >
> >  Mipssim
> >  M: Aleksandar Markovic 
> > +M: Huacai Chen 
> >  R: Aleksandar Rikalo 
> >  S: Odd Fixes
> >  F: hw/mips/mipssim.c
> > @@ -1080,7 +1084,6 @@ F: hw/net/mipsnet.c
> >
> >  R4000
> >  M: Aleksandar Markovic 
> > -R: Aurelien Jarno 
> >  R: Aleksandar Rikalo 
> >  S: Obsolete
> >  F: hw/mips/r4k.c
> > @@ -1103,7 +1106,8 @@ S: Maintained
> >  F: hw/intc/loongson_liointc.c
> >
> >  Boston
> > -M: Paul Burton 
> > +M: Aleksandar Markovic 
> > +M: Huacai Chen 
> >  R: Aleksandar Rikalo 
> >  S: Maintained
> >  F: hw/core/loader-fit.c
> > @@ -2677,7 +2681,8 @@ F: disas/i386.c
> >
> >  MIPS TCG target
> >  M: Aleksandar Markovic 
> > -R: Aurelien Jarno 
> > +M: Huacai Chen 
> > +R: Jiaxun Yang 
> >  R: Aleksandar Rikalo 
> >  S: Maintained
> >  F: tcg/mips/
> > --
> > 2.20.1
> >
> >
> >
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
>

Re: [PATCH v3 2/2] MAINTAINERS: Adjust MIPS maintainership

[Aleksandar Markovic]

On Wed, Jul 1, 2020 at 8:55 PM Aurelien Jarno  wrote:
>
> NACK
>
> On 2020-07-01 20:25, Aleksandar Markovic wrote:
> > Paul Burton and Aurelien Jarno removed for not being present.
> > A polite email was sent to them with question whether they
> > intend to actively participate, but there was no response.
>
> I indeed received a polite email, but it was sent less than 12 hours ago
> (Peter Maydell was Cc:ed and can confirm). I didn't even got time to
> answer it, I am still processing my emails after coming back from paid
> work.
>
> I don't understand this sudden need to rush things in adjusting the
> MIPS maintainership.
>

Well, from time to time it happens - there is nor rush.

Good, I am glad. Welcome back! :)

> Regards,
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

Re: [PATCH v3 2/2] MAINTAINERS: Adjust MIPS maintainership

[Aleksandar Markovic]

On Wed, Jul 1, 2020 at 8:43 PM Paul Burton  wrote:
>
> Hi Aleksandar,
>
> On Wed, Jul 1, 2020 at 11:26 AM Aleksandar Markovic
>  wrote:
> > Paul Burton and Aurelien Jarno removed for not being present.
> > A polite email was sent to them with question whether they
> > intend to actively participate, but there was no response.
>
> It was 2 days ago, not 2 months :)
>

:) Haha, but nobody said 2 months ago. What do you need - 2 years notice? :)

Paul, you know I would like you be with me here more than anything
else. I still feel the excitement of working together with you - can
you believe it? Some people here even (so wrongfully) think I have
some bad feelings about you, while the truth is the total opposite,
and I am sure you know too. All doors are open to you, if you want to
get involved, and wherever I will be. You are among the best
engineers, actually, now I am thinking, probably the very best, I
worked with!

I long our path cross again!

All the best on your pursuits!

Aleksandar

> I'm fine with being removed though - I no longer have access to modern
> MIPS CPUs or Boston hardware, and wouldn't currently have time to
> spend on them if I did. So as far as removing me goes:
>
>   Acked-by: Paul Burton 
>
> > In cases where needed, other persons step in instead.
> >
> > Huacai Chen and Jiaxun Yang step in as new energy.
>
> All the best with it moving forwards, and thanks to Huacai & Jiaxun
> for stepping up!
>
> Paul

Re: [PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Aleksandar Markovic]

On Wed, Jul 1, 2020 at 7:39 PM Aurelien Jarno  wrote:
>
> Aleksandar,
>
> On 2020-06-30 23:54, Aleksandar Markovic wrote:
> > As, in a very clear way, evidenced from the previous versions of this
> > series, this series real goal was not not to create some new
> > "malta-strict" machine, but to prepare path to creation of some
> > imagined "malta-unleashed" machine which will, to the contrary of
> > proclaimed goal, create a machine that could never exist in reality.
> > That is why I can't accept this series.
>
> I do not understand your opposition to this, and why it is an issue to
> support more than 2GiB of RAM for such a board. Supporting more than 2GiB
> of memory doesn't prevent people to emulate a real Malta board with less
> memory.
>
> In addition to that, the Malta board in QEMU has been supporting for
> many years more than the maximum 256MiB that is possible on a physical
> board. The QEMU version also supports way more than CPU variants than
> the physical board. In other word the existing malta machine in QEMU is
> already a "malta-unleashed".
>

Aurelien,

Glad to see you again. I am really sorry you were absent for so long.

Those (what you described in the paragraphs above) were mistakes from
the past. At some point, we needed to stop doing it, and finally
returned to the root QEMU principles of emulating systems as
faithfully as possible.

Knowing the needs like you described exist, my vision is that, just
for occasions you described, we create a virtual board that would have
very wide set of feature, unconstrained by real world. That way we
would avoid situations to "lie" in our emulations.

If you needed something more that is currently provided, you should
have issued a feature request through regular channels, and that would
have the people the chance to develop a solid solution, not some quick
fixes that pushes us further and further in wring direction.

Best wishes,
Aleksandar


Why didn't you respond on my mail from the other day? Do you plan to respond?

> And these possibilities have been used by MIPS* employees to develop
> MIPS R6 based distributions. Limiting the board in terms of RAM, CPU or
> virtio support would just make our users life more difficult for no
> gain.
>
> Regards,
> Aurelien
>
> * By MIPS employee, I mean persons that have been employed by companies
> owning MIPS over the last few years, including Imagination Technologies
> and Wave Computing.
>
>
>
> > уто, 30. јун 2020. у 21:58 Philippe Mathieu-Daudé  је
> > написао/ла:
> > >
> > > Hi,
> > >
> > > This series add a new 'malta-strict' machine, that aims to properly
> > > model the real hardware (which is not what the current 'malta'
> > > machine models).
> > >
> > > Since v2:
> > > - Initialize missing malta_machine_types::class_size
> > > - Remove RFC patch that confuses Aleksandar
> > > - Added examples of 'malta-strict' use
> > >
> > > $ git backport-diff -u v2
> > > Key:
> > > [] : patches are identical
> > > [] : number of functional differences between upstream/downstream 
> > > patch
> > > [down] : patch is downstream-only
> > > The flags [FC] indicate (F)unctional and (C)ontextual differences, 
> > > respectively
> > >
> > > 001/5:[] [--] 'hw/mips/malta: Trivial code movement'
> > > 002/5:[] [--] 'hw/mips/malta: Register the machine as a TypeInfo'
> > > 003/5:[0001] [FC] 'hw/mips/malta: Introduce 
> > > MaltaMachineClass::max_ramsize'
> > > 004/5:[] [--] 'hw/mips/malta: Introduce the 'malta-strict' machine'
> > > 005/5:[] [--] 'hw/mips/malta: Verify malta-strict machine uses 
> > > correct DIMM sizes'
> > >
> > > Philippe Mathieu-Daudé (5):
> > >   hw/mips/malta: Trivial code movement
> > >   hw/mips/malta: Register the machine as a TypeInfo
> > >   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> > >   hw/mips/malta: Introduce the 'malta-strict' machine
> > >   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
> > >
> > >  hw/mips/malta.c | 105 +---
> > >  1 file changed, 91 insertions(+), 14 deletions(-)
> > >
> > > --
> > > 2.21.3
> > >
> > >
> >
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

[PATCH v3 0/2] target mips: Misc fixes and improvements

[Aleksandar Markovic]

A collection of pending fixes and improvements.

v2->v3:

- minor content and commit message changes

v1->v2:

- minor content and commit message changes

Aleksandar Markovic (2):
  target/mips: Remove identical if/else branches
  MAINTAINERS: Adjust MIPS maintainership

 MAINTAINERS  | 11 +--
 target/mips/cp0_helper.c |  9 +
 2 files changed, 6 insertions(+), 14 deletions(-)

-- 
2.20.1

[PATCH v3 2/2] MAINTAINERS: Adjust MIPS maintainership

[Aleksandar Markovic]

Paul Burton and Aurelien Jarno removed for not being present.
A polite email was sent to them with question whether they
intend to actively participate, but there was no response.
In cases where needed, other persons step in instead.

Huacai Chen and Jiaxun Yang step in as new energy.

CC: Paul Burton 
CC: Aurelien Jarno 
CC: Huacai Chen 
CC: Jiaxun Yang 
Signed-off-by: Aleksandar Markovic 
---
 MAINTAINERS | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d8acf8d31..6f96c03f3e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -213,7 +213,8 @@ F: disas/microblaze.c
 
 MIPS TCG CPUs
 M: Aleksandar Markovic 
-R: Aurelien Jarno 
+R: Huacai Chen 
+R: Jiaxun Yang 
 R: Aleksandar Rikalo 
 S: Maintained
 F: target/mips/
@@ -377,6 +378,7 @@ F: target/arm/kvm.c
 
 MIPS KVM CPUs
 M: Aleksandar Markovic 
+M: Huacai Chen 
 S: Odd Fixes
 F: target/mips/kvm.c
 
@@ -1061,7 +1063,6 @@ F: hw/dma/rc4030.c
 Malta
 M: Aleksandar Markovic 
 M: Philippe Mathieu-Daudé 
-R: Aurelien Jarno 
 S: Maintained
 F: hw/isa/piix4.c
 F: hw/acpi/piix4.c
@@ -1080,7 +1081,6 @@ F: hw/net/mipsnet.c
 
 R4000
 M: Aleksandar Markovic 
-R: Aurelien Jarno 
 R: Aleksandar Rikalo 
 S: Obsolete
 F: hw/mips/r4k.c
@@ -1103,8 +1103,7 @@ S: Maintained
 F: hw/intc/loongson_liointc.c
 
 Boston
-M: Paul Burton 
-R: Aleksandar Rikalo 
+M: Aleksandar Rikalo 
 S: Maintained
 F: hw/core/loader-fit.c
 F: hw/mips/boston.c
@@ -2677,7 +2676,7 @@ F: disas/i386.c
 
 MIPS TCG target
 M: Aleksandar Markovic 
-R: Aurelien Jarno 
+R: Jiaxun Yang 
 R: Aleksandar Rikalo 
 S: Maintained
 F: tcg/mips/
-- 
2.20.1

[PATCH v3 1/2] target/mips: Remove identical if/else branches

[Aleksandar Markovic]

Remove the segment:

  if (other_tc == other->current_tc) {
  tccause = other->CP0_Cause;
  } else {
  tccause = other->CP0_Cause;
  }

Original contributor can't remember what was his intention.

Fixes: 5a25ce9487 ("mips: Hook in more reg accesses via mttr/mftr")
Buglink: https://bugs.launchpad.net/qemu/+bug/1885718
Signed-off-by: Aleksandar Markovic 
---
 target/mips/cp0_helper.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c
index bbf12e4a97..de64add038 100644
--- a/target/mips/cp0_helper.c
+++ b/target/mips/cp0_helper.c
@@ -375,16 +375,9 @@ target_ulong helper_mftc0_entryhi(CPUMIPSState *env)
 target_ulong helper_mftc0_cause(CPUMIPSState *env)
 {
 int other_tc = env->CP0_VPEControl & (0xff << CP0VPECo_TargTC);
-int32_t tccause;
 CPUMIPSState *other = mips_cpu_map_tc(env, _tc);
 
-if (other_tc == other->current_tc) {
-tccause = other->CP0_Cause;
-} else {
-tccause = other->CP0_Cause;
-}
-
-return tccause;
+return other->CP0_Cause;
 }
 
 target_ulong helper_mftc0_status(CPUMIPSState *env)
-- 
2.20.1

Re: [PATCH 2/2] checkpatch: Change occurences of 'kernel' to 'qemu' in user messages

[Aleksandar Markovic]

On Wed, Jul 1, 2020 at 4:20 PM Paolo Bonzini  wrote:
>
> On 20/06/20 17:04, Peter Maydell wrote:
> > On Sat, 20 Jun 2020 at 14:33, Aleksandar Markovic
> >  wrote:
> >>
> >> It is odd that we inform user that, for example, his current working
> >> directory is not kernel root, when, in face, we mean qemu root.
> >>
> >> Replace that and few other similar odd user messages.
> >>
> >> Signed-off-by: Aleksandar Markovic 
> >> ---
> >>  scripts/checkpatch.pl | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > Regardless of my comments on the cover letter, for user facing
> > messages this makes sense, especially since it's only 3 lines.
> >
> > Reviewed-by: Peter Maydell 
> >
> > thanks
> > -- PMM
> >
>
> Queued, thanks.
>

Thanks a lot, Paolo.

There is though one spelling mistake in my commit message:

s/face/fact

Truly yours,
Aleksandar

> paolo
>

Re: [PATCH v2 2/2] MAINTAINERS: Adjust MIPS maintainership

[Aleksandar Markovic]

On Wed, Jul 1, 2020 at 1:05 PM chen huacai  wrote:
>
> Hi, Philippe and Alexandar,
>
> On Wed, Jul 1, 2020 at 4:49 PM Philippe Mathieu-Daudé  wrote:
> >
> > On 7/1/20 10:00 AM, Philippe Mathieu-Daudé wrote:
> > > On 6/30/20 7:19 PM, Philippe Mathieu-Daudé wrote:
> > >> On 6/30/20 6:46 PM, Aleksandar Markovic wrote:
> > >>> Paul Burton and Aurelien Jarno removed for not being present.
> > >>>
> > >>> Huacai Chen and Jiaxun Yang step in as new energy.
> > >>>
> > >>> CC: Paul Burton 
> > >>> CC: Aurelien Jarno 
> > >>> Signed-off-by: Aleksandar Markovic 
> > >>> ---
> > >>>  MAINTAINERS | 15 ++-
> > >>>  1 file changed, 10 insertions(+), 5 deletions(-)
> > >>>
> > >>> diff --git a/MAINTAINERS b/MAINTAINERS
> > >>> index 5d8acf8d31..7fc16e21c9 100644
> > >>> --- a/MAINTAINERS
> > >>> +++ b/MAINTAINERS
> > >>> @@ -213,7 +213,8 @@ F: disas/microblaze.c
> > >>>
> > >>>  MIPS TCG CPUs
> > >>>  M: Aleksandar Markovic 
> > >>> -R: Aurelien Jarno 
> > >>> +M: Huacai Chen 
> > >>> +R: Jiaxun Yang 
> > >>>  R: Aleksandar Rikalo 
> > >>>  S: Maintained
> > >>>  F: target/mips/
> > >>> @@ -377,6 +378,7 @@ F: target/arm/kvm.c
> > >>>
> > >>>  MIPS KVM CPUs
> > >>>  M: Aleksandar Markovic 
> > >>> +M: Huacai Chen 
> > >>>  S: Odd Fixes
> > >>>  F: target/mips/kvm.c
> > >>>
> > >>> @@ -1052,6 +1054,7 @@ MIPS Machines
> > >>>  -
> > >>>  Jazz
> > >>>  M: Hervé Poussineau 
> > >>> +M: Huacai Chen 
> > >
> > > Hmm this is the Jazz hobbyist machine, Huacai are you sure this
> > > the correct section you want to be?
> > >
> > > Anyway Hervé Poussineau has to ack that, Aleksandar, it would
> > > be easier if you split this as a separate patch.
> > >
> > >>>  R: Aleksandar Rikalo 
> > >>>  S: Maintained
> > >>>  F: hw/mips/jazz.c
> > >>> @@ -1060,8 +1063,8 @@ F: hw/dma/rc4030.c
> > >>>
> > >>>  Malta
> > >>>  M: Aleksandar Markovic 
> > >>> +M: Huacai Chen 
> > >>>  M: Philippe Mathieu-Daudé 
> > >>> -R: Aurelien Jarno 
> > >
> > > Last time Aurelien commented on the Malta machine, was on March 23,
> > > 3 months ago, then there hasn't been Malta patches. As a reviewer
> > > he is present and provides valuable feedback, why are you kicking
> > > him out? See:
> > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg691406.html
> > >
> > > Huacai, has Jiangsu Lemote Tech Co., Ltd real interest to paid
> > > employees to maintain the Malta board?
> I think I can review TCG part and maintain KVM part currently, but
> can't maintain Jazz/Malta/Mipssim/R4k/Boston (maybe possible in
> future, but not now).
>

Sure, Huacai, I will respect your wish.

I truly like your cautious approach. Although, honestly speaking, your
credentials for being a maintainer are - at least - three order of
magnitude higher than for some other maintainer. But, people, here we
have a responsible, serious man - Huacai Chen! Bravo for caution,
bravo for being modest, and bravo for being not greedy!

My deep admiration! We want and we need such people in QEMU for MIPS!
There is a place for you here!

Aleksandar

> Thanks,
> Huacai
> > >
> > >>>  S: Maintained
> > >>>  F: hw/isa/piix4.c
> > >>>  F: hw/acpi/piix4.c
> > >>> @@ -1073,6 +1076,7 @@ F: tests/acceptance/machine_mips_malta.py
> > >>>
> > >>>  Mipssim
> > >>>  M: Aleksandar Markovic 
> > >>> +M: Huacai Chen 
> > >>>  R: Aleksandar Rikalo 
> > >>>  S: Odd Fixes
> > >
> > > Now that you have 2 maintainers, you can raise the status to Maintained.
> > >
> > >>>  F: hw/mips/mipssim.c
> > >>> @@ -1080,7 +1084,6 @@ F: hw/net/mipsnet.c
> > >>>
> > >>>  R4000
> > >>>  M: Aleksandar Markovic 
> > >>> -R: Aurelien Jarno 
> > >
> > > I'm sure Aurelien will agree with this part. But let's wait
> > > for his feedback.
> > >
> > >>>  R: Aleksandar Rikalo 
&

Re: [PATCH 2/2] checkpatch: Change occurences of 'kernel' to 'qemu' in user messages

[Aleksandar Markovic]

On Sat, Jun 20, 2020 at 9:32 AM Aleksandar Markovic
 wrote:
>
> It is odd that we inform user that, for example, his current working
> directory is not kernel root, when, in face, we mean qemu root.
>
> Replace that and few other similar odd user messages.
>
> Signed-off-by: Aleksandar Markovic 
> ---

Paolo, Stefan, Michael,

Are some of you willing to select this patch for your queues?

I could include it in my mips queue, scheduled to be sent soon, but I
certainly don't want to be seen intruding into someone else's area.

Truly yours, Aleksandar

>  scripts/checkpatch.pl | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index c760c5a4a9..f46c18e413 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -49,7 +49,7 @@ Version: $V
>
>  Options:
>-q, --quietquiet
> -  --no-tree  run without a kernel tree
> +  --no-tree  run without a qemu tree
>--no-signoff   do not check for 'Signed-off-by' line
>--patchtreat FILE as patchfile
>--branch   treat args as GIT revision list
> @@ -57,7 +57,7 @@ Options:
>--terseone line per report
>-f, --file treat FILE as regular source file
>--strict   fail if only warnings are found
> -  --root=PATHPATH to the kernel tree root
> +  --root=PATHPATH to the qemu tree root
>--no-summary   suppress the per-file summary
>--mailback only produce a report in case of warnings/errors
>--summary-file include the filename in summary
> @@ -203,7 +203,7 @@ if ($tree) {
> }
>
> if (!defined $root) {
> -   print "Must be run from the top-level dir. of a kernel 
> tree\n";
> +   print "Must be run from the top-level dir. of a qemu tree\n";
> exit(2);
> }
>  }
> --
> 2.20.1
>

Re: [PATCH v3 0/5] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Aleksandar Markovic]

As, in a very clear way, evidenced from the previous versions of this
series, this series real goal was not not to create some new
"malta-strict" machine, but to prepare path to creation of some
imagined "malta-unleashed" machine which will, to the contrary of
proclaimed goal, create a machine that could never exist in reality.
That is why I can't accept this series.

Regards,
Aleksandar


уто, 30. јун 2020. у 21:58 Philippe Mathieu-Daudé  је
написао/ла:
>
> Hi,
>
> This series add a new 'malta-strict' machine, that aims to properly
> model the real hardware (which is not what the current 'malta'
> machine models).
>
> Since v2:
> - Initialize missing malta_machine_types::class_size
> - Remove RFC patch that confuses Aleksandar
> - Added examples of 'malta-strict' use
>
> $ git backport-diff -u v2
> Key:
> [] : patches are identical
> [] : number of functional differences between upstream/downstream patch
> [down] : patch is downstream-only
> The flags [FC] indicate (F)unctional and (C)ontextual differences, 
> respectively
>
> 001/5:[] [--] 'hw/mips/malta: Trivial code movement'
> 002/5:[] [--] 'hw/mips/malta: Register the machine as a TypeInfo'
> 003/5:[0001] [FC] 'hw/mips/malta: Introduce MaltaMachineClass::max_ramsize'
> 004/5:[] [--] 'hw/mips/malta: Introduce the 'malta-strict' machine'
> 005/5:[] [--] 'hw/mips/malta: Verify malta-strict machine uses correct 
> DIMM sizes'
>
> Philippe Mathieu-Daudé (5):
>   hw/mips/malta: Trivial code movement
>   hw/mips/malta: Register the machine as a TypeInfo
>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
>   hw/mips/malta: Introduce the 'malta-strict' machine
>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
>
>  hw/mips/malta.c | 105 +---
>  1 file changed, 91 insertions(+), 14 deletions(-)
>
> --
> 2.21.3
>
>

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Aleksandar Markovic]

уто, 30. јун 2020. у 19:16 Philippe Mathieu-Daudé  је
написао/ла:
>
> On 6/30/20 6:55 PM, Aleksandar Markovic wrote:
> > уто, 30. јун 2020. у 18:46 Philippe Mathieu-Daudé  је
> > написао/ла:
> >>
> >> On 6/30/20 5:38 PM, Aleksandar Markovic wrote:
> >>> уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé  је
> >>> написао/ла:
> >>>>
> >>>> Hi,
> >>>>
> >>>> This series add a new 'malta-strict' machine, that aims to properly
> >>>> model the real hardware (which is not what the current 'malta'
> >>>> machine models).
> >>>>
> >>>> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
> >>>> patch is included. This might start another endless discussion
> >>>> upstream, but this is not the point of, so I still include it
> >>>> for people to test. The rest of the series is candidate for merging
> >>>> in mainstream QEMU.
> >>>>
> >>>> Philippe Mathieu-Daudé (6):
> >>>>   hw/mips/malta: Trivial code movement
> >>>>   hw/mips/malta: Register the machine as a TypeInfo
> >>>>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> >>>>   hw/mips/malta: Introduce the 'malta-strict' machine
> >>>>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
> >>>>   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
> >>>>
> >>>>  hw/mips/malta.c | 125 ++--
> >>>>  1 file changed, 111 insertions(+), 14 deletions(-)
> >>>>
> >>>> --
> >>>
> >>> This whole series is based on idea of emulating physically
> >>> non-existing feature, and as such violates the fundamental principles
> >>> of QEMU.
> >>>
> >>> As such, not acceptable for upstreaming.
> >>>
> >>> I don't see the point of sending again the same series, in just
> >>> cosmetically different form, if it was said to you that the concept is
> >>> wrong.
> >>
> >> Have you looked at the patches? What "violates the fundamental
> >> principles of QEMU" is the code currently in mainstream. Should
> >> we remove it? I can send a patch for it if it pleases you, but
> >> you will make QEMU unuseful for many distribution users.
> >>
> >
> > Past mistakes are past mistakes. We have to live with them. And not
> > make them in the future.
> >
> > I see the whole series as a precursor for your change that repeats
> > past mistakes, a "wolf in sheep clothing".
> >
> > That's why I reject the series as a whole.
>
> As a co-maintainer I don't accept that.
>

I offered you the full maintainership for Malta.

You said you can proveide only "Odd fiexes".

I had to jump in to provide "Maintained" status.

Therefore, I provide the higher level of maintainership, and you have
to respect that. But you don't.

Regards,
Aleksandar

> The 'malta' machine is not changed, the series adds the 'malta-strict'
> machine which check the RAM restriction:
>
> $ qemu-system-mips -M malta-strict -bios /dev/null -m 512
> qemu-system-mips: Too much memory for this machine: 512 MiB, maximum 256 MiB
>
> $ qemu-system-mips -M malta-strict -bios /dev/null -m 252
> qemu-system-mips: RAM size must be the combination of 4 powers of 2
>
> $ qemu-system-mips -M malta-strict -monitor stdio -S -bios /dev/null -m 100
> QEMU 5.0.50 monitor - type 'help' for more information
> (qemu) info mtree
> address-space: memory
>   - (prio 0, i/o): system
> -063f (prio 0, ram): alias
> mips_malta_low_preio.ram @mips_malta.ram -063f
>
> 100 = 64 + 32 + 2 + 2
>
> >
> > Yours,
> > Aleksandar
> >
> >> What this series does is emulate the physically existing feature
> >> that are not yet emulated in QEMU.
> >>
> >> Please refer to the datasheet 'MIPS Document Number: MD00051
> >> Revision 01.07' before rejecting this series, and find the
> >> correct arguments.
> >>
> >> Thanks.
> >>
> >>>
> >>> Regards,
> >>> Aleksandar
> >>>
> >>>
> >>>> 2.21.3
> >>>>
> >>>
> >

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Aleksandar Markovic]

уто, 30. јун 2020. у 18:46 Philippe Mathieu-Daudé  је
написао/ла:
>
> On 6/30/20 5:38 PM, Aleksandar Markovic wrote:
> > уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé  је
> > написао/ла:
> >>
> >> Hi,
> >>
> >> This series add a new 'malta-strict' machine, that aims to properly
> >> model the real hardware (which is not what the current 'malta'
> >> machine models).
> >>
> >> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
> >> patch is included. This might start another endless discussion
> >> upstream, but this is not the point of, so I still include it
> >> for people to test. The rest of the series is candidate for merging
> >> in mainstream QEMU.
> >>
> >> Philippe Mathieu-Daudé (6):
> >>   hw/mips/malta: Trivial code movement
> >>   hw/mips/malta: Register the machine as a TypeInfo
> >>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> >>   hw/mips/malta: Introduce the 'malta-strict' machine
> >>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
> >>   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
> >>
> >>  hw/mips/malta.c | 125 ++--
> >>  1 file changed, 111 insertions(+), 14 deletions(-)
> >>
> >> --
> >
> > This whole series is based on idea of emulating physically
> > non-existing feature, and as such violates the fundamental principles
> > of QEMU.
> >
> > As such, not acceptable for upstreaming.
> >
> > I don't see the point of sending again the same series, in just
> > cosmetically different form, if it was said to you that the concept is
> > wrong.
>
> Have you looked at the patches? What "violates the fundamental
> principles of QEMU" is the code currently in mainstream. Should
> we remove it? I can send a patch for it if it pleases you, but
> you will make QEMU unuseful for many distribution users.
>

Past mistakes are past mistakes. We have to live with them. And not
make them in the future.

I see the whole series as a precursor for your change that repeats
past mistakes, a "wolf in sheep clothing".

That's why I reject the series as a whole.

Yours,
Aleksandar

> What this series does is emulate the physically existing feature
> that are not yet emulated in QEMU.
>
> Please refer to the datasheet 'MIPS Document Number: MD00051
> Revision 01.07' before rejecting this series, and find the
> correct arguments.
>
> Thanks.
>
> >
> > Regards,
> > Aleksandar
> >
> >
> >> 2.21.3
> >>
> >

[PATCH v2 1/2] target/mips: Remove identical if/else branches

[Aleksandar Markovic]

Remove the segment:

  if (other_tc == other->current_tc) {
  tccause = other->CP0_Cause;
  } else {
  tccause = other->CP0_Cause;
  }

Original contributor can't remember what was his intention.

Bug: 1885718
Signed-off-by: Aleksandar Markovic 
---
 target/mips/cp0_helper.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c
index bbf12e4a97..de64add038 100644
--- a/target/mips/cp0_helper.c
+++ b/target/mips/cp0_helper.c
@@ -375,16 +375,9 @@ target_ulong helper_mftc0_entryhi(CPUMIPSState *env)
 target_ulong helper_mftc0_cause(CPUMIPSState *env)
 {
 int other_tc = env->CP0_VPEControl & (0xff << CP0VPECo_TargTC);
-int32_t tccause;
 CPUMIPSState *other = mips_cpu_map_tc(env, _tc);
 
-if (other_tc == other->current_tc) {
-tccause = other->CP0_Cause;
-} else {
-tccause = other->CP0_Cause;
-}
-
-return tccause;
+return other->CP0_Cause;
 }
 
 target_ulong helper_mftc0_status(CPUMIPSState *env)
-- 
2.20.1

[PATCH v2 0/2] target mips: Misc fixes and improvements

[Aleksandar Markovic]

A collection of pending fixes and improvements.

v1->v2:

- minor content and commit message changes

Aleksandar Markovic (2):
  target/mips: Remove identical if/else branches
  MAINTAINERS: Adjust MIPS maintainership

 MAINTAINERS  | 15 ++-
 target/mips/cp0_helper.c |  9 +
 2 files changed, 11 insertions(+), 13 deletions(-)

-- 
2.20.1

[PATCH v2 2/2] MAINTAINERS: Adjust MIPS maintainership

[Aleksandar Markovic]

Paul Burton and Aurelien Jarno removed for not being present.

Huacai Chen and Jiaxun Yang step in as new energy.

CC: Paul Burton 
CC: Aurelien Jarno 
Signed-off-by: Aleksandar Markovic 
---
 MAINTAINERS | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d8acf8d31..7fc16e21c9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -213,7 +213,8 @@ F: disas/microblaze.c
 
 MIPS TCG CPUs
 M: Aleksandar Markovic 
-R: Aurelien Jarno 
+M: Huacai Chen 
+R: Jiaxun Yang 
 R: Aleksandar Rikalo 
 S: Maintained
 F: target/mips/
@@ -377,6 +378,7 @@ F: target/arm/kvm.c
 
 MIPS KVM CPUs
 M: Aleksandar Markovic 
+M: Huacai Chen 
 S: Odd Fixes
 F: target/mips/kvm.c
 
@@ -1052,6 +1054,7 @@ MIPS Machines
 -
 Jazz
 M: Hervé Poussineau 
+M: Huacai Chen 
 R: Aleksandar Rikalo 
 S: Maintained
 F: hw/mips/jazz.c
@@ -1060,8 +1063,8 @@ F: hw/dma/rc4030.c
 
 Malta
 M: Aleksandar Markovic 
+M: Huacai Chen 
 M: Philippe Mathieu-Daudé 
-R: Aurelien Jarno 
 S: Maintained
 F: hw/isa/piix4.c
 F: hw/acpi/piix4.c
@@ -1073,6 +1076,7 @@ F: tests/acceptance/machine_mips_malta.py
 
 Mipssim
 M: Aleksandar Markovic 
+M: Huacai Chen 
 R: Aleksandar Rikalo 
 S: Odd Fixes
 F: hw/mips/mipssim.c
@@ -1080,7 +1084,6 @@ F: hw/net/mipsnet.c
 
 R4000
 M: Aleksandar Markovic 
-R: Aurelien Jarno 
 R: Aleksandar Rikalo 
 S: Obsolete
 F: hw/mips/r4k.c
@@ -1103,7 +1106,8 @@ S: Maintained
 F: hw/intc/loongson_liointc.c
 
 Boston
-M: Paul Burton 
+M: Aleksandar Markovic 
+M: Huacai Chen 
 R: Aleksandar Rikalo 
 S: Maintained
 F: hw/core/loader-fit.c
@@ -2677,7 +2681,8 @@ F: disas/i386.c
 
 MIPS TCG target
 M: Aleksandar Markovic 
-R: Aurelien Jarno 
+M: Huacai Chen 
+R: Jiaxun Yang 
 R: Aleksandar Rikalo 
 S: Maintained
 F: tcg/mips/
-- 
2.20.1

Re: [PATCH v2 0/6] hw/mips/malta: Add the 'malta-strict' machine, matching Malta hardware

[Aleksandar Markovic]

уто, 30. јун 2020. у 16:52 Philippe Mathieu-Daudé  је
написао/ла:
>
> Hi,
>
> This series add a new 'malta-strict' machine, that aims to properly
> model the real hardware (which is not what the current 'malta'
> machine models).
>
> As a bonus for Debian builders, a 'malta-unleashed' machine RFC
> patch is included. This might start another endless discussion
> upstream, but this is not the point of, so I still include it
> for people to test. The rest of the series is candidate for merging
> in mainstream QEMU.
>
> Philippe Mathieu-Daudé (6):
>   hw/mips/malta: Trivial code movement
>   hw/mips/malta: Register the machine as a TypeInfo
>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
>   hw/mips/malta: Introduce the 'malta-strict' machine
>   hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
>   hw/mips/malta: Introduce the 'malta-unleashed' 64-bit machine
>
>  hw/mips/malta.c | 125 ++--
>  1 file changed, 111 insertions(+), 14 deletions(-)
>
> --

This whole series is based on idea of emulating physically
non-existing feature, and as such violates the fundamental principles
of QEMU.

As such, not acceptable for upstreaming.

I don't see the point of sending again the same series, in just
cosmetically different form, if it was said to you that the concept is
wrong.

Regards,
Aleksandar


> 2.21.3
>

[PATCH 2/2] MAINTAINERS: Adjust MIPS maintainership

[Aleksandar Markovic]

Paul Burton and Aurelien Jarno removed for not being present.

Huacai Chen and Jiaxun Yang step in as reinforcement.

CC: Paul Burton 
CC: Aurelien Jarno 
Signed-off-by: Aleksandar Markovic 
---
 MAINTAINERS | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d8acf8d31..908431580c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -213,7 +213,8 @@ F: disas/microblaze.c
 
 MIPS TCG CPUs
 M: Aleksandar Markovic 
-R: Aurelien Jarno 
+M: Huacai Chen 
+R: Jiaxun Yang 
 R: Aleksandar Rikalo 
 S: Maintained
 F: target/mips/
@@ -1061,7 +1062,6 @@ F: hw/dma/rc4030.c
 Malta
 M: Aleksandar Markovic 
 M: Philippe Mathieu-Daudé 
-R: Aurelien Jarno 
 S: Maintained
 F: hw/isa/piix4.c
 F: hw/acpi/piix4.c
@@ -1080,7 +1080,6 @@ F: hw/net/mipsnet.c
 
 R4000
 M: Aleksandar Markovic 
-R: Aurelien Jarno 
 R: Aleksandar Rikalo 
 S: Obsolete
 F: hw/mips/r4k.c
@@ -1103,7 +1102,7 @@ S: Maintained
 F: hw/intc/loongson_liointc.c
 
 Boston
-M: Paul Burton 
+M: Aleksandar Markovic 
 R: Aleksandar Rikalo 
 S: Maintained
 F: hw/core/loader-fit.c
@@ -2677,7 +2676,8 @@ F: disas/i386.c
 
 MIPS TCG target
 M: Aleksandar Markovic 
-R: Aurelien Jarno 
+M: Huacai Chen 
+R: Jiaxun Yang 
 R: Aleksandar Rikalo 
 S: Maintained
 F: tcg/mips/
-- 
2.20.1

[PATCH 1/2] target/mips: Remove identical if/else branches

[Aleksandar Markovic]

Remove the segment:

  if (other_tc == other->current_tc) {
  tccause = other->CP0_Cause;
  } else {
  tccause = other->CP0_Cause;
  }

Original contributor can't remember what was his intention.

Signed-off-by: Aleksandar Markovic 
---
 target/mips/cp0_helper.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c
index bbf12e4a97..de64add038 100644
--- a/target/mips/cp0_helper.c
+++ b/target/mips/cp0_helper.c
@@ -375,16 +375,9 @@ target_ulong helper_mftc0_entryhi(CPUMIPSState *env)
 target_ulong helper_mftc0_cause(CPUMIPSState *env)
 {
 int other_tc = env->CP0_VPEControl & (0xff << CP0VPECo_TargTC);
-int32_t tccause;
 CPUMIPSState *other = mips_cpu_map_tc(env, _tc);
 
-if (other_tc == other->current_tc) {
-tccause = other->CP0_Cause;
-} else {
-tccause = other->CP0_Cause;
-}
-
-return tccause;
+return other->CP0_Cause;
 }
 
 target_ulong helper_mftc0_status(CPUMIPSState *env)
-- 
2.20.1

[PATCH 0/2] target mips: Misc fixes and improvements

[Aleksandar Markovic]

A collection of pendind fixes and improvements.

Aleksandar Markovic (2):
  target/mips: Remove identical if/else branches
  MAINTAINERS: Adjust MIPS maintainership

 MAINTAINERS  | 10 +-
 target/mips/cp0_helper.c |  9 +
 2 files changed, 6 insertions(+), 13 deletions(-)

-- 
2.20.1

[Bug 1885718] Re: qemu/target/mips/op_helper.c:943:5: style:inconclusive: Found duplicate branches for 'if' and 'else'

[Aleksandar Markovic]

*** This bug is a duplicate of bug 1856706 ***
https://bugs.launchpad.net/bugs/1856706

Thank you for reporting this!

Believe it or not, this has been a know issue to us for a while. We
contacted the original contributor, and he says he can't recall what he
actually meant when he wrote the segment. We left it as is until he
remembers. However, this seems not likely to happen, and probably we
will issue a fix soon. In any case, it is good that you reported it,
many thanks!

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1885718

Title:
  qemu/target/mips/op_helper.c:943:5: style:inconclusive: Found
  duplicate branches for 'if' and 'else'

Status in QEMU:
  New

Bug description:
  Source code is

  if (other_tc == other->current_tc) {
  tccause = other->CP0_Cause;
  } else {
  tccause = other->CP0_Cause;
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1885718/+subscriptions

Re: [PATCH 0/7] hw/mips/malta: Rework to allow more than 2GB of RAM on 64-bit

[Aleksandar Markovic]

уто, 30. јун 2020. у 13:59 Philippe Mathieu-Daudé  је
написао/ла:
>
> On 6/30/20 1:55 PM, Aleksandar Markovic wrote:
> > уто, 30. јун 2020. у 13:34 Philippe Mathieu-Daudé  је
> > написао/ла:
> >>
> >> On 6/30/20 1:17 PM, Aleksandar Markovic wrote:
> >>> уторак, 30. јун 2020., Philippe Mathieu-Daudé  >>> <mailto:f4...@amsat.org>> је написао/ла:
> >>>
> >>> On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> >>> >
> >>> >
> >>> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  >>> <mailto:f4...@amsat.org>
> >>> > <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>> је написао/ла:
> >>> >
> >>> > On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
> >>> > mailto:f4...@amsat.org>
> >>> <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>> wrote:
> >>> > >
> >>> > > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> >>> > > >
> >>> > > >
> >>> > > > уторак, 30. јун 2020., Philippe Mathieu-Daudé
> >>> mailto:f4...@amsat.org>
> >>> > <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>
> >>> > > > <mailto:f4...@amsat.org <mailto:f4...@amsat.org>
> >>> <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>>> је написао/ла:
> >>> > > >
> >>> > > > Hi,
> >>> > > >
> >>> > > > Following Jiaxun Yang's patch and discussion:
> >>> > > > https://patchwork.kernel.org/patch/11416915/
> >>> <https://patchwork.kernel.org/patch/11416915/>
> >>> > <https://patchwork.kernel.org/patch/11416915/
> >>> <https://patchwork.kernel.org/patch/11416915/>>
> >>> > > > <https://patchwork.kernel.org/patch/11416915/
> >>> <https://patchwork.kernel.org/patch/11416915/>
> >>> > <https://patchwork.kernel.org/patch/11416915/
> >>> <https://patchwork.kernel.org/patch/11416915/>>>
> >>> > > >
> >>> > > > - Rename the current machine as 'malta-virt' (keeping
> >>> > 'malta' aliased)
> >>> > > >   Suggestions for better names are welcome, maybe
> >>> > 'malta-unreal' or
> >>> > > >   'malta-unleashed' instead?
> >>> > > > - Add 'malta-phys' which respects hardware
> >>> restrictions (on
> >>> > RAM so far)
> >>> > > > - Unleash 'malta-virt' to allow more than 2GB on 64-bit
> >>> > > >
> >>> > > > Philippe Mathieu-Daudé (7):
> >>> > > >   hw/mips/malta: Trivial code movement
> >>> > > >   hw/mips/malta: Register the machine as a TypeInfo
> >>> > > >   hw/mips/malta: Rename 'malta' machine as 'malta-virt'
> >>> > > >   hw/mips/malta: Introduce 
> >>> MaltaMachineClass::max_ramsize
> >>> > > >   hw/mips/malta: Introduce the 'malta-phys' machine
> >>> > > >   hw/mips/malta: Verify malta-phys machine uses
> >>> correct DIMM
> >>> > sizes
> >>> > > >   hw/mips/malta: Allow more than 2GB on 64-bit 
> >>> malta-virt
> >>> > > >
> >>> > > >  hw/mips/malta.c | 121
> >>> > +++-
> >>> > > >  1 file changed, 99 insertions(+), 22 deletions(-)
> >>> > > >
> >>> > > > --
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > Thank you, Philippe, for providing this series.
> >>> > > >
> >>> > > > However, in previous discussion on the patch you mention
> >>> above, I
> >>> > > > already expressed serious reservations on the approach
&

Re: [PATCH 0/7] hw/mips/malta: Rework to allow more than 2GB of RAM on 64-bit

[Aleksandar Markovic]

уто, 30. јун 2020. у 13:34 Philippe Mathieu-Daudé  је
написао/ла:
>
> On 6/30/20 1:17 PM, Aleksandar Markovic wrote:
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > <mailto:f4...@amsat.org>> је написао/ла:
> >
> > On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> > >
> > >
> > > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > <mailto:f4...@amsat.org>
> > > <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>> је написао/ла:
> > >
> > > On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
> > > mailto:f4...@amsat.org>
> >     <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>> wrote:
> > > >
> > > > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> > > > >
> > > > >
> > > > > уторак, 30. јун 2020., Philippe Mathieu-Daudé
> > mailto:f4...@amsat.org>
> > > <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>
> > > > > <mailto:f4...@amsat.org <mailto:f4...@amsat.org>
> > <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>>> је написао/ла:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Following Jiaxun Yang's patch and discussion:
> > > > > https://patchwork.kernel.org/patch/11416915/
> > <https://patchwork.kernel.org/patch/11416915/>
> > > <https://patchwork.kernel.org/patch/11416915/
> > <https://patchwork.kernel.org/patch/11416915/>>
> > > > > <https://patchwork.kernel.org/patch/11416915/
> > <https://patchwork.kernel.org/patch/11416915/>
> > > <https://patchwork.kernel.org/patch/11416915/
> > <https://patchwork.kernel.org/patch/11416915/>>>
> > > > >
> > > > > - Rename the current machine as 'malta-virt' (keeping
> > > 'malta' aliased)
> > > > >   Suggestions for better names are welcome, maybe
> > > 'malta-unreal' or
> > > > >   'malta-unleashed' instead?
> > > > > - Add 'malta-phys' which respects hardware
> > restrictions (on
> > > RAM so far)
> > > > > - Unleash 'malta-virt' to allow more than 2GB on 64-bit
> > > > >
> > > > > Philippe Mathieu-Daudé (7):
> > > > >   hw/mips/malta: Trivial code movement
> > > > >   hw/mips/malta: Register the machine as a TypeInfo
> > > > >   hw/mips/malta: Rename 'malta' machine as 'malta-virt'
> > > > >   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> > > > >   hw/mips/malta: Introduce the 'malta-phys' machine
> > > > >   hw/mips/malta: Verify malta-phys machine uses
> > correct DIMM
> > > sizes
> > > > >   hw/mips/malta: Allow more than 2GB on 64-bit malta-virt
> > > > >
> > > > >  hw/mips/malta.c | 121
> > > +++-
> > > > >  1 file changed, 99 insertions(+), 22 deletions(-)
> > > > >
> > > > > --
> > > > >
> > > > >
> > > > >
> > > > > Thank you, Philippe, for providing this series.
> > > > >
> > > > > However, in previous discussion on the patch you mention
> > above, I
> > > > > already expressed serious reservations on the approach
> > taken in that
> > > > > patch. These reservations stay today too.
> > > > >
> > > > > There is nothing qualitatively different between the original
> > > patch and
> > > > > this series. Naming and related stuff are just cosmetic
> > issues.
> > > >
> > > > OK, what about considering all patches except the last one?
> > > > So we can run firmware on a real Malta board, not the QEMU
> > > > imaginary one (in the discussion you said QEMU should respect
> > > > real hardware, which I agree).
> > > 

Re: [PATCH 0/7] hw/mips/malta: Rework to allow more than 2GB of RAM on 64-bit

[Aleksandar Markovic]

уторак, 30. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> On 6/30/20 1:01 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > <mailto:f4...@amsat.org>> је написао/ла:
> >
> > On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé
> > mailto:f4...@amsat.org>> wrote:
> > >
> > > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> > > >
> > > >
> > > > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > <mailto:f4...@amsat.org>
> > > > <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>> је
> написао/ла:
> > > >
> > > > Hi,
> > > >
> > > > Following Jiaxun Yang's patch and discussion:
> > > > https://patchwork.kernel.org/patch/11416915/
> > <https://patchwork.kernel.org/patch/11416915/>
> > > > <https://patchwork.kernel.org/patch/11416915/
> > <https://patchwork.kernel.org/patch/11416915/>>
> > > >
> > > > - Rename the current machine as 'malta-virt' (keeping
> > 'malta' aliased)
> > > >   Suggestions for better names are welcome, maybe
> > 'malta-unreal' or
> > > >   'malta-unleashed' instead?
> > > > - Add 'malta-phys' which respects hardware restrictions (on
> > RAM so far)
> > > > - Unleash 'malta-virt' to allow more than 2GB on 64-bit
> > > >
> > > > Philippe Mathieu-Daudé (7):
> > > >   hw/mips/malta: Trivial code movement
> > > >   hw/mips/malta: Register the machine as a TypeInfo
> > > >   hw/mips/malta: Rename 'malta' machine as 'malta-virt'
> > > >   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> > > >   hw/mips/malta: Introduce the 'malta-phys' machine
> > > >   hw/mips/malta: Verify malta-phys machine uses correct DIMM
> > sizes
> > > >   hw/mips/malta: Allow more than 2GB on 64-bit malta-virt
> > > >
> > > >  hw/mips/malta.c | 121
> > +++-
> > > >  1 file changed, 99 insertions(+), 22 deletions(-)
> > > >
> > > > --
> > > >
> > > >
> > > >
> > > > Thank you, Philippe, for providing this series.
> > > >
> > > > However, in previous discussion on the patch you mention above, I
> > > > already expressed serious reservations on the approach taken in
> that
> > > > patch. These reservations stay today too.
> > > >
> > > > There is nothing qualitatively different between the original
> > patch and
> > > > this series. Naming and related stuff are just cosmetic issues.
> > >
> > > OK, what about considering all patches except the last one?
> > > So we can run firmware on a real Malta board, not the QEMU
> > > imaginary one (in the discussion you said QEMU should respect
> > > real hardware, which I agree).
> > >
> > > >
> > > > The good thing about this series is that one can apply it
> > dowstream, if
> > > > one finds it useful. However, it is not suitable for upstreaming
> >
> > IOW, what is missing to have this series (except the last patch)
> > accepted upstream?
> >
> >
> > It is not what is missing, but was already is in the series that makes
> > it not suitable for upstreaming. The very concept of the series is
> > problematic.
>
> What is the series is not suitable for upstream? Can you point to
> patch and code please? How would you conceptually resolve the
> problem?
>
>
The answer is already in the original thread on the original patch.

The problem is artificialy imposed:

One needs a feature not present in the physical system. The solution is not
in creating "virtual" upgrade - this violates the basic foundation if QEMU.

If the feature is missing, the optimal solution would be emulating the
physical solution that has that feature.

In some rare cases (that should be avoided as mush as possible), and for
really good reasons, we can create an emulation of some imagined hardware
that was never designed let alone built - there are a couple of examples in
other targets.

But extending the emulation of existing physical system with non-existing
features is not acceptable.

Hopefuly everything is clear now to you. :)

Regards,
Aleksandar



> >
> > Regards,
> > Aleksandar
> >
> >
> >
> >
> >
> >
> >
> > > >
> > > > Regards,
> > > > Aleksandar
> > > >
> > > >
> > > >
> > > > 2.21.3
> > > >
> >
>

Re: [PATCH 0/7] hw/mips/malta: Rework to allow more than 2GB of RAM on 64-bit

[Aleksandar Markovic]

уторак, 30. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> On 6/30/20 12:54 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > <mailto:f4...@amsat.org>> је написао/ла:
> >
> > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> > >
> > >
> > > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > <mailto:f4...@amsat.org>
> > > <mailto:f4...@amsat.org <mailto:f4...@amsat.org>>> је написао/ла:
> > >
> > > Hi,
> > >
> > > Following Jiaxun Yang's patch and discussion:
> > > https://patchwork.kernel.org/patch/11416915/
> > <https://patchwork.kernel.org/patch/11416915/>
> > > <https://patchwork.kernel.org/patch/11416915/
> > <https://patchwork.kernel.org/patch/11416915/>>
> > >
> > > - Rename the current machine as 'malta-virt' (keeping 'malta'
> > aliased)
> > >   Suggestions for better names are welcome, maybe
> > 'malta-unreal' or
> > >   'malta-unleashed' instead?
> > > - Add 'malta-phys' which respects hardware restrictions (on
> > RAM so far)
> > > - Unleash 'malta-virt' to allow more than 2GB on 64-bit
> > >
> > > Philippe Mathieu-Daudé (7):
> > >   hw/mips/malta: Trivial code movement
> > >   hw/mips/malta: Register the machine as a TypeInfo
> > >   hw/mips/malta: Rename 'malta' machine as 'malta-virt'
> > >   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> > >   hw/mips/malta: Introduce the 'malta-phys' machine
> > >   hw/mips/malta: Verify malta-phys machine uses correct DIMM
> sizes
> > >   hw/mips/malta: Allow more than 2GB on 64-bit malta-virt
> > >
> > >  hw/mips/malta.c | 121
> > +++-
> > >  1 file changed, 99 insertions(+), 22 deletions(-)
> > >
> > > --
> > >
> > >
> > >
> > > Thank you, Philippe, for providing this series.
> > >
> > > However, in previous discussion on the patch you mention above, I
> > > already expressed serious reservations on the approach taken in
> that
> > > patch. These reservations stay today too.
> > >
> > > There is nothing qualitatively different between the original
> > patch and
> > > this series. Naming and related stuff are just cosmetic issues.
> >
> > OK, what about considering all patches except the last one?
> > So we can run firmware on a real Malta board, not the QEMU
> > imaginary one (in the discussion you said QEMU should respect
> > real hardware, which I agree).
> >
> >
> > Redo the series, and we can discuss, of course.
>
> I can resend without the last patch but I don't see the point,
> why not discuss first?
>
> QEMU should do its best to model a real Malta board. I don't
> want to break the current users for the existing 'malta' machine.
> How do you want me to name the real malta machine?
>
>
You now self-convinced yourself that only the last patch is wrong. I
repeat, the concept of the series is not ok, and, if you will, all patches
in the series are not good.

Regards,
Aleksandar


> >
> >
> > >
> > > The good thing about this series is that one can apply it
> > dowstream, if
> > > one finds it useful. However, it is not suitable for upstreaming
> > >
> > > Regards,
> > > Aleksandar
> > >
> > >
> > >
> > > 2.21.3
> > >
> >
>

Re: [PATCH 0/7] hw/mips/malta: Rework to allow more than 2GB of RAM on 64-bit

[Aleksandar Markovic]

уторак, 30. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> On Tue, Jun 30, 2020 at 12:52 PM Philippe Mathieu-Daudé 
> wrote:
> >
> > On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> > >
> > >
> > > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > > <mailto:f4...@amsat.org>> је написао/ла:
> > >
> > > Hi,
> > >
> > > Following Jiaxun Yang's patch and discussion:
> > > https://patchwork.kernel.org/patch/11416915/
> > > <https://patchwork.kernel.org/patch/11416915/>
> > >
> > > - Rename the current machine as 'malta-virt' (keeping 'malta'
> aliased)
> > >   Suggestions for better names are welcome, maybe 'malta-unreal' or
> > >   'malta-unleashed' instead?
> > > - Add 'malta-phys' which respects hardware restrictions (on RAM so
> far)
> > > - Unleash 'malta-virt' to allow more than 2GB on 64-bit
> > >
> > > Philippe Mathieu-Daudé (7):
> > >   hw/mips/malta: Trivial code movement
> > >   hw/mips/malta: Register the machine as a TypeInfo
> > >   hw/mips/malta: Rename 'malta' machine as 'malta-virt'
> > >   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> > >   hw/mips/malta: Introduce the 'malta-phys' machine
> > >   hw/mips/malta: Verify malta-phys machine uses correct DIMM sizes
> > >   hw/mips/malta: Allow more than 2GB on 64-bit malta-virt
> > >
> > >  hw/mips/malta.c | 121 ++
> +-
> > >  1 file changed, 99 insertions(+), 22 deletions(-)
> > >
> > > --
> > >
> > >
> > >
> > > Thank you, Philippe, for providing this series.
> > >
> > > However, in previous discussion on the patch you mention above, I
> > > already expressed serious reservations on the approach taken in that
> > > patch. These reservations stay today too.
> > >
> > > There is nothing qualitatively different between the original patch and
> > > this series. Naming and related stuff are just cosmetic issues.
> >
> > OK, what about considering all patches except the last one?
> > So we can run firmware on a real Malta board, not the QEMU
> > imaginary one (in the discussion you said QEMU should respect
> > real hardware, which I agree).
> >
> > >
> > > The good thing about this series is that one can apply it dowstream, if
> > > one finds it useful. However, it is not suitable for upstreaming
>
> IOW, what is missing to have this series (except the last patch)
> accepted upstream?
>
>
It is not what is missing, but was already is in the series that makes it
not suitable for upstreaming. The very concept of the series is problematic.

Regards,
Aleksandar







> > >
> > > Regards,
> > > Aleksandar
> > >
> > >
> > >
> > > 2.21.3
> > >
>

Re: [PATCH 0/7] hw/mips/malta: Rework to allow more than 2GB of RAM on 64-bit

[Aleksandar Markovic]

уторак, 30. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> On 6/30/20 12:48 PM, Aleksandar Markovic wrote:
> >
> >
> > уторак, 30. јун 2020., Philippe Mathieu-Daudé  > <mailto:f4...@amsat.org>> је написао/ла:
> >
> > Hi,
> >
> > Following Jiaxun Yang's patch and discussion:
> > https://patchwork.kernel.org/patch/11416915/
> > <https://patchwork.kernel.org/patch/11416915/>
> >
> > - Rename the current machine as 'malta-virt' (keeping 'malta'
> aliased)
> >   Suggestions for better names are welcome, maybe 'malta-unreal' or
> >   'malta-unleashed' instead?
> > - Add 'malta-phys' which respects hardware restrictions (on RAM so
> far)
> > - Unleash 'malta-virt' to allow more than 2GB on 64-bit
> >
> > Philippe Mathieu-Daudé (7):
> >   hw/mips/malta: Trivial code movement
> >   hw/mips/malta: Register the machine as a TypeInfo
> >   hw/mips/malta: Rename 'malta' machine as 'malta-virt'
> >   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
> >   hw/mips/malta: Introduce the 'malta-phys' machine
> >   hw/mips/malta: Verify malta-phys machine uses correct DIMM sizes
> >   hw/mips/malta: Allow more than 2GB on 64-bit malta-virt
> >
> >  hw/mips/malta.c | 121 ++
> +-
> >  1 file changed, 99 insertions(+), 22 deletions(-)
> >
> > --
> >
> >
> >
> > Thank you, Philippe, for providing this series.
> >
> > However, in previous discussion on the patch you mention above, I
> > already expressed serious reservations on the approach taken in that
> > patch. These reservations stay today too.
> >
> > There is nothing qualitatively different between the original patch and
> > this series. Naming and related stuff are just cosmetic issues.
>
> OK, what about considering all patches except the last one?
> So we can run firmware on a real Malta board, not the QEMU
> imaginary one (in the discussion you said QEMU should respect
> real hardware, which I agree).
>
>
Redo the series, and we can discuss, of course.


> >
> > The good thing about this series is that one can apply it dowstream, if
> > one finds it useful. However, it is not suitable for upstreaming
> >
> > Regards,
> > Aleksandar
> >
> >
> >
> > 2.21.3
> >
>

Re: [PATCH 0/7] hw/mips/malta: Rework to allow more than 2GB of RAM on 64-bit

[Aleksandar Markovic]

уторак, 30. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> Hi,
>
> Following Jiaxun Yang's patch and discussion:
> https://patchwork.kernel.org/patch/11416915/
>
> - Rename the current machine as 'malta-virt' (keeping 'malta' aliased)
>   Suggestions for better names are welcome, maybe 'malta-unreal' or
>   'malta-unleashed' instead?
> - Add 'malta-phys' which respects hardware restrictions (on RAM so far)
> - Unleash 'malta-virt' to allow more than 2GB on 64-bit
>
> Philippe Mathieu-Daudé (7):
>   hw/mips/malta: Trivial code movement
>   hw/mips/malta: Register the machine as a TypeInfo
>   hw/mips/malta: Rename 'malta' machine as 'malta-virt'
>   hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
>   hw/mips/malta: Introduce the 'malta-phys' machine
>   hw/mips/malta: Verify malta-phys machine uses correct DIMM sizes
>   hw/mips/malta: Allow more than 2GB on 64-bit malta-virt
>
>  hw/mips/malta.c | 121 +++-
>  1 file changed, 99 insertions(+), 22 deletions(-)
>
> --



Thank you, Philippe, for providing this series.

However, in previous discussion on the patch you mention above, I already
expressed serious reservations on the approach taken in that patch. These
reservations stay today too.

There is nothing qualitatively different between the original patch and
this series. Naming and related stuff are just cosmetic issues.

The good thing about this series is that one can apply it dowstream, if one
finds it useful. However, it is not suitable for upstreaming

Regards,
Aleksandar



> 2.21.3
>
>

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#2] Dissecting QEMU Into Three Main Parts

[Aleksandar Markovic]

> As far as I know, this is how Ahmed test bed is setup:
>
> 1) Fresh installation on Ubuntu 18.04 on an Inter 64-bit host.
> 2) Install QEMU build prerequisite packages.
> 3) Install perf (this step is not necessary for Report 2, but it is
> for Report 1).
> 4) Install vallgrind.
> 5) Install 16 gcc cross-compilers. (which, together with native
> comipler, will sum up to the 17 possible QEMU targets)
>

The following commands install cross-compilers needed for creating
table in the second part or Ahmed's Report 2:

sudo apt-get install g++
sudo apt-get install g++-aarch64-linux-gnu
sudo apt-get install g++-alpha-linux-gnu
sudo apt-get install g++-arm-linux-gnueabi
sudo apt-get install g++-hppa-linux-gnu
sudo apt-get install g++-m68k-linux-gnu
sudo apt-get install g++-mips-linux-gnu
sudo apt-get install g++-mips64-linux-gnuabi64
sudo apt-get install g++-mips64el-linux-gnuabi64
sudo apt-get install g++-mipsel-linux-gnu
sudo apt-get install g++-powerpc-linux-gnu
sudo apt-get install g++-powerpc64-linux-gnu
sudo apt-get install g++-powerpc64le-linux-gnu
sudo apt-get install g++-riscv64-linux-gnu
sudo apt-get install g++-s390x-linux-gnu
sudo apt-get install g++-sh4-linux-gnu
sudo apt-get install g++-sparc64-linux-gnu

Ahmed, I think this should be in an Appendix section of Report 2.

Sincerely,
Aleksandar

> That is all fine if Mr. Yongang is able to do the above, or if he
> already have similar system.
>
> I am fairly convinced that the setup for any Debian-based Linux
> distribution will be almost identical as described above
>
> However, let's say Mr.Yongang system is Suse-bases distribution (SUSE
> Linux Enterprise, openSUSE Leap, openSUSE Tumbleweed, Gecko). He could
> do steps 2), 3), 4) in a fairly similar manner. But, step 5) will be
> difficult. I know that support for cross-compilers is relatively poor
> for Suse-based distributions. I think Mr. Yongang could run experiment
> from the second part of Report 2 only for 5 or 6 targets, rather than
> 17 as you did.
>
> The bottom line for Report 2:
>
> I think there should be an "Appendix" note on installing
> cross-compilers. And some general note on your test bed, as well as
> some guideline for all people like Mr. Yongang who wish to repro the
> results on their own systems.
>
> Sincerely,
> Aleksandar
>
>
>
>
>
>
>
>
>
> 2)
>
>
> > Best Regards,
> > Ahmed Karaman

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#2] Dissecting QEMU Into Three Main Parts

[Aleksandar Markovic]

уто, 30. јун 2020. у 06:34 Lukáš Doktor  је написао/ла:
>
> Dne 29. 06. 20 v 12:25 Ahmed Karaman napsal(a):
> > Hi,
> >
> > The second report of the TCG Continuous Benchmarking series builds
> > upon the QEMU performance metrics calculated in the previous report.
> > This report presents a method to dissect the number of instructions
> > executed by a QEMU invocation into three main phases:
> > - Code Generation
> > - JIT Execution
> > - Helpers Execution
> > It devises a Python script that automates this process.
> >
> > After that, the report presents an experiment for comparing the
> > output of running the script on 17 different targets. Many conclusions
> > can be drawn from the results and two of them are discussed in the
> > analysis section.
> >
> > Report link:
> > https://ahmedkrmn.github.io/TCG-Continuous-Benchmarking/Dissecting-QEMU-Into-Three-Main-Parts/
> >
> > Previous reports:
> > Report 1 - Measuring Basic Performance Metrics of QEMU:
> > https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg06692.html
> >
> > Best regards,
> > Ahmed Karaman
>
> Hello Ahmed,
>
> very nice reading, both reports so far. One thing that could be better 
> displayed is the system you used this to generate. This would come handy 
> especially later when you move from examples to actual reports. I think it'd 
> make sense to add a section with a clear definition of the machine as well as 
> the operation system, qemu version and eventually other deps (like compiler, 
> flags, ...). For this report something like:
>
> architecture: x86_64
> cpu_codename: Kaby Lake
> cpu: i7-8650U
> ram: 32GB DDR4
> os: Fedora 32
> qemu: 470dd165d152ff7ceac61c7b71c2b89220b3aad7
> compiler: gcc-10.1.1-1.fc32.x86_64
> flags: 
> --target-list="x86_64-softmmu,ppc64-softmmu,aarch64-softmmu,s390x-softmmu,riscv64-softmmu"
>  --disable-werror --disable-sparse --enable-sdl --enable-kvm  
> --enable-vhost-net --enable-vhost-net --enable-attr  --enable-kvm  
> --enable-fdt   --enable-vnc --enable-seccomp 
> --block-drv-rw-whitelist="vmdk,null-aio,quorum,null-co,blkverify,file,nbd,raw,blkdebug,host_device,qed,nbd,iscsi,gluster,rbd,qcow2,throttle,copy-on-read"
>  --python=/usr/bin/python3 --enable-linux-io-uring
>
> would do. Maybe it'd be even a good idea to create a script to report this 
> basic set of information and add it after each of the perf scripts so people 
> don't forget to double-check the conditions, but others might disagree so 
> take this only as a suggestion.
>

I just want to follow up on this observation here, and not related to
Ahmed's report at all.

We often receive bug reports of the following style: "I have Debian
10.2 system and mips emulation misbehaves". As you may imagine, I
assign the bug to myself, install Debian 10.2 system on my
experimental box, and mips emulation works like charm.
 Obviously, I need more info on
the submitter's system.

After all these years, we don't have (or at least I don't know about
it) a script that we could give the submitter, that picks up various
aspects of his system. This script, since it is not "for presentation"
could be even far more aggressive in picking ups system information
that what Lukas mentioned above. It could collect the output of
various relevant commands, and yip it in a single file. We should have
"get_system_info.py" in our scripts directory!

Sincerely,
Aleksandar


> Regards,
> Lukáš
>
> PS: Automated cpu codenames, hosts OSes and such could be tricky, but one can 
> use other libraries or just best-effort-approach with fallback to "unknown" 
> to let people filling it manually or adding their branch to your script.
>
> Regards,
> Lukáš
>

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#2] Dissecting QEMU Into Three Main Parts

[Aleksandar Markovic]

уто, 30. јун 2020. у 09:19 Ahmed Karaman
 је написао/ла:
>
> On Tue, Jun 30, 2020 at 6:34 AM Lukáš Doktor  wrote:
> >
> > Dne 29. 06. 20 v 12:25 Ahmed Karaman napsal(a):
> > > Hi,
> > >
> > > The second report of the TCG Continuous Benchmarking series builds
> > > upon the QEMU performance metrics calculated in the previous report.
> > > This report presents a method to dissect the number of instructions
> > > executed by a QEMU invocation into three main phases:
> > > - Code Generation
> > > - JIT Execution
> > > - Helpers Execution
> > > It devises a Python script that automates this process.
> > >
> > > After that, the report presents an experiment for comparing the
> > > output of running the script on 17 different targets. Many conclusions
> > > can be drawn from the results and two of them are discussed in the
> > > analysis section.
> > >
> > > Report link:
> > > https://ahmedkrmn.github.io/TCG-Continuous-Benchmarking/Dissecting-QEMU-Into-Three-Main-Parts/
> > >
> > > Previous reports:
> > > Report 1 - Measuring Basic Performance Metrics of QEMU:
> > > https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg06692.html
> > >
> > > Best regards,
> > > Ahmed Karaman
> >
> > Hello Ahmed,
> >
> > very nice reading, both reports so far. One thing that could be better 
> > displayed is the system you used this to generate. This would come handy 
> > especially later when you move from examples to actual reports. I think 
> > it'd make sense to add a section with a clear definition of the machine as 
> > well as the operation system, qemu version and eventually other deps (like 
> > compiler, flags, ...). For this report something like:
> >
> > architecture: x86_64
> > cpu_codename: Kaby Lake
> > cpu: i7-8650U
> > ram: 32GB DDR4
> > os: Fedora 32
> > qemu: 470dd165d152ff7ceac61c7b71c2b89220b3aad7
> > compiler: gcc-10.1.1-1.fc32.x86_64
> > flags: 
> > --target-list="x86_64-softmmu,ppc64-softmmu,aarch64-softmmu,s390x-softmmu,riscv64-softmmu"
> >  --disable-werror --disable-sparse --enable-sdl --enable-kvm  
> > --enable-vhost-net --enable-vhost-net --enable-attr  --enable-kvm  
> > --enable-fdt   --enable-vnc --enable-seccomp 
> > --block-drv-rw-whitelist="vmdk,null-aio,quorum,null-co,blkverify,file,nbd,raw,blkdebug,host_device,qed,nbd,iscsi,gluster,rbd,qcow2,throttle,copy-on-read"
> >  --python=/usr/bin/python3 --enable-linux-io-uring
> >
> > would do. Maybe it'd be even a good idea to create a script to report this 
> > basic set of information and add it after each of the perf scripts so 
> > people don't forget to double-check the conditions, but others might 
> > disagree so take this only as a suggestion.
> >
> > Regards,
> > Lukáš
> >
> > PS: Automated cpu codenames, hosts OSes and such could be tricky, but one 
> > can use other libraries or just best-effort-approach with fallback to 
> > "unknown" to let people filling it manually or adding their branch to your 
> > script.
> >
> > Regards,
> > Lukáš
> >
> Thanks Mr. Lukáš, I'm really glad you found both reports interesting.
>
> Both reports are based on QEMU version 5.0.0, this wasn't mentioned in
> the reports so thanks for the reminder. I'll add a short note about
> that.
>
> The used QEMU build is a very basic GCC build (created by just running
> ../configure in the build directory without any flags).
>
> Regarding the detailed machine information (CPU, RAM ... etc), The two
> reports introduce some concepts and methodologies that will produce
> consistent results on whichever machine they are executed on. So I
> think it's unnecessary to mention the detailed system information used
> in the reports for now.
>

Ahmed, I don't entirely agree with you on this topic.

I think you treated Mr. Lukas comments in an overly lax way.

Yes, the results will be stable (within a small fraction of a percent)
on a particular given system (which is proved in "Stability
Experiment" section of Report 1). That is great! Although it sounds
elementary, this is not easy to achieve, so I am glad you did it.

However, we know that the results for hosts of different architectures
will be different - we expect that.

32-bit Intel host will also most likely produce significantly
different results than 64-bit Intel hosts. By the way, 64-bit targets
in QEMU linux-user mode are not supported on 32-bit hosts (although
nothing stops the user to start corresponding instances of QEMU on a
32-bit host, but the results are unpredictable.

Let's focus now on Intel 64-bit hosts only. Richard, can you perhaps
enlighten us on whether QEMU (from the point of view of TCG target)
behaves differently on different Intel 64-bit hosts, and to what
degree?

I currently work remotely, but once I am be physically at my office I
will have a variety of hosts at the company, and would be happy to do
the comparison between them, wrt what you presented in Report 2.

In conclusion, I think a basic description of your test bed is missing
in your reports. And, for final reports (which we call 

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#2] Dissecting QEMU Into Three Main Parts

[Aleksandar Markovic]

уто, 30. јун 2020. у 09:30 Ahmed Karaman
 је написао/ла:
>
> On Tue, Jun 30, 2020 at 7:59 AM 罗勇刚(Yonggang Luo)  
> wrote:
> >
> > Wonderful work, May I reproduce the work on my local machine?
> >
> > On Mon, Jun 29, 2020 at 6:26 PM Ahmed Karaman 
> >  wrote:
> >>
> >> Hi,
> >>
> >> The second report of the TCG Continuous Benchmarking series builds
> >> upon the QEMU performance metrics calculated in the previous report.
> >> This report presents a method to dissect the number of instructions
> >> executed by a QEMU invocation into three main phases:
> >> - Code Generation
> >> - JIT Execution
> >> - Helpers Execution
> >> It devises a Python script that automates this process.
> >>
> >> After that, the report presents an experiment for comparing the
> >> output of running the script on 17 different targets. Many conclusions
> >> can be drawn from the results and two of them are discussed in the
> >> analysis section.
> >>
> >> Report link:
> >> https://ahmedkrmn.github.io/TCG-Continuous-Benchmarking/Dissecting-QEMU-Into-Three-Main-Parts/
> >>
> >> Previous reports:
> >> Report 1 - Measuring Basic Performance Metrics of QEMU:
> >> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg06692.html
> >>
> >> Best regards,
> >> Ahmed Karaman
> >
> >
> >
> > --
> >  此致
> > 礼
> > 罗勇刚
> > Yours
> > sincerely,
> > Yonggang Luo
>
> Thanks Mr. Yonggang. Yes of course, go ahead.
> Please let me know if you have any further questions.
>

Yes, Ahmed, you said Mr. Yonggang can go ahaed - but you didn't say how. :)

As far as I know, this is how Ahmed test bed is setup:

1) Fresh installation on Ubuntu 18.04 on an Inter 64-bit host.
2) Install QEMU build prerequisite packages.
3) Install perf (this step is not necessary for Report 2, but it is
for Report 1).
4) Install vallgrind.
5) Install 16 gcc cross-compilers. (which, together with native
comipler, will sum up to the 17 possible QEMU targets)

That is all fine if Mr. Yongang is able to do the above, or if he
already have similar system.

I am fairly convinced that the setup for any Debian-based Linux
distribution will be almost identical as described above

However, let's say Mr.Yongang system is Suse-bases distribution (SUSE
Linux Enterprise, openSUSE Leap, openSUSE Tumbleweed, Gecko). He could
do steps 2), 3), 4) in a fairly similar manner. But, step 5) will be
difficult. I know that support for cross-compilers is relatively poor
for Suse-based distributions. I think Mr. Yongang could run experiment
from the second part of Report 2 only for 5 or 6 targets, rather than
17 as you did.

The bottom line for Report 2:

I think there should be an "Appendix" note on installing
cross-compilers. And some general note on your test bed, as well as
some guideline for all people like Mr. Yongang who wish to repro the
results on their own systems.

Sincerely,
Aleksandar









2)


> Best Regards,
> Ahmed Karaman

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#2] Dissecting QEMU Into Three Main Parts

[Aleksandar Markovic]

> I should have also pointed out in your
> by only having one benchmark you are going to miss out on the envelope
> of use cases.
>

Alex, thank you for all your comments, and other perspectives that you
always bring to Ahmed's and everyones else's attention. I always imagine
you as a "four-dimensional" engineer for the your unabashed presentation of
out-of-the-box ideas. I actually truly like this, quite often, inspiring
style.

However, it seems to me that this last paragraph is a little unjust
critique, and as if doesn't come from you.

The report is not about a benchmark, it is about a script that does
something. Ahmed never said "we are going to benchmark" anything. The
program in the report is just an example used for illustration.

And, now you say: it is not good for benchmarking. Well, no example is good
for benchmarking, and, again, the report is not about benchmarking. Why do
you mwntion benchmarking at all than? And what is Ahmed supposed to do? To
flood the report with dozens of programs and dozens of tables, thousands of
numbers, find some average - just to illustrate the script?

The variety of test programs will be the subject of future reports.

Otherwise, all intriguing and useful proposals from your side, and many
thanks for them!!

Yours,
Aleksandar

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#2] Dissecting QEMU Into Three Main Parts

[Aleksandar Markovic]

понедељак, 29. јун 2020., Ahmed Karaman  је
написао/ла:

> Hi,
>
> The second report of the TCG Continuous Benchmarking series builds
> upon the QEMU performance metrics calculated in the previous report.
> This report presents a method to dissect the number of instructions
> executed by a QEMU invocation into three main phases:
> - Code Generation
> - JIT Execution
> - Helpers Execution
> It devises a Python script that automates this process.
>
> After that, the report presents an experiment for comparing the
> output of running the script on 17 different targets. Many conclusions
> can be drawn from the results and two of them are discussed in the
> analysis section.
>
> Report link:
> https://ahmedkrmn.github.io/TCG-Continuous-Benchmarking/
> Dissecting-QEMU-Into-Three-Main-Parts/
>
> Previous reports:
> Report 1 - Measuring Basic Performance Metrics of QEMU:
> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg06692.html
>
>
My sincere congratulations on the Report 2!!

And, on top of that, this is an excellent idea to list previous reports, as
you did in the paragraph above.

Keep reports coming!!

Aleksandar



> Best regards,
> Ahmed Karaman
>

Re: [PULL 6/6] MAINTAINERS: Add 'Performance Tools and Tests' subsection

[Aleksandar Markovic]

понедељак, 29. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> On 6/27/20 9:51 PM, Aleksandar Markovic wrote:
> > This commit creates a new 'Miscellaneous' section which hosts a new
> > 'Performance Tools and Tests' subsection. This subsection will contain
> > the the performance scripts and benchmarks written as a part of the
> > 'TCG Continuous Benchmarking' project. Also, it will be a placeholder
> > for follow-ups to this project, if any.
> >
> > Signed-off-by: Ahmed Karaman 
> > Reviewed-by: Alex Bennée 
> > Reviewed-by: Aleksandar Markovic 
> > Signed-off-by: Aleksandar Markovic 
> > Message-Id: <20200626164546.22102-4-ahmedkhaledkara...@gmail.com>
> > ---
> >  MAINTAINERS | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index fe925ea..dec252f 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1096,11 +1096,10 @@ F: hw/isa/vt82c686.c
> >  F: hw/pci-host/bonito.c
> >  F: include/hw/isa/vt82c686.h
> >
> > -Loongson-3 Virtual Platform
> > +Loongson-3 virtual platforms
> >  M: Huacai Chen 
> >  R: Jiaxun Yang 
> >  S: Maintained
> > -F: hw/mips/loongson3_virt.c
>
> Ah, now I see, here you unlist the uncommited file.
>
>
This file/machine, for multiple reasons, will not be accepted in 5.1. The
end user will not be able to see, let alone use the machine in question in
5.1. This is on purpose.

This will give enough development time to Huacai to implement missing bits
and pieces, and to possibly improve the whole idea during 5.2 development
cycle.

Even though the support that Huacai introduced in 5.1 is, for many reasons,
not completed, and even though Huacai and I had at times opposing views and
fierce discussions and disagreements - I salute and support his work, and
consider it, by far, the best and the most important contribution to QEMU
for MIPS in years.



> It might be easier to manage sending 2 different pull requests,
> on for MIPS and one for the performance tools.
>
> >  F: hw/intc/loongson_liointc.c
> >
> >  Boston
> > @@ -3026,3 +3025,10 @@ M: Peter Maydell 
> >  S: Maintained
> >  F: docs/conf.py
> >  F: docs/*/conf.py
> > +
> > +Miscellaneous
> > +-
> > +Performance Tools and Tests
> > +M: Ahmed Karaman 
>
> Aleksandar, don't you want to be listed here with Ahmed?
>
>
Of course not. The project is student's. The mentor just helps and leads
the student. The fruits of the project belong to the community and to the
student - and not to the mentor.

If you were the mentor, my impression is that you would leave your name in
MAINTAINERS whenever you see the slightest opportunity (I remember an
occasion where you were saying "I worked six hours on this" and then
proposing yourself as the maitainer for a particular segment (??)). I don't
have such approach, and I oppose your approach, and I appeal to you to
control your apetite for maintainership.

Regards,
Aleksandar



> > +S: Maintained
> > +F: scripts/performance/
> >
>
>

Re: [PULL 3/6] MAINTAINERS: Add Loongson-3 maintainer and reviewer

[Aleksandar Markovic]

понедељак, 29. јун 2020., Philippe Mathieu-Daudé  је
написао/ла:

> On 6/27/20 9:51 PM, Aleksandar Markovic wrote:
> > From: Huacai Chen 
> >
> > Add myself as the maintainer for Loongson-3 virtual platforms, and
> > also add Jiaxun Yang as the reviewer.
> >
> > Signed-off-by: Huacai Chen 
> > Co-developed-by: Jiaxun Yang 
> > Reviewed-by: Aleksandar Markovic 
> > Signed-off-by: Aleksandar Markovic 
> > Message-Id: <1592995531-32600-5-git-send-email-che...@lemote.com>
> > ---
> >  MAINTAINERS | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 1b40446..fe925ea 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1096,6 +1096,13 @@ F: hw/isa/vt82c686.c
> >  F: hw/pci-host/bonito.c
> >  F: include/hw/isa/vt82c686.h
> >
> > +Loongson-3 Virtual Platform
> > +M: Huacai Chen 
> > +R: Jiaxun Yang 
> > +S: Maintained
> > +F: hw/mips/loongson3_virt.c
>
> This file has not been commited, is this pull request incomplete?
>
> > +F: hw/intc/loongson_liointc.c
>
>
This line, in this patch, was my mistake. I did delete the line, but forgot
to do "git add MAINTAINERS". So, the deletion happened in the next patch
dealing with MAINTAINERS.

So, my bad. An honest mistake. I apoligize.

However, the final outcome of the pull request is 100% as desired, and as I
informed other in my responses to patches.  No need to do any follow ups.

How can we test this device?
>
>
Please read the commit message of patch 3/4 of Huacai's recent series v6.


> > +
> >  Boston
> >  M: Paul Burton 
> >  R: Aleksandar Rikalo 
> >
>
>

Re: [REPORT] [GSoC - TCG Continuous Benchmarking] [#1] Measuring Basic Performance Metrics of QEMU

[Aleksandar Markovic]

пон, 22. јун 2020. у 12:31 Ahmed Karaman
 је написао/ла:
>
> Greetings,
>
> Welcome to the TCG Continuous Benchmarking GSoC project!
> This is the first report in a series that will be posted here on the
> mailing list as part of the project.
>
> During the project, multiple Linux profiling tools will be used.
> These tools will help you profile your different QEMU execution
> scenarios, and locate performance bottlenecks as well as performance
> regression problems.
>
> To provide you with a better understanding of these tools, this report
> presents two of them - Perf and Callgrind.
> It starts with measuring the basic performance metrics when running
> a program using both tools, then it proceeds to calculating the top 25
> most executed functions in QEMU

Now, thinking longer about topN scripts, I think one really missing
thing is number of invocations (or calls, whatever term you prefer)
for any function in the list. This data must be possible to obtain
using callgrind_annotate (most likely by using --tree option). With
perf, i don't think this is possible, given that perf works based on
sampling.

You don't need to start working on it right now, or work on it at all
- this is more like a brainstorming suggestion from me. You can make
improvements and correction all the way towards the end of the
project, on Aug 31st.

At the end of the project, perhaps you can publish a "Master Project
Report" - a pdf that is basically a sum of all your reports produced
during the project. That would be a nice reading!

Regards,
Aleksandar

> To dissect the output of each of the two tools, a separate section
> for comparing the output results is presented which focuses on how
> these results apply to QEMU.
> Finally, a stability test is devised that compares how the output
> of the two tools differ with each subsequent invocation of QEMU.
>
> For easier accessibility, all reports will be hosted on a dedicated
> website:
> https://ahmedkrmn.github.io/TCG-Continuous-Benchmarking/
>
> Link to the first report:
> https://ahmedkrmn.github.io/TCG-Continuous-Benchmarking/Measuring-Basic-Performance-Metrics-of-QEMU/
>
> Best regards,
> Ahmed Karaman

[PULL 4/6] scripts/performance: Add topN_perf.py script

[Aleksandar Markovic]

From: Ahmed Karaman 

Syntax:
topN_perf.py [-h] [-n]   -- \
  [] \
  []

[-h] - Print the script arguments help message.
[-n] - Specify the number of top functions to print.
 - If this flag is not specified, the tool defaults to 25.

Example of usage:
topN_perf.py -n 20 -- qemu-arm coulomb_double-arm

Example Output:
 No.  Percentage  Name   Invoked by
  --  -  -
   1  16.25%  float64_mulqemu-x86_64
   2  12.01%  float64_subqemu-x86_64
   3  11.99%  float64_addqemu-x86_64
   4   5.69%  helper_mulsd   qemu-x86_64
   5   4.68%  helper_addsd   qemu-x86_64
   6   4.43%  helper_lookup_tb_ptr   qemu-x86_64
   7   4.28%  helper_subsd   qemu-x86_64
   8   2.71%  f64_compareqemu-x86_64
   9   2.71%  helper_ucomisd qemu-x86_64
  10   1.04%  helper_pand_xmmqemu-x86_64
  11   0.71%  float64_divqemu-x86_64
  12   0.63%  helper_pxor_xmmqemu-x86_64
  13   0.50%  0x7f7b7004ef95 [JIT] tid 491
  14   0.50%  0x7f7b70044e83 [JIT] tid 491
  15   0.36%  helper_por_xmm qemu-x86_64
  16   0.32%  helper_cc_compute_all  qemu-x86_64
  17   0.30%  0x7f7b700433f0 [JIT] tid 491
  18   0.30%  float64_compare_quiet  qemu-x86_64
  19   0.27%  soft_f64_addsubqemu-x86_64
  20   0.26%  round_to_int   qemu-x86_64

Signed-off-by: Ahmed Karaman 
Signed-off-by: Aleksandar Markovic 
Reviewed-by: Aleksandar Markovic 
Message-Id: <20200626164546.22102-2-ahmedkhaledkara...@gmail.com>
---
 scripts/performance/topN_perf.py | 149 +++
 1 file changed, 149 insertions(+)
 create mode 100755 scripts/performance/topN_perf.py

diff --git a/scripts/performance/topN_perf.py b/scripts/performance/topN_perf.py
new file mode 100755
index 000..07be195
--- /dev/null
+++ b/scripts/performance/topN_perf.py
@@ -0,0 +1,149 @@
+#!/usr/bin/env python3
+
+#  Print the top N most executed functions in QEMU using perf.
+#  Syntax:
+#  topN_perf.py [-h] [-n]   -- \
+#[] \
+#[]
+#
+#  [-h] - Print the script arguments help message.
+#  [-n] - Specify the number of top functions to print.
+#   - If this flag is not specified, the tool defaults to 25.
+#
+#  Example of usage:
+#  topN_perf.py -n 20 -- qemu-arm coulomb_double-arm
+#
+#  This file is a part of the project "TCG Continuous Benchmarking".
+#
+#  Copyright (C) 2020  Ahmed Karaman 
+#  Copyright (C) 2020  Aleksandar Markovic 
+#
+#  This program is free software: you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation, either version 2 of the License, or
+#  (at your option) any later version.
+#
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+#  GNU General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+import argparse
+import os
+import subprocess
+import sys
+
+
+# Parse the command line arguments
+parser = argparse.ArgumentParser(
+usage='topN_perf.py [-h] [-n]   -- '
+  ' [] '
+  ' []')
+
+parser.add_argument('-n', dest='top', type=int, default=25,
+help='Specify the number of top functions to print.')
+
+parser.add_argument('command', type=str, nargs='+', help=argparse.SUPPRESS)
+
+args = parser.parse_args()
+
+# Extract the needed variables from the args
+command = args.command
+top = args.top
+
+# Insure that perf is installed
+check_perf_presence = subprocess.run(["which", "perf"],
+ stdout=subprocess.DEVNULL)
+if check_perf_presence.returncode:
+sys.exit("Please install perf before running the script!")
+
+# Insure user has previllage to run perf
+check_perf_executability = subprocess.run(["perf", "stat", "ls", "/"],
+  stdout=subprocess.DEVNULL,
+  stderr=subprocess.DEVNULL)
+if check_perf_executability.returncode:
+sys.exit(
+"""
+Error:
+You may not have permission to collect stats.
+
+Consider tweaking /proc/sys/kernel/perf_event_paranoid,
+which controls use of the performance events system by
+unprivileged users (without CAP_SYS_ADMIN).
+
+  -1: Allow use of (almost) all events by all users
+  Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK
+   0: Disall

[PULL 3/6] MAINTAINERS: Add Loongson-3 maintainer and reviewer

[Aleksandar Markovic]

From: Huacai Chen 

Add myself as the maintainer for Loongson-3 virtual platforms, and
also add Jiaxun Yang as the reviewer.

Signed-off-by: Huacai Chen 
Co-developed-by: Jiaxun Yang 
Reviewed-by: Aleksandar Markovic 
Signed-off-by: Aleksandar Markovic 
Message-Id: <1592995531-32600-5-git-send-email-che...@lemote.com>
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1b40446..fe925ea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1096,6 +1096,13 @@ F: hw/isa/vt82c686.c
 F: hw/pci-host/bonito.c
 F: include/hw/isa/vt82c686.h
 
+Loongson-3 Virtual Platform
+M: Huacai Chen 
+R: Jiaxun Yang 
+S: Maintained
+F: hw/mips/loongson3_virt.c
+F: hw/intc/loongson_liointc.c
+
 Boston
 M: Paul Burton 
 R: Aleksandar Rikalo 
-- 
2.7.4

[PULL 6/6] MAINTAINERS: Add 'Performance Tools and Tests' subsection

[Aleksandar Markovic]

This commit creates a new 'Miscellaneous' section which hosts a new
'Performance Tools and Tests' subsection. This subsection will contain
the the performance scripts and benchmarks written as a part of the
'TCG Continuous Benchmarking' project. Also, it will be a placeholder
for follow-ups to this project, if any.

Signed-off-by: Ahmed Karaman 
Reviewed-by: Alex Bennée 
Reviewed-by: Aleksandar Markovic 
Signed-off-by: Aleksandar Markovic 
Message-Id: <20200626164546.22102-4-ahmedkhaledkara...@gmail.com>
---
 MAINTAINERS | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fe925ea..dec252f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1096,11 +1096,10 @@ F: hw/isa/vt82c686.c
 F: hw/pci-host/bonito.c
 F: include/hw/isa/vt82c686.h
 
-Loongson-3 Virtual Platform
+Loongson-3 virtual platforms
 M: Huacai Chen 
 R: Jiaxun Yang 
 S: Maintained
-F: hw/mips/loongson3_virt.c
 F: hw/intc/loongson_liointc.c
 
 Boston
@@ -3026,3 +3025,10 @@ M: Peter Maydell 
 S: Maintained
 F: docs/conf.py
 F: docs/*/conf.py
+
+Miscellaneous
+-
+Performance Tools and Tests
+M: Ahmed Karaman 
+S: Maintained
+F: scripts/performance/
-- 
2.7.4

[PULL 0/6] MIPS + TCG Continuous Benchmarking queue for June 27th, 2020

[Aleksandar Markovic]

The following changes since commit 553cf5d7c47bee05a3dec9461c1f8430316d516b:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200626' 
into staging (2020-06-26 18:22:36 +0100)

are available in the git repository at:

  https://github.com/AMarkovic/qemu tags/mips-gsoc-queue-jun-27-2020

for you to fetch changes up to 53fb8bfb93487c0fd88b0babb9a52ec8d67cff7b:

  MAINTAINERS: Add 'Performance Tools and Tests' subsection (2020-06-27 
20:15:07 +0200)



MIPS + TCG Continuous Benchmarking queue for June 27th, 2020

   Highlights:

 - add two additional elements of Loongson-3 support
 - add first two Python scripts as a part of a GSoC project

   Notes:

 - several checkpatch warnings on updating MAINTAINERS should be ignored



Ahmed Karaman (2):
  scripts/performance: Add topN_perf.py script
  scripts/performance: Add topN_callgrind.py script

Aleksandar Markovic (1):
  MAINTAINERS: Add 'Performance Tools and Tests' subsection

Huacai Chen (3):
  hw/mips: Implement the kvm_type() hook in MachineClass
  hw/intc: Add Loongson LIOINTC support
  MAINTAINERS: Add Loongson-3 maintainer and reviewer

 target/mips/kvm_mips.h|  11 ++
 hw/intc/loongson_liointc.c| 242 ++
 target/mips/kvm.c |  26 
 MAINTAINERS   |  13 ++
 hw/intc/Kconfig   |   3 +
 hw/intc/Makefile.objs |   1 +
 scripts/performance/topN_callgrind.py | 140 
 scripts/performance/topN_perf.py  | 149 +
 8 files changed, 585 insertions(+)
 create mode 100644 hw/intc/loongson_liointc.c
 create mode 100755 scripts/performance/topN_callgrind.py
 create mode 100755 scripts/performance/topN_perf.py

-- 
2.7.4

[PULL 1/6] hw/mips: Implement the kvm_type() hook in MachineClass

[Aleksandar Markovic]

From: Huacai Chen 

MIPS has two types of KVM: TE & VZ, and TE is the default type. Now we
can't create a VZ guest in QEMU because it lacks the kvm_type() hook in
MachineClass. This patch add the the kvm_type() hook to support both of
the two types.

[AM: Added "if defined" guards.]

Reviewed-by: Aleksandar Markovic 
Signed-off-by: Aleksandar Markovic 
Signed-off-by: Huacai Chen 
Co-developed-by: Jiaxun Yang 
Message-Id: <1592995531-32600-2-git-send-email-che...@lemote.com>
---
 target/mips/kvm_mips.h | 11 +++
 target/mips/kvm.c  | 26 ++
 2 files changed, 37 insertions(+)

diff --git a/target/mips/kvm_mips.h b/target/mips/kvm_mips.h
index 1e40147..171d53d 100644
--- a/target/mips/kvm_mips.h
+++ b/target/mips/kvm_mips.h
@@ -12,6 +12,8 @@
 #ifndef KVM_MIPS_H
 #define KVM_MIPS_H
 
+#include "cpu.h"
+
 /**
  * kvm_mips_reset_vcpu:
  * @cpu: MIPSCPU
@@ -23,4 +25,13 @@ void kvm_mips_reset_vcpu(MIPSCPU *cpu);
 int kvm_mips_set_interrupt(MIPSCPU *cpu, int irq, int level);
 int kvm_mips_set_ipi_interrupt(MIPSCPU *cpu, int irq, int level);
 
+#ifdef CONFIG_KVM
+int mips_kvm_type(MachineState *machine, const char *vm_type);
+#else
+static inline int mips_kvm_type(MachineState *machine, const char *vm_type)
+{
+return 0;
+}
+#endif
+
 #endif /* KVM_MIPS_H */
diff --git a/target/mips/kvm.c b/target/mips/kvm.c
index 96cfa10..72637a1 100644
--- a/target/mips/kvm.c
+++ b/target/mips/kvm.c
@@ -21,10 +21,12 @@
 #include "qemu/main-loop.h"
 #include "qemu/timer.h"
 #include "sysemu/kvm.h"
+#include "sysemu/kvm_int.h"
 #include "sysemu/runstate.h"
 #include "sysemu/cpus.h"
 #include "kvm_mips.h"
 #include "exec/memattrs.h"
+#include "hw/boards.h"
 
 #define DEBUG_KVM 0
 
@@ -1270,3 +1272,27 @@ int kvm_arch_msi_data_to_gsi(uint32_t data)
 {
 abort();
 }
+
+int mips_kvm_type(MachineState *machine, const char *vm_type)
+{
+#if defined(KVM_CAP_MIPS_VZ) || defined(KVM_CAP_MIPS_TE)
+int r;
+KVMState *s = KVM_STATE(machine->accelerator);
+#endif
+
+#if defined(KVM_CAP_MIPS_VZ)
+r = kvm_check_extension(s, KVM_CAP_MIPS_VZ);
+if (r > 0) {
+return KVM_VM_MIPS_VZ;
+}
+#endif
+
+#if defined(KVM_CAP_MIPS_TE)
+r = kvm_check_extension(s, KVM_CAP_MIPS_TE);
+if (r > 0) {
+return KVM_VM_MIPS_TE;
+}
+#endif
+
+return -1;
+}
-- 
2.7.4

[PULL 2/6] hw/intc: Add Loongson LIOINTC support

[Aleksandar Markovic]

From: Huacai Chen 

Loongson-3 has an integrated liointc (Local I/O Interrupt Controller).
It is similar to Goldfish interrupt controller, but more powerful (e.g.,
it can route external interrupt to multi-cores).

Documents about Loongson-3's liointc:
1, https://wiki.godson.ac.cn/ip_block:liointc;
2, The "I/O中断" section of Loongson-3's user mannual, part 1.

Signed-off-by: Huacai Chen 
Signed-off-by: Jiaxun Yang 
Signed-off-by: Aleksandar Markovic 
Reviewed-by: Aleksandar Markovic 
Message-Id: <1592995531-32600-3-git-send-email-che...@lemote.com>
---
 hw/intc/loongson_liointc.c | 242 +
 hw/intc/Kconfig|   3 +
 hw/intc/Makefile.objs  |   1 +
 3 files changed, 246 insertions(+)
 create mode 100644 hw/intc/loongson_liointc.c

diff --git a/hw/intc/loongson_liointc.c b/hw/intc/loongson_liointc.c
new file mode 100644
index 000..23ca51c
--- /dev/null
+++ b/hw/intc/loongson_liointc.c
@@ -0,0 +1,242 @@
+/*
+ * QEMU Loongson Local I/O interrupt controler.
+ *
+ * Copyright (c) 2020 Jiaxun Yang 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <https://www.gnu.org/licenses/>.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "qemu/module.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+
+#define D(x)
+
+#define NUM_IRQS32
+
+#define NUM_CORES   4
+#define NUM_IPS 4
+#define NUM_PARENTS (NUM_CORES * NUM_IPS)
+#define PARENT_COREx_IPy(x, y)  (NUM_IPS * x + y)
+
+#define R_MAPPER_START  0x0
+#define R_MAPPER_END0x20
+#define R_ISR   R_MAPPER_END
+#define R_IEN   0x24
+#define R_IEN_SET   0x28
+#define R_IEN_CLR   0x2c
+#define R_PERCORE_ISR(x)(0x40 + 0x8 * x)
+#define R_END   0x64
+
+#define TYPE_LOONGSON_LIOINTC "loongson.liointc"
+#define LOONGSON_LIOINTC(obj) \
+OBJECT_CHECK(struct loongson_liointc, (obj), TYPE_LOONGSON_LIOINTC)
+
+struct loongson_liointc {
+SysBusDevice parent_obj;
+
+MemoryRegion mmio;
+qemu_irq parent_irq[NUM_PARENTS];
+
+uint8_t mapper[NUM_IRQS]; /* 0:3 for core, 4:7 for IP */
+uint32_t isr;
+uint32_t ien;
+uint32_t per_core_isr[NUM_CORES];
+
+/* state of the interrupt input pins */
+uint32_t pin_state;
+bool parent_state[NUM_PARENTS];
+};
+
+static void update_irq(struct loongson_liointc *p)
+{
+uint32_t irq, core, ip;
+uint32_t per_ip_isr[NUM_IPS] = {0};
+
+/* level triggered interrupt */
+p->isr = p->pin_state;
+
+/* Clear disabled IRQs */
+p->isr &= p->ien;
+
+/* Clear per_core_isr */
+for (core = 0; core < NUM_CORES; core++) {
+p->per_core_isr[core] = 0;
+}
+
+/* Update per_core_isr and per_ip_isr */
+for (irq = 0; irq < NUM_IRQS; irq++) {
+if (!(p->isr & (1 << irq))) {
+continue;
+}
+
+for (core = 0; core < NUM_CORES; core++) {
+if ((p->mapper[irq] & (1 << core))) {
+p->per_core_isr[core] |= (1 << irq);
+}
+}
+
+for (ip = 0; ip < NUM_IPS; ip++) {
+if ((p->mapper[irq] & (1 << (ip + 4 {
+per_ip_isr[ip] |= (1 << irq);
+}
+}
+}
+
+/* Emit IRQ to parent! */
+for (core = 0; core < NUM_CORES; core++) {
+for (ip = 0; ip < NUM_IPS; ip++) {
+int parent = PARENT_COREx_IPy(core, ip);
+if (p->parent_state[parent] !=
+(!!p->per_core_isr[core] && !!per_ip_isr[ip])) {
+p->parent_state[parent] = !p->parent_state[parent];
+qemu_set_irq(p->parent_irq[parent], p->parent_state[parent]);
+}
+}
+}
+}
+
+static uint64_t
+liointc_read(void *opaque, hwaddr addr, unsigned int size)
+{
+struct loongson_liointc *p = opaque;
+uint32_t r = 0;
+
+/* Mapper is 1 byte */
+if (size == 1 && addr < R_MAPPER_END) {
+r = p->mapper[addr];
+goto out;
+}
+
+/* Rest is 4 byte */
+if (size != 4 || (addr % 4)) {
+goto out;
+}
+
+if (addr >= R_PERCORE_ISR(0) &&
+addr < R_PERC

[PULL 5/6] scripts/performance: Add topN_callgrind.py script

[Aleksandar Markovic]

From: Ahmed Karaman 

Python script that prints the top N most executed functions in QEMU
using callgrind.

Syntax:
topN_callgrind.py [-h] [-n]   -- \
   [] \
   []

[-h] - Print the script arguments help message.
[-n] - Specify the number of top functions to print.
 - If this flag is not specified, the tool defaults to 25.

Example of usage:
topN_callgrind.py -n 20 -- qemu-arm coulomb_double-arm

Example Output:
No.  Percentage Function Name Source File
  - ----
   124.577% 0x082db000???
   220.467% float64_mul   /fpu/softfloat.c
   314.720% float64_sub   /fpu/softfloat.c
   413.864% float64_add   /fpu/softfloat.c
   5 4.876% helper_mulsd  /target/i386/ops_sse.h
   6 3.767% helper_subsd  /target/i386/ops_sse.h
   7 3.549% helper_addsd  /target/i386/ops_sse.h
   8 2.185% helper_ucomisd/target/i386/ops_sse.h
   9 1.667% helper_lookup_tb_ptr  /include/exec/tb-lookup.h
  10 1.662% f64_compare   /fpu/softfloat.c
  11 1.509% helper_lookup_tb_ptr  /accel/tcg/tcg-runtime.c
  12 0.635% helper_lookup_tb_ptr  /include/exec/exec-all.h
  13 0.616% float64_div   /fpu/softfloat.c
  14 0.502% helper_pand_xmm   /target/i386/ops_sse.h
  15 0.502% float64_mul   /include/fpu/softfloat.h
  16 0.476% helper_lookup_tb_ptr  /target/i386/cpu.h
  17 0.437% float64_compare_quiet /fpu/softfloat.c
  18 0.414% helper_pxor_xmm   /target/i386/ops_sse.h
  19 0.353% round_to_int  /fpu/softfloat.c
  20 0.347% helper_cc_compute_all /target/i386/cc_helper.c

Signed-off-by: Ahmed Karaman 
Signed-off-by: Aleksandar Markovic 
Reviewed-by: Aleksandar Markovic 
Message-Id: <20200626164546.22102-3-ahmedkhaledkara...@gmail.com>
---
 scripts/performance/topN_callgrind.py | 140 ++
 1 file changed, 140 insertions(+)
 create mode 100755 scripts/performance/topN_callgrind.py

diff --git a/scripts/performance/topN_callgrind.py 
b/scripts/performance/topN_callgrind.py
new file mode 100755
index 000..67c5919
--- /dev/null
+++ b/scripts/performance/topN_callgrind.py
@@ -0,0 +1,140 @@
+#!/usr/bin/env python3
+
+#  Print the top N most executed functions in QEMU using callgrind.
+#  Syntax:
+#  topN_callgrind.py [-h] [-n]   -- \
+#[] \
+#[]
+#
+#  [-h] - Print the script arguments help message.
+#  [-n] - Specify the number of top functions to print.
+#   - If this flag is not specified, the tool defaults to 25.
+#
+#  Example of usage:
+#  topN_callgrind.py -n 20 -- qemu-arm coulomb_double-arm
+#
+#  This file is a part of the project "TCG Continuous Benchmarking".
+#
+#  Copyright (C) 2020  Ahmed Karaman 
+#  Copyright (C) 2020  Aleksandar Markovic 
+#
+#  This program is free software: you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation, either version 2 of the License, or
+#  (at your option) any later version.
+#
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+#  GNU General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+import argparse
+import os
+import subprocess
+import sys
+
+
+# Parse the command line arguments
+parser = argparse.ArgumentParser(
+usage='topN_callgrind.py [-h] [-n]   -- 
'
+  ' [] '
+  ' []')
+
+parser.add_argument('-n', dest='top', type=int, default=25,
+help='Specify the number of top functions to print.')
+
+parser.add_argument('command', type=str, nargs='+', help=argparse.SUPPRESS)
+
+args = parser.parse_args()
+
+# Extract the needed variables from the args
+command = args.command
+top = args.top
+
+# Insure that valgrind is installed
+check_valgrind_presence = subprocess.run(["which", "valgrind"],
+ stdout=subprocess.DEVNULL)
+if check_valgrind_presence.returncode:
+sys.exit("Please install valgrind before running the script!")
+
+# Run callgrind
+callgrind = subprocess.run((
+["valgrind", "--tool=callgrind", 
"--callgrind-out-file=/tmp/callgrind.data"]
++ command),
+stdout=subprocess.DEVNULL,
+stderr=subprocess.PIPE)
+if callgrind.returncode:
+sys.exit(callgrind.stderr.decode("utf-8"))
+
+# Save callgrind_annotate output to /tmp/callgrind_annotate.out
+with open("/tmp/callgrind_annotate.out", "w") as output:
+callgrind_annotate = subprocess.run(["callgrind_annotate"

Re: [PATCH v4 3/3] MAINTAINERS: Add 'Performance Tools and Tests'subsection

[Aleksandar Markovic]

On Fri, Jun 26, 2020 at 7:02 PM Ahmed Karaman
 wrote:
>
> This commit creates a new 'Miscellaneous' section which hosts a new
> 'Performance Tools and Tests' subsection.
> The subsection will contain the the performance scripts and benchmarks
> written as a part of the 'TCG Continuous Benchmarking' project.
>
> Signed-off-by: Ahmed Karaman 
> Reviewed-by: Alex Bennée 
> ---

Reviewed-by: Aleksandar Markovic 

Applied to "TCG Continuous Benchmarking" queue.

>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1b40446c73..c510c942ac 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3019,3 +3019,10 @@ M: Peter Maydell 
>  S: Maintained
>  F: docs/conf.py
>  F: docs/*/conf.py
> +
> +Miscellaneous
> +-
> +Performance Tools and Tests
> +M: Ahmed Karaman 
> +S: Maintained
> +F: scripts/performance/
> --
> 2.17.1
>
>

Re: [PATCH v4 1/3] scripts/performance: Add topN_perf.py script

[Aleksandar Markovic]

On Fri, Jun 26, 2020 at 7:00 PM Ahmed Karaman
 wrote:
>
> Syntax:
> topN_perf.py [-h] [-n]   -- \
>   [] \
>   []
>
> [-h] - Print the script arguments help message.
> [-n] - Specify the number of top functions to print.
>  - If this flag is not specified, the tool defaults to 25.
>
> Example of usage:
> topN_perf.py -n 20 -- qemu-arm coulomb_double-arm
>
> Example Output:
>  No.  Percentage  Name   Invoked by
>   --  -  -
>1  16.25%  float64_mulqemu-x86_64
>2  12.01%  float64_subqemu-x86_64
>3  11.99%  float64_addqemu-x86_64
>4   5.69%  helper_mulsd   qemu-x86_64
>5   4.68%  helper_addsd   qemu-x86_64
>6   4.43%  helper_lookup_tb_ptr   qemu-x86_64
>7   4.28%  helper_subsd   qemu-x86_64
>8   2.71%  f64_compareqemu-x86_64
>9   2.71%  helper_ucomisd qemu-x86_64
>   10   1.04%  helper_pand_xmmqemu-x86_64
>   11   0.71%  float64_divqemu-x86_64
>   12   0.63%  helper_pxor_xmmqemu-x86_64
>   13   0.50%  0x7f7b7004ef95 [JIT] tid 491
>   14   0.50%  0x7f7b70044e83 [JIT] tid 491
>   15   0.36%  helper_por_xmm qemu-x86_64
>   16   0.32%  helper_cc_compute_all  qemu-x86_64
>   17   0.30%  0x7f7b700433f0 [JIT] tid 491
>   18   0.30%  float64_compare_quiet  qemu-x86_64
>   19   0.27%  soft_f64_addsubqemu-x86_64
>   20   0.26%  round_to_int   qemu-x86_64
>
> Signed-off-by: Ahmed Karaman 
> ---

Reviewed-by: Aleksandar Markovic 

Applied to "TCG Continuous Benchmarking" queue.

>  scripts/performance/topN_perf.py | 149 +++
>  1 file changed, 149 insertions(+)
>  create mode 100755 scripts/performance/topN_perf.py
>
> diff --git a/scripts/performance/topN_perf.py 
> b/scripts/performance/topN_perf.py
> new file mode 100755
> index 00..07be195fc8
> --- /dev/null
> +++ b/scripts/performance/topN_perf.py
> @@ -0,0 +1,149 @@
> +#!/usr/bin/env python3
> +
> +#  Print the top N most executed functions in QEMU using perf.
> +#  Syntax:
> +#  topN_perf.py [-h] [-n]   -- \
> +#[] \
> +#[]
> +#
> +#  [-h] - Print the script arguments help message.
> +#  [-n] - Specify the number of top functions to print.
> +#   - If this flag is not specified, the tool defaults to 25.
> +#
> +#  Example of usage:
> +#  topN_perf.py -n 20 -- qemu-arm coulomb_double-arm
> +#
> +#  This file is a part of the project "TCG Continuous Benchmarking".
> +#
> +#  Copyright (C) 2020  Ahmed Karaman 
> +#  Copyright (C) 2020  Aleksandar Markovic 
> +#
> +#  This program is free software: you can redistribute it and/or modify
> +#  it under the terms of the GNU General Public License as published by
> +#  the Free Software Foundation, either version 2 of the License, or
> +#  (at your option) any later version.
> +#
> +#  This program is distributed in the hope that it will be useful,
> +#  but WITHOUT ANY WARRANTY; without even the implied warranty of
> +#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +#  GNU General Public License for more details.
> +#
> +#  You should have received a copy of the GNU General Public License
> +#  along with this program. If not, see <https://www.gnu.org/licenses/>.
> +
> +import argparse
> +import os
> +import subprocess
> +import sys
> +
> +
> +# Parse the command line arguments
> +parser = argparse.ArgumentParser(
> +usage='topN_perf.py [-h] [-n]   -- '
> +  ' [] '
> +  ' []')
> +
> +parser.add_argument('-n', dest='top', type=int, default=25,
> +help='Specify the number of top functions to print.')
> +
> +parser.add_argument('command', type=str, nargs='+', help=argparse.SUPPRESS)
> +
> +args = parser.parse_args()
> +
> +# Extract the needed variables from the args
> +command = args.command
> +top = args.top
> +
> +# Insure that perf is installed
> +check_perf_presence = subprocess.run(["which", "perf"],
> + stdout=subprocess.DEVNULL)
> +if check_perf_presence.returncode:
> +sys.exit("Please install perf before running the script!")
> +
> +# Insure user has previllage to run perf
> +check_perf_executability = subprocess.run(["perf", "stat", "ls", "/"],
> +

Re: [PATCH v4 2/3] scripts/performance: Add topN_callgrind.py script

[Aleksandar Markovic]

On Fri, Jun 26, 2020 at 6:59 PM Ahmed Karaman
 wrote:
>
> Python script that prints the top N most executed functions in QEMU
> using callgrind.
>
> Syntax:
> topN_callgrind.py [-h] [-n]   -- \
>[] \
>[]
>
> [-h] - Print the script arguments help message.
> [-n] - Specify the number of top functions to print.
>  - If this flag is not specified, the tool defaults to 25.
>
> Example of usage:
> topN_callgrind.py -n 20 -- qemu-arm coulomb_double-arm
>
> Example Output:
> No.  Percentage Function Name Source File
>   - ----
>124.577% 0x082db000???
>220.467% float64_mul   /fpu/softfloat.c
>314.720% float64_sub   /fpu/softfloat.c
>413.864% float64_add   /fpu/softfloat.c
>5 4.876% helper_mulsd  /target/i386/ops_sse.h
>6 3.767% helper_subsd  /target/i386/ops_sse.h
>7 3.549% helper_addsd  /target/i386/ops_sse.h
>8 2.185% helper_ucomisd/target/i386/ops_sse.h
>9 1.667% helper_lookup_tb_ptr  /include/exec/tb-lookup.h
>   10 1.662% f64_compare   /fpu/softfloat.c
>   11 1.509% helper_lookup_tb_ptr  /accel/tcg/tcg-runtime.c
>   12 0.635% helper_lookup_tb_ptr  /include/exec/exec-all.h
>   13 0.616% float64_div   /fpu/softfloat.c
>   14 0.502% helper_pand_xmm   /target/i386/ops_sse.h
>   15 0.502% float64_mul   /include/fpu/softfloat.h
>   16 0.476% helper_lookup_tb_ptr  /target/i386/cpu.h
>   17 0.437% float64_compare_quiet /fpu/softfloat.c
>   18 0.414% helper_pxor_xmm   /target/i386/ops_sse.h
>   19 0.353% round_to_int  /fpu/softfloat.c
>   20 0.347% helper_cc_compute_all /target/i386/cc_helper.c
>
> Signed-off-by: Ahmed Karaman 
> ---

Reviewed-by: Aleksandar Markovic 

Applied to "TCG Continuous Benchmarking" queue.

>  scripts/performance/topN_callgrind.py | 140 ++
>  1 file changed, 140 insertions(+)
>  create mode 100755 scripts/performance/topN_callgrind.py
>
> diff --git a/scripts/performance/topN_callgrind.py 
> b/scripts/performance/topN_callgrind.py
> new file mode 100755
> index 00..67c59197af
> --- /dev/null
> +++ b/scripts/performance/topN_callgrind.py
> @@ -0,0 +1,140 @@
> +#!/usr/bin/env python3
> +
> +#  Print the top N most executed functions in QEMU using callgrind.
> +#  Syntax:
> +#  topN_callgrind.py [-h] [-n]   -- \
> +#[] \
> +#[]
> +#
> +#  [-h] - Print the script arguments help message.
> +#  [-n] - Specify the number of top functions to print.
> +#   - If this flag is not specified, the tool defaults to 25.
> +#
> +#  Example of usage:
> +#  topN_callgrind.py -n 20 -- qemu-arm coulomb_double-arm
> +#
> +#  This file is a part of the project "TCG Continuous Benchmarking".
> +#
> +#  Copyright (C) 2020  Ahmed Karaman 
> +#  Copyright (C) 2020  Aleksandar Markovic 
> +#
> +#  This program is free software: you can redistribute it and/or modify
> +#  it under the terms of the GNU General Public License as published by
> +#  the Free Software Foundation, either version 2 of the License, or
> +#  (at your option) any later version.
> +#
> +#  This program is distributed in the hope that it will be useful,
> +#  but WITHOUT ANY WARRANTY; without even the implied warranty of
> +#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +#  GNU General Public License for more details.
> +#
> +#  You should have received a copy of the GNU General Public License
> +#  along with this program. If not, see <https://www.gnu.org/licenses/>.
> +
> +import argparse
> +import os
> +import subprocess
> +import sys
> +
> +
> +# Parse the command line arguments
> +parser = argparse.ArgumentParser(
> +usage='topN_callgrind.py [-h] [-n]   
> -- '
> +  ' [] '
> +  ' []')
> +
> +parser.add_argument('-n', dest='top', type=int, default=25,
> +help='Specify the number of top functions to print.')
> +
> +parser.add_argument('command', type=str, nargs='+', help=argparse.SUPPRESS)
> +
> +args = parser.parse_args()
> +
> +# Extract the needed variables from the args
> +command = args.command
> +top = args.top
> +
> +# Insure that valgrind is installed
> +check_valgrind_presence = subprocess.run(["which", "valgrind"],
> + stdout=subprocess.DEVNULL)
> +if check_valgrind_presence.returncode:
> +sys.exit("Please install valgrind before running the script!