lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <tencent_525B0DBF67E67116595BAF23@qq.com>
Date: Wed, 4 Sep 2024 15:47:25 +0800
From: "虞陆铭" <luming.yu@...ngroup.cn>
To: "Yang Jialong 杨佳龙" <jialong.yang@...ngroup.cn>, "mpe" <mpe@...erman.id.au>, "npiggin" <npiggin@...il.com>, "christophe.leroy" <christophe.leroy@...roup.eu>, "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>
Cc: "shenghui.qu" <shenghui.qu@...ngroup.cn>, "linuxppc-dev" <linuxppc-dev@...ts.ozlabs.org>, "linux-kernel" <linux-kernel@...r.kernel.org>, "Steven Rostedt" <rostedt@...dmis.org>, "Masami Hiramatsu" <mhiramat@...nel.org>, "Karol Herbst" <karolherbst@...il.com>, "Pekka Paalanen" <ppaalanen@...il.com>, "nouveau" <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH v1 1/2] powerpc/mmiotrace: Add MMIO Tracing tool for PowerPC

Hi,

the patch set and mmio trace capability helped us to track down to the root cause of  a mysterious EEH only on powernv platform
 triggered by a testpmd dpdk user mode driver (UIO) by comparing the mmio trace from UIO and native kernel driver from the same nic. 
And the problem is solved by switch to VFIO driver as backend.

the problem is the mmiotrace could not capture user mode mmio which I think it could be limitation by its current design.

so, I think we could tidy up the patch and do some feature enhancement then we can submit again for the debug value of the patch.
As it really is painful when EEH A/B record doesn't point to a clear root cause or suffient details that can help us to fix  driver code for the unaligned
MMIO for a 3rd party nic vendor on powernv platform.
 
Cheers,
Luming
------------------ Original ------------------
From:  "Yang Jialong 杨佳龙"<jialong.yang@...ngroup.cn>;
Date:  Fri, Jun 28, 2024 04:21 PM
To:  "mpe"<mpe@...erman.id.au>; "npiggin"<npiggin@...il.com>; "christophe.leroy"<christophe.leroy@...roup.eu>; "Naveen N. Rao"<naveen.n.rao@...ux.ibm.com>; 
Cc:  "虞陆铭"<luming.yu@...ngroup.cn>; "shenghui.qu"<shenghui.qu@...ngroup.cn>; "linuxppc-dev"<linuxppc-dev@...ts.ozlabs.org>; "linux-kernel"<linux-kernel@...r.kernel.org>; "Steven Rostedt"<rostedt@...dmis.org>; "Masami Hiramatsu"<mhiramat@...nel.org>; "Karol Herbst"<karolherbst@...il.com>; "Pekka Paalanen"<ppaalanen@...il.com>; "nouveau"<nouveau@...ts.freedesktop.org>; 
Subject:  Re: [PATCH v1 1/2] powerpc/mmiotrace: Add MMIO Tracing tool for PowerPC

 


在 2024/6/28 15:02, Michael Ellerman 写道:
> Jialong Yang <jialong.yang@...ngroup.cn> writes:
>> mmiotrace is a useful tool to trace MMIO accesses. Nowadays, it only
>> supported on x86 and x86_64 platforms.
> I've never used mmiotrace, and don't know it well.
>
> I'm not necessarily opposed to merging it, but AFAIK it was mostly used
> for reverse engineering proprietary drivers, where the driver itself
> couldn't be easily instrumented. Is that what you're using it for?

Yes. Just like you think. We have used it for network stack debug in 
ppc64le.


>
> For drivers where we have the source wouldn't it be easier to just use
> tracepoints in the MMIO accessors?


Tracepoints need pre-defined. And in some big driver, it's not easy to 
overwrite

all points where access registers in io area. And tracepoint is C 
function level filter.

mmiotrace is similar to set tracepoints in writel/readl... But it can do 
deeperly.

mmiotrace is a asm level filter tool. It doesn't care what have done in 
C level. It will

only find what have done by asm, such as stw(store word)/lw(load word),  
just like standing

in the view of device.


>
> Is it still in-use/maintained on the x86 side?


Here is some core file patches number in x86:

|      | mmio_mod.c | kmmio.c | pf_in.* | testmmiotrace.c |
|------+------------+---------+---------+-----------------|
| 2022 |               1 |            3 | |                  |
| 2021 |               2 |            1 |               |         |
| 2020 |               4 |            4 | |               1 |
| 2019 |               2 |            1 |            1 |               4 |
| 2018 |                  |            2 |               |          |
| 2017 |               2 |            2 | |               1 |
| 2016 |               1 |            2 |            1 |        |
| 2014 |                  |            1 |               |          |
| 2013 |               1 |               |               |          |
| 2012 |               1 |               | |                  |
| 2011 |               3 |               |            1 |         |
| 2010 |               1 |            3 |            2 |               1 |
| 2009 |               4 |          19 | |               3 |
| 2008 |             13 |            5 |            2 |               3 |

>
>> Here is a support for powerpc.
>> The manual is located at Documentation/trace/mmiotrace.rst which means
>> I have not changed user API. People will be easy to use it.
>> Almost all files are copied from x86/mm, there are only some
>> differences from hardware and architectures software.
>>
>> LINK: https://lore.kernel.org/lkml/20080127195536.50809974@daedalus.pq.iki.fi/
>>
>> Signed-off-by: Jialong Yang <jialong.yang@...ngroup.cn>
>> ---
>>   arch/powerpc/Kconfig.debug       |   3 +
>>   arch/powerpc/mm/Makefile         |   1 +
>>   arch/powerpc/mm/kmmio.c          | 649 +++++++++++++++++++++++++++++++
>>   arch/powerpc/mm/mmio-mod.c       | 414 ++++++++++++++++++++
>>   arch/powerpc/mm/mmiotrace_arch.c | 149 +++++++
>>   arch/powerpc/mm/mmiotrace_arch.h |  25 ++
>>   arch/powerpc/mm/pf_in.c          | 185 +++++++++
>>   arch/powerpc/mm/pf_in.h          |  33 ++
>>   8 files changed, 1459 insertions(+)
>    
> At a glance most of that code could be shared between arches. I don't
> think I can merge that as-is, without some attempt to split the generic
> parts out.


Right.

I just copy them from arch/x86/mm. There are many code not arch specific.


> cheers
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ