[Qemu-devel] [PATCH 0/5] tile: Can load elf64 tilegx binary successfully for linux-user

[Qemu-devel] [PATCH 0/5] tile: Can load elf64 tilegx binary successfully for linux-user

[Chen Gang S]

After load elf64 tilegx binary for linux-user, the working flow reaches
1st correct instruction "__start". Next, we shall load all instructions
for qemu using.

This patch is based on Linux kernel tile architecture tilegx 64-bit
implementation, and also based on tilegx architecture ABI reference.

The related test:

  [root@localhost qemu]# ./configure --target-list=tilegx-linux-user && make 
  [root@localhost qemu]# ./tilegx-linux-user/qemu-tilegx -d all ./test.tgx
  CPU Reset (CPU 0)
  CPU Reset (CPU 0)
  host mmap_min_addr=0x10000
  Reserved 0xe0000 bytes of guest address space
  Relocating guest address space from 0x0000000000010000 to 0x10000
  guest_base  0x0  
  start            end              size             prot 
  0000000000010000-00000000000e0000 00000000000d0000 r-x
  00000000000e0000-00000000000f0000 0000000000010000 rw-
  0000004000000000-0000004000010000 0000000000010000 ---
  0000004000010000-0000004000810000 0000000000800000 rw-
  start_brk   0x0000000000000000
  end_code    0x00000000000d86f7
  start_code  0x0000000000010000
  start_data  0x00000000000e86f8
  end_data    0x00000000000ea208
  start_stack 0x000000400080f250
  brk         0x00000000000ec2b0
  entry       0x0000000000010f60
  PROLOGUE: [size=40]
  0x7fcc44c716f0:  push   %rbp 
  0x7fcc44c716f1:  push   %rbx 
  0x7fcc44c716f2:  push   %r12 
  0x7fcc44c716f4:  push   %r13 
  0x7fcc44c716f6:  push   %r14 
  0x7fcc44c716f8:  push   %r15 
  0x7fcc44c716fa:  mov    %rdi,%r14
  0x7fcc44c716fd:  add    $0xfffffffffffffb78,%rsp
  0x7fcc44c71704:  jmpq   *%rsi
  0x7fcc44c71706:  add    $0x488,%rsp
  0x7fcc44c7170d:  pop    %r15 
  0x7fcc44c7170f:  pop    %r14 
  0x7fcc44c71711:  pop    %r13 
  0x7fcc44c71713:  pop    %r12 
  0x7fcc44c71715:  pop    %rbx 
  0x7fcc44c71716:  pop    %rbp 
  0x7fcc44c71717:  retq 

  Load elf64 tilegx successfully
  reach code start position: [0000000000010f60] _start

  [root@localhost qemu]# echo $?
  0
  [root@localhost qemu]#


Chen Gang (5):
  target-tile: Firstly add to qemu with minimized features
  linux-user: tile: Firstly add architecture related features
  linux-user: tile: Add target features support within qemu
  linux-user: Support tile architecture in syscall
  linux-user: Support tile architecture in linux-user

 configure                             |   7 +
 default-configs/tilegx-linux-user.mak |   1 +
 include/elf.h                         |   2 +
 linux-user/elfload.c                  |  23 +++
 linux-user/main.c                     |  73 ++++++++
 linux-user/syscall_defs.h             |  34 +++-
 linux-user/tile/syscall.h             |  80 +++++++++
 linux-user/tile/syscall_nr.h          | 327 ++++++++++++++++++++++++++++++++++
 linux-user/tile/target_cpu.h          |  35 ++++
 linux-user/tile/target_signal.h       |  28 +++
 linux-user/tile/target_structs.h      |  48 +++++
 linux-user/tile/termbits.h            | 285 +++++++++++++++++++++++++++++
 target-tile/Makefile.objs             |   1 +
 target-tile/cpu-qom.h                 |  72 ++++++++
 target-tile/cpu.c                     | 159 +++++++++++++++++
 target-tile/cpu.h                     |  84 +++++++++
 target-tile/helper.h                  |   0
 target-tile/translate.c               |  54 ++++++
 18 files changed, 1310 insertions(+), 3 deletions(-)
 create mode 100644 default-configs/tilegx-linux-user.mak
 create mode 100644 linux-user/tile/syscall.h
 create mode 100644 linux-user/tile/syscall_nr.h
 create mode 100644 linux-user/tile/target_cpu.h
 create mode 100644 linux-user/tile/target_signal.h
 create mode 100644 linux-user/tile/target_structs.h
 create mode 100644 linux-user/tile/termbits.h
 create mode 100644 target-tile/Makefile.objs
 create mode 100644 target-tile/cpu-qom.h
 create mode 100644 target-tile/cpu.c
 create mode 100644 target-tile/cpu.h
 create mode 100644 target-tile/helper.h
 create mode 100644 target-tile/translate.c

-- 
1.9.3 (Apple Git-50)

[Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

It almost likes a template for adding an architecture target.

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 configure                             |   7 ++
 default-configs/tilegx-linux-user.mak |   1 +
 target-tile/Makefile.objs             |   1 +
 target-tile/cpu-qom.h                 |  72 +++++++++++++++
 target-tile/cpu.c                     | 159 ++++++++++++++++++++++++++++++++++
 target-tile/cpu.h                     |  84 ++++++++++++++++++
 target-tile/helper.h                  |   0
 target-tile/translate.c               |  54 ++++++++++++
 8 files changed, 378 insertions(+)
 create mode 100644 default-configs/tilegx-linux-user.mak
 create mode 100644 target-tile/Makefile.objs
 create mode 100644 target-tile/cpu-qom.h
 create mode 100644 target-tile/cpu.c
 create mode 100644 target-tile/cpu.h
 create mode 100644 target-tile/helper.h
 create mode 100644 target-tile/translate.c

diff --git a/configure b/configure
index 7ba4bcb..ffb4d56 100755
--- a/configure
+++ b/configure
@@ -5191,6 +5191,9 @@ case "$target_name" in
   s390x)
     gdb_xml_files="s390x-core64.xml s390-acr.xml s390-fpr.xml"
   ;;
+  tilegx)
+    TARGET_ARCH=tile
+  ;;
   unicore32)
   ;;
   xtensa|xtensaeb)
@@ -5363,6 +5366,10 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
     echo "CONFIG_SPARC_DIS=y"  >> $config_target_mak
     echo "CONFIG_SPARC_DIS=y"  >> config-all-disas.mak
   ;;
+  tilegx*)
+    echo "CONFIG_TILE_DIS=y"  >> $config_target_mak
+    echo "CONFIG_TILE_DIS=y"  >> config-all-disas.mak
+  ;;
   xtensa*)
     echo "CONFIG_XTENSA_DIS=y"  >> $config_target_mak
     echo "CONFIG_XTENSA_DIS=y"  >> config-all-disas.mak
diff --git a/default-configs/tilegx-linux-user.mak b/default-configs/tilegx-linux-user.mak
new file mode 100644
index 0000000..3e47493
--- /dev/null
+++ b/default-configs/tilegx-linux-user.mak
@@ -0,0 +1 @@
+# Default configuration for tilegx-linux-user
diff --git a/target-tile/Makefile.objs b/target-tile/Makefile.objs
new file mode 100644
index 0000000..dcf2fe4
--- /dev/null
+++ b/target-tile/Makefile.objs
@@ -0,0 +1 @@
+obj-y += cpu.o translate.o
diff --git a/target-tile/cpu-qom.h b/target-tile/cpu-qom.h
new file mode 100644
index 0000000..6026b81
--- /dev/null
+++ b/target-tile/cpu-qom.h
@@ -0,0 +1,72 @@
+/*
+ * QEMU Tile CPU
+ *
+ * Copyright (c) 2015 Chen Gang
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * <http://www.gnu.org/licenses/lgpl-2.1.html>
+ */
+#ifndef QEMU_TILE_CPU_QOM_H
+#define QEMU_TILE_CPU_QOM_H
+
+#include "qom/cpu.h"
+
+#define TYPE_TILE_CPU "tile-cpu"
+
+#define TILE_CPU_CLASS(klass) \
+    OBJECT_CLASS_CHECK(TileCPUClass, (klass), TYPE_TILE_CPU)
+#define TILE_CPU(obj) \
+    OBJECT_CHECK(TileCPU, (obj), TYPE_TILE_CPU)
+#define TILE_CPU_GET_CLASS(obj) \
+    OBJECT_GET_CLASS(TileCPUClass, (obj), TYPE_TILE_CPU)
+
+/**
+ * TileCPUClass:
+ * @parent_realize: The parent class' realize handler.
+ * @parent_reset: The parent class' reset handler.
+ *
+ * A Tile CPU model.
+ */
+typedef struct TileCPUClass {
+    /*< private >*/
+    CPUClass parent_class;
+    /*< public >*/
+
+    DeviceRealize parent_realize;
+    void (*parent_reset)(CPUState *cpu);
+} TileCPUClass;
+
+/**
+ * TileCPU:
+ * @env: #CPUTLState
+ *
+ * A Tile CPU.
+ */
+typedef struct TileCPU {
+    /*< private >*/
+    CPUState parent_obj;
+    uint64_t base_vectors;
+    /*< public >*/
+
+    CPUTLState env;
+} TileCPU;
+
+static inline TileCPU *tile_env_get_cpu(CPUTLState *env)
+{
+    return container_of(env, TileCPU, env);
+}
+
+#define ENV_GET_CPU(e) CPU(tile_env_get_cpu(e))
+
+#endif
diff --git a/target-tile/cpu.c b/target-tile/cpu.c
new file mode 100644
index 0000000..365ec7a
--- /dev/null
+++ b/target-tile/cpu.c
@@ -0,0 +1,159 @@
+/*
+ * QEMU Tile CPU
+ *
+ *  Copyright (c) 2015 Chen Gang
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * <http://www.gnu.org/licenses/lgpl-2.1.html>
+ */
+
+#include "cpu.h"
+#include "qemu-common.h"
+#include "hw/qdev-properties.h"
+#include "migration/vmstate.h"
+
+TileCPU *cpu_tile_init(const char *cpu_model)
+{
+    TileCPU *cpu;
+
+    cpu = TILE_CPU(object_new(TYPE_TILE_CPU));
+
+    object_property_set_bool(OBJECT(cpu), true, "realized", NULL);
+
+    return cpu;
+}
+
+static void tile_cpu_set_pc(CPUState *cs, vaddr value)
+{
+}
+
+static bool tile_cpu_has_work(CPUState *cs)
+{
+    return true;
+}
+
+static void tile_cpu_reset(CPUState *s)
+{
+    TileCPU *cpu = TILE_CPU(s);
+    TileCPUClass *mcc = TILE_CPU_GET_CLASS(cpu);
+    CPUTLState *env = &cpu->env;
+
+    mcc->parent_reset(s);
+
+    memset(env, 0, sizeof(CPUTLState));
+    tlb_flush(s, 1);
+}
+
+static void tile_cpu_realizefn(DeviceState *dev, Error **errp)
+{
+    CPUState *cs = CPU(dev);
+    TileCPUClass *mcc = TILE_CPU_GET_CLASS(dev);
+
+    cpu_reset(cs);
+    qemu_init_vcpu(cs);
+
+    mcc->parent_realize(dev, errp);
+}
+
+static void tile_tcg_init(void)
+{
+}
+
+static void tile_cpu_initfn(Object *obj)
+{
+    CPUState *cs = CPU(obj);
+    TileCPU *cpu = TILE_CPU(obj);
+    CPUTLState *env = &cpu->env;
+    static bool tcg_initialized;
+
+    cs->env_ptr = env;
+    cpu_exec_init(env);
+
+    if (tcg_enabled() && !tcg_initialized) {
+        tcg_initialized = true;
+        tile_tcg_init();
+    }
+}
+
+static const VMStateDescription vmstate_tile_cpu = {
+    .name = "cpu",
+    .unmigratable = 1,
+};
+
+static Property tile_properties[] = {
+    DEFINE_PROP_UINT64("tile.base-vectors", TileCPU, base_vectors, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void tile_cpu_do_interrupt(CPUState *cs)
+{
+    cs->exception_index = -1;
+}
+
+static int tile_cpu_handle_mmu_fault(CPUState *cs, vaddr address, int rw,
+                            int mmu_idx)
+{
+    cpu_dump_state(cs, stderr, fprintf, 0);
+    return 1;
+}
+
+static bool tile_cpu_exec_interrupt(CPUState *cs, int interrupt_request)
+{
+    if (interrupt_request & CPU_INTERRUPT_HARD) {
+        tile_cpu_do_interrupt(cs);
+        return true;
+    }
+    return false;
+}
+
+static void tile_cpu_class_init(ObjectClass *oc, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(oc);
+    CPUClass *cc = CPU_CLASS(oc);
+    TileCPUClass *mcc = TILE_CPU_CLASS(oc);
+
+    mcc->parent_realize = dc->realize;
+    dc->realize = tile_cpu_realizefn;
+
+    mcc->parent_reset = cc->reset;
+    cc->reset = tile_cpu_reset;
+
+    cc->has_work = tile_cpu_has_work;
+    cc->do_interrupt = tile_cpu_do_interrupt;
+    cc->cpu_exec_interrupt = tile_cpu_exec_interrupt;
+    cc->dump_state = NULL;
+    cc->set_pc = tile_cpu_set_pc;
+    cc->gdb_read_register = NULL;
+    cc->gdb_write_register = NULL;
+    cc->handle_mmu_fault = tile_cpu_handle_mmu_fault;
+    dc->vmsd = &vmstate_tile_cpu;
+    dc->props = tile_properties;
+    cc->gdb_num_core_regs = 0;
+}
+
+static const TypeInfo tile_cpu_type_info = {
+    .name = TYPE_TILE_CPU,
+    .parent = TYPE_CPU,
+    .instance_size = sizeof(TileCPU),
+    .instance_init = tile_cpu_initfn,
+    .class_size = sizeof(TileCPUClass),
+    .class_init = tile_cpu_class_init,
+};
+
+static void tile_cpu_register_types(void)
+{
+    type_register_static(&tile_cpu_type_info);
+}
+
+type_init(tile_cpu_register_types)
diff --git a/target-tile/cpu.h b/target-tile/cpu.h
new file mode 100644
index 0000000..b52ad75
--- /dev/null
+++ b/target-tile/cpu.h
@@ -0,0 +1,84 @@
+/*
+ *  Tile virtual CPU header
+ *
+ *  Copyright (c) 2015 Chen Gang
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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 Lesser General Public
+ * License along with this library; if not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef CPU_TILE_H
+#define CPU_TILE_H
+
+#include "config.h"
+#include "qemu-common.h"
+
+#define TARGET_LONG_BITS 64
+
+#define CPUArchState struct CPUTLState
+
+#include "exec/cpu-defs.h"
+#include "fpu/softfloat.h"
+
+/* Tilegx register alias */
+#define TILE_R_RE  0   /*  0 register, for function/syscall return value */
+#define TILE_R_NR  10  /* 10 register, for syscall number */
+#define TILE_R_BP  52  /* 52 register, optional frame pointer */
+#define TILE_R_TP  53  /* TP register, thread local storage data */
+#define TILE_R_SP  54  /* SP register, stack pointer */
+#define TILE_R_PC  55  /* LR register, pc pointer */
+
+typedef struct CPUTLState {
+    uint64_t regs[56];
+    CPU_COMMON
+} CPUTLState;
+
+#include "cpu-qom.h"
+
+/* Tilegx memory attributes */
+#define TARGET_PAGE_BITS 16  /* Tilegx uses 64KB page size */
+#define MMAP_SHIFT TARGET_PAGE_BITS
+#define TARGET_PHYS_ADDR_SPACE_BITS 42 /* Tilegx is 42 bit physical address */
+#define TARGET_VIRT_ADDR_SPACE_BITS 64 /* Tilegx has 64 bit virtual address */
+#define MMU_USER_IDX    0  /* independent from both qemu and architecture */
+
+#include "exec/cpu-all.h"
+
+int cpu_tile_exec(CPUTLState *s);
+int cpu_tile_signal_handler(int host_signum, void *pinfo, void *puc);
+
+#define cpu_exec cpu_tile_exec
+#define cpu_gen_code cpu_tile_gen_code
+#define cpu_signal_handler cpu_tile_signal_handler
+
+TileCPU *cpu_tile_init(const char *cpu_model);
+
+static inline CPUTLState *cpu_init(const char *cpu_model)
+{
+    TileCPU *cpu = cpu_tile_init(cpu_model);
+    if (cpu == NULL) {
+        return NULL;
+    }
+    return &cpu->env;
+}
+
+static inline void cpu_get_tb_cpu_state(CPUTLState *env, target_ulong *pc,
+                                        target_ulong *cs_base, int *flags)
+{
+    *pc = env->regs[TILE_R_PC];
+    *cs_base = 0;
+    *flags = 0;
+}
+
+#include "exec/exec-all.h"
+
+#endif
diff --git a/target-tile/helper.h b/target-tile/helper.h
new file mode 100644
index 0000000..e69de29
diff --git a/target-tile/translate.c b/target-tile/translate.c
new file mode 100644
index 0000000..d9fbf71
--- /dev/null
+++ b/target-tile/translate.c
@@ -0,0 +1,54 @@
+/*
+ * QEMU Tile CPU
+ *
+ *  Copyright (c) 2015 Chen Gang
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * <http://www.gnu.org/licenses/lgpl-2.1.html>
+ */
+
+#include "cpu.h"
+#include "disas/disas.h"
+#include "tcg-op.h"
+#include "exec/helper-proto.h"
+#include "exec/cpu_ldst.h"
+#include "exec/helper-gen.h"
+
+static inline void gen_intermediate_code_internal(TileCPU *cpu,
+                                                  TranslationBlock *tb,
+                                                  bool search_pc)
+{
+    /*
+     * FIXME: after load elf64 tilegx binary successfully, it will quit, at
+     * present, and will implement the related features next.
+     */
+    fprintf(stderr, "\nLoad elf64 tilegx successfully\n");
+    fprintf(stderr, "reach code start position: [" TARGET_FMT_lx "] %s\n\n",
+            tb->pc, lookup_symbol(tb->pc));
+    exit(0);
+}
+
+void gen_intermediate_code(CPUTLState *env, struct TranslationBlock *tb)
+{
+    gen_intermediate_code_internal(tile_env_get_cpu(env), tb, false);
+}
+
+void gen_intermediate_code_pc(CPUTLState *env, struct TranslationBlock *tb)
+{
+    gen_intermediate_code_internal(tile_env_get_cpu(env), tb, true);
+}
+
+void restore_state_to_opc(CPUTLState *env, TranslationBlock *tb, int pc_pos)
+{
+}
-- 
1.9.3 (Apple Git-50)

[Qemu-devel] [PATCH 3/5] linux-user: tile: Add target features support within qemu

[Chen Gang S]

They are for target features within qemu which independent from outside.

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 linux-user/tile/target_cpu.h     | 35 +++++++++++++++++++++++++++++
 linux-user/tile/target_signal.h  | 28 +++++++++++++++++++++++
 linux-user/tile/target_structs.h | 48 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 111 insertions(+)
 create mode 100644 linux-user/tile/target_cpu.h
 create mode 100644 linux-user/tile/target_signal.h
 create mode 100644 linux-user/tile/target_structs.h

diff --git a/linux-user/tile/target_cpu.h b/linux-user/tile/target_cpu.h
new file mode 100644
index 0000000..8e2f39c
--- /dev/null
+++ b/linux-user/tile/target_cpu.h
@@ -0,0 +1,35 @@
+/*
+ * Tile specific CPU ABI and functions for linux-user
+ *
+ * Copyright (c) 2015 Chen Gang
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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 Lesser General Public
+ * License along with this library; if not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef TARGET_CPU_H
+#define TARGET_CPU_H
+
+static inline void cpu_clone_regs(CPUTLState *env, target_ulong newsp)
+{
+    if (newsp) {
+        env->regs[TILE_R_SP] = newsp;
+    }
+    env->regs[TILE_R_RE] = 0;
+}
+
+static inline void cpu_set_tls(CPUTLState *env, target_ulong newtls)
+{
+    env->regs[TILE_R_TP] = newtls;
+}
+
+#endif
diff --git a/linux-user/tile/target_signal.h b/linux-user/tile/target_signal.h
new file mode 100644
index 0000000..7a70c37
--- /dev/null
+++ b/linux-user/tile/target_signal.h
@@ -0,0 +1,28 @@
+#ifndef TARGET_SIGNAL_H
+#define TARGET_SIGNAL_H
+
+#include "cpu.h"
+
+/* this struct defines a stack used during syscall handling */
+
+typedef struct target_sigaltstack {
+    abi_ulong ss_sp;
+    abi_ulong ss_size;
+    abi_long ss_flags;
+} target_stack_t;
+
+/*
+ * sigaltstack controls
+ */
+#define TARGET_SS_ONSTACK     1
+#define TARGET_SS_DISABLE     2
+
+#define TARGET_MINSIGSTKSZ    2048
+#define TARGET_SIGSTKSZ       8192
+
+static inline abi_ulong get_sp_from_cpustate(CPUTLState *state)
+{
+    return state->regs[TILE_R_SP];
+}
+
+#endif /* TARGET_SIGNAL_H */
diff --git a/linux-user/tile/target_structs.h b/linux-user/tile/target_structs.h
new file mode 100644
index 0000000..6fed776
--- /dev/null
+++ b/linux-user/tile/target_structs.h
@@ -0,0 +1,48 @@
+/*
+ * Tile specific structures for linux-user
+ *
+ * Copyright (c) 2015 Chen Gang
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef TARGET_STRUCTS_H
+#define TARGET_STRUCTS_H
+
+struct target_ipc_perm {
+    abi_int __key;                      /* Key.  */
+    abi_uint uid;                       /* Owner's user ID.  */
+    abi_uint gid;                       /* Owner's group ID.  */
+    abi_uint cuid;                      /* Creator's user ID.  */
+    abi_uint cgid;                      /* Creator's group ID.  */
+    abi_uint mode;                    /* Read/write permission.  */
+    abi_ushort __seq;                   /* Sequence number.  */
+    abi_ushort __pad2;
+    abi_ulong __unused1;
+    abi_ulong __unused2;
+};
+
+struct target_shmid_ds {
+    struct target_ipc_perm shm_perm;    /* operation permission struct */
+    abi_long shm_segsz;                 /* size of segment in bytes */
+    abi_ulong shm_atime;                /* time of last shmat() */
+    abi_ulong shm_dtime;                /* time of last shmdt() */
+    abi_ulong shm_ctime;                /* time of last change by shmctl() */
+    abi_int shm_cpid;                   /* pid of creator */
+    abi_int shm_lpid;                   /* pid of last shmop */
+    abi_ulong shm_nattch;               /* number of current attaches */
+    abi_ulong __unused4;
+    abi_ulong __unused5;
+};
+
+#endif
-- 
1.9.3 (Apple Git-50)

[Qemu-devel] [PATCH 4/5] linux-user: Support tile architecture in syscall

[Chen Gang S]

Add tile architecture in "syscall_defs.h", all related features (ioctrl,
and stat) are based on Linux kernel tilegx 64-bit implementation.

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 linux-user/syscall_defs.h | 34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 9ed6de8..06eb4af 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -65,7 +65,7 @@
 
 #if defined(TARGET_I386) || defined(TARGET_ARM) || defined(TARGET_SH4) \
     || defined(TARGET_M68K) || defined(TARGET_CRIS) || defined(TARGET_UNICORE32) \
-    || defined(TARGET_S390X) || defined(TARGET_OPENRISC)
+    || defined(TARGET_S390X) || defined(TARGET_OPENRISC) || defined(TARGET_TILE)
 
 #define TARGET_IOC_SIZEBITS	14
 #define TARGET_IOC_DIRBITS	2
@@ -365,7 +365,7 @@ int do_sigaction(int sig, const struct target_sigaction *act,
     || defined(TARGET_PPC) || defined(TARGET_MIPS) || defined(TARGET_SH4) \
     || defined(TARGET_M68K) || defined(TARGET_ALPHA) || defined(TARGET_CRIS) \
     || defined(TARGET_MICROBLAZE) || defined(TARGET_UNICORE32) \
-    || defined(TARGET_S390X) || defined(TARGET_OPENRISC)
+    || defined(TARGET_S390X) || defined(TARGET_OPENRISC) || defined(TARGET_TILE)
 
 #if defined(TARGET_SPARC)
 #define TARGET_SA_NOCLDSTOP    8u
@@ -1970,6 +1970,32 @@ struct target_stat64 {
     unsigned int __unused5;
 };
 
+#elif defined(TARGET_TILE)
+
+/* Copy from Linux kernel "uapi/asm-generic/stat.h" */
+struct target_stat {
+        abi_ulong st_dev;         /* Device.  */
+        abi_ulong st_ino;         /* File serial number.  */
+        unsigned int st_mode;        /* File mode.  */
+        unsigned int st_nlink;       /* Link count.  */
+        unsigned int st_uid;         /* User ID of the file's owner.  */
+        unsigned int st_gid;         /* Group ID of the file's group. */
+        abi_ulong st_rdev;        /* Device number, if device.  */
+        abi_ulong __pad1;
+        abi_long  st_size;        /* Size of file, in bytes.  */
+        int st_blksize;     /* Optimal block size for I/O.  */
+        int __pad2;
+        abi_long st_blocks;      /* Number 512-byte blocks allocated. */
+        abi_long target_st_atime;       /* Time of last access.  */
+        abi_ulong target_st_atime_nsec;
+        abi_long target_st_mtime;       /* Time of last modification.  */
+        abi_ulong target_st_mtime_nsec;
+        abi_long target_st_ctime;       /* Time of last status change.  */
+        abi_ulong target_st_ctime_nsec;
+        unsigned int __unused4;
+        unsigned int __unused5;
+};
+
 #else
 #error unsupported CPU
 #endif
@@ -2312,7 +2338,9 @@ struct target_flock {
 struct target_flock64 {
 	short  l_type;
 	short  l_whence;
-#if defined(TARGET_PPC) || defined(TARGET_X86_64) || defined(TARGET_MIPS) || defined(TARGET_SPARC) || defined(TARGET_HPPA) || defined (TARGET_MICROBLAZE)
+#if defined(TARGET_PPC) || defined(TARGET_X86_64) || defined(TARGET_MIPS) || \
+    defined(TARGET_SPARC) || defined(TARGET_HPPA) \
+    || defined(TARGET_MICROBLAZE) || defined(TARGET_TILE)
         int __pad;
 #endif
 	unsigned long long l_start;
-- 
1.9.3 (Apple Git-50)

[Qemu-devel] [PATCH 5/5] linux-user: Support tile architecture in linux-user

[Chen Gang S]

Add main working flow feature and loading elf64 tilegx binary feature,
based on Linux kernel tilegx 64-bit implementation.

After this patch, qemu can successfully load elf64 tilegx binary for
linux-user, and the working flow reaches 1st instruction "__start".

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 include/elf.h        |  2 ++
 linux-user/elfload.c | 23 +++++++++++++++++
 linux-user/main.c    | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 98 insertions(+)

diff --git a/include/elf.h b/include/elf.h
index a516584..9a16d5a 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -133,6 +133,8 @@ typedef int64_t  Elf64_Sxword;
 
 #define EM_AARCH64  183
 
+#define EM_TILEGX   191 /* Tile */
+
 /* This is the info that is needed to parse the dynamic section of the file */
 #define DT_NULL		0
 #define DT_NEEDED	1
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 399c021..fc68701 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1189,6 +1189,29 @@ static inline void init_thread(struct target_pt_regs *regs, struct image_info *i
 
 #endif /* TARGET_S390X */
 
+#ifdef TARGET_TILE
+
+/* 42 bits real used address, a half for user mode */
+#define ELF_START_MMAP (0x00000020000000000ULL)
+
+#define elf_check_arch(x) ((x) == EM_TILEGX)
+
+#define ELF_CLASS   ELFCLASS64
+#define ELF_DATA    ELFDATA2LSB
+#define ELF_ARCH    EM_TILE
+
+static inline void init_thread(struct target_pt_regs *regs,
+                               struct image_info *infop)
+{
+    regs->lr = infop->entry;
+    regs->sp = infop->start_stack;
+
+}
+
+#define ELF_EXEC_PAGESIZE        65536 /* Tilegx page size is 64KB */
+
+#endif /* TARGET_TILE */
+
 #ifndef ELF_PLATFORM
 #define ELF_PLATFORM (NULL)
 #endif
diff --git a/linux-user/main.c b/linux-user/main.c
index d92702a..4921f47 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3418,6 +3418,20 @@ void cpu_loop(CPUS390XState *env)
 
 #endif /* TARGET_S390X */
 
+#ifdef TARGET_TILE
+void cpu_loop(CPUTLState *env)
+{
+    CPUState *cs = CPU(tile_env_get_cpu(env));
+
+    while (1) {
+        cpu_exec_start(cs);
+        cpu_tile_exec(env);
+        cpu_exec_end(cs);
+        process_pending_signals(env);
+    }
+}
+#endif
+
 THREAD CPUState *thread_cpu;
 
 void task_settid(TaskState *ts)
@@ -4392,6 +4406,65 @@ int main(int argc, char **argv, char **envp)
             env->psw.mask = regs->psw.mask;
             env->psw.addr = regs->psw.addr;
     }
+#elif defined(TARGET_TILE)
+    {
+        env->regs[0] = regs->r0;
+        env->regs[1] = regs->r1;
+        env->regs[2] = regs->r2;
+        env->regs[3] = regs->r3;
+        env->regs[4] = regs->r4;
+        env->regs[5] = regs->r5;
+        env->regs[6] = regs->r6;
+        env->regs[7] = regs->r7;
+        env->regs[8] = regs->r8;
+        env->regs[9] = regs->r9;
+        env->regs[10] = regs->r10;
+        env->regs[11] = regs->r11;
+        env->regs[12] = regs->r12;
+        env->regs[13] = regs->r13;
+        env->regs[14] = regs->r14;
+        env->regs[15] = regs->r15;
+        env->regs[16] = regs->r16;
+        env->regs[17] = regs->r17;
+        env->regs[18] = regs->r18;
+        env->regs[19] = regs->r19;
+        env->regs[20] = regs->r20;
+        env->regs[21] = regs->r21;
+        env->regs[22] = regs->r22;
+        env->regs[23] = regs->r23;
+        env->regs[24] = regs->r24;
+        env->regs[25] = regs->r25;
+        env->regs[26] = regs->r26;
+        env->regs[27] = regs->r27;
+        env->regs[28] = regs->r28;
+        env->regs[29] = regs->r29;
+        env->regs[30] = regs->r30;
+        env->regs[31] = regs->r31;
+        env->regs[32] = regs->r32;
+        env->regs[33] = regs->r33;
+        env->regs[34] = regs->r34;
+        env->regs[35] = regs->r35;
+        env->regs[36] = regs->r36;
+        env->regs[37] = regs->r37;
+        env->regs[38] = regs->r38;
+        env->regs[39] = regs->r39;
+        env->regs[40] = regs->r40;
+        env->regs[41] = regs->r41;
+        env->regs[42] = regs->r42;
+        env->regs[43] = regs->r43;
+        env->regs[44] = regs->r44;
+        env->regs[45] = regs->r45;
+        env->regs[46] = regs->r46;
+        env->regs[47] = regs->r47;
+        env->regs[48] = regs->r48;
+        env->regs[49] = regs->r49;
+        env->regs[50] = regs->r50;
+        env->regs[51] = regs->r51;
+        env->regs[52] = regs->r52; /* TILE_R_BP */
+        env->regs[53] = regs->tp;  /* TILE_R_TP */
+        env->regs[54] = regs->sp;  /* TILE_R_SP */
+        env->regs[55] = regs->lr;  /* TILE_R_PC */
+    }
 #else
 #error unsupported target CPU
 #endif
-- 
1.9.3 (Apple Git-50)

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

On 2/13/15 05:15, Chen Gang S wrote:
> It almost likes a template for adding an architecture target.
> 
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> ---
>  configure                             |   7 ++
>  default-configs/tilegx-linux-user.mak |   1 +
>  target-tile/Makefile.objs             |   1 +
>  target-tile/cpu-qom.h                 |  72 +++++++++++++++
>  target-tile/cpu.c                     | 159 ++++++++++++++++++++++++++++++++++
>  target-tile/cpu.h                     |  84 ++++++++++++++++++
>  target-tile/helper.h                  |   0
>  target-tile/translate.c               |  54 ++++++++++++
>  8 files changed, 378 insertions(+)
>  create mode 100644 default-configs/tilegx-linux-user.mak
>  create mode 100644 target-tile/Makefile.objs
>  create mode 100644 target-tile/cpu-qom.h
>  create mode 100644 target-tile/cpu.c
>  create mode 100644 target-tile/cpu.h
>  create mode 100644 target-tile/helper.h
>  create mode 100644 target-tile/translate.c
> 
> diff --git a/configure b/configure
> index 7ba4bcb..ffb4d56 100755
> --- a/configure
> +++ b/configure
> @@ -5191,6 +5191,9 @@ case "$target_name" in
>    s390x)
>      gdb_xml_files="s390x-core64.xml s390-acr.xml s390-fpr.xml"
>    ;;
> +  tilegx)
> +    TARGET_ARCH=tile
> +  ;;

Oh, it needs to use "TARGET_ARCH=tilegx" instead of "TARGET_ARCH=tile",
or can not put "CONFIG_TILE_DIS=y" to config-all-disas.mak, below (when
I am adding "disas/tilegx.c", I meet it).

>    unicore32)
>    ;;
>    xtensa|xtensaeb)
> @@ -5363,6 +5366,10 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
>      echo "CONFIG_SPARC_DIS=y"  >> $config_target_mak
>      echo "CONFIG_SPARC_DIS=y"  >> config-all-disas.mak
>    ;;
> +  tilegx*)
> +    echo "CONFIG_TILE_DIS=y"  >> $config_target_mak
> +    echo "CONFIG_TILE_DIS=y"  >> config-all-disas.mak
> +  ;;
>    xtensa*)
>      echo "CONFIG_XTENSA_DIS=y"  >> $config_target_mak
>      echo "CONFIG_XTENSA_DIS=y"  >> config-all-disas.mak

[...]


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Peter Maydell]

On 13 February 2015 at 23:50, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
>
> On 2/13/15 05:15, Chen Gang S wrote:
>> It almost likes a template for adding an architecture target.
>>
>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>> ---
>>  configure                             |   7 ++
>>  default-configs/tilegx-linux-user.mak |   1 +
>>  target-tile/Makefile.objs             |   1 +
>>  target-tile/cpu-qom.h                 |  72 +++++++++++++++
>>  target-tile/cpu.c                     | 159 ++++++++++++++++++++++++++++++++++
>>  target-tile/cpu.h                     |  84 ++++++++++++++++++
>>  target-tile/helper.h                  |   0
>>  target-tile/translate.c               |  54 ++++++++++++
>>  8 files changed, 378 insertions(+)
>>  create mode 100644 default-configs/tilegx-linux-user.mak
>>  create mode 100644 target-tile/Makefile.objs
>>  create mode 100644 target-tile/cpu-qom.h
>>  create mode 100644 target-tile/cpu.c
>>  create mode 100644 target-tile/cpu.h
>>  create mode 100644 target-tile/helper.h
>>  create mode 100644 target-tile/translate.c
>>
>> diff --git a/configure b/configure
>> index 7ba4bcb..ffb4d56 100755
>> --- a/configure
>> +++ b/configure
>> @@ -5191,6 +5191,9 @@ case "$target_name" in
>>    s390x)
>>      gdb_xml_files="s390x-core64.xml s390-acr.xml s390-fpr.xml"
>>    ;;
>> +  tilegx)
>> +    TARGET_ARCH=tile
>> +  ;;
>
> Oh, it needs to use "TARGET_ARCH=tilegx" instead of "TARGET_ARCH=tile",
> or can not put "CONFIG_TILE_DIS=y" to config-all-disas.mak, below (when
> I am adding "disas/tilegx.c", I meet it).

You need to make up your mind about what your architecture
is called: is it "tile" or "tilegx"? Be consistent...

>
>>    unicore32)
>>    ;;
>>    xtensa|xtensaeb)
>> @@ -5363,6 +5366,10 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
>>      echo "CONFIG_SPARC_DIS=y"  >> $config_target_mak
>>      echo "CONFIG_SPARC_DIS=y"  >> config-all-disas.mak
>>    ;;
>> +  tilegx*)
>> +    echo "CONFIG_TILE_DIS=y"  >> $config_target_mak
>> +    echo "CONFIG_TILE_DIS=y"  >> config-all-disas.mak
>> +  ;;

You should only add this bit to configure in the patchset
where you add a Tile disassembler.

-- PMM

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Richard Henderson]

On 02/13/2015 04:26 PM, Peter Maydell wrote:
>> Oh, it needs to use "TARGET_ARCH=tilegx" instead of "TARGET_ARCH=tile",
>> or can not put "CONFIG_TILE_DIS=y" to config-all-disas.mak, below (when
>> I am adding "disas/tilegx.c", I meet it).
> 
> You need to make up your mind about what your architecture
> is called: is it "tile" or "tilegx"? Be consistent...

In particular, if you never plan to implement the 32-bit tilepro, then call it
tilegx.  All the way to putting the files in target-tilegx/.


r~

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

On 2/14/15 08:26, Peter Maydell wrote:
> On 13 February 2015 at 23:50, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
>>
>> On 2/13/15 05:15, Chen Gang S wrote:
>>> It almost likes a template for adding an architecture target.
>>>
>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>> ---
>>>  configure                             |   7 ++
>>>  default-configs/tilegx-linux-user.mak |   1 +
>>>  target-tile/Makefile.objs             |   1 +
>>>  target-tile/cpu-qom.h                 |  72 +++++++++++++++
>>>  target-tile/cpu.c                     | 159 ++++++++++++++++++++++++++++++++++
>>>  target-tile/cpu.h                     |  84 ++++++++++++++++++
>>>  target-tile/helper.h                  |   0
>>>  target-tile/translate.c               |  54 ++++++++++++
>>>  8 files changed, 378 insertions(+)
>>>  create mode 100644 default-configs/tilegx-linux-user.mak
>>>  create mode 100644 target-tile/Makefile.objs
>>>  create mode 100644 target-tile/cpu-qom.h
>>>  create mode 100644 target-tile/cpu.c
>>>  create mode 100644 target-tile/cpu.h
>>>  create mode 100644 target-tile/helper.h
>>>  create mode 100644 target-tile/translate.c
>>>
>>> diff --git a/configure b/configure
>>> index 7ba4bcb..ffb4d56 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -5191,6 +5191,9 @@ case "$target_name" in
>>>    s390x)
>>>      gdb_xml_files="s390x-core64.xml s390-acr.xml s390-fpr.xml"
>>>    ;;
>>> +  tilegx)
>>> +    TARGET_ARCH=tile
>>> +  ;;
>>
>> Oh, it needs to use "TARGET_ARCH=tilegx" instead of "TARGET_ARCH=tile",
>> or can not put "CONFIG_TILE_DIS=y" to config-all-disas.mak, below (when
>> I am adding "disas/tilegx.c", I meet it).
> 
> You need to make up your mind about what your architecture
> is called: is it "tile" or "tilegx"? Be consistent...
> 

Oh, after think of, for me, I shall follow the other architectures has
done (e.g. i386).

 - Still use target-tile directory, since 'tile' is the architecture
   name.

 - 'tilegx' is one kind of cpu of tile, so I need consider about it just
   like another architectures have done (e.g. i386).



>>
>>>    unicore32)
>>>    ;;
>>>    xtensa|xtensaeb)
>>> @@ -5363,6 +5366,10 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
>>>      echo "CONFIG_SPARC_DIS=y"  >> $config_target_mak
>>>      echo "CONFIG_SPARC_DIS=y"  >> config-all-disas.mak
>>>    ;;
>>> +  tilegx*)
>>> +    echo "CONFIG_TILE_DIS=y"  >> $config_target_mak
>>> +    echo "CONFIG_TILE_DIS=y"  >> config-all-disas.mak
>>> +  ;;
> 
> You should only add this bit to configure in the patchset
> where you add a Tile disassembler.
> 

Yeah, I shall add disassembler firstly, before generate tcg code:

 - binutils tilegx disassembler is easy to be integrated into qemu.

 - I shall reuse part of the tilegx disassembler code for generating tcg
   code.

 - For me, dumping disassemble code in qemu is much helpful for testing.

At present, I have integrated binutils tilegx disassembler into qemu, it
is passed building, and I shall give a test for it tonight. If no any
issues, I plan to send related patch too.

Welcome any ideas, suggestions, and completions.

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Peter Maydell]

On 14 February 2015 at 03:08, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
> Yeah, I shall add disassembler firstly, before generate tcg code:
>
>  - binutils tilegx disassembler is easy to be integrated into qemu.
>
>  - I shall reuse part of the tilegx disassembler code for generating tcg
>    code.
>
>  - For me, dumping disassemble code in qemu is much helpful for testing.
>
> At present, I have integrated binutils tilegx disassembler into qemu, it
> is passed building, and I shall give a test for it tonight. If no any
> issues, I plan to send related patch too.

Look out for license incompatibility issues. Binutils is GPL version 3,
whereas QEMU is GPLv2, so we can't accept code which is GPLv3-only.
If you want to use binutils disassembler code you need to use the
code from the last version of binutils which was GPLv2 licensed.
(The other option is if you happen to be the author of the disassembler
and so are in a position to dual-license it, but that doesn't apply
to you.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

On 2/14/15 10:40, Richard Henderson wrote:
> On 02/13/2015 04:26 PM, Peter Maydell wrote:
>>> Oh, it needs to use "TARGET_ARCH=tilegx" instead of "TARGET_ARCH=tile",
>>> or can not put "CONFIG_TILE_DIS=y" to config-all-disas.mak, below (when
>>> I am adding "disas/tilegx.c", I meet it).
>>
>> You need to make up your mind about what your architecture
>> is called: is it "tile" or "tilegx"? Be consistent...
> 
> In particular, if you never plan to implement the 32-bit tilepro, then call it
> tilegx.  All the way to putting the files in target-tilegx/.
> 

At present, for me, I do not plan to implement the 32-bit tilepro.

But the code is (will be) in qemu, it is shared to all over the world.
The other members should have right to add the 32-bit tilepro, and I
should not make negative effect with them.

So, for me, I need to follow with all other architectures have done in
qemu.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chris Metcalf]

On 2/13/2015 10:08 PM, Chen Gang S wrote:
> On 2/14/15 08:26, Peter Maydell wrote:
>> On 13 February 2015 at 23:50, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
>>> On 2/13/15 05:15, Chen Gang S wrote:
>>>> It almost likes a template for adding an architecture target.
>>>>
>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>>> ---
>>>>   configure                             |   7 ++
>>>>   default-configs/tilegx-linux-user.mak |   1 +
>>>>   target-tile/Makefile.objs             |   1 +
>>>>   target-tile/cpu-qom.h                 |  72 +++++++++++++++
>>>>   target-tile/cpu.c                     | 159 ++++++++++++++++++++++++++++++++++
>>>>   target-tile/cpu.h                     |  84 ++++++++++++++++++
>>>>   target-tile/helper.h                  |   0
>>>>   target-tile/translate.c               |  54 ++++++++++++
>>>>   8 files changed, 378 insertions(+)
>>>>   create mode 100644 default-configs/tilegx-linux-user.mak
>>>>   create mode 100644 target-tile/Makefile.objs
>>>>   create mode 100644 target-tile/cpu-qom.h
>>>>   create mode 100644 target-tile/cpu.c
>>>>   create mode 100644 target-tile/cpu.h
>>>>   create mode 100644 target-tile/helper.h
>>>>   create mode 100644 target-tile/translate.c
>>>>
>>>> diff --git a/configure b/configure
>>>> index 7ba4bcb..ffb4d56 100755
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -5191,6 +5191,9 @@ case "$target_name" in
>>>>     s390x)
>>>>       gdb_xml_files="s390x-core64.xml s390-acr.xml s390-fpr.xml"
>>>>     ;;
>>>> +  tilegx)
>>>> +    TARGET_ARCH=tile
>>>> +  ;;
>>> Oh, it needs to use "TARGET_ARCH=tilegx" instead of "TARGET_ARCH=tile",
>>> or can not put "CONFIG_TILE_DIS=y" to config-all-disas.mak, below (when
>>> I am adding "disas/tilegx.c", I meet it).
>> You need to make up your mind about what your architecture
>> is called: is it "tile" or "tilegx"? Be consistent...
>>
> Oh, after think of, for me, I shall follow the other architectures has
> done (e.g. i386).
>
>   - Still use target-tile directory, since 'tile' is the architecture
>     name.
>
>   - 'tilegx' is one kind of cpu of tile, so I need consider about it just
>     like another architectures have done (e.g. i386).

I recommend pretty strongly that you use "tilegx" consistently for qemu.  There is enough commonality in the Linux arch code that I chose "tile" to support both tilepro and tilegx.  But elsewhere, we use "tilegx" vs "tilepro", for example in binutils and gcc.  I would argue "qemu" is much more like binutils or gcc.  Also, note that while x86_64 can run i386 binaries, tilegx can not run tilepro binaries.

>> You should only add this bit to configure in the patchset
>> where you add a Tile disassembler.
> Yeah, I shall add disassembler firstly, before generate tcg code:
>
>   - binutils tilegx disassembler is easy to be integrated into qemu.
>
>   - I shall reuse part of the tilegx disassembler code for generating tcg
>     code.
>
>   - For me, dumping disassemble code in qemu is much helpful for testing.
>
> At present, I have integrated binutils tilegx disassembler into qemu, it
> is passed building, and I shall give a test for it tonight. If no any
> issues, I plan to send related patch too.

The license issue is tricky with qemu.  The tilegx support was only returned to the community in release 2.22, and binutils has been GPL v3 since 2.18 or so.  So you can't use that code.  On the other hand, there is disassembly code in the kernel that we released under the kernel's GPL v2; see arch/tile/kernel/tile-desc_64.c and the matching include file.  So maybe there is enough there for you to use to implement the disassembly code.

I'm not sure whether Tilera can simply re-release the tilegx-specific stuff from binutils as a separate tarball with GPL v2 licensing.  Hopefully we can avoid having to figure that out. :-)

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Peter Maydell]

On 14 February 2015 at 03:37, Chris Metcalf <cmetcalf@ezchip.com> wrote:
> I'm not sure whether Tilera can simply re-release the tilegx-specific stuff
> from binutils as a separate tarball with GPL v2 licensing.  Hopefully we can
> avoid having to figure that out. :-)

I believe it is theoretically possible (the usual FSF copyright arrangements
involve the original authors giving the copyright to the FSF but being
granted back a right to distribute their work under other licenses).
However it is definitely a "check with your lawyers" kind of question
and I entirely appreciate the desire to avoid having to go down that
route :-)

-- PMM

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

On 2/14/15 11:37, Chris Metcalf wrote:
> On 2/13/2015 10:08 PM, Chen Gang S wrote:
>> On 2/14/15 08:26, Peter Maydell wrote:
>>> On 13 February 2015 at 23:50, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
>>>> On 2/13/15 05:15, Chen Gang S wrote:
>>>>> It almost likes a template for adding an architecture target.
>>>>>
>>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>>>> ---
>>>>>   configure                             |   7 ++
>>>>>   default-configs/tilegx-linux-user.mak |   1 +
>>>>>   target-tile/Makefile.objs             |   1 +
>>>>>   target-tile/cpu-qom.h                 |  72 +++++++++++++++
>>>>>   target-tile/cpu.c                     | 159 ++++++++++++++++++++++++++++++++++
>>>>>   target-tile/cpu.h                     |  84 ++++++++++++++++++
>>>>>   target-tile/helper.h                  |   0
>>>>>   target-tile/translate.c               |  54 ++++++++++++
>>>>>   8 files changed, 378 insertions(+)
>>>>>   create mode 100644 default-configs/tilegx-linux-user.mak
>>>>>   create mode 100644 target-tile/Makefile.objs
>>>>>   create mode 100644 target-tile/cpu-qom.h
>>>>>   create mode 100644 target-tile/cpu.c
>>>>>   create mode 100644 target-tile/cpu.h
>>>>>   create mode 100644 target-tile/helper.h
>>>>>   create mode 100644 target-tile/translate.c
>>>>>
>>>>> diff --git a/configure b/configure
>>>>> index 7ba4bcb..ffb4d56 100755
>>>>> --- a/configure
>>>>> +++ b/configure
>>>>> @@ -5191,6 +5191,9 @@ case "$target_name" in
>>>>>     s390x)
>>>>>       gdb_xml_files="s390x-core64.xml s390-acr.xml s390-fpr.xml"
>>>>>     ;;
>>>>> +  tilegx)
>>>>> +    TARGET_ARCH=tile
>>>>> +  ;;
>>>> Oh, it needs to use "TARGET_ARCH=tilegx" instead of "TARGET_ARCH=tile",
>>>> or can not put "CONFIG_TILE_DIS=y" to config-all-disas.mak, below (when
>>>> I am adding "disas/tilegx.c", I meet it).
>>> You need to make up your mind about what your architecture
>>> is called: is it "tile" or "tilegx"? Be consistent...
>>>
>> Oh, after think of, for me, I shall follow the other architectures has
>> done (e.g. i386).
>>
>>   - Still use target-tile directory, since 'tile' is the architecture
>>     name.
>>
>>   - 'tilegx' is one kind of cpu of tile, so I need consider about it just
>>     like another architectures have done (e.g. i386).
> 
> I recommend pretty strongly that you use "tilegx" consistently for qemu.  There is enough commonality in the Linux arch code that I chose "tile" to support both tilepro and tilegx.  But elsewhere, we use "tilegx" vs "tilepro", for example in binutils and gcc.  I would argue "qemu" is much more like binutils or gcc.  Also, note that while x86_64 can run i386 binaries, tilegx can not run tilepro binaries.
> 

OK, thanks, what you said sounds reasonable to me, I shall only use
tilegx consistently for qemu.


>>> You should only add this bit to configure in the patchset
>>> where you add a Tile disassembler.
>> Yeah, I shall add disassembler firstly, before generate tcg code:
>>
>>   - binutils tilegx disassembler is easy to be integrated into qemu.
>>
>>   - I shall reuse part of the tilegx disassembler code for generating tcg
>>     code.
>>
>>   - For me, dumping disassemble code in qemu is much helpful for testing.
>>
>> At present, I have integrated binutils tilegx disassembler into qemu, it
>> is passed building, and I shall give a test for it tonight. If no any
>> issues, I plan to send related patch too.
> 
> The license issue is tricky with qemu.  The tilegx support was only returned to the community in release 2.22, and binutils has been GPL v3 since 2.18 or so.  So you can't use that code.  On the other hand, there is disassembly code in the kernel that we released under the kernel's GPL v2; see arch/tile/kernel/tile-desc_64.c and the matching include file.  So maybe there is enough there for you to use to implement the disassembly code.
> 
> I'm not sure whether Tilera can simply re-release the tilegx-specific stuff from binutils as a separate tarball with GPL v2 licensing.  Hopefully we can avoid having to figure that out. :-)
> 

After read through the related kernel code, I guess, it is enough for me
to use to implement the disassembly code.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

On 2/14/15 13:47, Peter Maydell wrote:
> On 14 February 2015 at 03:37, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>> I'm not sure whether Tilera can simply re-release the tilegx-specific stuff
>> from binutils as a separate tarball with GPL v2 licensing.  Hopefully we can
>> avoid having to figure that out. :-)
> 
> I believe it is theoretically possible (the usual FSF copyright arrangements
> involve the original authors giving the copyright to the FSF but being
> granted back a right to distribute their work under other licenses).
> However it is definitely a "check with your lawyers" kind of question
> and I entirely appreciate the desire to avoid having to go down that
> route :-)
> 

For me, the main feature of kernel disassembly implementation is almost
the same as the feature of binutils disassembly implementation. And all
of related code are not quite much (only several thousand lines),

So at present, I guess, we needn't consider more about the related
license.


Thanks
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

Excuse me, I want to consult the related information about SPR.

For SPRs (Special Purpose Register) under tilegx, I can not get related
documents (I only got the tilepro related document for SPR). After read
through the source code of Linux kernel for tile, I guess:

 - SPRs are in "arch/tile/include/uapi/arch/spr_def_64.h".

 - SPRs are all 64-bit registers (I referenced the 'interrupt_mask' and
   CHIP_HAS_SPLIT_INTR_MASK to know about it).

If what I guess is incorrect, please let me know. And welcome to provide
tilegx SPR related documents, too.

Thanks.

On 2/14/15 23:53, Chen Gang S wrote:
> On 2/14/15 13:47, Peter Maydell wrote:
>> On 14 February 2015 at 03:37, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>>> I'm not sure whether Tilera can simply re-release the tilegx-specific stuff
>>> from binutils as a separate tarball with GPL v2 licensing.  Hopefully we can
>>> avoid having to figure that out. :-)
>>
>> I believe it is theoretically possible (the usual FSF copyright arrangements
>> involve the original authors giving the copyright to the FSF but being
>> granted back a right to distribute their work under other licenses).
>> However it is definitely a "check with your lawyers" kind of question
>> and I entirely appreciate the desire to avoid having to go down that
>> route :-)
>>
> 
> For me, the main feature of kernel disassembly implementation is almost
> the same as the feature of binutils disassembly implementation. And all
> of related code are not quite much (only several thousand lines),
> 
> So at present, I guess, we needn't consider more about the related
> license.
> 
> 
> Thanks
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

Excuse me, after comparing the code details between kernel version
disassembler and binutils version disassembler, I am sure the kernel
version disassembler is the part of the binutils version disassembler:

 - kernel version is DISASM_ONLY.

 - kernel version does not need BFD_RELOC.

 - kernel version has defined __KERNEL__ (so need not check it again).

 - kernel version decode_X1_fsm[1206] is older than binutils version
   decode_X1_fsm[1266].

I guess, for qemu, we need !DISASM_ONLY, and may need BFD_RELOC, and may
need the latest decode_X1_fsm, and also may need !__KERNEL__ -- which
means we will use the full binutils version disassembler!!

In current condition, I really don't know how to do next. Welcome any
ideas, and suggestions.


Thanks.

On 2/16/15 11:40, Chen Gang S wrote:
> Excuse me, I want to consult the related information about SPR.
> 
> For SPRs (Special Purpose Register) under tilegx, I can not get related
> documents (I only got the tilepro related document for SPR). After read
> through the source code of Linux kernel for tile, I guess:
> 
>  - SPRs are in "arch/tile/include/uapi/arch/spr_def_64.h".
> 
>  - SPRs are all 64-bit registers (I referenced the 'interrupt_mask' and
>    CHIP_HAS_SPLIT_INTR_MASK to know about it).
> 
> If what I guess is incorrect, please let me know. And welcome to provide
> tilegx SPR related documents, too.
> 
> Thanks.
> 
> On 2/14/15 23:53, Chen Gang S wrote:
>> On 2/14/15 13:47, Peter Maydell wrote:
>>> On 14 February 2015 at 03:37, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>>>> I'm not sure whether Tilera can simply re-release the tilegx-specific stuff
>>>> from binutils as a separate tarball with GPL v2 licensing.  Hopefully we can
>>>> avoid having to figure that out. :-)
>>>
>>> I believe it is theoretically possible (the usual FSF copyright arrangements
>>> involve the original authors giving the copyright to the FSF but being
>>> granted back a right to distribute their work under other licenses).
>>> However it is definitely a "check with your lawyers" kind of question
>>> and I entirely appreciate the desire to avoid having to go down that
>>> route :-)
>>>
>>
>> For me, the main feature of kernel disassembly implementation is almost
>> the same as the feature of binutils disassembly implementation. And all
>> of related code are not quite much (only several thousand lines),
>>
>> So at present, I guess, we needn't consider more about the related
>> license.
>>
>>
>> Thanks
>>
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chris Metcalf]

On 2/16/2015 9:44 AM, Chen Gang S wrote:
> Excuse me, after comparing the code details between kernel version
> disassembler and binutils version disassembler, I am sure the kernel
> version disassembler is the part of the binutils version disassembler:

Yes, exactly.  We used an unifdef tool and some reindenting to generate the
kernel version from the same master that we used to generate the binutils
version.  We released the two under different licenses.  I'm pretty comfortable
that all of this is in the letter and spirit of copyright and license.

So you can start with the kernel version and you will inherit the GPL v2 license
of that code.

>   - kernel version decode_X1_fsm[1206] is older than binutils version
>     decode_X1_fsm[1266].

I'm pretty sure this represents the ld_tls family of instructions that are present
in binutils.  However, these are updated by the runtime loader, so you won't see
them if you are disassembling live code anyway.  If it for some reason this becomes
an issue, I expect we could generate an appropriate update for the kernel version.

> I guess, for qemu, we need !DISASM_ONLY, and may need BFD_RELOC, and may
> need the latest decode_X1_fsm, and also may need !__KERNEL__ -- which
> means we will use the full binutils version disassembler!!
>
> In current condition, I really don't know how to do next. Welcome any
> ideas, and suggestions.

Honestly, I'm not sure that that's true.  Mostly you just need to be able to
recognize instructions, I would think.  I suspect it's worth pushing ahead with
the kernel stuff as a base and see more precisely what you think is missing.
I don't know the qemu requirements well enough to give an educated opinion.

The disassembly stuff in the kernel allows you to recognize instructions, extract
operands (registers and immediates), etc.

There is also some code in glibc's sysdep/tile/dl-machine.h which implements the
runtime loader relocation processing, under GPL v2.1; perhaps some of that would
be relevant to what qemu does?  Again, I'm not really sure.

On 2/14/15 23:53, Chen Gang S wrote:
>>> On 2/14/15 13:47, Peter Maydell wrote:
>>>> On 14 February 2015 at 03:37, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>>>>> I'm not sure whether Tilera can simply re-release the tilegx-specific stuff
>>>>> from binutils as a separate tarball with GPL v2 licensing.  Hopefully we can
>>>>> avoid having to figure that out. :-)
>>>> I believe it is theoretically possible (the usual FSF copyright arrangements
>>>> involve the original authors giving the copyright to the FSF but being
>>>> granted back a right to distribute their work under other licenses).
>>>> However it is definitely a "check with your lawyers" kind of question
>>>> and I entirely appreciate the desire to avoid having to go down that
>>>> route :-)
>>>>
>>> For me, the main feature of kernel disassembly implementation is almost
>>> the same as the feature of binutils disassembly implementation. And all
>>> of related code are not quite much (only several thousand lines),
>>>
>>> So at present, I guess, we needn't consider more about the related
>>> license.
>>>
>>>
>>> Thanks
>>>

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Max Filippov]

On Mon, Feb 16, 2015 at 5:44 PM, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
> I guess, for qemu, we need !DISASM_ONLY, and may need BFD_RELOC, and may
> need the latest decode_X1_fsm, and also may need !__KERNEL__ -- which
> means we will use the full binutils version disassembler!!

Disassembler is not a crucial part of QEMU target.
If you need it you can dump instruction bytes and use the script
scripts/disas-objdump.pl
that calls binutils. target-xtensa does that.

-- 
Thanks.
-- Max

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

On 2/16/15 23:24, Max Filippov wrote:
> On Mon, Feb 16, 2015 at 5:44 PM, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
>> I guess, for qemu, we need !DISASM_ONLY, and may need BFD_RELOC, and may
>> need the latest decode_X1_fsm, and also may need !__KERNEL__ -- which
>> means we will use the full binutils version disassembler!!
> 
> Disassembler is not a crucial part of QEMU target.

For me, it is necessary. We need disassemble target binary instructions
(recognize them), then translate them into tcg instructions which are
grouped by Translate Block.

We may not need to display the instructions (it is only for test), but
we still need recognize them.

And for me, current tilera opcode implementation in binutils/kernel is
already almost the fewest and the simplestkk.


> If you need it you can dump instruction bytes and use the script
> scripts/disas-objdump.pl
> that calls binutils. target-xtensa does that.
> 

OK, thanks, for me, it is a useful tool.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

On 2/16/15 23:00, Chris Metcalf wrote:
> On 2/16/2015 9:44 AM, Chen Gang S wrote:
>> Excuse me, after comparing the code details between kernel version
>> disassembler and binutils version disassembler, I am sure the kernel
>> version disassembler is the part of the binutils version disassembler:
> 
> Yes, exactly.  We used an unifdef tool and some reindenting to generate the
> kernel version from the same master that we used to generate the binutils
> version.  We released the two under different licenses.  I'm pretty comfortable
> that all of this is in the letter and spirit of copyright and license.
> 
> So you can start with the kernel version and you will inherit the GPL v2 license
> of that code.
> 

OK, thanks, so I can continue. :-)


>>   - kernel version decode_X1_fsm[1206] is older than binutils version
>>     decode_X1_fsm[1266].
> 
> I'm pretty sure this represents the ld_tls family of instructions that are present
> in binutils.  However, these are updated by the runtime loader, so you won't see
> them if you are disassembling live code anyway.  If it for some reason this becomes
> an issue, I expect we could generate an appropriate update for the kernel version.
> 

OK, thanks. At present, I just skip them, if I really meet the related
issue (I guess not), I shall notify to tile related members.


>> I guess, for qemu, we need !DISASM_ONLY, and may need BFD_RELOC, and may
>> need the latest decode_X1_fsm, and also may need !__KERNEL__ -- which
>> means we will use the full binutils version disassembler!!
>>
>> In current condition, I really don't know how to do next. Welcome any
>> ideas, and suggestions.
> 
> Honestly, I'm not sure that that's true.  Mostly you just need to be able to
> recognize instructions, I would think.  I suspect it's worth pushing ahead with
> the kernel stuff as a base and see more precisely what you think is missing.
> I don't know the qemu requirements well enough to give an educated opinion.
> 

OK, thanks.


> The disassembly stuff in the kernel allows you to recognize instructions, extract
> operands (registers and immediates), etc.
> 

OK, thanks, I guess, you mean that we can still be DISASM_ONLY (if what
I guess is incorrect, please let me know).

> There is also some code in glibc's sysdep/tile/dl-machine.h which implements the
> runtime loader relocation processing, under GPL v2.1; perhaps some of that would
> be relevant to what qemu does?  Again, I'm not really sure.
> 

OK, thanks, I guess you mean we need consider about BFD_RELOC, and may
reference glib implementation to get help (binutils implements BFD_RELOC
with the almost simplest and fewest code, but we can not use them).

And I shall also try "!__KERNEL__ && !__LIBC__" to see the result, then
decide whether we use them or not (I guess we can skip them, just like
kernel version disassembler has done).


Thanks
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Peter Maydell]

On 17 February 2015 at 08:08, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
> On 2/16/15 23:24, Max Filippov wrote:
>> Disassembler is not a crucial part of QEMU target.
>
> For me, it is necessary. We need disassemble target binary instructions
> (recognize them), then translate them into tcg instructions which are
> grouped by Translate Block.

No, Max is correct. What QEMU calls the "disassembler" is just
used for debug logging: it is code that goes from target binary
instructions to printed display of assembly language instructions.
This is completely separate code from the code in target-*/translate.c
which decodes target binary instructions and emits TCG opcodes.
That code is generally called the translator or the decoder, and
it is always written from scratch specifically for QEMU. Don't
try to reuse code from binutils there.

-- PMM

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chris Metcalf]

On 2/16/2015 6:46 PM, Peter Maydell wrote:
> On 17 February 2015 at 08:08, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
>> On 2/16/15 23:24, Max Filippov wrote:
>>> Disassembler is not a crucial part of QEMU target.
>> For me, it is necessary. We need disassemble target binary instructions
>> (recognize them), then translate them into tcg instructions which are
>> grouped by Translate Block.
> No, Max is correct. What QEMU calls the "disassembler" is just
> used for debug logging: it is code that goes from target binary
> instructions to printed display of assembly language instructions.
> This is completely separate code from the code in target-*/translate.c
> which decodes target binary instructions and emits TCG opcodes.
> That code is generally called the translator or the decoder, and
> it is always written from scratch specifically for QEMU. Don't
> try to reuse code from binutils there.

The kernel disassembly that Chen Gang is looking at is basically just an
instruction recognizer; it doesn't even include text strings for opcodes,
for example.  But my guess is that it is exactly the right starting building
block for decoding target binary instructions.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chris Metcalf]

Yes, I think there is a bit less documentation on tilegx SPRs available.
If this becomes a blocker for you, let me know and I will see if there is anything
we can do about it.  Probably best to wait until you have made more progress
on qemu before trying to make a case for it internally, though.

On 2/15/2015 10:40 PM, Chen Gang S wrote:
> Excuse me, I want to consult the related information about SPR.
>
> For SPRs (Special Purpose Register) under tilegx, I can not get related
> documents (I only got the tilepro related document for SPR). After read
> through the source code of Linux kernel for tile, I guess:
>
>   - SPRs are in "arch/tile/include/uapi/arch/spr_def_64.h".
>
>   - SPRs are all 64-bit registers (I referenced the 'interrupt_mask' and
>     CHIP_HAS_SPLIT_INTR_MASK to know about it).
>
> If what I guess is incorrect, please let me know. And welcome to provide
> tilegx SPR related documents, too.
>
> Thanks.
>
> On 2/14/15 23:53, Chen Gang S wrote:
>> On 2/14/15 13:47, Peter Maydell wrote:
>>> On 14 February 2015 at 03:37, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>>>> I'm not sure whether Tilera can simply re-release the tilegx-specific stuff
>>>> from binutils as a separate tarball with GPL v2 licensing.  Hopefully we can
>>>> avoid having to figure that out. :-)
>>> I believe it is theoretically possible (the usual FSF copyright arrangements
>>> involve the original authors giving the copyright to the FSF but being
>>> granted back a right to distribute their work under other licenses).
>>> However it is definitely a "check with your lawyers" kind of question
>>> and I entirely appreciate the desire to avoid having to go down that
>>> route :-)
>>>
>> For me, the main feature of kernel disassembly implementation is almost
>> the same as the feature of binutils disassembly implementation. And all
>> of related code are not quite much (only several thousand lines),
>>
>> So at present, I guess, we needn't consider more about the related
>> license.
>>
>>
>> Thanks
>>

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

On 2/17/15 08:29, Chris Metcalf wrote:
> Yes, I think there is a bit less documentation on tilegx SPRs available.
> If this becomes a blocker for you, let me know and I will see if there is anything
> we can do about it.  Probably best to wait until you have made more progress
> on qemu before trying to make a case for it internally, though.
> 

OK, thanks.

> On 2/15/2015 10:40 PM, Chen Gang S wrote:
>> Excuse me, I want to consult the related information about SPR.
>>
>> For SPRs (Special Purpose Register) under tilegx, I can not get related
>> documents (I only got the tilepro related document for SPR). After read
>> through the source code of Linux kernel for tile, I guess:
>>
>>   - SPRs are in "arch/tile/include/uapi/arch/spr_def_64.h".
>>
>>   - SPRs are all 64-bit registers (I referenced the 'interrupt_mask' and
>>     CHIP_HAS_SPLIT_INTR_MASK to know about it).
>>
>> If what I guess is incorrect, please let me know. And welcome to provide
>> tilegx SPR related documents, too.
>>


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

On 2/17/15 08:11, Chris Metcalf wrote:
> On 2/16/2015 6:46 PM, Peter Maydell wrote:
>> On 17 February 2015 at 08:08, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
>>> On 2/16/15 23:24, Max Filippov wrote:
>>>> Disassembler is not a crucial part of QEMU target.
>>> For me, it is necessary. We need disassemble target binary instructions
>>> (recognize them), then translate them into tcg instructions which are
>>> grouped by Translate Block.
>> No, Max is correct. What QEMU calls the "disassembler" is just
>> used for debug logging: it is code that goes from target binary
>> instructions to printed display of assembly language instructions.
>> This is completely separate code from the code in target-*/translate.c
>> which decodes target binary instructions and emits TCG opcodes.
>> That code is generally called the translator or the decoder, and
>> it is always written from scratch specifically for QEMU. Don't
>> try to reuse code from binutils there.
> 
> The kernel disassembly that Chen Gang is looking at is basically just an
> instruction recognizer; it doesn't even include text strings for opcodes,
> for example.  But my guess is that it is exactly the right starting building
> block for decoding target binary instructions.
> 

Excuse me, I am not quite familiar with the GPL license, so I guess we
are misunderstanding with each other.

 - it is necessary to disassemble/decode target binary instructions.

 - I want to write the decoder in translate.c according to binutils/
   kernel disassembler (also need consider about "BFD_RELOC" and
   "!__KERNEL__ && !__LIBC__").

 - If I reference to binutils source code, I am not quite sure whether I
   break the license or not (is it illegal?).


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

On 2/17/15 10:48, Chen Gang S wrote:
> On 2/17/15 08:11, Chris Metcalf wrote:
>> On 2/16/2015 6:46 PM, Peter Maydell wrote:
>>> On 17 February 2015 at 08:08, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
>>>> On 2/16/15 23:24, Max Filippov wrote:
>>>>> Disassembler is not a crucial part of QEMU target.
>>>> For me, it is necessary. We need disassemble target binary instructions
>>>> (recognize them), then translate them into tcg instructions which are
>>>> grouped by Translate Block.
>>> No, Max is correct. What QEMU calls the "disassembler" is just
>>> used for debug logging: it is code that goes from target binary
>>> instructions to printed display of assembly language instructions.
>>> This is completely separate code from the code in target-*/translate.c
>>> which decodes target binary instructions and emits TCG opcodes.
>>> That code is generally called the translator or the decoder, and
>>> it is always written from scratch specifically for QEMU. Don't
>>> try to reuse code from binutils there.
>>
>> The kernel disassembly that Chen Gang is looking at is basically just an
>> instruction recognizer; it doesn't even include text strings for opcodes,
>> for example.  But my guess is that it is exactly the right starting building
>> block for decoding target binary instructions.
>>
> 
> Excuse me, I am not quite familiar with the GPL license, so I guess we
> are misunderstanding with each other.
> 
>  - it is necessary to disassemble/decode target binary instructions.
> 
>  - I want to write the decoder in translate.c according to binutils/
>    kernel disassembler (also need consider about "BFD_RELOC" and
>    "!__KERNEL__ && !__LIBC__").
> 
>  - If I reference to binutils source code, I am not quite sure whether I
>    break the license or not (is it illegal?).
> 

Originally, I really wanted to print the disassembly code, although I
knew it is optional (not necessary), just like all of you said (and
originally, I was not quite sure DISASM_ONLY, either).


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features

[Chen Gang S]

And of cause, it is not the excuse to let me stop:

 - I shall integrate binutils disassembler firstly in my own branch for
   the related test and learning.

 - According to binutils disassembler implementation, I shall write
   translate.c step by step.

 - After finish translate.c, I shall send related patch to qemu mailing
   list without binutils disassembler integration.

For me, I guess, it is legal.

Thanks.

On 2/17/15 11:11, Chen Gang S wrote:
> On 2/17/15 10:48, Chen Gang S wrote:
>> On 2/17/15 08:11, Chris Metcalf wrote:
>>> On 2/16/2015 6:46 PM, Peter Maydell wrote:
>>>> On 17 February 2015 at 08:08, Chen Gang S <gang.chen@sunrus.com.cn> wrote:
>>>>> On 2/16/15 23:24, Max Filippov wrote:
>>>>>> Disassembler is not a crucial part of QEMU target.
>>>>> For me, it is necessary. We need disassemble target binary instructions
>>>>> (recognize them), then translate them into tcg instructions which are
>>>>> grouped by Translate Block.
>>>> No, Max is correct. What QEMU calls the "disassembler" is just
>>>> used for debug logging: it is code that goes from target binary
>>>> instructions to printed display of assembly language instructions.
>>>> This is completely separate code from the code in target-*/translate.c
>>>> which decodes target binary instructions and emits TCG opcodes.
>>>> That code is generally called the translator or the decoder, and
>>>> it is always written from scratch specifically for QEMU. Don't
>>>> try to reuse code from binutils there.
>>>
>>> The kernel disassembly that Chen Gang is looking at is basically just an
>>> instruction recognizer; it doesn't even include text strings for opcodes,
>>> for example.  But my guess is that it is exactly the right starting building
>>> block for decoding target binary instructions.
>>>
>>
>> Excuse me, I am not quite familiar with the GPL license, so I guess we
>> are misunderstanding with each other.
>>
>>  - it is necessary to disassemble/decode target binary instructions.
>>
>>  - I want to write the decoder in translate.c according to binutils/
>>    kernel disassembler (also need consider about "BFD_RELOC" and
>>    "!__KERNEL__ && !__LIBC__").
>>
>>  - If I reference to binutils source code, I am not quite sure whether I
>>    break the license or not (is it illegal?).
>>
> 
> Originally, I really wanted to print the disassembly code, although I
> knew it is optional (not necessary), just like all of you said (and
> originally, I was not quite sure DISASM_ONLY, either).
> 
> 
> Thanks.
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Qemu-devel] [Consult] About SPRs information

[Chen Gang]

On 2/17/15 08:29, Chris Metcalf wrote:
> Yes, I think there is a bit less documentation on tilegx SPRs available.
> If this becomes a blocker for you, let me know and I will see if there is anything
> we can do about it.  Probably best to wait until you have made more progress
> on qemu before trying to make a case for it internally, though.
> 

Hello all:

Now, I am blocked at SPRs: "mtspr SPR_CMPEXCH_VALUE %r12", and trying to
solve it.

And welcome any ideas, suggestions and completions for it.

Thanks.

> On 2/15/2015 10:40 PM, Chen Gang S wrote:
>> Excuse me, I want to consult the related information about SPR.
>>
>> For SPRs (Special Purpose Register) under tilegx, I can not get related
>> documents (I only got the tilepro related document for SPR). After read
>> through the source code of Linux kernel for tile, I guess:
>>
>>   - SPRs are in "arch/tile/include/uapi/arch/spr_def_64.h".
>>
>>   - SPRs are all 64-bit registers (I referenced the 'interrupt_mask' and
>>     CHIP_HAS_SPLIT_INTR_MASK to know about it).
>>
>> If what I guess is incorrect, please let me know. And welcome to provide
>> tilegx SPR related documents, too.
>>
>> Thanks.
>>


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [Consult] About SPRs information

[Richard Henderson]

On 04/27/2015 02:12 PM, Chen Gang wrote:
> Now, I am blocked at SPRs: "mtspr SPR_CMPEXCH_VALUE %r12", and trying to
> solve it.

SPR_CMPEXCH_VALUE should be present in your cpu structure, should be a TCGv
like all of your other registers, and this expands to a simple move.

You will probably need to dispatch on the SPR number.  Some of these will be
normal moves to special register slots.  Some of these may require a function
call in order to handle the side effects.


r~

Re: [Qemu-devel] [Consult] About SPRs information

[Chen Gang]

On 4/28/15 06:04, Richard Henderson wrote:
> On 04/27/2015 02:12 PM, Chen Gang wrote:
>> Now, I am blocked at SPRs: "mtspr SPR_CMPEXCH_VALUE %r12", and trying to
>> solve it.
> 
> SPR_CMPEXCH_VALUE should be present in your cpu structure, should be a TCGv
> like all of your other registers, and this expands to a simple move.
> 
> You will probably need to dispatch on the SPR number.  Some of these will be
> normal moves to special register slots.  Some of these may require a function
> call in order to handle the side effects.
> 

OK, thank you very much.

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [Consult] About SPRs information

[Chen Gang]

On 4/29/15 04:19, Chen Gang wrote:
> On 4/28/15 06:04, Richard Henderson wrote:
>> On 04/27/2015 02:12 PM, Chen Gang wrote:
>>> Now, I am blocked at SPRs: "mtspr SPR_CMPEXCH_VALUE %r12", and trying to
>>> solve it.
>>
>> SPR_CMPEXCH_VALUE should be present in your cpu structure, should be a TCGv
>> like all of your other registers, and this expands to a simple move.
>>
>> You will probably need to dispatch on the SPR number.  Some of these will be
>> normal moves to special register slots.  Some of these may require a function
>> call in order to handle the side effects.
>>

After check the next instruction cmpexch which uses SPR_CMPEXCH_VALUE:

 - Do we need a lock for cmpexch spr? (I guess not)

 - Do we need the same lock within cmpexch instruction for reading
   cmpexch spr? (I guess not)

 - When each spr occurs, do we need end the current block just like
   branch/call instruction occurs? (I guess we need)


The related information for cmpexch instruction:

  Description

    Compare the 8-byte contents of the CmpValue SPR with the 8-byte
    value in memory at the address held in the first source register. If
    the values are not equal, then no memory operation is performed. If
    the values are equal, the 8-byte quantity from the second source
    register is written into memory at the address held in the first
    source register. In either case, the result of the instruc- tion is
    the value read from memory. The compare and write to memory are
    atomic and thus can be used for synchronization purposes. This
    instruction only operates for addresses aligned to a 8-byte boundary.
    Unaligned memory access causes an Unaligned Data Reference interrupt.

  Functional Description

        uint64_t memVal = memoryReadDoubleWord (rf[SrcA]);
        rf[Dest] = memVal;
        if (memVal == SPR[CmpValueSPR])
          memoryWriteDoubleWord (rf[SrcA], rf[SrcB]);
  

> 
> OK, thank you very much.
> 

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [Consult] About SPRs information

[Peter Maydell]

On 28 April 2015 at 22:32, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
> The related information for cmpexch instruction:
>
>   Description
>
>     Compare the 8-byte contents of the CmpValue SPR with the 8-byte
>     value in memory at the address held in the first source register. If
>     the values are not equal, then no memory operation is performed. If
>     the values are equal, the 8-byte quantity from the second source
>     register is written into memory at the address held in the first
>     source register. In either case, the result of the instruc- tion is
>     the value read from memory. The compare and write to memory are
>     atomic and thus can be used for synchronization purposes. This
>     instruction only operates for addresses aligned to a 8-byte boundary.
>     Unaligned memory access causes an Unaligned Data Reference interrupt.

I suggest you look at how existing CPUs handle this kind of
atomic operation.

I also suggest you stop adding implementations of *new* instructions
and concentrate on getting a basic set into shape for inclusion.
The more stuff you keep adding the bigger your patchset is going
to get and the harder it is going to get to review.

thanks
-- PMM

Re: [Qemu-devel] [Consult] About SPRs information

[Chen Gang]

On 4/29/15 05:43, Peter Maydell wrote:
> On 28 April 2015 at 22:32, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>> The related information for cmpexch instruction:
>>
>>   Description
>>
>>     Compare the 8-byte contents of the CmpValue SPR with the 8-byte
>>     value in memory at the address held in the first source register. If
>>     the values are not equal, then no memory operation is performed. If
>>     the values are equal, the 8-byte quantity from the second source
>>     register is written into memory at the address held in the first
>>     source register. In either case, the result of the instruc- tion is
>>     the value read from memory. The compare and write to memory are
>>     atomic and thus can be used for synchronization purposes. This
>>     instruction only operates for addresses aligned to a 8-byte boundary.
>>     Unaligned memory access causes an Unaligned Data Reference interrupt.
> 
> I suggest you look at how existing CPUs handle this kind of
> atomic operation.
> 

OK, thanks.

> I also suggest you stop adding implementations of *new* instructions
> and concentrate on getting a basic set into shape for inclusion.
> The more stuff you keep adding the bigger your patchset is going
> to get and the harder it is going to get to review.
> 

For me, current code is not quite much, and really easy enough. At
present I am still going smoothly (the issues are mainly about
understanding new instructions which I shall meet).

I still want to reach "display hello world" successfully (it does not
seem quite difficult to me), then reconstruct current code, and send
patch to upstream.

But sorry, it seems I can not finish it within this month (and I shall
try to finish within next month).


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [Consult] About SPRs information

[Chen Gang]

On 4/29/15 21:32, Chen Gang wrote:
> On 4/29/15 05:43, Peter Maydell wrote:
>> On 28 April 2015 at 22:32, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>>> The related information for cmpexch instruction:
>>>
>>>   Description
>>>
>>>     Compare the 8-byte contents of the CmpValue SPR with the 8-byte
>>>     value in memory at the address held in the first source register. If
>>>     the values are not equal, then no memory operation is performed. If
>>>     the values are equal, the 8-byte quantity from the second source
>>>     register is written into memory at the address held in the first
>>>     source register. In either case, the result of the instruc- tion is
>>>     the value read from memory. The compare and write to memory are
>>>     atomic and thus can be used for synchronization purposes. This
>>>     instruction only operates for addresses aligned to a 8-byte boundary.
>>>     Unaligned memory access causes an Unaligned Data Reference interrupt.
>>
>> I suggest you look at how existing CPUs handle this kind of
>> atomic operation.
>>

I finished cmpexch(), referenced to store_exclusive() in arm and alpha.
Hope what I have done is correct (I guess, it should be).

 - Save information about cmpexch (add additional variable in CPUState).

 - Generate an exception for it.

 - Process the related exception in main.c with start/end_exclusive()
   just like what alpha or arm has done.


Thanks.

> OK, thanks.
> 


>> I also suggest you stop adding implementations of *new* instructions
>> and concentrate on getting a basic set into shape for inclusion.
>> The more stuff you keep adding the bigger your patchset is going
>> to get and the harder it is going to get to review.
>>

Reconstruction the code is really very useful, cmp*, shl?add*, V?int_?.
That will not only simplify reading, but also speed up coding.

Thank you for your valuable suggestions again.

> 
> For me, current code is not quite much, and really easy enough. At
> present I am still going smoothly (the issues are mainly about
> understanding new instructions which I shall meet).
> 
> I still want to reach "display hello world" successfully (it does not
> seem quite difficult to me), then reconstruct current code, and send
> patch to upstream.
> 
> But sorry, it seems I can not finish it within this month (and I shall
> try to finish within next month).
> 
> 
> Thanks.
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [Consult] About SPRs information

[Chen Gang]

Hello all:

At present, I met an issue (I guess, it should be my code bug), I am
analyzing it which may spend quite a few time resources (checking and
reconstructing the code is helpful for analyzing this issue):

 - It is about invalid memory access for ld operation. The related
   tilegx code is "ld r48, r12", the related x86_64 code is
   "mov (%rbx),%rbx".

 - The related invalid address is 0x128020 which is near (but a little
   upper) tilegx rsp.

 - I have ways for analyzing it: we have the related libc source code,
   and the working flow is not quite complex. But it really needs to
   spend me quite a few time resources on it.

At present, for me, I plan to send the reconstructed code to upstream
within 2 days, and continue analyzing (so that other members can also
have a check), but I am not quite sure whether it is suitable.

Welcome any ideas, suggestions and completions.

Thanks.

On 5/2/15 10:42, Chen Gang wrote:
> 
> 
> On 4/29/15 21:32, Chen Gang wrote:
>> On 4/29/15 05:43, Peter Maydell wrote:
>>> On 28 April 2015 at 22:32, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>>>> The related information for cmpexch instruction:
>>>>
>>>>   Description
>>>>
>>>>     Compare the 8-byte contents of the CmpValue SPR with the 8-byte
>>>>     value in memory at the address held in the first source register. If
>>>>     the values are not equal, then no memory operation is performed. If
>>>>     the values are equal, the 8-byte quantity from the second source
>>>>     register is written into memory at the address held in the first
>>>>     source register. In either case, the result of the instruc- tion is
>>>>     the value read from memory. The compare and write to memory are
>>>>     atomic and thus can be used for synchronization purposes. This
>>>>     instruction only operates for addresses aligned to a 8-byte boundary.
>>>>     Unaligned memory access causes an Unaligned Data Reference interrupt.
>>>
>>> I suggest you look at how existing CPUs handle this kind of
>>> atomic operation.
>>>
> 
> I finished cmpexch(), referenced to store_exclusive() in arm and alpha.
> Hope what I have done is correct (I guess, it should be).
> 
>  - Save information about cmpexch (add additional variable in CPUState).
> 
>  - Generate an exception for it.
> 
>  - Process the related exception in main.c with start/end_exclusive()
>    just like what alpha or arm has done.
> 
> 
> Thanks.
> 
>> OK, thanks.
>>
> 
> 
>>> I also suggest you stop adding implementations of *new* instructions
>>> and concentrate on getting a basic set into shape for inclusion.
>>> The more stuff you keep adding the bigger your patchset is going
>>> to get and the harder it is going to get to review.
>>>
> 
> Reconstruction the code is really very useful, cmp*, shl?add*, V?int_?.
> That will not only simplify reading, but also speed up coding.
> 
> Thank you for your valuable suggestions again.
> 
>>
>> For me, current code is not quite much, and really easy enough. At
>> present I am still going smoothly (the issues are mainly about
>> understanding new instructions which I shall meet).
>>
>> I still want to reach "display hello world" successfully (it does not
>> seem quite difficult to me), then reconstruct current code, and send
>> patch to upstream.
>>
>> But sorry, it seems I can not finish it within this month (and I shall
>> try to finish within next month).
>>
>>
>> Thanks.
>>
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [Consult] About SPRs information

[Chen Gang]

After spend two days, I fix the issue below: I misunderstood v4int_l
instruction, so cause this issue.

At present, I met mf (memory fence), I guess, we can just skip it, but I
am not quite sure, welcome any ideas, suggestions and completions for it.

And I almost re-constructed the code (it doesn't change quite much), if
suitable, I shall try to send patches to upstream for reviewing. Welcome
any ideas, suggestions and completions for it.

Thanks.

On 5/2/15 12:09, Chen Gang wrote:
> Hello all:
> 
> At present, I met an issue (I guess, it should be my code bug), I am
> analyzing it which may spend quite a few time resources (checking and
> reconstructing the code is helpful for analyzing this issue):
> 
>  - It is about invalid memory access for ld operation. The related
>    tilegx code is "ld r48, r12", the related x86_64 code is
>    "mov (%rbx),%rbx".
> 
>  - The related invalid address is 0x128020 which is near (but a little
>    upper) tilegx rsp.
> 
>  - I have ways for analyzing it: we have the related libc source code,
>    and the working flow is not quite complex. But it really needs to
>    spend me quite a few time resources on it.
> 
> At present, for me, I plan to send the reconstructed code to upstream
> within 2 days, and continue analyzing (so that other members can also
> have a check), but I am not quite sure whether it is suitable.
> 
> Welcome any ideas, suggestions and completions.
> 
> Thanks.
> 
> On 5/2/15 10:42, Chen Gang wrote:
>>
>>
>> On 4/29/15 21:32, Chen Gang wrote:
>>> On 4/29/15 05:43, Peter Maydell wrote:
>>>> On 28 April 2015 at 22:32, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>>>>> The related information for cmpexch instruction:
>>>>>
>>>>>   Description
>>>>>
>>>>>     Compare the 8-byte contents of the CmpValue SPR with the 8-byte
>>>>>     value in memory at the address held in the first source register. If
>>>>>     the values are not equal, then no memory operation is performed. If
>>>>>     the values are equal, the 8-byte quantity from the second source
>>>>>     register is written into memory at the address held in the first
>>>>>     source register. In either case, the result of the instruc- tion is
>>>>>     the value read from memory. The compare and write to memory are
>>>>>     atomic and thus can be used for synchronization purposes. This
>>>>>     instruction only operates for addresses aligned to a 8-byte boundary.
>>>>>     Unaligned memory access causes an Unaligned Data Reference interrupt.
>>>>
>>>> I suggest you look at how existing CPUs handle this kind of
>>>> atomic operation.
>>>>
>>
>> I finished cmpexch(), referenced to store_exclusive() in arm and alpha.
>> Hope what I have done is correct (I guess, it should be).
>>
>>  - Save information about cmpexch (add additional variable in CPUState).
>>
>>  - Generate an exception for it.
>>
>>  - Process the related exception in main.c with start/end_exclusive()
>>    just like what alpha or arm has done.
>>
>>
>> Thanks.
>>
>>> OK, thanks.
>>>
>>
>>
>>>> I also suggest you stop adding implementations of *new* instructions
>>>> and concentrate on getting a basic set into shape for inclusion.
>>>> The more stuff you keep adding the bigger your patchset is going
>>>> to get and the harder it is going to get to review.
>>>>
>>
>> Reconstruction the code is really very useful, cmp*, shl?add*, V?int_?.
>> That will not only simplify reading, but also speed up coding.
>>
>> Thank you for your valuable suggestions again.
>>
>>>
>>> For me, current code is not quite much, and really easy enough. At
>>> present I am still going smoothly (the issues are mainly about
>>> understanding new instructions which I shall meet).
>>>
>>> I still want to reach "display hello world" successfully (it does not
>>> seem quite difficult to me), then reconstruct current code, and send
>>> patch to upstream.
>>>
>>> But sorry, it seems I can not finish it within this month (and I shall
>>> try to finish within next month).
>>>
>>>
>>> Thanks.
>>>
>>
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [Consult] About SPRs information

[Chen Gang]

Since no response, I assume that it is not suitable to send patches
before finish printing hello world successfully (when sending patches,
we should be sure of the patches are valuable enough).

And sorry, I delayed too much for developing tilegx qemu, next I shall
try to print hello world successfully and send patches within this
month.

Thanks.

On 5/3/15 22:30, Chen Gang wrote:
> 
> After spend two days, I fix the issue below: I misunderstood v4int_l
> instruction, so cause this issue.
> 
> At present, I met mf (memory fence), I guess, we can just skip it, but I
> am not quite sure, welcome any ideas, suggestions and completions for it.
> 
> And I almost re-constructed the code (it doesn't change quite much), if
> suitable, I shall try to send patches to upstream for reviewing. Welcome
> any ideas, suggestions and completions for it.
> 
> Thanks.
> 
> On 5/2/15 12:09, Chen Gang wrote:
>> Hello all:
>>
>> At present, I met an issue (I guess, it should be my code bug), I am
>> analyzing it which may spend quite a few time resources (checking and
>> reconstructing the code is helpful for analyzing this issue):
>>
>>  - It is about invalid memory access for ld operation. The related
>>    tilegx code is "ld r48, r12", the related x86_64 code is
>>    "mov (%rbx),%rbx".
>>
>>  - The related invalid address is 0x128020 which is near (but a little
>>    upper) tilegx rsp.
>>
>>  - I have ways for analyzing it: we have the related libc source code,
>>    and the working flow is not quite complex. But it really needs to
>>    spend me quite a few time resources on it.
>>
>> At present, for me, I plan to send the reconstructed code to upstream
>> within 2 days, and continue analyzing (so that other members can also
>> have a check), but I am not quite sure whether it is suitable.
>>
>> Welcome any ideas, suggestions and completions.
>>
>> Thanks.
>>
>> On 5/2/15 10:42, Chen Gang wrote:
>>>
>>>
>>> On 4/29/15 21:32, Chen Gang wrote:
>>>> On 4/29/15 05:43, Peter Maydell wrote:
>>>>> On 28 April 2015 at 22:32, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>>>>>> The related information for cmpexch instruction:
>>>>>>
>>>>>>   Description
>>>>>>
>>>>>>     Compare the 8-byte contents of the CmpValue SPR with the 8-byte
>>>>>>     value in memory at the address held in the first source register. If
>>>>>>     the values are not equal, then no memory operation is performed. If
>>>>>>     the values are equal, the 8-byte quantity from the second source
>>>>>>     register is written into memory at the address held in the first
>>>>>>     source register. In either case, the result of the instruc- tion is
>>>>>>     the value read from memory. The compare and write to memory are
>>>>>>     atomic and thus can be used for synchronization purposes. This
>>>>>>     instruction only operates for addresses aligned to a 8-byte boundary.
>>>>>>     Unaligned memory access causes an Unaligned Data Reference interrupt.
>>>>>
>>>>> I suggest you look at how existing CPUs handle this kind of
>>>>> atomic operation.
>>>>>
>>>
>>> I finished cmpexch(), referenced to store_exclusive() in arm and alpha.
>>> Hope what I have done is correct (I guess, it should be).
>>>
>>>  - Save information about cmpexch (add additional variable in CPUState).
>>>
>>>  - Generate an exception for it.
>>>
>>>  - Process the related exception in main.c with start/end_exclusive()
>>>    just like what alpha or arm has done.
>>>
>>>
>>> Thanks.
>>>
>>>> OK, thanks.
>>>>
>>>
>>>
>>>>> I also suggest you stop adding implementations of *new* instructions
>>>>> and concentrate on getting a basic set into shape for inclusion.
>>>>> The more stuff you keep adding the bigger your patchset is going
>>>>> to get and the harder it is going to get to review.
>>>>>
>>>
>>> Reconstruction the code is really very useful, cmp*, shl?add*, V?int_?.
>>> That will not only simplify reading, but also speed up coding.
>>>
>>> Thank you for your valuable suggestions again.
>>>
>>>>
>>>> For me, current code is not quite much, and really easy enough. At
>>>> present I am still going smoothly (the issues are mainly about
>>>> understanding new instructions which I shall meet).
>>>>
>>>> I still want to reach "display hello world" successfully (it does not
>>>> seem quite difficult to me), then reconstruct current code, and send
>>>> patch to upstream.
>>>>
>>>> But sorry, it seems I can not finish it within this month (and I shall
>>>> try to finish within next month).
>>>>
>>>>
>>>> Thanks.
>>>>
>>>
>>
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [Qemu-devel] [Consult] About SPRs information

[Peter Maydell]

On 7 May 2015 at 22:05, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>
> Since no response, I assume that it is not suitable to send patches
> before finish printing hello world successfully (when sending patches,
> we should be sure of the patches are valuable enough).

Er, I said you should send patches earlier rather than later.
The longer you hold on to them without sending them the bigger
the patchset will get and the more rework you may need to do
if there are review comments that suggest significant
refactoring.

-- PMM

Re: [Qemu-devel] [Consult] About SPRs information

[Chen Gang]

On 5/8/15 11:14, Peter Maydell wrote:
> On 7 May 2015 at 22:05, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>>
>> Since no response, I assume that it is not suitable to send patches
>> before finish printing hello world successfully (when sending patches,
>> we should be sure of the patches are valuable enough).
> 
> Er, I said you should send patches earlier rather than later.
> The longer you hold on to them without sending them the bigger
> the patchset will get and the more rework you may need to do
> if there are review comments that suggest significant
> refactoring.
> 

OK, I shall send patches within 2 days (2015-05-10), and continue.

At present, it still has bug (it will cause assert in _init_malloc, then
quit). It doesn't seem quite difficult for me to fix it, but it really
needs additional time resources.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed