Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
> My use case here is testing and debugging, so I think we could live with > the blocks being executed in an interleaved fashion until someone has > the ultimate parallelization solution for upstream. So you prefer parallelizing QEMU itself in your case? -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH] target-arm: Tidy up ARM1136 CPUID naming
Am 03.10.2011 12:32, schrieb Andreas Färber:
> -cpu arm1136-r2 is commented to in fact be ARM1136 r0p2, whereas
> -cpu arm1136 seems to be ARM1136 r1p3 according to the MIDR value.
>
> The CPUID values contain major and minor revision numbers (rnpn) and
> are never used with a mask, so are specific to the chosen revision.
> Rename the CPUID preprocessor defines to reflect this, but leave the
> CPU model names unchanged for command line compatibility.
>
> Cc: Andrzej Zaborowski
> Cc: Peter Maydell
> Signed-off-by: Andreas Färber
> ---
Ping?
Andreas
> target-arm/cpu.h|4 ++--
> target-arm/helper.c | 12 ++--
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 6ab780d..783989f 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -419,8 +419,8 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
> #define ARM_CPUID_PXA270_B1 0x69054113
> #define ARM_CPUID_PXA270_C0 0x69054114
> #define ARM_CPUID_PXA270_C5 0x69054117
> -#define ARM_CPUID_ARM1136 0x4117b363
> -#define ARM_CPUID_ARM1136_R2 0x4107b362
> +#define ARM_CPUID_ARM1136_R1P3 0x4117b363
> +#define ARM_CPUID_ARM1136_R0P2 0x4107b362
> #define ARM_CPUID_ARM1176 0x410fb767
> #define ARM_CPUID_ARM11MPCORE 0x410fb022
> #define ARM_CPUID_CORTEXA80x410fc080
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index e2428eb..0d342ba 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -76,11 +76,11 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
> id)
> env->cp15.c0_cachetype = 0x1dd20d2;
> env->cp15.c1_sys = 0x00090078;
> break;
> -case ARM_CPUID_ARM1136:
> +case ARM_CPUID_ARM1136_R1P3:
> /* This is the 1136 r1, which is a v6K core */
> set_feature(env, ARM_FEATURE_V6K);
> /* Fall through */
> -case ARM_CPUID_ARM1136_R2:
> +case ARM_CPUID_ARM1136_R0P2:
> /* What qemu calls "arm1136_r2" is actually the 1136 r0p2, ie an
> * older core than plain "arm1136". In particular this does not
> * have the v6K features.
> @@ -417,8 +417,8 @@ static const struct arm_cpu_t arm_cpu_names[] = {
> { ARM_CPUID_ARM926, "arm926"},
> { ARM_CPUID_ARM946, "arm946"},
> { ARM_CPUID_ARM1026, "arm1026"},
> -{ ARM_CPUID_ARM1136, "arm1136"},
> -{ ARM_CPUID_ARM1136_R2, "arm1136-r2"},
> +{ ARM_CPUID_ARM1136_R1P3, "arm1136" },
> +{ ARM_CPUID_ARM1136_R0P2, "arm1136-r2" },
> { ARM_CPUID_ARM1176, "arm1176"},
> { ARM_CPUID_ARM11MPCORE, "arm11mpcore"},
> { ARM_CPUID_CORTEXM3, "cortex-m3"},
> @@ -1886,8 +1886,8 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
> switch (ARM_CPUID(env)) {
> case ARM_CPUID_ARM1026:
> return 1;
> -case ARM_CPUID_ARM1136:
> -case ARM_CPUID_ARM1136_R2:
> +case ARM_CPUID_ARM1136_R1P3:
> +case ARM_CPUID_ARM1136_R0P2:
> case ARM_CPUID_ARM1176:
> return 7;
> case ARM_CPUID_ARM11MPCORE:
Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
On 21 October 2011 23:05, Andreas Färber wrote: > Am 21.10.2011 08:58, schrieb Peter Maydell: >> (For several >> of the ARM boards we currently just ignore the fact that the real >> h/w has a Cortex-M3 doing power management type stuff.) > > Mind to share which boards? I'm only aware of the NXP LPC43xx asymmetric > SoC (Cortex-M4 + Cortex-M0), which still is in development stage. I had in mind the Versatile Express -- the main core is an A9x4 but there is also an M3 on the board. (There are some other interestng ARM based heterogeneous architectures coming up too, like the nVidia Tegra3 with 4xA9+1xA9, and the ARM big.LITTLE systems with 4xA7+4xA15.) > The > datasheet doesn't really enlighten me how such a combo is supposed to > work in shared memory: Do all ARM cores share a reset vector (or what > you call it on arm) so that one has to branch based on CPUID to do > different tasks on different cores? In general a multicore bootup will use the core ID to figure out what it is at reset. I don't know what a multicluster system would do, but probably the same thing. The other approach I've seen is that you can give the two CPUs different memory maps so they share most things but have different memory layouts where the vector table/startup code is. Or you could have the power controller hold the secondary core in reset until the primary core has booted, and have your boot code work differently for first and second execution, I guess. (The reset architecture on M profile and AR profiles is different, but I don't think the differences are important for these purposes.) -- PMM
Re: [Qemu-devel] [PATCH] target-arm: Tidy up ARM1136 CPUID naming
On 3 October 2011 11:32, Andreas Färber wrote: > -#define ARM_CPUID_ARM1136 0x4117b363 > -#define ARM_CPUID_ARM1136_R2 0x4107b362 > +#define ARM_CPUID_ARM1136_R1P3 0x4117b363 > +#define ARM_CPUID_ARM1136_R0P2 0x4107b362 I don't think the patchlevels are important enough to memorialise in the constant names. The important distinction in behaviour is between the r0 and r1, so I think that ARM1136_R0 vs _R1 would be better. -- PMM
[Qemu-devel] [PATCH v3 2/6] target-mips:enabling of 64 bit user mode and floating point operations
From: Khansa Butt
Signed-off-by: Khansa Butt
---
target-mips/translate.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index d5b1c76..0550333 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -12779,6 +12779,8 @@ void cpu_reset (CPUMIPSState *env)
env->hflags |= MIPS_HFLAG_FPU;
}
#ifdef TARGET_MIPS64
+env->hflags |= MIPS_HFLAG_UX;
+env->active_fpu.fcr0 = env->cpu_model->CP1_fcr0;
if (env->active_fpu.fcr0 & (1 << FCR0_F64)) {
env->hflags |= MIPS_HFLAG_F64;
}
--
1.7.3.4
[Qemu-devel] [PATCH v3 3/6] linux-user:Signal handling for MIPS64
From: Khansa Butt
Signed-off-by: Khansa Butt
---
linux-user/signal.c | 438 +--
1 files changed, 426 insertions(+), 12 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 59c3c88..f5f8bba 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -30,6 +30,8 @@
#include "qemu-common.h"
#include "target_signal.h"
+int sigrt;
+
//#define DEBUG_SIGNAL
static struct target_sigaltstack target_sigaltstack_used = {
@@ -596,7 +598,11 @@ int do_sigaction(int sig, const struct target_sigaction
*act,
if (act) {
/* FIXME: This is not threadsafe. */
k->_sa_handler = tswapl(act->_sa_handler);
+#if defined(TARGET_MIPS64)
+k->sa_flags = bswap32(act->sa_flags);
+#else
k->sa_flags = tswapl(act->sa_flags);
+#endif
#if !defined(TARGET_MIPS)
k->sa_restorer = tswapl(act->sa_restorer);
#endif
@@ -2415,29 +2421,435 @@ void sparc64_get_context(CPUSPARCState *env)
#endif
#elif defined(TARGET_ABI_MIPSN64)
+struct target_sigcontext {
+uint32_t sc_regmask; /* Unused */
+uint32_t sc_status;
+uint64_t sc_pc;
+uint64_t sc_regs[32];
+uint64_t sc_fpregs[32];
+uint32_t sc_ownedfp; /* Unused */
+uint32_t sc_fpc_csr;
+uint32_t sc_fpc_eir; /* Unused */
+uint32_t sc_used_math;
+uint32_t sc_dsp; /* dsp status, was sc_ssflags */
+uint32_t pad0;
+uint64_t sc_mdhi;
+uint64_t sc_mdlo;
+target_ulong sc_hi1; /* Was sc_cause */
+target_ulong sc_lo1; /* Was sc_badvaddr */
+target_ulong sc_hi2; /* Was sc_sigset[4] */
+target_ulong sc_lo2;
+target_ulong sc_hi3;
+target_ulong sc_lo3;
+};
+
+struct sigframe {
+uint32_t sf_ass[4]; /* argument save space for o32 */
+uint32_t sf_code[2];/* signal trampoline */
+struct target_sigcontext sf_sc;
+target_sigset_t sf_mask;
+};
+
+struct target_ucontext {
+target_ulong tuc_flags;
+target_ulong tuc_link;
+target_stack_t tuc_stack;
+target_ulong pad0;
+struct target_sigcontext tuc_mcontext;
+target_sigset_t tuc_sigmask;
+};
+
+struct target_rt_sigframe {
+uint32_t rs_ass[4]; /* argument save space for o32 */
+uint32_t rs_code[2]; /* signal trampoline */
+struct target_siginfo rs_info;
+struct target_ucontext rs_uc;
+};
+
+/* Install trampoline to jump back from signal handler */
+static inline int install_sigtramp(unsigned int *tramp, unsigned int syscall)
+{
+int err;
+
+/*
+ * Set up the return code ...
+ *
+ * li v0, __NR__foo_sigreturn
+ * syscall
+ */
+
+err = __put_user(0x2402 + syscall, tramp + 0);
+err |= __put_user(0x000c , tramp + 1);
+/* flush_cache_sigtramp((unsigned long) tramp); */
+return err;
+}
+
+static inline int
+setup_sigcontext(CPUState *regs, struct target_sigcontext *sc)
+{
+int err = 0;
+
+err |= __put_user(regs->active_tc.PC, &sc->sc_pc);
+
+#define save_gp_reg(i) do { \
+err |= __put_user(regs->active_tc.gpr[i], &sc->sc_regs[i]); \
+} while (0)
+__put_user(0, &sc->sc_regs[0]); save_gp_reg(1); save_gp_reg(2);
+save_gp_reg(3); save_gp_reg(4); save_gp_reg(5); save_gp_reg(6);
+save_gp_reg(7); save_gp_reg(8); save_gp_reg(9); save_gp_reg(10);
+save_gp_reg(11); save_gp_reg(12); save_gp_reg(13); save_gp_reg(14);
+save_gp_reg(15); save_gp_reg(16); save_gp_reg(17); save_gp_reg(18);
+save_gp_reg(19); save_gp_reg(20); save_gp_reg(21); save_gp_reg(22);
+save_gp_reg(23); save_gp_reg(24); save_gp_reg(25); save_gp_reg(26);
+save_gp_reg(27); save_gp_reg(28); save_gp_reg(29); save_gp_reg(30);
+save_gp_reg(31);
+#undef save_gp_reg
+
+err |= __put_user(regs->active_tc.HI[0], &sc->sc_mdhi);
+err |= __put_user(regs->active_tc.LO[0], &sc->sc_mdlo);
+
+/* Not used yet, but might be useful if we ever have DSP suppport */
+#if 0
+if (cpu_has_dsp) {
+err |= __put_user(mfhi1(), &sc->sc_hi1);
+err |= __put_user(mflo1(), &sc->sc_lo1);
+err |= __put_user(mfhi2(), &sc->sc_hi2);
+err |= __put_user(mflo2(), &sc->sc_lo2);
+err |= __put_user(mfhi3(), &sc->sc_hi3);
+err |= __put_user(mflo3(), &sc->sc_lo3);
+err |= __put_user(rddsp(DSP_MASK), &sc->sc_dsp);
+}
+/* same with 64 bit */
+#ifdef CONFIG_64BIT
+err |= __put_user(regs->hi, &sc->sc_hi[0]);
+err |= __put_user(regs->lo, &sc->sc_lo[0]);
+if (cpu_has_dsp) {
+err |= __put_user(mfhi1(), &sc->sc_hi[1]);
+err |= __put_user(mflo1(), &sc->sc_lo[1]);
+err |= __put_user(mfhi2(), &sc->sc_hi[2]);
+err |= __put_user(mflo2(), &sc->sc_lo[2]);
+err |= __put_user(mfhi3(), &sc->sc_hi[3]);
+err |= __put_user(mflo3(), &sc->sc_lo[3]);
+err |= __put_user(rddsp(DSP_MASK), &sc->sc_dsp);
+}
+#
[Qemu-devel] [PATCH v3 1/6] linux-user:Support for MIPS64 user mode emulation in QEMU
From: Khansa Butt
Signed-off-by: Khansa Butt
---
configure |1 +
default-configs/mips64-linux-user.mak |1 +
linux-user/main.c | 21 +++--
linux-user/mips64/syscall.h |2 ++
linux-user/signal.c |2 --
5 files changed, 23 insertions(+), 4 deletions(-)
create mode 100644 default-configs/mips64-linux-user.mak
diff --git a/configure b/configure
index 9ab3ab4..5e45a43 100755
--- a/configure
+++ b/configure
@@ -891,6 +891,7 @@ m68k-linux-user \
microblaze-linux-user \
microblazeel-linux-user \
mips-linux-user \
+mips64-linux-user \
mipsel-linux-user \
ppc-linux-user \
ppc64-linux-user \
diff --git a/default-configs/mips64-linux-user.mak
b/default-configs/mips64-linux-user.mak
new file mode 100644
index 000..1598bfc
--- /dev/null
+++ b/default-configs/mips64-linux-user.mak
@@ -0,0 +1 @@
+# Default configuration for mips64-linux-user
diff --git a/linux-user/main.c b/linux-user/main.c
index 89a51d7..1cc564d 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2068,7 +2068,8 @@ static int do_store_exclusive(CPUMIPSState *env)
void cpu_loop(CPUMIPSState *env)
{
target_siginfo_t info;
-int trapnr, ret;
+int trapnr;
+abi_long ret;
unsigned int syscall_num;
for(;;) {
@@ -2077,8 +2078,23 @@ void cpu_loop(CPUMIPSState *env)
cpu_exec_end(env);
switch(trapnr) {
case EXCP_SYSCALL:
-syscall_num = env->active_tc.gpr[2] - 4000;
env->active_tc.PC += 4;
+#if defined(TARGET_MIPS64)
+syscall_num = env->active_tc.gpr[2] - 5000;
+/* MIPS64 has eight argument registers so there is
+ * no need to get arguments from stack
+ */
+ret = do_syscall(env, env->active_tc.gpr[2],
+ env->active_tc.gpr[4],
+ env->active_tc.gpr[5],
+ env->active_tc.gpr[6],
+ env->active_tc.gpr[7],
+ env->active_tc.gpr[8],
+ env->active_tc.gpr[9],
+ env->active_tc.gpr[10],
+ env->active_tc.gpr[11]);
+#else
+syscall_num = env->active_tc.gpr[2] - 4000;
if (syscall_num >= sizeof(mips_syscall_args)) {
ret = -TARGET_ENOSYS;
} else {
@@ -2105,6 +2121,7 @@ void cpu_loop(CPUMIPSState *env)
env->active_tc.gpr[7],
arg5, arg6, arg7, arg8);
}
+#endif
if (ret == -TARGET_QEMU_ESIGRETURN) {
/* Returning from a successful sigreturn syscall.
Avoid clobbering register state. */
diff --git a/linux-user/mips64/syscall.h b/linux-user/mips64/syscall.h
index 668a2b9..96f03da 100644
--- a/linux-user/mips64/syscall.h
+++ b/linux-user/mips64/syscall.h
@@ -218,4 +218,6 @@ struct target_pt_regs {
+#define TARGET_QEMU_ESIGRETURN 255
+
#define UNAME_MACHINE "mips64"
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 89276eb..59c3c88 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2415,8 +2415,6 @@ void sparc64_get_context(CPUSPARCState *env)
#endif
#elif defined(TARGET_ABI_MIPSN64)
-# warning signal handling not implemented
-
static void setup_frame(int sig, struct target_sigaction *ka,
target_sigset_t *set, CPUState *env)
{
--
1.7.3.4
[Qemu-devel] [PATCH v3 6/6] Addition of Cavium instructions in disassembler
From: Khansa Butt
Signed-off-by: Khansa Butt
---
mips-dis.c | 53 +
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/mips-dis.c b/mips-dis.c
index e3a6e0b..96ab1e8 100644
--- a/mips-dis.c
+++ b/mips-dis.c
@@ -300,6 +300,7 @@ struct mips_opcode
Also used for immediate operands in vr5400 vector insns.
"o" 16 bit signed offset (OP_*_DELTA)
"p" 16 bit PC relative branch target address (OP_*_DELTA)
+ "+p" 5 bit unsigned constant describing bit position, for Octeon (OP_*_RT)
"q" 10 bit extra breakpoint code (OP_*_CODE2)
"r" 5 bit same register used as both source and target (OP_*_RS)
"s" 5 bit source register specifier (OP_*_RS)
@@ -491,6 +492,13 @@ struct mips_opcode
#define INSN_MULT 0x4000
/* Instruction synchronize shared memory. */
#define INSN_SYNC 0x8000
+/* Load Cavium specific multiplier registers. */
+#define INSN_WRITE_MPL0 0x1
+#define INSN_WRITE_MPL1 0x2
+#define INSN_WRITE_MPL2 0x4
+#define INSN_WRITE_P0 0x8
+#define INSN_WRITE_P1 0x10
+#define INSN_WRITE_P2 0x20
/* These are the bits which may be set in the pinfo2 field of an
instruction. */
@@ -569,6 +577,8 @@ struct mips_opcode
#define INSN_LOONGSON_2E 0x4000
/* ST Microelectronics Loongson 2F. */
#define INSN_LOONGSON_2F 0x8000
+/* Cavium Network's Octeon processor */
+#define INSN_CVM_OCTEON 0x1
/* MIPS ISA defines, use instead of hardcoding ISA level. */
@@ -1099,6 +1109,13 @@ extern const int bfd_mips16_num_opcodes;
#define RD_HI INSN_READ_HI
#define MOD_HI WR_HI|RD_HI
+#define WR_MPL0 INSN_WRITE_MPL0
+#define WR_MPL1 INSN_WRITE_MPL1
+#define WR_MPL2 INSN_WRITE_MPL2
+#define WR_P0 INSN_WRITE_P0
+#define WR_P1 INSN_WRITE_P1
+#define WR_P2 INSN_WRITE_P2
+
#define WR_LO INSN_WRITE_LO
#define RD_LO INSN_READ_LO
#define MOD_LO WR_LO|RD_LO
@@ -1137,6 +1154,8 @@ extern const int bfd_mips16_num_opcodes;
#define IL2E (INSN_LOONGSON_2E)
#define IL2F (INSN_LOONGSON_2F)
+#define ICVM(INSN_CVM_OCTEON)
+
#define P3 INSN_4650
#define L1 INSN_4010
#define V1 (INSN_4100 | INSN_4111 | INSN_4120)
@@ -2435,6 +2454,34 @@ const struct mips_opcode mips_builtin_opcodes[] =
{"cop1", "C", 0,(int) M_COP1, INSN_MACRO, 0,
I1 },
{"cop2", "C", 0,(int) M_COP2, INSN_MACRO, 0,
I1 },
{"cop3", "C", 0,(int) M_COP3, INSN_MACRO, 0,
I1 },
+/* Cavium specific instructions */
+{"baddu", "d,s,t",0x7028, 0xfc0007ff, RD_s|RD_t|WR_d, 0, ICVM},
+{"dmul","d,s,t",0x7003, 0xfc0007ff, RD_s|RD_t|WR_d, 0, ICVM},
+{"v3mulu", "d,s,t",0x7011, 0xfc0007ff, RD_s|RD_t|WR_d, 0, ICVM},
+{"vmm0","d,s,t",0x7010, 0xfc0007ff, RD_s|RD_t|WR_d, 0, ICVM},
+{"vmulu", "d,s,t",0x700f, 0xfc0007ff, RD_s|RD_t|WR_d, 0, ICVM},
+{"seq", "d,s,t",0x702a, 0xfc0007ff, RD_s|RD_t|WR_d, 0, ICVM},
+{"seqi", "t,r,j", 0x702e, 0xfc3f, WR_t|RD_s, 0, ICVM},
+{"sne", "d,s,t",0x702b, 0xfc0007ff, RD_s|RD_t|WR_d, 0, ICVM},
+{"snei","t,r,j",0x702f, 0xfc3f, WR_t|RD_s, 0, ICVM},
+{"bbit0","s,+p,p", 0xc800, 0xfc00, CBD|RD_s, 0, ICVM},
+{"bbit032","s,+p,p", 0xd800, 0xfc00, CBD|RD_s, 0, ICVM},
+{"bbit1","s,+p,p", 0xe800, 0xfc00, CBD|RD_s, 0, ICVM},
+{"bbit132","s,+p,p", 0xf800, 0xfc00, CBD|RD_s, 0, ICVM},
+{"saa","t,(b)", 0x7018, 0xfc00, SM|RD_t|RD_b,0, ICVM},
+{"saad", "t,(b)", 0x7019, 0xfc00, SM|RD_t|RD_b,0, ICVM},
+{"exts", "t,r,+A,+C", 0x703a, 0xfc3f, WR_t|RD_s, 0, ICVM},
+{"exts32", "t,r,+A,+C", 0x7c3b, 0xfc3f, WR_t|RD_s, 0, ICVM},
+{"cins", "t,r,+A,+B", 0x7032, 0xfc3f, WR_t|RD_s, 0, ICVM},
+{"cins32", "t,r,+A,+B", 0x7033, 0xfc3f, WR_t|RD_s, 0, ICVM},
+{"mtm0","s",0x7008, 0xfc1f, RD_s|WR_MPL0, 0, ICVM},
+{"mtm1","s",0x700c, 0xfc1f, RD_s|WR_MPL1, 0, ICVM},
+{"mtm2","s",0x700d, 0xfc1f, RD_s|WR_MPL2, 0, ICVM},
+{"mtp0","s",0x7009, 0xfc1f, RD_s|WR_P0, 0, ICVM},
+{"mtp1","s",0x700a, 0xfc1f, RD_s|WR_P1, 0, ICVM},
+{"mtp2","s",0x700b, 0xfc1f, RD_s|WR_P2, 0, ICVM},
+{"dpop","d,s", 0x702d, 0xfc1f07ff, RD_s|WR_d, 0, ICVM},
+{"pop", "d,s", 0x702c, 0xfc1f07ff, RD_s|WR_d, 0, ICVM},
/* Conflicts with the 4650's "mul" instruction. Nobody's using the
Re: [Qemu-devel] [PATCH] target-arm: Tidy up ARM1136 CPUID naming
Am 22.10.2011 12:20, schrieb Peter Maydell: > On 3 October 2011 11:32, Andreas Färber wrote: >> -#define ARM_CPUID_ARM1136 0x4117b363 >> -#define ARM_CPUID_ARM1136_R2 0x4107b362 >> +#define ARM_CPUID_ARM1136_R1P3 0x4117b363 >> +#define ARM_CPUID_ARM1136_R0P2 0x4107b362 > > I don't think the patchlevels are important enough to > memorialise in the constant names. The important > distinction in behaviour is between the r0 and r1, so > I think that ARM1136_R0 vs _R1 would be better. Would you be okay if we do the following? #define ARM_CPUID_ARM1136_R0 ARM_CPUID_ARM1136_R0P2 #define ARM_CPUID_ARM1136_R1 ARM_CPUID_ARM1136_R1P3 My point is that the number is actually hardcoded in there, whatever we name the constant. ARM1136 or ARM1136_R0 gives the impression of a more generic value. Masking would be the only way to have generic code there and I still haven't figured out how to do that sensibly without breaking up the whole switch. For now I have a patch cooking for CPUID preservation that I'll submit shortly. Andreas
[Qemu-devel] [PATCH v3 5/6] target-mips: Adding support for Cavium specific instructions
From: Khansa Butt
Signed-off-by: Khansa Butt
Signed-off-by: Ehsan Ul Haq
Signed-off-by: Abdul Qadeer
Signed-off-by: Abdul Waheed
---
target-mips/cpu.h |7 +
target-mips/helper.h|5 +
target-mips/machine.c | 12 ++
target-mips/op_helper.c | 73
target-mips/translate.c | 428 ++-
5 files changed, 520 insertions(+), 5 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 79e2558..9180ee9 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -173,6 +173,13 @@ struct TCState {
target_ulong CP0_TCSchedule;
target_ulong CP0_TCScheFBack;
int32_t CP0_Debug_tcstatus;
+/* Multiplier registers for Octeon */
+target_ulong MPL0;
+target_ulong MPL1;
+target_ulong MPL2;
+target_ulong P0;
+target_ulong P1;
+target_ulong P2;
};
typedef struct CPUMIPSState CPUMIPSState;
diff --git a/target-mips/helper.h b/target-mips/helper.h
index 442f684..7ba5d9f 100644
--- a/target-mips/helper.h
+++ b/target-mips/helper.h
@@ -8,7 +8,12 @@ DEF_HELPER_3(ldl, tl, tl, tl, int)
DEF_HELPER_3(ldr, tl, tl, tl, int)
DEF_HELPER_3(sdl, void, tl, tl, int)
DEF_HELPER_3(sdr, void, tl, tl, int)
+DEF_HELPER_2(v3mulu, tl, tl, tl)
+DEF_HELPER_2(vmulu, tl, tl, tl)
+DEF_HELPER_1(dpop, tl, tl)
#endif
+DEF_HELPER_1(pop, tl, tl)
+
DEF_HELPER_3(lwl, tl, tl, tl, int)
DEF_HELPER_3(lwr, tl, tl, tl, int)
DEF_HELPER_3(swl, void, tl, tl, int)
diff --git a/target-mips/machine.c b/target-mips/machine.c
index be72b36..a274ce2 100644
--- a/target-mips/machine.c
+++ b/target-mips/machine.c
@@ -25,6 +25,12 @@ static void save_tc(QEMUFile *f, TCState *tc)
qemu_put_betls(f, &tc->CP0_TCSchedule);
qemu_put_betls(f, &tc->CP0_TCScheFBack);
qemu_put_sbe32s(f, &tc->CP0_Debug_tcstatus);
+qemu_put_betls(f, &tc->MPL0);
+qemu_put_betls(f, &tc->MPL1);
+qemu_put_betls(f, &tc->P0);
+qemu_put_betls(f, &tc->P1);
+qemu_put_betls(f, &tc->P2);
+
}
static void save_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
@@ -173,6 +179,12 @@ static void load_tc(QEMUFile *f, TCState *tc)
qemu_get_betls(f, &tc->CP0_TCSchedule);
qemu_get_betls(f, &tc->CP0_TCScheFBack);
qemu_get_sbe32s(f, &tc->CP0_Debug_tcstatus);
+qemu_get_betls(f, &tc->MPL0);
+qemu_get_betls(f, &tc->MPL1);
+qemu_get_betls(f, &tc->MPL2);
+qemu_get_betls(f, &tc->P0);
+qemu_get_betls(f, &tc->P1);
+qemu_get_betls(f, &tc->P2);
}
static void load_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index 96e40c6..4565d17 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -320,8 +320,81 @@ void helper_dmultu (target_ulong arg1, target_ulong arg2)
{
mulu64(&(env->active_tc.LO[0]), &(env->active_tc.HI[0]), arg1, arg2);
}
+
+static void addc(uint64_t res[], uint64_t a, int i)
+{
+uint64_t c = res[i];
+for (; i < 4; i++) {
+res[i] = c + a;
+if (res[i] < a) {
+c = 1;
+a = res[i+1];
+} else {
+break;
+}
+}
+}
+
+target_ulong helper_v3mulu(target_ulong arg1, target_ulong arg2)
+{
+uint64_t hi, lo, res[4];
+int i;
+for (i = 0; i < 4; i++) {
+res[i] = 0;
+}
+mulu64(&res[0], &res[1], env->active_tc.MPL0, arg1);
+mulu64(&lo, &hi, env->active_tc.MPL1, arg1);
+res[1] = res[1] + lo;
+if (res[1] < lo) {
+res[2]++;
+}
+res[2] = res[2] + hi;
+if (res[2] < hi) {
+res[3]++;
+}
+mulu64(&lo, &hi, env->active_tc.MPL2, arg1);
+res[2] = res[2] + lo;
+if (res[2] < lo) {
+res[3]++;
+}
+res[3] = res[3] + hi;
+addc(res, arg2, 0);
+addc(res, env->active_tc.P0, 0);
+addc(res, env->active_tc.P1, 1);
+addc(res, env->active_tc.P2, 2);
+env->active_tc.P0 = res[1];
+env->active_tc.P1 = res[2];
+env->active_tc.P2 = res[3];
+return res[0];
+}
+
+target_ulong helper_vmulu(target_ulong arg1, target_ulong arg2)
+{
+uint64_t hi, lo;
+mulu64(&lo, &hi, env->active_tc.MPL0, arg1);
+lo = lo + arg2;
+if (lo < arg2) {
+hi++;
+}
+lo = lo + env->active_tc.P0;
+if (lo < env->active_tc.P0) {
+hi++;
+}
+env->active_tc.P0 = hi;
+return lo;
+}
+
+target_ulong helper_dpop(target_ulong arg)
+{
+return ctpop64(arg);
+}
#endif
+target_ulong helper_pop(target_ulong arg)
+{
+return ctpop32((uint32_t)arg);
+}
+
#ifndef CONFIG_USER_ONLY
static inline target_phys_addr_t do_translate_address(target_ulong address,
int rw)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 0550333..e57f3fe 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -78,6 +78,11 @@ enum {
OPC_BGTZL= (0x17 << 26),
OPC_JALX = (0x1D << 26), /* MIPS 16 only */
OPC_JALXS= OPC_JALX | 0x5,
+/* Cavium Specific branches */
+OPC_BBIT1= (0x3a << 26), /* jump on bit set */
+OPC_BBIT
[Qemu-devel] [PATCH v3 0/6] MIPS64 user mode emulation in QEMU with Cavium specific instruction support
From: Khansa Butt This is the team work of Ehsan-ul-Haq, Abdul Qadeer, Abdul Waheed, Khansa Butt from HPCN Lab KICS UET Lahore. Sorry Richard! gen_set was missed. v1 contains: * SEQI and SEQ related changes specified by Richard Henderson * Fix issues related to coding style, typos and misleading comments * Cavium specific change in set_thread_area syscall has been removed * as it corresponds to modified libc and kernel. This Patch series add support of MIPS64 user mode emulation in QEMU. Along with we implemented Cavium specific instructions which We will use in SME (in sysem mode emulation of Octeon processor) If you have any objection regarding the Implementation of Cavium instructions please read following notes. Notes * The detail of some instructions are as follows 1)seq rd,rs,rt seq-->rd = 1 if rs = rt is equivalent to xor rd,rs,rt sltiu rd,rd,1 2)exts rt,rs,p,lenm1 rt = sign-extend(rs,lenm1) >From reference manual of Cavium Networks "Bit locations p + lenm1 to p are extracted from rs and the result is written into the lowest bits of destination register rt. The remaining bits in rt are a sign-extension of the most-significant bit of the bit field (i.e. rt<63:lenm1> are all duplicates of the source-register bit rs)." so we can't use any of 8,16 or 32 bit sign extention tcg function. To sign extend according to msb of bit field we have our own implementation 3)dmul rd,rs,rt This instruction is included in gen_arith() because it is three operand double word multiply instruction. configure |1 + default-configs/mips64-linux-user.mak |1 + linux-user/main.c | 21 ++- linux-user/mips64/syscall.h |2 + linux-user/signal.c | 438 - mips-dis.c| 53 target-mips/cpu.h |7 + target-mips/helper.h |5 + target-mips/machine.c | 12 + target-mips/mips-defs.h |2 + target-mips/op_helper.c | 73 ++ target-mips/translate.c | 430 - target-mips/translate_init.c | 24 ++ 13 files changed, 1049 insertions(+), 20 deletions(-) create mode 100644 default-configs/mips64-linux-user.mak -- 1.7.3.4
[Qemu-devel] [PATCH v3 4/6] target-mips:Octeon cpu definition
From: Khansa Butt
Signed-off-by: Khansa Butt
---
target-mips/mips-defs.h |2 ++
target-mips/translate_init.c | 24
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/target-mips/mips-defs.h b/target-mips/mips-defs.h
index bf094a3..e1ec2b2 100644
--- a/target-mips/mips-defs.h
+++ b/target-mips/mips-defs.h
@@ -41,6 +41,7 @@
#defineASE_MICROMIPS 0x0008
/* Chip specific instructions. */
+#define INSN_OCTEON 0x1000
#defineINSN_LOONGSON2E 0x2000
#defineINSN_LOONGSON2F 0x4000
#defineINSN_VR54XX 0x8000
@@ -53,6 +54,7 @@
#defineCPU_VR54XX (CPU_MIPS4 | INSN_VR54XX)
#defineCPU_LOONGSON2E (CPU_MIPS3 | INSN_LOONGSON2E)
#defineCPU_LOONGSON2F (CPU_MIPS3 | INSN_LOONGSON2F)
+#define CPU_OCTEON (CPU_MIPS64R2 | INSN_OCTEON)
#defineCPU_MIPS5 (CPU_MIPS4 | ISA_MIPS5)
diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
index c39138f..09d2605 100644
--- a/target-mips/translate_init.c
+++ b/target-mips/translate_init.c
@@ -451,6 +451,30 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_R4000,
},
{
+.name = "octeon",
+.CP0_PRid = 0x0d30,
+.CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) | (0x2 << CP0C0_AT) |
+ (MMU_TYPE_R4000 << CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 | (63 << CP0C1_MMU) |
+ (2 << CP0C1_IS) | (4 << CP0C1_IL) | (3 << CP0C1_IA) |
+ (2 << CP0C1_DS) | (4 << CP0C1_DL) | (3 << CP0C1_DA) |
+ (1 << CP0C1_PC) | (1 << CP0C1_WR) | (1 << CP0C1_EP),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3 | (1 << CP0C3_LPA),
+.CP0_LLAddr_rw_bitmask = 0,
+.CP0_LLAddr_shift = 0,
+.SYNCI_Step = 32,
+.CCRes = 2,
+.CP0_Status_rw_bitmask = 0x36FB,
+.CP1_fcr0 = (1 << FCR0_F64) | (1 << FCR0_3D) | (1 << FCR0_PS) |
+(1 << FCR0_L) | (1 << FCR0_W) | (1 << FCR0_D) |
+(1 << FCR0_S) | (0x00 << FCR0_PRID) | (0x0 << FCR0_REV),
+.SEGBITS = 49,
+.PABITS = 49,
+.insn_flags = CPU_OCTEON | ASE_MIPS3D,
+.mmu_type = MMU_TYPE_R4000,
+},
+{
.name = "Loongson-2E",
.CP0_PRid = 0x6302,
/*64KB I-cache and d-cache. 4 way with 32 bit cache line size*/
--
1.7.3.4
[Qemu-devel] [RFC] target-arm: Preserve CPUID over CPU reset
Previously the CPUID register was set in cpu_arm_init() based on -cpu
model. The CPU was then reset, requiring to save the CPUID and restore
it afterwards.
Change the storage location of c0_cpuid so that it does not get cleared.
OMAP appears to be special in that the CPUID can be switched between
TI915T and TI925T on write. Therefore preserve cpu_reset_model_id() in
slightly simplified form, allowing OMAP to reset the CPUID to TI925.
Cc: Peter Maydell
Cc: Paul Brook
Cc: Andrzej Zaborowski
Signed-off-by: Andreas Färber
---
hw/armv7m_nvic.c |2 +-
target-arm/cpu.h |4 ++--
target-arm/helper.c | 24 ++--
target-arm/machine.c |4 ++--
4 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/hw/armv7m_nvic.c b/hw/armv7m_nvic.c
index bf8c3c5..e029537 100644
--- a/hw/armv7m_nvic.c
+++ b/hw/armv7m_nvic.c
@@ -151,7 +151,7 @@ static uint32_t nvic_readl(void *opaque, uint32_t offset)
case 0x1c: /* SysTick Calibration Value. */
return 1;
case 0xd00: /* CPUID Base. */
-return cpu_single_env->cp15.c0_cpuid;
+return ARM_CPUID(cpu_single_env);
case 0xd04: /* Interrypt Control State. */
/* VECTACTIVE */
val = s->gic.running_irq[0];
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 6ab780d..1623a2a 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -106,7 +106,6 @@ typedef struct CPUARMState {
/* System control coprocessor (cp15) */
struct {
-uint32_t c0_cpuid;
uint32_t c0_cachetype;
uint32_t c0_ccsid[16]; /* Cache size. */
uint32_t c0_clid; /* Cache level. */
@@ -228,6 +227,7 @@ typedef struct CPUARMState {
} cp[15];
void *nvic;
const struct arm_boot_info *boot_info;
+uint32_t cp15_c0_cpuid;
} CPUARMState;
CPUARMState *cpu_arm_init(const char *cpu_model);
@@ -398,7 +398,7 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
conventional cores (ie. Application or Realtime profile). */
#define IS_M(env) arm_feature(env, ARM_FEATURE_M)
-#define ARM_CPUID(env) (env->cp15.c0_cpuid)
+#define ARM_CPUID(env) (env->cp15_c0_cpuid)
#define ARM_CPUID_ARM1026 0x4106a262
#define ARM_CPUID_ARM926 0x41069265
diff --git a/target-arm/helper.c b/target-arm/helper.c
index e2428eb..74e423d 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -48,10 +48,9 @@ static inline void set_feature(CPUARMState *env, int feature)
env->features |= 1u << feature;
}
-static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
+static void cpu_reset_model_id(CPUARMState *env)
{
-env->cp15.c0_cpuid = id;
-switch (id) {
+switch (env->cp15_c0_cpuid) {
case ARM_CPUID_ARM926:
set_feature(env, ARM_FEATURE_V4T);
set_feature(env, ARM_FEATURE_V5);
@@ -214,7 +213,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
case ARM_CPUID_TI925T:
set_feature(env, ARM_FEATURE_V4T);
set_feature(env, ARM_FEATURE_OMAPCP);
-env->cp15.c0_cpuid = ARM_CPUID_TI925T; /* Depends on wiring. */
+env->cp15_c0_cpuid = ARM_CPUID_TI925T; /* Depends on wiring. */
env->cp15.c0_cachetype = 0x5109149;
env->cp15.c1_sys = 0x0070;
env->cp15.c15_i_max = 0x000;
@@ -253,7 +252,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
env->cp15.c1_sys = 0x0070;
break;
default:
-cpu_abort(env, "Bad CPU ID: %x\n", id);
+cpu_abort(env, "Bad CPU ID: %x\n", env->cp15_c0_cpuid);
break;
}
@@ -265,17 +264,14 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
id)
void cpu_reset(CPUARMState *env)
{
-uint32_t id;
-
if (qemu_loglevel_mask(CPU_LOG_RESET)) {
qemu_log("CPU Reset (CPU %d)\n", env->cpu_index);
log_cpu_state(env, 0);
}
-id = env->cp15.c0_cpuid;
memset(env, 0, offsetof(CPUARMState, breakpoints));
-if (id)
-cpu_reset_model_id(env, id);
+if (env->cp15_c0_cpuid)
+cpu_reset_model_id(env);
#if defined (CONFIG_USER_ONLY)
env->uncached_cpsr = ARM_CPU_MODE_USR;
/* For user mode we must enable access to coprocessors */
@@ -311,7 +307,7 @@ void cpu_reset(CPUARMState *env)
/* v7 performance monitor control register: same implementor
* field as main ID register, and we implement no event counters.
*/
-env->cp15.c9_pmcr = (id & 0xff00);
+env->cp15.c9_pmcr = (env->cp15_c0_cpuid & 0xff00);
#endif
set_flush_to_zero(1, &env->vfp.standard_fp_status);
set_flush_inputs_to_zero(1, &env->vfp.standard_fp_status);
@@ -392,7 +388,7 @@ CPUARMState *cpu_arm_init(const char *cpu_model)
}
env->cpu_model_str = cpu_model;
-env->cp15.c0_cpuid = id;
+env->cp15_c0_cpuid = id;
cpu_reset(env);
if (arm_feature(env, ARM_FEATURE_NEON)) {
gdb_register_coprocessor(env, vfp_gdb_get_reg, vfp_gdb_set_reg,
@@ -1756,7 +1752,7 @@ void HELPER(set_cp1
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
2011/10/22 xunxun : > 于 2011/10/22 13:13, xunxun 写道: >> >> Hi, all >> >> It seems that gcc's auto-omit-frame-pointer has other problems. >> >> The example is from mingw bug tracker: >> http://sourceforge.net/tracker/?func=detail&aid=3426555&group_id=2435&atid=102435 >> >> g++ -O3 main.cpp running will crash. >> g++ -O2 main.cpp running no crash. >> g++ -O3 -fno-omit-frame-pointer running no crash. >> >> I don't know in the end which optimize option defaultly contains this >> switch "-fomit-frame-pointer" on i686-pc-mingw32 or x86_64-w64-mingw32? >> > It crashes on Win7. Well, this issue isn't related to this thread. It is more related to dw2 and SjLj used. For toolchains using dw2 exception mechanism, you will see this crash. By using SjLj you won't (thanks for checking this). This shows indeed my strong concerns about dw2 exception mechanism for 32-bit Windows targets. The implementation depends too much on code-patterns and is therefore a bit inconsitant. Secondly it causes harm if you try to throw exceptions over VC generated code. So I would strongly recomment to use the slower, but more reliable SjLj throwing mechanism on Windows 32-bit. Regards, Kai
Re: [Qemu-devel] [PATCH v3 0/6] MIPS64 user mode emulation in QEMU with Cavium specific instruction support
Am 22.10.2011 12:11, schrieb kha...@kics.edu.pk: > From: Khansa Butt > > This is the team work of Ehsan-ul-Haq, Abdul Qadeer, Abdul Waheed, Khansa Butt > from HPCN Lab KICS UET Lahore. > > Sorry Richard! gen_set was missed. When I say further description is missing, I mean: Please add at least one sentence between From: and Signed-off-by: summarizing what changes you are doing and why those are correct. This is very useful for bisecting, git log and web interfaces. And if you're fixing a bug, please describe what symptoms there were (crash? wrong values? etc.) so that it can be verified and checked for future regressions. Remember, most of us are not too intimate with mips. Andreas > v1 contains: > * SEQI and SEQ related changes specified by Richard Henderson > * Fix issues related to coding style, typos and misleading comments > * Cavium specific change in set_thread_area syscall has been removed > * as it corresponds to modified libc and kernel.
Re: [Qemu-devel] [PATCH v3 5/6] target-mips: Adding support for Cavium specific instructions
Am 22.10.2011 12:11, schrieb kha...@kics.edu.pk:
> From: Khansa Butt
Commit message should mention here at least that new registers are
introduced and that load/save format is being changed.
> Signed-off-by: Khansa Butt
> Signed-off-by: Ehsan Ul Haq
> Signed-off-by: Abdul Qadeer
> Signed-off-by: Abdul Waheed
> ---
> diff --git a/target-mips/cpu.h b/target-mips/cpu.h
> index 79e2558..9180ee9 100644
> --- a/target-mips/cpu.h
> +++ b/target-mips/cpu.h
> @@ -173,6 +173,13 @@ struct TCState {
> target_ulong CP0_TCSchedule;
> target_ulong CP0_TCScheFBack;
> int32_t CP0_Debug_tcstatus;
> +/* Multiplier registers for Octeon */
> +target_ulong MPL0;
> +target_ulong MPL1;
> +target_ulong MPL2;
> +target_ulong P0;
> +target_ulong P1;
> +target_ulong P2;
> };
>
> typedef struct CPUMIPSState CPUMIPSState;
> diff --git a/target-mips/machine.c b/target-mips/machine.c
> index be72b36..a274ce2 100644
> --- a/target-mips/machine.c
> +++ b/target-mips/machine.c
> @@ -25,6 +25,12 @@ static void save_tc(QEMUFile *f, TCState *tc)
> qemu_put_betls(f, &tc->CP0_TCSchedule);
> qemu_put_betls(f, &tc->CP0_TCScheFBack);
> qemu_put_sbe32s(f, &tc->CP0_Debug_tcstatus);
> +qemu_put_betls(f, &tc->MPL0);
> +qemu_put_betls(f, &tc->MPL1);
MPL2 is not being saved but loaded below.
> +qemu_put_betls(f, &tc->P0);
> +qemu_put_betls(f, &tc->P1);
> +qemu_put_betls(f, &tc->P2);
> +
> }
>
> static void save_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
> @@ -173,6 +179,12 @@ static void load_tc(QEMUFile *f, TCState *tc)
> qemu_get_betls(f, &tc->CP0_TCSchedule);
> qemu_get_betls(f, &tc->CP0_TCScheFBack);
> qemu_get_sbe32s(f, &tc->CP0_Debug_tcstatus);
> +qemu_get_betls(f, &tc->MPL0);
> +qemu_get_betls(f, &tc->MPL1);
> +qemu_get_betls(f, &tc->MPL2);
> +qemu_get_betls(f, &tc->P0);
> +qemu_get_betls(f, &tc->P1);
> +qemu_get_betls(f, &tc->P2);
> }
>
> static void load_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
You're saving new fields, so you'll need to bump the version somewhere.
For loading, since you're adding at the end, you might be able to make
your additions conditional on the to-be-bumped version.
I'm wondering whether those register and serialization additions could
and should be limited to TARGET_MIPS64.
Andreas
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
On 2011-10-20 23:34, Kai Tietz wrote: > Hi, > > For trunk-version I have a tentative patch for this issue. On 4.6.x > and older branches this doesn't work, as here we can't differenciate > that easy between ms- and sysv-abi. > > But could somebody give this patch a try? > > Regards, > Kai > > ChangeLog > > * config/i386/i386.c (ix86_frame_pointer_required): Enforce use of > frame-pointer for 32-bit ms-abi, if setjmp is used. > > Index: i386.c > === > --- i386.c (revision 180099) > +++ i386.c (working copy) > @@ -8391,6 +8391,10 @@ > if (SUBTARGET_FRAME_POINTER_REQUIRED) > return true; > > + /* For older 32-bit runtimes setjmp requires valid frame-pointer. */ > + if (TARGET_32BIT_MS_ABI&& cfun->calls_setjmp) > +return true; > + > /* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER >turns off the frame pointer by default. Turn it back on now if >we've not got a leaf function. */ > I just see two related links about this issue: see: http://stackoverflow.com/questions/5887552/setjmp-and-omit-frame-pointer and http://connect.microsoft.com/VisualStudio/feedback/details/666704/visual-c-generates-incorrect-code-with-omit-frame-pointer-and-setjmp I'm not sure microsoft has fix this issue. asmwarrior ollydbg from codeblocks' forum
Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
On 21.10.2011, at 11:44, Paolo Bonzini wrote: > On 10/21/2011 07:08 PM, Kevin Wolf wrote: >> Avi complained that not even writing out qcow2's cache on bdrv_flush() made >> cache=unsafe too unsafe to be useful. He's got a point. > > Why? cache=unsafe is explicitly allowing to s/data/manure/ on crash. Exactly, but not on kill. By not flushing internal caches you're almost guaranteed to get an inconsistent qcow2 image. > If you do this for raw-posix, you need to do it for all protocols. Only for the ones that actually do flushes to the block layer. The idea is that while QEMU dies the OS can still finish writing unflushed blocks. Alex
Re: [Qemu-devel] [QEMU : VVFAT] vvfat.c - help required for understanding/modification
Hello Mr. Johannes, Kevin
I already did some work for scanning only top level directory in vvfat.
Using the following logic in read_directory()
if(parent_index >= 0 & (!dot & !dotdot))
{
free(buffer);
break;
}
Hope this is correct logic for skipping sub-directories content by
just scanning only dot and dotdot entries inside it.
But as per the recent analysis it was observed that there is some
problem in skipping sub-directory scanning itself.
Because when I issue "df" command on VVFAT partition I get
read_cluster errors during these sector location.
Mr. Johannes, can you clarify on this first.
Then we will look into the dynamic mapping part later.
Thank you very much.
Thanks, Regards,
Pintu
On Thu, Oct 20, 2011 at 1:43 PM, Kevin Wolf wrote:
> Am 19.10.2011 20:34, schrieb Pintu Kumar:
>> Dear Mr. Johannes,
>>
>> Thank you very much for your reply.
>>
>> So according to you implementing dynamic mapping logic after mounting
>> in VVFAT is possible.
>>
>> But from your following mail, I could not understand how to do that.
>>
>> Can you explain me with reference from the vvfat.c code.
>>
>> What should I do to scan only top level files/folders in read_directory?
>>
>> And what should I need to do in vvfatd_process_req (case : READ) to
>> create dynamic mapping on the fly before displaying the content on
>> guest OS.
>>
>> Right now I very this on my Linux PC it using "ls" command.
>>
>> Example:
>> If my vvfat mount path is /mnt/movifs and it contains one
>> sub-directory say "test1"
>> Then I use "ls -l /mnt/movifs/test1" in which case vvfatd_process_req
>> is invoked and then vvfat_read is invoked.
>>
>>
>> Please let me know.
>
> You asked in a second mail that you sent privately that I explain to you
> how to implement this, as you didn't fully understand what Johannes
> wrote. I'm going to add my reply here so that we don't have several
> separate mail threads. Actually, adding the mailing list wouldn't hurt
> either, but that's your decision.
>
> There's really one main thing that I would recommend you to finally do:
> Take a look at how FAT works. Completely independent of vvfat. And then
> think about how to implement something like this. And only then go back
> to vvfat and do it there. I won't do that for you, even if you double
> the length of the email thread.
>
>>> -- Forwarded message --
>>> From: Johannes Schindelin
>>> Date: Wed, Oct 19, 2011 at 1:37 AM
>>> Subject: Re: [QEMU : VVFAT] vvfat.c - help required for
>>> understanding/modification
>>> To: Pintu Kumar
>>>
>>>
>>> Hi,
>>>
>>> On Sun, 16 Oct 2011, Pintu Kumar wrote:
>>>
In short, we wanted to implement partial scanning in the beginning and
dynamic mappings for VVFAT during runtime and after VVFAT is mounted.
That is, to scan only top level files and directories (skip
sub-directories content) during vvfat_prepare() and mount it.
Later we a particular sub-directory is accessed by the guest OS, we
wanted to create its mapping on the fly.
>>>
>>> That sounds doable, since you can initialize the respective blocks in the
>>> FAT lazily, when they are accessed.
>
> I think it's possible in a very limited way. The nasty thing is that you
> don't really have the notion of directories when the guest accesses the
> file system. You have accesses to sectors that contain the FAT.
>
> Once the guest has read in a sector of the FAT, you must consider this
> sector final. You can't later allocate new clusters in this sector of
> the FAT because in general the guest OS will have cached the sector and
> won't reread it.
>
> So the real problem is to manage which clusters already have been read;
> which clusters you already referenced, but are still open for additions;
> and which files/subdirectories still need to be integrated somewhere.
> The guest can read the sectors of the FAT in any order, and it could
> read sectors that you haven't referenced yet at all (because, who reads
> single sectors?), which should add a bit to the fun.
>
I did some work on it but facing some problem. The sub-directory
contents are not visible after dynamic mapping and updating the FAT
content.
I wanted to know your opinion if such kind of logic is possible to
implement in VVFAT.
>>>
>>> I think the basic problem is to know when to update the FAT content. As I
>>> alluded to above, I would do it thusly: Initialize the top-level directory
>>> and remember the blocks you want to use for the subdirectories. Whenever
>>> the corresponding blocks' contents are requested, initialize them, again
>>> ear-marking blocks for the subdirectories.
>>>
>>> But maybe I misunderstood?
>
> It really boils down to this question: Do we have enough space in the
> FAT for leaving most of it sparse? It looks like we're talking about a
> rather big directory tree, otherwise reading it in on startup wouldn't
> be a problem.
>
> And of course you're wasting precious disk space: If I under
Re: [Qemu-devel] [QEMU : VVFAT] vvfat.c - help required for understanding/modification
Hi Pintu,
On Sat, 22 Oct 2011, Pintu Kumar wrote:
> I already did some work for scanning only top level directory in vvfat.
> Using the following logic in read_directory()
>
> if(parent_index >= 0 & (!dot & !dotdot))
> {
>free(buffer);
>break;
> }
Sorry, this is way too deep in the code (and I'd have to guess because you
did not grace me with exact locations), I cannot afford to dive into it
that far. But what I can say is that it is not all that easy; you'll need
to refactor the code.
You _will_ need to reserve sectors for future directory parsing. You
_will_ need to add code that intercepts reads to those sectors. You _will_
have to read the directories in question when those sectors are accessed
and thereby commit the sectors to a final state.
BTW both Kevin and I said that before.
> Hope this is correct logic for skipping sub-directories content by just
> scanning only dot and dotdot entries inside it.
It would be, if all you want are empty directories.
> But as per the recent analysis it was observed that there is some
> problem in skipping sub-directory scanning itself. Because when I issue
> "df" command on VVFAT partition I get read_cluster errors during these
> sector location.
When you issue "df", you need to commit to which sectors are reserved. By
that, you take almost all the advantage of lazy directory parsing away.
> Mr. Johannes, can you clarify on this first.
>
> Then we will look into the dynamic mapping part later.
I am very sorry, but I do get the impression that the intent is to lure me
into doing all the work, including the investigation what it would take to
turn the code into a version that reads just the top-level first and only
later the subdirectories.
This will not happen. I have enough projects that I want to tackle myself,
and I am extremely unwilling to do the work for somebody else when that
somebody else is paid to do the work. For the things I _want_ to do I
already have too little time, given that my day job is quite demanding and
asks software design and architecture of me already.
So: you _will_ have to acquaint yourself with the FAT and then the VFAT
specification. You _will_ have to make a proper plan how the client may be
fooled into believing that there is a fixed filesystem when there is
actually just directories of files. And you _will_ have to write that code
yourself.
I hope this clarified it?
Ciao,
Johannes
Re: [Qemu-devel] [PATCH 3/7] target-arm: Rename ARM_FEATURE_DIV to _THUMB_DIV
Am 20.10.2011 15:16, schrieb Peter Maydell:
> Rename the ARM_FEATURE_DIV feature bit to _THUMB_DIV, to
> make room for a new feature switch enabling DIV in the ARM
> encoding. (Cores may implement either (a) no divide insns
> (b) divide insns in Thumb encodings only (c) divide insns
> in both ARM and Thumb encodings.)
>
> Signed-off-by: Peter Maydell
Acked-by: Andreas Färber
Andreas
> ---
> target-arm/cpu.h |2 +-
> target-arm/helper.c|4 ++--
> target-arm/translate.c |3 ++-
> 3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 6ab780d..00e012e 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -366,7 +366,7 @@ enum arm_features {
> ARM_FEATURE_VFP3,
> ARM_FEATURE_VFP_FP16,
> ARM_FEATURE_NEON,
> -ARM_FEATURE_DIV,
> +ARM_FEATURE_THUMB_DIV, /* divide supported in Thumb encoding */
> ARM_FEATURE_M, /* Microcontroller profile. */
> ARM_FEATURE_OMAPCP, /* OMAP specific CP15 ops handling. */
> ARM_FEATURE_THUMB2EE,
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 17ef98b..faf0283 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -193,7 +193,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
> id)
> set_feature(env, ARM_FEATURE_THUMB2);
> set_feature(env, ARM_FEATURE_V7);
> set_feature(env, ARM_FEATURE_M);
> -set_feature(env, ARM_FEATURE_DIV);
> +set_feature(env, ARM_FEATURE_THUMB_DIV);
> break;
> case ARM_CPUID_ANY: /* For userspace emulation. */
> set_feature(env, ARM_FEATURE_V4T);
> @@ -207,7 +207,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
> id)
> set_feature(env, ARM_FEATURE_VFP_FP16);
> set_feature(env, ARM_FEATURE_NEON);
> set_feature(env, ARM_FEATURE_THUMB2EE);
> -set_feature(env, ARM_FEATURE_DIV);
> +set_feature(env, ARM_FEATURE_THUMB_DIV);
> set_feature(env, ARM_FEATURE_V7MP);
> break;
> case ARM_CPUID_TI915T:
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index e99fc18..deb0bcf 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -8513,8 +8513,9 @@ static int disas_thumb2_insn(CPUState *env,
> DisasContext *s, uint16_t insn_hw1)
> tmp2 = load_reg(s, rm);
> if ((op & 0x50) == 0x10) {
> /* sdiv, udiv */
> -if (!arm_feature(env, ARM_FEATURE_DIV))
> +if (!arm_feature(env, ARM_FEATURE_THUMB_DIV)) {
> goto illegal_op;
> +}
> if (op & 0x20)
> gen_helper_udiv(tmp, tmp, tmp2);
> else
Re: [Qemu-devel] [PATCH 4/7] target-arm: Add ARM UDIV/SDIV support
Am 20.10.2011 15:16, schrieb Peter Maydell:
> Add support for UDIV and SDIV in ARM mode. This is a new optional
> feature for A profile cores (Thumb mode has had UDIV and SDIV for
> M profile cores for some time).
>
> Signed-off-by: Peter Maydell
Lightly ...
Tested-by: Andreas Färber
Andreas
> ---
> target-arm/cpu.h |1 +
> target-arm/helper.c|5 -
> target-arm/translate.c | 19 +++
> 3 files changed, 24 insertions(+), 1 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 00e012e..af3904d 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -375,6 +375,7 @@ enum arm_features {
> ARM_FEATURE_V5,
> ARM_FEATURE_STRONGARM,
> ARM_FEATURE_VAPA, /* cp15 VA to PA lookups */
> +ARM_FEATURE_ARM_DIV, /* divide supported in ARM encoding */
> };
>
> static inline int arm_feature(CPUARMState *env, int feature)
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index faf0283..3a51fd7 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -207,7 +207,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
> id)
> set_feature(env, ARM_FEATURE_VFP_FP16);
> set_feature(env, ARM_FEATURE_NEON);
> set_feature(env, ARM_FEATURE_THUMB2EE);
> -set_feature(env, ARM_FEATURE_THUMB_DIV);
> +set_feature(env, ARM_FEATURE_ARM_DIV);
> set_feature(env, ARM_FEATURE_V7MP);
> break;
> case ARM_CPUID_TI915T:
> @@ -261,6 +261,9 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t
> id)
> if (arm_feature(env, ARM_FEATURE_V7)) {
> set_feature(env, ARM_FEATURE_VAPA);
> }
> +if (arm_feature(env, ARM_FEATURE_ARM_DIV)) {
> +set_feature(env, ARM_FEATURE_THUMB_DIV);
> +}
> }
>
> void cpu_reset(CPUARMState *env)
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index deb0bcf..812a9e7 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -7639,6 +7639,25 @@ static void disas_arm_insn(CPUState * env,
> DisasContext *s)
> store_reg(s, rn, tmp);
> }
> break;
> +case 1:
> +case 3:
> +/* SDIV, UDIV */
> +if (!arm_feature(env, ARM_FEATURE_ARM_DIV)) {
> +goto illegal_op;
> +}
> +if (((insn >> 5) & 7) || (rd != 15)) {
> +goto illegal_op;
> +}
> +tmp = load_reg(s, rm);
> +tmp2 = load_reg(s, rs);
> +if (insn & (1 << 21)) {
> +gen_helper_udiv(tmp, tmp, tmp2);
> +} else {
> +gen_helper_sdiv(tmp, tmp, tmp2);
> +}
> +tcg_temp_free_i32(tmp2);
> +store_reg(s, rn, tmp);
> +break;
> default:
> goto illegal_op;
> }
[Qemu-devel] buildbot failure in qemu on xen_i386_debian_6_0
The Buildbot has detected a new failure on builder xen_i386_debian_6_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/xen_i386_debian_6_0/builds/69 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_xen' triggered this build Build Source Stamp: [branch xen-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] [PATCH] exec-all: Fix void pointer arithmetic
Adding an offset to a void pointer works with gcc but is not allowed by the current C standards. With -pedantic, gcc complains: exec-all.h:344: error: pointer of type ‘void *’ used in arithmetic Fix this, and also replace (unsigned int) by (uintptr_t) in the same statement. Signed-off-by: Stefan Weil --- exec-all.h |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/exec-all.h b/exec-all.h index 69fd5e4..0f10393 100644 --- a/exec-all.h +++ b/exec-all.h @@ -358,8 +358,7 @@ static inline tb_page_addr_t get_page_addr_code(CPUState *env1, target_ulong add cpu_abort(env1, "Trying to execute code outside RAM or ROM at 0x" TARGET_FMT_lx "\n", addr); #endif } -p = (void *)(unsigned long)addr -+ env1->tlb_table[mmu_idx][page_index].addend; +p = (void *)((uintptr_t)addr + env1->tlb_table[mmu_idx][page_index].addend); return qemu_ram_addr_from_host_nofail(p); } #endif -- 1.7.2.5
