From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
Huacai Chen <chenhc@lemote.com>,
Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [PATCH-for-5.2] target/mips: Report unimplemented cache() operations
Date: Mon, 10 Aug 2020 19:21:12 +0200 [thread overview]
Message-ID: <6cecb59e-3a78-907c-cf63-225b4efbca01@amsat.org> (raw)
In-Reply-To: <a620f323-e42a-e75e-0491-228c480fa55b@amsat.org>
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
>>
>
next prev parent reply other threads:[~2020-08-10 18:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-06 12:26 [PATCH-for-5.2] target/mips: Report unimplemented cache() operations Philippe Mathieu-Daudé
2020-08-06 18:01 ` Jiaxun Yang
2020-08-06 20:11 ` Philippe Mathieu-Daudé
2020-08-06 20:51 ` Peter Maydell
2020-08-06 21:37 ` Philippe Mathieu-Daudé
2020-08-10 17:21 ` Philippe Mathieu-Daudé [this message]
2020-08-13 10:58 ` Jiaxun Yang
2020-08-13 15:23 ` Jiaxun Yang
2020-08-13 17:59 ` Philippe Mathieu-Daudé
2020-08-07 7:57 ` Jiaxun Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6cecb59e-3a78-907c-cf63-225b4efbca01@amsat.org \
--to=f4bug@amsat.org \
--cc=aleksandar.qemu.devel@gmail.com \
--cc=aleksandar.rikalo@syrmia.com \
--cc=aurelien@aurel32.net \
--cc=chenhc@lemote.com \
--cc=jiaxun.yang@flygoat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).