Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <1687955688-20809-1-git-send-email-quic_mojha@quicinc.com> <2023062814-chance-flounder-f002@gregkh>
In-Reply-To: <2023062814-chance-flounder-f002@gregkh>
From:   Rob Herring <robh+dt@kernel.org>
Date:   Wed, 28 Jun 2023 17:12:06 -0600
Message-ID: <CAL_JsqLO9yey2-4FcWsaGxijiS6hGL0SH9VoMuiyei-u9=Cv=w@mail.gmail.com>
Subject: Re: [PATCH v4 00/21] Add Qualcomm Minidump kernel driver related support
To:     Greg KH <gregkh@linuxfoundation.org>,
        Mukesh Ojha <quic_mojha@quicinc.com>
Cc:     corbet@lwn.net, agross@kernel.org, andersson@kernel.org,
        konrad.dybcio@linaro.org, krzysztof.kozlowski+dt@linaro.org,
        conor+dt@kernel.org, keescook@chromium.org, tony.luck@intel.com,
        gpiccoli@igalia.com, mathieu.poirier@linaro.org,
        catalin.marinas@arm.com, will@kernel.org, linus.walleij@linaro.org,
        andy.shevchenko@gmail.com, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
        devicetree@vger.kernel.org, linux-hardening@vger.kernel.org,
        linux-remoteproc@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Jun 28, 2023 at 9:45=E2=80=AFAM Greg KH <gregkh@linuxfoundation.org=
> wrote:
>
> On Wed, Jun 28, 2023 at 06:04:27PM +0530, Mukesh Ojha wrote:
> > Minidump is a best effort mechanism to collect useful and predefined da=
ta
> > for first level of debugging on end user devices running on Qualcomm So=
Cs.
> > It is built on the premise that System on Chip (SoC) or subsystem part =
of
> > SoC crashes, due to a range of hardware and software bugs. Hence, the
> > ability to collect accurate data is only a best-effort. The data collec=
ted
> > could be invalid or corrupted, data collection itself could fail, and s=
o on.
> >
> > Qualcomm devices in engineering mode provides a mechanism for generatin=
g
> > full system ramdumps for post mortem debugging. But in some cases it's
> > however not feasible to capture the entire content of RAM. The minidump
> > mechanism provides the means for selecting which snippets should be
> > included in the ramdump.
> >
> > Minidump kernel driver implementation is divided into two parts for
> > simplicity, one is minidump core which can also be called minidump
> > frontend(As API gets exported from this driver for registration with
> > backend) and the other part is minidump backend i.e, where the underlyi=
ng
> > implementation of minidump will be there. There could be different way
> > how the backend is implemented like Shared memory, Memory mapped IO
> > or Resource manager(gunyah) based where the guest region information is
> > passed to hypervisor via hypercalls.
> >
> >     Minidump Client-1     Client-2      Client-5    Client-n
> >              |               |              |             |
> >              |               |    ...       |   ...       |
> >              |               |              |             |
> >              |               |              |             |
> >              |               |              |             |
> >              |               |              |             |
> >              |               |              |             |
> >              |               |              |             |
> >              |           +---+--------------+----+        |
> >              +-----------+  qcom_minidump(core)  +--------+
> >                          |                       |
> >                          +------+-----+------+---+
> >                                 |     |      |
> >                                 |     |      |
> >                 +---------------+     |      +--------------------+
> >                 |                     |                           |
> >                 |                     |                           |
> >                 |                     |                           |
> >                 v                     v                           v
> >      +-------------------+      +-------------------+     +------------=
------+
> >      |qcom_minidump_smem |      |qcom_minidump_mmio |     | qcom_minidu=
mp_rm |
> >      |                   |      |                   |     |            =
      |
> >      +-------------------+      +-------------------+     +------------=
------+
> >        Shared memory              Memory mapped IO           Resource m=
anager
> >         (backend)                   (backend)                   (backen=
d)
> >
> >
> > Here, we will be giving all analogy of backend with SMEM as it is the
> > only implemented backend at present but general idea remains the same.
>
> If you only have one "backend" then you don't need the extra compexity
> here at all, just remove that whole middle layer please and make this
> much simpler and smaller and easier to review and possibly accept.

pstore already supports backends. Why aren't the above backends just
pstore backends rather than having an intermediate pstore backend in
RAM which then somehow gets moved into these minidump backends.

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

Rob