From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Cc: Ira Weiny <ira.weiny@intel.com>, <linux-cxl@vger.kernel.org>,
<qemu-devel@nongnu.org>, <dan.j.williams@intel.com>,
<dave@stgolabs.net>, <alison.schofield@intel.com>,
<shiju.jose@huawei.com>
Subject: Re: [PATCH v3 2/2] cxl/core: add poison creation event handler
Date: Wed, 8 May 2024 17:15:14 +0100 [thread overview]
Message-ID: <20240508171514.000031dd@Huawei.com> (raw)
In-Reply-To: <0d0b087f-9aa4-45d3-9412-0b1a6a005c52@fujitsu.com>
On Fri, 3 May 2024 18:42:31 +0800
Shiyang Ruan <ruansy.fnst@fujitsu.com> wrote:
> 在 2024/4/24 1:57, Ira Weiny 写道:
> > Shiyang Ruan wrote:
> >> Currently driver only traces cxl events, poison creation (for both vmem
> >> and pmem type) on cxl memdev is silent. OS needs to be notified then it
> >> could handle poison pages in time. Per CXL spec, the device error event
> >> could be signaled through FW-First and OS-First methods.
> >>
> >> So, add poison creation event handler in OS-First method:
> >> - Qemu:
> >> - CXL device reports POISON creation event to OS by MSI by sending
> >> GMER/DER after injecting a poison record;
> >> - CXL driver:
> >> a. parse the POISON event from GMER/DER;
> >> b. translate poisoned DPA to HPA (PFN);
> >> c. enqueue poisoned PFN to memory_failure's work queue;
> >
> > I'm a bit confused by the need for this patch. Perhaps a bit more detail
> > here?
>
> Yes, I should have wrote more details.
>
> I want to check and make sure the HWPOISON on a CXL device (type3) is
> working properly. For example, a FSDAX filesystem created on a
> type3-pmem device, then it gets a POISON bit, the OS should be able to
> handle this POISON event: find the relevant process
>
> Currently I'm using Qemu with several simulated CXL devices, and using
> poison injection API of Qemu to create POISON records, but OS isn't
> notified. Only when we actively call list POISON records (cxl list -L)
> will the driver fetch them and log into trace events, then we see the
> POISON records. Memory failure wasn't triggered too.
>
Indeed - QEMU emulation of this is not complete. It should also be generating
the events. Ideally we'd even handle injecting silent poison (not yet detected
by the device) and have that generate the synchronous memory faults on an access.
> That's why I said "poison creation on cxl memdev is silent". Per spec,
> POISON creation should be notified to OS. Since not familiar with
> firmware part, I'm try adding this notification for OS-First.
>
> >
> > More comments below.
> >
> >>
> >> Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
> >> ---
> >> drivers/cxl/core/mbox.c | 119 +++++++++++++++++++++++++++++++++-----
> >> drivers/cxl/cxlmem.h | 8 +--
> >> include/linux/cxl-event.h | 18 +++++-
> >> 3 files changed, 125 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> >> index f0f54aeccc87..76af0d73859d 100644
> >> --- a/drivers/cxl/core/mbox.c
> >> +++ b/drivers/cxl/core/mbox.c
> >> @@ -837,25 +837,116 @@ int cxl_enumerate_cmds(struct cxl_memdev_state *mds)
> >> }
> >> EXPORT_SYMBOL_NS_GPL(cxl_enumerate_cmds, CXL);
> >>
> >> -void cxl_event_trace_record(const struct cxl_memdev *cxlmd,
> >> - enum cxl_event_log_type type,
> >> - enum cxl_event_type event_type,
> >> - const uuid_t *uuid, union cxl_event *evt)
> >> +static void cxl_report_poison(struct cxl_memdev *cxlmd, struct cxl_region *cxlr,
> >> + u64 dpa)
> >> {
> >> - if (event_type == CXL_CPER_EVENT_GEN_MEDIA)
> >> + u64 hpa = cxl_trace_hpa(cxlr, cxlmd, dpa);
> >> + unsigned long pfn = PHYS_PFN(hpa);
> >> +
> >> + if (!IS_ENABLED(CONFIG_MEMORY_FAILURE))
> >> + return;
> >> +
> >> + memory_failure_queue(pfn, MF_ACTION_REQUIRED);
> >
> > I thought that ras daemon was supposed to take care of this when the trace
> > event occurred. Alison is working on the HPA data for that path.
>
> It seems to save CXL trace events/memory-failures to DB and report to
> others, but cannot let OS call memory failure.
Interesting question of whose problem this is. For corrected
errors it's policy stuff that belongs in userspace, but for known
memory failure, it might want to be in kernel.
Shiju (+Cc) pointed me a the existing rasdaemon handling for corrected
errors (statistics get too bad, so memory offlined)
https://github.com/mchehab/rasdaemon/commit/9ae6b70effb8adc9572debc800b8e16173f74bb8
Poison detection via scrub though is reported via CPER Memory Error Section with
"Scrub uncorrected error" set. That triggers apei handling. On
x86 looks to be apei_mce_report_mem_error(). Also triggers
the ghes_do_memory_failure_path() and ultimately memory_failure().
Conveniently there was a patch fixing the sync path last year
that includes info on what happens in async case.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a70297d2213253853e95f5b49651f924990c6d3b
"In addition, for aysnchronous errors, kernel will notify the
process who owns the poisoned page by sending SIGBUS with BUS_MCERRR_A0
in early kill mode."
So I think the kernel should probably do the same for CXL poison
error records when it gets them.
Jonathan
next prev parent reply other threads:[~2024-05-08 16:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 7:50 [PATCH v3 0/2] cxl: add poison creation event handler Shiyang Ruan via
2024-04-17 7:50 ` [PATCH v3 1/2] cxl/core: correct length of DPA field masks Shiyang Ruan via
2024-04-23 17:35 ` Ira Weiny
2024-04-23 17:35 ` Dan Williams
2024-04-23 17:42 ` Alison Schofield
2024-04-23 21:04 ` Ira Weiny
2024-04-25 10:05 ` Shiyang Ruan via
2024-04-25 16:04 ` Ira Weiny
2024-04-30 21:00 ` Alison Schofield
2024-05-03 11:37 ` Shiyang Ruan via
2024-04-17 7:50 ` [PATCH v3 2/2] cxl/core: add poison creation event handler Shiyang Ruan via
2024-04-17 17:30 ` Dave Jiang
2024-04-18 9:01 ` Shiyang Ruan via
2024-04-21 12:14 ` kernel test robot
2024-04-23 17:57 ` Ira Weiny
2024-05-03 10:42 ` Shiyang Ruan via
2024-05-08 16:15 ` Jonathan Cameron via [this message]
2024-04-23 18:40 ` Dan Williams
2024-05-03 11:32 ` Shiyang Ruan via
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=20240508171514.000031dd@Huawei.com \
--to=qemu-devel@nongnu.org \
--cc=Jonathan.Cameron@Huawei.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=ruansy.fnst@fujitsu.com \
--cc=shiju.jose@huawei.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).