All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alison Schofield <alison.schofield@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Ben Widawsky <bwidawsk@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org,
	shiju.jose@huawei.com
Subject: Re: [PATCH v4 2/5] cxl/trace: Add TRACE support for CXL media-error records
Date: Thu, 12 Jan 2023 08:37:38 -0800	[thread overview]
Message-ID: <Y8A3Ulo/DnflNVQu@aschofie-mobl2> (raw)
In-Reply-To: <20230112111652.00000266@Huawei.com>

On Thu, Jan 12, 2023 at 11:16:52AM +0000, Jonathan Cameron wrote:
> On Thu, 15 Dec 2022 13:17:44 -0800
> alison.schofield@intel.com wrote:
> 
> > From: Alison Schofield <alison.schofield@intel.com>
> > 
> > CXL devices may support the retrieval of a device poison list.
> > Add a new trace event that the CXL subsystem may use to log
> > the media-error records returned in the poison list.
> > 
> > Log each media-error record as a trace event of type 'cxl_poison'.
> > 
> > When the poison list is requested by region, include the region name
> > and uuid in the trace event.
> > 
> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> 
> Hi Alison,
> 
> I'm wondering a bit if it makes sense to log/trace the MORE flag for each
> record.  That has some unusual semantics.  Like the other flags it's a
> characteristic of the underlying Get Poison List Output Payload, not a
> particularly Poison list entry. Unlike overflow and scanning which are
> reasonably a characteristic of each poison record in a given set read
> in one command, MORE is not.
> Imagine the following.
> 
> Read first N records, MORE set so we have that flag in all the trace
> records.
> Read next M records, MORE not set as list is less than N+M records.
> 
> Now userspace tooling has no idea about the mapping to underlying
> mailbox commands. So it sees this bit set for first N which is fine
> as there are more records following, but for the next M - 1 it might
> reasonably expect to see MORE set (as more records are getting traced)
> but it doesn't see it for any of them.
> 
> That seems less than intuitive. 
> 
> I'm not sure what to suggest... Seems wrong to 'make up a MORE flag' for
> those M-1 records.  Does it make sense to expose this flag at all?  In
> what way is it useful?
> 
> Jonathan

Thanks Jonathan - 

The FLAGs field today simply reflects the contents of the flags
field of the payload, which can be MORE, OVERFLOW, SCANNING.

Understand that 'MORE' seems useless to userspace however, I lean
towards giving userspace the complete truth, and letting userspace
ignore what is of no interest.

Perhaps a user wants to explore the boundaries of a devices
poison handling capacity. ie...use inject and get_poison and
see when the MORE flag appears. I don't know if it may appear
before the inject_max is reached.

So - I say keep MORE as is.

This discussion triggers another thought...

ATM, a devices max_mer - Max Media Error Records is not exposed in
sysfs, and this conversation makes me think it should be. It also,
comes to mind because I am exposing the inject_poison_limit to sysfs.

Users wanting to explore poison capabilities would be interested in
max_mer.

I'll add the max_mer to syfs in next rev.

Alison

> 
> 
> > ---
> >  drivers/cxl/core/mbox.c  |  6 ++-
> >  drivers/cxl/core/trace.h | 83 ++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 88 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> > index dfe24a2adfdb..c345af8a4afd 100644
> > --- a/drivers/cxl/core/mbox.c
> > +++ b/drivers/cxl/core/mbox.c
> > @@ -10,6 +10,7 @@
> >  #include <cxl.h>
> >  
> >  #include "core.h"
> > +#include "trace.h"
> >  
> >  static bool cxl_raw_allow_all;
> >  
> > @@ -899,7 +900,10 @@ int cxl_mem_get_poison(struct cxl_memdev *cxlmd, u64 offset, u64 len,
> >  		if (rc)
> >  			break;
> >  
> > -		/* TODO TRACE the media error records */
> > +		for (int i = 0; i < le16_to_cpu(po->count); i++)
> > +			trace_cxl_poison(cxlmd, to_pci_dev(cxlds->dev),
> > +					 cxlr, &po->record[i], po->flags,
> > +					 po->overflow_t);
> >  
> >  		/* Protect against an uncleared _FLAG_MORE */
> >  		nr_records = nr_records + le16_to_cpu(po->count);
> > diff --git a/drivers/cxl/core/trace.h b/drivers/cxl/core/trace.h
> > index 20ca2fe2ca8e..c7958311ce5f 100644
> > --- a/drivers/cxl/core/trace.h
> > +++ b/drivers/cxl/core/trace.h
> > @@ -8,6 +8,9 @@
> >  
> >  #include <cxl.h>
> >  #include <linux/tracepoint.h>
> > +#include <linux/pci.h>
> > +
> > +#include <cxlmem.h>
> >  
> >  #define CXL_RAS_UC_CACHE_DATA_PARITY	BIT(0)
> >  #define CXL_RAS_UC_CACHE_ADDR_PARITY	BIT(1)
> > @@ -103,6 +106,86 @@ TRACE_EVENT(cxl_aer_correctable_error,
> >  	)
> >  );
> >  
> > +#define __show_poison_source(source)                          \
> > +	__print_symbolic(source,                              \
> > +		{ CXL_POISON_SOURCE_UNKNOWN,   "Unknown"  },  \
> > +		{ CXL_POISON_SOURCE_EXTERNAL,  "External" },  \
> > +		{ CXL_POISON_SOURCE_INTERNAL,  "Internal" },  \
> > +		{ CXL_POISON_SOURCE_INJECTED,  "Injected" },  \
> > +		{ CXL_POISON_SOURCE_VENDOR,    "Vendor"   })
> > +
> > +#define show_poison_source(source)			     \
> > +	(((source > CXL_POISON_SOURCE_INJECTED) &&	     \
> > +	 (source != CXL_POISON_SOURCE_VENDOR)) ? "Reserved"  \
> > +	 : __show_poison_source(source))
> > +
> > +#define show_poison_flags(flags)                             \
> > +	__print_flags(flags, "|",                            \
> > +		{ CXL_POISON_FLAG_MORE,      "More"     },   \
> > +		{ CXL_POISON_FLAG_OVERFLOW,  "Overflow"  },  \
> > +		{ CXL_POISON_FLAG_SCANNING,  "Scanning"  })
> > +
> > +#define __cxl_poison_addr(record)					\
> > +	(le64_to_cpu(record->address))
> > +#define cxl_poison_record_dpa(record)					\
> > +	(__cxl_poison_addr(record) & CXL_POISON_START_MASK)
> > +#define cxl_poison_record_source(record)				\
> > +	(__cxl_poison_addr(record)  & CXL_POISON_SOURCE_MASK)
> > +#define cxl_poison_record_length(record)				\
> > +	(le32_to_cpu(record->length) * CXL_POISON_LEN_MULT)
> > +#define cxl_poison_overflow(flags, time)				\
> > +	(flags & CXL_POISON_FLAG_OVERFLOW ? le64_to_cpu(time) : 0)
> > +
> > +TRACE_EVENT(cxl_poison,
> > +
> > +	    TP_PROTO(struct cxl_memdev *memdev, const struct pci_dev *pcidev,
> > +		     struct cxl_region *region,
> > +		     const struct cxl_poison_record *record,
> > +		     u8 flags, __le64 overflow_t),
> > +
> > +	    TP_ARGS(memdev, pcidev, region, record, flags, overflow_t),
> > +
> > +	    TP_STRUCT__entry(
> > +		__string(memdev, dev_name(&memdev->dev))
> > +		__string(pcidev, dev_name(&pcidev->dev))
> > +		__string(region, region)
> > +		__field(u64, overflow_t)
> > +		__field(u64, dpa)
> > +		__field(u32, length)
> > +		__array(char, uuid, 16)
> > +		__field(u8, source)
> > +		__field(u8, flags)
> > +	    ),
> > +
> > +	    TP_fast_assign(
> > +		__assign_str(memdev, dev_name(&memdev->dev));
> > +		__assign_str(pcidev, dev_name(&pcidev->dev));
> > +		__entry->overflow_t = cxl_poison_overflow(flags, overflow_t);
> > +		__entry->dpa = cxl_poison_record_dpa(record);
> > +		__entry->length = cxl_poison_record_length(record);
> > +		__entry->source = cxl_poison_record_source(record);
> > +		__entry->flags = flags;
> > +		if (region) {
> > +			__assign_str(region, dev_name(&region->dev));
> > +			memcpy(__entry->uuid, &region->params.uuid, 16);
> > +		} else {
> > +			__assign_str(region, "");
> > +			memset(__entry->uuid, 0, 16);
> > +		}
> > +	    ),
> > +
> > +	    TP_printk("memdev=%s pcidev=%s region=%s region_uuid=%pU dpa=0x%llx length=0x%x source=%s flags=%s overflow_time=%llu",
> > +		__get_str(memdev),
> > +		__get_str(pcidev),
> > +		__get_str(region),
> > +		__entry->uuid,
> > +		__entry->dpa,
> > +		__entry->length,
> > +		show_poison_source(__entry->source),
> > +		show_poison_flags(__entry->flags),
> > +		__entry->overflow_t)
> > +);
> > +
> >  #endif /* _CXL_EVENTS_H */
> >  
> >  #define TRACE_INCLUDE_FILE trace
> 

  reply	other threads:[~2023-01-12 16:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-15 21:17 [PATCH v4 0/5] CXL Poison List Retrieval & Tracing alison.schofield
2022-12-15 21:17 ` [PATCH v4 1/5] cxl/mbox: Add GET_POISON_LIST mailbox command alison.schofield
2023-01-06 16:56   ` Alison Schofield
2022-12-15 21:17 ` [PATCH v4 2/5] cxl/trace: Add TRACE support for CXL media-error records alison.schofield
2023-01-12 11:16   ` Jonathan Cameron
2023-01-12 16:37     ` Alison Schofield [this message]
2022-12-15 21:17 ` [PATCH v4 3/5] cxl/memdev: Add trigger_poison_list sysfs attribute alison.schofield
2022-12-20 16:20   ` Jonathan Cameron
2022-12-15 21:17 ` [PATCH v4 4/5] cxl/region: " alison.schofield
2022-12-15 21:17 ` [PATCH v4 5/5] tools/testing/cxl: Mock support for Get Poison List alison.schofield

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=Y8A3Ulo/DnflNVQu@aschofie-mobl2 \
    --to=alison.schofield@intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=bwidawsk@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=shiju.jose@huawei.com \
    --cc=vishal.l.verma@intel.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.