Re: [PATCH 16/46] cxl/hdm: Add 'mode' attribute to decoder objects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Cameron wrote:
> On Thu, 23 Jun 2022 19:46:59 -0700
> Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
> 
> > Recall that the Device Physical Address (DPA) space of a CXL Memory
> > Expander is potentially partitioned into a volatile and persistent
> > portion. A decoder maps a Host Physical Address (HPA) range to a DPA
> > range and that translation depends on the value of all previous (lower
> > instance number) decoders before the current one.
> > 
> > In preparation for allowing dynamic provisioning of regions, decoders
> > need an ABI to indicate which DPA partition a decoder targets. This ABI
> > needs to be prepared for the possibility that some other agent committed
> > and locked a decoder that spans the partition boundary.
> > 
> > Add 'decoderX.Y/mode' to endpoint decoders that indicates which
> > partition 'ram' / 'pmem' the decoder targets, or 'mixed' if the decoder
> > currently spans the partition boundary.
> > 
> > Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
> 
> A few trivial things inline though I'm not super keen on it being
> introduced RO for just 2 patches...  You could pull forwards
> the outline of the store() to avoid that slight oddity, but
> I'm not that bothered if it is a pain to do.

It's either RO as a temporary state, or a pointless store() as a
temporary state, I think the former is more palatable for bisecting.

> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
> 
> > ---
> >  Documentation/ABI/testing/sysfs-bus-cxl |   16 ++++++++++++++++
> >  drivers/cxl/core/hdm.c                  |   10 ++++++++++
> >  drivers/cxl/core/port.c                 |   20 ++++++++++++++++++++
> >  drivers/cxl/cxl.h                       |    9 +++++++++
> >  4 files changed, 55 insertions(+)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl
> > index 1fd5984b6158..091459216e11 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-cxl
> > +++ b/Documentation/ABI/testing/sysfs-bus-cxl
> > @@ -164,3 +164,19 @@ Description:
> >  		expander memory (type-3). The 'target_type' attribute indicates
> >  		the current setting which may dynamically change based on what
> >  		memory regions are activated in this decode hierarchy.
> > +
> > +
> 
> Single blank line used for previous entries. Note this carries to other
> later patches.

It was deliberate, I should go back and fix up the previous ones to be
consistent.

> 
> 
> > +What:		/sys/bus/cxl/devices/decoderX.Y/mode
> > +Date:		May, 2022
> > +KernelVersion:	v5.20
> > +Contact:	linux-cxl@xxxxxxxxxxxxxxx
> > +Description:
> > +		(RO) When a CXL decoder is of devtype "cxl_decoder_endpoint" it
> > +		translates from a host physical address range, to a device local
> > +		address range. Device-local address ranges are further split
> > +		into a 'ram' (volatile memory) range and 'pmem' (persistent
> > +		memory) range. The 'mode' attribute emits one of 'ram', 'pmem',
> > +		'mixed', or 'none'. The 'mixed' indication is for error cases
> > +		when a decoder straddles the volatile/persistent partition
> > +		boundary, and 'none' indicates the decoder is not actively
> > +		decoding, or no DPA allocation policy has been set.
> > diff --git a/drivers/cxl/core/hdm.c b/drivers/cxl/core/hdm.c
> > index daae6e533146..3f929231b822 100644
> > --- a/drivers/cxl/core/hdm.c
> > +++ b/drivers/cxl/core/hdm.c
> > @@ -204,6 +204,16 @@ static int __cxl_dpa_reserve(struct cxl_endpoint_decoder *cxled,
> >  	cxled->dpa_res = res;
> >  	cxled->skip = skip;
> >  
> > +	if (resource_contains(&cxlds->pmem_res, res))
> > +		cxled->mode = CXL_DECODER_PMEM;
> > +	else if (resource_contains(&cxlds->ram_res, res))
> > +		cxled->mode = CXL_DECODER_RAM;
> > +	else {
> > +		dev_dbg(dev, "decoder%d.%d: %pr mixed\n", port->id,
> > +			cxled->cxld.id, cxled->dpa_res);
> 
> Why debug for one case and not the the others?

It's an exceptional, "should never happen" case, but can be benign so
it does not rise to the level of dev_warn(). However, if someone is
reporting a bug and I ask for a debug log, this is something odd that
I'd like to see highlighted.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux