Linux CXL
 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>,
	Ben Widawsky <bwidawsk@kernel.org>,
	Dave Jiang <dave.jiang@intel.com>,
	linux-cxl@vger.kernel.org
Subject: Re: [PATCH v2] cxl/trace: Add an HPA to cxl_poison trace events
Date: Mon, 23 Jan 2023 15:31:35 -0800	[thread overview]
Message-ID: <Y88Y11hUGfsQD0ki@aschofie-mobl2> (raw)
In-Reply-To: <20230123145848.00007b5f@Huawei.com>

On Mon, Jan 23, 2023 at 02:58:48PM +0000, Jonathan Cameron wrote:
> On Wed, 18 Jan 2023 12:18:05 -0800
> alison.schofield@intel.com wrote:
> 
> > From: Alison Schofield <alison.schofield@intel.com>
> > 
> > When a cxl_poison trace event is reported by region, the poisoned
> > Device Physical Address (DPA) can be translated to a Host Physical
> > Address (HPA) for consumption by user space.
> > 
> > Translate and add the resulting HPA to the cxl_poison trace event.
> > Follow the device decode logic as defined in the CXL Spec 3.0 Section
> > 8.2.4.19.13.
> > 
> > When the poison request is by memdev, no HPA translation is performed
> > and ULLONG_MAX is assigned to the cxl_poison hpa trace field.
> > 
> > Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> 
> The offset stuff for non power of 2 gives me a headache, but I 'think'
> you have it right... We don't yet have support in QEMU for those
> modes, so I can't easily brute force test it.  With all that in mind.
> 
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> 
> Trivial style comment inline.
> 
Thanks for the review Jonathan. I noted the comment hpa->HPA, and will
pick it up if/when I rev this.

Thanks for sharing the headache with me ;)  I posted a test program to
that mimics these calculations and cranks thru every (perhaps some
illegal) permuation of EIG, EIW, POS, and applies them to a dpa_offset
to make an hpa_offset.

https://github.com/AlisonSchofield/cxl-addrtest

Ideally, I would be able to compare the outputs I'm getting, rather
than just validate using my own, possibly flawed again, calculations.

Ideas to further that testing are welcome!

Alison


> > ---
> > 
> > Built on cxl/next plus Patchset: CXL Poison List Retrieval & Tracing [1]
> > 
> > Changes in v2:
> > - Rebased to cxl/next
> > 
> > Link to v1: https://lore.kernel.org/linux-cxl/20230104210401.195808-1-alison.schofield@intel.com/
> > 
> > [1] https://lore.kernel.org/linux-cxl/de11785ff05844299b40b100f8e0f56c7eef7f08.1674070170.git.alison.schofield@intel.com/
> > 
> > 
> >  drivers/cxl/core/trace.c | 94 ++++++++++++++++++++++++++++++++++++++++
> >  drivers/cxl/core/trace.h |  9 +++-
> >  2 files changed, 102 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cxl/core/trace.c b/drivers/cxl/core/trace.c
> > index 29ae7ce81dc5..d0403dc3c8ab 100644
> > --- a/drivers/cxl/core/trace.c
> > +++ b/drivers/cxl/core/trace.c
> > @@ -1,5 +1,99 @@
> >  // SPDX-License-Identifier: GPL-2.0-only
> >  /* Copyright(c) 2022 Intel Corporation. All rights reserved. */
> >  
> > +#include <cxl.h>
> > +#include "core.h"
> > +
> >  #define CREATE_TRACE_POINTS
> >  #include "trace.h"
> > +
> > +static bool cxl_is_hpa_in_range(u64 hpa, struct cxl_region *cxlr, int pos)
> > +{
> > +	struct cxl_region_params *p = &cxlr->params;
> > +	int gran = p->interleave_granularity;
> > +	int ways = p->interleave_ways;
> > +	u64 offset;
> > +
> > +	/* Is the hpa within this region at all */
> 
> For comments we could go with HPA... Doesn't really matter though.
> 
>  
> > +	if (hpa < p->res->start || hpa > p->res->end) {
> > +		dev_dbg(&cxlr->dev,
> > +			"Addr trans fail: hpa 0x%llx not in region\n", hpa);
> > +		return false;
> > +	}
> > +
> > +	/* Is the hpa in an expected chunk for its pos(-ition) */
> > +	offset = hpa - p->res->start;
> > +	offset = do_div(offset, gran * ways);
> > +	if ((offset >= pos * gran) && (offset < (pos + 1) * gran))
> > +		return true;
> > +
> > +	dev_dbg(&cxlr->dev,
> > +		"Addr trans fail: hpa 0x%llx not in expected chunk\n", hpa);
> > +
> > +	return false;
> > +}
> > +
> > +static u64 cxl_dpa_to_hpa(u64 dpa,  struct cxl_region *cxlr,
> > +			  struct cxl_endpoint_decoder *cxled)
> > +{
> > +	u64 dpa_offset, hpa_offset, bits_upper, mask_upper, hpa;
> > +	struct cxl_region_params *p = &cxlr->params;
> > +	int pos = cxled->pos;
> > +	u16 eig = 0;
> > +	u8 eiw = 0;
> > +
> > +	ways_to_eiw(p->interleave_ways, &eiw);
> > +	granularity_to_eig(p->interleave_granularity, &eig);
> > +
> > +	/*
> > +	 * The device position in the region interleave set was removed
> > +	 * from the offset at HPA->DPA translation. To reconstruct the
> > +	 * HPA, place the 'pos' in the offset.
> > +	 *
> > +	 * The placement of 'pos' in the HPA is determined by interleave
> > +	 * ways and granularity and is defined in the CXL Spec 3.0 Section
> > +	 * 8.2.4.19.13 Implementation Note: Device Decode Logic
> > +	 */
> > +
> > +	/* Remove the dpa base */
> > +	dpa_offset = dpa - cxl_dpa_resource_start(cxled);
> > +
> > +	mask_upper = GENMASK_ULL(51, eig + 8);
> > +
> > +	if (eiw < 8) {
> > +		hpa_offset = (dpa_offset & mask_upper) << eiw;
> > +		hpa_offset |= pos << (eig + 8);
> > +	} else {
> > +		bits_upper = (dpa_offset & mask_upper) >> (eig + 8);
> > +		bits_upper = bits_upper * 3;
> > +		hpa_offset = ((bits_upper << (eiw - 8)) + pos) << (eig + 8);
> > +	}
> > +
> > +	/* The lower bits remain unchanged */
> > +	hpa_offset |= dpa_offset & GENMASK_ULL(eig + 7, 0);
> > +
> > +	/* Apply the hpa_offset to the region base address */
> > +	hpa = hpa_offset + p->res->start;
> > +
> > +	if (!cxl_is_hpa_in_range(hpa, cxlr, cxled->pos))
> > +		return ULLONG_MAX;
> > +
> > +	return hpa;
> > +}
> > +
> 
> > diff --git a/drivers/cxl/core/trace.h b/drivers/cxl/core/trace.h
> > index c7958311ce5f..521b80f92e96 100644
> > --- a/drivers/cxl/core/trace.h
> > +++ b/drivers/cxl/core/trace.h
> > @@ -136,6 +136,8 @@ TRACE_EVENT(cxl_aer_correctable_error,
> >  #define cxl_poison_overflow(flags, time)				\
> >  	(flags & CXL_POISON_FLAG_OVERFLOW ? le64_to_cpu(time) : 0)
> >  
> > +u64 cxl_trace_hpa(struct cxl_region *cxlr, struct cxl_memdev *memdev, u64 dpa);
> > +
> >  TRACE_EVENT(cxl_poison,
> >  
> >  	    TP_PROTO(struct cxl_memdev *memdev, const struct pci_dev *pcidev,
> > @@ -150,6 +152,7 @@ TRACE_EVENT(cxl_poison,
> >  		__string(pcidev, dev_name(&pcidev->dev))
> >  		__string(region, region)
> >  		__field(u64, overflow_t)
> > +		__field(u64, hpa)
> >  		__field(u64, dpa)
> >  		__field(u32, length)
> >  		__array(char, uuid, 16)
> > @@ -168,17 +171,21 @@ TRACE_EVENT(cxl_poison,
> >  		if (region) {
> >  			__assign_str(region, dev_name(&region->dev));
> >  			memcpy(__entry->uuid, &region->params.uuid, 16);
> > +			__entry->hpa = cxl_trace_hpa(region, memdev,
> > +						     __entry->dpa);
> >  		} else {
> >  			__assign_str(region, "");
> >  			memset(__entry->uuid, 0, 16);
> > +			__entry->hpa = ULLONG_MAX;
> >  		}
> >  	    ),
> >  
> > -	    TP_printk("memdev=%s pcidev=%s region=%s region_uuid=%pU dpa=0x%llx length=0x%x source=%s flags=%s overflow_time=%llu",
> > +	    TP_printk("memdev=%s pcidev=%s region=%s region_uuid=%pU hpa=0x%llx 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->hpa,
> >  		__entry->dpa,
> >  		__entry->length,
> >  		show_poison_source(__entry->source),
> 

  reply	other threads:[~2023-01-23 23:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18 20:18 [PATCH v2] cxl/trace: Add an HPA to cxl_poison trace events alison.schofield
2023-01-23 14:58 ` Jonathan Cameron
2023-01-23 23:31   ` Alison Schofield [this message]
2023-01-24 16:16 ` Dave Jiang

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=Y88Y11hUGfsQD0ki@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=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