target/mips/op_helper.c | 2 ++ 1 file changed, 2 insertions(+)
We only implement the Index[Store/Load]Tag from the 'cache' opcode.
Instead of ignoring the other cache operations, report them as
unimplemented.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
target/mips/op_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/mips/op_helper.c b/target/mips/op_helper.c
index 9552b280e0..7f87e57c8e 100644
--- a/target/mips/op_helper.c
+++ b/target/mips/op_helper.c
@@ -1583,6 +1583,8 @@ void helper_cache(CPUMIPSState *env, target_ulong addr, uint32_t op)
/* Index Load Tag */
memory_region_dispatch_read(env->itc_tag, index, &env->CP0_TagLo,
MO_64, MEMTXATTRS_UNSPECIFIED);
+ } else {
+ qemu_log_mask(LOG_UNIMP, "cache %u\n", op);
}
#endif
}
--
2.21.3
在 2020/8/6 下午8:26, Philippe Mathieu-Daudé 写道: > We only implement the Index[Store/Load]Tag from the 'cache' opcode. > Instead of ignoring the other cache operations, report them as > unimplemented. Hmm, I don't think we have anything to do with Invalidate/Writeback etc. opcodes in QEMU. Why do we log this? Thanks. - Jiaxun > > Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> > --- > target/mips/op_helper.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/target/mips/op_helper.c b/target/mips/op_helper.c > index 9552b280e0..7f87e57c8e 100644 > --- a/target/mips/op_helper.c > +++ b/target/mips/op_helper.c > @@ -1583,6 +1583,8 @@ void helper_cache(CPUMIPSState *env, target_ulong addr, uint32_t op) > /* Index Load Tag */ > memory_region_dispatch_read(env->itc_tag, index, &env->CP0_TagLo, > MO_64, MEMTXATTRS_UNSPECIFIED); > + } else { > + qemu_log_mask(LOG_UNIMP, "cache %u\n", op); > } > #endif > }
On 8/6/20 8:01 PM, Jiaxun Yang wrote: > 在 2020/8/6 下午8:26, Philippe Mathieu-Daudé 写道: >> We only implement the Index[Store/Load]Tag from the 'cache' opcode. >> Instead of ignoring the other cache operations, report them as >> unimplemented. > > Hmm, I don't think we have anything to do with Invalidate/Writeback etc. > opcodes > in QEMU. Why do we log this? I'm noticed this code is run on Linux 3.3.8 (4KEc): 8880: 3082000f andi v0,a0,0xf 8884: 10800008 beqz a0,88a8 8888: 00a21021 addu v0,a1,v0 888c: 08002227 j 889c 8890: 00001821 move v1,zero 8894: bcf90000 cache 0x19,0(a3) 8898: 24630010 addiu v1,v1,16 889c: 0062302b sltu a2,v1,v0 88a0: 14c0fffc bnez a2,8894 88a4: 00833821 addu a3,a0,v1 88a8: 03e00008 jr ra 88ac: 00000000 nop Why silently ignore the opcode is not implemented instead of logging it? > > Thanks. > > - Jiaxun > >> >> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> >> --- >> target/mips/op_helper.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/target/mips/op_helper.c b/target/mips/op_helper.c >> index 9552b280e0..7f87e57c8e 100644 >> --- a/target/mips/op_helper.c >> +++ b/target/mips/op_helper.c >> @@ -1583,6 +1583,8 @@ void helper_cache(CPUMIPSState *env, >> target_ulong addr, uint32_t op) >> /* Index Load Tag */ >> memory_region_dispatch_read(env->itc_tag, index, >> &env->CP0_TagLo, >> MO_64, MEMTXATTRS_UNSPECIFIED); >> + } else { >> + qemu_log_mask(LOG_UNIMP, "cache %u\n", op); >> } >> #endif >> } >
On Thu, 6 Aug 2020 at 21:31, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > On 8/6/20 8:01 PM, Jiaxun Yang wrote: > > 在 2020/8/6 下午8:26, Philippe Mathieu-Daudé 写道: > >> We only implement the Index[Store/Load]Tag from the 'cache' opcode. > >> Instead of ignoring the other cache operations, report them as > >> unimplemented. > > > > Hmm, I don't think we have anything to do with Invalidate/Writeback etc. > > opcodes > > in QEMU. Why do we log this? > > I'm noticed this code is run on Linux 3.3.8 (4KEc): > > 8880: 3082000f andi v0,a0,0xf > 8884: 10800008 beqz a0,88a8 > 8888: 00a21021 addu v0,a1,v0 > 888c: 08002227 j 889c > 8890: 00001821 move v1,zero > 8894: bcf90000 cache 0x19,0(a3) > 8898: 24630010 addiu v1,v1,16 > 889c: 0062302b sltu a2,v1,v0 > 88a0: 14c0fffc bnez a2,8894 > 88a4: 00833821 addu a3,a0,v1 > 88a8: 03e00008 jr ra > 88ac: 00000000 nop > > Why silently ignore the opcode is not implemented instead of logging it? I think the question is whether the opcode is supposed to have some behaviour which we're not implementing, or whether "no-op" is the correct behaviour for it (which it usually is for cache invalidate type operations; compare the way the Arm cache ops like IC_IALLU are just ARM_CP_NOP ops). thanks -- PMM
On 8/6/20 10:51 PM, Peter Maydell wrote: > On Thu, 6 Aug 2020 at 21:31, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> >> On 8/6/20 8:01 PM, Jiaxun Yang wrote: >>> 在 2020/8/6 下午8:26, Philippe Mathieu-Daudé 写道: >>>> We only implement the Index[Store/Load]Tag from the 'cache' opcode. >>>> Instead of ignoring the other cache operations, report them as >>>> unimplemented. >>> >>> Hmm, I don't think we have anything to do with Invalidate/Writeback etc. >>> opcodes >>> in QEMU. Why do we log this? >> >> I'm noticed this code is run on Linux 3.3.8 (4KEc): >> >> 8880: 3082000f andi v0,a0,0xf >> 8884: 10800008 beqz a0,88a8 >> 8888: 00a21021 addu v0,a1,v0 >> 888c: 08002227 j 889c >> 8890: 00001821 move v1,zero >> 8894: bcf90000 cache 0x19,0(a3) >> 8898: 24630010 addiu v1,v1,16 >> 889c: 0062302b sltu a2,v1,v0 >> 88a0: 14c0fffc bnez a2,8894 >> 88a4: 00833821 addu a3,a0,v1 >> 88a8: 03e00008 jr ra >> 88ac: 00000000 nop >> >> Why silently ignore the opcode is not implemented instead of logging it? > > I think the question is whether the opcode is supposed to have > some behaviour which we're not implementing, or whether "no-op" > is the correct behaviour for it (which it usually is for > cache invalidate type operations; compare the way the Arm > cache ops like IC_IALLU are just ARM_CP_NOP ops). OK now I understand better, thanks. I haven't found useful information about this 0x19=25 opcode value. On a r10k core it is listed as 'Hit Writeback Invalidate (D)' but here this is a 4kEc. The address used is a SRAM shared with a embedded DSP on the same SoC. From a RevEng PoV it is helpful to see there is a such cache access, as I can separate better the peripheral involved. I'm happy using a trace event instead. Jiaxun, can you list me the list of opcodes QEMU can safely ignore from the TCG emulation PoV? That way we can comment them in the code such: switch (op) { case 9: /* Index Store Tag */ ... break; case 5: /* Index Load Tag */ ... break; case X: case Y: case Z: /* No-Op for QEMU */ ... break; default: qemu_log_mask(LOG_UNIMP, "cache %u\n", op); } Thanks, Phil. > > thanks > -- PMM >
On 8/6/20 11:37 PM, Philippe Mathieu-Daudé wrote: > On 8/6/20 10:51 PM, Peter Maydell wrote: >> On Thu, 6 Aug 2020 at 21:31, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >>> >>> On 8/6/20 8:01 PM, Jiaxun Yang wrote: >>>> 在 2020/8/6 下午8:26, Philippe Mathieu-Daudé 写道: >>>>> We only implement the Index[Store/Load]Tag from the 'cache' opcode. >>>>> Instead of ignoring the other cache operations, report them as >>>>> unimplemented. >>>> >>>> Hmm, I don't think we have anything to do with Invalidate/Writeback etc. >>>> opcodes >>>> in QEMU. Why do we log this? >>> >>> I'm noticed this code is run on Linux 3.3.8 (4KEc): >>> >>> 8880: 3082000f andi v0,a0,0xf >>> 8884: 10800008 beqz a0,88a8 >>> 8888: 00a21021 addu v0,a1,v0 >>> 888c: 08002227 j 889c >>> 8890: 00001821 move v1,zero >>> 8894: bcf90000 cache 0x19,0(a3) >>> 8898: 24630010 addiu v1,v1,16 >>> 889c: 0062302b sltu a2,v1,v0 >>> 88a0: 14c0fffc bnez a2,8894 >>> 88a4: 00833821 addu a3,a0,v1 >>> 88a8: 03e00008 jr ra >>> 88ac: 00000000 nop >>> >>> Why silently ignore the opcode is not implemented instead of logging it? >> >> I think the question is whether the opcode is supposed to have >> some behaviour which we're not implementing, or whether "no-op" >> is the correct behaviour for it (which it usually is for >> cache invalidate type operations; compare the way the Arm >> cache ops like IC_IALLU are just ARM_CP_NOP ops). > > OK now I understand better, thanks. > > I haven't found useful information about this 0x19=25 opcode value. Just to close this thread, some findings from last WE: - I couldn't find where Linux 3.3.8 use that op - I eventually figured out it comes from a kernel module called 'tiatm'. - This kmod is released by OpenWRT in packages named kmod-sangam-atm-annex - Googling for strings from the object, this file has been added in [1] based on the file included in [2] - Someone imported these files in a git repo and published - There is a commented reference [4] as: #define DataCacheHitInvalidate(a) {__asm__(" cache 17, (%0)" : : "r" (a));} #define DataCacheHitWriteback(a) {__asm__(" cache 25, (%0)" : : "r" (a));} - Also referenced (not commented) in [5] "Linux atm module implementation". For my use I'm happy using a trace event: -- >8 -- diff --git a/target/mips/op_helper.c b/target/mips/op_helper.c index 7f87e57c8e..71b28ede2d 100644 --- a/target/mips/op_helper.c +++ b/target/mips/op_helper.c @@ -30,2 +30,3 @@ #include "sysemu/kvm.h" +#include "trace.h" @@ -1577,2 +1578,4 @@ void helper_cache(CPUMIPSState *env, target_ulong addr, uint32_t op) target_ulong index = addr & 0x1fffffff; + + trace_cache_op(op, addr); if (op == 9) { diff --git a/target/mips/trace-events b/target/mips/trace-events index ba87fe6062..8a60f23bbd 100644 --- a/target/mips/trace-events +++ b/target/mips/trace-events @@ -2,2 +2,5 @@ +# op_helper.c +cache_op(uint32_t op, uint64_t addr) "cache op:%u paddr:0x%" PRIx64 + # translate.c --- [1] https://git.openwrt.org/?p=openwrt/svn-archive/archive.git;a=commit;h=5a8a8f35c5a356f7167c3b3a3ca00f0780d86473 [2] https://dev.archive.openwrt.org/ticket/1411.html [3] https://github.com/wolfhechel/ar7-atm [4] https://github.com/wolfhechel/ar7-atm/blob/master/cpswhal_cpsar.h#L84 [5] https://github.com/wolfhechel/ar7-atm/blob/master/tn7atm.c#L479 > > On a r10k core it is listed as 'Hit Writeback Invalidate (D)' but here > this is a 4kEc. The address used is a SRAM shared with a embedded DSP > on the same SoC. From a RevEng PoV it is helpful to see there is a such > cache access, as I can separate better the peripheral involved. > I'm happy using a trace event instead. > > Jiaxun, can you list me the list of opcodes QEMU can safely ignore from > the TCG emulation PoV? That way we can comment them in the code such: > > switch (op) { > case 9: > /* Index Store Tag */ > ... > break; > case 5: > /* Index Load Tag */ > ... > break; > case X: > case Y: > case Z: > /* No-Op for QEMU */ > ... > break; > default: > qemu_log_mask(LOG_UNIMP, "cache %u\n", op); > } > > Thanks, > > Phil. > >> >> thanks >> -- PMM >> >
在 2020/8/11 上午1:21, Philippe Mathieu-Daudé 写道: > On 8/6/20 11:37 PM, Philippe Mathieu-Daudé wrote: >> On 8/6/20 10:51 PM, Peter Maydell wrote: >>> On Thu, 6 Aug 2020 at 21:31, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >>>> On 8/6/20 8:01 PM, Jiaxun Yang wrote: >>>>> 在 2020/8/6 下午8:26, Philippe Mathieu-Daudé 写道: >>>>>> We only implement the Index[Store/Load]Tag from the 'cache' opcode. >>>>>> Instead of ignoring the other cache operations, report them as >>>>>> unimplemented. [...] >> On a r10k core it is listed as 'Hit Writeback Invalidate (D)' but here >> this is a 4kEc. The address used is a SRAM shared with a embedded DSP >> on the same SoC. From a RevEng PoV it is helpful to see there is a such >> cache access, as I can separate better the peripheral involved. >> I'm happy using a trace event instead. >> >> Jiaxun, can you list me the list of opcodes QEMU can safely ignore from >> the TCG emulation PoV? That way we can comment them in the code such: Hi Phil, I believe we have nothing to do with all VA Hit based invalidate, writeback, fetch and lock, According to MD00086-2B-MIPS32BIS-AFP, the Code (Bit[20:18]) should be 0b100 (Hit Inavlidate), 0b101(Hit Fill), 0b110 (Hit FB), 0b111 (Fetch and Lock). I'm unsure about what applications expected from Index based ops, so we'd better keep a log for them. What I can say is Linux rarely use Index based ops. Thanks. - Jiaxun
在 2020/8/11 上午1:21, Philippe Mathieu-Daudé 写道: > On 8/6/20 11:37 PM, Philippe Mathieu-Daudé wrote: >> On 8/6/20 10:51 PM, Peter Maydell wrote: >>> On Thu, 6 Aug 2020 at 21:31, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >>>> On 8/6/20 8:01 PM, Jiaxun Yang wrote: >>>>> 在 2020/8/6 下午8:26, Philippe Mathieu-Daudé 写道: >>>>>> We only implement the Index[Store/Load]Tag from the 'cache' opcode. >>>>>> Instead of ignoring the other cache operations, report them as >>>>>> unimplemented. >>>>> Hmm, I don't think we have anything to do with Invalidate/Writeback etc. >>>>> opcodes >>>>> in QEMU. Why do we log this? >>>> I'm noticed this code is run on Linux 3.3.8 (4KEc): >>>> >>>> 8880: 3082000f andi v0,a0,0xf >>>> 8884: 10800008 beqz a0,88a8 >>>> 8888: 00a21021 addu v0,a1,v0 >>>> 888c: 08002227 j 889c >>>> 8890: 00001821 move v1,zero >>>> 8894: bcf90000 cache 0x19,0(a3) >>>> 8898: 24630010 addiu v1,v1,16 >>>> 889c: 0062302b sltu a2,v1,v0 >>>> 88a0: 14c0fffc bnez a2,8894 >>>> 88a4: 00833821 addu a3,a0,v1 >>>> 88a8: 03e00008 jr ra >>>> 88ac: 00000000 nop >>>> >>>> Why silently ignore the opcode is not implemented instead of logging it? >>> I think the question is whether the opcode is supposed to have >>> some behaviour which we're not implementing, or whether "no-op" >>> is the correct behaviour for it (which it usually is for >>> cache invalidate type operations; compare the way the Arm >>> cache ops like IC_IALLU are just ARM_CP_NOP ops). >> OK now I understand better, thanks. >> >> I haven't found useful information about this 0x19=25 opcode value. > Just to close this thread, some findings from last WE: > > - I couldn't find where Linux 3.3.8 use that op > - I eventually figured out it comes from a kernel module called 'tiatm'. > - This kmod is released by OpenWRT in packages named kmod-sangam-atm-annex > - Googling for strings from the object, this file has been added in [1] > based on the file included in [2] > - Someone imported these files in a git repo and published > - There is a commented reference [4] as: > > #define DataCacheHitInvalidate(a) {__asm__(" cache 17, (%0)" > : : "r" (a));} > #define DataCacheHitWriteback(a) {__asm__(" cache 25, (%0)" > : : "r" (a));} > > - Also referenced (not commented) in [5] "Linux atm module implementation". > > For my use I'm happy using a trace event: > > -- >8 -- FYI, I took a look at MIPS M14K (interAptiv) RTL from MIPSOpen project, HitInvalidate and HitWriteback cache Ops to L2/L3 Cache will also act on L1 Cache. So probably that's kinda... Undocumented trick... Thanks. - Jiaxun
On 8/13/20 5:23 PM, Jiaxun Yang wrote: > 在 2020/8/11 上午1:21, Philippe Mathieu-Daudé 写道: >> On 8/6/20 11:37 PM, Philippe Mathieu-Daudé wrote: >>> On 8/6/20 10:51 PM, Peter Maydell wrote: >>>> On Thu, 6 Aug 2020 at 21:31, Philippe Mathieu-Daudé >>>> <f4bug@amsat.org> wrote: >>>>> On 8/6/20 8:01 PM, Jiaxun Yang wrote: >>>>>> 在 2020/8/6 下午8:26, Philippe Mathieu-Daudé 写道: >>>>>>> We only implement the Index[Store/Load]Tag from the 'cache' opcode. >>>>>>> Instead of ignoring the other cache operations, report them as >>>>>>> unimplemented. >>>>>> Hmm, I don't think we have anything to do with >>>>>> Invalidate/Writeback etc. >>>>>> opcodes >>>>>> in QEMU. Why do we log this? >>>>> I'm noticed this code is run on Linux 3.3.8 (4KEc): >>>>> >>>>> 8880: 3082000f andi v0,a0,0xf >>>>> 8884: 10800008 beqz a0,88a8 >>>>> 8888: 00a21021 addu v0,a1,v0 >>>>> 888c: 08002227 j 889c >>>>> 8890: 00001821 move v1,zero >>>>> 8894: bcf90000 cache 0x19,0(a3) >>>>> 8898: 24630010 addiu v1,v1,16 >>>>> 889c: 0062302b sltu a2,v1,v0 >>>>> 88a0: 14c0fffc bnez a2,8894 >>>>> 88a4: 00833821 addu a3,a0,v1 >>>>> 88a8: 03e00008 jr ra >>>>> 88ac: 00000000 nop >>>>> >>>>> Why silently ignore the opcode is not implemented instead of >>>>> logging it? >>>> I think the question is whether the opcode is supposed to have >>>> some behaviour which we're not implementing, or whether "no-op" >>>> is the correct behaviour for it (which it usually is for >>>> cache invalidate type operations; compare the way the Arm >>>> cache ops like IC_IALLU are just ARM_CP_NOP ops). >>> OK now I understand better, thanks. >>> >>> I haven't found useful information about this 0x19=25 opcode value. >> Just to close this thread, some findings from last WE: >> >> - I couldn't find where Linux 3.3.8 use that op >> - I eventually figured out it comes from a kernel module called 'tiatm'. >> - This kmod is released by OpenWRT in packages named >> kmod-sangam-atm-annex >> - Googling for strings from the object, this file has been added in [1] >> based on the file included in [2] >> - Someone imported these files in a git repo and published >> - There is a commented reference [4] as: >> >> #define DataCacheHitInvalidate(a) {__asm__(" cache 17, (%0)" >> : : "r" (a));} >> #define DataCacheHitWriteback(a) {__asm__(" cache 25, (%0)" >> : : "r" (a));} >> >> - Also referenced (not commented) in [5] "Linux atm module >> implementation". >> >> For my use I'm happy using a trace event: >> >> -- >8 -- > > FYI, I took a look at MIPS M14K (interAptiv) RTL from MIPSOpen project, > HitInvalidate and HitWriteback cache Ops to L2/L3 Cache will also act > on L1 Cache. So probably that's kinda... Undocumented trick... Uh... Thanks for having a look! > > Thanks. > > - Jiaxun >
在 2020/8/7 上午4:51, Peter Maydell 写道: > On Thu, 6 Aug 2020 at 21:31, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> On 8/6/20 8:01 PM, Jiaxun Yang wrote: >>> 在 2020/8/6 下午8:26, Philippe Mathieu-Daudé 写道: >>>> We only implement the Index[Store/Load]Tag from the 'cache' opcode. >>>> Instead of ignoring the other cache operations, report them as >>>> unimplemented. >>> Hmm, I don't think we have anything to do with Invalidate/Writeback etc. >>> opcodes >>> in QEMU. Why do we log this? >> I'm noticed this code is run on Linux 3.3.8 (4KEc): >> >> 8880: 3082000f andi v0,a0,0xf >> 8884: 10800008 beqz a0,88a8 >> 8888: 00a21021 addu v0,a1,v0 >> 888c: 08002227 j 889c >> 8890: 00001821 move v1,zero >> 8894: bcf90000 cache 0x19,0(a3) >> 8898: 24630010 addiu v1,v1,16 >> 889c: 0062302b sltu a2,v1,v0 >> 88a0: 14c0fffc bnez a2,8894 >> 88a4: 00833821 addu a3,a0,v1 >> 88a8: 03e00008 jr ra >> 88ac: 00000000 nop >> >> Why silently ignore the opcode is not implemented instead of logging it? > I think the question is whether the opcode is supposed to have > some behaviour which we're not implementing, or whether "no-op" > is the correct behaviour for it (which it usually is for > cache invalidate type operations; compare the way the Arm > cache ops like IC_IALLU are just ARM_CP_NOP ops). Probably we should skip Inv & WB opcode and log other undefined ops? Otherwise the log may be flushed by Cache ops. Thanks. - Jiaxun > > thanks > -- PMM
© 2016 - 2024 Red Hat, Inc.