qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
>>
> 


  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).