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