From: "Luck, Tony" <tony.luck@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Zaid Alali <zaidal@os.amperecomputing.com>,
rafael@kernel.org, lenb@kernel.org, james.morse@arm.com,
robert.moore@intel.com, Jonathan.Cameron@huawei.com,
ira.weiny@intel.com, Benjamin.Cheatham@amd.com,
dan.j.williams@intel.com, arnd@arndb.de, Avadhut.Naik@amd.com,
john.allen@amd.com, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, acpica-devel@lists.linux.dev
Subject: Re: [PATCH v7 9/9] ACPI: APEI: EINJ: Update the documentation for EINJv2 support
Date: Mon, 2 Jun 2025 10:02:15 -0700 [thread overview]
Message-ID: <aD3ZFyBW4SCyaGI9@agluck-desk3> (raw)
In-Reply-To: <20250601102554.GAaDwqsgCODzEne7Ow@fat_crate.local>
On Sun, Jun 01, 2025 at 12:25:54PM +0200, Borislav Petkov wrote:
> Some questions inline...
>
> On Sat, May 31, 2025 at 03:24:14PM -0700, Luck, Tony wrote:
> > EINJ V2 allows the user to perform multiple injections together.
> >
> > The component_idN/component_syndromeN pairs of files direct the
> > "where" and the "what" of each injection.
> >
> > But the kernel needs to know how many of these pairs to use
> > for an injection (to fill in a field in the structure passed
> > to the BIOS).
>
> The kernel could realloc on each write. Or we could allocate the struct to max
> elems and trim it before passing it down to BIOS.
The actual structure passed to BIOS is the same each time. Just the
set_error_type_with_address::einjv2_struct::component_arr_count
changed to indicate how many errors to inject. In theory the
driver could allocate and copy a correctly sized structure, but
Zaid's code here is simpler, an this is hardly a critical path.
> > User interface options:
> >
> > 1) User can zero out the component_idN/component_syndromeN pairs
> > that they don't need and have the kernel count how many injections
> > are requested by looping to find the zero terminator.
> >
> > 2) Kernel could zero all pairs after an injection to make the user
> > explicitly set the list of targets each time.
> >
> > 3) User provides the count vis the nr_components file (perhaps
> > needs a better name?)
>
> Yap, agree that the name is not optimal.
It can be dropped if we make the user zap previously supplied
component_idN/component_syndromeN pairs that are no longer
wanted.
>
> User can inject into each component pairs file and the kernel can put that in
> the tracking struct. So you have:
>
> # echo 4 > component_id0
> # echo A5A5A5A5 > component_syndrome0
> ... set other files and finish with usual
> # echo 1 > error_inject
>
> <--- here, it goes through each component pair and builds the structure to
> pass down the BIOS.
>
> And you track valid component pairs by setting the IDs to -1 or something else
> invalid.
This is just an improvement on my "option 1" (improved because all-ones
for the component ID is going to be invalid for sure, while all zeroes
could be a valid component).
>
> All those component IDs which have remained invalid after the error_inject
> write happens, get ignored - you gather only those which are valid and inject.
Or just stop collecting on the first invalid one.
> And this way you can keep the old values too and gather them again and inject
> again, over and over again.
>
> Right?
Yup.
-Tony
next prev parent reply other threads:[~2025-06-02 17:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 21:38 [PATCH v7 0/9] Enable EINJv2 Support Zaid Alali
2025-05-06 21:38 ` [PATCH v7 1/9] ACPICA: Update values to hex to follow ACPI specs Zaid Alali
2025-05-07 11:28 ` Rafael J. Wysocki
2025-05-06 21:38 ` [PATCH v7 2/9] ACPICA: Add EINJv2 get error type action Zaid Alali
2025-05-07 11:28 ` Rafael J. Wysocki
2025-05-06 21:38 ` [PATCH v7 3/9] ACPI: APEI: EINJ: Fix kernel test sparse warnings Zaid Alali
2025-05-07 11:31 ` Rafael J. Wysocki
2025-05-06 21:38 ` [PATCH v7 4/9] ACPI: APEI: EINJ: Remove redundant calls to einj_get_available_error_type Zaid Alali
2025-05-07 11:34 ` Rafael J. Wysocki
2025-05-08 17:57 ` Zaid Alali
2025-05-09 19:25 ` Rafael J. Wysocki
2025-05-06 21:38 ` [PATCH v7 5/9] ACPI: APEI: EINJ: Enable the discovery of EINJv2 capabilities Zaid Alali
2025-05-07 11:38 ` Rafael J. Wysocki
2025-05-28 20:55 ` Luck, Tony
2025-05-06 21:38 ` [PATCH v7 6/9] ACPI: APEI: EINJ: Add einjv2 extension struct Zaid Alali
2025-05-28 18:38 ` Luck, Tony
2025-05-29 15:28 ` Luck, Tony
2025-05-06 21:38 ` [PATCH v7 7/9] ACPI: APEI: EINJ: Add debugfs files for EINJv2 support Zaid Alali
2025-05-29 23:36 ` Luck, Tony
2025-05-06 21:38 ` [PATCH v7 8/9] ACPI: APEI: EINJ: Enable EINJv2 error injections Zaid Alali
2025-05-30 0:21 ` Luck, Tony
2025-05-06 21:38 ` [PATCH v7 9/9] ACPI: APEI: EINJ: Update the documentation for EINJv2 support Zaid Alali
2025-05-29 23:33 ` Luck, Tony
2025-05-30 10:27 ` Borislav Petkov
2025-05-30 20:52 ` Luck, Tony
2025-05-30 23:09 ` Luck, Tony
2025-05-31 9:20 ` Borislav Petkov
2025-05-31 22:24 ` Luck, Tony
2025-06-01 10:25 ` Borislav Petkov
2025-06-02 17:02 ` Luck, Tony [this message]
2025-06-02 23:41 ` Zaid Alali
2025-06-03 8:31 ` Borislav Petkov
2025-06-03 15:42 ` Luck, Tony
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=aD3ZFyBW4SCyaGI9@agluck-desk3 \
--to=tony.luck@intel.com \
--cc=Avadhut.Naik@amd.com \
--cc=Benjamin.Cheatham@amd.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=acpica-devel@lists.linux.dev \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=ira.weiny@intel.com \
--cc=james.morse@arm.com \
--cc=john.allen@amd.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=zaidal@os.amperecomputing.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.