Linux CXL
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: <ira.weiny@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	"Ben Widawsky" <bwidawsk@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	<linux-kernel@vger.kernel.org>, <linux-cxl@vger.kernel.org>
Subject: Re: [RFC V2 PATCH 06/11] cxl/mem: Trace DRAM Event Record
Date: Tue, 11 Oct 2022 14:47:12 +0100	[thread overview]
Message-ID: <20221011144712.00004a05@huawei.com> (raw)
In-Reply-To: <20221010224131.1866246-7-ira.weiny@intel.com>

On Mon, 10 Oct 2022 15:41:26 -0700
ira.weiny@intel.com wrote:

> From: Ira Weiny <ira.weiny@intel.com>
> 
> CXL rev 3.0 section 8.2.9.2.1.2 defines the DRAM Event Record.
> 
> Determine if the event read is a DRAM event record and if so trace the
> record.
> 
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> 

Trivial comments inline

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> diff --git a/include/trace/events/cxl.h b/include/trace/events/cxl.h
> index 82a8d3b750a2..7a90cfea348b 100644
> --- a/include/trace/events/cxl.h
> +++ b/include/trace/events/cxl.h
> @@ -230,6 +230,100 @@ TRACE_EVENT(general_media,
>  		)
>  );
>  

> +
> +TRACE_EVENT(dram,
> +
> +	TP_PROTO(const char *dev_name, enum cxl_event_log_type log,
> +		 struct cxl_event_dram *rec),
> +
> +	TP_ARGS(dev_name, log, rec),
> +
> +	TP_STRUCT__entry(
> +		CXL_EVT_TP_entry
> +		/* DRAM */
> +		__field(u64, phys_addr)
> +		__field(u8, descriptor)
> +		__field(u8, type)
> +		__field(u8, transaction_type)
> +		__field(u8, channel)
> +		__field(u16, validity_flags)
> +		__field(u16, column)	/* Out of order to pack trace record */
> +		__field(u32, nibble_mask)
> +		__field(u32, row)
> +		__array(u8, cor_mask, CXL_EVENT_DER_CORRECTION_MASK_SIZE)
> +		__array(u8, reserved, CXL_EVENT_DER_RES_SIZE)

If we are going to have this, why not put it at the end?  Will that affect the
packing badly?

> +		__field(u8, rank)	/* Out of order to pack trace record */
> +		__field(u8, bank_group)	/* Out of order to pack trace record */
> +		__field(u8, bank)	/* Out of order to pack trace record */
> +	),
> +
> +	TP_fast_assign(
> +		CXL_EVT_TP_fast_assign(dev_name, log, rec->hdr);
> +
> +		/* DRAM */
> +		__entry->phys_addr = le64_to_cpu(rec->phys_addr);
> +		__entry->descriptor = rec->descriptor;
> +		__entry->type = rec->type;
> +		__entry->transaction_type = rec->transaction_type;
> +		__entry->validity_flags = get_unaligned_le16(rec->validity_flags);
> +		__entry->channel = rec->channel;
> +		__entry->rank = rec->rank;
> +		__entry->nibble_mask = get_unaligned_le24(rec->nibble_mask);
> +		__entry->bank_group = rec->bank_group;
> +		__entry->bank = rec->bank;
> +		__entry->row = get_unaligned_le24(rec->row);
> +		__entry->column = get_unaligned_le16(rec->column);
> +		memcpy(__entry->cor_mask, &rec->correction_mask,
> +			CXL_EVENT_DER_CORRECTION_MASK_SIZE);
> +		memcpy(__entry->reserved, &rec->reserved,
> +			CXL_EVENT_DER_RES_SIZE);
> +	),
> +
> +	CXL_EVT_TP_printk("phys_addr=%llx volatile=%s desc='%s' type='%s' " \
> +		"trans_type='%s' channel=%u rank=%u nibble_mask=%x " \
> +		"bank_group=%u bank=%u row=%u column=%u cor_mask=%s " \
> +		"valid_flags='%s' reserved=%s",
> +		__entry->phys_addr & CXL_GMER_PHYS_ADDR_MASK,
> +		(__entry->phys_addr & CXL_GMER_PHYS_ADDR_VOLATILE) ? "TRUE" : "FALSE",
> +		show_event_desc_flags(__entry->descriptor),
> +		show_mem_event_type(__entry->type),
> +		show_trans_type(__entry->transaction_type),
> +		__entry->channel, __entry->rank, __entry->nibble_mask,
> +		__entry->bank_group, __entry->bank,
> +		__entry->row, __entry->column,
> +		__print_hex(__entry->cor_mask, CXL_EVENT_DER_CORRECTION_MASK_SIZE),
> +		show_dram_valid_flags(__entry->validity_flags),
> +		__print_hex(__entry->reserved, CXL_EVENT_DER_RES_SIZE)
> +		)
Probably one less tab on that trailing )?

> +);
> +
>  #endif /* _CXL_TRACE_EVENTS_H */
>  
>  /* This part must be outside protection */


  reply	other threads:[~2022-10-11 13:47 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-10 22:41 [RFC V2 PATCH 00/11] CXL: Process event logs ira.weiny
2022-10-10 22:41 ` [RFC V2 PATCH 01/11] cxl/mbox: Add debug of hardware error code ira.weiny
2022-10-11 10:41   ` Jonathan Cameron
2022-10-14 16:29   ` Davidlohr Bueso
2022-10-14 16:31     ` Davidlohr Bueso
2022-10-14 17:00       ` Ira Weiny
2022-10-10 22:41 ` [RFC V2 PATCH 02/11] cxl/mem: Implement Get Event Records command ira.weiny
2022-10-11 12:39   ` Jonathan Cameron
2022-10-14 19:21     ` Ira Weiny
2022-10-15 11:28   ` Steven Rostedt
2022-10-16 21:43     ` Ira Weiny
2022-10-20 21:50   ` Smita Koralahalli
2022-10-21  5:11     ` Ira Weiny
2022-10-10 22:41 ` [RFC V2 PATCH 03/11] cxl/mem: Implement Clear " ira.weiny
2022-10-10 22:41 ` [RFC V2 PATCH 04/11] cxl/mem: Clear events on driver load ira.weiny
2022-10-11 12:42   ` Jonathan Cameron
2022-10-10 22:41 ` [RFC V2 PATCH 05/11] cxl/mem: Trace General Media Event Record ira.weiny
2022-10-11 12:57   ` Jonathan Cameron
2022-10-14 23:33     ` Ira Weiny
2022-10-17 16:37       ` Jonathan Cameron
2022-10-17 17:21         ` Steven Rostedt
2022-10-18  9:46           ` Jonathan Cameron
2022-10-21  5:13             ` Ira Weiny
2022-10-15 11:30   ` Steven Rostedt
2022-10-10 22:41 ` [RFC V2 PATCH 06/11] cxl/mem: Trace DRAM " ira.weiny
2022-10-11 13:47   ` Jonathan Cameron [this message]
2022-10-14 23:45     ` Ira Weiny
2022-10-15 11:31   ` Steven Rostedt
2022-10-10 22:41 ` [RFC V2 PATCH 07/11] cxl/mem: Trace Memory Module " ira.weiny
2022-10-11 13:54   ` Jonathan Cameron
2022-10-15 11:32   ` Steven Rostedt
2022-10-10 22:41 ` [RFC V2 PATCH 08/11] cxl/test: Add generic mock events ira.weiny
2022-10-10 22:41 ` [RFC V2 PATCH 09/11] cxl/test: Add specific events ira.weiny
2022-10-10 22:41 ` [RFC V2 PATCH 10/11] cxl/test: Simulate event log overflow ira.weiny
2022-10-10 22:41 ` [RFC V2 PATCH 11/11] cxl/mem: Wire up event interrupts ira.weiny
2022-10-12 18:01   ` Davidlohr Bueso

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=20221011144712.00004a05@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=bwidawsk@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave@stgolabs.net \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox