Re: [Qemu-devel] [PATCH v3 5/6] target-mips: Adding support for Cavium specific instructions
Am 22.11.2011 09:31, schrieb Khansa Butt:
On Tue, Nov 1, 2011 at 1:24 AM, Andreas Färber andreas.faer...@web.de wrote:
Am 28.10.2011 06:42, schrieb Khansa Butt:
On Sat, Oct 22, 2011 at 4:36 PM, Andreas Färber andreas.faer...@web.de
mailto:andreas.faer...@web.de wrote:
Am 22.10.2011 12:11, schrieb kha...@kics.edu.pk
mailto:kha...@kics.edu.pk:
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
@@ -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 not able to understand bump the version somewhere kindly
explain this.
Somewhere indicates I don't know the exact line for mips. Compare the
recent patch to arm_gic.
The general idea is that QEMU needs to be able to load files saved with
an older version, the file format is therefore versioned. If you
unconditionally try to load your new registers, you break loading older
files that don't include them.
Thanks for your response.
As I can't see any example of bumping the version of registers in
mips ( 32 or 64) so i'm in a bit difficult situation
From arm_gic what i understand is that version_id is related to
devices which are specific to some board
as gic is related to RealView board. considering that i'm in user
mode, can i do the same thing with Cavium's registers as these are
related to multiplier unit?
No, this is not board- or device-specific, it's CPU-specific. Cf.
target-mips/cpu.h:CPU_SAVE_VERSION
target-mips/savevm.c:cpu_load()
My suggestion was to bump CPU_SAVE_VERSION to 4, change the error check
to if (version_id 3) and to enclose your cpuo_load() additions in
if (version_id = 4) { ... }.
Depending how long you need to resend, note that Juan is working on a
VMState refactoring of machine.c, which will make it more like devices.
Andreas
Re: [Qemu-devel] [PATCH v3 5/6] target-mips: Adding support for Cavium specific instructions
On Wed, Nov 30, 2011 at 4:54 PM, Andreas Färber andreas.faer...@web.de wrote:
Am 22.11.2011 09:31, schrieb Khansa Butt:
On Tue, Nov 1, 2011 at 1:24 AM, Andreas Färber andreas.faer...@web.de
wrote:
Am 28.10.2011 06:42, schrieb Khansa Butt:
On Sat, Oct 22, 2011 at 4:36 PM, Andreas Färber andreas.faer...@web.de
mailto:andreas.faer...@web.de wrote:
Am 22.10.2011 12:11, schrieb kha...@kics.edu.pk
mailto:kha...@kics.edu.pk:
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
@@ -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 not able to understand bump the version somewhere kindly
explain this.
Somewhere indicates I don't know the exact line for mips. Compare the
recent patch to arm_gic.
The general idea is that QEMU needs to be able to load files saved with
an older version, the file format is therefore versioned. If you
unconditionally try to load your new registers, you break loading older
files that don't include them.
Thanks for your response.
As I can't see any example of bumping the version of registers in
mips ( 32 or 64) so i'm in a bit difficult situation
From arm_gic what i understand is that version_id is related to
devices which are specific to some board
as gic is related to RealView board. considering that i'm in user
mode, can i do the same thing with Cavium's registers as these are
related to multiplier unit?
No, this is not board- or device-specific, it's CPU-specific. Cf.
target-mips/cpu.h:CPU_SAVE_VERSION
target-mips/savevm.c:cpu_load()
My suggestion was to bump CPU_SAVE_VERSION to 4, change the error check
to if (version_id 3) and to enclose your cpuo_load() additions in
if (version_id = 4) { ... }.
Thanks for your response!
Here is a confusion. I found that cpu_save() and cpu_load() are not called in
user mode emulation, here is the code from exec.c
#if defined(CPU_SAVE_VERSION) !defined(CONFIG_USER_ONLY)
vmstate_register(NULL, cpu_index, vmstate_cpu_common, env);
register_savevm(NULL, cpu, cpu_index, CPU_SAVE_VERSION,
cpu_save, cpu_load, env);
#endif
As these patches are related to UME so we decided to postpone Octeon
specific changes ( registers and instructions) and will include them in our
SME work( we are currently working on system mode emulation of Octeon board)
that's why yesterday I sent only MIPS64 user mode emulation patches
here is the link
http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg03527.html
Please review them
I'm sorry, the words with Cavium specific instruction support are
mistakenly added
into subject line.
Please guide me towards the right track. should we stick to are old patches or
submit MIPS64 UME patches only(which are without Cavium's Instruction support)
Depending how long you need to resend, note that Juan is working on a
VMState refactoring of machine.c, which will make it more like devices.
Andreas
Re: [Qemu-devel] [PATCH v3 5/6] target-mips: Adding support for Cavium specific instructions
On Tue, Nov 1, 2011 at 1:24 AM, Andreas Färber andreas.faer...@web.de wrote:
Am 28.10.2011 06:42, schrieb Khansa Butt:
On Sat, Oct 22, 2011 at 4:36 PM, Andreas Färber andreas.faer...@web.de
mailto:andreas.faer...@web.de wrote:
Am 22.10.2011 12:11, schrieb kha...@kics.edu.pk
mailto:kha...@kics.edu.pk:
HTML again :(
From: Khansa Butt kha...@kics.edu.pk mailto:kha...@kics.edu.pk
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 kha...@kics.edu.pk
mailto:kha...@kics.edu.pk
Signed-off-by: Ehsan Ul Haq ehsan.ul...@kics.edu.pk
mailto:ehsan.ul...@kics.edu.pk
Signed-off-by: Abdul Qadeer qad...@kics.edu.pk
mailto:qad...@kics.edu.pk
Signed-off-by: Abdul Waheed awah...@kics.edu.pk
mailto:awah...@kics.edu.pk
---
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 not able to understand bump the version somewhere kindly
explain this.
Somewhere indicates I don't know the exact line for mips. Compare the
recent patch to arm_gic.
The general idea is that QEMU needs to be able to load files saved with
an older version, the file format is therefore versioned. If you
unconditionally try to load your new registers, you break loading older
files that don't include them.
Thanks for your response.
As I can't see any example of bumping the version of registers in
mips ( 32 or 64) so i'm in a bit difficult situation
From arm_gic what i understand is that version_id is related to
devices which are specific to some board
as gic is related to RealView board. considering that i'm in user
mode, can i do the same thing with Cavium's registers as these are
related to multiplier unit? Also please tell me about mips maintainer,
Aurelien Jarno. I think he is not active in developer list for a
while.
I'm wondering whether those register and serialization additions could
and should be limited to TARGET_MIPS64.
you want me to limit these registers to TARGET_OCTEON
No, there shouldn't be a TARGET_OCTEON, there's no Octeon-specific
executable.
My point is, IIUC, qemu-system-mips will never have Octeon registers
because they're in qemu-system-mips64 only. So without #ifdef it would
save and load unused registers.
Andreas
Re: [Qemu-devel] [PATCH v3 5/6] target-mips: Adding support for Cavium specific instructions
Am 28.10.2011 06:42, schrieb Khansa Butt:
On Sat, Oct 22, 2011 at 4:36 PM, Andreas Färber andreas.faer...@web.de
mailto:andreas.faer...@web.de wrote:
Am 22.10.2011 12:11, schrieb kha...@kics.edu.pk
mailto:kha...@kics.edu.pk:
HTML again :(
From: Khansa Butt kha...@kics.edu.pk mailto:kha...@kics.edu.pk
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 kha...@kics.edu.pk
mailto:kha...@kics.edu.pk
Signed-off-by: Ehsan Ul Haq ehsan.ul...@kics.edu.pk
mailto:ehsan.ul...@kics.edu.pk
Signed-off-by: Abdul Qadeer qad...@kics.edu.pk
mailto:qad...@kics.edu.pk
Signed-off-by: Abdul Waheed awah...@kics.edu.pk
mailto:awah...@kics.edu.pk
---
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 not able to understand bump the version somewhere kindly
explain this.
Somewhere indicates I don't know the exact line for mips. Compare the
recent patch to arm_gic.
The general idea is that QEMU needs to be able to load files saved with
an older version, the file format is therefore versioned. If you
unconditionally try to load your new registers, you break loading older
files that don't include them.
I'm wondering whether those register and serialization additions could
and should be limited to TARGET_MIPS64.
you want me to limit these registers to TARGET_OCTEON
No, there shouldn't be a TARGET_OCTEON, there's no Octeon-specific
executable.
My point is, IIUC, qemu-system-mips will never have Octeon registers
because they're in qemu-system-mips64 only. So without #ifdef it would
save and load unused registers.
Andreas
Re: [Qemu-devel] [PATCH v3 5/6] target-mips: Adding support for Cavium specific instructions
On Sat, Oct 22, 2011 at 4:36 PM, Andreas Färber andreas.faer...@web.dewrote:
Am 22.10.2011 12:11, schrieb kha...@kics.edu.pk:
From: Khansa Butt kha...@kics.edu.pk
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 kha...@kics.edu.pk
Signed-off-by: Ehsan Ul Haq ehsan.ul...@kics.edu.pk
Signed-off-by: Abdul Qadeer qad...@kics.edu.pk
Signed-off-by: Abdul Waheed awah...@kics.edu.pk
---
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 not able to understand bump the version somewhere kindly
explain this.
I'm wondering whether those register and serialization additions could
and should be limited to TARGET_MIPS64.
you want me to limit these registers to TARGET_OCTEON
[Qemu-devel] [PATCH v3 5/6] target-mips: Adding support for Cavium specific instructions
From: Khansa Butt kha...@kics.edu.pk
Signed-off-by: Khansa Butt kha...@kics.edu.pk
Signed-off-by: Ehsan Ul Haq ehsan.ul...@kics.edu.pk
Signed-off-by: Abdul Qadeer qad...@kics.edu.pk
Signed-off-by: Abdul Waheed awah...@kics.edu.pk
---
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
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 kha...@kics.edu.pk
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 kha...@kics.edu.pk
Signed-off-by: Ehsan Ul Haq ehsan.ul...@kics.edu.pk
Signed-off-by: Abdul Qadeer qad...@kics.edu.pk
Signed-off-by: Abdul Waheed awah...@kics.edu.pk
---
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
