All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Ira Weiny <ira.weiny@intel.com>
Cc: Ben Widawsky <ben.widawsky@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Alison Schofield" <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	<linux-kernel@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
	<linux-pci@vger.kernel.org>
Subject: Re: [PATCH V6 10/10] cxl/cdat: Parse out DSMAS data from CDAT table
Date: Fri, 4 Feb 2022 13:33:03 +0000	[thread overview]
Message-ID: <20220204133303.0000667b@Huawei.com> (raw)
In-Reply-To: <20220201223717.GR785175@iweiny-DESK2.sc.intel.com>

On Tue, 1 Feb 2022 14:37:17 -0800
Ira Weiny <ira.weiny@intel.com> wrote:

> On Tue, Feb 01, 2022 at 11:05:32AM -0800, Widawsky, Ben wrote:
> > On 22-01-31 23:19:52, ira.weiny@intel.com wrote:  
> > > From: Ira Weiny <ira.weiny@intel.com>
> > > 
> > > CXL memory devices need the information in the Device Scoped Memory
> > > Affinity Structure (DSMAS).  This information is contained within the
> > > CDAT table buffer which is already read and cached.
> > > 
> > > Parse and cache DSMAS data from the CDAT table.  Store this data in
> > > unmarshaled struct dsmas data structures for ease of use.
> > > 
> > > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> > > 
> > > ---
> > > Changes from V5
> > > 	Fix up sparse warnings
> > > 	Split out cdat_hdr_valid()
> > > 	Update cdat_hdr_valid()
> > > 		Remove revision and cs field parsing
> > > 			There is no point in these
> > > 		Add seq check and debug print.
> > > 	From Jonathan
> > > 		Add spaces around '+' and '/'
> > > 		use devm_krealloc() for dmas_ary
> > > 
> > > Changes from V4
> > > 	New patch
> > > ---
> > >  drivers/cxl/cdat.h        | 21 ++++++++++++
> > >  drivers/cxl/core/memdev.c | 70 +++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 91 insertions(+)
> > > 
> > > diff --git a/drivers/cxl/cdat.h b/drivers/cxl/cdat.h
> > > index a7725d26f2d2..f8c126190d18 100644
> > > --- a/drivers/cxl/cdat.h
> > > +++ b/drivers/cxl/cdat.h
> > > @@ -83,17 +83,38 @@
> > >  #define CDAT_SSLBIS_ENTRY_PORT_Y(entry, i) (((entry)[4 + (i) * 2] & 0xffff0000) >> 16)
> > >  #define CDAT_SSLBIS_ENTRY_LAT_OR_BW(entry, i) ((entry)[4 + (i) * 2 + 1] & 0x0000ffff)
> > >  
> > > +/**
> > > + * struct cxl_dsmas - host unmarshaled version of DSMAS data
> > > + *
> > > + * As defined in the Coherent Device Attribute Table (CDAT) specification this
> > > + * represents a single DSMAS entry in that table.
> > > + *
> > > + * @dpa_base: The lowest DPA address associated with this DSMAD
> > > + * @dpa_length: Length in bytes of this DSMAD
> > > + * @non_volatile: If set, the memory region represents Non-Volatile memory
> > > + */
> > > +struct cxl_dsmas {
> > > +	u64 dpa_base;
> > > +	u64 dpa_length;
> > > +	/* Flags */
> > > +	u8 non_volatile:1;
> > > +};
> > > +
> > >  /**
> > >   * struct cxl_cdat - CXL CDAT data
> > >   *
> > >   * @table: cache of CDAT table
> > >   * @length: length of cached CDAT table
> > >   * @seq: Last read Sequence number of the CDAT table
> > > + * @dsmas_ary: Array of DSMAS entries as parsed from the CDAT table
> > > + * @nr_dsmas: Number of entries in dsmas_ary
> > >   */
> > >  struct cxl_cdat {
> > >  	void *table;
> > >  	size_t length;
> > >  	u32 seq;
> > > +	struct cxl_dsmas *dsmas_ary;
> > > +	int nr_dsmas;
> > >  };
> > >  
> > >  #endif /* !__CXL_CDAT_H__ */
> > > diff --git a/drivers/cxl/core/memdev.c b/drivers/cxl/core/memdev.c
> > > index 11d721c56f08..32342a15e991 100644
> > > --- a/drivers/cxl/core/memdev.c
> > > +++ b/drivers/cxl/core/memdev.c
> > > @@ -6,6 +6,7 @@
> > >  #include <linux/idr.h>
> > >  #include <linux/pci.h>
> > >  #include <cxlmem.h>
> > > +#include "cdat.h"
> > >  #include "core.h"
> > >  
> > >  static DECLARE_RWSEM(cxl_memdev_rwsem);
> > > @@ -386,6 +387,71 @@ static int read_cdat_data(struct cxl_memdev *cxlmd,
> > >  	return rc;
> > >  }
> > >  
> > > +static int parse_dsmas(struct cxl_memdev *cxlmd)
> > > +{
> > > +	struct cxl_dsmas *dsmas_ary = NULL;
> > > +	u32 *data = cxlmd->cdat.table;
> > > +	int bytes_left = cxlmd->cdat.length;
> > > +	int nr_dsmas = 0;
> > > +
> > > +	if (!data)
> > > +		return -ENXIO;
> > > +
> > > +	/* Skip header */
> > > +	data += CDAT_HEADER_LENGTH_DW;
> > > +	bytes_left -= CDAT_HEADER_LENGTH_BYTES;
> > > +
> > > +	while (bytes_left > 0) {
> > > +		u32 *cur_rec = data;
> > > +		u8 type = FIELD_GET(CDAT_STRUCTURE_DW0_TYPE, cur_rec[0]);
> > > +		u16 length = FIELD_GET(CDAT_STRUCTURE_DW0_LENGTH, cur_rec[0]);
> > > +
> > > +		if (type == CDAT_STRUCTURE_DW0_TYPE_DSMAS) {
> > > +			struct cxl_dsmas *new_ary;
> > > +			u8 flags;
> > > +
> > > +			new_ary = devm_krealloc(&cxlmd->dev, dsmas_ary,
> > > +					   sizeof(*dsmas_ary) * (nr_dsmas + 1),
> > > +					   GFP_KERNEL);
> > > +			if (!new_ary) {
> > > +				dev_err(&cxlmd->dev,
> > > +					"Failed to allocate memory for DSMAS data\n");
> > > +				return -ENOMEM;
> > > +			}  
> > 
> > One thought here - it looks like there are at most 256 DSMAS entries. You could
> > allocate the full 256 up front, and then realloc *down* to the actual number.
> >   
> > > +			dsmas_ary = new_ary;
> > > +
> > > +			flags = FIELD_GET(CDAT_DSMAS_DW1_FLAGS, cur_rec[1]);
> > > +
> > > +			dsmas_ary[nr_dsmas].dpa_base = CDAT_DSMAS_DPA_OFFSET(cur_rec);
> > > +			dsmas_ary[nr_dsmas].dpa_length = CDAT_DSMAS_DPA_LEN(cur_rec);
> > > +			dsmas_ary[nr_dsmas].non_volatile = CDAT_DSMAS_NON_VOLATILE(flags);
> > > +
> > > +			dev_dbg(&cxlmd->dev, "DSMAS %d: %llx:%llx %s\n",
> > > +				nr_dsmas,
> > > +				dsmas_ary[nr_dsmas].dpa_base,
> > > +				dsmas_ary[nr_dsmas].dpa_base +
> > > +					dsmas_ary[nr_dsmas].dpa_length,
> > > +				(dsmas_ary[nr_dsmas].non_volatile ?
> > > +					"Persistent" : "Volatile")
> > > +				);
> > > +
> > > +			nr_dsmas++;
> > > +		}
> > > +
> > > +		data += (length / sizeof(u32));
> > > +		bytes_left -= length;
> > > +	}
> > > +
> > > +	if (nr_dsmas == 0)
> > > +		return -ENXIO;  
> > 
> > Hmm is there documentation that suggests a DSMAS must be implemented? Could this
> > just return 0? I'd put maybe dev_dbg here if it's unexpected but not a failure
> > and return success.  
> 
> For this call I was not envisioning this as an error.  I wanted to leave it up
> to the caller.
> 
> I think it would make more sense to return the number of DSMAS' found or
> negative errno on failure...
> 
> I'll clean it up.  Including below...
> 
> >   
> > > +
> > > +	dev_dbg(&cxlmd->dev, "Found %d DSMAS entries\n", nr_dsmas);
> > > +	cxlmd->cdat.dsmas_ary = dsmas_ary;
> > > +	cxlmd->cdat.nr_dsmas = nr_dsmas;
> > > +
> > > +	return 0;
> > > +}
> > > +
> > >  struct cxl_memdev *devm_cxl_add_memdev(struct cxl_dev_state *cxlds)
> > >  {
> > >  	struct cxl_memdev *cxlmd;
> > > @@ -407,6 +473,10 @@ struct cxl_memdev *devm_cxl_add_memdev(struct cxl_dev_state *cxlds)
> > >  	if (rc)
> > >  		goto err;
> > >  
> > > +	rc = parse_dsmas(cxlmd);
> > > +	if (rc)
> > > +		dev_warn(dev, "No DSMAS data found: %d\n", rc);
> > > +  
> 
> This was changed to dev_warn() because I think here we do expect dsmas data?
> Don't we?

There are flags in the CXL Range registers that specify that some stuff
is communicated via CDAT.  That includes one for whether it is nonvolatile
or not which is a DSMAS flag.  So if that is set we definitely expect them.

We would also expect them if QTG _DSM is in use as that has specific references
to DMSAS regions.

More generally a switch implementing CDAT wouldn't have DSMAS but
we are fairly safe that if a memory device has CDAT at all, DSMAS is expected
because most of the other structures reference the DSMAS handle.

Message is in general wrong though as it could be a memory failure
in parse_dsmas() so you need to check the actual error code.

J

> 
> Thanks,
> Ira
> 
> > >  	/*
> > >  	 * Activate ioctl operations, no cxl_memdev_rwsem manipulation
> > >  	 * needed as this is ordered with cdev_add() publishing the device.
> > > -- 
> > > 2.31.1
> > >   


  reply	other threads:[~2022-02-04 13:33 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-01  7:19 [PATCH V6 00/10] CXL: Read CDAT and DSMAS data from the device ira.weiny
2022-02-01  7:19 ` [PATCH V6 01/10] PCI: Add vendor ID for the PCI SIG ira.weiny
2022-02-03 17:11   ` Bjorn Helgaas
2022-02-03 20:28     ` Ira Weiny
2022-02-01  7:19 ` [PATCH V6 02/10] PCI: Replace magic constant for PCI Sig Vendor ID ira.weiny
2022-02-04 21:16   ` Dan Williams
2022-02-04 21:49   ` Bjorn Helgaas
2022-03-15 21:48     ` Ira Weiny
2022-02-01  7:19 ` [PATCH V6 03/10] PCI/DOE: Add Data Object Exchange Aux Driver ira.weiny
2022-02-03 22:40   ` Bjorn Helgaas
2022-03-15 21:48     ` Ira Weiny
2022-02-09  0:59   ` Dan Williams
2022-02-09 10:13     ` Jonathan Cameron
2022-02-09 16:26       ` Dan Williams
2022-02-09 16:57         ` Jonathan Cameron
2022-02-09 19:57           ` Dan Williams
2022-02-10 21:51             ` Ira Weiny
2022-03-16 22:50     ` Ira Weiny
2022-03-17 19:37       ` Ira Weiny
2022-02-01  7:19 ` [PATCH V6 04/10] PCI/DOE: Introduce pci_doe_create_doe_devices ira.weiny
2022-02-03 22:44   ` Bjorn Helgaas
2022-02-04 14:51     ` Jonathan Cameron
2022-02-04 16:27       ` Bjorn Helgaas
2022-02-11  2:54         ` Dan Williams
2022-03-24  0:26     ` Ira Weiny
2022-03-24 14:05       ` Jonathan Cameron
2022-03-24 23:44         ` Ira Weiny
2022-03-25 12:02           ` Jonathan Cameron
2022-02-01  7:19 ` [PATCH V6 05/10] cxl/pci: Create DOE auxiliary devices ira.weiny
2022-02-01  7:19 ` [PATCH V6 06/10] cxl/pci: Find the DOE mailbox which supports CDAT ira.weiny
2022-02-01 18:49   ` Ben Widawsky
2022-02-01 22:18     ` Ira Weiny
2022-02-04 14:04       ` Jonathan Cameron
2022-02-01  7:19 ` [PATCH V6 07/10] cxl/mem: Read CDAT table ira.weiny
2022-02-04 13:46   ` Jonathan Cameron
2022-02-01  7:19 ` [PATCH V6 08/10] cxl/cdat: Introduce cdat_hdr_valid() ira.weiny
2022-02-01 18:56   ` Ben Widawsky
2022-02-01 22:29     ` Ira Weiny
2022-02-04 13:17       ` Jonathan Cameron
2022-02-01  7:19 ` [PATCH V6 09/10] cxl/mem: Retry reading CDAT on failure ira.weiny
2022-02-01 18:59   ` Ben Widawsky
2022-02-01 22:31     ` Ira Weiny
2022-02-04 13:20       ` Jonathan Cameron
2022-02-01  7:19 ` [PATCH V6 10/10] cxl/cdat: Parse out DSMAS data from CDAT table ira.weiny
2022-02-01 19:05   ` Ben Widawsky
2022-02-01 22:37     ` Ira Weiny
2022-02-04 13:33       ` Jonathan Cameron [this message]
2022-02-04 13:41       ` Jonathan Cameron
2022-02-04 13:40   ` Jonathan Cameron

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=20220204133303.0000667b@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=ben.widawsky@intel.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@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 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.