Re: [PATCH v4 00/21] Add Qualcomm Minidump kernel driver related support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 7/18/2023 8:33 PM, Mukesh Ojha wrote:


On 7/6/2023 10:50 PM, Mathieu Poirier wrote:
On Mon, Jul 03, 2023 at 02:05:58PM -0700, Trilok Soni wrote:
On 7/2/2023 1:29 AM, Krzysztof Kozlowski wrote:
On 30/06/2023 18:04, Mukesh Ojha wrote:

We don't add layers when they are not needed, and never when there is no
actual user.  If you need the extra "complexity" later, then add it
later when it is needed as who knows when that will ever be.

Please redo this series based on that, thanks.

My bigger issue with this whole series is what would this all look
like if every SoC vendor upstreamed their own custom dumping
mechanism. That would be a mess. (I have similar opinions on the
$soc-vendor hypervisors.)

Mukesh,

LPC CFP is still open. There will be also Android and Kernel Debugging
LPC microconference tracks. Coming with a unified solution could be a
great topic for LPC. Solutions targeting only one user are quite often
frowned upon.

LPC is far out and in November. Can we not have others speak up if they have the similar solution now? We can expand this to linux-kernel and ask for the other SOC vendors to chime in. I am sure that we may have existing solutions which came in for the one user first like Intel RDT if I remember. I am sure ARM MPAM usecase was present at that time but Intel RDT based solution which
was x86 specific but accepted.

I am not familiar with Intel RDT and Arm MPAM but the community is always
improving on the way it does things.

LPC is indeed far out in November but it is an opportunity to cover the
groundwork needed to have this discussion.  It is always best to improve on something then introduce something new.  Even better if something specific such
as Intel RDT and Arm MPAM can be made more generic.  A perfect example is
hwtracing Linus referred to.  The perf framework wasn't a perfect fit but it was enhanced to accommodate our requirements.  I suggest to look at what is currently available and come up with a strategy to be presented at LPC - event better if you have a prototype.  If you can't find anything or the drawbacks inherent to each avenue outweigh the benefits then we can have that conversation at LPC.

I was checking hwtracing[1] and pmu interface introduction of
address filtering[3] from analogy point of view, which i think you
meant that perf framework was extended to accommodate this.

Minidump is quite different and simple in its way to address the problem
of debugging on end user devices with minimum data captured to debug crashes and this patch series is inline with similar (core + backend)
implementation done for stm patches[1] where stm core was developed
and intel trace hub get hooked into it and later it got reused in [2] by coresight-stm driver.

I am still exploring if something available we can reuse but it seems unlikely at the moment to already available something in the kernel with
similar use case.


I explored about kdump and fadump(PPC) but they take another route to boot capture kernel, FAdump is even optimized and do not even boot
capture kernel instead reboot the same kernel with minimal
memory and once the reading of crash kernel region is complete
from user space it release the memories.

Latency in booting another kernel may not acceptable to boot time
sensitive devices like mobile, tablet etc., also to boot another
kernel will have security implication with user data..

So, Minidump is limited in its capability and uses firmware infra
to dump registered entries and boot afresh. So, it need to be
presented what need to be dumped via Minidump registration API.

If there is no comments, would like to go ahead with the next
revision of the patchset.

-Mukesh

-Mukesh

[1]
https://lwn.net/Articles/650245/

[2]
https://lwn.net/Articles/674201/

[3]
https://lore.kernel.org/lkml/1461771888-10409-1-git-send-email-alexander.shishkin@xxxxxxxxxxxxxxx/




---Trilok Soni



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux