| Message ID | 163116431893.2460985.4003511000574373922.stgit@dwillia2-desk3.amr.corp.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | cxl_test: Enable CXL Topology and UAPI regression tests | expand |
On 21-09-08 22:11:58, Dan Williams wrote: > Add a definition of the CXL 2.0 region label format. Note this is done > as a separate patch to make the next patch that adds namespace label > support easier to read. > > Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > Signed-off-by: Dan Williams <dan.j.williams@intel.com> > --- > drivers/nvdimm/label.h | 32 ++++++++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) Wondering how awkward it's going to be to use this in the cxl region driver. Is the intent to push all device based reads/writes to labels happen in drivers/nvdimm? > > diff --git a/drivers/nvdimm/label.h b/drivers/nvdimm/label.h > index 7fa757d47846..0519aacc2926 100644 > --- a/drivers/nvdimm/label.h > +++ b/drivers/nvdimm/label.h > @@ -66,6 +66,38 @@ struct nd_namespace_index { > u8 free[]; > }; > > +/** > + * struct cxl_region_label - CXL 2.0 Table 211 > + * @type: uuid identifying this label format (region) > + * @uuid: uuid for the region this label describes > + * @flags: NSLABEL_FLAG_UPDATING (all other flags reserved) > + * @nlabel: 1 per interleave-way in the region > + * @position: this label's position in the set > + * @dpa: start address in device-local capacity for this label > + * @rawsize: size of this label's contribution to region > + * @hpa: mandatory system physical address to map this region > + * @slot: slot id of this label in label area > + * @ig: interleave granularity (1 << @ig) * 256 bytes > + * @align: alignment in SZ_256M blocks > + * @reserved: reserved > + * @checksum: fletcher64 sum of this label > + */ > +struct cxl_region_label { > + u8 type[NSLABEL_UUID_LEN]; > + u8 uuid[NSLABEL_UUID_LEN]; > + __le32 flags; > + __le16 nlabel; > + __le16 position; > + __le64 dpa; > + __le64 rawsize; > + __le64 hpa; > + __le32 slot; > + __le32 ig; > + __le32 align; > + u8 reserved[0xac]; > + __le64 checksum; > +}; > + > /** > * struct nd_namespace_label - namespace superblock > * @uuid: UUID per RFC 4122 >
On Thu, Sep 9, 2021 at 8:58 AM Ben Widawsky <ben.widawsky@intel.com> wrote: > > On 21-09-08 22:11:58, Dan Williams wrote: > > Add a definition of the CXL 2.0 region label format. Note this is done > > as a separate patch to make the next patch that adds namespace label > > support easier to read. > > > > Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Signed-off-by: Dan Williams <dan.j.williams@intel.com> > > --- > > drivers/nvdimm/label.h | 32 ++++++++++++++++++++++++++++++++ > > 1 file changed, 32 insertions(+) > > Wondering how awkward it's going to be to use this in the cxl region driver. Is > the intent to push all device based reads/writes to labels happen in > drivers/nvdimm? I am looking at it from the perspective that namespace provisioning and assembly will need to consult region details. So drivers/nvdimm/ needs to have region-label awareness regardless. Now, when the CXL side wants to provision a region, it will also need to coordinate label area access with any namespace provisioning operations that might be happening on other regions that the CXL device is contributing. Both of those lead me to believe that CXL should just request the nvdimm sub-system to update labels to keep all the competing label operations and cached label data in-sync.
diff --git a/drivers/nvdimm/label.h b/drivers/nvdimm/label.h index 7fa757d47846..0519aacc2926 100644 --- a/drivers/nvdimm/label.h +++ b/drivers/nvdimm/label.h @@ -66,6 +66,38 @@ struct nd_namespace_index { u8 free[]; }; +/** + * struct cxl_region_label - CXL 2.0 Table 211 + * @type: uuid identifying this label format (region) + * @uuid: uuid for the region this label describes + * @flags: NSLABEL_FLAG_UPDATING (all other flags reserved) + * @nlabel: 1 per interleave-way in the region + * @position: this label's position in the set + * @dpa: start address in device-local capacity for this label + * @rawsize: size of this label's contribution to region + * @hpa: mandatory system physical address to map this region + * @slot: slot id of this label in label area + * @ig: interleave granularity (1 << @ig) * 256 bytes + * @align: alignment in SZ_256M blocks + * @reserved: reserved + * @checksum: fletcher64 sum of this label + */ +struct cxl_region_label { + u8 type[NSLABEL_UUID_LEN]; + u8 uuid[NSLABEL_UUID_LEN]; + __le32 flags; + __le16 nlabel; + __le16 position; + __le64 dpa; + __le64 rawsize; + __le64 hpa; + __le32 slot; + __le32 ig; + __le32 align; + u8 reserved[0xac]; + __le64 checksum; +}; + /** * struct nd_namespace_label - namespace superblock * @uuid: UUID per RFC 4122