linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH 0/9] CXL 2.0 Support
@ 2020-11-11  5:43 Ben Widawsky
  2020-11-11  5:43 ` [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect Ben Widawsky
                   ` (10 more replies)
  0 siblings, 11 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11  5:43 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki,
	Ben Widawsky

Introduce support for “type-3” memory devices defined in the recently released
Compute Express Link (CXL) 2.0 specification. Specifically, these are the memory
devices defined by section 8.2.8.5 of the CXL 2.0 spec. A reference
implementation emulating these devices is being submitted to the QEMU mailing
list. “Type-3” is a CXL device that acts as a memory expander for RAM or PMEM.
It might be interleaved with other CXL devices in a given physical address
range.

These changes allow for foundational enumeration of CXL 2.0 memory devices. The functionality present is:
- Initial driver bring-up
- Device enumeration and an initial sysfs representation
- Submit a basic firmware command via ‘mailbox’ to an emulated memory device
  with non-volatile capacity.

Some of the functionality that is still missing includes:
- Memory interleaving at the host bridge, root port, or switch level
- CXL 1.1 Root Complex Integrated Endpoint Support
- CXL 2.0 Hot plug support

In addition to the core functionality of discovering the spec defined registers
and resources, introduce a CXL device model that will be the foundation for
translating CXL capabilities into existing Linux infrastructure for Persistent
Memory and other memory devices. For now, this only includes support for the
management command mailbox that type-3 devices surface. These control devices
fill the role of “DIMMs” / nmemX memory-devices in LIBNVDIMM terms.

Now, while implementing the driver some feedback for the specification was
generated to cover perceived gaps and address conflicts. The feedback is
presented as a reference implementation in the driver and QEMU emulation.
Specifically the following concepts are original to the Linux implementation and
feedback / collaboration is requested to develop these into specification
proposals:
1. Top level ACPI object (ACPI0017)
2. HW imposed address space and interleave constraints
3. _OSC UUID A4D1629D-FF52-4888-BE96-E5CADE548DB1

ACPI0017
--------
Introduce a new ACPI namespace device with an _HID of ACPI0017. The purpose of
this object is twofold, support a legacy OS with a set of out-of-tree CXL
modules, and establish an attach point for a driver that knows about
interleaving. Both of these boil down to the same point, to centralize Operating
System support for resources described by the CXL Early Discovery Table (CEDT).

The legacy OS problem stems from the spec's description of a host bridge,
ACPI0016 is denoted as the _HID for host bridges, with a _CID of PNP0A08. In a
CXL unaware version of Linux, the core ACPI subsystem will bind a driver to
PNP0A08 and preclude a CXL-aware driver from binding to ACPI0016. An ACPI0017
device allows a standalone CXL-aware driver to register for handling /
coordinating CEDT and CXL-specific _OSC control.

Similarly when managing interleaving there needs to be some management layer
above the ACPI0016 device that is capable of assembling leaf nodes into
interleave sets. As is the case with ACPI0012 that does this central
coordination for NFIT defined resources, ACPI0017 does the same for CEDT
described resources.

Memory Windows
-------
For CXL.mem capable platforms, there is a need for a mechanism for platform
firmware to make the Operating System aware of any restrictions that hardware
might have in address space. For example, in a system with 4 host bridges all
participating in an interleave set, the firmware needs to provide some
description of this. That information is missing from the CXL 2.0 spec as of
today and it also is not implemented in the driver. A variety of ACPI based
mechanisms, for example _CRS fields on the ACPI0017 device, were considered.


CXL Exclusive _OSC
-----------------
CXL 2.0 definition provides new fields to _OSC for host bridges to allow for new
services provided by CXL - error handling, hot plug, capabilities, etc. This is
built on top of PCIe _OSC via a new UUID. A CXL unaware OS will use the old UUID
to configure the PCIe host bridge. The expectation is that a CXL aware OS uses
the new UUID and to modify both CXL and PCIE capabilities in one shot. The issue
arises when trying to define a standalone CXL driver. The core OS will configure
the PCIe _OSC, but when the CXL driver attempts to set CXL _OSC the current
definition makes that driver re-specify PCIE capabilities. An isolated CXL-only
_OSC allows the PCIE core to be unchanged and let a CXL driver stack manage CXL
_OSC without the possibility of clobbering / colliding with PCIE core OSC
management.  The proposal moves the new _OSC dwords (SUPC and CTRC) to their own
_OSC UUID.

Next steps after this basic foundation is expanded command support and LIBNVDIMM
integration. This is the initial “release early / release often” version of the
Linux CXL enabling.


Ben Widawsky (5):
  cxl/mem: Map memory device registers
  cxl/mem: Find device capabilities
  cxl/mem: Initialize the mailbox interface
  cxl/mem: Implement polled mode mailbox
  MAINTAINERS: Add maintainers of the CXL driver

Dan Williams (2):
  cxl/mem: Add a driver for the type-3 mailbox
  cxl/mem: Register CXL memX devices

Vishal Verma (2):
  cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  cxl/acpi: add OSC support

 MAINTAINERS           |   9 +
 drivers/Kconfig       |   1 +
 drivers/Makefile      |   1 +
 drivers/cxl/Kconfig   |  50 ++++
 drivers/cxl/Makefile  |   9 +
 drivers/cxl/acpi.c    | 325 ++++++++++++++++++++++
 drivers/cxl/acpi.h    |  33 +++
 drivers/cxl/bus.c     |  35 +++
 drivers/cxl/bus.h     |   8 +
 drivers/cxl/cxl.h     | 166 +++++++++++
 drivers/cxl/mem.c     | 631 ++++++++++++++++++++++++++++++++++++++++++
 drivers/cxl/pci.h     |  21 ++
 include/acpi/actbl1.h |  52 ++++
 13 files changed, 1341 insertions(+)
 create mode 100644 drivers/cxl/Kconfig
 create mode 100644 drivers/cxl/Makefile
 create mode 100644 drivers/cxl/acpi.c
 create mode 100644 drivers/cxl/acpi.h
 create mode 100644 drivers/cxl/bus.c
 create mode 100644 drivers/cxl/bus.h
 create mode 100644 drivers/cxl/cxl.h
 create mode 100644 drivers/cxl/mem.c
 create mode 100644 drivers/cxl/pci.h

-- 
2.29.2


^ permalink raw reply	[flat|nested] 73+ messages in thread

* [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
@ 2020-11-11  5:43 ` Ben Widawsky
  2020-11-11  6:17   ` Randy Dunlap
                     ` (4 more replies)
  2020-11-11  5:43 ` [RFC PATCH 2/9] cxl/acpi: add OSC support Ben Widawsky
                   ` (9 subsequent siblings)
  10 siblings, 5 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11  5:43 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki,
	Ben Widawsky

From: Vishal Verma <vishal.l.verma@intel.com>

Add an acpi_cxl module to coordinate the ACPI portions of the CXL
(Compute eXpress Link) interconnect. This driver binds to ACPI0017
objects in the ACPI tree, and coordinates access to the resources
provided by the ACPI CEDT (CXL Early Discovery Table).

It also coordinates operations of the root port _OSC object to notify
platform firmware that the OS has native support for the CXL
capabilities of endpoints.

Note: the actbl1.h changes are speculative. The expectation is that they
will arrive through the ACPICA tree in due time.

Cc: Ben Widawsky <ben.widawsky@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
---
 drivers/Kconfig       |   1 +
 drivers/Makefile      |   1 +
 drivers/cxl/Kconfig   |  30 +++++++++++
 drivers/cxl/Makefile  |   5 ++
 drivers/cxl/acpi.c    | 119 ++++++++++++++++++++++++++++++++++++++++++
 drivers/cxl/acpi.h    |  15 ++++++
 include/acpi/actbl1.h |  52 ++++++++++++++++++
 7 files changed, 223 insertions(+)
 create mode 100644 drivers/cxl/Kconfig
 create mode 100644 drivers/cxl/Makefile
 create mode 100644 drivers/cxl/acpi.c
 create mode 100644 drivers/cxl/acpi.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index dcecc9f6e33f..62c753a73651 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -6,6 +6,7 @@ menu "Device Drivers"
 source "drivers/amba/Kconfig"
 source "drivers/eisa/Kconfig"
 source "drivers/pci/Kconfig"
+source "drivers/cxl/Kconfig"
 source "drivers/pcmcia/Kconfig"
 source "drivers/rapidio/Kconfig"
 
diff --git a/drivers/Makefile b/drivers/Makefile
index c0cd1b9075e3..5dad349de73b 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_NVM)		+= lightnvm/
 obj-y				+= base/ block/ misc/ mfd/ nfc/
 obj-$(CONFIG_LIBNVDIMM)		+= nvdimm/
 obj-$(CONFIG_DAX)		+= dax/
+obj-$(CONFIG_CXL_BUS)		+= cxl/
 obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/
 obj-$(CONFIG_NUBUS)		+= nubus/
 obj-y				+= macintosh/
diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
new file mode 100644
index 000000000000..dd724bd364df
--- /dev/null
+++ b/drivers/cxl/Kconfig
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0-only
+menuconfig CXL_BUS
+	tristate "CXL (Compute Express Link) Devices Support"
+	help
+	  CXL is a bus that is electrically compatible with PCI-E, but layers
+	  three protocols on that signalling (CXL.io, CXL.cache, and CXL.mem). The
+	  CXL.cache protocol allows devices to hold cachelines locally, the
+	  CXL.mem protocol allows devices to be fully coherent memory targets, the
+	  CXL.io protocol is equivalent to PCI-E. Say 'y' to enable support for
+	  the configuration and management of devices supporting these protocols.
+
+if CXL_BUS
+
+config CXL_BUS_PROVIDER
+	tristate
+
+config CXL_ACPI
+	tristate "CXL Platform Support"
+	depends on ACPI
+	default CXL_BUS
+	select CXL_BUS_PROVIDER
+	help
+	  CXL Platform Support is a prerequisite for any CXL device driver that
+	  wants to claim ownership of the component register space. By default
+	  platform firmware assumes Linux is unaware of CXL capabilities and
+	  requires explicit opt-in. This platform component also mediates
+	  resources described by the CEDT (CXL Early Discovery Table)
+
+	  Say 'y' to enable CXL (Compute Express Link) drivers.
+endif
diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
new file mode 100644
index 000000000000..d38cd34a2582
--- /dev/null
+++ b/drivers/cxl/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
+
+ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
+cxl_acpi-y := acpi.o
diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
new file mode 100644
index 000000000000..26e4f73838a7
--- /dev/null
+++ b/drivers/cxl/acpi.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020 Intel Corporation. All rights reserved.
+ */
+#include <linux/list_sort.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/sysfs.h>
+#include <linux/list.h>
+#include <linux/acpi.h>
+#include <linux/sort.h>
+#include <linux/pci.h>
+#include "acpi.h"
+
+static void acpi_cxl_desc_init(struct acpi_cxl_desc *acpi_desc, struct device *dev)
+{
+	dev_set_drvdata(dev, acpi_desc);
+	acpi_desc->dev = dev;
+}
+
+static void acpi_cedt_put_table(void *table)
+{
+	acpi_put_table(table);
+}
+
+static int acpi_cxl_add(struct acpi_device *adev)
+{
+	struct acpi_cxl_desc *acpi_desc;
+	struct device *dev = &adev->dev;
+	struct acpi_table_header *tbl;
+	acpi_status status = AE_OK;
+	acpi_size sz;
+	int rc = 0;
+
+	status = acpi_get_table(ACPI_SIG_CEDT, 0, &tbl);
+	if (ACPI_FAILURE(status)) {
+		dev_err(dev, "failed to find CEDT at startup\n");
+		return 0;
+	}
+
+	rc = devm_add_action_or_reset(dev, acpi_cedt_put_table, tbl);
+	if (rc)
+		return rc;
+	sz = tbl->length;
+	dev_info(dev, "found CEDT at startup: %lld bytes\n", sz);
+
+	acpi_desc = devm_kzalloc(dev, sizeof(*acpi_desc), GFP_KERNEL);
+	if (!acpi_desc)
+		return -ENOMEM;
+	acpi_cxl_desc_init(acpi_desc, &adev->dev);
+
+	acpi_desc->acpi_header = *tbl;
+
+	return 0;
+}
+
+static int acpi_cxl_remove(struct acpi_device *adev)
+{
+	return 0;
+}
+
+static const struct acpi_device_id acpi_cxl_ids[] = {
+	{ "ACPI0017", 0 },
+	{ "", 0 },
+};
+MODULE_DEVICE_TABLE(acpi, acpi_cxl_ids);
+
+static struct acpi_driver acpi_cxl_driver = {
+	.name = KBUILD_MODNAME,
+	.ids = acpi_cxl_ids,
+	.ops = {
+		.add = acpi_cxl_add,
+		.remove = acpi_cxl_remove,
+	},
+};
+
+/*
+ * If/when CXL support is defined by other platform firmware the kernel
+ * will need a mechanism to select between the platform specific version
+ * of this routine, until then, hard-code ACPI assumptions
+ */
+int cxl_bus_prepared(struct pci_dev *pdev)
+{
+	struct acpi_device *adev;
+	struct pci_dev *root_port;
+	struct device *root;
+
+	root_port = pcie_find_root_port(pdev);
+	if (!root_port)
+		return -ENXIO;
+
+	root = root_port->dev.parent;
+	if (!root)
+		return -ENXIO;
+
+	adev = ACPI_COMPANION(root);
+	if (!adev)
+		return -ENXIO;
+
+	/* TODO: OSC enabling */
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cxl_bus_prepared);
+
+static __init int acpi_cxl_init(void)
+{
+	return acpi_bus_register_driver(&acpi_cxl_driver);
+}
+
+static __exit void acpi_cxl_exit(void)
+{
+	acpi_bus_unregister_driver(&acpi_cxl_driver);
+}
+
+module_init(acpi_cxl_init);
+module_exit(acpi_cxl_exit);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Intel Corporation");
diff --git a/drivers/cxl/acpi.h b/drivers/cxl/acpi.h
new file mode 100644
index 000000000000..011505475cc6
--- /dev/null
+++ b/drivers/cxl/acpi.h
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright(c) 2020 Intel Corporation. All rights reserved.
+
+#ifndef __CXL_ACPI_H__
+#define __CXL_ACPI_H__
+#include <linux/acpi.h>
+
+struct acpi_cxl_desc {
+	struct acpi_table_header acpi_header;
+	struct device *dev;
+};
+
+int cxl_bus_prepared(struct pci_dev *pci_dev);
+
+#endif	/* __CXL_ACPI_H__ */
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 43549547ed3e..70f745f526e3 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -28,6 +28,7 @@
 #define ACPI_SIG_BERT           "BERT"	/* Boot Error Record Table */
 #define ACPI_SIG_BGRT           "BGRT"	/* Boot Graphics Resource Table */
 #define ACPI_SIG_BOOT           "BOOT"	/* Simple Boot Flag Table */
+#define ACPI_SIG_CEDT           "CEDT"	/* CXL Early Discovery Table */
 #define ACPI_SIG_CPEP           "CPEP"	/* Corrected Platform Error Polling table */
 #define ACPI_SIG_CSRT           "CSRT"	/* Core System Resource Table */
 #define ACPI_SIG_DBG2           "DBG2"	/* Debug Port table type 2 */
@@ -1624,6 +1625,57 @@ struct acpi_ibft_target {
 	u16 reverse_chap_secret_offset;
 };
 
+/*******************************************************************************
+ *
+ * CEDT - CXL Early Discovery Table (ACPI 6.4)
+ *        Version 1
+ *
+ ******************************************************************************/
+
+struct acpi_table_cedt {
+	struct acpi_table_header header;	/* Common ACPI table header */
+	u32 reserved;
+};
+
+/* Values for CEDT structure types */
+
+enum acpi_cedt_type {
+	ACPI_CEDT_TYPE_HOST_BRIDGE = 0, /* CHBS - CXL Host Bridge Structure */
+	ACPI_CEDT_TYPE_CFMWS = 1, 	/* CFMWS - CXL Fixed Memory Window Structure */
+};
+
+struct acpi_cedt_structure {
+	u8 type;
+	u8 reserved;
+	u16 length;
+};
+
+/*
+ * CEDT Structures, correspond to Type in struct acpi_cedt_structure
+ */
+
+/* 0: CXL Host Bridge Structure */
+
+struct acpi_cedt_chbs {
+	struct acpi_cedt_structure header;
+	u32 uid;
+	u32 version;
+	u32 reserved1;
+	u64 base;
+	u32 length;
+	u32 reserved2;
+};
+
+/* Values for version field above */
+
+#define ACPI_CEDT_CHBS_VERSION_CXL11    (0)
+#define ACPI_CEDT_CHBS_VERSION_CXL20    (1)
+
+/* Values for length field above */
+
+#define ACPI_CEDT_CHBS_LENGTH_CXL11     (0x2000)
+#define ACPI_CEDT_CHBS_LENGTH_CXL20     (0x10000)
+
 /* Reset to default packing */
 
 #pragma pack()
-- 
2.29.2


^ permalink raw reply	[flat|nested] 73+ messages in thread

* [RFC PATCH 2/9] cxl/acpi: add OSC support
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
  2020-11-11  5:43 ` [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect Ben Widawsky
@ 2020-11-11  5:43 ` Ben Widawsky
  2020-11-16 17:59   ` Jonathan Cameron
  2020-11-11  5:43 ` [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox Ben Widawsky
                   ` (8 subsequent siblings)
  10 siblings, 1 reply; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11  5:43 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki,
	Ben Widawsky

From: Vishal Verma <vishal.l.verma@intel.com>

Add support to advertise OS capabilities, and request OS control for CXL
features using the ACPI _OSC mechanism. Advertise support for all
possible CXL features, and attempt to request control too for all
possible features.

Based on a patch by Sean Kelley.

Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>

---

This uses a non-standard UUID for CXL and is meant as a change proposal
to the CXL specification. The definition for _OSC intermixes PCIe and
CXL Dwords, which makes a clean separation of CXL capabilities
difficult, if not impossible. This is therefore subject to change.

---
 drivers/cxl/acpi.c | 210 ++++++++++++++++++++++++++++++++++++++++++++-
 drivers/cxl/acpi.h |  18 ++++
 2 files changed, 226 insertions(+), 2 deletions(-)

diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
index 26e4f73838a7..c3e2f7f6ea02 100644
--- a/drivers/cxl/acpi.c
+++ b/drivers/cxl/acpi.c
@@ -12,6 +12,16 @@
 #include <linux/pci.h>
 #include "acpi.h"
 
+/*
+ * TODO: These are global for now to save the OSC state.
+ * This works if OSC can be expected to be uniform for every ACPI0016 object.
+ * If that is not the case, revisit this. These need to be saved because
+ * relinquishing control of a previously granted capability is disallowed.
+ */
+static u32 cxl_osc_support_set;
+static u32 cxl_osc_control_set;
+static DEFINE_MUTEX(acpi_desc_lock);
+
 static void acpi_cxl_desc_init(struct acpi_cxl_desc *acpi_desc, struct device *dev)
 {
 	dev_set_drvdata(dev, acpi_desc);
@@ -74,6 +84,199 @@ static struct acpi_driver acpi_cxl_driver = {
 	},
 };
 
+struct pci_osc_bit_struct {
+	u32 bit;
+	char *desc;
+};
+
+static struct pci_osc_bit_struct cxl_osc_support_bit[] = {
+	{ CXL_OSC_PORT_REG_ACCESS_SUPPORT, "CXLPortRegAccess" },
+	{ CXL_OSC_PORT_DEV_REG_ACCESS_SUPPORT, "CXLPortDevRegAccess" },
+	{ CXL_OSC_PER_SUPPORT, "CXLProtocolErrorReporting" },
+	{ CXL_OSC_NATIVE_HP_SUPPORT, "CXLNativeHotPlug" },
+};
+
+static struct pci_osc_bit_struct cxl_osc_control_bit[] = {
+	{ CXL_OSC_MEM_ERROR_CONTROL, "CXLMemErrorReporting" },
+};
+
+/*
+ * CXL 2.0 spec UUID - unusable as it PCI and CXL OSC are mixed
+ * static u8 cxl_osc_uuid_str[] = "68F2D50B-C469-4d8A-BD3D-941A103FD3FC";
+ */
+/* New, proposed UUID for CXL-only OSC */
+static u8 cxl_osc_uuid_str[] = "A4D1629D-FF52-4888-BE96-E5CADE548DB1";
+
+static void decode_osc_bits(struct device *dev, char *msg, u32 word,
+			    struct pci_osc_bit_struct *table, int size)
+{
+	char buf[80];
+	int i, len = 0;
+	struct pci_osc_bit_struct *entry;
+
+	buf[0] = '\0';
+	for (i = 0, entry = table; i < size; i++, entry++)
+		if (word & entry->bit)
+			len += scnprintf(buf + len, sizeof(buf) - len, "%s%s",
+					len ? " " : "", entry->desc);
+
+	dev_info(dev, "_OSC: %s [%s]\n", msg, buf);
+}
+
+static void decode_cxl_osc_support(struct device *dev, char *msg, u32 word)
+{
+	decode_osc_bits(dev, msg, word, cxl_osc_support_bit,
+			ARRAY_SIZE(cxl_osc_support_bit));
+}
+
+static void decode_cxl_osc_control(struct device *dev, char *msg, u32 word)
+{
+	decode_osc_bits(dev, msg, word, cxl_osc_control_bit,
+			ARRAY_SIZE(cxl_osc_control_bit));
+}
+
+static acpi_status acpi_cap_run_osc(acpi_handle handle,
+				    const u32 *capbuf, u8 *uuid_str, u32 *retval)
+{
+	struct acpi_osc_context context = {
+		.uuid_str = uuid_str,
+		.rev = 1,
+		.cap.length = 20,
+		.cap.pointer = (void *)capbuf,
+	};
+	acpi_status status;
+
+	status = acpi_run_osc(handle, &context);
+	if (ACPI_SUCCESS(status)) {
+		*retval = *((u32 *)(context.ret.pointer + 8));
+		kfree(context.ret.pointer);
+	}
+	return status;
+}
+
+static acpi_status cxl_query_osc(acpi_handle handle, u32 support, u32 *control)
+{
+	acpi_status status;
+	u32 result, capbuf[5];
+
+	support &= CXL_OSC_SUPPORT_VALID_MASK;
+	support |= cxl_osc_support_set;
+
+	capbuf[OSC_QUERY_DWORD] = OSC_QUERY_ENABLE;
+	capbuf[CXL_OSC_SUPPORT_DWORD] = support;
+	if (control) {
+		*control &= CXL_OSC_CONTROL_VALID_MASK;
+		capbuf[CXL_OSC_CONTROL_DWORD] = *control | cxl_osc_control_set;
+	} else {
+		/* Run _OSC query only with existing controls. */
+		capbuf[CXL_OSC_CONTROL_DWORD] = cxl_osc_control_set;
+	}
+
+	status = acpi_cap_run_osc(handle, capbuf, cxl_osc_uuid_str, &result);
+	if (ACPI_SUCCESS(status)) {
+		cxl_osc_support_set = support;
+		if (control)
+			*control = result;
+	}
+	return status;
+}
+
+static acpi_status cxl_osc_advertise_support(acpi_handle handle, u32 flags)
+{
+	acpi_status status;
+
+	mutex_lock(&acpi_desc_lock);
+	status = cxl_query_osc(handle, flags, NULL);
+	mutex_unlock(&acpi_desc_lock);
+	return status;
+}
+
+/**
+ * cxl_osc_request_control - Request control of CXL root _OSC features.
+ * @adev: ACPI device for the PCI root bridge (or PCIe Root Complex).
+ * @mask: Mask of _OSC bits to request control of, place to store control mask.
+ * @req: Mask of _OSC bits the control of is essential to the caller.
+ **/
+static acpi_status cxl_osc_request_control(struct acpi_device *adev, u32 *mask, u32 req)
+{
+	acpi_handle handle = adev->handle;
+	struct device *dev = &adev->dev;
+	acpi_status status = AE_OK;
+	u32 ctrl, capbuf[5];
+
+	if (!mask)
+		return AE_BAD_PARAMETER;
+
+	ctrl = *mask & CXL_OSC_MEM_ERROR_CONTROL;
+	if ((ctrl & req) != req)
+		return AE_TYPE;
+
+	mutex_lock(&acpi_desc_lock);
+
+	*mask = ctrl | cxl_osc_control_set;
+	/* No need to evaluate _OSC if the control was already granted. */
+	if ((cxl_osc_control_set & ctrl) == ctrl)
+		goto out;
+
+	/* Need to check the available controls bits before requesting them. */
+	while (*mask) {
+		status = cxl_query_osc(handle, cxl_osc_support_set, mask);
+		if (ACPI_FAILURE(status))
+			goto out;
+		if (ctrl == *mask)
+			break;
+		decode_cxl_osc_control(dev, "platform does not support", ctrl & ~(*mask));
+		ctrl = *mask;
+	}
+
+	if ((ctrl & req) != req) {
+		decode_cxl_osc_control(dev, "not requesting control; platform does not support",
+				       req & ~(ctrl));
+		status = AE_SUPPORT;
+		goto out;
+	}
+
+	capbuf[OSC_QUERY_DWORD] = 0;
+	capbuf[CXL_OSC_SUPPORT_DWORD] = cxl_osc_support_set;
+	capbuf[CXL_OSC_CONTROL_DWORD] = ctrl;
+	status = acpi_cap_run_osc(handle, capbuf, cxl_osc_uuid_str, mask);
+	if (ACPI_SUCCESS(status))
+		cxl_osc_control_set = *mask;
+out:
+	mutex_unlock(&acpi_desc_lock);
+	return status;
+}
+
+static int cxl_negotiate_osc(struct acpi_device *adev)
+{
+	u32 cxl_support, cxl_control, requested;
+	acpi_handle handle = adev->handle;
+	struct device *dev = &adev->dev;
+	acpi_status status;
+
+	/* Declare support for everything */
+	cxl_support = CXL_OSC_SUPPORT_VALID_MASK;
+	decode_cxl_osc_support(dev, "OS supports", cxl_support);
+	status = cxl_osc_advertise_support(handle, cxl_support);
+	if (ACPI_FAILURE(status)) {
+		dev_info(dev, "CXL_OSC failed (%s)\n", acpi_format_exception(status));
+		return -ENXIO;
+	}
+
+	/* Request control for everything */
+	cxl_control = CXL_OSC_CONTROL_VALID_MASK;
+	requested = cxl_control;
+	status = cxl_osc_request_control(adev, &cxl_control, CXL_OSC_MEM_ERROR_CONTROL);
+	if (ACPI_SUCCESS(status)) {
+		decode_cxl_osc_control(dev, "OS now controls", cxl_control);
+	} else {
+		decode_cxl_osc_control(dev, "OS requested", requested);
+		decode_cxl_osc_control(dev, "platform willing to grant", cxl_control);
+		dev_info(dev, "_OSC failed (%s)\n", acpi_format_exception(status));
+	}
+	return 0;
+}
+
 /*
  * If/when CXL support is defined by other platform firmware the kernel
  * will need a mechanism to select between the platform specific version
@@ -84,6 +287,7 @@ int cxl_bus_prepared(struct pci_dev *pdev)
 	struct acpi_device *adev;
 	struct pci_dev *root_port;
 	struct device *root;
+	int rc;
 
 	root_port = pcie_find_root_port(pdev);
 	if (!root_port)
@@ -97,9 +301,11 @@ int cxl_bus_prepared(struct pci_dev *pdev)
 	if (!adev)
 		return -ENXIO;
 
-	/* TODO: OSC enabling */
+	rc = cxl_negotiate_osc(adev);
+	if (rc)
+		dev_err(&pdev->dev, "Failed to negotiate OSC\n");
 
-	return 0;
+	return rc;
 }
 EXPORT_SYMBOL_GPL(cxl_bus_prepared);
 
diff --git a/drivers/cxl/acpi.h b/drivers/cxl/acpi.h
index 011505475cc6..bf8d078e1b2a 100644
--- a/drivers/cxl/acpi.h
+++ b/drivers/cxl/acpi.h
@@ -10,6 +10,24 @@ struct acpi_cxl_desc {
 	struct device *dev;
 };
 
+/* Indexes into _OSC Capabilities Buffer */
+#define CXL_OSC_SUPPORT_DWORD			1	/* DWORD 2 */
+#define CXL_OSC_CONTROL_DWORD			2	/* DWORD 3 */
+
+/* CXL Host Bridge _OSC: Capabilities DWORD 2: Support Field */
+#define CXL_OSC_PORT_REG_ACCESS_SUPPORT		0x00000001
+#define CXL_OSC_PORT_DEV_REG_ACCESS_SUPPORT	0x00000002
+#define CXL_OSC_PER_SUPPORT			0x00000004
+#define CXL_OSC_NATIVE_HP_SUPPORT		0x00000008
+#define CXL_OSC_SUPPORT_VALID_MASK		(CXL_OSC_PORT_REG_ACCESS_SUPPORT |	\
+						 CXL_OSC_PORT_DEV_REG_ACCESS_SUPPORT |	\
+						 CXL_OSC_PER_SUPPORT |			\
+						 CXL_OSC_NATIVE_HP_SUPPORT)
+
+/* CXL Host Bridge _OSC: Capabilities DWORD 3: Control Field */
+#define CXL_OSC_MEM_ERROR_CONTROL		0x00000001
+#define CXL_OSC_CONTROL_VALID_MASK		(CXL_OSC_MEM_ERROR_CONTROL)
+
 int cxl_bus_prepared(struct pci_dev *pci_dev);
 
 #endif	/* __CXL_ACPI_H__ */
-- 
2.29.2


^ permalink raw reply	[flat|nested] 73+ messages in thread

* [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
  2020-11-11  5:43 ` [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect Ben Widawsky
  2020-11-11  5:43 ` [RFC PATCH 2/9] cxl/acpi: add OSC support Ben Widawsky
@ 2020-11-11  5:43 ` Ben Widawsky
  2020-11-11  6:17   ` Randy Dunlap
                     ` (3 more replies)
  2020-11-11  5:43 ` [RFC PATCH 4/9] cxl/mem: Map memory device registers Ben Widawsky
                   ` (7 subsequent siblings)
  10 siblings, 4 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11  5:43 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki,
	Ben Widawsky

From: Dan Williams <dan.j.williams@intel.com>

The CXL.mem protocol allows a device to act as a provider of "System
RAM" and/or "Persistent Memory" that is fully coherent as if the memory
was attached to the typical CPU memory controller.

The memory range exported by the device may optionally be described by
the platform firmware memory map, or by infrastructure like LIBNVDIMM to
provision persistent memory capacity from one, or more, CXL.mem devices.

A pre-requisite for Linux-managed memory-capacity provisioning is this
cxl_mem driver that can speak the "type-3 mailbox" protocol.

For now just land the driver boiler-plate and fill it in with
functionality in subsequent commits.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
---
 drivers/cxl/Kconfig  | 20 +++++++++++
 drivers/cxl/Makefile |  2 ++
 drivers/cxl/mem.c    | 82 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/cxl/pci.h    | 15 ++++++++
 4 files changed, 119 insertions(+)
 create mode 100644 drivers/cxl/mem.c
 create mode 100644 drivers/cxl/pci.h

diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index dd724bd364df..15548f5c77ff 100644
--- a/drivers/cxl/Kconfig
+++ b/drivers/cxl/Kconfig
@@ -27,4 +27,24 @@ config CXL_ACPI
 	  resources described by the CEDT (CXL Early Discovery Table)
 
 	  Say 'y' to enable CXL (Compute Express Link) drivers.
+
+config CXL_MEM
+        tristate "CXL.mem Device Support"
+        depends on PCI && CXL_BUS_PROVIDER != n
+        default m if CXL_BUS_PROVIDER
+        help
+          The CXL.mem protocol allows a device to act as a provider of
+          "System RAM" and/or "Persistent Memory" that is fully coherent
+          as if the memory was attached to the typical CPU memory
+          controller.
+
+          Say 'y/m' to enable a driver named "cxl_mem.ko" that will attach
+          to CXL.mem devices for configuration, provisioning, and health
+          monitoring, the so called "type-3 mailbox". Note, this driver
+          is required for dynamic provisioning of CXL.mem attached
+          memory, a pre-requisite for persistent memory support, but
+          devices that provide volatile memory may be fully described by
+          existing platform firmware memory enumeration.
+
+          If unsure say 'n'.
 endif
diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
index d38cd34a2582..97fdffb00f2d 100644
--- a/drivers/cxl/Makefile
+++ b/drivers/cxl/Makefile
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
+obj-$(CONFIG_CXL_MEM) += cxl_mem.o
 
 ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
 cxl_acpi-y := acpi.o
+cxl_mem-y := mem.o
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
new file mode 100644
index 000000000000..aa7d881fa47b
--- /dev/null
+++ b/drivers/cxl/mem.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright(c) 2020 Intel Corporation. All rights reserved.
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/io.h>
+#include "acpi.h"
+#include "pci.h"
+
+struct cxl_mem {
+	void __iomem *regs;
+};
+
+static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
+{
+	int pos;
+
+	pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DVSEC);
+	if (!pos)
+		return 0;
+
+	while (pos) {
+		u16 vendor, id;
+
+		pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, &vendor);
+		pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, &id);
+		if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
+			return pos;
+
+		pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
+	}
+
+	return 0;
+}
+
+static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+	struct device *dev = &pdev->dev;
+	struct cxl_mem *cxlm;
+	int rc, regloc;
+
+	rc = cxl_bus_prepared(pdev);
+	if (rc != 0) {
+		dev_err(dev, "failed to acquire interface\n");
+		return rc;
+	}
+
+	regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
+	if (!regloc) {
+		dev_err(dev, "register location dvsec not found\n");
+		return -ENXIO;
+	}
+
+	cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
+	if (!cxlm)
+		return -ENOMEM;
+
+	return 0;
+}
+
+static void cxl_mem_remove(struct pci_dev *pdev)
+{
+}
+
+static const struct pci_device_id cxl_mem_pci_tbl[] = {
+	/* PCI class code for CXL.mem Type-3 Devices */
+	{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
+	  PCI_CLASS_MEMORY_CXL, 0xffffff, 0 },
+	{ /* terminate list */ },
+};
+MODULE_DEVICE_TABLE(pci, cxl_mem_pci_tbl);
+
+static struct pci_driver cxl_mem_driver = {
+	.name			= KBUILD_MODNAME,
+	.id_table		= cxl_mem_pci_tbl,
+	.probe			= cxl_mem_probe,
+	.remove			= cxl_mem_remove,
+};
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Intel Corporation");
+module_pci_driver(cxl_mem_driver);
+MODULE_IMPORT_NS(CXL);
diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
new file mode 100644
index 000000000000..beb03921e6da
--- /dev/null
+++ b/drivers/cxl/pci.h
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright(c) 2020 Intel Corporation. All rights reserved.
+#ifndef __CXL_PCI_H__
+#define __CXL_PCI_H__
+
+#define PCI_CLASS_MEMORY_CXL	0x050210
+
+#define PCI_EXT_CAP_ID_DVSEC	0x23
+#define PCI_DVSEC_VENDOR_CXL	0x1E98
+#define PCI_DVSEC_VENDOR_OFFSET	0x4
+#define PCI_DVSEC_ID_OFFSET	0x8
+#define PCI_DVSEC_ID_CXL	0x0
+#define PCI_DVSEC_ID_CXL_REGLOC	0x8
+
+#endif /* __CXL_PCI_H__ */
-- 
2.29.2


^ permalink raw reply	[flat|nested] 73+ messages in thread

* [RFC PATCH 4/9] cxl/mem: Map memory device registers
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
                   ` (2 preceding siblings ...)
  2020-11-11  5:43 ` [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox Ben Widawsky
@ 2020-11-11  5:43 ` Ben Widawsky
  2020-11-13 18:17   ` Bjorn Helgaas
  2020-11-17 15:00   ` Jonathan Cameron
  2020-11-11  5:43 ` [RFC PATCH 5/9] cxl/mem: Find device capabilities Ben Widawsky
                   ` (6 subsequent siblings)
  10 siblings, 2 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11  5:43 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki,
	Ben Widawsky

All the necessary bits are initialized in order to find and map the
register space for CXL Memory Devices. This is accomplished by using the
Register Locator DVSEC (CXL 2.0 - 8.1.9.1) to determine which PCI BAR to
use, and how much of an offset from that BAR should be added.

If the memory device registers are found and mapped a new internal data
structure tracking device state is allocated.

Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
---
 drivers/cxl/mem.c | 68 +++++++++++++++++++++++++++++++++++++++++++----
 drivers/cxl/pci.h |  6 +++++
 2 files changed, 69 insertions(+), 5 deletions(-)

diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index aa7d881fa47b..8d9b9ab6c5ea 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -7,9 +7,49 @@
 #include "pci.h"
 
 struct cxl_mem {
+	struct pci_dev *pdev;
 	void __iomem *regs;
 };
 
+static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo, u32 reg_hi)
+{
+	struct device *dev = &pdev->dev;
+	struct cxl_mem *cxlm;
+	void __iomem *regs;
+	u64 offset;
+	u8 bar;
+	int rc;
+
+	offset = ((u64)reg_hi << 32) | (reg_lo & 0xffff0000);
+	bar = reg_lo & 0x7;
+
+	/* Basic sanity check that BAR is big enough */
+	if (pci_resource_len(pdev, bar) < offset) {
+		dev_err(dev, "bar%d: %pr: too small (offset: %#llx)\n",
+				bar, &pdev->resource[bar], (unsigned long long) offset);
+		return ERR_PTR(-ENXIO);
+	}
+
+	rc = pcim_iomap_regions(pdev, 1 << bar, pci_name(pdev));
+	if (rc != 0) {
+		dev_err(dev, "failed to map registers\n");
+		return ERR_PTR(-ENXIO);
+	}
+
+	cxlm = devm_kzalloc(&pdev->dev, sizeof(*cxlm), GFP_KERNEL);
+	if (!cxlm) {
+		dev_err(dev, "No memory available\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	regs = pcim_iomap_table(pdev)[bar];
+	cxlm->pdev = pdev;
+	cxlm->regs = regs + offset;
+
+	dev_dbg(dev, "Mapped CXL Memory Device resource\n");
+	return cxlm;
+}
+
 static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
 {
 	int pos;
@@ -34,9 +74,9 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
 
 static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
+	struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
 	struct device *dev = &pdev->dev;
-	struct cxl_mem *cxlm;
-	int rc, regloc;
+	int rc, regloc, i;
 
 	rc = cxl_bus_prepared(pdev);
 	if (rc != 0) {
@@ -44,15 +84,33 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 		return rc;
 	}
 
+	rc = pcim_enable_device(pdev);
+	if (rc)
+		return rc;
+
 	regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
 	if (!regloc) {
 		dev_err(dev, "register location dvsec not found\n");
 		return -ENXIO;
 	}
+	regloc += 0xc; /* Skip DVSEC + reserved fields */
+
+	for (i = regloc; i < regloc + 0x24; i += 8) {
+		u32 reg_lo, reg_hi;
+
+		pci_read_config_dword(pdev, i, &reg_lo);
+		pci_read_config_dword(pdev, i + 4, &reg_hi);
+
+		if (CXL_REGLOG_IS_MEMDEV(reg_lo)) {
+			cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
+			break;
+		}
+	}
+
+	if (IS_ERR(cxlm))
+		return -ENXIO;
 
-	cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
-	if (!cxlm)
-		return -ENOMEM;
+	pci_set_drvdata(pdev, cxlm);
 
 	return 0;
 }
diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
index beb03921e6da..be87f62e9132 100644
--- a/drivers/cxl/pci.h
+++ b/drivers/cxl/pci.h
@@ -12,4 +12,10 @@
 #define PCI_DVSEC_ID_CXL	0x0
 #define PCI_DVSEC_ID_CXL_REGLOC	0x8
 
+#define CXL_REGLOG_RBI_EMPTY 0
+#define CXL_REGLOG_RBI_COMPONENT 1
+#define CXL_REGLOG_RBI_VIRT 2
+#define CXL_REGLOG_RBI_MEMDEV 3
+#define CXL_REGLOG_IS_MEMDEV(x) ((((x) >> 8) & 0xff) == CXL_REGLOG_RBI_MEMDEV)
+
 #endif /* __CXL_PCI_H__ */
-- 
2.29.2


^ permalink raw reply	[flat|nested] 73+ messages in thread

* [RFC PATCH 5/9] cxl/mem: Find device capabilities
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
                   ` (3 preceding siblings ...)
  2020-11-11  5:43 ` [RFC PATCH 4/9] cxl/mem: Map memory device registers Ben Widawsky
@ 2020-11-11  5:43 ` Ben Widawsky
  2020-11-13 18:26   ` Bjorn Helgaas
                     ` (3 more replies)
  2020-11-11  5:43 ` [RFC PATCH 6/9] cxl/mem: Initialize the mailbox interface Ben Widawsky
                   ` (5 subsequent siblings)
  10 siblings, 4 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11  5:43 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki,
	Ben Widawsky

CXL devices contain an array of capabilities that describe the
interactions software can interact with the device, or firmware running
on the device. A CXL compliant device must implement the device status
and the mailbox capability. A CXL compliant memory device must implement
the memory device capability.

Each of the capabilities can [will] provide an offset within the MMIO
region for interacting with the CXL device.

Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
---
 drivers/cxl/cxl.h | 89 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/cxl/mem.c | 58 +++++++++++++++++++++++++++---
 2 files changed, 143 insertions(+), 4 deletions(-)
 create mode 100644 drivers/cxl/cxl.h

diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
new file mode 100644
index 000000000000..02858ae63d6d
--- /dev/null
+++ b/drivers/cxl/cxl.h
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright(c) 2020 Intel Corporation. All rights reserved.
+
+#ifndef __CXL_H__
+#define __CXL_H__
+
+/* Device */
+#define CXLDEV_CAP_ARRAY_REG 0x0
+#define CXLDEV_CAP_ARRAY_CAP_ID 0
+#define CXLDEV_CAP_ARRAY_ID(x) ((x) & 0xffff)
+#define CXLDEV_CAP_ARRAY_COUNT(x) (((x) >> 32) & 0xffff)
+
+#define CXL_CAPABILITIES_CAP_ID_DEVICE_STATUS 1
+#define CXL_CAPABILITIES_CAP_ID_PRIMARY_MAILBOX 2
+#define CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX 3
+#define CXL_CAPABILITIES_CAP_ID_MEMDEV 0x4000
+
+/* Mailbox */
+#define CXLDEV_MB_CAPS 0x00
+#define   CXLDEV_MB_CAP_PAYLOAD_SIZE(cap) ((cap) & 0x1F)
+#define CXLDEV_MB_CTRL 0x04
+#define CXLDEV_MB_CMD 0x08
+#define CXLDEV_MB_STATUS 0x10
+#define CXLDEV_MB_BG_CMD_STATUS 0x18
+
+struct cxl_mem {
+	struct pci_dev *pdev;
+	void __iomem *regs;
+
+	/* Cap 0000h */
+	struct {
+		void __iomem *regs;
+	} status;
+
+	/* Cap 0002h */
+	struct {
+		void __iomem *regs;
+		size_t payload_size;
+	} mbox;
+
+	/* Cap 0040h */
+	struct {
+		void __iomem *regs;
+	} mem;
+};
+
+#define cxl_reg(type)                                                          \
+	static inline void cxl_write_##type##_reg32(struct cxl_mem *cxlm,      \
+						    u32 reg, u32 value)        \
+	{                                                                      \
+		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
+		writel(value, reg_addr + reg);                                 \
+	}                                                                      \
+	static inline void cxl_write_##type##_reg64(struct cxl_mem *cxlm,      \
+						    u32 reg, u64 value)        \
+	{                                                                      \
+		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
+		writeq(value, reg_addr + reg);                                 \
+	}                                                                      \
+	static inline u32 cxl_read_##type##_reg32(struct cxl_mem *cxlm,        \
+						  u32 reg)                     \
+	{                                                                      \
+		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
+		return readl(reg_addr + reg);                                  \
+	}                                                                      \
+	static inline u64 cxl_read_##type##_reg64(struct cxl_mem *cxlm,        \
+						  u32 reg)                     \
+	{                                                                      \
+		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
+		return readq(reg_addr + reg);                                  \
+	}
+
+cxl_reg(status)
+cxl_reg(mbox)
+
+static inline u32 __cxl_raw_read_reg32(struct cxl_mem *cxlm, u32 reg)
+{
+	void __iomem *reg_addr = READ_ONCE(cxlm->regs);
+
+	return readl(reg_addr + reg);
+}
+
+static inline u64 __cxl_raw_read_reg64(struct cxl_mem *cxlm, u32 reg)
+{
+	void __iomem *reg_addr = READ_ONCE(cxlm->regs);
+
+	return readq(reg_addr + reg);
+}
+#endif /* __CXL_H__ */
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 8d9b9ab6c5ea..4109ef7c3ecb 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -5,11 +5,57 @@
 #include <linux/io.h>
 #include "acpi.h"
 #include "pci.h"
+#include "cxl.h"
 
-struct cxl_mem {
-	struct pci_dev *pdev;
-	void __iomem *regs;
-};
+static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
+{
+	u64 cap_array;
+	int cap;
+
+	cap_array = __cxl_raw_read_reg64(cxlm, CXLDEV_CAP_ARRAY_REG);
+	if (CXLDEV_CAP_ARRAY_ID(cap_array) != CXLDEV_CAP_ARRAY_CAP_ID)
+		return -ENODEV;
+
+	for (cap = 1; cap <= CXLDEV_CAP_ARRAY_COUNT(cap_array); cap++) {
+		void *__iomem register_block;
+		u32 offset;
+		u16 cap_id;
+
+		cap_id = __cxl_raw_read_reg32(cxlm, cap * 0x10) & 0xffff;
+		offset = __cxl_raw_read_reg32(cxlm, cap * 0x10 + 0x4);
+		register_block = cxlm->regs + offset;
+
+		switch (cap_id) {
+		case CXL_CAPABILITIES_CAP_ID_DEVICE_STATUS:
+			dev_dbg(&cxlm->pdev->dev, "found Status capability\n");
+			cxlm->status.regs = register_block;
+			break;
+		case CXL_CAPABILITIES_CAP_ID_PRIMARY_MAILBOX:
+			dev_dbg(&cxlm->pdev->dev,
+				 "found Mailbox capability\n");
+			cxlm->mbox.regs = register_block;
+			cxlm->mbox.payload_size = CXLDEV_MB_CAP_PAYLOAD_SIZE(cap_id);
+			break;
+		case CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX:
+			dev_dbg(&cxlm->pdev->dev,
+				   "found UNSUPPORTED Secondary Mailbox capability\n");
+			break;
+		case CXL_CAPABILITIES_CAP_ID_MEMDEV:
+			dev_dbg(&cxlm->pdev->dev,
+				 "found Memory Device capability\n");
+			cxlm->mem.regs = register_block;
+			break;
+		default:
+			dev_err(&cxlm->pdev->dev, "Unknown cap ID: %d\n", cap_id);
+			return -ENXIO;
+		}
+	}
+
+	if (!cxlm->status.regs || !cxlm->mbox.regs || !cxlm->mem.regs)
+		return -ENXIO;
+
+	return 0;
+}
 
 static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo, u32 reg_hi)
 {
@@ -110,6 +156,10 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	if (IS_ERR(cxlm))
 		return -ENXIO;
 
+	rc = cxl_mem_setup_regs(cxlm);
+	if (rc)
+		return rc;
+
 	pci_set_drvdata(pdev, cxlm);
 
 	return 0;
-- 
2.29.2


^ permalink raw reply	[flat|nested] 73+ messages in thread

* [RFC PATCH 6/9] cxl/mem: Initialize the mailbox interface
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
                   ` (4 preceding siblings ...)
  2020-11-11  5:43 ` [RFC PATCH 5/9] cxl/mem: Find device capabilities Ben Widawsky
@ 2020-11-11  5:43 ` Ben Widawsky
  2020-11-17 15:22   ` Jonathan Cameron
  2020-11-11  5:43 ` [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox Ben Widawsky
                   ` (4 subsequent siblings)
  10 siblings, 1 reply; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11  5:43 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki,
	Ben Widawsky

Provide enough functionality to utilize the mailbox of a memory device.
The mailbox is used to interact with the firmware running on the memory
device.

The CXL specification defines separate capabilities for the mailbox and the
memory device. While we can confirm the mailbox is ready, in order to actually
interact with the memory device, the driver must also confirm the device's
firmware is ready.

Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
---
 drivers/cxl/cxl.h | 28 ++++++++++++++++++++++
 drivers/cxl/mem.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 87 insertions(+)

diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index 02858ae63d6d..482fc9cdc890 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -19,14 +19,41 @@
 #define CXLDEV_MB_CAPS 0x00
 #define   CXLDEV_MB_CAP_PAYLOAD_SIZE(cap) ((cap) & 0x1F)
 #define CXLDEV_MB_CTRL 0x04
+#define   CXLDEV_MB_CTRL_DOORBELL BIT(0)
 #define CXLDEV_MB_CMD 0x08
 #define CXLDEV_MB_STATUS 0x10
 #define CXLDEV_MB_BG_CMD_STATUS 0x18
 
+/* Memory Device */
+#define CXLMDEV_STATUS 0
+#define CXLMDEV_DEV_FATAL BIT(0)
+#define CXLMDEV_FW_HALT BIT(1)
+#define CXLMDEV_MEDIA_STATUS_SHIFT 2
+#define CXLMDEV_MEDIA_STATUS_MASK 0x3
+#define CXLMDEV_READY(status)                                                  \
+	((((status) >> CXLMDEV_MEDIA_STATUS_SHIFT) &                           \
+	  CXLMDEV_MEDIA_STATUS_MASK) == CXLMDEV_MS_READY)
+#define CXLMDEV_MS_NOT_READY 0
+#define CXLMDEV_MS_READY 1
+#define CXLMDEV_MS_ERROR 2
+#define CXLMDEV_MS_DISABLED 3
+#define CXLMDEV_MBOX_IF_READY BIT(4)
+#define CXLMDEV_RESET_NEEDED_SHIFT 5
+#define CXLMDEV_RESET_NEEDED_MASK 0x7
+#define CXLMDEV_RESET_NEEDED(status)                                           \
+	(((status) >> CXLMDEV_RESET_NEEDED_SHIFT) & CXLMDEV_RESET_NEEDED_MASK)
+#define CXLMDEV_RESET_NEEDED_NOT 0
+#define CXLMDEV_RESET_NEEDED_COLD 1
+#define CXLMDEV_RESET_NEEDED_WARM 2
+#define CXLMDEV_RESET_NEEDED_HOT 3
+#define CXLMDEV_RESET_NEEDED_CXL 4
+
 struct cxl_mem {
 	struct pci_dev *pdev;
 	void __iomem *regs;
 
+	spinlock_t mbox_lock; /* Protects device mailbox and firmware */
+
 	/* Cap 0000h */
 	struct {
 		void __iomem *regs;
@@ -72,6 +99,7 @@ struct cxl_mem {
 
 cxl_reg(status)
 cxl_reg(mbox)
+cxl_reg(mem)
 
 static inline u32 __cxl_raw_read_reg32(struct cxl_mem *cxlm, u32 reg)
 {
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 4109ef7c3ecb..9fd2d1daa534 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -7,6 +7,56 @@
 #include "pci.h"
 #include "cxl.h"
 
+static int cxl_mem_mbox_get(struct cxl_mem *cxlm)
+{
+	u64 md_status;
+	u32 ctrl;
+	int rc = -EBUSY;
+
+	spin_lock(&cxlm->mbox_lock);
+
+	ctrl = cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CTRL);
+	if (ctrl & CXLDEV_MB_CTRL_DOORBELL)
+		goto out;
+
+	md_status = cxl_read_mem_reg64(cxlm, CXLMDEV_STATUS);
+	if (md_status & CXLMDEV_MBOX_IF_READY && CXLMDEV_READY(md_status)) {
+		/*
+		 * Hardware shouldn't allow a ready status but also have failure
+		 * bits set. Spit out an error, this should be a bug report
+		 */
+		if (md_status & CXLMDEV_DEV_FATAL) {
+			dev_err(&cxlm->pdev->dev,
+				"CXL device reporting ready and fatal\n");
+			rc = -EFAULT;
+			goto out;
+		}
+		if (md_status & CXLMDEV_FW_HALT) {
+			dev_err(&cxlm->pdev->dev,
+				"CXL device reporting ready and halted\n");
+			rc = -EFAULT;
+			goto out;
+		}
+		if (CXLMDEV_RESET_NEEDED(md_status)) {
+			dev_err(&cxlm->pdev->dev,
+				"CXL device reporting ready and reset needed\n");
+			rc = -EFAULT;
+			goto out;
+		}
+
+		return 0;
+	}
+
+out:
+	spin_unlock(&cxlm->mbox_lock);
+	return rc;
+}
+
+static void cxl_mem_mbox_put(struct cxl_mem *cxlm)
+{
+	spin_unlock(&cxlm->mbox_lock);
+}
+
 static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
 {
 	u64 cap_array;
@@ -88,6 +138,8 @@ static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo, u32 reg_
 		return ERR_PTR(-ENOMEM);
 	}
 
+	spin_lock_init(&cxlm->mbox_lock);
+
 	regs = pcim_iomap_table(pdev)[bar];
 	cxlm->pdev = pdev;
 	cxlm->regs = regs + offset;
@@ -160,6 +212,13 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	if (rc)
 		return rc;
 
+	/* Check that hardware "looks" okay. */
+	rc = cxl_mem_mbox_get(cxlm);
+	if (rc)
+		return rc;
+
+	cxl_mem_mbox_put(cxlm);
+	dev_dbg(&pdev->dev, "CXL Memory Device Interface Up\n");
 	pci_set_drvdata(pdev, cxlm);
 
 	return 0;
-- 
2.29.2


^ permalink raw reply	[flat|nested] 73+ messages in thread

* [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
                   ` (5 preceding siblings ...)
  2020-11-11  5:43 ` [RFC PATCH 6/9] cxl/mem: Initialize the mailbox interface Ben Widawsky
@ 2020-11-11  5:43 ` Ben Widawsky
  2020-11-13 23:14   ` Bjorn Helgaas
  2020-11-17 15:31   ` Jonathan Cameron
  2020-11-11  5:43 ` [RFC PATCH 8/9] cxl/mem: Register CXL memX devices Ben Widawsky
                   ` (3 subsequent siblings)
  10 siblings, 2 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11  5:43 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki,
	Ben Widawsky

Create a function to handle sending a command, optionally with a
payload, to the memory device, polling on a result, and then optionally
copying out the payload. The algorithm for doing this come straight out
of the CXL 2.0 specification.

Primary mailboxes are capable of generating an interrupt when submitting
a command in the background. That implementation is saved for a later
time.

Secondary mailboxes aren't implemented at this time.

WARNING: This is untested with actual timeouts occurring.

Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
---
 drivers/cxl/cxl.h |  16 +++++++
 drivers/cxl/mem.c | 107 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 123 insertions(+)

diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index 482fc9cdc890..f49ab80f68bd 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -21,8 +21,12 @@
 #define CXLDEV_MB_CTRL 0x04
 #define   CXLDEV_MB_CTRL_DOORBELL BIT(0)
 #define CXLDEV_MB_CMD 0x08
+#define   CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT 16
 #define CXLDEV_MB_STATUS 0x10
+#define   CXLDEV_MB_STATUS_RET_CODE_SHIFT 32
+#define   CXLDEV_MB_STATUS_RET_CODE_MASK 0xffff
 #define CXLDEV_MB_BG_CMD_STATUS 0x18
+#define CXLDEV_MB_PAYLOAD 0x20
 
 /* Memory Device */
 #define CXLMDEV_STATUS 0
@@ -114,4 +118,16 @@ static inline u64 __cxl_raw_read_reg64(struct cxl_mem *cxlm, u32 reg)
 
 	return readq(reg_addr + reg);
 }
+
+static inline void cxl_mbox_payload_fill(struct cxl_mem *cxlm, u8 *input,
+					    unsigned int length)
+{
+	memcpy_toio(cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, input, length);
+}
+
+static inline void cxl_mbox_payload_drain(struct cxl_mem *cxlm,
+					     u8 *output, unsigned int length)
+{
+	memcpy_fromio(output, cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, length);
+}
 #endif /* __CXL_H__ */
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 9fd2d1daa534..08913360d500 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 // Copyright(c) 2020 Intel Corporation. All rights reserved.
+#include <linux/sched/clock.h>
 #include <linux/module.h>
 #include <linux/pci.h>
 #include <linux/io.h>
@@ -7,6 +8,112 @@
 #include "pci.h"
 #include "cxl.h"
 
+struct mbox_cmd {
+	u16 cmd;
+	u8 *payload;
+	size_t payload_size;
+	u16 return_code;
+};
+
+static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
+{
+	u64 start, now;
+	int cpu, ret, timeout = 2000000000;
+
+	start = local_clock();
+	preempt_disable();
+	cpu = smp_processor_id();
+	for (;;) {
+		now = local_clock();
+		preempt_enable();
+		if ((cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CTRL) &
+		     CXLDEV_MB_CTRL_DOORBELL) == 0) {
+			ret = 0;
+			break;
+		}
+
+		if (now - start >= timeout) {
+			ret = -ETIMEDOUT;
+			break;
+		}
+
+		cpu_relax();
+		preempt_disable();
+		if (unlikely(cpu != smp_processor_id())) {
+			timeout -= (now - start);
+			cpu = smp_processor_id();
+			start = local_clock();
+		}
+	}
+
+	return ret;
+}
+
+/*
+ * Returns 0 if the doorbell transaction was successful from a protocol level.
+ * Caller should check the return code in @mbox_cmd to make sure it succeeded.
+ */
+static int __maybe_unused cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, struct mbox_cmd *mbox_cmd)
+{
+	u64 cmd, status;
+	int rc;
+
+	lockdep_assert_held(&cxlm->mbox_lock);
+
+	/*
+	 * Here are the steps from 8.2.8.4 of the CXL 2.0 spec.
+	 *   1. Caller reads MB Control Register to verify doorbell is clear
+	 *   2. Caller writes Command Register
+	 *   3. Caller writes Command Payload Registers if input payload is non-empty
+	 *   4. Caller writes MB Control Register to set doorbell
+	 *   5. Caller either polls for doorbell to be clear or waits for interrupt if configured
+	 *   6. Caller reads MB Status Register to fetch Return code
+	 *   7. If command successful, Caller reads Command Register to get Payload Length
+	 *   8. If output payload is non-empty, host reads Command Payload Registers
+	 */
+
+	cmd = mbox_cmd->cmd;
+	if (mbox_cmd->payload_size) {
+		/* #3 */
+		cmd |= mbox_cmd->payload_size
+		       << CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT;
+		cxl_mbox_payload_fill(cxlm, mbox_cmd->payload, mbox_cmd->payload_size);
+	}
+
+	/* #2 */
+	cxl_write_mbox_reg64(cxlm, CXLDEV_MB_CMD, cmd);
+
+	/* #4 */
+	cxl_write_mbox_reg32(cxlm, CXLDEV_MB_CTRL, CXLDEV_MB_CTRL_DOORBELL);
+
+	/* #5 */
+	rc = cxldev_wait_for_doorbell(cxlm);
+	if (rc == -ETIMEDOUT) {
+		dev_warn(&cxlm->pdev->dev, "Mailbox command timed out\n");
+		return rc;
+	}
+
+	/* #6 */
+	status = cxl_read_mbox_reg64(cxlm, CXLDEV_MB_STATUS);
+	cmd = cxl_read_mbox_reg64(cxlm, CXLDEV_MB_CMD);
+
+	mbox_cmd->return_code = (status >> CXLDEV_MB_STATUS_RET_CODE_SHIFT) &
+				CXLDEV_MB_STATUS_RET_CODE_MASK;
+
+	/* There was a problem, let the caller deal with it */
+	if (mbox_cmd->return_code != 0)
+		return 0;
+
+	/* #7 */
+	mbox_cmd->payload_size = cmd >> CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT;
+
+	/* #8 */
+	if (mbox_cmd->payload_size)
+		cxl_mbox_payload_drain(cxlm, mbox_cmd->payload, mbox_cmd->payload_size);
+
+	return 0;
+}
+
 static int cxl_mem_mbox_get(struct cxl_mem *cxlm)
 {
 	u64 md_status;
-- 
2.29.2


^ permalink raw reply	[flat|nested] 73+ messages in thread

* [RFC PATCH 8/9] cxl/mem: Register CXL memX devices
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
                   ` (6 preceding siblings ...)
  2020-11-11  5:43 ` [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox Ben Widawsky
@ 2020-11-11  5:43 ` Ben Widawsky
  2020-11-17 15:56   ` Jonathan Cameron
  2020-11-11  5:43 ` [RFC PATCH 9/9] MAINTAINERS: Add maintainers of the CXL driver Ben Widawsky
                   ` (2 subsequent siblings)
  10 siblings, 1 reply; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11  5:43 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki,
	Ben Widawsky

From: Dan Williams <dan.j.williams@intel.com>

Create the /sys/bus/cxl hierarchy to enumerate memory devices
(per-endpoint control devices), memory address space devices (platform
address ranges with interleaving, performance, and persistence
attributes), and memory regions (active provisioned memory from an
address space device that is in use as System RAM or delegated to
libnvdimm as Persistent Memory regions).

For now, only the per-endpoint control devices are registered on the
'cxl' bus.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
---
 drivers/cxl/Makefile |   2 +
 drivers/cxl/bus.c    |  35 ++++++
 drivers/cxl/bus.h    |   8 ++
 drivers/cxl/cxl.h    |  33 +++++
 drivers/cxl/mem.c    | 287 ++++++++++++++++++++++++++++++++++++++++++-
 5 files changed, 359 insertions(+), 6 deletions(-)
 create mode 100644 drivers/cxl/bus.c
 create mode 100644 drivers/cxl/bus.h

diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
index 97fdffb00f2d..1cc032092852 100644
--- a/drivers/cxl/Makefile
+++ b/drivers/cxl/Makefile
@@ -1,7 +1,9 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
 obj-$(CONFIG_CXL_MEM) += cxl_mem.o
+obj-$(CONFIG_CXL_BUS_PROVIDER) += cxl_bus.o
 
 ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
 cxl_acpi-y := acpi.o
 cxl_mem-y := mem.o
+cxl_bus-y := bus.o
diff --git a/drivers/cxl/bus.c b/drivers/cxl/bus.c
new file mode 100644
index 000000000000..8594366955f7
--- /dev/null
+++ b/drivers/cxl/bus.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright(c) 2020 Intel Corporation. All rights reserved.
+#include <linux/device.h>
+#include <linux/module.h>
+
+static struct bus_type cxl_bus_type = {
+	.name = "cxl",
+};
+
+int cxl_register(struct device *dev)
+{
+	int rc;
+
+	dev->bus = &cxl_bus_type;
+	rc = device_add(dev);
+	if (rc)
+		put_device(dev);
+	return rc;
+}
+EXPORT_SYMBOL_GPL(cxl_register);
+
+static __init int cxl_bus_init(void)
+{
+	return bus_register(&cxl_bus_type);
+}
+
+static void cxl_bus_exit(void)
+{
+	bus_unregister(&cxl_bus_type);
+}
+
+module_init(cxl_bus_init);
+module_exit(cxl_bus_exit);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Intel Corporation");
diff --git a/drivers/cxl/bus.h b/drivers/cxl/bus.h
new file mode 100644
index 000000000000..fe2bea2bbc3c
--- /dev/null
+++ b/drivers/cxl/bus.h
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright(c) 2020 Intel Corporation. All rights reserved.
+#ifndef __CXL_BUS_H__
+#define __CXL_BUS_H__
+
+int cxl_register(struct device *dev);
+
+#endif /* __CXL_BUS_H__ */
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index f49ab80f68bd..cef5fd9ea68b 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -3,6 +3,7 @@
 
 #ifndef __CXL_H__
 #define __CXL_H__
+#include <linux/range.h>
 
 /* Device */
 #define CXLDEV_CAP_ARRAY_REG 0x0
@@ -52,12 +53,24 @@
 #define CXLMDEV_RESET_NEEDED_HOT 3
 #define CXLMDEV_RESET_NEEDED_CXL 4
 
+struct cxl_memdev;
 struct cxl_mem {
 	struct pci_dev *pdev;
 	void __iomem *regs;
+	struct cxl_memdev *cxlmd;
 
 	spinlock_t mbox_lock; /* Protects device mailbox and firmware */
 
+	struct {
+		struct range range;
+	} pmem;
+
+	struct {
+		struct range range;
+	} ram;
+
+	char firmware_version[0x10];
+
 	/* Cap 0000h */
 	struct {
 		void __iomem *regs;
@@ -130,4 +143,24 @@ static inline void cxl_mbox_payload_drain(struct cxl_mem *cxlm,
 {
 	memcpy_fromio(output, cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, length);
 }
+
+#define CXL_MBOX_IDENTIFY 0x4000
+
+struct cxl_mbox_identify {
+	char fw_revision[0x10];
+	__le64 total_capacity;
+	__le64 volatile_capacity;
+	__le64 persistent_capacity;
+	__le64 partition_align;
+	__le16 info_event_log_size;
+	__le16 warning_event_log_size;
+	__le16 failure_event_log_size;
+	__le16 fatal_event_log_size;
+	__le32 lsa_size;
+	u8 poison_list_max_mer[3];
+	__le16 inject_poison_limit;
+	u8 poison_caps;
+	u8 qos_telemetry_caps;
+} __packed;
+
 #endif /* __CXL_H__ */
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 08913360d500..54743d196feb 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -2,11 +2,15 @@
 // Copyright(c) 2020 Intel Corporation. All rights reserved.
 #include <linux/sched/clock.h>
 #include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/cdev.h>
+#include <linux/idr.h>
 #include <linux/pci.h>
 #include <linux/io.h>
 #include "acpi.h"
 #include "pci.h"
 #include "cxl.h"
+#include "bus.h"
 
 struct mbox_cmd {
 	u16 cmd;
@@ -15,6 +19,53 @@ struct mbox_cmd {
 	u16 return_code;
 };
 
+/*
+ * An entire PCI topology full of devices should be enough for any
+ * config
+ */
+#define CXL_MEM_MAX_DEVS 65536
+
+struct cxl_memdev {
+	struct device dev;
+	struct cxl_mem *cxlm;
+	int id;
+};
+
+static int cxl_mem_major;
+static struct cdev cxl_mem_cdev;
+static DEFINE_IDR(cxl_mem_idr);
+static DEFINE_MUTEX(cxl_memdev_lock);
+
+static int cxl_mem_open(struct inode *inode, struct file *file)
+{
+	long minor = iminor(inode);
+	struct cxl_memdev *cxlmd;
+
+	rcu_read_lock();
+	cxlmd = idr_find(&cxl_mem_idr, minor);
+	rcu_read_unlock();
+
+	if (!cxlmd)
+		return -ENXIO;
+
+	file->private_data = cxlmd;
+
+	return 0;
+}
+
+static long cxl_mem_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+	return -ENOTTY;
+}
+
+static const struct file_operations cxl_mem_fops = {
+	.owner = THIS_MODULE,
+	.open = cxl_mem_open,
+	.unlocked_ioctl = cxl_mem_ioctl,
+	.compat_ioctl = compat_ptr_ioctl,
+	.llseek = noop_llseek,
+};
+
 static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
 {
 	u64 start, now;
@@ -53,7 +104,7 @@ static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
  * Returns 0 if the doorbell transaction was successful from a protocol level.
  * Caller should check the return code in @mbox_cmd to make sure it succeeded.
  */
-static int __maybe_unused cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, struct mbox_cmd *mbox_cmd)
+static int cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, struct mbox_cmd *mbox_cmd)
 {
 	u64 cmd, status;
 	int rc;
@@ -277,10 +328,185 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
 	return 0;
 }
 
+static struct cxl_memdev *to_cxl_memdev(struct device *dev)
+{
+	return container_of(dev, struct cxl_memdev, dev);
+}
+
+static void cxl_memdev_release(struct device *dev)
+{
+	struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
+
+	mutex_lock(&cxl_memdev_lock);
+	idr_remove(&cxl_mem_idr, cxlmd->id);
+	mutex_unlock(&cxl_memdev_lock);
+
+	kfree(cxlmd);
+}
+
+static char *cxl_memdev_devnode(struct device *dev, umode_t *mode, kuid_t *uid, kgid_t *gid)
+{
+	return kasprintf(GFP_KERNEL, "cxl/%s", dev_name(dev));
+}
+
+static ssize_t firmware_version_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
+	struct cxl_mem *cxlm = cxlmd->cxlm;
+
+	return sprintf(buf, "%.16s\n", cxlm->firmware_version);
+}
+static DEVICE_ATTR_RO(firmware_version);
+
+static ssize_t ram_size_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
+	struct cxl_mem *cxlm = cxlmd->cxlm;
+
+	return sprintf(buf, "%#llx\n", (unsigned long long) range_len(&cxlm->ram.range));
+}
+static struct device_attribute dev_attr_ram_size = __ATTR(size, 0444, ram_size_show, NULL);
+
+static ssize_t pmem_size_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
+	struct cxl_mem *cxlm = cxlmd->cxlm;
+
+	return sprintf(buf, "%#llx\n", (unsigned long long) range_len(&cxlm->pmem.range));
+}
+static struct device_attribute dev_attr_pmem_size = __ATTR(size, 0444, pmem_size_show, NULL);
+
+static struct attribute *cxl_memdev_attributes[] = {
+	&dev_attr_firmware_version.attr,
+	NULL,
+};
+
+static struct attribute *cxl_memdev_pmem_attributes[] = {
+	&dev_attr_pmem_size.attr,
+	NULL,
+};
+
+static struct attribute *cxl_memdev_ram_attributes[] = {
+	&dev_attr_ram_size.attr,
+	NULL,
+};
+
+static struct attribute_group cxl_memdev_attribute_group = {
+	.attrs = cxl_memdev_attributes,
+};
+
+static struct attribute_group cxl_memdev_ram_attribute_group = {
+	.name = "ram",
+	.attrs = cxl_memdev_ram_attributes,
+};
+
+static struct attribute_group cxl_memdev_pmem_attribute_group = {
+	.name = "pmem",
+	.attrs = cxl_memdev_pmem_attributes,
+};
+
+static const struct attribute_group *cxl_memdev_attribute_groups[] = {
+	&cxl_memdev_attribute_group,
+	&cxl_memdev_ram_attribute_group,
+	&cxl_memdev_pmem_attribute_group,
+	NULL,
+};
+
+static const struct device_type cxl_memdev_type = {
+	.name = "cxl_memdev",
+	.release = cxl_memdev_release,
+	.devnode = cxl_memdev_devnode,
+	.groups = cxl_memdev_attribute_groups,
+};
+
+static struct cxl_memdev *cxl_mem_add_memdev(struct cxl_mem *cxlm)
+{
+	struct pci_dev *pdev = cxlm->pdev;
+	struct cxl_memdev *cxlmd;
+	struct device *dev;
+	int id, rc;
+
+	cxlmd = kzalloc(sizeof(*cxlmd), GFP_KERNEL);
+	if (!cxlmd)
+		return ERR_PTR(-ENOMEM);
+
+	cxlmd->cxlm = cxlm;
+	cxlm->cxlmd = cxlmd;
+
+	mutex_lock(&cxl_memdev_lock);
+	id = idr_alloc(&cxl_mem_idr, cxlmd, 0, CXL_MEM_MAX_DEVS, GFP_KERNEL);
+	mutex_unlock(&cxl_memdev_lock);
+	if (id < 0) {
+		rc = id;
+		goto err_idr;
+	}
+
+	cxlmd->id = id;
+
+	dev = &cxlmd->dev;
+
+	device_initialize(dev);
+	dev->parent = &pdev->dev;
+	dev->devt = MKDEV(cxl_mem_major, id);
+	dev->type = &cxl_memdev_type;
+	dev_set_name(dev, "mem%d", id);
+	rc = cxl_register(dev);
+	if (rc)
+		return ERR_PTR(rc);
+
+	return cxlmd;
+
+err_idr:
+	kfree(cxlmd);
+
+	return ERR_PTR(rc);
+}
+
+static int cxl_mem_identify(struct cxl_mem *cxlm)
+{
+	struct cxl_mbox_identify *id;
+	struct mbox_cmd mbox_cmd;
+	u8 pload[256];
+	int rc;
+
+	/* Retrieve initial device memory map */
+	rc = cxl_mem_mbox_get(cxlm);
+	if (rc)
+		return rc;
+
+	mbox_cmd = (struct mbox_cmd) {
+		.cmd = CXL_MBOX_IDENTIFY,
+		.payload = pload,
+		.payload_size = 0,
+	};
+	rc = cxl_mem_mbox_send_cmd(cxlm, &mbox_cmd);
+	if (rc)
+		goto out;
+
+	id = (struct cxl_mbox_identify *) mbox_cmd.payload;
+
+	/*
+	 * TODO: enumerate DPA map, as 'ram' and 'pmem' do not alias.
+	 * For now, only the capacity is exported in sysfs
+	 */
+	cxlm->ram.range.start = 0;
+	cxlm->ram.range.end = le64_to_cpu(id->volatile_capacity) - 1;
+
+	cxlm->pmem.range.start = 0;
+	cxlm->pmem.range.end = le64_to_cpu(id->persistent_capacity) - 1;
+
+	memcpy(cxlm->firmware_version, id->fw_revision, sizeof(id->fw_revision));
+out:
+	cxl_mem_mbox_put(cxlm);
+
+	return rc;
+}
+
 static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
 	struct device *dev = &pdev->dev;
+	struct cxl_memdev *cxlmd;
 	int rc, regloc, i;
 
 	rc = cxl_bus_prepared(pdev);
@@ -319,20 +545,31 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	if (rc)
 		return rc;
 
-	/* Check that hardware "looks" okay. */
-	rc = cxl_mem_mbox_get(cxlm);
+	rc = cxl_mem_identify(cxlm);
 	if (rc)
 		return rc;
-
-	cxl_mem_mbox_put(cxlm);
 	dev_dbg(&pdev->dev, "CXL Memory Device Interface Up\n");
+
 	pci_set_drvdata(pdev, cxlm);
 
+	cxlmd = cxl_mem_add_memdev(cxlm);
+	if (IS_ERR(cxlmd))
+		return PTR_ERR(cxlmd);
+
 	return 0;
 }
 
 static void cxl_mem_remove(struct pci_dev *pdev)
 {
+	struct cxl_mem *cxlm = pci_get_drvdata(pdev);
+	struct cxl_memdev *cxlmd = cxlm->cxlmd;
+
+	device_lock(&cxlmd->dev);
+	cxlm->cxlmd = NULL;
+	cxlmd->cxlm = NULL;
+	device_unlock(&cxlmd->dev);
+
+	device_unregister(&cxlmd->dev);
 }
 
 static const struct pci_device_id cxl_mem_pci_tbl[] = {
@@ -350,7 +587,45 @@ static struct pci_driver cxl_mem_driver = {
 	.remove			= cxl_mem_remove,
 };
 
+static __init int cxl_mem_init(void)
+{
+	int rc;
+	dev_t devt;
+
+	rc = alloc_chrdev_region(&devt, 0, CXL_MEM_MAX_DEVS, "cxl");
+	if (rc)
+		return rc;
+
+	cxl_mem_major = MAJOR(devt);
+
+	cdev_init(&cxl_mem_cdev, &cxl_mem_fops);
+	rc = cdev_add(&cxl_mem_cdev, MKDEV(cxl_mem_major, 0), CXL_MEM_MAX_DEVS);
+	if (rc)
+		goto err_cdev;
+
+	rc = pci_register_driver(&cxl_mem_driver);
+	if (rc)
+		goto err_driver;
+
+	return 0;
+
+err_driver:
+	cdev_del(&cxl_mem_cdev);
+err_cdev:
+	unregister_chrdev_region(MKDEV(cxl_mem_major, 0), CXL_MEM_MAX_DEVS);
+
+	return rc;
+}
+
+static __exit void cxl_mem_exit(void)
+{
+	pci_unregister_driver(&cxl_mem_driver);
+	unregister_chrdev_region(MKDEV(cxl_mem_major, 0), CXL_MEM_MAX_DEVS);
+	cdev_del(&cxl_mem_cdev);
+}
+
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Intel Corporation");
-module_pci_driver(cxl_mem_driver);
+module_init(cxl_mem_init);
+module_exit(cxl_mem_exit);
 MODULE_IMPORT_NS(CXL);
-- 
2.29.2


^ permalink raw reply	[flat|nested] 73+ messages in thread

* [RFC PATCH 9/9] MAINTAINERS: Add maintainers of the CXL driver
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
                   ` (7 preceding siblings ...)
  2020-11-11  5:43 ` [RFC PATCH 8/9] cxl/mem: Register CXL memX devices Ben Widawsky
@ 2020-11-11  5:43 ` Ben Widawsky
  2020-11-11 22:06 ` [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
  2020-11-11 22:43 ` Bjorn Helgaas
  10 siblings, 0 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11  5:43 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki,
	Ben Widawsky

Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
---
 MAINTAINERS | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b516bb34a8d5..25e294031376 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4428,6 +4428,15 @@ F:	fs/configfs/
 F:	include/linux/configfs.h
 F:	samples/configfs/
 
+COMPUTE EXPRESS LINK (CXL)
+M:	Vishal Verma <vishal.l.verma@intel.com>
+M:	Ira Weiny <ira.weiny@intel.com>
+M:	Ben Widawsky <ben.widawsky@intel.com>
+M:	Dan Williams <dan.j.williams@intel.com>
+L:	linux-cxl@vger.kernel.org
+S:	Maintained
+F:	drivers/cxl/
+
 CONSOLE SUBSYSTEM
 M:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 S:	Supported
-- 
2.29.2


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-11  5:43 ` [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox Ben Widawsky
@ 2020-11-11  6:17   ` Randy Dunlap
  2020-11-11  7:12   ` Christoph Hellwig
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 73+ messages in thread
From: Randy Dunlap @ 2020-11-11  6:17 UTC (permalink / raw)
  To: Ben Widawsky, linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki

Hi,

On 11/10/20 9:43 PM, Ben Widawsky wrote:
> ---
>  drivers/cxl/Kconfig  | 20 +++++++++++
>  drivers/cxl/Makefile |  2 ++
>  drivers/cxl/mem.c    | 82 ++++++++++++++++++++++++++++++++++++++++++++
>  drivers/cxl/pci.h    | 15 ++++++++
>  4 files changed, 119 insertions(+)

> diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> index dd724bd364df..15548f5c77ff 100644
> --- a/drivers/cxl/Kconfig
> +++ b/drivers/cxl/Kconfig
> @@ -27,4 +27,24 @@ config CXL_ACPI
>  	  resources described by the CEDT (CXL Early Discovery Table)
>  
>  	  Say 'y' to enable CXL (Compute Express Link) drivers.
> +
> +config CXL_MEM
> +        tristate "CXL.mem Device Support"
> +        depends on PCI && CXL_BUS_PROVIDER != n
> +        default m if CXL_BUS_PROVIDER

The "if CXL_BUS_PROVIDER" should be redundant due to the "depends on" clause.
However, having any default or 'm' or 'y' needs to be justified.

> +        help
> +          The CXL.mem protocol allows a device to act as a provider of
> +          "System RAM" and/or "Persistent Memory" that is fully coherent
> +          as if the memory was attached to the typical CPU memory
> +          controller.
> +
> +          Say 'y/m' to enable a driver named "cxl_mem.ko" that will attach

The builtin driver will not be named cxl-mem.ko.

> +          to CXL.mem devices for configuration, provisioning, and health
> +          monitoring, the so called "type-3 mailbox". Note, this driver
> +          is required for dynamic provisioning of CXL.mem attached
> +          memory, a pre-requisite for persistent memory support, but

	               prerequisite

> +          devices that provide volatile memory may be fully described by
> +          existing platform firmware memory enumeration.
> +
> +          If unsure say 'n'.
>  endif


-- 
~Randy


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-11  5:43 ` [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect Ben Widawsky
@ 2020-11-11  6:17   ` Randy Dunlap
  2020-11-11  7:10   ` Christoph Hellwig
                     ` (3 subsequent siblings)
  4 siblings, 0 replies; 73+ messages in thread
From: Randy Dunlap @ 2020-11-11  6:17 UTC (permalink / raw)
  To: Ben Widawsky, linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki

Hi,

On 11/10/20 9:43 PM, Ben Widawsky wrote:
> ---
>  drivers/Kconfig       |   1 +
>  drivers/Makefile      |   1 +
>  drivers/cxl/Kconfig   |  30 +++++++++++
>  drivers/cxl/Makefile  |   5 ++
>  drivers/cxl/acpi.c    | 119 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/cxl/acpi.h    |  15 ++++++
>  include/acpi/actbl1.h |  52 ++++++++++++++++++
>  7 files changed, 223 insertions(+)

> diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> new file mode 100644
> index 000000000000..dd724bd364df
> --- /dev/null
> +++ b/drivers/cxl/Kconfig
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +menuconfig CXL_BUS
> +	tristate "CXL (Compute Express Link) Devices Support"
> +	help
> +	  CXL is a bus that is electrically compatible with PCI-E, but layers
> +	  three protocols on that signalling (CXL.io, CXL.cache, and CXL.mem). The
> +	  CXL.cache protocol allows devices to hold cachelines locally, the
> +	  CXL.mem protocol allows devices to be fully coherent memory targets, the
> +	  CXL.io protocol is equivalent to PCI-E. Say 'y' to enable support for
> +	  the configuration and management of devices supporting these protocols.
> +
> +if CXL_BUS
> +
> +config CXL_BUS_PROVIDER
> +	tristate
> +
> +config CXL_ACPI
> +	tristate "CXL Platform Support"
> +	depends on ACPI
> +	default CXL_BUS

Please provide some justification for something other than the
default default of 'n'. We try hard not to add drivers/modules that
are not required for bootup.

> +	select CXL_BUS_PROVIDER
> +	help
> +	  CXL Platform Support is a prerequisite for any CXL device driver that
> +	  wants to claim ownership of the component register space. By default
> +	  platform firmware assumes Linux is unaware of CXL capabilities and
> +	  requires explicit opt-in. This platform component also mediates
> +	  resources described by the CEDT (CXL Early Discovery Table)

end sentence with '.'

> +
> +	  Say 'y' to enable CXL (Compute Express Link) drivers.

	  or 'm'

> +endif


-- 
~Randy


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-11  5:43 ` [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect Ben Widawsky
  2020-11-11  6:17   ` Randy Dunlap
@ 2020-11-11  7:10   ` Christoph Hellwig
  2020-11-11  7:30     ` Verma, Vishal L
  2020-11-11 23:03   ` Bjorn Helgaas
                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 73+ messages in thread
From: Christoph Hellwig @ 2020-11-11  7:10 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, Nov 10, 2020 at 09:43:48PM -0800, Ben Widawsky wrote:
> +menuconfig CXL_BUS
> +	tristate "CXL (Compute Express Link) Devices Support"
> +	help
> +	  CXL is a bus that is electrically compatible with PCI-E, but layers
> +	  three protocols on that signalling (CXL.io, CXL.cache, and CXL.mem). The
> +	  CXL.cache protocol allows devices to hold cachelines locally, the
> +	  CXL.mem protocol allows devices to be fully coherent memory targets, the
> +	  CXL.io protocol is equivalent to PCI-E. Say 'y' to enable support for
> +	  the configuration and management of devices supporting these protocols.
> +

Please fix the overly long lines.

> +static void acpi_cxl_desc_init(struct acpi_cxl_desc *acpi_desc, struct device *dev)


Another overly long line.

> +{
> +	dev_set_drvdata(dev, acpi_desc);
> +	acpi_desc->dev = dev;
> +}

But this helper seems pretty pointless to start with.

> +static int acpi_cxl_remove(struct acpi_device *adev)
> +{
> +	return 0;
> +}

The emptry remove callback is not needed.

> +/*
> + * If/when CXL support is defined by other platform firmware the kernel
> + * will need a mechanism to select between the platform specific version
> + * of this routine, until then, hard-code ACPI assumptions
> + */
> +int cxl_bus_prepared(struct pci_dev *pdev)
> +{
> +	struct acpi_device *adev;
> +	struct pci_dev *root_port;
> +	struct device *root;
> +
> +	root_port = pcie_find_root_port(pdev);
> +	if (!root_port)
> +		return -ENXIO;
> +
> +	root = root_port->dev.parent;
> +	if (!root)
> +		return -ENXIO;
> +
> +	adev = ACPI_COMPANION(root);
> +	if (!adev)
> +		return -ENXIO;
> +
> +	/* TODO: OSC enabling */
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(cxl_bus_prepared);

What is the point of this function?  I doesn't realy do anything,
not even a CXL specific check.  

>  
> +/*******************************************************************************
> + *
> + * CEDT - CXL Early Discovery Table (ACPI 6.4)
> + *        Version 1
> + *
> + ******************************************************************************/
> +

Pleae use the normal Linux comment style.


> +#define ACPI_CEDT_CHBS_VERSION_CXL11    (0)
> +#define ACPI_CEDT_CHBS_VERSION_CXL20    (1)
> +
> +/* Values for length field above */
> +
> +#define ACPI_CEDT_CHBS_LENGTH_CXL11     (0x2000)
> +#define ACPI_CEDT_CHBS_LENGTH_CXL20     (0x10000)

No need for the braces.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-11  5:43 ` [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox Ben Widawsky
  2020-11-11  6:17   ` Randy Dunlap
@ 2020-11-11  7:12   ` Christoph Hellwig
  2020-11-11 17:17     ` Dan Williams
  2020-11-13 18:17   ` Bjorn Helgaas
  2020-11-17 14:49   ` Jonathan Cameron
  3 siblings, 1 reply; 73+ messages in thread
From: Christoph Hellwig @ 2020-11-11  7:12 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, Nov 10, 2020 at 09:43:50PM -0800, Ben Widawsky wrote:
> +config CXL_MEM
> +        tristate "CXL.mem Device Support"
> +        depends on PCI && CXL_BUS_PROVIDER != n

depend on PCI && CXL_BUS_PROVIDER

> +        default m if CXL_BUS_PROVIDER

Please don't set weird defaults for new code.  Especially not default
to module crap like this.

> +// Copyright(c) 2020 Intel Corporation. All rights reserved.

Please don't use '//' for anything but the SPDX header.

> +
> +		pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, &vendor);
> +		pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, &id);
> +		if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> +			return pos;
> +
> +		pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);

Overly long lines again.

> +static void cxl_mem_remove(struct pci_dev *pdev)
> +{
> +}

No need for the empty remove callback.

> +MODULE_AUTHOR("Intel Corporation");

A module author is not a company.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-11  7:10   ` Christoph Hellwig
@ 2020-11-11  7:30     ` Verma, Vishal L
  2020-11-11  7:34       ` hch
  0 siblings, 1 reply; 73+ messages in thread
From: Verma, Vishal L @ 2020-11-11  7:30 UTC (permalink / raw)
  To: Widawsky, Ben, hch
  Cc: Kelley, Sean V, Wysocki, Rafael J, linux-cxl, linux-kernel,
	Williams, Dan J, Weiny, Ira, linux-pci, bhelgaas, linux-acpi

On Wed, 2020-11-11 at 07:10 +0000, Christoph Hellwig wrote:
> On Tue, Nov 10, 2020 at 09:43:48PM -0800, Ben Widawsky wrote:
> > +menuconfig CXL_BUS
> > +	tristate "CXL (Compute Express Link) Devices Support"
> > +	help
> > +	  CXL is a bus that is electrically compatible with PCI-E, but layers
> > +	  three protocols on that signalling (CXL.io, CXL.cache, and CXL.mem). The
> > +	  CXL.cache protocol allows devices to hold cachelines locally, the
> > +	  CXL.mem protocol allows devices to be fully coherent memory targets, the
> > +	  CXL.io protocol is equivalent to PCI-E. Say 'y' to enable support for
> > +	  the configuration and management of devices supporting these protocols.
> > +
> 
> Please fix the overly long lines.
> 
> > +static void acpi_cxl_desc_init(struct acpi_cxl_desc *acpi_desc, struct device *dev)
> 
> Another overly long line.

Hi Christpph,

I thought 100 col. lines were acceptable now.

> 
> > +{
> > +	dev_set_drvdata(dev, acpi_desc);
> > +	acpi_desc->dev = dev;
> > +}
> 
> But this helper seems pretty pointless to start with.
> 
> > +static int acpi_cxl_remove(struct acpi_device *adev)
> > +{
> > +	return 0;
> > +}
> 
> The emptry remove callback is not needed.

Agreed on both of the above comments - these are just boilerplate for
now, I expect they will get filled in in the next revision as more
functionality gets fleshed out. If they are still empty/no-op by then I
will remove them.

> 
> > +/*
> > + * If/when CXL support is defined by other platform firmware the kernel
> > + * will need a mechanism to select between the platform specific version
> > + * of this routine, until then, hard-code ACPI assumptions
> > + */
> > +int cxl_bus_prepared(struct pci_dev *pdev)
> > +{
> > +	struct acpi_device *adev;
> > +	struct pci_dev *root_port;
> > +	struct device *root;
> > +
> > +	root_port = pcie_find_root_port(pdev);
> > +	if (!root_port)
> > +		return -ENXIO;
> > +
> > +	root = root_port->dev.parent;
> > +	if (!root)
> > +		return -ENXIO;
> > +
> > +	adev = ACPI_COMPANION(root);
> > +	if (!adev)
> > +		return -ENXIO;
> > +
> > +	/* TODO: OSC enabling */
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(cxl_bus_prepared);
> 
> What is the point of this function?  I doesn't realy do anything,
> not even a CXL specific check.  

This gets a bit more fleshed out in patch 2. I kept that separate so
that it is easier to review the bulk of the _OSC work in that patch
without this driver boilerplate getting in the way.

> 
> >  
> > +/*******************************************************************************
> > + *
> > + * CEDT - CXL Early Discovery Table (ACPI 6.4)
> > + *        Version 1
> > + *
> > + ******************************************************************************/
> > +
> 
> Pleae use the normal Linux comment style.
> 
> 
> > +#define ACPI_CEDT_CHBS_VERSION_CXL11    (0)
> > +#define ACPI_CEDT_CHBS_VERSION_CXL20    (1)
> > +
> > +/* Values for length field above */
> > +
> > +#define ACPI_CEDT_CHBS_LENGTH_CXL11     (0x2000)
> > +#define ACPI_CEDT_CHBS_LENGTH_CXL20     (0x10000)
> 
> No need for the braces.

For both of these - see the note in the commit message. I just followed
the ACPI header's style, and these hunks are only in this series to make
it usable. I expect the 'actual' struct definitions, naming etc will
come through ACPICA.


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-11  7:30     ` Verma, Vishal L
@ 2020-11-11  7:34       ` hch
  2020-11-11  7:36         ` Verma, Vishal L
  0 siblings, 1 reply; 73+ messages in thread
From: hch @ 2020-11-11  7:34 UTC (permalink / raw)
  To: Verma, Vishal L
  Cc: Widawsky, Ben, hch, Kelley, Sean V, Wysocki, Rafael J, linux-cxl,
	linux-kernel, Williams, Dan J, Weiny, Ira, linux-pci, bhelgaas,
	linux-acpi

On Wed, Nov 11, 2020 at 07:30:34AM +0000, Verma, Vishal L wrote:
> Hi Christpph,
> 
> I thought 100 col. lines were acceptable now.

Quote from the coding style document:

"The preferred limit on the length of a single line is 80 columns.

Statements longer than 80 columns should be broken into sensible chunks,
unless exceeding 80 columns significantly increases readability and does
not hide information."

So yes, they are acceptable as an expception.  Not for crap like this.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-11  7:34       ` hch
@ 2020-11-11  7:36         ` Verma, Vishal L
  0 siblings, 0 replies; 73+ messages in thread
From: Verma, Vishal L @ 2020-11-11  7:36 UTC (permalink / raw)
  To: hch
  Cc: Kelley, Sean V, linux-cxl, linux-kernel, Williams, Dan J,
	Widawsky, Ben, Wysocki, Rafael J, linux-pci, Weiny, Ira,
	bhelgaas, linux-acpi

On Wed, 2020-11-11 at 07:34 +0000, hch@infradead.org wrote:
> On Wed, Nov 11, 2020 at 07:30:34AM +0000, Verma, Vishal L wrote:
> > Hi Christpph,
> > 
> > I thought 100 col. lines were acceptable now.
> 
> Quote from the coding style document:
> 
> "The preferred limit on the length of a single line is 80 columns.
> 
> Statements longer than 80 columns should be broken into sensible chunks,
> unless exceeding 80 columns significantly increases readability and does
> not hide information."
> 
> So yes, they are acceptable as an expception.  Not for crap like this.

Ah fair enough, I'll reflow all of these for the next revision.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-11  7:12   ` Christoph Hellwig
@ 2020-11-11 17:17     ` Dan Williams
  2020-11-11 18:27       ` Dan Williams
                         ` (2 more replies)
  0 siblings, 3 replies; 73+ messages in thread
From: Dan Williams @ 2020-11-11 17:17 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Tue, Nov 10, 2020 at 11:12 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Nov 10, 2020 at 09:43:50PM -0800, Ben Widawsky wrote:
> > +config CXL_MEM
> > +        tristate "CXL.mem Device Support"
> > +        depends on PCI && CXL_BUS_PROVIDER != n
>
> depend on PCI && CXL_BUS_PROVIDER
>
> > +        default m if CXL_BUS_PROVIDER
>
> Please don't set weird defaults for new code.  Especially not default
> to module crap like this.

This goes back to what people like Dave C. asked for LIBNVDIMM / DAX,
a way to blanket turn on a subsystem without needing to go hunt down
individual configs. All of CXL is "default n", but if someone turns on
a piece of it they get all of it by default. The user can then opt-out
on pieces after that first opt-in. If there's a better way to turn on
suggested configs I'm open to switch to that style. As for the
"default m" I was worried that it would be "default y" without the
specificity, but I did not test that... will check. There have been
times when I wished that distros defaulted bleeding edge new enabling
to 'm' and putting that default in the Kconfig maybe saves me from
needing to file individual config changes to distros after the fact.

>
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
>
> Please don't use '//' for anything but the SPDX header.

Ok, I find // following by /* */ a bit ugly, but I don't care enough to fight.

>
> > +
> > +             pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, &vendor);
> > +             pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, &id);
> > +             if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> > +                     return pos;
> > +
> > +             pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
>
> Overly long lines again.

I thought 100 is the new 80 these days?

> > +static void cxl_mem_remove(struct pci_dev *pdev)
> > +{
> > +}
>
> No need for the empty remove callback.

True, will fix.

>
> > +MODULE_AUTHOR("Intel Corporation");
>
> A module author is not a company.

At least I don't have a copyright assignment clause, I don't agree
with the vanity of listing multiple people here especially when
MAINTAINERS has the contact info, and I don't want to maintain a list
as people do drive-by contributions and we need to figure out at what
level of contribution mandates a new MODULE_AUTHOR line. Now, that
said I would be ok to duplicate the MAINTAINERS as MODULE_AUTHOR
lines, but I otherwise expect MAINTAINERS is the central source for
module contact info.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-11 17:17     ` Dan Williams
@ 2020-11-11 18:27       ` Dan Williams
  2020-11-11 21:41       ` Randy Dunlap
  2020-11-16 16:56       ` Christoph Hellwig
  2 siblings, 0 replies; 73+ messages in thread
From: Dan Williams @ 2020-11-11 18:27 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Wed, Nov 11, 2020 at 9:17 AM Dan Williams <dan.j.williams@intel.com> wrote:
[..]
> > > +
> > > +             pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, &vendor);
> > > +             pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, &id);
> > > +             if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> > > +                     return pos;
> > > +
> > > +             pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
> >
> > Overly long lines again.
>
> I thought 100 is the new 80 these days?

Saw your clarification to Vishal, I had missed that. Will trim.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-11 17:17     ` Dan Williams
  2020-11-11 18:27       ` Dan Williams
@ 2020-11-11 21:41       ` Randy Dunlap
  2020-11-11 22:40         ` Dan Williams
  2020-11-16 16:56       ` Christoph Hellwig
  2 siblings, 1 reply; 73+ messages in thread
From: Randy Dunlap @ 2020-11-11 21:41 UTC (permalink / raw)
  To: Dan Williams, Christoph Hellwig
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On 11/11/20 9:17 AM, Dan Williams wrote:
> On Tue, Nov 10, 2020 at 11:12 PM Christoph Hellwig <hch@infradead.org> wrote:
>>
>> On Tue, Nov 10, 2020 at 09:43:50PM -0800, Ben Widawsky wrote:
>>> +config CXL_MEM
>>> +        tristate "CXL.mem Device Support"
>>> +        depends on PCI && CXL_BUS_PROVIDER != n
>>
>> depend on PCI && CXL_BUS_PROVIDER
>>
>>> +        default m if CXL_BUS_PROVIDER
>>
>> Please don't set weird defaults for new code.  Especially not default
>> to module crap like this.
> 
> This goes back to what people like Dave C. asked for LIBNVDIMM / DAX,
> a way to blanket turn on a subsystem without needing to go hunt down
> individual configs. All of CXL is "default n", but if someone turns on
> a piece of it they get all of it by default. The user can then opt-out
> on pieces after that first opt-in. If there's a better way to turn on
> suggested configs I'm open to switch to that style. As for the
> "default m" I was worried that it would be "default y" without the
> specificity, but I did not test that... will check. There have been
> times when I wished that distros defaulted bleeding edge new enabling
> to 'm' and putting that default in the Kconfig maybe saves me from
> needing to file individual config changes to distros after the fact.

What we as developers put into mainline kernel Kconfig files has nothing
to do with what distros use in their distro config files.
Or at least it shouldn't.  Maybe your experience has been different.

>>
>>> +// Copyright(c) 2020 Intel Corporation. All rights reserved.
>>
>> Please don't use '//' for anything but the SPDX header.
> 
> Ok, I find // following by /* */ a bit ugly, but I don't care enough to fight.
> 

Hm, it's not in coding-style AFAICT but Linus has OK-ed C99 style comments:
http://lkml.iu.edu/hypermail/linux/kernel/1607.1/00627.html


>>> +MODULE_AUTHOR("Intel Corporation");
>>
>> A module author is not a company.
> 
> At least I don't have a copyright assignment clause, I don't agree
> with the vanity of listing multiple people here especially when
> MAINTAINERS has the contact info, and I don't want to maintain a list
> as people do drive-by contributions and we need to figure out at what
> level of contribution mandates a new MODULE_AUTHOR line. Now, that
> said I would be ok to duplicate the MAINTAINERS as MODULE_AUTHOR
> lines, but I otherwise expect MAINTAINERS is the central source for
> module contact info.

Sure, MAINTAINERS is fine, but the MODULE_AUTHOR() above provides
no useful information.
Even saying (made up) linux-devel@linux.intel.com would be slightly better,
but some kind of contact info would be great. Otherwise just delete that line.


-- 
~Randy


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 0/9] CXL 2.0 Support
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
                   ` (8 preceding siblings ...)
  2020-11-11  5:43 ` [RFC PATCH 9/9] MAINTAINERS: Add maintainers of the CXL driver Ben Widawsky
@ 2020-11-11 22:06 ` Ben Widawsky
  2020-11-11 22:43 ` Bjorn Helgaas
  10 siblings, 0 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-11 22:06 UTC (permalink / raw)
  To: linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki

Adding a cross reference to the QEMU work since I sent those patches after this:

https://gitlab.com/bwidawsk/qemu/-/tree/cxl-2.0
https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg02886.html

[snip]


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-11 21:41       ` Randy Dunlap
@ 2020-11-11 22:40         ` Dan Williams
  0 siblings, 0 replies; 73+ messages in thread
From: Dan Williams @ 2020-11-11 22:40 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Christoph Hellwig, Ben Widawsky, linux-cxl,
	Linux Kernel Mailing List, Linux PCI, Linux ACPI, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki

On Wed, Nov 11, 2020 at 1:42 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 11/11/20 9:17 AM, Dan Williams wrote:
> > On Tue, Nov 10, 2020 at 11:12 PM Christoph Hellwig <hch@infradead.org> wrote:
> >>
> >> On Tue, Nov 10, 2020 at 09:43:50PM -0800, Ben Widawsky wrote:
> >>> +config CXL_MEM
> >>> +        tristate "CXL.mem Device Support"
> >>> +        depends on PCI && CXL_BUS_PROVIDER != n
> >>
> >> depend on PCI && CXL_BUS_PROVIDER
> >>
> >>> +        default m if CXL_BUS_PROVIDER
> >>
> >> Please don't set weird defaults for new code.  Especially not default
> >> to module crap like this.
> >
> > This goes back to what people like Dave C. asked for LIBNVDIMM / DAX,
> > a way to blanket turn on a subsystem without needing to go hunt down
> > individual configs. All of CXL is "default n", but if someone turns on
> > a piece of it they get all of it by default. The user can then opt-out
> > on pieces after that first opt-in. If there's a better way to turn on
> > suggested configs I'm open to switch to that style. As for the
> > "default m" I was worried that it would be "default y" without the
> > specificity, but I did not test that... will check. There have been
> > times when I wished that distros defaulted bleeding edge new enabling
> > to 'm' and putting that default in the Kconfig maybe saves me from
> > needing to file individual config changes to distros after the fact.
>
> What we as developers put into mainline kernel Kconfig files has nothing
> to do with what distros use in their distro config files.
> Or at least it shouldn't.  Maybe your experience has been different.

I agree with that sentiment, but walk it back through the requirement
I mentioned above... *if* we want a top-level CXL option (default n)
that goes and enables many CXL sub-options the default for those
sub-options is something that needs to be listed in the Kconfig. 'm'
is more flexible than 'y', so if a user wants CXL at all, and doesn't
care about how, I'd prefer it's 'm' rather than 'y'.

I have had to go submit distro config fixes when Kconfig defaulted to
'y' when 'm' was available, and the reasoning for why it was 'y' was
"oh, that was the Kconfig default when I flipped this other option".


> >>> +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> >>
> >> Please don't use '//' for anything but the SPDX header.
> >
> > Ok, I find // following by /* */ a bit ugly, but I don't care enough to fight.
> >
>
> Hm, it's not in coding-style AFAICT but Linus has OK-ed C99 style comments:
> http://lkml.iu.edu/hypermail/linux/kernel/1607.1/00627.html
>
>
> >>> +MODULE_AUTHOR("Intel Corporation");
> >>
> >> A module author is not a company.
> >
> > At least I don't have a copyright assignment clause, I don't agree
> > with the vanity of listing multiple people here especially when
> > MAINTAINERS has the contact info, and I don't want to maintain a list
> > as people do drive-by contributions and we need to figure out at what
> > level of contribution mandates a new MODULE_AUTHOR line. Now, that
> > said I would be ok to duplicate the MAINTAINERS as MODULE_AUTHOR
> > lines, but I otherwise expect MAINTAINERS is the central source for
> > module contact info.
>
> Sure, MAINTAINERS is fine, but the MODULE_AUTHOR() above provides
> no useful information.
> Even saying (made up) linux-devel@linux.intel.com would be slightly better,
> but some kind of contact info would be great. Otherwise just delete that line.

True, if the goal is to allow random end users to email support
questions about this module I'd rather not put my email there.
Instead, if it's someone that has kernel development questions then
they should be able to use MAINTAINERS for that contact.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 0/9] CXL 2.0 Support
  2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
                   ` (9 preceding siblings ...)
  2020-11-11 22:06 ` [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
@ 2020-11-11 22:43 ` Bjorn Helgaas
  10 siblings, 0 replies; 73+ messages in thread
From: Bjorn Helgaas @ 2020-11-11 22:43 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, Nov 10, 2020 at 09:43:47PM -0800, Ben Widawsky wrote:
> ...
> Ben Widawsky (5):
>   cxl/mem: Map memory device registers
>   cxl/mem: Find device capabilities
>   cxl/mem: Initialize the mailbox interface
>   cxl/mem: Implement polled mode mailbox
>   MAINTAINERS: Add maintainers of the CXL driver
> 
> Dan Williams (2):
>   cxl/mem: Add a driver for the type-3 mailbox

To include important words first and use "Type 3" as in spec:

  cxl/mem: Add Type 3 mailbox driver

>   cxl/mem: Register CXL memX devices
> 
> Vishal Verma (2):
>   cxl/acpi: Add an acpi_cxl module for the CXL interconnect
>   cxl/acpi: add OSC support

For consistency:

  cxl/acpi: Add _OSC support

It's conventional in drivers/acpi and drivers/pci to capitalize the
"ACPI" and "PCI" initialisms except in actual C code.   Seems like
you're mostly doing the same with "CXL", except in the subject lines
above.  Since you're making a new directory, I guess you get to
choose.

I use "PCIe" (not "PCIE" or "PCI-E"; you have a mix) because that
seems to be the official abbreviation.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-11  5:43 ` [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect Ben Widawsky
  2020-11-11  6:17   ` Randy Dunlap
  2020-11-11  7:10   ` Christoph Hellwig
@ 2020-11-11 23:03   ` Bjorn Helgaas
  2020-11-16 17:59   ` Jonathan Cameron
  2020-11-17 14:32   ` Rafael J. Wysocki
  4 siblings, 0 replies; 73+ messages in thread
From: Bjorn Helgaas @ 2020-11-11 23:03 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, Nov 10, 2020 at 09:43:48PM -0800, Ben Widawsky wrote:

> +static int acpi_cxl_add(struct acpi_device *adev)
> +{
> +	struct acpi_cxl_desc *acpi_desc;
> +	struct device *dev = &adev->dev;
> +	struct acpi_table_header *tbl;
> +	acpi_status status = AE_OK;

Pointless init.

> +	acpi_size sz;
> +	int rc = 0;

Pointless init.

> +	status = acpi_get_table(ACPI_SIG_CEDT, 0, &tbl);
> +	if (ACPI_FAILURE(status)) {
> +		dev_err(dev, "failed to find CEDT at startup\n");
> +		return 0;
> +	}
> +
> +	rc = devm_add_action_or_reset(dev, acpi_cedt_put_table, tbl);
> +	if (rc)
> +		return rc;

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-11  5:43 ` [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox Ben Widawsky
  2020-11-11  6:17   ` Randy Dunlap
  2020-11-11  7:12   ` Christoph Hellwig
@ 2020-11-13 18:17   ` Bjorn Helgaas
  2020-11-14  1:08     ` Ben Widawsky
  2020-11-17 14:49   ` Jonathan Cameron
  3 siblings, 1 reply; 73+ messages in thread
From: Bjorn Helgaas @ 2020-11-13 18:17 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, Nov 10, 2020 at 09:43:50PM -0800, Ben Widawsky wrote:
> From: Dan Williams <dan.j.williams@intel.com>
> 
> The CXL.mem protocol allows a device to act as a provider of "System
> RAM" and/or "Persistent Memory" that is fully coherent as if the memory
> was attached to the typical CPU memory controller.
> 
> The memory range exported by the device may optionally be described by
> the platform firmware memory map, or by infrastructure like LIBNVDIMM to
> provision persistent memory capacity from one, or more, CXL.mem devices.
> 
> A pre-requisite for Linux-managed memory-capacity provisioning is this
> cxl_mem driver that can speak the "type-3 mailbox" protocol.

"Type 3" to indicate that this is a proper adjective that can be
looked up in the spec and to match the usage there.

The r1.1 spec I have doesn't mention "mailbox".  Is that also
something defined in the 2.0 spec?

A URL or similar citation for the spec would be nice somewhere.

> For now just land the driver boiler-plate and fill it in with
> functionality in subsequent commits.
> 
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> ---
>  drivers/cxl/Kconfig  | 20 +++++++++++
>  drivers/cxl/Makefile |  2 ++
>  drivers/cxl/mem.c    | 82 ++++++++++++++++++++++++++++++++++++++++++++
>  drivers/cxl/pci.h    | 15 ++++++++
>  4 files changed, 119 insertions(+)
>  create mode 100644 drivers/cxl/mem.c
>  create mode 100644 drivers/cxl/pci.h
> 
> diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> index dd724bd364df..15548f5c77ff 100644
> --- a/drivers/cxl/Kconfig
> +++ b/drivers/cxl/Kconfig
> @@ -27,4 +27,24 @@ config CXL_ACPI
>  	  resources described by the CEDT (CXL Early Discovery Table)
>  
>  	  Say 'y' to enable CXL (Compute Express Link) drivers.
> +
> +config CXL_MEM
> +        tristate "CXL.mem Device Support"
> +        depends on PCI && CXL_BUS_PROVIDER != n
> +        default m if CXL_BUS_PROVIDER
> +        help
> +          The CXL.mem protocol allows a device to act as a provider of
> +          "System RAM" and/or "Persistent Memory" that is fully coherent
> +          as if the memory was attached to the typical CPU memory
> +          controller.
> +
> +          Say 'y/m' to enable a driver named "cxl_mem.ko" that will attach
> +          to CXL.mem devices for configuration, provisioning, and health
> +          monitoring, the so called "type-3 mailbox". Note, this driver

"Type 3"

> +          is required for dynamic provisioning of CXL.mem attached
> +          memory, a pre-requisite for persistent memory support, but
> +          devices that provide volatile memory may be fully described by
> +          existing platform firmware memory enumeration.
> +
> +          If unsure say 'n'.
>  endif
> diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> index d38cd34a2582..97fdffb00f2d 100644
> --- a/drivers/cxl/Makefile
> +++ b/drivers/cxl/Makefile
> @@ -1,5 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
> +obj-$(CONFIG_CXL_MEM) += cxl_mem.o
>  
>  ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
>  cxl_acpi-y := acpi.o
> +cxl_mem-y := mem.o
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> new file mode 100644
> index 000000000000..aa7d881fa47b
> --- /dev/null
> +++ b/drivers/cxl/mem.c
> @@ -0,0 +1,82 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/io.h>
> +#include "acpi.h"
> +#include "pci.h"
> +
> +struct cxl_mem {
> +	void __iomem *regs;
> +};

Unused, maybe move it to the patch that adds the use?

> +static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> +{
> +	int pos;
> +
> +	pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DVSEC);
> +	if (!pos)
> +		return 0;
> +
> +	while (pos) {
> +		u16 vendor, id;
> +
> +		pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, &vendor);
> +		pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, &id);
> +		if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> +			return pos;
> +
> +		pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
> +	}
> +
> +	return 0;
> +}

I assume we'll refactor and move this into the PCI core after we
resolve the several places this is needed.  When we do that, the
vendor would be passed in, so maybe we should do that here to make it
simpler to move this to the PCI core.

> +static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct cxl_mem *cxlm;
> +	int rc, regloc;
> +
> +	rc = cxl_bus_prepared(pdev);
> +	if (rc != 0) {
> +		dev_err(dev, "failed to acquire interface\n");

Interesting naming: apparently when cxl_bus_prepared() returns a
non-zero ("true") value, it is actually *not* prepared?

> +		return rc;
> +	}
> +
> +	regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
> +	if (!regloc) {
> +		dev_err(dev, "register location dvsec not found\n");
> +		return -ENXIO;
> +	}
> +
> +	cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> +	if (!cxlm)
> +		return -ENOMEM;

Unused.  And [4/9] removes it before it's *ever* used :)

> +	return 0;
> +}
> +
> +static void cxl_mem_remove(struct pci_dev *pdev)
> +{
> +}
> +
> +static const struct pci_device_id cxl_mem_pci_tbl[] = {
> +	/* PCI class code for CXL.mem Type-3 Devices */
> +	{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> +	  PCI_CLASS_MEMORY_CXL, 0xffffff, 0 },
> +	{ /* terminate list */ },
> +};
> +MODULE_DEVICE_TABLE(pci, cxl_mem_pci_tbl);
> +
> +static struct pci_driver cxl_mem_driver = {
> +	.name			= KBUILD_MODNAME,
> +	.id_table		= cxl_mem_pci_tbl,
> +	.probe			= cxl_mem_probe,
> +	.remove			= cxl_mem_remove,
> +};
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Intel Corporation");
> +module_pci_driver(cxl_mem_driver);
> +MODULE_IMPORT_NS(CXL);
> diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> new file mode 100644
> index 000000000000..beb03921e6da
> --- /dev/null

> +++ b/drivers/cxl/pci.h
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright(c) 2020 Intel Corporation. All rights reserved.

/* SPDX-... */
/* Copyright ...*/

The SPDX rules are a bit arcane and annoyingly hard to grep for, but
I found them in Documentation/process/license-rules.rst

> +#ifndef __CXL_PCI_H__
> +#define __CXL_PCI_H__
> +
> +#define PCI_CLASS_MEMORY_CXL	0x050210
> +
> +#define PCI_EXT_CAP_ID_DVSEC	0x23
> +#define PCI_DVSEC_VENDOR_CXL	0x1E98
> +#define PCI_DVSEC_VENDOR_OFFSET	0x4
> +#define PCI_DVSEC_ID_OFFSET	0x8
> +#define PCI_DVSEC_ID_CXL	0x0
> +#define PCI_DVSEC_ID_CXL_REGLOC	0x8

I assume these will go in include/linux/pci_ids.h (PCI_CLASS_...) and
include/uapi/linux/pci_regs.h (the rest) eventually, after we get the
merge issues sorted out.  But if they're only used in cxl/mem.c, I'd
put them there for now.

> +#endif /* __CXL_PCI_H__ */
> -- 
> 2.29.2
> 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers
  2020-11-11  5:43 ` [RFC PATCH 4/9] cxl/mem: Map memory device registers Ben Widawsky
@ 2020-11-13 18:17   ` Bjorn Helgaas
  2020-11-14  1:12     ` Ben Widawsky
  2020-11-17 15:00   ` Jonathan Cameron
  1 sibling, 1 reply; 73+ messages in thread
From: Bjorn Helgaas @ 2020-11-13 18:17 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, Nov 10, 2020 at 09:43:51PM -0800, Ben Widawsky wrote:
> All the necessary bits are initialized in order to find and map the
> register space for CXL Memory Devices. This is accomplished by using the
> Register Locator DVSEC (CXL 2.0 - 8.1.9.1) to determine which PCI BAR to
> use, and how much of an offset from that BAR should be added.

"Initialize the necessary bits ..." to use the usual imperative
sentence structure, as you did in the subject.

> If the memory device registers are found and mapped a new internal data
> structure tracking device state is allocated.

"Allocate device state if we find device registers" or similar.

> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> ---
>  drivers/cxl/mem.c | 68 +++++++++++++++++++++++++++++++++++++++++++----
>  drivers/cxl/pci.h |  6 +++++
>  2 files changed, 69 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index aa7d881fa47b..8d9b9ab6c5ea 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -7,9 +7,49 @@
>  #include "pci.h"
>  
>  struct cxl_mem {
> +	struct pci_dev *pdev;
>  	void __iomem *regs;
>  };
>  
> +static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo, u32 reg_hi)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct cxl_mem *cxlm;
> +	void __iomem *regs;
> +	u64 offset;
> +	u8 bar;
> +	int rc;
> +
> +	offset = ((u64)reg_hi << 32) | (reg_lo & 0xffff0000);
> +	bar = reg_lo & 0x7;
> +
> +	/* Basic sanity check that BAR is big enough */
> +	if (pci_resource_len(pdev, bar) < offset) {
> +		dev_err(dev, "bar%d: %pr: too small (offset: %#llx)\n",
> +				bar, &pdev->resource[bar], (unsigned long long) offset);

s/bar/BAR/

> +		return ERR_PTR(-ENXIO);
> +	}
> +
> +	rc = pcim_iomap_regions(pdev, 1 << bar, pci_name(pdev));
> +	if (rc != 0) {
> +		dev_err(dev, "failed to map registers\n");
> +		return ERR_PTR(-ENXIO);
> +	}
> +
> +	cxlm = devm_kzalloc(&pdev->dev, sizeof(*cxlm), GFP_KERNEL);
> +	if (!cxlm) {
> +		dev_err(dev, "No memory available\n");
> +		return ERR_PTR(-ENOMEM);
> +	}
> +
> +	regs = pcim_iomap_table(pdev)[bar];
> +	cxlm->pdev = pdev;
> +	cxlm->regs = regs + offset;
> +
> +	dev_dbg(dev, "Mapped CXL Memory Device resource\n");
> +	return cxlm;
> +}
> +
>  static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
>  {
>  	int pos;
> @@ -34,9 +74,9 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
>  
>  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  {
> +	struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
>  	struct device *dev = &pdev->dev;
> -	struct cxl_mem *cxlm;

The order was better before ("dev", then "clxm").  Oh, I suppose this
is a "reverse Christmas tree" thing.

> -	int rc, regloc;
> +	int rc, regloc, i;
>  
>  	rc = cxl_bus_prepared(pdev);
>  	if (rc != 0) {
> @@ -44,15 +84,33 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  		return rc;
>  	}
>  
> +	rc = pcim_enable_device(pdev);
> +	if (rc)
> +		return rc;
> +
>  	regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
>  	if (!regloc) {
>  		dev_err(dev, "register location dvsec not found\n");
>  		return -ENXIO;
>  	}
> +	regloc += 0xc; /* Skip DVSEC + reserved fields */
> +
> +	for (i = regloc; i < regloc + 0x24; i += 8) {
> +		u32 reg_lo, reg_hi;
> +
> +		pci_read_config_dword(pdev, i, &reg_lo);
> +		pci_read_config_dword(pdev, i + 4, &reg_hi);
> +
> +		if (CXL_REGLOG_IS_MEMDEV(reg_lo)) {
> +			cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
> +			break;
> +		}
> +	}
> +
> +	if (IS_ERR(cxlm))
> +		return -ENXIO;

I think this would be easier to read if cxl_mem_create() returned NULL
on failure (it prints error messages and we throw away
-ENXIO/-ENOMEM distinction here anyway) so you could do:

  struct cxl_mem *cxlm = NULL;

  for (...) {
    if (...) {
      cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
      break;
    }
  }

  if (!cxlm)
    return -ENXIO;  /* -ENODEV might be more natural? */

> -	cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> -	if (!cxlm)
> -		return -ENOMEM;
> +	pci_set_drvdata(pdev, cxlm);
>  
>  	return 0;
>  }
> diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> index beb03921e6da..be87f62e9132 100644
> --- a/drivers/cxl/pci.h
> +++ b/drivers/cxl/pci.h
> @@ -12,4 +12,10 @@
>  #define PCI_DVSEC_ID_CXL	0x0
>  #define PCI_DVSEC_ID_CXL_REGLOC	0x8
>  
> +#define CXL_REGLOG_RBI_EMPTY 0
> +#define CXL_REGLOG_RBI_COMPONENT 1
> +#define CXL_REGLOG_RBI_VIRT 2
> +#define CXL_REGLOG_RBI_MEMDEV 3

Maybe line these values up.

> +#define CXL_REGLOG_IS_MEMDEV(x) ((((x) >> 8) & 0xff) == CXL_REGLOG_RBI_MEMDEV)

If these are only needed in cxl/mem.c, they could go there.  Do you
expect code outside of drivers/cxl to need these?

>  #endif /* __CXL_PCI_H__ */
> -- 
> 2.29.2
> 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities
  2020-11-11  5:43 ` [RFC PATCH 5/9] cxl/mem: Find device capabilities Ben Widawsky
@ 2020-11-13 18:26   ` Bjorn Helgaas
  2020-11-14  1:36     ` Ben Widawsky
  2020-11-17 15:15   ` Jonathan Cameron
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 73+ messages in thread
From: Bjorn Helgaas @ 2020-11-13 18:26 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, Nov 10, 2020 at 09:43:52PM -0800, Ben Widawsky wrote:
> CXL devices contain an array of capabilities that describe the
> interactions software can interact with the device, or firmware running
> on the device. A CXL compliant device must implement the device status
> and the mailbox capability. A CXL compliant memory device must implement
> the memory device capability.
> 
> Each of the capabilities can [will] provide an offset within the MMIO
> region for interacting with the CXL device.
> 
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> ---
>  drivers/cxl/cxl.h | 89 +++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/cxl/mem.c | 58 +++++++++++++++++++++++++++---
>  2 files changed, 143 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/cxl/cxl.h
> 
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> new file mode 100644
> index 000000000000..02858ae63d6d
> --- /dev/null
> +++ b/drivers/cxl/cxl.h
> @@ -0,0 +1,89 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright(c) 2020 Intel Corporation. All rights reserved.

Fix comment usage (I think SPDX in .h needs "/* */")

> +#ifndef __CXL_H__
> +#define __CXL_H__
> +
> +/* Device */
> +#define CXLDEV_CAP_ARRAY_REG 0x0
> +#define CXLDEV_CAP_ARRAY_CAP_ID 0
> +#define CXLDEV_CAP_ARRAY_ID(x) ((x) & 0xffff)
> +#define CXLDEV_CAP_ARRAY_COUNT(x) (((x) >> 32) & 0xffff)
> +
> +#define CXL_CAPABILITIES_CAP_ID_DEVICE_STATUS 1
> +#define CXL_CAPABILITIES_CAP_ID_PRIMARY_MAILBOX 2
> +#define CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX 3
> +#define CXL_CAPABILITIES_CAP_ID_MEMDEV 0x4000

Strange that the first three are decimal and the last is hex.

> +/* Mailbox */
> +#define CXLDEV_MB_CAPS 0x00
> +#define   CXLDEV_MB_CAP_PAYLOAD_SIZE(cap) ((cap) & 0x1F)

Use upper- or lower-case hex consistently.  Add tabs to line things
up.

> +#define CXLDEV_MB_CTRL 0x04
> +#define CXLDEV_MB_CMD 0x08
> +#define CXLDEV_MB_STATUS 0x10
> +#define CXLDEV_MB_BG_CMD_STATUS 0x18
> +
> +struct cxl_mem {
> +	struct pci_dev *pdev;
> +	void __iomem *regs;
> +
> +	/* Cap 0000h */
> +	struct {
> +		void __iomem *regs;
> +	} status;
> +
> +	/* Cap 0002h */
> +	struct {
> +		void __iomem *regs;
> +		size_t payload_size;
> +	} mbox;
> +
> +	/* Cap 0040h */
> +	struct {
> +		void __iomem *regs;
> +	} mem;
> +};

Maybe a note about why READ_ONCE() is required?

> +#define cxl_reg(type)                                                          \
> +	static inline void cxl_write_##type##_reg32(struct cxl_mem *cxlm,      \
> +						    u32 reg, u32 value)        \
> +	{                                                                      \
> +		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
> +		writel(value, reg_addr + reg);                                 \
> +	}                                                                      \
> +	static inline void cxl_write_##type##_reg64(struct cxl_mem *cxlm,      \
> +						    u32 reg, u64 value)        \
> +	{                                                                      \
> +		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
> +		writeq(value, reg_addr + reg);                                 \
> +	}                                                                      \
> +	static inline u32 cxl_read_##type##_reg32(struct cxl_mem *cxlm,        \
> +						  u32 reg)                     \
> +	{                                                                      \
> +		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
> +		return readl(reg_addr + reg);                                  \
> +	}                                                                      \
> +	static inline u64 cxl_read_##type##_reg64(struct cxl_mem *cxlm,        \
> +						  u32 reg)                     \
> +	{                                                                      \
> +		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
> +		return readq(reg_addr + reg);                                  \
> +	}
> +
> +cxl_reg(status)
> +cxl_reg(mbox)
> +
> +static inline u32 __cxl_raw_read_reg32(struct cxl_mem *cxlm, u32 reg)
> +{
> +	void __iomem *reg_addr = READ_ONCE(cxlm->regs);
> +
> +	return readl(reg_addr + reg);
> +}
> +
> +static inline u64 __cxl_raw_read_reg64(struct cxl_mem *cxlm, u32 reg)
> +{
> +	void __iomem *reg_addr = READ_ONCE(cxlm->regs);
> +
> +	return readq(reg_addr + reg);
> +}

Are the "__" prefixes here to leave space for something else in the
future?  "__" typically means something like "raw", so right now it
sort of reads like "raw cxl raw read".  So if you don't *need* the
"__" prefix, I'd drop it.

> +#endif /* __CXL_H__ */
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 8d9b9ab6c5ea..4109ef7c3ecb 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -5,11 +5,57 @@
>  #include <linux/io.h>
>  #include "acpi.h"
>  #include "pci.h"
> +#include "cxl.h"
>  
> -struct cxl_mem {
> -	struct pci_dev *pdev;
> -	void __iomem *regs;
> -};

Probably nicer if you put "struct cxl_mem" in its ultimate destination
(drivers/cxl/cxl.h) from the beginning.  Then it's easier to see what
this patch adds because it's not moving at the same time.

> +static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> +{
> +	u64 cap_array;
> +	int cap;
> +
> +	cap_array = __cxl_raw_read_reg64(cxlm, CXLDEV_CAP_ARRAY_REG);
> +	if (CXLDEV_CAP_ARRAY_ID(cap_array) != CXLDEV_CAP_ARRAY_CAP_ID)
> +		return -ENODEV;
> +
> +	for (cap = 1; cap <= CXLDEV_CAP_ARRAY_COUNT(cap_array); cap++) {
> +		void *__iomem register_block;
> +		u32 offset;
> +		u16 cap_id;
> +
> +		cap_id = __cxl_raw_read_reg32(cxlm, cap * 0x10) & 0xffff;
> +		offset = __cxl_raw_read_reg32(cxlm, cap * 0x10 + 0x4);
> +		register_block = cxlm->regs + offset;
> +
> +		switch (cap_id) {
> +		case CXL_CAPABILITIES_CAP_ID_DEVICE_STATUS:
> +			dev_dbg(&cxlm->pdev->dev, "found Status capability\n");

Consider including the address or offset in these messages to help
debug?  Printing a completely constant string always seems like a
missed opportunity to me.

> +			cxlm->status.regs = register_block;
> +			break;
> +		case CXL_CAPABILITIES_CAP_ID_PRIMARY_MAILBOX:
> +			dev_dbg(&cxlm->pdev->dev,
> +				 "found Mailbox capability\n");
> +			cxlm->mbox.regs = register_block;
> +			cxlm->mbox.payload_size = CXLDEV_MB_CAP_PAYLOAD_SIZE(cap_id);
> +			break;
> +		case CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX:
> +			dev_dbg(&cxlm->pdev->dev,
> +				   "found UNSUPPORTED Secondary Mailbox capability\n");
> +			break;
> +		case CXL_CAPABILITIES_CAP_ID_MEMDEV:
> +			dev_dbg(&cxlm->pdev->dev,
> +				 "found Memory Device capability\n");
> +			cxlm->mem.regs = register_block;
> +			break;
> +		default:
> +			dev_err(&cxlm->pdev->dev, "Unknown cap ID: %d\n", cap_id);
> +			return -ENXIO;
> +		}
> +	}
> +
> +	if (!cxlm->status.regs || !cxlm->mbox.regs || !cxlm->mem.regs)
> +		return -ENXIO;
> +
> +	return 0;
> +}
>  
>  static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo, u32 reg_hi)
>  {
> @@ -110,6 +156,10 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  	if (IS_ERR(cxlm))
>  		return -ENXIO;
>  
> +	rc = cxl_mem_setup_regs(cxlm);
> +	if (rc)
> +		return rc;
> +
>  	pci_set_drvdata(pdev, cxlm);
>  
>  	return 0;
> -- 
> 2.29.2
> 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox
  2020-11-11  5:43 ` [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox Ben Widawsky
@ 2020-11-13 23:14   ` Bjorn Helgaas
  2020-11-17 15:31   ` Jonathan Cameron
  1 sibling, 0 replies; 73+ messages in thread
From: Bjorn Helgaas @ 2020-11-13 23:14 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, Nov 10, 2020 at 09:43:54PM -0800, Ben Widawsky wrote:
> Create a function to handle sending a command, optionally with a
> payload, to the memory device, polling on a result, and then optionally
> copying out the payload. The algorithm for doing this come straight out
> of the CXL 2.0 specification.
> 
> Primary mailboxes are capable of generating an interrupt when submitting
> a command in the background. That implementation is saved for a later
> time.
> 
> Secondary mailboxes aren't implemented at this time.
> 
> WARNING: This is untested with actual timeouts occurring.
> 
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> ---
>  drivers/cxl/cxl.h |  16 +++++++
>  drivers/cxl/mem.c | 107 ++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 123 insertions(+)
> 
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 482fc9cdc890..f49ab80f68bd 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -21,8 +21,12 @@
>  #define CXLDEV_MB_CTRL 0x04
>  #define   CXLDEV_MB_CTRL_DOORBELL BIT(0)
>  #define CXLDEV_MB_CMD 0x08
> +#define   CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT 16
>  #define CXLDEV_MB_STATUS 0x10
> +#define   CXLDEV_MB_STATUS_RET_CODE_SHIFT 32
> +#define   CXLDEV_MB_STATUS_RET_CODE_MASK 0xffff
>  #define CXLDEV_MB_BG_CMD_STATUS 0x18
> +#define CXLDEV_MB_PAYLOAD 0x20
>  
>  /* Memory Device */
>  #define CXLMDEV_STATUS 0
> @@ -114,4 +118,16 @@ static inline u64 __cxl_raw_read_reg64(struct cxl_mem *cxlm, u32 reg)
>  
>  	return readq(reg_addr + reg);
>  }
> +
> +static inline void cxl_mbox_payload_fill(struct cxl_mem *cxlm, u8 *input,
> +					    unsigned int length)
> +{
> +	memcpy_toio(cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, input, length);
> +}
> +
> +static inline void cxl_mbox_payload_drain(struct cxl_mem *cxlm,
> +					     u8 *output, unsigned int length)
> +{
> +	memcpy_fromio(output, cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, length);
> +}
>  #endif /* __CXL_H__ */
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 9fd2d1daa534..08913360d500 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -1,5 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  // Copyright(c) 2020 Intel Corporation. All rights reserved.

/* Copyright ... */

> +#include <linux/sched/clock.h>
>  #include <linux/module.h>
>  #include <linux/pci.h>
>  #include <linux/io.h>
> @@ -7,6 +8,112 @@
>  #include "pci.h"
>  #include "cxl.h"
>  
> +struct mbox_cmd {
> +	u16 cmd;
> +	u8 *payload;
> +	size_t payload_size;
> +	u16 return_code;
> +};
> +
> +static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
> +{
> +	u64 start, now;
> +	int cpu, ret, timeout = 2000000000;

It'd be nice to have a hint about where this timeout comes from and
what the units are.  local_clock(), sched_clock_cpu(), etc don't have
any hints either and I got tired of following the chain.

Several callers use ns_to_ktime(local_clock()), so I guess it must be
in ns?

> +	start = local_clock();
> +	preempt_disable();
> +	cpu = smp_processor_id();
> +	for (;;) {
> +		now = local_clock();
> +		preempt_enable();
> +		if ((cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CTRL) &
> +		     CXLDEV_MB_CTRL_DOORBELL) == 0) {
> +			ret = 0;
> +			break;
> +		}
> +
> +		if (now - start >= timeout) {
> +			ret = -ETIMEDOUT;
> +			break;
> +		}
> +
> +		cpu_relax();
> +		preempt_disable();
> +		if (unlikely(cpu != smp_processor_id())) {
> +			timeout -= (now - start);
> +			cpu = smp_processor_id();
> +			start = local_clock();
> +		}
> +	}

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-13 18:17   ` Bjorn Helgaas
@ 2020-11-14  1:08     ` Ben Widawsky
  2020-11-15  0:23       ` Dan Williams
  0 siblings, 1 reply; 73+ messages in thread
From: Ben Widawsky @ 2020-11-14  1:08 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On 20-11-13 12:17:28, Bjorn Helgaas wrote:
> On Tue, Nov 10, 2020 at 09:43:50PM -0800, Ben Widawsky wrote:
> > From: Dan Williams <dan.j.williams@intel.com>
> > 
> > The CXL.mem protocol allows a device to act as a provider of "System
> > RAM" and/or "Persistent Memory" that is fully coherent as if the memory
> > was attached to the typical CPU memory controller.
> > 
> > The memory range exported by the device may optionally be described by
> > the platform firmware memory map, or by infrastructure like LIBNVDIMM to
> > provision persistent memory capacity from one, or more, CXL.mem devices.
> > 
> > A pre-requisite for Linux-managed memory-capacity provisioning is this
> > cxl_mem driver that can speak the "type-3 mailbox" protocol.
> 
> "Type 3" to indicate that this is a proper adjective that can be
> looked up in the spec and to match the usage there.
> 
> The r1.1 spec I have doesn't mention "mailbox".  Is that also
> something defined in the 2.0 spec?

Yes, these device types are new to 2.0.

> 
> A URL or similar citation for the spec would be nice somewhere.
> 

Agreed. For the patches I authored at least, it seemed repetitive to put a Link:
in each one to the spec. It was meant to be in the cover letter, but obviously I
missed that. Do you have a suggestion there, is cover letter good enough?

> > For now just land the driver boiler-plate and fill it in with
> > functionality in subsequent commits.
> > 
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > ---
> >  drivers/cxl/Kconfig  | 20 +++++++++++
> >  drivers/cxl/Makefile |  2 ++
> >  drivers/cxl/mem.c    | 82 ++++++++++++++++++++++++++++++++++++++++++++
> >  drivers/cxl/pci.h    | 15 ++++++++
> >  4 files changed, 119 insertions(+)
> >  create mode 100644 drivers/cxl/mem.c
> >  create mode 100644 drivers/cxl/pci.h
> > 
> > diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> > index dd724bd364df..15548f5c77ff 100644
> > --- a/drivers/cxl/Kconfig
> > +++ b/drivers/cxl/Kconfig
> > @@ -27,4 +27,24 @@ config CXL_ACPI
> >  	  resources described by the CEDT (CXL Early Discovery Table)
> >  
> >  	  Say 'y' to enable CXL (Compute Express Link) drivers.
> > +
> > +config CXL_MEM
> > +        tristate "CXL.mem Device Support"
> > +        depends on PCI && CXL_BUS_PROVIDER != n
> > +        default m if CXL_BUS_PROVIDER
> > +        help
> > +          The CXL.mem protocol allows a device to act as a provider of
> > +          "System RAM" and/or "Persistent Memory" that is fully coherent
> > +          as if the memory was attached to the typical CPU memory
> > +          controller.
> > +
> > +          Say 'y/m' to enable a driver named "cxl_mem.ko" that will attach
> > +          to CXL.mem devices for configuration, provisioning, and health
> > +          monitoring, the so called "type-3 mailbox". Note, this driver
> 
> "Type 3"
> 
> > +          is required for dynamic provisioning of CXL.mem attached
> > +          memory, a pre-requisite for persistent memory support, but
> > +          devices that provide volatile memory may be fully described by
> > +          existing platform firmware memory enumeration.
> > +
> > +          If unsure say 'n'.
> >  endif
> > diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> > index d38cd34a2582..97fdffb00f2d 100644
> > --- a/drivers/cxl/Makefile
> > +++ b/drivers/cxl/Makefile
> > @@ -1,5 +1,7 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
> > +obj-$(CONFIG_CXL_MEM) += cxl_mem.o
> >  
> >  ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
> >  cxl_acpi-y := acpi.o
> > +cxl_mem-y := mem.o
> > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > new file mode 100644
> > index 000000000000..aa7d881fa47b
> > --- /dev/null
> > +++ b/drivers/cxl/mem.c
> > @@ -0,0 +1,82 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > +#include <linux/module.h>
> > +#include <linux/pci.h>
> > +#include <linux/io.h>
> > +#include "acpi.h"
> > +#include "pci.h"
> > +
> > +struct cxl_mem {
> > +	void __iomem *regs;
> > +};
> 
> Unused, maybe move it to the patch that adds the use?
> 

This is a remnant from when Dan gave me the basis to do the mmio work. I agree
it can be removed now.

> > +static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> > +{
> > +	int pos;
> > +
> > +	pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DVSEC);
> > +	if (!pos)
> > +		return 0;
> > +
> > +	while (pos) {
> > +		u16 vendor, id;
> > +
> > +		pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, &vendor);
> > +		pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, &id);
> > +		if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> > +			return pos;
> > +
> > +		pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
> > +	}
> > +
> > +	return 0;
> > +}
> 
> I assume we'll refactor and move this into the PCI core after we
> resolve the several places this is needed.  When we do that, the
> vendor would be passed in, so maybe we should do that here to make it
> simpler to move this to the PCI core.
> 

I think we'll need to keep this in order to try to keep the dream alive of
loading a CXL kernel module on an older kernel. However, PCI code would benefit
from having it (in an ideal world, it'd only be there).

> > +static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct cxl_mem *cxlm;
> > +	int rc, regloc;
> > +
> > +	rc = cxl_bus_prepared(pdev);
> > +	if (rc != 0) {
> > +		dev_err(dev, "failed to acquire interface\n");
> 
> Interesting naming: apparently when cxl_bus_prepared() returns a
> non-zero ("true") value, it is actually *not* prepared?
> 

This looks like a rebase fail to me, but I'll let Dan answer.

> > +		return rc;
> > +	}
> > +
> > +	regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
> > +	if (!regloc) {
> > +		dev_err(dev, "register location dvsec not found\n");
> > +		return -ENXIO;
> > +	}
> > +
> > +	cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> > +	if (!cxlm)
> > +		return -ENOMEM;
> 
> Unused.  And [4/9] removes it before it's *ever* used :)
> 

Same as a few above, I think Dan was providing this for me to implement the
reset. It could go away...

> > +	return 0;
> > +}
> > +
> > +static void cxl_mem_remove(struct pci_dev *pdev)
> > +{
> > +}
> > +
> > +static const struct pci_device_id cxl_mem_pci_tbl[] = {
> > +	/* PCI class code for CXL.mem Type-3 Devices */
> > +	{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> > +	  PCI_CLASS_MEMORY_CXL, 0xffffff, 0 },
> > +	{ /* terminate list */ },
> > +};
> > +MODULE_DEVICE_TABLE(pci, cxl_mem_pci_tbl);
> > +
> > +static struct pci_driver cxl_mem_driver = {
> > +	.name			= KBUILD_MODNAME,
> > +	.id_table		= cxl_mem_pci_tbl,
> > +	.probe			= cxl_mem_probe,
> > +	.remove			= cxl_mem_remove,
> > +};
> > +
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_AUTHOR("Intel Corporation");
> > +module_pci_driver(cxl_mem_driver);
> > +MODULE_IMPORT_NS(CXL);
> > diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> > new file mode 100644
> > index 000000000000..beb03921e6da
> > --- /dev/null
> 
> > +++ b/drivers/cxl/pci.h
> > @@ -0,0 +1,15 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> 
> /* SPDX-... */
> /* Copyright ...*/
> 
> The SPDX rules are a bit arcane and annoyingly hard to grep for, but
> I found them in Documentation/process/license-rules.rst
> 
> > +#ifndef __CXL_PCI_H__
> > +#define __CXL_PCI_H__
> > +
> > +#define PCI_CLASS_MEMORY_CXL	0x050210
> > +
> > +#define PCI_EXT_CAP_ID_DVSEC	0x23
> > +#define PCI_DVSEC_VENDOR_CXL	0x1E98
> > +#define PCI_DVSEC_VENDOR_OFFSET	0x4
> > +#define PCI_DVSEC_ID_OFFSET	0x8
> > +#define PCI_DVSEC_ID_CXL	0x0
> > +#define PCI_DVSEC_ID_CXL_REGLOC	0x8
> 
> I assume these will go in include/linux/pci_ids.h (PCI_CLASS_...) and
> include/uapi/linux/pci_regs.h (the rest) eventually, after we get the
> merge issues sorted out.  But if they're only used in cxl/mem.c, I'd
> put them there for now.
> 
> > +#endif /* __CXL_PCI_H__ */
> > -- 
> > 2.29.2
> > 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers
  2020-11-13 18:17   ` Bjorn Helgaas
@ 2020-11-14  1:12     ` Ben Widawsky
  2020-11-16 23:19       ` Dan Williams
  0 siblings, 1 reply; 73+ messages in thread
From: Ben Widawsky @ 2020-11-14  1:12 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On 20-11-13 12:17:32, Bjorn Helgaas wrote:
> On Tue, Nov 10, 2020 at 09:43:51PM -0800, Ben Widawsky wrote:
> > All the necessary bits are initialized in order to find and map the
> > register space for CXL Memory Devices. This is accomplished by using the
> > Register Locator DVSEC (CXL 2.0 - 8.1.9.1) to determine which PCI BAR to
> > use, and how much of an offset from that BAR should be added.
> 
> "Initialize the necessary bits ..." to use the usual imperative
> sentence structure, as you did in the subject.
> 
> > If the memory device registers are found and mapped a new internal data
> > structure tracking device state is allocated.
> 
> "Allocate device state if we find device registers" or similar.
> 
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > ---
> >  drivers/cxl/mem.c | 68 +++++++++++++++++++++++++++++++++++++++++++----
> >  drivers/cxl/pci.h |  6 +++++
> >  2 files changed, 69 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > index aa7d881fa47b..8d9b9ab6c5ea 100644
> > --- a/drivers/cxl/mem.c
> > +++ b/drivers/cxl/mem.c
> > @@ -7,9 +7,49 @@
> >  #include "pci.h"
> >  
> >  struct cxl_mem {
> > +	struct pci_dev *pdev;
> >  	void __iomem *regs;
> >  };
> >  
> > +static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo, u32 reg_hi)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct cxl_mem *cxlm;
> > +	void __iomem *regs;
> > +	u64 offset;
> > +	u8 bar;
> > +	int rc;
> > +
> > +	offset = ((u64)reg_hi << 32) | (reg_lo & 0xffff0000);
> > +	bar = reg_lo & 0x7;
> > +
> > +	/* Basic sanity check that BAR is big enough */
> > +	if (pci_resource_len(pdev, bar) < offset) {
> > +		dev_err(dev, "bar%d: %pr: too small (offset: %#llx)\n",
> > +				bar, &pdev->resource[bar], (unsigned long long) offset);
> 
> s/bar/BAR/
> 
> > +		return ERR_PTR(-ENXIO);
> > +	}
> > +
> > +	rc = pcim_iomap_regions(pdev, 1 << bar, pci_name(pdev));
> > +	if (rc != 0) {
> > +		dev_err(dev, "failed to map registers\n");
> > +		return ERR_PTR(-ENXIO);
> > +	}
> > +
> > +	cxlm = devm_kzalloc(&pdev->dev, sizeof(*cxlm), GFP_KERNEL);
> > +	if (!cxlm) {
> > +		dev_err(dev, "No memory available\n");
> > +		return ERR_PTR(-ENOMEM);
> > +	}
> > +
> > +	regs = pcim_iomap_table(pdev)[bar];
> > +	cxlm->pdev = pdev;
> > +	cxlm->regs = regs + offset;
> > +
> > +	dev_dbg(dev, "Mapped CXL Memory Device resource\n");
> > +	return cxlm;
> > +}
> > +
> >  static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> >  {
> >  	int pos;
> > @@ -34,9 +74,9 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> >  
> >  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> >  {
> > +	struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
> >  	struct device *dev = &pdev->dev;
> > -	struct cxl_mem *cxlm;
> 
> The order was better before ("dev", then "clxm").  Oh, I suppose this
> is a "reverse Christmas tree" thing.
> 

I don't actually care either way as long as it's consistent. I tend to do
reverse Christmas tree for no particular reason.

> > -	int rc, regloc;
> > +	int rc, regloc, i;
> >  
> >  	rc = cxl_bus_prepared(pdev);
> >  	if (rc != 0) {
> > @@ -44,15 +84,33 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> >  		return rc;
> >  	}
> >  
> > +	rc = pcim_enable_device(pdev);
> > +	if (rc)
> > +		return rc;
> > +
> >  	regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
> >  	if (!regloc) {
> >  		dev_err(dev, "register location dvsec not found\n");
> >  		return -ENXIO;
> >  	}
> > +	regloc += 0xc; /* Skip DVSEC + reserved fields */
> > +
> > +	for (i = regloc; i < regloc + 0x24; i += 8) {
> > +		u32 reg_lo, reg_hi;
> > +
> > +		pci_read_config_dword(pdev, i, &reg_lo);
> > +		pci_read_config_dword(pdev, i + 4, &reg_hi);
> > +
> > +		if (CXL_REGLOG_IS_MEMDEV(reg_lo)) {
> > +			cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
> > +			break;
> > +		}
> > +	}
> > +
> > +	if (IS_ERR(cxlm))
> > +		return -ENXIO;
> 
> I think this would be easier to read if cxl_mem_create() returned NULL
> on failure (it prints error messages and we throw away
> -ENXIO/-ENOMEM distinction here anyway) so you could do:
> 
>   struct cxl_mem *cxlm = NULL;
> 
>   for (...) {
>     if (...) {
>       cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
>       break;
>     }
>   }
> 
>   if (!cxlm)
>     return -ENXIO;  /* -ENODEV might be more natural? */
> 

I agree on both counts. Both of these came from Dan, so I will let him explain.

> > -	cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> > -	if (!cxlm)
> > -		return -ENOMEM;
> > +	pci_set_drvdata(pdev, cxlm);
> >  
> >  	return 0;
> >  }
> > diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> > index beb03921e6da..be87f62e9132 100644
> > --- a/drivers/cxl/pci.h
> > +++ b/drivers/cxl/pci.h
> > @@ -12,4 +12,10 @@
> >  #define PCI_DVSEC_ID_CXL	0x0
> >  #define PCI_DVSEC_ID_CXL_REGLOC	0x8
> >  
> > +#define CXL_REGLOG_RBI_EMPTY 0
> > +#define CXL_REGLOG_RBI_COMPONENT 1
> > +#define CXL_REGLOG_RBI_VIRT 2
> > +#define CXL_REGLOG_RBI_MEMDEV 3
> 
> Maybe line these values up.
> 
> > +#define CXL_REGLOG_IS_MEMDEV(x) ((((x) >> 8) & 0xff) == CXL_REGLOG_RBI_MEMDEV)
> 
> If these are only needed in cxl/mem.c, they could go there.  Do you
> expect code outside of drivers/cxl to need these?

Will do.

I'll suck in everything else as they seem like improvements.

> 
> >  #endif /* __CXL_PCI_H__ */
> > -- 
> > 2.29.2
> > 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities
  2020-11-13 18:26   ` Bjorn Helgaas
@ 2020-11-14  1:36     ` Ben Widawsky
  0 siblings, 0 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-14  1:36 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On 20-11-13 12:26:03, Bjorn Helgaas wrote:
> On Tue, Nov 10, 2020 at 09:43:52PM -0800, Ben Widawsky wrote:
> > CXL devices contain an array of capabilities that describe the
> > interactions software can interact with the device, or firmware running
> > on the device. A CXL compliant device must implement the device status
> > and the mailbox capability. A CXL compliant memory device must implement
> > the memory device capability.
> > 
> > Each of the capabilities can [will] provide an offset within the MMIO
> > region for interacting with the CXL device.
> > 
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > ---
> >  drivers/cxl/cxl.h | 89 +++++++++++++++++++++++++++++++++++++++++++++++
> >  drivers/cxl/mem.c | 58 +++++++++++++++++++++++++++---
> >  2 files changed, 143 insertions(+), 4 deletions(-)
> >  create mode 100644 drivers/cxl/cxl.h
> > 
> > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> > new file mode 100644
> > index 000000000000..02858ae63d6d
> > --- /dev/null
> > +++ b/drivers/cxl/cxl.h
> > @@ -0,0 +1,89 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> 
> Fix comment usage (I think SPDX in .h needs "/* */")
> 
> > +#ifndef __CXL_H__
> > +#define __CXL_H__
> > +
> > +/* Device */
> > +#define CXLDEV_CAP_ARRAY_REG 0x0
> > +#define CXLDEV_CAP_ARRAY_CAP_ID 0
> > +#define CXLDEV_CAP_ARRAY_ID(x) ((x) & 0xffff)
> > +#define CXLDEV_CAP_ARRAY_COUNT(x) (((x) >> 32) & 0xffff)
> > +
> > +#define CXL_CAPABILITIES_CAP_ID_DEVICE_STATUS 1
> > +#define CXL_CAPABILITIES_CAP_ID_PRIMARY_MAILBOX 2
> > +#define CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX 3
> > +#define CXL_CAPABILITIES_CAP_ID_MEMDEV 0x4000
> 
> Strange that the first three are decimal and the last is hex.
> 
> > +/* Mailbox */
> > +#define CXLDEV_MB_CAPS 0x00
> > +#define   CXLDEV_MB_CAP_PAYLOAD_SIZE(cap) ((cap) & 0x1F)
> 
> Use upper- or lower-case hex consistently.  Add tabs to line things
> up.
> 
> > +#define CXLDEV_MB_CTRL 0x04
> > +#define CXLDEV_MB_CMD 0x08
> > +#define CXLDEV_MB_STATUS 0x10
> > +#define CXLDEV_MB_BG_CMD_STATUS 0x18
> > +
> > +struct cxl_mem {
> > +	struct pci_dev *pdev;
> > +	void __iomem *regs;
> > +
> > +	/* Cap 0000h */
> > +	struct {
> > +		void __iomem *regs;
> > +	} status;
> > +
> > +	/* Cap 0002h */
> > +	struct {
> > +		void __iomem *regs;
> > +		size_t payload_size;
> > +	} mbox;
> > +
> > +	/* Cap 0040h */
> > +	struct {
> > +		void __iomem *regs;
> > +	} mem;
> > +};
> 
> Maybe a note about why READ_ONCE() is required?
> 

I don't believe it's actually necessary. I will drop it.

> > +#define cxl_reg(type)                                                          \
> > +	static inline void cxl_write_##type##_reg32(struct cxl_mem *cxlm,      \
> > +						    u32 reg, u32 value)        \
> > +	{                                                                      \
> > +		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
> > +		writel(value, reg_addr + reg);                                 \
> > +	}                                                                      \
> > +	static inline void cxl_write_##type##_reg64(struct cxl_mem *cxlm,      \
> > +						    u32 reg, u64 value)        \
> > +	{                                                                      \
> > +		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
> > +		writeq(value, reg_addr + reg);                                 \
> > +	}                                                                      \
> > +	static inline u32 cxl_read_##type##_reg32(struct cxl_mem *cxlm,        \
> > +						  u32 reg)                     \
> > +	{                                                                      \
> > +		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
> > +		return readl(reg_addr + reg);                                  \
> > +	}                                                                      \
> > +	static inline u64 cxl_read_##type##_reg64(struct cxl_mem *cxlm,        \
> > +						  u32 reg)                     \
> > +	{                                                                      \
> > +		void __iomem *reg_addr = READ_ONCE(cxlm->type.regs);           \
> > +		return readq(reg_addr + reg);                                  \
> > +	}
> > +
> > +cxl_reg(status)
> > +cxl_reg(mbox)
> > +
> > +static inline u32 __cxl_raw_read_reg32(struct cxl_mem *cxlm, u32 reg)
> > +{
> > +	void __iomem *reg_addr = READ_ONCE(cxlm->regs);
> > +
> > +	return readl(reg_addr + reg);
> > +}
> > +
> > +static inline u64 __cxl_raw_read_reg64(struct cxl_mem *cxlm, u32 reg)
> > +{
> > +	void __iomem *reg_addr = READ_ONCE(cxlm->regs);
> > +
> > +	return readq(reg_addr + reg);
> > +}
> 
> Are the "__" prefixes here to leave space for something else in the
> future?  "__" typically means something like "raw", so right now it
> sort of reads like "raw cxl raw read".  So if you don't *need* the
> "__" prefix, I'd drop it.
> 

The "__" prefix is because those functions really shouldn't be used except in
early initialization and perhaps for debugfs kinds of things. I can remove the
'raw' from the name, but I do consider this a raw read as it isn't going to
read/write to any particular function of a CXL device.

So unless you're deeply offended by it, I'd like to make it

__cxl_read/write_reg64()

> > +#endif /* __CXL_H__ */
> > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > index 8d9b9ab6c5ea..4109ef7c3ecb 100644
> > --- a/drivers/cxl/mem.c
> > +++ b/drivers/cxl/mem.c
> > @@ -5,11 +5,57 @@
> >  #include <linux/io.h>
> >  #include "acpi.h"
> >  #include "pci.h"
> > +#include "cxl.h"
> >  
> > -struct cxl_mem {
> > -	struct pci_dev *pdev;
> > -	void __iomem *regs;
> > -};
> 
> Probably nicer if you put "struct cxl_mem" in its ultimate destination
> (drivers/cxl/cxl.h) from the beginning.  Then it's easier to see what
> this patch adds because it's not moving at the same time.
> 

Yes, this is sort of the wart again of 3 of us all working on the code at the
same time. Dan, you want to squash it into yours?

> > +static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> > +{
> > +	u64 cap_array;
> > +	int cap;
> > +
> > +	cap_array = __cxl_raw_read_reg64(cxlm, CXLDEV_CAP_ARRAY_REG);
> > +	if (CXLDEV_CAP_ARRAY_ID(cap_array) != CXLDEV_CAP_ARRAY_CAP_ID)
> > +		return -ENODEV;
> > +
> > +	for (cap = 1; cap <= CXLDEV_CAP_ARRAY_COUNT(cap_array); cap++) {
> > +		void *__iomem register_block;
> > +		u32 offset;
> > +		u16 cap_id;
> > +
> > +		cap_id = __cxl_raw_read_reg32(cxlm, cap * 0x10) & 0xffff;
> > +		offset = __cxl_raw_read_reg32(cxlm, cap * 0x10 + 0x4);
> > +		register_block = cxlm->regs + offset;
> > +
> > +		switch (cap_id) {
> > +		case CXL_CAPABILITIES_CAP_ID_DEVICE_STATUS:
> > +			dev_dbg(&cxlm->pdev->dev, "found Status capability\n");
> 
> Consider including the address or offset in these messages to help
> debug?  Printing a completely constant string always seems like a
> missed opportunity to me.
> 

Sure. The main thing the debug message is trying to help notify is textual
versions of the caps, compared to what one might expect. I don't see offsets as
immediately useful, but they definitely do not hurt.

> > +			cxlm->status.regs = register_block;
> > +			break;
> > +		case CXL_CAPABILITIES_CAP_ID_PRIMARY_MAILBOX:
> > +			dev_dbg(&cxlm->pdev->dev,
> > +				 "found Mailbox capability\n");
> > +			cxlm->mbox.regs = register_block;
> > +			cxlm->mbox.payload_size = CXLDEV_MB_CAP_PAYLOAD_SIZE(cap_id);
> > +			break;
> > +		case CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX:
> > +			dev_dbg(&cxlm->pdev->dev,
> > +				   "found UNSUPPORTED Secondary Mailbox capability\n");
> > +			break;
> > +		case CXL_CAPABILITIES_CAP_ID_MEMDEV:
> > +			dev_dbg(&cxlm->pdev->dev,
> > +				 "found Memory Device capability\n");
> > +			cxlm->mem.regs = register_block;
> > +			break;
> > +		default:
> > +			dev_err(&cxlm->pdev->dev, "Unknown cap ID: %d\n", cap_id);
> > +			return -ENXIO;
> > +		}
> > +	}
> > +
> > +	if (!cxlm->status.regs || !cxlm->mbox.regs || !cxlm->mem.regs)
> > +		return -ENXIO;
> > +
> > +	return 0;
> > +}
> >  
> >  static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo, u32 reg_hi)
> >  {
> > @@ -110,6 +156,10 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> >  	if (IS_ERR(cxlm))
> >  		return -ENXIO;
> >  
> > +	rc = cxl_mem_setup_regs(cxlm);
> > +	if (rc)
> > +		return rc;
> > +
> >  	pci_set_drvdata(pdev, cxlm);
> >  
> >  	return 0;
> > -- 
> > 2.29.2
> > 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-14  1:08     ` Ben Widawsky
@ 2020-11-15  0:23       ` Dan Williams
  0 siblings, 0 replies; 73+ messages in thread
From: Dan Williams @ 2020-11-15  0:23 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Bjorn Helgaas, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Fri, Nov 13, 2020 at 5:09 PM Ben Widawsky <ben.widawsky@intel.com> wrote:
[..]
> > Unused, maybe move it to the patch that adds the use?
> >
>
> This is a remnant from when Dan gave me the basis to do the mmio work. I agree
> it can be removed now.

Yes.

> > > +static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> > > +{
> > > +   int pos;
> > > +
> > > +   pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DVSEC);
> > > +   if (!pos)
> > > +           return 0;
> > > +
> > > +   while (pos) {
> > > +           u16 vendor, id;
> > > +
> > > +           pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, &vendor);
> > > +           pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, &id);
> > > +           if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> > > +                   return pos;
> > > +
> > > +           pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
> > > +   }
> > > +
> > > +   return 0;
> > > +}
> >
> > I assume we'll refactor and move this into the PCI core after we
> > resolve the several places this is needed.  When we do that, the
> > vendor would be passed in, so maybe we should do that here to make it
> > simpler to move this to the PCI core.
> >
>
> I think we'll need to keep this in order to try to keep the dream alive of
> loading a CXL kernel module on an older kernel. However, PCI code would benefit
> from having it (in an ideal world, it'd only be there).

So I think this is fine / expected to move standalone common code like
this to the PCI core. What I'm aiming to avoid with "the dream" Ben
references is unnecessary dependencies on core changes. CXL is large
enough that it will generate more backport pressure than ACPI NFIT /
LIBNVDIMM ever did. From a self interest perspective maximizing how
much of CXL can be enabled without core dependencies is a goal just to
lighten my own backport load. The internals of cxl_mem_dvsec() are
simple enough to backport.

>
> > > +static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > > +{
> > > +   struct device *dev = &pdev->dev;
> > > +   struct cxl_mem *cxlm;
> > > +   int rc, regloc;
> > > +
> > > +   rc = cxl_bus_prepared(pdev);
> > > +   if (rc != 0) {
> > > +           dev_err(dev, "failed to acquire interface\n");
> >
> > Interesting naming: apparently when cxl_bus_prepared() returns a
> > non-zero ("true") value, it is actually *not* prepared?
> >
>
> This looks like a rebase fail to me, but I'll let Dan answer.

Yeah, I originally envisioned this as a ternary result with
-EPROBE_DEFER as a possible return value, but now that we've found a
way to handle CXL _OSC without colliding with legacy PCIE _OSC this
can indeed move to a boolean result.

Will fix up.

>
> > > +           return rc;
> > > +   }
> > > +
> > > +   regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
> > > +   if (!regloc) {
> > > +           dev_err(dev, "register location dvsec not found\n");
> > > +           return -ENXIO;
> > > +   }
> > > +
> > > +   cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> > > +   if (!cxlm)
> > > +           return -ENOMEM;
> >
> > Unused.  And [4/9] removes it before it's *ever* used :)
> >
>
> Same as a few above, I think Dan was providing this for me to implement the
> reset. It could go away...

Yes, a collaboration artifact that we can clean up.

>
> > > +   return 0;
> > > +}
> > > +
> > > +static void cxl_mem_remove(struct pci_dev *pdev)
> > > +{
> > > +}
> > > +
> > > +static const struct pci_device_id cxl_mem_pci_tbl[] = {
> > > +   /* PCI class code for CXL.mem Type-3 Devices */
> > > +   { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> > > +     PCI_CLASS_MEMORY_CXL, 0xffffff, 0 },
> > > +   { /* terminate list */ },
> > > +};
> > > +MODULE_DEVICE_TABLE(pci, cxl_mem_pci_tbl);
> > > +
> > > +static struct pci_driver cxl_mem_driver = {
> > > +   .name                   = KBUILD_MODNAME,
> > > +   .id_table               = cxl_mem_pci_tbl,
> > > +   .probe                  = cxl_mem_probe,
> > > +   .remove                 = cxl_mem_remove,
> > > +};
> > > +
> > > +MODULE_LICENSE("GPL v2");
> > > +MODULE_AUTHOR("Intel Corporation");
> > > +module_pci_driver(cxl_mem_driver);
> > > +MODULE_IMPORT_NS(CXL);
> > > diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> > > new file mode 100644
> > > index 000000000000..beb03921e6da
> > > --- /dev/null
> >
> > > +++ b/drivers/cxl/pci.h
> > > @@ -0,0 +1,15 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> >
> > /* SPDX-... */
> > /* Copyright ...*/
> >
> > The SPDX rules are a bit arcane and annoyingly hard to grep for, but
> > I found them in Documentation/process/license-rules.rst

Yes, I did not realize the header vs source /* */ vs // SPDX style.

> >
> > > +#ifndef __CXL_PCI_H__
> > > +#define __CXL_PCI_H__
> > > +
> > > +#define PCI_CLASS_MEMORY_CXL       0x050210
> > > +
> > > +#define PCI_EXT_CAP_ID_DVSEC       0x23
> > > +#define PCI_DVSEC_VENDOR_CXL       0x1E98
> > > +#define PCI_DVSEC_VENDOR_OFFSET    0x4
> > > +#define PCI_DVSEC_ID_OFFSET        0x8
> > > +#define PCI_DVSEC_ID_CXL   0x0
> > > +#define PCI_DVSEC_ID_CXL_REGLOC    0x8
> >
> > I assume these will go in include/linux/pci_ids.h (PCI_CLASS_...) and
> > include/uapi/linux/pci_regs.h (the rest) eventually, after we get the
> > merge issues sorted out.  But if they're only used in cxl/mem.c, I'd
> > put them there for now.

Yes, I assume they'll move eventually. I'm cheating a standalone
backport driver organization in the meantime.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-11 17:17     ` Dan Williams
  2020-11-11 18:27       ` Dan Williams
  2020-11-11 21:41       ` Randy Dunlap
@ 2020-11-16 16:56       ` Christoph Hellwig
  2 siblings, 0 replies; 73+ messages in thread
From: Christoph Hellwig @ 2020-11-16 16:56 UTC (permalink / raw)
  To: Dan Williams
  Cc: Christoph Hellwig, Ben Widawsky, linux-cxl,
	Linux Kernel Mailing List, Linux PCI, Linux ACPI, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki

On Wed, Nov 11, 2020 at 09:17:37AM -0800, Dan Williams wrote:
> > > +config CXL_MEM
> > > +        tristate "CXL.mem Device Support"
> > > +        depends on PCI && CXL_BUS_PROVIDER != n
> >
> > depend on PCI && CXL_BUS_PROVIDER
> >
> > > +        default m if CXL_BUS_PROVIDER
> >
> > Please don't set weird defaults for new code.  Especially not default
> > to module crap like this.
> 
> This goes back to what people like Dave C. asked for LIBNVDIMM / DAX,
> a way to blanket turn on a subsystem without needing to go hunt down
> individual configs.

Then at least do a

   default CXL_BUS_PROVIDER

but we really don't do this elsewhere.  E.g. we don't default the scsi
disk driver on if there is some host adapter selected.


> > > +MODULE_AUTHOR("Intel Corporation");
> >
> > A module author is not a company.
> 
> At least I don't have a copyright assignment clause, I don't agree
> with the vanity of listing multiple people here especially when
> MAINTAINERS has the contact info, and I don't want to maintain a list
> as people do drive-by contributions and we need to figure out at what
> level of contribution mandates a new MODULE_AUTHOR line. Now, that
> said I would be ok to duplicate the MAINTAINERS as MODULE_AUTHOR
> lines, but I otherwise expect MAINTAINERS is the central source for
> module contact info.

IMHO MODULE_AUTHOR is completely pointless.  I haven't used for ~15
years.  Especially as the concept that a module has a single author
is a rather strange one.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 2/9] cxl/acpi: add OSC support
  2020-11-11  5:43 ` [RFC PATCH 2/9] cxl/acpi: add OSC support Ben Widawsky
@ 2020-11-16 17:59   ` Jonathan Cameron
  2020-11-16 23:25     ` Dan Williams
  0 siblings, 1 reply; 73+ messages in thread
From: Jonathan Cameron @ 2020-11-16 17:59 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, 10 Nov 2020 21:43:49 -0800
Ben Widawsky <ben.widawsky@intel.com> wrote:

> From: Vishal Verma <vishal.l.verma@intel.com>
> 
> Add support to advertise OS capabilities, and request OS control for CXL
> features using the ACPI _OSC mechanism. Advertise support for all
> possible CXL features, and attempt to request control too for all
> possible features.
> 
> Based on a patch by Sean Kelley.
> 
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>

I guess unsurprisingly a lot of this is cut and paste from PCIe
so can we share some of the code?

Thanks,

Jonathan

> 
> ---
> 
> This uses a non-standard UUID for CXL and is meant as a change proposal
> to the CXL specification. The definition for _OSC intermixes PCIe and
> CXL Dwords, which makes a clean separation of CXL capabilities
> difficult, if not impossible. This is therefore subject to change.
> 
> ---
>  drivers/cxl/acpi.c | 210 ++++++++++++++++++++++++++++++++++++++++++++-
>  drivers/cxl/acpi.h |  18 ++++
>  2 files changed, 226 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> index 26e4f73838a7..c3e2f7f6ea02 100644
> --- a/drivers/cxl/acpi.c
> +++ b/drivers/cxl/acpi.c
> @@ -12,6 +12,16 @@
>  #include <linux/pci.h>
>  #include "acpi.h"
>  
> +/*
> + * TODO: These are global for now to save the OSC state.
> + * This works if OSC can be expected to be uniform for every ACPI0016 object.
> + * If that is not the case, revisit this. These need to be saved because
> + * relinquishing control of a previously granted capability is disallowed.
> + */
> +static u32 cxl_osc_support_set;
> +static u32 cxl_osc_control_set;
> +static DEFINE_MUTEX(acpi_desc_lock);
> +
>  static void acpi_cxl_desc_init(struct acpi_cxl_desc *acpi_desc, struct device *dev)
>  {
>  	dev_set_drvdata(dev, acpi_desc);
> @@ -74,6 +84,199 @@ static struct acpi_driver acpi_cxl_driver = {
>  	},
>  };
>  
> +struct pci_osc_bit_struct {
> +	u32 bit;
> +	char *desc;
> +};
> +
> +static struct pci_osc_bit_struct cxl_osc_support_bit[] = {
> +	{ CXL_OSC_PORT_REG_ACCESS_SUPPORT, "CXLPortRegAccess" },
> +	{ CXL_OSC_PORT_DEV_REG_ACCESS_SUPPORT, "CXLPortDevRegAccess" },
> +	{ CXL_OSC_PER_SUPPORT, "CXLProtocolErrorReporting" },
> +	{ CXL_OSC_NATIVE_HP_SUPPORT, "CXLNativeHotPlug" },
> +};
> +
> +static struct pci_osc_bit_struct cxl_osc_control_bit[] = {
> +	{ CXL_OSC_MEM_ERROR_CONTROL, "CXLMemErrorReporting" },
> +};
> +
> +/*
> + * CXL 2.0 spec UUID - unusable as it PCI and CXL OSC are mixed
> + * static u8 cxl_osc_uuid_str[] = "68F2D50B-C469-4d8A-BD3D-941A103FD3FC";
> + */
> +/* New, proposed UUID for CXL-only OSC */
> +static u8 cxl_osc_uuid_str[] = "A4D1629D-FF52-4888-BE96-E5CADE548DB1";
> +
> +static void decode_osc_bits(struct device *dev, char *msg, u32 word,
> +			    struct pci_osc_bit_struct *table, int size)
> +{
> +	char buf[80];
> +	int i, len = 0;
> +	struct pci_osc_bit_struct *entry;
> +
> +	buf[0] = '\0';
> +	for (i = 0, entry = table; i < size; i++, entry++)
> +		if (word & entry->bit)
> +			len += scnprintf(buf + len, sizeof(buf) - len, "%s%s",
> +					len ? " " : "", entry->desc);
> +
> +	dev_info(dev, "_OSC: %s [%s]\n", msg, buf);

Can we look at sharing code with PCI?

> +}
> +
> +static void decode_cxl_osc_support(struct device *dev, char *msg, u32 word)
> +{
> +	decode_osc_bits(dev, msg, word, cxl_osc_support_bit,
> +			ARRAY_SIZE(cxl_osc_support_bit));
> +}
> +
> +static void decode_cxl_osc_control(struct device *dev, char *msg, u32 word)
> +{
> +	decode_osc_bits(dev, msg, word, cxl_osc_control_bit,
> +			ARRAY_SIZE(cxl_osc_control_bit));
> +}
> +
> +static acpi_status acpi_cap_run_osc(acpi_handle handle,
> +				    const u32 *capbuf, u8 *uuid_str, u32 *retval)
> +{
> +	struct acpi_osc_context context = {
> +		.uuid_str = uuid_str,
> +		.rev = 1,
> +		.cap.length = 20,
> +		.cap.pointer = (void *)capbuf,
> +	};
> +	acpi_status status;
> +
> +	status = acpi_run_osc(handle, &context);
> +	if (ACPI_SUCCESS(status)) {
> +		*retval = *((u32 *)(context.ret.pointer + 8));
> +		kfree(context.ret.pointer);
> +	}
> +	return status;
> +}
> +
> +static acpi_status cxl_query_osc(acpi_handle handle, u32 support, u32 *control)
> +{
> +	acpi_status status;
> +	u32 result, capbuf[5];
> +
> +	support &= CXL_OSC_SUPPORT_VALID_MASK;
> +	support |= cxl_osc_support_set;
> +
> +	capbuf[OSC_QUERY_DWORD] = OSC_QUERY_ENABLE;
> +	capbuf[CXL_OSC_SUPPORT_DWORD] = support;
> +	if (control) {
> +		*control &= CXL_OSC_CONTROL_VALID_MASK;
> +		capbuf[CXL_OSC_CONTROL_DWORD] = *control | cxl_osc_control_set;
> +	} else {
> +		/* Run _OSC query only with existing controls. */
> +		capbuf[CXL_OSC_CONTROL_DWORD] = cxl_osc_control_set;
> +	}
> +
> +	status = acpi_cap_run_osc(handle, capbuf, cxl_osc_uuid_str, &result);
> +	if (ACPI_SUCCESS(status)) {
> +		cxl_osc_support_set = support;
> +		if (control)
> +			*control = result;
> +	}
> +	return status;
> +}
> +
> +static acpi_status cxl_osc_advertise_support(acpi_handle handle, u32 flags)
> +{
> +	acpi_status status;
> +
> +	mutex_lock(&acpi_desc_lock);
> +	status = cxl_query_osc(handle, flags, NULL);
> +	mutex_unlock(&acpi_desc_lock);
> +	return status;
> +}
> +
> +/**
> + * cxl_osc_request_control - Request control of CXL root _OSC features.
> + * @adev: ACPI device for the PCI root bridge (or PCIe Root Complex).
> + * @mask: Mask of _OSC bits to request control of, place to store control mask.
> + * @req: Mask of _OSC bits the control of is essential to the caller.
> + **/
> +static acpi_status cxl_osc_request_control(struct acpi_device *adev, u32 *mask, u32 req)
> +{
> +	acpi_handle handle = adev->handle;
> +	struct device *dev = &adev->dev;
> +	acpi_status status = AE_OK;
> +	u32 ctrl, capbuf[5];
> +
> +	if (!mask)
> +		return AE_BAD_PARAMETER;
> +
> +	ctrl = *mask & CXL_OSC_MEM_ERROR_CONTROL;
> +	if ((ctrl & req) != req)
> +		return AE_TYPE;
> +
> +	mutex_lock(&acpi_desc_lock);
> +
> +	*mask = ctrl | cxl_osc_control_set;
> +	/* No need to evaluate _OSC if the control was already granted. */
> +	if ((cxl_osc_control_set & ctrl) == ctrl)
> +		goto out;
> +
> +	/* Need to check the available controls bits before requesting them. */
> +	while (*mask) {
> +		status = cxl_query_osc(handle, cxl_osc_support_set, mask);
> +		if (ACPI_FAILURE(status))
> +			goto out;
> +		if (ctrl == *mask)
> +			break;
> +		decode_cxl_osc_control(dev, "platform does not support", ctrl & ~(*mask));
> +		ctrl = *mask;
> +	}
> +
> +	if ((ctrl & req) != req) {
> +		decode_cxl_osc_control(dev, "not requesting control; platform does not support",
> +				       req & ~(ctrl));
> +		status = AE_SUPPORT;
> +		goto out;
> +	}
> +
> +	capbuf[OSC_QUERY_DWORD] = 0;
> +	capbuf[CXL_OSC_SUPPORT_DWORD] = cxl_osc_support_set;
> +	capbuf[CXL_OSC_CONTROL_DWORD] = ctrl;
> +	status = acpi_cap_run_osc(handle, capbuf, cxl_osc_uuid_str, mask);
> +	if (ACPI_SUCCESS(status))
> +		cxl_osc_control_set = *mask;
> +out:
> +	mutex_unlock(&acpi_desc_lock);
> +	return status;
> +}
> +
> +static int cxl_negotiate_osc(struct acpi_device *adev)
> +{
> +	u32 cxl_support, cxl_control, requested;
> +	acpi_handle handle = adev->handle;
> +	struct device *dev = &adev->dev;
> +	acpi_status status;
> +
> +	/* Declare support for everything */
> +	cxl_support = CXL_OSC_SUPPORT_VALID_MASK;
> +	decode_cxl_osc_support(dev, "OS supports", cxl_support);
> +	status = cxl_osc_advertise_support(handle, cxl_support);
> +	if (ACPI_FAILURE(status)) {
> +		dev_info(dev, "CXL_OSC failed (%s)\n", acpi_format_exception(status));
> +		return -ENXIO;
> +	}
> +
> +	/* Request control for everything */
> +	cxl_control = CXL_OSC_CONTROL_VALID_MASK;
> +	requested = cxl_control;
> +	status = cxl_osc_request_control(adev, &cxl_control, CXL_OSC_MEM_ERROR_CONTROL);
> +	if (ACPI_SUCCESS(status)) {
> +		decode_cxl_osc_control(dev, "OS now controls", cxl_control);
> +	} else {
> +		decode_cxl_osc_control(dev, "OS requested", requested);
> +		decode_cxl_osc_control(dev, "platform willing to grant", cxl_control);
> +		dev_info(dev, "_OSC failed (%s)\n", acpi_format_exception(status));
> +	}
> +	return 0;
> +}
> +
>  /*
>   * If/when CXL support is defined by other platform firmware the kernel
>   * will need a mechanism to select between the platform specific version
> @@ -84,6 +287,7 @@ int cxl_bus_prepared(struct pci_dev *pdev)
>  	struct acpi_device *adev;
>  	struct pci_dev *root_port;
>  	struct device *root;
> +	int rc;
>  
>  	root_port = pcie_find_root_port(pdev);
>  	if (!root_port)
> @@ -97,9 +301,11 @@ int cxl_bus_prepared(struct pci_dev *pdev)
>  	if (!adev)
>  		return -ENXIO;
>  
> -	/* TODO: OSC enabling */
> +	rc = cxl_negotiate_osc(adev);
> +	if (rc)
> +		dev_err(&pdev->dev, "Failed to negotiate OSC\n");
>  
> -	return 0;
> +	return rc;
>  }
>  EXPORT_SYMBOL_GPL(cxl_bus_prepared);
>  
> diff --git a/drivers/cxl/acpi.h b/drivers/cxl/acpi.h
> index 011505475cc6..bf8d078e1b2a 100644
> --- a/drivers/cxl/acpi.h
> +++ b/drivers/cxl/acpi.h
> @@ -10,6 +10,24 @@ struct acpi_cxl_desc {
>  	struct device *dev;
>  };
>  
> +/* Indexes into _OSC Capabilities Buffer */
> +#define CXL_OSC_SUPPORT_DWORD			1	/* DWORD 2 */
> +#define CXL_OSC_CONTROL_DWORD			2	/* DWORD 3 */
> +
> +/* CXL Host Bridge _OSC: Capabilities DWORD 2: Support Field */
> +#define CXL_OSC_PORT_REG_ACCESS_SUPPORT		0x00000001
> +#define CXL_OSC_PORT_DEV_REG_ACCESS_SUPPORT	0x00000002
> +#define CXL_OSC_PER_SUPPORT			0x00000004
> +#define CXL_OSC_NATIVE_HP_SUPPORT		0x00000008
> +#define CXL_OSC_SUPPORT_VALID_MASK		(CXL_OSC_PORT_REG_ACCESS_SUPPORT |	\
> +						 CXL_OSC_PORT_DEV_REG_ACCESS_SUPPORT |	\
> +						 CXL_OSC_PER_SUPPORT |			\
> +						 CXL_OSC_NATIVE_HP_SUPPORT)
> +
> +/* CXL Host Bridge _OSC: Capabilities DWORD 3: Control Field */
> +#define CXL_OSC_MEM_ERROR_CONTROL		0x00000001
> +#define CXL_OSC_CONTROL_VALID_MASK		(CXL_OSC_MEM_ERROR_CONTROL)
> +
>  int cxl_bus_prepared(struct pci_dev *pci_dev);
>  
>  #endif	/* __CXL_ACPI_H__ */


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-11  5:43 ` [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect Ben Widawsky
                     ` (2 preceding siblings ...)
  2020-11-11 23:03   ` Bjorn Helgaas
@ 2020-11-16 17:59   ` Jonathan Cameron
  2020-11-16 18:23     ` Verma, Vishal L
  2020-11-17 14:32   ` Rafael J. Wysocki
  4 siblings, 1 reply; 73+ messages in thread
From: Jonathan Cameron @ 2020-11-16 17:59 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, 10 Nov 2020 21:43:48 -0800
Ben Widawsky <ben.widawsky@intel.com> wrote:

> From: Vishal Verma <vishal.l.verma@intel.com>
> 
> Add an acpi_cxl module to coordinate the ACPI portions of the CXL
> (Compute eXpress Link) interconnect. This driver binds to ACPI0017
> objects in the ACPI tree, and coordinates access to the resources
> provided by the ACPI CEDT (CXL Early Discovery Table).

I think the qemu series notes that this ACPI0017 is just a proposal at
this stage. Please make sure that's highlighted here as well unless
that status is out of date.

> 
> It also coordinates operations of the root port _OSC object to notify
> platform firmware that the OS has native support for the CXL
> capabilities of endpoints.
> 
> Note: the actbl1.h changes are speculative. The expectation is that they
> will arrive through the ACPICA tree in due time.
> 
> Cc: Ben Widawsky <ben.widawsky@intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> ---
>  drivers/Kconfig       |   1 +
>  drivers/Makefile      |   1 +
>  drivers/cxl/Kconfig   |  30 +++++++++++
>  drivers/cxl/Makefile  |   5 ++
>  drivers/cxl/acpi.c    | 119 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/cxl/acpi.h    |  15 ++++++
>  include/acpi/actbl1.h |  52 ++++++++++++++++++
>  7 files changed, 223 insertions(+)
>  create mode 100644 drivers/cxl/Kconfig
>  create mode 100644 drivers/cxl/Makefile
>  create mode 100644 drivers/cxl/acpi.c
>  create mode 100644 drivers/cxl/acpi.h
> 
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index dcecc9f6e33f..62c753a73651 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -6,6 +6,7 @@ menu "Device Drivers"
>  source "drivers/amba/Kconfig"
>  source "drivers/eisa/Kconfig"
>  source "drivers/pci/Kconfig"
> +source "drivers/cxl/Kconfig"
>  source "drivers/pcmcia/Kconfig"
>  source "drivers/rapidio/Kconfig"
>  
> diff --git a/drivers/Makefile b/drivers/Makefile
> index c0cd1b9075e3..5dad349de73b 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -73,6 +73,7 @@ obj-$(CONFIG_NVM)		+= lightnvm/
>  obj-y				+= base/ block/ misc/ mfd/ nfc/
>  obj-$(CONFIG_LIBNVDIMM)		+= nvdimm/
>  obj-$(CONFIG_DAX)		+= dax/
> +obj-$(CONFIG_CXL_BUS)		+= cxl/
>  obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/
>  obj-$(CONFIG_NUBUS)		+= nubus/
>  obj-y				+= macintosh/
> diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> new file mode 100644
> index 000000000000..dd724bd364df
> --- /dev/null
> +++ b/drivers/cxl/Kconfig
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +menuconfig CXL_BUS
> +	tristate "CXL (Compute Express Link) Devices Support"
> +	help
> +	  CXL is a bus that is electrically compatible with PCI-E, but layers
> +	  three protocols on that signalling (CXL.io, CXL.cache, and CXL.mem). The
> +	  CXL.cache protocol allows devices to hold cachelines locally, the
> +	  CXL.mem protocol allows devices to be fully coherent memory targets, the
> +	  CXL.io protocol is equivalent to PCI-E. Say 'y' to enable support for
> +	  the configuration and management of devices supporting these protocols.
> +
> +if CXL_BUS
> +
> +config CXL_BUS_PROVIDER
> +	tristate
> +
> +config CXL_ACPI
> +	tristate "CXL Platform Support"
> +	depends on ACPI
> +	default CXL_BUS
> +	select CXL_BUS_PROVIDER
> +	help
> +	  CXL Platform Support is a prerequisite for any CXL device driver that
> +	  wants to claim ownership of the component register space. By default
> +	  platform firmware assumes Linux is unaware of CXL capabilities and
> +	  requires explicit opt-in. This platform component also mediates
> +	  resources described by the CEDT (CXL Early Discovery Table)
> +
> +	  Say 'y' to enable CXL (Compute Express Link) drivers.
> +endif
> diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> new file mode 100644
> index 000000000000..d38cd34a2582
> --- /dev/null
> +++ b/drivers/cxl/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
> +
> +ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
> +cxl_acpi-y := acpi.o
> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> new file mode 100644
> index 000000000000..26e4f73838a7
> --- /dev/null
> +++ b/drivers/cxl/acpi.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright(c) 2020 Intel Corporation. All rights reserved.
> + */
> +#include <linux/list_sort.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/sysfs.h>
> +#include <linux/list.h>
> +#include <linux/acpi.h>
> +#include <linux/sort.h>
> +#include <linux/pci.h>
> +#include "acpi.h"
> +
> +static void acpi_cxl_desc_init(struct acpi_cxl_desc *acpi_desc, struct device *dev)
> +{
> +	dev_set_drvdata(dev, acpi_desc);

No need to have this wrapper + it hides the fact you are not just initialsing
the acpi_desc structure.

> +	acpi_desc->dev = dev;
> +}
> +
> +static void acpi_cedt_put_table(void *table)
> +{
> +	acpi_put_table(table);
> +}
> +
> +static int acpi_cxl_add(struct acpi_device *adev)
> +{
> +	struct acpi_cxl_desc *acpi_desc;
> +	struct device *dev = &adev->dev;
> +	struct acpi_table_header *tbl;
> +	acpi_status status = AE_OK;

Set below, so don't do it here.

> +	acpi_size sz;
> +	int rc = 0;

Set in paths in which it's used so don't do it here.

> +
> +	status = acpi_get_table(ACPI_SIG_CEDT, 0, &tbl);
> +	if (ACPI_FAILURE(status)) {
> +		dev_err(dev, "failed to find CEDT at startup\n");
> +		return 0;
> +	}
> +
> +	rc = devm_add_action_or_reset(dev, acpi_cedt_put_table, tbl);
> +	if (rc)
> +		return rc;

blank line here preferred for readability (do something, then check errors as
block)

> +	sz = tbl->length;
> +	dev_info(dev, "found CEDT at startup: %lld bytes\n", sz);
> +
> +	acpi_desc = devm_kzalloc(dev, sizeof(*acpi_desc), GFP_KERNEL);
> +	if (!acpi_desc)
> +		return -ENOMEM;

blank line here slightly helps readability.

> +	acpi_cxl_desc_init(acpi_desc, &adev->dev);
> +
> +	acpi_desc->acpi_header = *tbl;
> +
> +	return 0;
> +}
> +
> +static int acpi_cxl_remove(struct acpi_device *adev)
> +{
> +	return 0;

Don't think empty remove is needed.


> +}
> +
> +static const struct acpi_device_id acpi_cxl_ids[] = {
> +	{ "ACPI0017", 0 },
> +	{ "", 0 },
> +};
> +MODULE_DEVICE_TABLE(acpi, acpi_cxl_ids);
> +
> +static struct acpi_driver acpi_cxl_driver = {
> +	.name = KBUILD_MODNAME,
> +	.ids = acpi_cxl_ids,
> +	.ops = {
> +		.add = acpi_cxl_add,
> +		.remove = acpi_cxl_remove,
> +	},
> +};
> +
> +/*
> + * If/when CXL support is defined by other platform firmware the kernel
> + * will need a mechanism to select between the platform specific version
> + * of this routine, until then, hard-code ACPI assumptions
> + */
> +int cxl_bus_prepared(struct pci_dev *pdev)
> +{
> +	struct acpi_device *adev;
> +	struct pci_dev *root_port;
> +	struct device *root;
> +
> +	root_port = pcie_find_root_port(pdev);
> +	if (!root_port)
> +		return -ENXIO;
> +
> +	root = root_port->dev.parent;
> +	if (!root)
> +		return -ENXIO;
> +
> +	adev = ACPI_COMPANION(root);
> +	if (!adev)
> +		return -ENXIO;
> +
> +	/* TODO: OSC enabling */
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(cxl_bus_prepared);
> +
> +static __init int acpi_cxl_init(void)
> +{
> +	return acpi_bus_register_driver(&acpi_cxl_driver);
> +}
> +
> +static __exit void acpi_cxl_exit(void)
> +{
> +	acpi_bus_unregister_driver(&acpi_cxl_driver);
> +}
> +
> +module_init(acpi_cxl_init);
> +module_exit(acpi_cxl_exit);
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Intel Corporation");
> diff --git a/drivers/cxl/acpi.h b/drivers/cxl/acpi.h
> new file mode 100644
> index 000000000000..011505475cc6
> --- /dev/null
> +++ b/drivers/cxl/acpi.h
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> +
> +#ifndef __CXL_ACPI_H__
> +#define __CXL_ACPI_H__
> +#include <linux/acpi.h>
> +
> +struct acpi_cxl_desc {
> +	struct acpi_table_header acpi_header;
> +	struct device *dev;
> +};
> +
> +int cxl_bus_prepared(struct pci_dev *pci_dev);
> +
> +#endif	/* __CXL_ACPI_H__ */
> diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
> index 43549547ed3e..70f745f526e3 100644
> --- a/include/acpi/actbl1.h
> +++ b/include/acpi/actbl1.h
> @@ -28,6 +28,7 @@
>  #define ACPI_SIG_BERT           "BERT"	/* Boot Error Record Table */
>  #define ACPI_SIG_BGRT           "BGRT"	/* Boot Graphics Resource Table */
>  #define ACPI_SIG_BOOT           "BOOT"	/* Simple Boot Flag Table */
> +#define ACPI_SIG_CEDT           "CEDT"	/* CXL Early Discovery Table */
>  #define ACPI_SIG_CPEP           "CPEP"	/* Corrected Platform Error Polling table */
>  #define ACPI_SIG_CSRT           "CSRT"	/* Core System Resource Table */
>  #define ACPI_SIG_DBG2           "DBG2"	/* Debug Port table type 2 */
> @@ -1624,6 +1625,57 @@ struct acpi_ibft_target {
>  	u16 reverse_chap_secret_offset;
>  };
>  
> +/*******************************************************************************
> + *
> + * CEDT - CXL Early Discovery Table (ACPI 6.4)
> + *        Version 1
> + *
> + ******************************************************************************/
> +
> +struct acpi_table_cedt {
> +	struct acpi_table_header header;	/* Common ACPI table header */
> +	u32 reserved;
> +};
> +
> +/* Values for CEDT structure types */
> +
> +enum acpi_cedt_type {
> +	ACPI_CEDT_TYPE_HOST_BRIDGE = 0, /* CHBS - CXL Host Bridge Structure */
> +	ACPI_CEDT_TYPE_CFMWS = 1, 	/* CFMWS - CXL Fixed Memory Window Structure */

This isn't in the 2.0 spec, so I guess also part of some proposed changes.

> +};
> +
> +struct acpi_cedt_structure {
> +	u8 type;
> +	u8 reserved;
> +	u16 length;
> +};
> +
> +/*
> + * CEDT Structures, correspond to Type in struct acpi_cedt_structure
> + */
> +
> +/* 0: CXL Host Bridge Structure */
> +
> +struct acpi_cedt_chbs {
> +	struct acpi_cedt_structure header;
> +	u32 uid;
> +	u32 version;
> +	u32 reserved1;
> +	u64 base;
> +	u32 length;
> +	u32 reserved2;
> +};
> +
> +/* Values for version field above */
> +
> +#define ACPI_CEDT_CHBS_VERSION_CXL11    (0)
> +#define ACPI_CEDT_CHBS_VERSION_CXL20    (1)
> +
> +/* Values for length field above */
> +
> +#define ACPI_CEDT_CHBS_LENGTH_CXL11     (0x2000)
> +#define ACPI_CEDT_CHBS_LENGTH_CXL20     (0x10000)
> +
>  /* Reset to default packing */
>  
>  #pragma pack()


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-16 17:59   ` Jonathan Cameron
@ 2020-11-16 18:23     ` Verma, Vishal L
  0 siblings, 0 replies; 73+ messages in thread
From: Verma, Vishal L @ 2020-11-16 18:23 UTC (permalink / raw)
  To: Widawsky, Ben, Jonathan.Cameron
  Cc: Kelley, Sean V, Wysocki, Rafael J, linux-cxl, linux-kernel,
	Williams, Dan J, Weiny, Ira, linux-pci, bhelgaas, linux-acpi

On Mon, 2020-11-16 at 17:59 +0000, Jonathan Cameron wrote:
> On Tue, 10 Nov 2020 21:43:48 -0800
> Ben Widawsky <ben.widawsky@intel.com> wrote:
> 
> > From: Vishal Verma <vishal.l.verma@intel.com>
> > 
> > Add an acpi_cxl module to coordinate the ACPI portions of the CXL
> > (Compute eXpress Link) interconnect. This driver binds to ACPI0017
> > objects in the ACPI tree, and coordinates access to the resources
> > provided by the ACPI CEDT (CXL Early Discovery Table).
> 
> I think the qemu series notes that this ACPI0017 is just a proposal at
> this stage. Please make sure that's highlighted here as well unless
> that status is out of date.

Hi Jonathan,

Thank you for the review. The cover letter talks about this, but I agree
it would be worth repeating in this patch briefly as I did with the OSC
patch. If it is still in a proposal state by the next posting, I'll make
sure to add a note here too.

> 
> > +
> > +static void acpi_cxl_desc_init(struct acpi_cxl_desc *acpi_desc, struct device *dev)
> > +{
> > +	dev_set_drvdata(dev, acpi_desc);
> 
> No need to have this wrapper + it hides the fact you are not just initialsing
> the acpi_desc structure.
> 
> > +	acpi_desc->dev = dev;
> > +}
> > +
> > +static void acpi_cedt_put_table(void *table)
> > +{
> > +	acpi_put_table(table);
> > +}
> > +
> > +static int acpi_cxl_add(struct acpi_device *adev)
> > +{
> > +	struct acpi_cxl_desc *acpi_desc;
> > +	struct device *dev = &adev->dev;
> > +	struct acpi_table_header *tbl;
> > +	acpi_status status = AE_OK;
> 
> Set below, so don't do it here.
> 
> > +	acpi_size sz;
> > +	int rc = 0;
> 
> Set in paths in which it's used so don't do it here.
> 
> > +
> > +	status = acpi_get_table(ACPI_SIG_CEDT, 0, &tbl);
> > +	if (ACPI_FAILURE(status)) {
> > +		dev_err(dev, "failed to find CEDT at startup\n");
> > +		return 0;
> > +	}
> > +
> > +	rc = devm_add_action_or_reset(dev, acpi_cedt_put_table, tbl);
> > +	if (rc)
> > +		return rc;
> 
> blank line here preferred for readability (do something, then check errors as
> block)
> 
> > +	sz = tbl->length;
> > +	dev_info(dev, "found CEDT at startup: %lld bytes\n", sz);
> > +
> > +	acpi_desc = devm_kzalloc(dev, sizeof(*acpi_desc), GFP_KERNEL);
> > +	if (!acpi_desc)
> > +		return -ENOMEM;
> 
> blank line here slightly helps readability.
> 
> > +	acpi_cxl_desc_init(acpi_desc, &adev->dev);
> > +
> > +	acpi_desc->acpi_header = *tbl;
> > +
> > +	return 0;
> > +}
> > +
> > +static int acpi_cxl_remove(struct acpi_device *adev)
> > +{
> > +	return 0;
> 
> Don't think empty remove is needed.
> 

Agreed with all of the above, I'll fix for the next posting.

> > +
> > +/* Values for CEDT structure types */
> > +
> > +enum acpi_cedt_type {
> > +	ACPI_CEDT_TYPE_HOST_BRIDGE = 0, /* CHBS - CXL Host Bridge Structure */
> > +	ACPI_CEDT_TYPE_CFMWS = 1, 	/* CFMWS - CXL Fixed Memory Window Structure */
> 
> This isn't in the 2.0 spec, so I guess also part of some proposed changes.

Yes this got in accidentally, will remove.



^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers
  2020-11-14  1:12     ` Ben Widawsky
@ 2020-11-16 23:19       ` Dan Williams
  2020-11-17  0:23         ` Bjorn Helgaas
  0 siblings, 1 reply; 73+ messages in thread
From: Dan Williams @ 2020-11-16 23:19 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Bjorn Helgaas, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Fri, Nov 13, 2020 at 5:12 PM Ben Widawsky <ben.widawsky@intel.com> wrote:
>
> On 20-11-13 12:17:32, Bjorn Helgaas wrote:
> > On Tue, Nov 10, 2020 at 09:43:51PM -0800, Ben Widawsky wrote:
> > > All the necessary bits are initialized in order to find and map the
> > > register space for CXL Memory Devices. This is accomplished by using the
> > > Register Locator DVSEC (CXL 2.0 - 8.1.9.1) to determine which PCI BAR to
> > > use, and how much of an offset from that BAR should be added.
> >
> > "Initialize the necessary bits ..." to use the usual imperative
> > sentence structure, as you did in the subject.
> >
> > > If the memory device registers are found and mapped a new internal data
> > > structure tracking device state is allocated.
> >
> > "Allocate device state if we find device registers" or similar.
> >
> > > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > > ---
> > >  drivers/cxl/mem.c | 68 +++++++++++++++++++++++++++++++++++++++++++----
> > >  drivers/cxl/pci.h |  6 +++++
> > >  2 files changed, 69 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > > index aa7d881fa47b..8d9b9ab6c5ea 100644
> > > --- a/drivers/cxl/mem.c
> > > +++ b/drivers/cxl/mem.c
> > > @@ -7,9 +7,49 @@
> > >  #include "pci.h"
> > >
> > >  struct cxl_mem {
> > > +   struct pci_dev *pdev;
> > >     void __iomem *regs;
> > >  };
> > >
> > > +static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo, u32 reg_hi)
> > > +{
> > > +   struct device *dev = &pdev->dev;
> > > +   struct cxl_mem *cxlm;
> > > +   void __iomem *regs;
> > > +   u64 offset;
> > > +   u8 bar;
> > > +   int rc;
> > > +
> > > +   offset = ((u64)reg_hi << 32) | (reg_lo & 0xffff0000);
> > > +   bar = reg_lo & 0x7;
> > > +
> > > +   /* Basic sanity check that BAR is big enough */
> > > +   if (pci_resource_len(pdev, bar) < offset) {
> > > +           dev_err(dev, "bar%d: %pr: too small (offset: %#llx)\n",
> > > +                           bar, &pdev->resource[bar], (unsigned long long) offset);
> >
> > s/bar/BAR/
> >
> > > +           return ERR_PTR(-ENXIO);
> > > +   }
> > > +
> > > +   rc = pcim_iomap_regions(pdev, 1 << bar, pci_name(pdev));
> > > +   if (rc != 0) {
> > > +           dev_err(dev, "failed to map registers\n");
> > > +           return ERR_PTR(-ENXIO);
> > > +   }
> > > +
> > > +   cxlm = devm_kzalloc(&pdev->dev, sizeof(*cxlm), GFP_KERNEL);
> > > +   if (!cxlm) {
> > > +           dev_err(dev, "No memory available\n");
> > > +           return ERR_PTR(-ENOMEM);
> > > +   }
> > > +
> > > +   regs = pcim_iomap_table(pdev)[bar];
> > > +   cxlm->pdev = pdev;
> > > +   cxlm->regs = regs + offset;
> > > +
> > > +   dev_dbg(dev, "Mapped CXL Memory Device resource\n");
> > > +   return cxlm;
> > > +}
> > > +
> > >  static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> > >  {
> > >     int pos;
> > > @@ -34,9 +74,9 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> > >
> > >  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > >  {
> > > +   struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
> > >     struct device *dev = &pdev->dev;
> > > -   struct cxl_mem *cxlm;
> >
> > The order was better before ("dev", then "clxm").  Oh, I suppose this
> > is a "reverse Christmas tree" thing.
> >
>
> I don't actually care either way as long as it's consistent. I tend to do
> reverse Christmas tree for no particular reason.

Yeah, reverse Christmas tree for no particular reason.

>
> > > -   int rc, regloc;
> > > +   int rc, regloc, i;
> > >
> > >     rc = cxl_bus_prepared(pdev);
> > >     if (rc != 0) {
> > > @@ -44,15 +84,33 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > >             return rc;
> > >     }
> > >
> > > +   rc = pcim_enable_device(pdev);
> > > +   if (rc)
> > > +           return rc;
> > > +
> > >     regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
> > >     if (!regloc) {
> > >             dev_err(dev, "register location dvsec not found\n");
> > >             return -ENXIO;
> > >     }
> > > +   regloc += 0xc; /* Skip DVSEC + reserved fields */
> > > +
> > > +   for (i = regloc; i < regloc + 0x24; i += 8) {
> > > +           u32 reg_lo, reg_hi;
> > > +
> > > +           pci_read_config_dword(pdev, i, &reg_lo);
> > > +           pci_read_config_dword(pdev, i + 4, &reg_hi);
> > > +
> > > +           if (CXL_REGLOG_IS_MEMDEV(reg_lo)) {
> > > +                   cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
> > > +                   break;
> > > +           }
> > > +   }
> > > +
> > > +   if (IS_ERR(cxlm))
> > > +           return -ENXIO;
> >
> > I think this would be easier to read if cxl_mem_create() returned NULL
> > on failure (it prints error messages and we throw away
> > -ENXIO/-ENOMEM distinction here anyway) so you could do:
> >
> >   struct cxl_mem *cxlm = NULL;
> >
> >   for (...) {
> >     if (...) {
> >       cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
> >       break;
> >     }
> >   }
> >
> >   if (!cxlm)
> >     return -ENXIO;  /* -ENODEV might be more natural? */
> >
>
> I agree on both counts. Both of these came from Dan, so I will let him explain.

I'm not attached to differentiating -ENOMEM from -ENXIO and am ok to
drop the ERR_PTR() return. I do tend to use -ENXIO for failure to
perform an initialization action vs failure to even find the device,
but if -ENODEV seems more idiomatic to Bjorn, I won't argue.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 2/9] cxl/acpi: add OSC support
  2020-11-16 17:59   ` Jonathan Cameron
@ 2020-11-16 23:25     ` Dan Williams
  2020-11-18 12:25       ` Rafael J. Wysocki
  0 siblings, 1 reply; 73+ messages in thread
From: Dan Williams @ 2020-11-16 23:25 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Mon, Nov 16, 2020 at 10:00 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Tue, 10 Nov 2020 21:43:49 -0800
> Ben Widawsky <ben.widawsky@intel.com> wrote:
>
> > From: Vishal Verma <vishal.l.verma@intel.com>
> >
> > Add support to advertise OS capabilities, and request OS control for CXL
> > features using the ACPI _OSC mechanism. Advertise support for all
> > possible CXL features, and attempt to request control too for all
> > possible features.
> >
> > Based on a patch by Sean Kelley.
> >
> > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
>
> I guess unsurprisingly a lot of this is cut and paste from PCIe
> so can we share some of the code?
>

I do not see a refactoring effort for these bit being all that
fruitful. The backport pressure for this driver stack I expect will be
higher than most, so I'm sensitive to avoiding unnecessary core
entanglements.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers
  2020-11-16 23:19       ` Dan Williams
@ 2020-11-17  0:23         ` Bjorn Helgaas
  2020-11-23 19:20           ` Ben Widawsky
  0 siblings, 1 reply; 73+ messages in thread
From: Bjorn Helgaas @ 2020-11-17  0:23 UTC (permalink / raw)
  To: Dan Williams
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Mon, Nov 16, 2020 at 03:19:41PM -0800, Dan Williams wrote:
> On Fri, Nov 13, 2020 at 5:12 PM Ben Widawsky <ben.widawsky@intel.com> wrote:
> > On 20-11-13 12:17:32, Bjorn Helgaas wrote:
> > > On Tue, Nov 10, 2020 at 09:43:51PM -0800, Ben Widawsky wrote:

> > > >  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > > >  {
> > > > +   struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
> > > >     struct device *dev = &pdev->dev;
> > > > -   struct cxl_mem *cxlm;
> > >
> > > The order was better before ("dev", then "clxm").  Oh, I suppose this
> > > is a "reverse Christmas tree" thing.
> > >
> >
> > I don't actually care either way as long as it's consistent. I tend to do
> > reverse Christmas tree for no particular reason.
> 
> Yeah, reverse Christmas tree for no particular reason.

FWIW, the usual drivers/pci style is to order the decls in the order
the variables are used in the code.  But this isn't drivers/pci, so
it's up to you.  I only noticed because changing the order made the
diff bigger than it needed to be.

> > > I think this would be easier to read if cxl_mem_create() returned NULL
> > > on failure (it prints error messages and we throw away
> > > -ENXIO/-ENOMEM distinction here anyway) so you could do:
> > >
> > >   struct cxl_mem *cxlm = NULL;
> > >
> > >   for (...) {
> > >     if (...) {
> > >       cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
> > >       break;
> > >     }
> > >   }
> > >
> > >   if (!cxlm)
> > >     return -ENXIO;  /* -ENODEV might be more natural? */
> > >
> >
> > I agree on both counts. Both of these came from Dan, so I will let him explain.
> 
> I'm not attached to differentiating -ENOMEM from -ENXIO and am ok to
> drop the ERR_PTR() return. I do tend to use -ENXIO for failure to
> perform an initialization action vs failure to even find the device,
> but if -ENODEV seems more idiomatic to Bjorn, I won't argue.

-ENXIO is fine with me.  I just don't see it as often so I don't
really know what it is.

Bjorn

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-11  5:43 ` [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect Ben Widawsky
                     ` (3 preceding siblings ...)
  2020-11-16 17:59   ` Jonathan Cameron
@ 2020-11-17 14:32   ` Rafael J. Wysocki
  2020-11-17 21:45     ` Dan Williams
  4 siblings, 1 reply; 73+ messages in thread
From: Rafael J. Wysocki @ 2020-11-17 14:32 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, Linux Kernel Mailing List, Linux PCI,
	ACPI Devel Maling List, Dan Williams, Ira Weiny, Vishal Verma,
	Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki

On Wed, Nov 11, 2020 at 6:45 AM Ben Widawsky <ben.widawsky@intel.com> wrote:
>
> From: Vishal Verma <vishal.l.verma@intel.com>
>
> Add an acpi_cxl module to coordinate the ACPI portions of the CXL
> (Compute eXpress Link) interconnect. This driver binds to ACPI0017
> objects in the ACPI tree, and coordinates access to the resources
> provided by the ACPI CEDT (CXL Early Discovery Table).
>
> It also coordinates operations of the root port _OSC object to notify
> platform firmware that the OS has native support for the CXL
> capabilities of endpoints.
>
> Note: the actbl1.h changes are speculative. The expectation is that they
> will arrive through the ACPICA tree in due time.
>
> Cc: Ben Widawsky <ben.widawsky@intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> ---
>  drivers/Kconfig       |   1 +
>  drivers/Makefile      |   1 +
>  drivers/cxl/Kconfig   |  30 +++++++++++
>  drivers/cxl/Makefile  |   5 ++
>  drivers/cxl/acpi.c    | 119 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/cxl/acpi.h    |  15 ++++++
>  include/acpi/actbl1.h |  52 ++++++++++++++++++
>  7 files changed, 223 insertions(+)
>  create mode 100644 drivers/cxl/Kconfig
>  create mode 100644 drivers/cxl/Makefile
>  create mode 100644 drivers/cxl/acpi.c
>  create mode 100644 drivers/cxl/acpi.h
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index dcecc9f6e33f..62c753a73651 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -6,6 +6,7 @@ menu "Device Drivers"
>  source "drivers/amba/Kconfig"
>  source "drivers/eisa/Kconfig"
>  source "drivers/pci/Kconfig"
> +source "drivers/cxl/Kconfig"
>  source "drivers/pcmcia/Kconfig"
>  source "drivers/rapidio/Kconfig"
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index c0cd1b9075e3..5dad349de73b 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -73,6 +73,7 @@ obj-$(CONFIG_NVM)             += lightnvm/
>  obj-y                          += base/ block/ misc/ mfd/ nfc/
>  obj-$(CONFIG_LIBNVDIMM)                += nvdimm/
>  obj-$(CONFIG_DAX)              += dax/
> +obj-$(CONFIG_CXL_BUS)          += cxl/
>  obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/
>  obj-$(CONFIG_NUBUS)            += nubus/
>  obj-y                          += macintosh/
> diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> new file mode 100644
> index 000000000000..dd724bd364df
> --- /dev/null
> +++ b/drivers/cxl/Kconfig
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +menuconfig CXL_BUS
> +       tristate "CXL (Compute Express Link) Devices Support"
> +       help
> +         CXL is a bus that is electrically compatible with PCI-E, but layers
> +         three protocols on that signalling (CXL.io, CXL.cache, and CXL.mem). The
> +         CXL.cache protocol allows devices to hold cachelines locally, the
> +         CXL.mem protocol allows devices to be fully coherent memory targets, the
> +         CXL.io protocol is equivalent to PCI-E. Say 'y' to enable support for
> +         the configuration and management of devices supporting these protocols.
> +
> +if CXL_BUS
> +
> +config CXL_BUS_PROVIDER
> +       tristate
> +
> +config CXL_ACPI
> +       tristate "CXL Platform Support"
> +       depends on ACPI
> +       default CXL_BUS
> +       select CXL_BUS_PROVIDER
> +       help
> +         CXL Platform Support is a prerequisite for any CXL device driver that
> +         wants to claim ownership of the component register space. By default
> +         platform firmware assumes Linux is unaware of CXL capabilities and
> +         requires explicit opt-in. This platform component also mediates
> +         resources described by the CEDT (CXL Early Discovery Table)
> +
> +         Say 'y' to enable CXL (Compute Express Link) drivers.
> +endif
> diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> new file mode 100644
> index 000000000000..d38cd34a2582
> --- /dev/null
> +++ b/drivers/cxl/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
> +
> +ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
> +cxl_acpi-y := acpi.o
> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> new file mode 100644
> index 000000000000..26e4f73838a7
> --- /dev/null
> +++ b/drivers/cxl/acpi.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright(c) 2020 Intel Corporation. All rights reserved.
> + */
> +#include <linux/list_sort.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/sysfs.h>
> +#include <linux/list.h>
> +#include <linux/acpi.h>
> +#include <linux/sort.h>
> +#include <linux/pci.h>
> +#include "acpi.h"
> +
> +static void acpi_cxl_desc_init(struct acpi_cxl_desc *acpi_desc, struct device *dev)
> +{
> +       dev_set_drvdata(dev, acpi_desc);
> +       acpi_desc->dev = dev;
> +}
> +
> +static void acpi_cedt_put_table(void *table)
> +{
> +       acpi_put_table(table);
> +}
> +
> +static int acpi_cxl_add(struct acpi_device *adev)
> +{
> +       struct acpi_cxl_desc *acpi_desc;
> +       struct device *dev = &adev->dev;
> +       struct acpi_table_header *tbl;
> +       acpi_status status = AE_OK;
> +       acpi_size sz;
> +       int rc = 0;
> +
> +       status = acpi_get_table(ACPI_SIG_CEDT, 0, &tbl);
> +       if (ACPI_FAILURE(status)) {
> +               dev_err(dev, "failed to find CEDT at startup\n");
> +               return 0;
> +       }
> +
> +       rc = devm_add_action_or_reset(dev, acpi_cedt_put_table, tbl);
> +       if (rc)
> +               return rc;
> +       sz = tbl->length;
> +       dev_info(dev, "found CEDT at startup: %lld bytes\n", sz);
> +
> +       acpi_desc = devm_kzalloc(dev, sizeof(*acpi_desc), GFP_KERNEL);
> +       if (!acpi_desc)
> +               return -ENOMEM;
> +       acpi_cxl_desc_init(acpi_desc, &adev->dev);
> +
> +       acpi_desc->acpi_header = *tbl;
> +
> +       return 0;
> +}
> +
> +static int acpi_cxl_remove(struct acpi_device *adev)
> +{
> +       return 0;
> +}
> +
> +static const struct acpi_device_id acpi_cxl_ids[] = {
> +       { "ACPI0017", 0 },
> +       { "", 0 },
> +};
> +MODULE_DEVICE_TABLE(acpi, acpi_cxl_ids);
> +
> +static struct acpi_driver acpi_cxl_driver = {

First of all, no new acpi_driver instances, pretty please!

acpi_default_enumeration() should create a platform device with the
ACPI0017 ID for you.  Can't you provide a driver for this one?

> +       .name = KBUILD_MODNAME,
> +       .ids = acpi_cxl_ids,
> +       .ops = {
> +               .add = acpi_cxl_add,
> +               .remove = acpi_cxl_remove,
> +       },
> +};
> +
> +/*
> + * If/when CXL support is defined by other platform firmware the kernel
> + * will need a mechanism to select between the platform specific version
> + * of this routine, until then, hard-code ACPI assumptions
> + */
> +int cxl_bus_prepared(struct pci_dev *pdev)
> +{
> +       struct acpi_device *adev;
> +       struct pci_dev *root_port;
> +       struct device *root;
> +
> +       root_port = pcie_find_root_port(pdev);
> +       if (!root_port)
> +               return -ENXIO;
> +
> +       root = root_port->dev.parent;
> +       if (!root)
> +               return -ENXIO;
> +
> +       adev = ACPI_COMPANION(root);
> +       if (!adev)
> +               return -ENXIO;
> +
> +       /* TODO: OSC enabling */
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(cxl_bus_prepared);
> +
> +static __init int acpi_cxl_init(void)
> +{
> +       return acpi_bus_register_driver(&acpi_cxl_driver);
> +}
> +
> +static __exit void acpi_cxl_exit(void)
> +{
> +       acpi_bus_unregister_driver(&acpi_cxl_driver);
> +}
> +
> +module_init(acpi_cxl_init);
> +module_exit(acpi_cxl_exit);
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Intel Corporation");
> diff --git a/drivers/cxl/acpi.h b/drivers/cxl/acpi.h
> new file mode 100644
> index 000000000000..011505475cc6
> --- /dev/null
> +++ b/drivers/cxl/acpi.h
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> +
> +#ifndef __CXL_ACPI_H__
> +#define __CXL_ACPI_H__
> +#include <linux/acpi.h>
> +
> +struct acpi_cxl_desc {
> +       struct acpi_table_header acpi_header;
> +       struct device *dev;
> +};
> +
> +int cxl_bus_prepared(struct pci_dev *pci_dev);
> +
> +#endif /* __CXL_ACPI_H__ */
> diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
> index 43549547ed3e..70f745f526e3 100644
> --- a/include/acpi/actbl1.h
> +++ b/include/acpi/actbl1.h
> @@ -28,6 +28,7 @@
>  #define ACPI_SIG_BERT           "BERT" /* Boot Error Record Table */
>  #define ACPI_SIG_BGRT           "BGRT" /* Boot Graphics Resource Table */
>  #define ACPI_SIG_BOOT           "BOOT" /* Simple Boot Flag Table */
> +#define ACPI_SIG_CEDT           "CEDT" /* CXL Early Discovery Table */
>  #define ACPI_SIG_CPEP           "CPEP" /* Corrected Platform Error Polling table */
>  #define ACPI_SIG_CSRT           "CSRT" /* Core System Resource Table */
>  #define ACPI_SIG_DBG2           "DBG2" /* Debug Port table type 2 */
> @@ -1624,6 +1625,57 @@ struct acpi_ibft_target {
>         u16 reverse_chap_secret_offset;
>  };
>
> +/*******************************************************************************
> + *
> + * CEDT - CXL Early Discovery Table (ACPI 6.4)
> + *        Version 1
> + *
> + ******************************************************************************/
> +
> +struct acpi_table_cedt {
> +       struct acpi_table_header header;        /* Common ACPI table header */
> +       u32 reserved;
> +};
> +
> +/* Values for CEDT structure types */
> +
> +enum acpi_cedt_type {
> +       ACPI_CEDT_TYPE_HOST_BRIDGE = 0, /* CHBS - CXL Host Bridge Structure */
> +       ACPI_CEDT_TYPE_CFMWS = 1,       /* CFMWS - CXL Fixed Memory Window Structure */
> +};
> +
> +struct acpi_cedt_structure {
> +       u8 type;
> +       u8 reserved;
> +       u16 length;
> +};
> +
> +/*
> + * CEDT Structures, correspond to Type in struct acpi_cedt_structure
> + */
> +
> +/* 0: CXL Host Bridge Structure */
> +
> +struct acpi_cedt_chbs {
> +       struct acpi_cedt_structure header;
> +       u32 uid;
> +       u32 version;
> +       u32 reserved1;
> +       u64 base;
> +       u32 length;
> +       u32 reserved2;
> +};
> +
> +/* Values for version field above */
> +
> +#define ACPI_CEDT_CHBS_VERSION_CXL11    (0)
> +#define ACPI_CEDT_CHBS_VERSION_CXL20    (1)
> +
> +/* Values for length field above */
> +
> +#define ACPI_CEDT_CHBS_LENGTH_CXL11     (0x2000)
> +#define ACPI_CEDT_CHBS_LENGTH_CXL20     (0x10000)
> +
>  /* Reset to default packing */
>
>  #pragma pack()
> --
> 2.29.2
>

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-11  5:43 ` [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox Ben Widawsky
                     ` (2 preceding siblings ...)
  2020-11-13 18:17   ` Bjorn Helgaas
@ 2020-11-17 14:49   ` Jonathan Cameron
  2020-12-04  7:22     ` Dan Williams
  3 siblings, 1 reply; 73+ messages in thread
From: Jonathan Cameron @ 2020-11-17 14:49 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, 10 Nov 2020 21:43:50 -0800
Ben Widawsky <ben.widawsky@intel.com> wrote:

> From: Dan Williams <dan.j.williams@intel.com>
> 
> The CXL.mem protocol allows a device to act as a provider of "System
> RAM" and/or "Persistent Memory" that is fully coherent as if the memory
> was attached to the typical CPU memory controller.
> 
> The memory range exported by the device may optionally be described by
> the platform firmware memory map, or by infrastructure like LIBNVDIMM to
> provision persistent memory capacity from one, or more, CXL.mem devices.
> 
> A pre-requisite for Linux-managed memory-capacity provisioning is this
> cxl_mem driver that can speak the "type-3 mailbox" protocol.
> 
> For now just land the driver boiler-plate and fill it in with
> functionality in subsequent commits.
> 
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>

I've tried to avoid repeats, so mostly this is me moaning about naming!

Jonathan

> ---
>  drivers/cxl/Kconfig  | 20 +++++++++++
>  drivers/cxl/Makefile |  2 ++
>  drivers/cxl/mem.c    | 82 ++++++++++++++++++++++++++++++++++++++++++++
>  drivers/cxl/pci.h    | 15 ++++++++
>  4 files changed, 119 insertions(+)
>  create mode 100644 drivers/cxl/mem.c
>  create mode 100644 drivers/cxl/pci.h
> 
> diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> index dd724bd364df..15548f5c77ff 100644
> --- a/drivers/cxl/Kconfig
> +++ b/drivers/cxl/Kconfig
> @@ -27,4 +27,24 @@ config CXL_ACPI
>  	  resources described by the CEDT (CXL Early Discovery Table)
>  
>  	  Say 'y' to enable CXL (Compute Express Link) drivers.
> +
> +config CXL_MEM
> +        tristate "CXL.mem Device Support"
> +        depends on PCI && CXL_BUS_PROVIDER != n
> +        default m if CXL_BUS_PROVIDER
> +        help
> +          The CXL.mem protocol allows a device to act as a provider of
> +          "System RAM" and/or "Persistent Memory" that is fully coherent
> +          as if the memory was attached to the typical CPU memory
> +          controller.
> +
> +          Say 'y/m' to enable a driver named "cxl_mem.ko" that will attach
> +          to CXL.mem devices for configuration, provisioning, and health
> +          monitoring, the so called "type-3 mailbox". Note, this driver
> +          is required for dynamic provisioning of CXL.mem attached
> +          memory, a pre-requisite for persistent memory support, but
> +          devices that provide volatile memory may be fully described by
> +          existing platform firmware memory enumeration.
> +
> +          If unsure say 'n'.
>  endif
> diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> index d38cd34a2582..97fdffb00f2d 100644
> --- a/drivers/cxl/Makefile
> +++ b/drivers/cxl/Makefile
> @@ -1,5 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
> +obj-$(CONFIG_CXL_MEM) += cxl_mem.o
>  
>  ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
>  cxl_acpi-y := acpi.o
> +cxl_mem-y := mem.o
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> new file mode 100644
> index 000000000000..aa7d881fa47b
> --- /dev/null
> +++ b/drivers/cxl/mem.c
> @@ -0,0 +1,82 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/io.h>
> +#include "acpi.h"
> +#include "pci.h"
> +
> +struct cxl_mem {
> +	void __iomem *regs;
> +};
> +
> +static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> +{
> +	int pos;
> +
> +	pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DVSEC);
> +	if (!pos)
> +		return 0;
> +
> +	while (pos) {
> +		u16 vendor, id;
> +
> +		pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, &vendor);
> +		pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, &id);
> +		if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> +			return pos;
> +
> +		pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);

This is good generic code and wouldn't cause much backport effort (even if needed
to bring in a local copy), so perhaps make it a generic function and move to
core PCI code?

Mind you I guess that can happen the 'second' time someone wants to find a DVSEC.

> +	}
> +
> +	return 0;
> +}
> +
> +static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct cxl_mem *cxlm;
> +	int rc, regloc;
> +
> +	rc = cxl_bus_prepared(pdev);
> +	if (rc != 0) {
> +		dev_err(dev, "failed to acquire interface\n");
> +		return rc;
> +	}
> +
> +	regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
> +	if (!regloc) {
> +		dev_err(dev, "register location dvsec not found\n");
> +		return -ENXIO;
> +	}
> +
> +	cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> +	if (!cxlm)
> +		return -ENOMEM;
> +
> +	return 0;
> +}
> +
> +static void cxl_mem_remove(struct pci_dev *pdev)
> +{
> +}

I'd bring this in only when needed in later patch.

> +
> +static const struct pci_device_id cxl_mem_pci_tbl[] = {
> +	/* PCI class code for CXL.mem Type-3 Devices */
> +	{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> +	  PCI_CLASS_MEMORY_CXL, 0xffffff, 0 },
> +	{ /* terminate list */ },
> +};
> +MODULE_DEVICE_TABLE(pci, cxl_mem_pci_tbl);
> +
> +static struct pci_driver cxl_mem_driver = {
> +	.name			= KBUILD_MODNAME,
> +	.id_table		= cxl_mem_pci_tbl,
> +	.probe			= cxl_mem_probe,
> +	.remove			= cxl_mem_remove,
> +};
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Intel Corporation");
> +module_pci_driver(cxl_mem_driver);
> +MODULE_IMPORT_NS(CXL);
> diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> new file mode 100644
> index 000000000000..beb03921e6da
> --- /dev/null
> +++ b/drivers/cxl/pci.h
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> +#ifndef __CXL_PCI_H__
> +#define __CXL_PCI_H__
> +
> +#define PCI_CLASS_MEMORY_CXL	0x050210
> +
> +#define PCI_EXT_CAP_ID_DVSEC	0x23
> +#define PCI_DVSEC_VENDOR_CXL	0x1E98

Hmm. The magic question of what to call a vendor ID that isn't a vendor
ID but just a magic number that talks like a duck and quacks like a duck
(for anyone wondering what I'm talking about, there is a nice bit of legal
boilerplate on this in the CXL spec)

This name is definitely not accurate however.

PCI_UNIQUE_VALUE_CXL maybe?  It is used for other things than DVSEC (VDMs etc),
though possibly this is the only software visible use.


> +#define PCI_DVSEC_VENDOR_OFFSET	0x4
> +#define PCI_DVSEC_ID_OFFSET	0x8

Put a line break here perhaps and maybe a spec reference to where to find
the various DVSEC IDs.

> +#define PCI_DVSEC_ID_CXL	0x0

That's definitely a confusing name as well.

PCI_DEVSEC_ID_CXL_DEVICE maybe?


> +#define PCI_DVSEC_ID_CXL_REGLOC	0x8
> +
> +#endif /* __CXL_PCI_H__ */


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers
  2020-11-11  5:43 ` [RFC PATCH 4/9] cxl/mem: Map memory device registers Ben Widawsky
  2020-11-13 18:17   ` Bjorn Helgaas
@ 2020-11-17 15:00   ` Jonathan Cameron
  1 sibling, 0 replies; 73+ messages in thread
From: Jonathan Cameron @ 2020-11-17 15:00 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, 10 Nov 2020 21:43:51 -0800
Ben Widawsky <ben.widawsky@intel.com> wrote:

> All the necessary bits are initialized in order to find and map the
> register space for CXL Memory Devices. This is accomplished by using the
> Register Locator DVSEC (CXL 2.0 - 8.1.9.1) to determine which PCI BAR to
> use, and how much of an offset from that BAR should be added.
> 
> If the memory device registers are found and mapped a new internal data
> structure tracking device state is allocated.
> 
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> ---
>  drivers/cxl/mem.c | 68 +++++++++++++++++++++++++++++++++++++++++++----
>  drivers/cxl/pci.h |  6 +++++
>  2 files changed, 69 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index aa7d881fa47b..8d9b9ab6c5ea 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -7,9 +7,49 @@
>  #include "pci.h"
>  
>  struct cxl_mem {
> +	struct pci_dev *pdev;
>  	void __iomem *regs;
>  };
>  
> +static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo, u32 reg_hi)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct cxl_mem *cxlm;
> +	void __iomem *regs;
> +	u64 offset;
> +	u8 bar;
> +	int rc;
> +
> +	offset = ((u64)reg_hi << 32) | (reg_lo & 0xffff0000);
> +	bar = reg_lo & 0x7;
> +
> +	/* Basic sanity check that BAR is big enough */
> +	if (pci_resource_len(pdev, bar) < offset) {
> +		dev_err(dev, "bar%d: %pr: too small (offset: %#llx)\n",
> +				bar, &pdev->resource[bar], (unsigned long long) offset);
> +		return ERR_PTR(-ENXIO);
> +	}
> +
> +	rc = pcim_iomap_regions(pdev, 1 << bar, pci_name(pdev));
> +	if (rc != 0) {
> +		dev_err(dev, "failed to map registers\n");
> +		return ERR_PTR(-ENXIO);
> +	}
> +
> +	cxlm = devm_kzalloc(&pdev->dev, sizeof(*cxlm), GFP_KERNEL);
> +	if (!cxlm) {
> +		dev_err(dev, "No memory available\n");
> +		return ERR_PTR(-ENOMEM);
> +	}
> +
> +	regs = pcim_iomap_table(pdev)[bar];
> +	cxlm->pdev = pdev;
> +	cxlm->regs = regs + offset;
> +
> +	dev_dbg(dev, "Mapped CXL Memory Device resource\n");
> +	return cxlm;
> +}
> +
>  static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
>  {
>  	int pos;
> @@ -34,9 +74,9 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
>  
>  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  {
> +	struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
>  	struct device *dev = &pdev->dev;
> -	struct cxl_mem *cxlm;
> -	int rc, regloc;
> +	int rc, regloc, i;
>  
>  	rc = cxl_bus_prepared(pdev);
>  	if (rc != 0) {
> @@ -44,15 +84,33 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  		return rc;
>  	}
>  
> +	rc = pcim_enable_device(pdev);
> +	if (rc)
> +		return rc;
> +
>  	regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
>  	if (!regloc) {
>  		dev_err(dev, "register location dvsec not found\n");
>  		return -ENXIO;
>  	}
> +	regloc += 0xc; /* Skip DVSEC + reserved fields */
> +
> +	for (i = regloc; i < regloc + 0x24; i += 8) {
> +		u32 reg_lo, reg_hi;

Hmm. That "register offset low" naming in the spec is just designed to confuse
given lots of other things packed in the register.
Perhaps a comment here to say it contains other information?
Also possibly some docs for cxl_mem_create to make the same point there.

> +
> +		pci_read_config_dword(pdev, i, &reg_lo);
> +		pci_read_config_dword(pdev, i + 4, &reg_hi);
> +
> +		if (CXL_REGLOG_IS_MEMDEV(reg_lo)) {
> +			cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
> +			break;
> +		}
> +	}
> +
> +	if (IS_ERR(cxlm))
> +		return -ENXIO;
>  
> -	cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> -	if (!cxlm)
> -		return -ENOMEM;
> +	pci_set_drvdata(pdev, cxlm);

I could be wrong but don't think this is used yet.  I'd prefer to see
it introduced only when it is.  Makes it easy to match up without
having to search back in earlier patches.

>  
>  	return 0;
>  }
> diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> index beb03921e6da..be87f62e9132 100644
> --- a/drivers/cxl/pci.h
> +++ b/drivers/cxl/pci.h
> @@ -12,4 +12,10 @@
>  #define PCI_DVSEC_ID_CXL	0x0
>  #define PCI_DVSEC_ID_CXL_REGLOC	0x8
>  
> +#define CXL_REGLOG_RBI_EMPTY 0

As in the QEMU patches, please add a comment on what RBI means
here. It's non obvious even just after you've read through the spec!

> +#define CXL_REGLOG_RBI_COMPONENT 1
> +#define CXL_REGLOG_RBI_VIRT 2
> +#define CXL_REGLOG_RBI_MEMDEV 3
> +#define CXL_REGLOG_IS_MEMDEV(x) ((((x) >> 8) & 0xff) == CXL_REGLOG_RBI_MEMDEV)
> +
>  #endif /* __CXL_PCI_H__ */


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities
  2020-11-11  5:43 ` [RFC PATCH 5/9] cxl/mem: Find device capabilities Ben Widawsky
  2020-11-13 18:26   ` Bjorn Helgaas
@ 2020-11-17 15:15   ` Jonathan Cameron
  2020-11-24  0:17     ` Ben Widawsky
  2020-11-26  6:05   ` Jon Masters
  2020-12-04  7:41   ` Dan Williams
  3 siblings, 1 reply; 73+ messages in thread
From: Jonathan Cameron @ 2020-11-17 15:15 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, 10 Nov 2020 21:43:52 -0800
Ben Widawsky <ben.widawsky@intel.com> wrote:

> CXL devices contain an array of capabilities that describe the
> interactions software can interact with the device, or firmware running
> on the device. A CXL compliant device must implement the device status
> and the mailbox capability. A CXL compliant memory device must implement
> the memory device capability.
> 
> Each of the capabilities can [will] provide an offset within the MMIO
> region for interacting with the CXL device.
> 
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>

A few really minor things in this one.

Jonathan

> ---
>  drivers/cxl/cxl.h | 89 +++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/cxl/mem.c | 58 +++++++++++++++++++++++++++---
>  2 files changed, 143 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/cxl/cxl.h
> 
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> new file mode 100644
> index 000000000000..02858ae63d6d
> --- /dev/null
> +++ b/drivers/cxl/cxl.h
> @@ -0,0 +1,89 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> +
> +#ifndef __CXL_H__
> +#define __CXL_H__
> +
> +/* Device */
> +#define CXLDEV_CAP_ARRAY_REG 0x0
> +#define CXLDEV_CAP_ARRAY_CAP_ID 0
> +#define CXLDEV_CAP_ARRAY_ID(x) ((x) & 0xffff)
> +#define CXLDEV_CAP_ARRAY_COUNT(x) (((x) >> 32) & 0xffff)
> +
> +#define CXL_CAPABILITIES_CAP_ID_DEVICE_STATUS 1

I'm not sure what you can do about consistent naming, but
perhaps this really does need to be 
CXLDEV_CAP_CAP_ID_x  however silly that looks.

It's a funny exercise I've only seen done once in a spec, but
I wish everyone would try working out what their fully expanded
field names will end up as and make sure the long form naming shortens
to something sensible.  It definitely helps with clarity!

> +#define CXL_CAPABILITIES_CAP_ID_PRIMARY_MAILBOX 2
> +#define CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX 3
> +#define CXL_CAPABILITIES_CAP_ID_MEMDEV 0x4000
> +
> +/* Mailbox */
> +#define CXLDEV_MB_CAPS 0x00

Elsewhere you've used _OFFSET postfix. That's useful so I'd do it here
as well.  Cross references to the spec section always appreciated as well!

> +#define   CXLDEV_MB_CAP_PAYLOAD_SIZE(cap) ((cap) & 0x1F)
> +#define CXLDEV_MB_CTRL 0x04
> +#define CXLDEV_MB_CMD 0x08
> +#define CXLDEV_MB_STATUS 0x10
> +#define CXLDEV_MB_BG_CMD_STATUS 0x18
> +
> +struct cxl_mem {
> +	struct pci_dev *pdev;
> +	void __iomem *regs;
> +
> +	/* Cap 0000h */

What are the numbers here?  These capabilities have too
many indexes associated with them in different ways for it
to be obvious, so perhaps more detail in the comments?

> +	struct {
> +		void __iomem *regs;
> +	} status;
> +
> +	/* Cap 0002h */
> +	struct {
> +		void __iomem *regs;
> +		size_t payload_size;
> +	} mbox;
> +
> +	/* Cap 0040h */
> +	struct {
> +		void __iomem *regs;
> +	} mem;
> +};

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 6/9] cxl/mem: Initialize the mailbox interface
  2020-11-11  5:43 ` [RFC PATCH 6/9] cxl/mem: Initialize the mailbox interface Ben Widawsky
@ 2020-11-17 15:22   ` Jonathan Cameron
  0 siblings, 0 replies; 73+ messages in thread
From: Jonathan Cameron @ 2020-11-17 15:22 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, 10 Nov 2020 21:43:53 -0800
Ben Widawsky <ben.widawsky@intel.com> wrote:

> Provide enough functionality to utilize the mailbox of a memory device.
> The mailbox is used to interact with the firmware running on the memory
> device.
> 
> The CXL specification defines separate capabilities for the mailbox and the
> memory device. While we can confirm the mailbox is ready, in order to actually
> interact with the memory device, the driver must also confirm the device's
> firmware is ready.
> 
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
Hi Ben,

A few minor suggestions.

J
> ---
>  drivers/cxl/cxl.h | 28 ++++++++++++++++++++++
>  drivers/cxl/mem.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 87 insertions(+)
> 
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 02858ae63d6d..482fc9cdc890 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -19,14 +19,41 @@
>  #define CXLDEV_MB_CAPS 0x00
>  #define   CXLDEV_MB_CAP_PAYLOAD_SIZE(cap) ((cap) & 0x1F)
>  #define CXLDEV_MB_CTRL 0x04
> +#define   CXLDEV_MB_CTRL_DOORBELL BIT(0)
>  #define CXLDEV_MB_CMD 0x08
>  #define CXLDEV_MB_STATUS 0x10
>  #define CXLDEV_MB_BG_CMD_STATUS 0x18
>  
> +/* Memory Device */
> +#define CXLMDEV_STATUS 0
As mentioned earlier, I'd make sure there is a clear way of telling what is a
register/memory offset and what is a field.

> +#define CXLMDEV_DEV_FATAL BIT(0)
> +#define CXLMDEV_FW_HALT BIT(1)
> +#define CXLMDEV_MEDIA_STATUS_SHIFT 2
> +#define CXLMDEV_MEDIA_STATUS_MASK 0x3

Problem with masks defined like this is it's not apparent from name if they
are pre or post shift.  Could we use FIELD_GET etc and GENMASK to
ensure there is only one unambiguous definition?

> +#define CXLMDEV_READY(status)                                                  \
> +	((((status) >> CXLMDEV_MEDIA_STATUS_SHIFT) &                           \
> +	  CXLMDEV_MEDIA_STATUS_MASK) == CXLMDEV_MS_READY)
> +#define CXLMDEV_MS_NOT_READY 0
> +#define CXLMDEV_MS_READY 1
> +#define CXLMDEV_MS_ERROR 2
> +#define CXLMDEV_MS_DISABLED 3
> +#define CXLMDEV_MBOX_IF_READY BIT(4)
> +#define CXLMDEV_RESET_NEEDED_SHIFT 5
> +#define CXLMDEV_RESET_NEEDED_MASK 0x7
> +#define CXLMDEV_RESET_NEEDED(status)                                           \
> +	(((status) >> CXLMDEV_RESET_NEEDED_SHIFT) & CXLMDEV_RESET_NEEDED_MASK)
> +#define CXLMDEV_RESET_NEEDED_NOT 0
> +#define CXLMDEV_RESET_NEEDED_COLD 1
> +#define CXLMDEV_RESET_NEEDED_WARM 2
> +#define CXLMDEV_RESET_NEEDED_HOT 3
> +#define CXLMDEV_RESET_NEEDED_CXL 4
> +
>  struct cxl_mem {
>  	struct pci_dev *pdev;
>  	void __iomem *regs;
>  
> +	spinlock_t mbox_lock; /* Protects device mailbox and firmware */
> +
>  	/* Cap 0000h */
>  	struct {
>  		void __iomem *regs;
> @@ -72,6 +99,7 @@ struct cxl_mem {
>  
>  cxl_reg(status)
>  cxl_reg(mbox)
> +cxl_reg(mem)
>  
>  static inline u32 __cxl_raw_read_reg32(struct cxl_mem *cxlm, u32 reg)
>  {
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 4109ef7c3ecb..9fd2d1daa534 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -7,6 +7,56 @@
>  #include "pci.h"
>  #include "cxl.h"
>  
> +static int cxl_mem_mbox_get(struct cxl_mem *cxlm)
> +{
> +	u64 md_status;
> +	u32 ctrl;
> +	int rc = -EBUSY;
> +
> +	spin_lock(&cxlm->mbox_lock);
> +
> +	ctrl = cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CTRL);
> +	if (ctrl & CXLDEV_MB_CTRL_DOORBELL)

Perhaps a comment on what this path means? I know from the spec, but
not super obvious from the code here.  If we do hit this path the device
will fail to come up and we won't have a clue why.

> +		goto out;
> +
> +	md_status = cxl_read_mem_reg64(cxlm, CXLMDEV_STATUS);
> +	if (md_status & CXLMDEV_MBOX_IF_READY && CXLMDEV_READY(md_status)) {
> +		/*
> +		 * Hardware shouldn't allow a ready status but also have failure
> +		 * bits set. Spit out an error, this should be a bug report
> +		 */
> +		if (md_status & CXLMDEV_DEV_FATAL) {
> +			dev_err(&cxlm->pdev->dev,
> +				"CXL device reporting ready and fatal\n");
> +			rc = -EFAULT;
> +			goto out;
> +		}
> +		if (md_status & CXLMDEV_FW_HALT) {
> +			dev_err(&cxlm->pdev->dev,
> +				"CXL device reporting ready and halted\n");
> +			rc = -EFAULT;
> +			goto out;
> +		}
> +		if (CXLMDEV_RESET_NEEDED(md_status)) {
> +			dev_err(&cxlm->pdev->dev,
> +				"CXL device reporting ready and reset needed\n");
> +			rc = -EFAULT;
> +			goto out;
> +		}
> +
> +		return 0;
> +	}
> +
> +out:
> +	spin_unlock(&cxlm->mbox_lock);
> +	return rc;
> +}
> +
> +static void cxl_mem_mbox_put(struct cxl_mem *cxlm)
> +{
> +	spin_unlock(&cxlm->mbox_lock);
> +}
> +
>  static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
>  {
>  	u64 cap_array;
> @@ -88,6 +138,8 @@ static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo, u32 reg_
>  		return ERR_PTR(-ENOMEM);
>  	}
>  
> +	spin_lock_init(&cxlm->mbox_lock);
> +
>  	regs = pcim_iomap_table(pdev)[bar];
>  	cxlm->pdev = pdev;
>  	cxlm->regs = regs + offset;
> @@ -160,6 +212,13 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  	if (rc)
>  		return rc;
>  
> +	/* Check that hardware "looks" okay. */
> +	rc = cxl_mem_mbox_get(cxlm);
> +	if (rc)
> +		return rc;
> +
> +	cxl_mem_mbox_put(cxlm);
> +	dev_dbg(&pdev->dev, "CXL Memory Device Interface Up\n");
>  	pci_set_drvdata(pdev, cxlm);
>  
>  	return 0;


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox
  2020-11-11  5:43 ` [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox Ben Widawsky
  2020-11-13 23:14   ` Bjorn Helgaas
@ 2020-11-17 15:31   ` Jonathan Cameron
  2020-11-17 16:34     ` Ben Widawsky
  1 sibling, 1 reply; 73+ messages in thread
From: Jonathan Cameron @ 2020-11-17 15:31 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, 10 Nov 2020 21:43:54 -0800
Ben Widawsky <ben.widawsky@intel.com> wrote:

> Create a function to handle sending a command, optionally with a
> payload, to the memory device, polling on a result, and then optionally
> copying out the payload. The algorithm for doing this come straight out
> of the CXL 2.0 specification.
> 
> Primary mailboxes are capable of generating an interrupt when submitting
> a command in the background. That implementation is saved for a later
> time.
> 
> Secondary mailboxes aren't implemented at this time.
> 
> WARNING: This is untested with actual timeouts occurring.
> 
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>

Question inline for why the preempt / local timer dance is worth bothering with.
What am I missing?

Thanks,

Jonathan

> ---
>  drivers/cxl/cxl.h |  16 +++++++
>  drivers/cxl/mem.c | 107 ++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 123 insertions(+)
> 
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 482fc9cdc890..f49ab80f68bd 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -21,8 +21,12 @@
>  #define CXLDEV_MB_CTRL 0x04
>  #define   CXLDEV_MB_CTRL_DOORBELL BIT(0)
>  #define CXLDEV_MB_CMD 0x08
> +#define   CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT 16
>  #define CXLDEV_MB_STATUS 0x10
> +#define   CXLDEV_MB_STATUS_RET_CODE_SHIFT 32
> +#define   CXLDEV_MB_STATUS_RET_CODE_MASK 0xffff
>  #define CXLDEV_MB_BG_CMD_STATUS 0x18
> +#define CXLDEV_MB_PAYLOAD 0x20
>  
>  /* Memory Device */
>  #define CXLMDEV_STATUS 0
> @@ -114,4 +118,16 @@ static inline u64 __cxl_raw_read_reg64(struct cxl_mem *cxlm, u32 reg)
>  
>  	return readq(reg_addr + reg);
>  }
> +
> +static inline void cxl_mbox_payload_fill(struct cxl_mem *cxlm, u8 *input,
> +					    unsigned int length)
> +{
> +	memcpy_toio(cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, input, length);
> +}
> +
> +static inline void cxl_mbox_payload_drain(struct cxl_mem *cxlm,
> +					     u8 *output, unsigned int length)
> +{
> +	memcpy_fromio(output, cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, length);
> +}
>  #endif /* __CXL_H__ */
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 9fd2d1daa534..08913360d500 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -1,5 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  // Copyright(c) 2020 Intel Corporation. All rights reserved.
> +#include <linux/sched/clock.h>
>  #include <linux/module.h>
>  #include <linux/pci.h>
>  #include <linux/io.h>
> @@ -7,6 +8,112 @@
>  #include "pci.h"
>  #include "cxl.h"
>  
> +struct mbox_cmd {
> +	u16 cmd;
> +	u8 *payload;
> +	size_t payload_size;
> +	u16 return_code;
> +};
> +
> +static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
> +{
> +	u64 start, now;
> +	int cpu, ret, timeout = 2000000000;
> +
> +	start = local_clock();
> +	preempt_disable();
> +	cpu = smp_processor_id();
> +	for (;;) {
> +		now = local_clock();
> +		preempt_enable();

What do we ever do with this mailbox that is particularly
performance critical? I'd like to understand why we care enough
to mess around with the preemption changes and local clock etc.

> +		if ((cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CTRL) &
> +		     CXLDEV_MB_CTRL_DOORBELL) == 0) {
> +			ret = 0;
> +			break;
> +		}
> +
> +		if (now - start >= timeout) {
> +			ret = -ETIMEDOUT;
> +			break;
> +		}
> +
> +		cpu_relax();
> +		preempt_disable();
> +		if (unlikely(cpu != smp_processor_id())) {
> +			timeout -= (now - start);
> +			cpu = smp_processor_id();
> +			start = local_clock();
> +		}
> +	}
> +
> +	return ret;
> +}
> +
> +/*
> + * Returns 0 if the doorbell transaction was successful from a protocol level.
> + * Caller should check the return code in @mbox_cmd to make sure it succeeded.
> + */
> +static int __maybe_unused cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, struct mbox_cmd *mbox_cmd)
> +{
> +	u64 cmd, status;
> +	int rc;
> +
> +	lockdep_assert_held(&cxlm->mbox_lock);
> +
> +	/*
> +	 * Here are the steps from 8.2.8.4 of the CXL 2.0 spec.
> +	 *   1. Caller reads MB Control Register to verify doorbell is clear
> +	 *   2. Caller writes Command Register
> +	 *   3. Caller writes Command Payload Registers if input payload is non-empty
> +	 *   4. Caller writes MB Control Register to set doorbell
> +	 *   5. Caller either polls for doorbell to be clear or waits for interrupt if configured
> +	 *   6. Caller reads MB Status Register to fetch Return code
> +	 *   7. If command successful, Caller reads Command Register to get Payload Length
> +	 *   8. If output payload is non-empty, host reads Command Payload Registers
> +	 */
> +
> +	cmd = mbox_cmd->cmd;
> +	if (mbox_cmd->payload_size) {
> +		/* #3 */

Having just given the steps above, having them out of order feels like it needs
a comment to state why.

> +		cmd |= mbox_cmd->payload_size
> +		       << CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT;
> +		cxl_mbox_payload_fill(cxlm, mbox_cmd->payload, mbox_cmd->payload_size);
> +	}
> +
> +	/* #2 */
> +	cxl_write_mbox_reg64(cxlm, CXLDEV_MB_CMD, cmd);
> +
> +	/* #4 */
> +	cxl_write_mbox_reg32(cxlm, CXLDEV_MB_CTRL, CXLDEV_MB_CTRL_DOORBELL);
> +
> +	/* #5 */
> +	rc = cxldev_wait_for_doorbell(cxlm);
> +	if (rc == -ETIMEDOUT) {
> +		dev_warn(&cxlm->pdev->dev, "Mailbox command timed out\n");
> +		return rc;
> +	}
> +
> +	/* #6 */
> +	status = cxl_read_mbox_reg64(cxlm, CXLDEV_MB_STATUS);
> +	cmd = cxl_read_mbox_reg64(cxlm, CXLDEV_MB_CMD);
> +
> +	mbox_cmd->return_code = (status >> CXLDEV_MB_STATUS_RET_CODE_SHIFT) &
> +				CXLDEV_MB_STATUS_RET_CODE_MASK;
> +
> +	/* There was a problem, let the caller deal with it */
> +	if (mbox_cmd->return_code != 0)
> +		return 0;
> +
> +	/* #7 */
> +	mbox_cmd->payload_size = cmd >> CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT;
> +
> +	/* #8 */
> +	if (mbox_cmd->payload_size)
> +		cxl_mbox_payload_drain(cxlm, mbox_cmd->payload, mbox_cmd->payload_size);
> +
> +	return 0;
> +}
> +
>  static int cxl_mem_mbox_get(struct cxl_mem *cxlm)
>  {
>  	u64 md_status;


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 8/9] cxl/mem: Register CXL memX devices
  2020-11-11  5:43 ` [RFC PATCH 8/9] cxl/mem: Register CXL memX devices Ben Widawsky
@ 2020-11-17 15:56   ` Jonathan Cameron
  2020-11-20  2:16     ` Dan Williams
  0 siblings, 1 reply; 73+ messages in thread
From: Jonathan Cameron @ 2020-11-17 15:56 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, 10 Nov 2020 21:43:55 -0800
Ben Widawsky <ben.widawsky@intel.com> wrote:

> From: Dan Williams <dan.j.williams@intel.com>
> 
> Create the /sys/bus/cxl hierarchy to enumerate memory devices
> (per-endpoint control devices), memory address space devices (platform
> address ranges with interleaving, performance, and persistence
> attributes), and memory regions (active provisioned memory from an
> address space device that is in use as System RAM or delegated to
> libnvdimm as Persistent Memory regions).
> 
> For now, only the per-endpoint control devices are registered on the
> 'cxl' bus.

Reviewing ABI without documentation is challenging even when it's simple
so please add that for v2.

This patch feels somewhat unpolished, but I guess it is mainly here to
give an illustration of how stuff might fit together rather than
any expectation of detailed review.

So in that spirit I've just pointed out stuff that jumped out at me
during a quick read through.

Thanks,

Jonathan


> 
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> ---
>  drivers/cxl/Makefile |   2 +
>  drivers/cxl/bus.c    |  35 ++++++
>  drivers/cxl/bus.h    |   8 ++
>  drivers/cxl/cxl.h    |  33 +++++
>  drivers/cxl/mem.c    | 287 ++++++++++++++++++++++++++++++++++++++++++-
>  5 files changed, 359 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/cxl/bus.c
>  create mode 100644 drivers/cxl/bus.h
> 
> diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> index 97fdffb00f2d..1cc032092852 100644
> --- a/drivers/cxl/Makefile
> +++ b/drivers/cxl/Makefile
> @@ -1,7 +1,9 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
>  obj-$(CONFIG_CXL_MEM) += cxl_mem.o
> +obj-$(CONFIG_CXL_BUS_PROVIDER) += cxl_bus.o
>  
>  ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
>  cxl_acpi-y := acpi.o
>  cxl_mem-y := mem.o
> +cxl_bus-y := bus.o
> diff --git a/drivers/cxl/bus.c b/drivers/cxl/bus.c
> new file mode 100644
> index 000000000000..8594366955f7
> --- /dev/null
> +++ b/drivers/cxl/bus.c
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> +#include <linux/device.h>
> +#include <linux/module.h>
> +
> +static struct bus_type cxl_bus_type = {
> +	.name = "cxl",
> +};
> +
> +int cxl_register(struct device *dev)
> +{
> +	int rc;
> +
> +	dev->bus = &cxl_bus_type;
> +	rc = device_add(dev);
> +	if (rc)
> +		put_device(dev);
> +	return rc;
> +}
> +EXPORT_SYMBOL_GPL(cxl_register);
> +
> +static __init int cxl_bus_init(void)
> +{
> +	return bus_register(&cxl_bus_type);
> +}
> +
> +static void cxl_bus_exit(void)
> +{
> +	bus_unregister(&cxl_bus_type);
> +}
> +
> +module_init(cxl_bus_init);
> +module_exit(cxl_bus_exit);
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Intel Corporation");
> diff --git a/drivers/cxl/bus.h b/drivers/cxl/bus.h
> new file mode 100644
> index 000000000000..fe2bea2bbc3c
> --- /dev/null
> +++ b/drivers/cxl/bus.h
> @@ -0,0 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> +#ifndef __CXL_BUS_H__
> +#define __CXL_BUS_H__
> +
> +int cxl_register(struct device *dev);
> +
> +#endif /* __CXL_BUS_H__ */
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index f49ab80f68bd..cef5fd9ea68b 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -3,6 +3,7 @@
>  
>  #ifndef __CXL_H__
>  #define __CXL_H__
> +#include <linux/range.h>
>  
>  /* Device */
>  #define CXLDEV_CAP_ARRAY_REG 0x0
> @@ -52,12 +53,24 @@
>  #define CXLMDEV_RESET_NEEDED_HOT 3
>  #define CXLMDEV_RESET_NEEDED_CXL 4
>  
> +struct cxl_memdev;
>  struct cxl_mem {
>  	struct pci_dev *pdev;
>  	void __iomem *regs;
> +	struct cxl_memdev *cxlmd;
>  
>  	spinlock_t mbox_lock; /* Protects device mailbox and firmware */
>  
> +	struct {
> +		struct range range;
> +	} pmem;
> +
> +	struct {
> +		struct range range;
> +	} ram;
> +
> +	char firmware_version[0x10];
> +
>  	/* Cap 0000h */
>  	struct {
>  		void __iomem *regs;
> @@ -130,4 +143,24 @@ static inline void cxl_mbox_payload_drain(struct cxl_mem *cxlm,
>  {
>  	memcpy_fromio(output, cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, length);
>  }
> +
> +#define CXL_MBOX_IDENTIFY 0x4000
> +
> +struct cxl_mbox_identify {
> +	char fw_revision[0x10];
> +	__le64 total_capacity;
> +	__le64 volatile_capacity;
> +	__le64 persistent_capacity;
> +	__le64 partition_align;
> +	__le16 info_event_log_size;
> +	__le16 warning_event_log_size;
> +	__le16 failure_event_log_size;
> +	__le16 fatal_event_log_size;
> +	__le32 lsa_size;
> +	u8 poison_list_max_mer[3];
> +	__le16 inject_poison_limit;
> +	u8 poison_caps;
> +	u8 qos_telemetry_caps;
> +} __packed;
> +
>  #endif /* __CXL_H__ */
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 08913360d500..54743d196feb 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -2,11 +2,15 @@
>  // Copyright(c) 2020 Intel Corporation. All rights reserved.
>  #include <linux/sched/clock.h>
>  #include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/cdev.h>
> +#include <linux/idr.h>
>  #include <linux/pci.h>
>  #include <linux/io.h>
>  #include "acpi.h"
>  #include "pci.h"
>  #include "cxl.h"
> +#include "bus.h"
>  
>  struct mbox_cmd {
>  	u16 cmd;
> @@ -15,6 +19,53 @@ struct mbox_cmd {
>  	u16 return_code;
>  };
>  
> +/*
> + * An entire PCI topology full of devices should be enough for any
> + * config
> + */
> +#define CXL_MEM_MAX_DEVS 65536
> +
> +struct cxl_memdev {
> +	struct device dev;
> +	struct cxl_mem *cxlm;
> +	int id;
> +};
> +
> +static int cxl_mem_major;
> +static struct cdev cxl_mem_cdev;
> +static DEFINE_IDR(cxl_mem_idr);
> +static DEFINE_MUTEX(cxl_memdev_lock);

Define scope of this lock with a comment.

> +
> +static int cxl_mem_open(struct inode *inode, struct file *file)
> +{
> +	long minor = iminor(inode);
> +	struct cxl_memdev *cxlmd;
> +
> +	rcu_read_lock();
> +	cxlmd = idr_find(&cxl_mem_idr, minor);
> +	rcu_read_unlock();
> +
> +	if (!cxlmd)
> +		return -ENXIO;
> +
> +	file->private_data = cxlmd;
> +
> +	return 0;
> +}
> +
> +static long cxl_mem_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> +{
> +	return -ENOTTY;
> +}
> +
> +static const struct file_operations cxl_mem_fops = {
> +	.owner = THIS_MODULE,
> +	.open = cxl_mem_open,
> +	.unlocked_ioctl = cxl_mem_ioctl,
> +	.compat_ioctl = compat_ptr_ioctl,
> +	.llseek = noop_llseek,
> +};
> +
>  static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
>  {
>  	u64 start, now;
> @@ -53,7 +104,7 @@ static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
>   * Returns 0 if the doorbell transaction was successful from a protocol level.
>   * Caller should check the return code in @mbox_cmd to make sure it succeeded.
>   */
> -static int __maybe_unused cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, struct mbox_cmd *mbox_cmd)
> +static int cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, struct mbox_cmd *mbox_cmd)
>  {
>  	u64 cmd, status;
>  	int rc;
> @@ -277,10 +328,185 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
>  	return 0;
>  }
>  
> +static struct cxl_memdev *to_cxl_memdev(struct device *dev)
> +{
> +	return container_of(dev, struct cxl_memdev, dev);
> +}
> +
> +static void cxl_memdev_release(struct device *dev)
> +{
> +	struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> +
> +	mutex_lock(&cxl_memdev_lock);
> +	idr_remove(&cxl_mem_idr, cxlmd->id);
> +	mutex_unlock(&cxl_memdev_lock);
> +
> +	kfree(cxlmd);
> +}
> +
> +static char *cxl_memdev_devnode(struct device *dev, umode_t *mode, kuid_t *uid, kgid_t *gid)
> +{
> +	return kasprintf(GFP_KERNEL, "cxl/%s", dev_name(dev));
> +}
> +
> +static ssize_t firmware_version_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> +	struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> +	struct cxl_mem *cxlm = cxlmd->cxlm;
> +
> +	return sprintf(buf, "%.16s\n", cxlm->firmware_version);
> +}
> +static DEVICE_ATTR_RO(firmware_version);
> +
> +static ssize_t ram_size_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> +	struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> +	struct cxl_mem *cxlm = cxlmd->cxlm;
> +
> +	return sprintf(buf, "%#llx\n", (unsigned long long) range_len(&cxlm->ram.range));
> +}
> +static struct device_attribute dev_attr_ram_size = __ATTR(size, 0444, ram_size_show, NULL);
> +
> +static ssize_t pmem_size_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> +	struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> +	struct cxl_mem *cxlm = cxlmd->cxlm;
> +
> +	return sprintf(buf, "%#llx\n", (unsigned long long) range_len(&cxlm->pmem.range));
> +}
> +static struct device_attribute dev_attr_pmem_size = __ATTR(size, 0444, pmem_size_show, NULL);
> +
> +static struct attribute *cxl_memdev_attributes[] = {
> +	&dev_attr_firmware_version.attr,
> +	NULL,
> +};
> +
> +static struct attribute *cxl_memdev_pmem_attributes[] = {
> +	&dev_attr_pmem_size.attr,

It's simple, but should still have docs in Documentation/ABI/testing/sysfs...

> +	NULL,
> +};
> +
> +static struct attribute *cxl_memdev_ram_attributes[] = {
> +	&dev_attr_ram_size.attr,
> +	NULL,
> +};
> +
> +static struct attribute_group cxl_memdev_attribute_group = {
> +	.attrs = cxl_memdev_attributes,
> +};
> +
> +static struct attribute_group cxl_memdev_ram_attribute_group = {
> +	.name = "ram",
> +	.attrs = cxl_memdev_ram_attributes,
> +};
> +
> +static struct attribute_group cxl_memdev_pmem_attribute_group = {
> +	.name = "pmem",
> +	.attrs = cxl_memdev_pmem_attributes,
> +};
> +
> +static const struct attribute_group *cxl_memdev_attribute_groups[] = {
> +	&cxl_memdev_attribute_group,
> +	&cxl_memdev_ram_attribute_group,
> +	&cxl_memdev_pmem_attribute_group,
> +	NULL,
> +};
> +
> +static const struct device_type cxl_memdev_type = {
> +	.name = "cxl_memdev",
> +	.release = cxl_memdev_release,
> +	.devnode = cxl_memdev_devnode,
> +	.groups = cxl_memdev_attribute_groups,
> +};
> +
> +static struct cxl_memdev *cxl_mem_add_memdev(struct cxl_mem *cxlm)
> +{
> +	struct pci_dev *pdev = cxlm->pdev;
> +	struct cxl_memdev *cxlmd;
> +	struct device *dev;
> +	int id, rc;
> +
> +	cxlmd = kzalloc(sizeof(*cxlmd), GFP_KERNEL);

Maybe I missed it, but I'm not seeing this freed anywhere.

> +	if (!cxlmd)
> +		return ERR_PTR(-ENOMEM);
> +
> +	cxlmd->cxlm = cxlm;
> +	cxlm->cxlmd = cxlmd;
> +
> +	mutex_lock(&cxl_memdev_lock);
> +	id = idr_alloc(&cxl_mem_idr, cxlmd, 0, CXL_MEM_MAX_DEVS, GFP_KERNEL);
> +	mutex_unlock(&cxl_memdev_lock);
> +	if (id < 0) {
> +		rc = id;
> +		goto err_idr;
> +	}
> +
> +	cxlmd->id = id;
> +
> +	dev = &cxlmd->dev;
> +
> +	device_initialize(dev);
> +	dev->parent = &pdev->dev;
> +	dev->devt = MKDEV(cxl_mem_major, id);
> +	dev->type = &cxl_memdev_type;
> +	dev_set_name(dev, "mem%d", id);

blank line here

> +	rc = cxl_register(dev);
> +	if (rc)
> +		return ERR_PTR(rc);
> +
> +	return cxlmd;
> +
> +err_idr:
> +	kfree(cxlmd);
> +
> +	return ERR_PTR(rc);
> +}
> +

...

>  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  {
>  	struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
>  	struct device *dev = &pdev->dev;
> +	struct cxl_memdev *cxlmd;
>  	int rc, regloc, i;
>  
>  	rc = cxl_bus_prepared(pdev);
> @@ -319,20 +545,31 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  	if (rc)
>  		return rc;
>  
> -	/* Check that hardware "looks" okay. */
> -	rc = cxl_mem_mbox_get(cxlm);
> +	rc = cxl_mem_identify(cxlm);
>  	if (rc)
>  		return rc;
> -
> -	cxl_mem_mbox_put(cxlm);

It was kind of nice to see the flow earlier, but I'm also thinking it made
a slightly harder to read patch.  Hmm.  Maybe just drop the version earlier
in favour of a todo comment that you then do here?

>  	dev_dbg(&pdev->dev, "CXL Memory Device Interface Up\n");
> +

Nice to tidy that up by moving to earlier patch.

>  	pci_set_drvdata(pdev, cxlm);
>  
> +	cxlmd = cxl_mem_add_memdev(cxlm);
> +	if (IS_ERR(cxlmd))
> +		return PTR_ERR(cxlmd);

Given we don't actually use cxlmd perhaps a simple return value
of 0 or error would be better from cxl_mem_add_memdev()

(I guess you may have follow up patches that do something with it
 here, though it feels wrong to ever do so given it is now registered
 and hence exposed to the system).

> +
>  	return 0;
>  }
>  
>  static void cxl_mem_remove(struct pci_dev *pdev)
>  {
> +	struct cxl_mem *cxlm = pci_get_drvdata(pdev);
> +	struct cxl_memdev *cxlmd = cxlm->cxlmd;
> +
> +	device_lock(&cxlmd->dev);
> +	cxlm->cxlmd = NULL;
> +	cxlmd->cxlm = NULL;
> +	device_unlock(&cxlmd->dev);
> +
> +	device_unregister(&cxlmd->dev);

Why device_unregister last? Normally removing exposure to the
system is the first thing you do in a remove() call.
Particularly as you'll get NULL ptr dereferences if anyone
manages a sysfs read between the pointers being set to NULL above
and the device_unregister() taking away the sysfs files.



>  }
>  
>  static const struct pci_device_id cxl_mem_pci_tbl[] = {
> @@ -350,7 +587,45 @@ static struct pci_driver cxl_mem_driver = {
>  	.remove			= cxl_mem_remove,
>  };
>  
> +static __init int cxl_mem_init(void)
> +{
> +	int rc;
> +	dev_t devt;
> +
> +	rc = alloc_chrdev_region(&devt, 0, CXL_MEM_MAX_DEVS, "cxl");
> +	if (rc)
> +		return rc;
> +
> +	cxl_mem_major = MAJOR(devt);
> +
> +	cdev_init(&cxl_mem_cdev, &cxl_mem_fops);
> +	rc = cdev_add(&cxl_mem_cdev, MKDEV(cxl_mem_major, 0), CXL_MEM_MAX_DEVS);
> +	if (rc)
> +		goto err_cdev;
> +
> +	rc = pci_register_driver(&cxl_mem_driver);
> +	if (rc)
> +		goto err_driver;
> +
> +	return 0;
> +
> +err_driver:
> +	cdev_del(&cxl_mem_cdev);
> +err_cdev:
> +	unregister_chrdev_region(MKDEV(cxl_mem_major, 0), CXL_MEM_MAX_DEVS);
> +
> +	return rc;
> +}
> +
> +static __exit void cxl_mem_exit(void)
> +{
> +	pci_unregister_driver(&cxl_mem_driver);
> +	unregister_chrdev_region(MKDEV(cxl_mem_major, 0), CXL_MEM_MAX_DEVS);
> +	cdev_del(&cxl_mem_cdev);

Ordering?  cdev_dev should be before unregister_chrdev_region to match
error handling in init()

> +}
> +
>  MODULE_LICENSE("GPL v2");
>  MODULE_AUTHOR("Intel Corporation");
> -module_pci_driver(cxl_mem_driver);
> +module_init(cxl_mem_init);
> +module_exit(cxl_mem_exit);
>  MODULE_IMPORT_NS(CXL);


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox
  2020-11-17 15:31   ` Jonathan Cameron
@ 2020-11-17 16:34     ` Ben Widawsky
  2020-11-17 18:06       ` Jonathan Cameron
  0 siblings, 1 reply; 73+ messages in thread
From: Ben Widawsky @ 2020-11-17 16:34 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On 20-11-17 15:31:22, Jonathan Cameron wrote:
> On Tue, 10 Nov 2020 21:43:54 -0800
> Ben Widawsky <ben.widawsky@intel.com> wrote:
> 
> > Create a function to handle sending a command, optionally with a
> > payload, to the memory device, polling on a result, and then optionally
> > copying out the payload. The algorithm for doing this come straight out
> > of the CXL 2.0 specification.
> > 
> > Primary mailboxes are capable of generating an interrupt when submitting
> > a command in the background. That implementation is saved for a later
> > time.
> > 
> > Secondary mailboxes aren't implemented at this time.
> > 
> > WARNING: This is untested with actual timeouts occurring.
> > 
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> 
> Question inline for why the preempt / local timer dance is worth bothering with.
> What am I missing?
> 
> Thanks,
> 
> Jonathan
> 
> > ---
> >  drivers/cxl/cxl.h |  16 +++++++
> >  drivers/cxl/mem.c | 107 ++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 123 insertions(+)
> > 
> > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> > index 482fc9cdc890..f49ab80f68bd 100644
> > --- a/drivers/cxl/cxl.h
> > +++ b/drivers/cxl/cxl.h
> > @@ -21,8 +21,12 @@
> >  #define CXLDEV_MB_CTRL 0x04
> >  #define   CXLDEV_MB_CTRL_DOORBELL BIT(0)
> >  #define CXLDEV_MB_CMD 0x08
> > +#define   CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT 16
> >  #define CXLDEV_MB_STATUS 0x10
> > +#define   CXLDEV_MB_STATUS_RET_CODE_SHIFT 32
> > +#define   CXLDEV_MB_STATUS_RET_CODE_MASK 0xffff
> >  #define CXLDEV_MB_BG_CMD_STATUS 0x18
> > +#define CXLDEV_MB_PAYLOAD 0x20
> >  
> >  /* Memory Device */
> >  #define CXLMDEV_STATUS 0
> > @@ -114,4 +118,16 @@ static inline u64 __cxl_raw_read_reg64(struct cxl_mem *cxlm, u32 reg)
> >  
> >  	return readq(reg_addr + reg);
> >  }
> > +
> > +static inline void cxl_mbox_payload_fill(struct cxl_mem *cxlm, u8 *input,
> > +					    unsigned int length)
> > +{
> > +	memcpy_toio(cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, input, length);
> > +}
> > +
> > +static inline void cxl_mbox_payload_drain(struct cxl_mem *cxlm,
> > +					     u8 *output, unsigned int length)
> > +{
> > +	memcpy_fromio(output, cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, length);
> > +}
> >  #endif /* __CXL_H__ */
> > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > index 9fd2d1daa534..08913360d500 100644
> > --- a/drivers/cxl/mem.c
> > +++ b/drivers/cxl/mem.c
> > @@ -1,5 +1,6 @@
> >  // SPDX-License-Identifier: GPL-2.0-only
> >  // Copyright(c) 2020 Intel Corporation. All rights reserved.
> > +#include <linux/sched/clock.h>
> >  #include <linux/module.h>
> >  #include <linux/pci.h>
> >  #include <linux/io.h>
> > @@ -7,6 +8,112 @@
> >  #include "pci.h"
> >  #include "cxl.h"
> >  
> > +struct mbox_cmd {
> > +	u16 cmd;
> > +	u8 *payload;
> > +	size_t payload_size;
> > +	u16 return_code;
> > +};
> > +
> > +static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
> > +{
> > +	u64 start, now;
> > +	int cpu, ret, timeout = 2000000000;
> > +
> > +	start = local_clock();
> > +	preempt_disable();
> > +	cpu = smp_processor_id();
> > +	for (;;) {
> > +		now = local_clock();
> > +		preempt_enable();
> 
> What do we ever do with this mailbox that is particularly
> performance critical? I'd like to understand why we care enough
> to mess around with the preemption changes and local clock etc.
> 

It is quite obviously a premature optimization at this point (since we only
support a single command in QEMU). However, the polling can be anywhere from
instant to 2 seconds. QEMU implementation aside again, some devices may never
support interrupts on completion, and so I thought providing a poll function now
that is capable of working for most [all?] cases was wise.

> > +		if ((cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CTRL) &
> > +		     CXLDEV_MB_CTRL_DOORBELL) == 0) {
> > +			ret = 0;
> > +			break;
> > +		}
> > +
> > +		if (now - start >= timeout) {
> > +			ret = -ETIMEDOUT;
> > +			break;
> > +		}
> > +
> > +		cpu_relax();
> > +		preempt_disable();
> > +		if (unlikely(cpu != smp_processor_id())) {
> > +			timeout -= (now - start);
> > +			cpu = smp_processor_id();
> > +			start = local_clock();
> > +		}
> > +	}
> > +
> > +	return ret;
> > +}
> > +
> > +/*
> > + * Returns 0 if the doorbell transaction was successful from a protocol level.
> > + * Caller should check the return code in @mbox_cmd to make sure it succeeded.
> > + */
> > +static int __maybe_unused cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, struct mbox_cmd *mbox_cmd)
> > +{
> > +	u64 cmd, status;
> > +	int rc;
> > +
> > +	lockdep_assert_held(&cxlm->mbox_lock);
> > +
> > +	/*
> > +	 * Here are the steps from 8.2.8.4 of the CXL 2.0 spec.
> > +	 *   1. Caller reads MB Control Register to verify doorbell is clear
> > +	 *   2. Caller writes Command Register
> > +	 *   3. Caller writes Command Payload Registers if input payload is non-empty
> > +	 *   4. Caller writes MB Control Register to set doorbell
> > +	 *   5. Caller either polls for doorbell to be clear or waits for interrupt if configured
> > +	 *   6. Caller reads MB Status Register to fetch Return code
> > +	 *   7. If command successful, Caller reads Command Register to get Payload Length
> > +	 *   8. If output payload is non-empty, host reads Command Payload Registers
> > +	 */
> > +
> > +	cmd = mbox_cmd->cmd;
> > +	if (mbox_cmd->payload_size) {
> > +		/* #3 */
> 
> Having just given the steps above, having them out of order feels like it needs
> a comment to state why.
> 
> > +		cmd |= mbox_cmd->payload_size
> > +		       << CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT;
> > +		cxl_mbox_payload_fill(cxlm, mbox_cmd->payload, mbox_cmd->payload_size);
> > +	}
> > +
> > +	/* #2 */
> > +	cxl_write_mbox_reg64(cxlm, CXLDEV_MB_CMD, cmd);
> > +
> > +	/* #4 */
> > +	cxl_write_mbox_reg32(cxlm, CXLDEV_MB_CTRL, CXLDEV_MB_CTRL_DOORBELL);
> > +
> > +	/* #5 */
> > +	rc = cxldev_wait_for_doorbell(cxlm);
> > +	if (rc == -ETIMEDOUT) {
> > +		dev_warn(&cxlm->pdev->dev, "Mailbox command timed out\n");
> > +		return rc;
> > +	}
> > +
> > +	/* #6 */
> > +	status = cxl_read_mbox_reg64(cxlm, CXLDEV_MB_STATUS);
> > +	cmd = cxl_read_mbox_reg64(cxlm, CXLDEV_MB_CMD);
> > +
> > +	mbox_cmd->return_code = (status >> CXLDEV_MB_STATUS_RET_CODE_SHIFT) &
> > +				CXLDEV_MB_STATUS_RET_CODE_MASK;
> > +
> > +	/* There was a problem, let the caller deal with it */
> > +	if (mbox_cmd->return_code != 0)
> > +		return 0;
> > +
> > +	/* #7 */
> > +	mbox_cmd->payload_size = cmd >> CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT;
> > +
> > +	/* #8 */
> > +	if (mbox_cmd->payload_size)
> > +		cxl_mbox_payload_drain(cxlm, mbox_cmd->payload, mbox_cmd->payload_size);
> > +
> > +	return 0;
> > +}
> > +
> >  static int cxl_mem_mbox_get(struct cxl_mem *cxlm)
> >  {
> >  	u64 md_status;
> 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox
  2020-11-17 16:34     ` Ben Widawsky
@ 2020-11-17 18:06       ` Jonathan Cameron
  2020-11-17 18:38         ` Dan Williams
  0 siblings, 1 reply; 73+ messages in thread
From: Jonathan Cameron @ 2020-11-17 18:06 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, 17 Nov 2020 08:34:38 -0800
Ben Widawsky <ben.widawsky@intel.com> wrote:

> On 20-11-17 15:31:22, Jonathan Cameron wrote:
> > On Tue, 10 Nov 2020 21:43:54 -0800
> > Ben Widawsky <ben.widawsky@intel.com> wrote:
> >   
> > > Create a function to handle sending a command, optionally with a
> > > payload, to the memory device, polling on a result, and then optionally
> > > copying out the payload. The algorithm for doing this come straight out
> > > of the CXL 2.0 specification.
> > > 
> > > Primary mailboxes are capable of generating an interrupt when submitting
> > > a command in the background. That implementation is saved for a later
> > > time.
> > > 
> > > Secondary mailboxes aren't implemented at this time.
> > > 
> > > WARNING: This is untested with actual timeouts occurring.
> > > 
> > > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>  
> > 
> > Question inline for why the preempt / local timer dance is worth bothering with.
> > What am I missing?
> > 
> > Thanks,
> > 
> > Jonathan
> >   
> > > ---
> > >  drivers/cxl/cxl.h |  16 +++++++
> > >  drivers/cxl/mem.c | 107 ++++++++++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 123 insertions(+)
> > > 
> > > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> > > index 482fc9cdc890..f49ab80f68bd 100644
> > > --- a/drivers/cxl/cxl.h
> > > +++ b/drivers/cxl/cxl.h
> > > @@ -21,8 +21,12 @@
> > >  #define CXLDEV_MB_CTRL 0x04
> > >  #define   CXLDEV_MB_CTRL_DOORBELL BIT(0)
> > >  #define CXLDEV_MB_CMD 0x08
> > > +#define   CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT 16
> > >  #define CXLDEV_MB_STATUS 0x10
> > > +#define   CXLDEV_MB_STATUS_RET_CODE_SHIFT 32
> > > +#define   CXLDEV_MB_STATUS_RET_CODE_MASK 0xffff
> > >  #define CXLDEV_MB_BG_CMD_STATUS 0x18
> > > +#define CXLDEV_MB_PAYLOAD 0x20
> > >  
> > >  /* Memory Device */
> > >  #define CXLMDEV_STATUS 0
> > > @@ -114,4 +118,16 @@ static inline u64 __cxl_raw_read_reg64(struct cxl_mem *cxlm, u32 reg)
> > >  
> > >  	return readq(reg_addr + reg);
> > >  }
> > > +
> > > +static inline void cxl_mbox_payload_fill(struct cxl_mem *cxlm, u8 *input,
> > > +					    unsigned int length)
> > > +{
> > > +	memcpy_toio(cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, input, length);
> > > +}
> > > +
> > > +static inline void cxl_mbox_payload_drain(struct cxl_mem *cxlm,
> > > +					     u8 *output, unsigned int length)
> > > +{
> > > +	memcpy_fromio(output, cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, length);
> > > +}
> > >  #endif /* __CXL_H__ */
> > > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > > index 9fd2d1daa534..08913360d500 100644
> > > --- a/drivers/cxl/mem.c
> > > +++ b/drivers/cxl/mem.c
> > > @@ -1,5 +1,6 @@
> > >  // SPDX-License-Identifier: GPL-2.0-only
> > >  // Copyright(c) 2020 Intel Corporation. All rights reserved.
> > > +#include <linux/sched/clock.h>
> > >  #include <linux/module.h>
> > >  #include <linux/pci.h>
> > >  #include <linux/io.h>
> > > @@ -7,6 +8,112 @@
> > >  #include "pci.h"
> > >  #include "cxl.h"
> > >  
> > > +struct mbox_cmd {
> > > +	u16 cmd;
> > > +	u8 *payload;
> > > +	size_t payload_size;
> > > +	u16 return_code;
> > > +};
> > > +
> > > +static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
> > > +{
> > > +	u64 start, now;
> > > +	int cpu, ret, timeout = 2000000000;
> > > +
> > > +	start = local_clock();
> > > +	preempt_disable();
> > > +	cpu = smp_processor_id();
> > > +	for (;;) {
> > > +		now = local_clock();
> > > +		preempt_enable();  
> > 
> > What do we ever do with this mailbox that is particularly
> > performance critical? I'd like to understand why we care enough
> > to mess around with the preemption changes and local clock etc.
> >   
> 
> It is quite obviously a premature optimization at this point (since we only
> support a single command in QEMU). However, the polling can be anywhere from
> instant to 2 seconds. QEMU implementation aside again, some devices may never
> support interrupts on completion, and so I thought providing a poll function now
> that is capable of working for most [all?] cases was wise.

Definitely seems premature.  I'd want to see real numbers on hardware
to justify this sort of complexity.  Maybe others disagree though.


Jonathan

> 
> > > +		if ((cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CTRL) &
> > > +		     CXLDEV_MB_CTRL_DOORBELL) == 0) {
> > > +			ret = 0;
> > > +			break;
> > > +		}
> > > +
> > > +		if (now - start >= timeout) {
> > > +			ret = -ETIMEDOUT;
> > > +			break;
> > > +		}
> > > +
> > > +		cpu_relax();
> > > +		preempt_disable();
> > > +		if (unlikely(cpu != smp_processor_id())) {
> > > +			timeout -= (now - start);
> > > +			cpu = smp_processor_id();
> > > +			start = local_clock();
> > > +		}
> > > +	}
> > > +
> > > +	return ret;
> > > +}
> > > +
> > > +/*
> > > + * Returns 0 if the doorbell transaction was successful from a protocol level.
> > > + * Caller should check the return code in @mbox_cmd to make sure it succeeded.
> > > + */
> > > +static int __maybe_unused cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, struct mbox_cmd *mbox_cmd)
> > > +{
> > > +	u64 cmd, status;
> > > +	int rc;
> > > +
> > > +	lockdep_assert_held(&cxlm->mbox_lock);
> > > +
> > > +	/*
> > > +	 * Here are the steps from 8.2.8.4 of the CXL 2.0 spec.
> > > +	 *   1. Caller reads MB Control Register to verify doorbell is clear
> > > +	 *   2. Caller writes Command Register
> > > +	 *   3. Caller writes Command Payload Registers if input payload is non-empty
> > > +	 *   4. Caller writes MB Control Register to set doorbell
> > > +	 *   5. Caller either polls for doorbell to be clear or waits for interrupt if configured
> > > +	 *   6. Caller reads MB Status Register to fetch Return code
> > > +	 *   7. If command successful, Caller reads Command Register to get Payload Length
> > > +	 *   8. If output payload is non-empty, host reads Command Payload Registers
> > > +	 */
> > > +
> > > +	cmd = mbox_cmd->cmd;
> > > +	if (mbox_cmd->payload_size) {
> > > +		/* #3 */  
> > 
> > Having just given the steps above, having them out of order feels like it needs
> > a comment to state why.
> >   
> > > +		cmd |= mbox_cmd->payload_size
> > > +		       << CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT;
> > > +		cxl_mbox_payload_fill(cxlm, mbox_cmd->payload, mbox_cmd->payload_size);
> > > +	}
> > > +
> > > +	/* #2 */
> > > +	cxl_write_mbox_reg64(cxlm, CXLDEV_MB_CMD, cmd);
> > > +
> > > +	/* #4 */
> > > +	cxl_write_mbox_reg32(cxlm, CXLDEV_MB_CTRL, CXLDEV_MB_CTRL_DOORBELL);
> > > +
> > > +	/* #5 */
> > > +	rc = cxldev_wait_for_doorbell(cxlm);
> > > +	if (rc == -ETIMEDOUT) {
> > > +		dev_warn(&cxlm->pdev->dev, "Mailbox command timed out\n");
> > > +		return rc;
> > > +	}
> > > +
> > > +	/* #6 */
> > > +	status = cxl_read_mbox_reg64(cxlm, CXLDEV_MB_STATUS);
> > > +	cmd = cxl_read_mbox_reg64(cxlm, CXLDEV_MB_CMD);
> > > +
> > > +	mbox_cmd->return_code = (status >> CXLDEV_MB_STATUS_RET_CODE_SHIFT) &
> > > +				CXLDEV_MB_STATUS_RET_CODE_MASK;
> > > +
> > > +	/* There was a problem, let the caller deal with it */
> > > +	if (mbox_cmd->return_code != 0)
> > > +		return 0;
> > > +
> > > +	/* #7 */
> > > +	mbox_cmd->payload_size = cmd >> CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT;
> > > +
> > > +	/* #8 */
> > > +	if (mbox_cmd->payload_size)
> > > +		cxl_mbox_payload_drain(cxlm, mbox_cmd->payload, mbox_cmd->payload_size);
> > > +
> > > +	return 0;
> > > +}
> > > +
> > >  static int cxl_mem_mbox_get(struct cxl_mem *cxlm)
> > >  {
> > >  	u64 md_status;  
> >   


^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox
  2020-11-17 18:06       ` Jonathan Cameron
@ 2020-11-17 18:38         ` Dan Williams
  0 siblings, 0 replies; 73+ messages in thread
From: Dan Williams @ 2020-11-17 18:38 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Tue, Nov 17, 2020 at 10:07 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Tue, 17 Nov 2020 08:34:38 -0800
> Ben Widawsky <ben.widawsky@intel.com> wrote:
>
> > On 20-11-17 15:31:22, Jonathan Cameron wrote:
> > > On Tue, 10 Nov 2020 21:43:54 -0800
> > > Ben Widawsky <ben.widawsky@intel.com> wrote:
> > >
> > > > Create a function to handle sending a command, optionally with a
> > > > payload, to the memory device, polling on a result, and then optionally
> > > > copying out the payload. The algorithm for doing this come straight out
> > > > of the CXL 2.0 specification.
> > > >
> > > > Primary mailboxes are capable of generating an interrupt when submitting
> > > > a command in the background. That implementation is saved for a later
> > > > time.
> > > >
> > > > Secondary mailboxes aren't implemented at this time.
> > > >
> > > > WARNING: This is untested with actual timeouts occurring.
> > > >
> > > > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > >
> > > Question inline for why the preempt / local timer dance is worth bothering with.
> > > What am I missing?
> > >
> > > Thanks,
> > >
> > > Jonathan
> > >
> > > > ---
> > > >  drivers/cxl/cxl.h |  16 +++++++
> > > >  drivers/cxl/mem.c | 107 ++++++++++++++++++++++++++++++++++++++++++++++
> > > >  2 files changed, 123 insertions(+)
> > > >
> > > > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> > > > index 482fc9cdc890..f49ab80f68bd 100644
> > > > --- a/drivers/cxl/cxl.h
> > > > +++ b/drivers/cxl/cxl.h
> > > > @@ -21,8 +21,12 @@
> > > >  #define CXLDEV_MB_CTRL 0x04
> > > >  #define   CXLDEV_MB_CTRL_DOORBELL BIT(0)
> > > >  #define CXLDEV_MB_CMD 0x08
> > > > +#define   CXLDEV_MB_CMD_PAYLOAD_LENGTH_SHIFT 16
> > > >  #define CXLDEV_MB_STATUS 0x10
> > > > +#define   CXLDEV_MB_STATUS_RET_CODE_SHIFT 32
> > > > +#define   CXLDEV_MB_STATUS_RET_CODE_MASK 0xffff
> > > >  #define CXLDEV_MB_BG_CMD_STATUS 0x18
> > > > +#define CXLDEV_MB_PAYLOAD 0x20
> > > >
> > > >  /* Memory Device */
> > > >  #define CXLMDEV_STATUS 0
> > > > @@ -114,4 +118,16 @@ static inline u64 __cxl_raw_read_reg64(struct cxl_mem *cxlm, u32 reg)
> > > >
> > > >   return readq(reg_addr + reg);
> > > >  }
> > > > +
> > > > +static inline void cxl_mbox_payload_fill(struct cxl_mem *cxlm, u8 *input,
> > > > +                                     unsigned int length)
> > > > +{
> > > > + memcpy_toio(cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, input, length);
> > > > +}
> > > > +
> > > > +static inline void cxl_mbox_payload_drain(struct cxl_mem *cxlm,
> > > > +                                      u8 *output, unsigned int length)
> > > > +{
> > > > + memcpy_fromio(output, cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, length);
> > > > +}
> > > >  #endif /* __CXL_H__ */
> > > > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > > > index 9fd2d1daa534..08913360d500 100644
> > > > --- a/drivers/cxl/mem.c
> > > > +++ b/drivers/cxl/mem.c
> > > > @@ -1,5 +1,6 @@
> > > >  // SPDX-License-Identifier: GPL-2.0-only
> > > >  // Copyright(c) 2020 Intel Corporation. All rights reserved.
> > > > +#include <linux/sched/clock.h>
> > > >  #include <linux/module.h>
> > > >  #include <linux/pci.h>
> > > >  #include <linux/io.h>
> > > > @@ -7,6 +8,112 @@
> > > >  #include "pci.h"
> > > >  #include "cxl.h"
> > > >
> > > > +struct mbox_cmd {
> > > > + u16 cmd;
> > > > + u8 *payload;
> > > > + size_t payload_size;
> > > > + u16 return_code;
> > > > +};
> > > > +
> > > > +static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
> > > > +{
> > > > + u64 start, now;
> > > > + int cpu, ret, timeout = 2000000000;
> > > > +
> > > > + start = local_clock();
> > > > + preempt_disable();
> > > > + cpu = smp_processor_id();
> > > > + for (;;) {
> > > > +         now = local_clock();
> > > > +         preempt_enable();
> > >
> > > What do we ever do with this mailbox that is particularly
> > > performance critical? I'd like to understand why we care enough
> > > to mess around with the preemption changes and local clock etc.
> > >
> >
> > It is quite obviously a premature optimization at this point (since we only
> > support a single command in QEMU). However, the polling can be anywhere from
> > instant to 2 seconds. QEMU implementation aside again, some devices may never
> > support interrupts on completion, and so I thought providing a poll function now
> > that is capable of working for most [all?] cases was wise.
>
> Definitely seems premature.  I'd want to see real numbers on hardware
> to justify this sort of complexity.  Maybe others disagree though.

The polling is definitely needed, but I think it can be a simple
jiffies based loop and avoid this sched_clock() complexity.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-17 14:32   ` Rafael J. Wysocki
@ 2020-11-17 21:45     ` Dan Williams
  2020-11-18 11:14       ` Rafael J. Wysocki
  0 siblings, 1 reply; 73+ messages in thread
From: Dan Williams @ 2020-11-17 21:45 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	ACPI Devel Maling List, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Tue, Nov 17, 2020 at 6:33 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
[..]
> > +static struct acpi_driver acpi_cxl_driver = {
>
> First of all, no new acpi_driver instances, pretty please!
>
> acpi_default_enumeration() should create a platform device with the
> ACPI0017 ID for you.  Can't you provide a driver for this one?
>

Ah, yes, I recall we had this discussion around the time the ACPI0012
NFIT driver was developed. IIRC the reason ACPI0012 remaining an
acpi_driver was due to a need to handle ACPI notifications, is that
the deciding factor? ACPI0017 does not have any notifications so it
seems like platform driver is the way to go.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
  2020-11-17 21:45     ` Dan Williams
@ 2020-11-18 11:14       ` Rafael J. Wysocki
  0 siblings, 0 replies; 73+ messages in thread
From: Rafael J. Wysocki @ 2020-11-18 11:14 UTC (permalink / raw)
  To: Dan Williams
  Cc: Rafael J. Wysocki, Ben Widawsky, linux-cxl,
	Linux Kernel Mailing List, Linux PCI, ACPI Devel Maling List,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, Nov 17, 2020 at 10:45 PM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Tue, Nov 17, 2020 at 6:33 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> [..]
> > > +static struct acpi_driver acpi_cxl_driver = {
> >
> > First of all, no new acpi_driver instances, pretty please!
> >
> > acpi_default_enumeration() should create a platform device with the
> > ACPI0017 ID for you.  Can't you provide a driver for this one?
> >
>
> Ah, yes, I recall we had this discussion around the time the ACPI0012
> NFIT driver was developed. IIRC the reason ACPI0012 remaining an
> acpi_driver was due to a need to handle ACPI notifications, is that
> the deciding factor?

Sort of.  In fact, a platform device driver can still handle ACPI
notifications just fine, it just needs to install a notify handler for
that.

The cases when an acpi_driver is really needed are basically when
creating the platform device during the enumeration is not desirable,
like in the PCI or PNP cases (because they both create device objects
of a different type to represent the "physical" device).

It doesn't look like it is really needed for ACPI0012, but since it is
there already, well ...

> ACPI0017 does not have any notifications so it seems like platform driver is the way to go.

Indeed.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 2/9] cxl/acpi: add OSC support
  2020-11-16 23:25     ` Dan Williams
@ 2020-11-18 12:25       ` Rafael J. Wysocki
  2020-11-18 17:58         ` Dan Williams
  0 siblings, 1 reply; 73+ messages in thread
From: Rafael J. Wysocki @ 2020-11-18 12:25 UTC (permalink / raw)
  To: Dan Williams
  Cc: Jonathan Cameron, Ben Widawsky, linux-cxl,
	Linux Kernel Mailing List, Linux PCI, Linux ACPI, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki

On Tue, Nov 17, 2020 at 12:26 AM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Mon, Nov 16, 2020 at 10:00 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Tue, 10 Nov 2020 21:43:49 -0800
> > Ben Widawsky <ben.widawsky@intel.com> wrote:
> >
> > > From: Vishal Verma <vishal.l.verma@intel.com>
> > >
> > > Add support to advertise OS capabilities, and request OS control for CXL
> > > features using the ACPI _OSC mechanism. Advertise support for all
> > > possible CXL features, and attempt to request control too for all
> > > possible features.
> > >
> > > Based on a patch by Sean Kelley.
> > >
> > > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> > > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> >
> > I guess unsurprisingly a lot of this is cut and paste from PCIe
> > so can we share some of the code?
> >
>
> I do not see a refactoring effort for these bit being all that
> fruitful.

Well, that depends on how much code duplication could be avoided this way.

> The backport pressure for this driver stack I expect will be
> higher than most, so I'm sensitive to avoiding unnecessary core
> entanglements.

If two pieces of code are based on the same underlying common code, it
is immediately clear to the reader how similar to each other they are.
Otherwise, they need to be carefully compared with each other to find
out what the differences are and whether or not they are arbitrary or
vitally important.  That is essential both from the revirem
perspective today and to anyone wanting to understand the given code
in the future (possibly in order to modify it without breaking it).
It outweighs the convenience by far IMV, with all due respect.

Recall how much effort it took to combine x86 with x86_64 and why it
turned out to be necessary to do that work, for one example.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 2/9] cxl/acpi: add OSC support
  2020-11-18 12:25       ` Rafael J. Wysocki
@ 2020-11-18 17:58         ` Dan Williams
  0 siblings, 0 replies; 73+ messages in thread
From: Dan Williams @ 2020-11-18 17:58 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Jonathan Cameron, Ben Widawsky, linux-cxl,
	Linux Kernel Mailing List, Linux PCI, Linux ACPI, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki

On Wed, Nov 18, 2020 at 4:26 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Tue, Nov 17, 2020 at 12:26 AM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Mon, Nov 16, 2020 at 10:00 AM Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > >
> > > On Tue, 10 Nov 2020 21:43:49 -0800
> > > Ben Widawsky <ben.widawsky@intel.com> wrote:
> > >
> > > > From: Vishal Verma <vishal.l.verma@intel.com>
> > > >
> > > > Add support to advertise OS capabilities, and request OS control for CXL
> > > > features using the ACPI _OSC mechanism. Advertise support for all
> > > > possible CXL features, and attempt to request control too for all
> > > > possible features.
> > > >
> > > > Based on a patch by Sean Kelley.
> > > >
> > > > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> > > > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > >
> > > I guess unsurprisingly a lot of this is cut and paste from PCIe
> > > so can we share some of the code?
> > >
> >
> > I do not see a refactoring effort for these bit being all that
> > fruitful.
>
> Well, that depends on how much code duplication could be avoided this way.
>
> > The backport pressure for this driver stack I expect will be
> > higher than most, so I'm sensitive to avoiding unnecessary core
> > entanglements.
>
> If two pieces of code are based on the same underlying common code, it
> is immediately clear to the reader how similar to each other they are.
> Otherwise, they need to be carefully compared with each other to find
> out what the differences are and whether or not they are arbitrary or
> vitally important.  That is essential both from the revirem
> perspective today and to anyone wanting to understand the given code
> in the future (possibly in order to modify it without breaking it).
> It outweighs the convenience by far IMV, with all due respect.
>
> Recall how much effort it took to combine x86 with x86_64 and why it
> turned out to be necessary to do that work, for one example.

I agree with above, but the degree of potential code sharing and
refactoring for CXL is nowhere near approaching the x86_64 situation.
There's also the counter example in ext3 and ext4 where a split is
maintained for good reason. All I'm saying is that let's judge patches
and not theory when it comes to refactoring CXL, my expectation is
that those opportunities will be few and far between. CXL is a
superset of PCIE functionality so it should not put much pressure on
common core PCIE code to change vs incremental CXL extensions.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 8/9] cxl/mem: Register CXL memX devices
  2020-11-17 15:56   ` Jonathan Cameron
@ 2020-11-20  2:16     ` Dan Williams
  2020-11-20 15:20       ` Jonathan Cameron
  0 siblings, 1 reply; 73+ messages in thread
From: Dan Williams @ 2020-11-20  2:16 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Tue, Nov 17, 2020 at 7:57 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Tue, 10 Nov 2020 21:43:55 -0800
> Ben Widawsky <ben.widawsky@intel.com> wrote:
>
> > From: Dan Williams <dan.j.williams@intel.com>
> >
> > Create the /sys/bus/cxl hierarchy to enumerate memory devices
> > (per-endpoint control devices), memory address space devices (platform
> > address ranges with interleaving, performance, and persistence
> > attributes), and memory regions (active provisioned memory from an
> > address space device that is in use as System RAM or delegated to
> > libnvdimm as Persistent Memory regions).
> >
> > For now, only the per-endpoint control devices are registered on the
> > 'cxl' bus.
>
> Reviewing ABI without documentation is challenging even when it's simple
> so please add that for v2.
>
> This patch feels somewhat unpolished, but I guess it is mainly here to
> give an illustration of how stuff might fit together rather than
> any expectation of detailed review.

Yeah, this is definitely an early look in the spirit of "Release early
/ release often".

>
> So in that spirit I've just pointed out stuff that jumped out at me
> during a quick read through.
>
> Thanks,
>
> Jonathan
>
>
> >
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > ---
> >  drivers/cxl/Makefile |   2 +
> >  drivers/cxl/bus.c    |  35 ++++++
> >  drivers/cxl/bus.h    |   8 ++
> >  drivers/cxl/cxl.h    |  33 +++++
> >  drivers/cxl/mem.c    | 287 ++++++++++++++++++++++++++++++++++++++++++-
> >  5 files changed, 359 insertions(+), 6 deletions(-)
> >  create mode 100644 drivers/cxl/bus.c
> >  create mode 100644 drivers/cxl/bus.h
> >
> > diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> > index 97fdffb00f2d..1cc032092852 100644
> > --- a/drivers/cxl/Makefile
> > +++ b/drivers/cxl/Makefile
> > @@ -1,7 +1,9 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
> >  obj-$(CONFIG_CXL_MEM) += cxl_mem.o
> > +obj-$(CONFIG_CXL_BUS_PROVIDER) += cxl_bus.o
> >
> >  ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
> >  cxl_acpi-y := acpi.o
> >  cxl_mem-y := mem.o
> > +cxl_bus-y := bus.o
> > diff --git a/drivers/cxl/bus.c b/drivers/cxl/bus.c
> > new file mode 100644
> > index 000000000000..8594366955f7
> > --- /dev/null
> > +++ b/drivers/cxl/bus.c
> > @@ -0,0 +1,35 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > +#include <linux/device.h>
> > +#include <linux/module.h>
> > +
> > +static struct bus_type cxl_bus_type = {
> > +     .name = "cxl",
> > +};
> > +
> > +int cxl_register(struct device *dev)
> > +{
> > +     int rc;
> > +
> > +     dev->bus = &cxl_bus_type;
> > +     rc = device_add(dev);
> > +     if (rc)
> > +             put_device(dev);
> > +     return rc;
> > +}
> > +EXPORT_SYMBOL_GPL(cxl_register);
> > +
> > +static __init int cxl_bus_init(void)
> > +{
> > +     return bus_register(&cxl_bus_type);
> > +}
> > +
> > +static void cxl_bus_exit(void)
> > +{
> > +     bus_unregister(&cxl_bus_type);
> > +}
> > +
> > +module_init(cxl_bus_init);
> > +module_exit(cxl_bus_exit);
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_AUTHOR("Intel Corporation");
> > diff --git a/drivers/cxl/bus.h b/drivers/cxl/bus.h
> > new file mode 100644
> > index 000000000000..fe2bea2bbc3c
> > --- /dev/null
> > +++ b/drivers/cxl/bus.h
> > @@ -0,0 +1,8 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > +#ifndef __CXL_BUS_H__
> > +#define __CXL_BUS_H__
> > +
> > +int cxl_register(struct device *dev);
> > +
> > +#endif /* __CXL_BUS_H__ */
> > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> > index f49ab80f68bd..cef5fd9ea68b 100644
> > --- a/drivers/cxl/cxl.h
> > +++ b/drivers/cxl/cxl.h
> > @@ -3,6 +3,7 @@
> >
> >  #ifndef __CXL_H__
> >  #define __CXL_H__
> > +#include <linux/range.h>
> >
> >  /* Device */
> >  #define CXLDEV_CAP_ARRAY_REG 0x0
> > @@ -52,12 +53,24 @@
> >  #define CXLMDEV_RESET_NEEDED_HOT 3
> >  #define CXLMDEV_RESET_NEEDED_CXL 4
> >
> > +struct cxl_memdev;
> >  struct cxl_mem {
> >       struct pci_dev *pdev;
> >       void __iomem *regs;
> > +     struct cxl_memdev *cxlmd;
> >
> >       spinlock_t mbox_lock; /* Protects device mailbox and firmware */
> >
> > +     struct {
> > +             struct range range;
> > +     } pmem;
> > +
> > +     struct {
> > +             struct range range;
> > +     } ram;
> > +
> > +     char firmware_version[0x10];
> > +
> >       /* Cap 0000h */
> >       struct {
> >               void __iomem *regs;
> > @@ -130,4 +143,24 @@ static inline void cxl_mbox_payload_drain(struct cxl_mem *cxlm,
> >  {
> >       memcpy_fromio(output, cxlm->mbox.regs + CXLDEV_MB_PAYLOAD, length);
> >  }
> > +
> > +#define CXL_MBOX_IDENTIFY 0x4000
> > +
> > +struct cxl_mbox_identify {
> > +     char fw_revision[0x10];
> > +     __le64 total_capacity;
> > +     __le64 volatile_capacity;
> > +     __le64 persistent_capacity;
> > +     __le64 partition_align;
> > +     __le16 info_event_log_size;
> > +     __le16 warning_event_log_size;
> > +     __le16 failure_event_log_size;
> > +     __le16 fatal_event_log_size;
> > +     __le32 lsa_size;
> > +     u8 poison_list_max_mer[3];
> > +     __le16 inject_poison_limit;
> > +     u8 poison_caps;
> > +     u8 qos_telemetry_caps;
> > +} __packed;
> > +
> >  #endif /* __CXL_H__ */
> > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > index 08913360d500..54743d196feb 100644
> > --- a/drivers/cxl/mem.c
> > +++ b/drivers/cxl/mem.c
> > @@ -2,11 +2,15 @@
> >  // Copyright(c) 2020 Intel Corporation. All rights reserved.
> >  #include <linux/sched/clock.h>
> >  #include <linux/module.h>
> > +#include <linux/mutex.h>
> > +#include <linux/cdev.h>
> > +#include <linux/idr.h>
> >  #include <linux/pci.h>
> >  #include <linux/io.h>
> >  #include "acpi.h"
> >  #include "pci.h"
> >  #include "cxl.h"
> > +#include "bus.h"
> >
> >  struct mbox_cmd {
> >       u16 cmd;
> > @@ -15,6 +19,53 @@ struct mbox_cmd {
> >       u16 return_code;
> >  };
> >
> > +/*
> > + * An entire PCI topology full of devices should be enough for any
> > + * config
> > + */
> > +#define CXL_MEM_MAX_DEVS 65536
> > +
> > +struct cxl_memdev {
> > +     struct device dev;
> > +     struct cxl_mem *cxlm;
> > +     int id;
> > +};
> > +
> > +static int cxl_mem_major;
> > +static struct cdev cxl_mem_cdev;
> > +static DEFINE_IDR(cxl_mem_idr);
> > +static DEFINE_MUTEX(cxl_memdev_lock);
>
> Define scope of this lock with a comment.

Will do.

>
> > +
> > +static int cxl_mem_open(struct inode *inode, struct file *file)
> > +{
> > +     long minor = iminor(inode);
> > +     struct cxl_memdev *cxlmd;
> > +
> > +     rcu_read_lock();
> > +     cxlmd = idr_find(&cxl_mem_idr, minor);
> > +     rcu_read_unlock();
> > +
> > +     if (!cxlmd)
> > +             return -ENXIO;
> > +
> > +     file->private_data = cxlmd;
> > +
> > +     return 0;
> > +}
> > +
> > +static long cxl_mem_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> > +{
> > +     return -ENOTTY;
> > +}
> > +
> > +static const struct file_operations cxl_mem_fops = {
> > +     .owner = THIS_MODULE,
> > +     .open = cxl_mem_open,
> > +     .unlocked_ioctl = cxl_mem_ioctl,
> > +     .compat_ioctl = compat_ptr_ioctl,
> > +     .llseek = noop_llseek,
> > +};
> > +
> >  static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
> >  {
> >       u64 start, now;
> > @@ -53,7 +104,7 @@ static int cxldev_wait_for_doorbell(struct cxl_mem *cxlm)
> >   * Returns 0 if the doorbell transaction was successful from a protocol level.
> >   * Caller should check the return code in @mbox_cmd to make sure it succeeded.
> >   */
> > -static int __maybe_unused cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, struct mbox_cmd *mbox_cmd)
> > +static int cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, struct mbox_cmd *mbox_cmd)
> >  {
> >       u64 cmd, status;
> >       int rc;
> > @@ -277,10 +328,185 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> >       return 0;
> >  }
> >
> > +static struct cxl_memdev *to_cxl_memdev(struct device *dev)
> > +{
> > +     return container_of(dev, struct cxl_memdev, dev);
> > +}
> > +
> > +static void cxl_memdev_release(struct device *dev)
> > +{
> > +     struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> > +
> > +     mutex_lock(&cxl_memdev_lock);
> > +     idr_remove(&cxl_mem_idr, cxlmd->id);
> > +     mutex_unlock(&cxl_memdev_lock);
> > +
> > +     kfree(cxlmd);
> > +}
> > +
> > +static char *cxl_memdev_devnode(struct device *dev, umode_t *mode, kuid_t *uid, kgid_t *gid)
> > +{
> > +     return kasprintf(GFP_KERNEL, "cxl/%s", dev_name(dev));
> > +}
> > +
> > +static ssize_t firmware_version_show(struct device *dev, struct device_attribute *attr, char *buf)
> > +{
> > +     struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> > +     struct cxl_mem *cxlm = cxlmd->cxlm;
> > +
> > +     return sprintf(buf, "%.16s\n", cxlm->firmware_version);
> > +}
> > +static DEVICE_ATTR_RO(firmware_version);
> > +
> > +static ssize_t ram_size_show(struct device *dev, struct device_attribute *attr, char *buf)
> > +{
> > +     struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> > +     struct cxl_mem *cxlm = cxlmd->cxlm;
> > +
> > +     return sprintf(buf, "%#llx\n", (unsigned long long) range_len(&cxlm->ram.range));
> > +}
> > +static struct device_attribute dev_attr_ram_size = __ATTR(size, 0444, ram_size_show, NULL);
> > +
> > +static ssize_t pmem_size_show(struct device *dev, struct device_attribute *attr, char *buf)
> > +{
> > +     struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> > +     struct cxl_mem *cxlm = cxlmd->cxlm;
> > +
> > +     return sprintf(buf, "%#llx\n", (unsigned long long) range_len(&cxlm->pmem.range));
> > +}
> > +static struct device_attribute dev_attr_pmem_size = __ATTR(size, 0444, pmem_size_show, NULL);
> > +
> > +static struct attribute *cxl_memdev_attributes[] = {
> > +     &dev_attr_firmware_version.attr,
> > +     NULL,
> > +};
> > +
> > +static struct attribute *cxl_memdev_pmem_attributes[] = {
> > +     &dev_attr_pmem_size.attr,
>
> It's simple, but should still have docs in Documentation/ABI/testing/sysfs...

Agree.

>
> > +     NULL,
> > +};
> > +
> > +static struct attribute *cxl_memdev_ram_attributes[] = {
> > +     &dev_attr_ram_size.attr,
> > +     NULL,
> > +};
> > +
> > +static struct attribute_group cxl_memdev_attribute_group = {
> > +     .attrs = cxl_memdev_attributes,
> > +};
> > +
> > +static struct attribute_group cxl_memdev_ram_attribute_group = {
> > +     .name = "ram",
> > +     .attrs = cxl_memdev_ram_attributes,
> > +};
> > +
> > +static struct attribute_group cxl_memdev_pmem_attribute_group = {
> > +     .name = "pmem",
> > +     .attrs = cxl_memdev_pmem_attributes,
> > +};
> > +
> > +static const struct attribute_group *cxl_memdev_attribute_groups[] = {
> > +     &cxl_memdev_attribute_group,
> > +     &cxl_memdev_ram_attribute_group,
> > +     &cxl_memdev_pmem_attribute_group,
> > +     NULL,
> > +};
> > +
> > +static const struct device_type cxl_memdev_type = {
> > +     .name = "cxl_memdev",
> > +     .release = cxl_memdev_release,
> > +     .devnode = cxl_memdev_devnode,
> > +     .groups = cxl_memdev_attribute_groups,
> > +};
> > +
> > +static struct cxl_memdev *cxl_mem_add_memdev(struct cxl_mem *cxlm)
> > +{
> > +     struct pci_dev *pdev = cxlm->pdev;
> > +     struct cxl_memdev *cxlmd;
> > +     struct device *dev;
> > +     int id, rc;
> > +
> > +     cxlmd = kzalloc(sizeof(*cxlmd), GFP_KERNEL);
>
> Maybe I missed it, but I'm not seeing this freed anywhere.

See: cxl_memdev_release()

>
> > +     if (!cxlmd)
> > +             return ERR_PTR(-ENOMEM);
> > +
> > +     cxlmd->cxlm = cxlm;
> > +     cxlm->cxlmd = cxlmd;
> > +
> > +     mutex_lock(&cxl_memdev_lock);
> > +     id = idr_alloc(&cxl_mem_idr, cxlmd, 0, CXL_MEM_MAX_DEVS, GFP_KERNEL);
> > +     mutex_unlock(&cxl_memdev_lock);
> > +     if (id < 0) {
> > +             rc = id;
> > +             goto err_idr;
> > +     }
> > +
> > +     cxlmd->id = id;
> > +
> > +     dev = &cxlmd->dev;
> > +
> > +     device_initialize(dev);
> > +     dev->parent = &pdev->dev;
> > +     dev->devt = MKDEV(cxl_mem_major, id);
> > +     dev->type = &cxl_memdev_type;
> > +     dev_set_name(dev, "mem%d", id);
>
> blank line here

ok

>
> > +     rc = cxl_register(dev);
> > +     if (rc)
> > +             return ERR_PTR(rc);
> > +
> > +     return cxlmd;
> > +
> > +err_idr:
> > +     kfree(cxlmd);
> > +
> > +     return ERR_PTR(rc);
> > +}
> > +
>
> ...
>
> >  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> >  {
> >       struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
> >       struct device *dev = &pdev->dev;
> > +     struct cxl_memdev *cxlmd;
> >       int rc, regloc, i;
> >
> >       rc = cxl_bus_prepared(pdev);
> > @@ -319,20 +545,31 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> >       if (rc)
> >               return rc;
> >
> > -     /* Check that hardware "looks" okay. */
> > -     rc = cxl_mem_mbox_get(cxlm);
> > +     rc = cxl_mem_identify(cxlm);
> >       if (rc)
> >               return rc;
> > -
> > -     cxl_mem_mbox_put(cxlm);
>
> It was kind of nice to see the flow earlier, but I'm also thinking it made
> a slightly harder to read patch.  Hmm.  Maybe just drop the version earlier
> in favour of a todo comment that you then do here?

Not sure I follow, but I think you're saying don't bother with an
initial patch introducing just doing the raw cxl_mem_mbox_get() in
this path, jump straight to cxl_mem_identify()?

>
> >       dev_dbg(&pdev->dev, "CXL Memory Device Interface Up\n");
> > +
>
> Nice to tidy that up by moving to earlier patch.

Sure.

>
> >       pci_set_drvdata(pdev, cxlm);
> >
> > +     cxlmd = cxl_mem_add_memdev(cxlm);
> > +     if (IS_ERR(cxlmd))
> > +             return PTR_ERR(cxlmd);
>
> Given we don't actually use cxlmd perhaps a simple return value
> of 0 or error would be better from cxl_mem_add_memdev()
>
> (I guess you may have follow up patches that do something with it
>  here, though it feels wrong to ever do so given it is now registered
>  and hence exposed to the system).

It's not added if IS_ERR() is true, but it would be simpler to just
have cxl_mem_add_memdev() return an int since ->probe() doesn't use
it.

>
> > +
> >       return 0;
> >  }
> >
> >  static void cxl_mem_remove(struct pci_dev *pdev)
> >  {
> > +     struct cxl_mem *cxlm = pci_get_drvdata(pdev);
> > +     struct cxl_memdev *cxlmd = cxlm->cxlmd;
> > +
> > +     device_lock(&cxlmd->dev);
> > +     cxlm->cxlmd = NULL;
> > +     cxlmd->cxlm = NULL;
> > +     device_unlock(&cxlmd->dev);
> > +
> > +     device_unregister(&cxlmd->dev);
>
> Why device_unregister last? Normally removing exposure to the
> system is the first thing you do in a remove() call.
> Particularly as you'll get NULL ptr dereferences if anyone
> manages a sysfs read between the pointers being set to NULL above
> and the device_unregister() taking away the sysfs files.

Yes, the unregister should be before the invalidation in this case. In
fact I'll likely drop the invalidation or do some other
synchronization requirement for any races between the ioctl path and
the remove path.

>
>
>
> >  }
> >
> >  static const struct pci_device_id cxl_mem_pci_tbl[] = {
> > @@ -350,7 +587,45 @@ static struct pci_driver cxl_mem_driver = {
> >       .remove                 = cxl_mem_remove,
> >  };
> >
> > +static __init int cxl_mem_init(void)
> > +{
> > +     int rc;
> > +     dev_t devt;
> > +
> > +     rc = alloc_chrdev_region(&devt, 0, CXL_MEM_MAX_DEVS, "cxl");
> > +     if (rc)
> > +             return rc;
> > +
> > +     cxl_mem_major = MAJOR(devt);
> > +
> > +     cdev_init(&cxl_mem_cdev, &cxl_mem_fops);
> > +     rc = cdev_add(&cxl_mem_cdev, MKDEV(cxl_mem_major, 0), CXL_MEM_MAX_DEVS);
> > +     if (rc)
> > +             goto err_cdev;
> > +
> > +     rc = pci_register_driver(&cxl_mem_driver);
> > +     if (rc)
> > +             goto err_driver;
> > +
> > +     return 0;
> > +
> > +err_driver:
> > +     cdev_del(&cxl_mem_cdev);
> > +err_cdev:
> > +     unregister_chrdev_region(MKDEV(cxl_mem_major, 0), CXL_MEM_MAX_DEVS);
> > +
> > +     return rc;
> > +}
> > +
> > +static __exit void cxl_mem_exit(void)
> > +{
> > +     pci_unregister_driver(&cxl_mem_driver);
> > +     unregister_chrdev_region(MKDEV(cxl_mem_major, 0), CXL_MEM_MAX_DEVS);
> > +     cdev_del(&cxl_mem_cdev);
>
> Ordering?  cdev_dev should be before unregister_chrdev_region to match
> error handling in init()

Yes.

Thanks for taking a look!

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 8/9] cxl/mem: Register CXL memX devices
  2020-11-20  2:16     ` Dan Williams
@ 2020-11-20 15:20       ` Jonathan Cameron
  0 siblings, 0 replies; 73+ messages in thread
From: Jonathan Cameron @ 2020-11-20 15:20 UTC (permalink / raw)
  To: Dan Williams
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Thu, 19 Nov 2020 18:16:19 -0800
Dan Williams <dan.j.williams@intel.com> wrote:

> On Tue, Nov 17, 2020 at 7:57 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Tue, 10 Nov 2020 21:43:55 -0800
> > Ben Widawsky <ben.widawsky@intel.com> wrote:
> >  
> > > From: Dan Williams <dan.j.williams@intel.com>
> > >
> > > Create the /sys/bus/cxl hierarchy to enumerate memory devices
> > > (per-endpoint control devices), memory address space devices (platform
> > > address ranges with interleaving, performance, and persistence
> > > attributes), and memory regions (active provisioned memory from an
> > > address space device that is in use as System RAM or delegated to
> > > libnvdimm as Persistent Memory regions).
> > >
> > > For now, only the per-endpoint control devices are registered on the
> > > 'cxl' bus.  
> >
> > Reviewing ABI without documentation is challenging even when it's simple
> > so please add that for v2.
> >
> > This patch feels somewhat unpolished, but I guess it is mainly here to
> > give an illustration of how stuff might fit together rather than
> > any expectation of detailed review.  
> 
> Yeah, this is definitely an early look in the spirit of "Release early
> / release often".
> 

Definitely a good idea.


...

> >  
> > >  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > >  {
> > >       struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
> > >       struct device *dev = &pdev->dev;
> > > +     struct cxl_memdev *cxlmd;
> > >       int rc, regloc, i;
> > >
> > >       rc = cxl_bus_prepared(pdev);
> > > @@ -319,20 +545,31 @@ static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > >       if (rc)
> > >               return rc;
> > >
> > > -     /* Check that hardware "looks" okay. */
> > > -     rc = cxl_mem_mbox_get(cxlm);
> > > +     rc = cxl_mem_identify(cxlm);
> > >       if (rc)
> > >               return rc;
> > > -
> > > -     cxl_mem_mbox_put(cxlm);  
> >
> > It was kind of nice to see the flow earlier, but I'm also thinking it made
> > a slightly harder to read patch.  Hmm.  Maybe just drop the version earlier
> > in favour of a todo comment that you then do here?  
> 
> Not sure I follow, but I think you're saying don't bother with an
> initial patch introducing just doing the raw cxl_mem_mbox_get() in
> this path, jump straight to cxl_mem_identify()?

Exactly.

> 
> >  
> > >       dev_dbg(&pdev->dev, "CXL Memory Device Interface Up\n");
> > > +  
> >
> > Nice to tidy that up by moving to earlier patch.  
> 
> Sure.
> 
> >  
> > >       pci_set_drvdata(pdev, cxlm);
> > >
> > > +     cxlmd = cxl_mem_add_memdev(cxlm);
> > > +     if (IS_ERR(cxlmd))
> > > +             return PTR_ERR(cxlmd);  
> >
> > Given we don't actually use cxlmd perhaps a simple return value
> > of 0 or error would be better from cxl_mem_add_memdev()
> >
> > (I guess you may have follow up patches that do something with it
> >  here, though it feels wrong to ever do so given it is now registered
> >  and hence exposed to the system).  
> 
> It's not added if IS_ERR() is true, but it would be simpler to just
> have cxl_mem_add_memdev() return an int since ->probe() doesn't use
> it.

Agreed.

> 
> >  
> > > +
> > >       return 0;
> > >  }
> > >

...




^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers
  2020-11-17  0:23         ` Bjorn Helgaas
@ 2020-11-23 19:20           ` Ben Widawsky
  2020-11-23 19:32             ` Dan Williams
  0 siblings, 1 reply; 73+ messages in thread
From: Ben Widawsky @ 2020-11-23 19:20 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Dan Williams, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On 20-11-16 18:23:21, Bjorn Helgaas wrote:
> On Mon, Nov 16, 2020 at 03:19:41PM -0800, Dan Williams wrote:
> > On Fri, Nov 13, 2020 at 5:12 PM Ben Widawsky <ben.widawsky@intel.com> wrote:
> > > On 20-11-13 12:17:32, Bjorn Helgaas wrote:
> > > > On Tue, Nov 10, 2020 at 09:43:51PM -0800, Ben Widawsky wrote:
> 
> > > > >  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > > > >  {
> > > > > +   struct cxl_mem *cxlm = ERR_PTR(-ENXIO);
> > > > >     struct device *dev = &pdev->dev;
> > > > > -   struct cxl_mem *cxlm;
> > > >
> > > > The order was better before ("dev", then "clxm").  Oh, I suppose this
> > > > is a "reverse Christmas tree" thing.
> > > >
> > >
> > > I don't actually care either way as long as it's consistent. I tend to do
> > > reverse Christmas tree for no particular reason.
> > 
> > Yeah, reverse Christmas tree for no particular reason.
> 
> FWIW, the usual drivers/pci style is to order the decls in the order
> the variables are used in the code.  But this isn't drivers/pci, so
> it's up to you.  I only noticed because changing the order made the
> diff bigger than it needed to be.
> 
> > > > I think this would be easier to read if cxl_mem_create() returned NULL
> > > > on failure (it prints error messages and we throw away
> > > > -ENXIO/-ENOMEM distinction here anyway) so you could do:
> > > >
> > > >   struct cxl_mem *cxlm = NULL;
> > > >
> > > >   for (...) {
> > > >     if (...) {
> > > >       cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
> > > >       break;
> > > >     }
> > > >   }
> > > >
> > > >   if (!cxlm)
> > > >     return -ENXIO;  /* -ENODEV might be more natural? */
> > > >
> > >
> > > I agree on both counts. Both of these came from Dan, so I will let him explain.
> > 
> > I'm not attached to differentiating -ENOMEM from -ENXIO and am ok to
> > drop the ERR_PTR() return. I do tend to use -ENXIO for failure to
> > perform an initialization action vs failure to even find the device,
> > but if -ENODEV seems more idiomatic to Bjorn, I won't argue.
> 
> -ENXIO is fine with me.  I just don't see it as often so I don't
> really know what it is.
> 
> Bjorn

Dan, Bjorn, I did a fairly randomized look at various probe functions and ENODEV
seems to be more common. My sort of historical use has been
- ENODEV: General, couldn't establish device presence
- ENXIO: Device was there but something is totally misconfigured
- E*: A matching errno for exactly what went wrong

My question though is, would it be useful to propagate the error up through
probe?

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers
  2020-11-23 19:20           ` Ben Widawsky
@ 2020-11-23 19:32             ` Dan Williams
  2020-11-23 19:58               ` Ben Widawsky
  0 siblings, 1 reply; 73+ messages in thread
From: Dan Williams @ 2020-11-23 19:32 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Bjorn Helgaas, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Mon, Nov 23, 2020 at 11:20 AM Ben Widawsky <ben.widawsky@intel.com> wrote:
[..]
> > -ENXIO is fine with me.  I just don't see it as often so I don't
> > really know what it is.
> >
> > Bjorn
>
> Dan, Bjorn, I did a fairly randomized look at various probe functions and ENODEV
> seems to be more common. My sort of historical use has been
> - ENODEV: General, couldn't establish device presence
> - ENXIO: Device was there but something is totally misconfigured
> - E*: A matching errno for exactly what went wrong
>
> My question though is, would it be useful to propagate the error up through
> probe?

The error from probe becomes the modprobe exit code, or the write to
the 'bind' attribute errno. So, it's a choice between "No such device
or address", or "No such device". The "or address" mention makes a
small bit more sense to me since the device is obviously present as it
is visible in lspci, but either error code clearly indicates a driver
problem so ENODEV is fine.

For the other error codes I think it would be confusing to return
something like EINVAL from probe as that would be mistaken as an
invalid argument to the modprobe without stracing to see that it came
from the result of a sysfs write

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers
  2020-11-23 19:32             ` Dan Williams
@ 2020-11-23 19:58               ` Ben Widawsky
  0 siblings, 0 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-23 19:58 UTC (permalink / raw)
  To: Dan Williams
  Cc: Bjorn Helgaas, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On 20-11-23 11:32:33, Dan Williams wrote:
> On Mon, Nov 23, 2020 at 11:20 AM Ben Widawsky <ben.widawsky@intel.com> wrote:
> [..]
> > > -ENXIO is fine with me.  I just don't see it as often so I don't
> > > really know what it is.
> > >
> > > Bjorn
> >
> > Dan, Bjorn, I did a fairly randomized look at various probe functions and ENODEV
> > seems to be more common. My sort of historical use has been
> > - ENODEV: General, couldn't establish device presence
> > - ENXIO: Device was there but something is totally misconfigured
> > - E*: A matching errno for exactly what went wrong
> >
> > My question though is, would it be useful to propagate the error up through
> > probe?
> 
> The error from probe becomes the modprobe exit code, or the write to
> the 'bind' attribute errno. So, it's a choice between "No such device
> or address", or "No such device". The "or address" mention makes a
> small bit more sense to me since the device is obviously present as it
> is visible in lspci, but either error code clearly indicates a driver
> problem so ENODEV is fine.
> 
> For the other error codes I think it would be confusing to return
> something like EINVAL from probe as that would be mistaken as an
> invalid argument to the modprobe without stracing to see that it came
> from the result of a sysfs write

Currently in this path there are 2 general reasons for failure:
1. Driver internal problem, ENOMEM or some such.
2. Device problem (the memory device capability isn't present).

I think I'll return ENODEV for the former and ENXIO for the latter. If that
sounds good to everyone else.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities
  2020-11-17 15:15   ` Jonathan Cameron
@ 2020-11-24  0:17     ` Ben Widawsky
  0 siblings, 0 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-24  0:17 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On 20-11-17 15:15:19, Jonathan Cameron wrote:
> On Tue, 10 Nov 2020 21:43:52 -0800
> Ben Widawsky <ben.widawsky@intel.com> wrote:
> 
> > CXL devices contain an array of capabilities that describe the
> > interactions software can interact with the device, or firmware running
> > on the device. A CXL compliant device must implement the device status
> > and the mailbox capability. A CXL compliant memory device must implement
> > the memory device capability.
> > 
> > Each of the capabilities can [will] provide an offset within the MMIO
> > region for interacting with the CXL device.
> > 
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> 
> A few really minor things in this one.
> 
> Jonathan
> 
> > ---
> >  drivers/cxl/cxl.h | 89 +++++++++++++++++++++++++++++++++++++++++++++++
> >  drivers/cxl/mem.c | 58 +++++++++++++++++++++++++++---
> >  2 files changed, 143 insertions(+), 4 deletions(-)
> >  create mode 100644 drivers/cxl/cxl.h
> > 
> > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> > new file mode 100644
> > index 000000000000..02858ae63d6d
> > --- /dev/null
> > +++ b/drivers/cxl/cxl.h
> > @@ -0,0 +1,89 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > +
> > +#ifndef __CXL_H__
> > +#define __CXL_H__
> > +
> > +/* Device */
> > +#define CXLDEV_CAP_ARRAY_REG 0x0
> > +#define CXLDEV_CAP_ARRAY_CAP_ID 0
> > +#define CXLDEV_CAP_ARRAY_ID(x) ((x) & 0xffff)
> > +#define CXLDEV_CAP_ARRAY_COUNT(x) (((x) >> 32) & 0xffff)
> > +
> > +#define CXL_CAPABILITIES_CAP_ID_DEVICE_STATUS 1
> 
> I'm not sure what you can do about consistent naming, but
> perhaps this really does need to be 
> CXLDEV_CAP_CAP_ID_x  however silly that looks.
> 
> It's a funny exercise I've only seen done once in a spec, but
> I wish everyone would try working out what their fully expanded
> field names will end up as and make sure the long form naming shortens
> to something sensible.  It definitely helps with clarity!
> 
> > +#define CXL_CAPABILITIES_CAP_ID_PRIMARY_MAILBOX 2
> > +#define CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX 3
> > +#define CXL_CAPABILITIES_CAP_ID_MEMDEV 0x4000
> > +
> > +/* Mailbox */
> > +#define CXLDEV_MB_CAPS 0x00
> 
> Elsewhere you've used _OFFSET postfix. That's useful so I'd do it here
> as well.  Cross references to the spec section always appreciated as well!
> 
> > +#define   CXLDEV_MB_CAP_PAYLOAD_SIZE(cap) ((cap) & 0x1F)
> > +#define CXLDEV_MB_CTRL 0x04
> > +#define CXLDEV_MB_CMD 0x08
> > +#define CXLDEV_MB_STATUS 0x10
> > +#define CXLDEV_MB_BG_CMD_STATUS 0x18
> > +
> > +struct cxl_mem {
> > +	struct pci_dev *pdev;
> > +	void __iomem *regs;
> > +
> > +	/* Cap 0000h */
> 
> What are the numbers here?  These capabilities have too
> many indexes associated with them in different ways for it
> to be obvious, so perhaps more detail in the comments?

This comment was a bug. The cap is 0001h actually. I've added the hash define
for its cap id as part of the comment.

Everything else is accepted.

> 
> > +	struct {
> > +		void __iomem *regs;
> > +	} status;
> > +
> > +	/* Cap 0002h */
> > +	struct {
> > +		void __iomem *regs;
> > +		size_t payload_size;
> > +	} mbox;
> > +
> > +	/* Cap 0040h */
> > +	struct {
> > +		void __iomem *regs;
> > +	} mem;
> > +};

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities
  2020-11-11  5:43 ` [RFC PATCH 5/9] cxl/mem: Find device capabilities Ben Widawsky
  2020-11-13 18:26   ` Bjorn Helgaas
  2020-11-17 15:15   ` Jonathan Cameron
@ 2020-11-26  6:05   ` Jon Masters
  2020-11-26 18:18     ` Ben Widawsky
  2020-12-04  7:35     ` Dan Williams
  2020-12-04  7:41   ` Dan Williams
  3 siblings, 2 replies; 73+ messages in thread
From: Jon Masters @ 2020-11-26  6:05 UTC (permalink / raw)
  To: Ben Widawsky, linux-cxl
  Cc: linux-kernel, linux-pci, linux-acpi, Dan Williams, Ira Weiny,
	Vishal Verma, Kelley, Sean V, Bjorn Helgaas, Rafael J . Wysocki

On 11/11/20 12:43 AM, Ben Widawsky wrote:

> +		case CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX:
> +			dev_dbg(&cxlm->pdev->dev,
> +				   "found UNSUPPORTED Secondary Mailbox capability\n");

Per spec, the secondary mailbox is intended for use by platform 
firmware, so Linux should never be using it anyway. Maybe that message 
is slightly misleading?

Jon.

P.S. Related - I've severe doubts about the mailbox approach being 
proposed by CXL and have begun to push back through the spec org.

-- 
Computer Architect

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities
  2020-11-26  6:05   ` Jon Masters
@ 2020-11-26 18:18     ` Ben Widawsky
  2020-12-04  7:35     ` Dan Williams
  1 sibling, 0 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-11-26 18:18 UTC (permalink / raw)
  To: Jon Masters
  Cc: linux-cxl, linux-kernel, linux-pci, linux-acpi, Dan Williams,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On 20-11-26 01:05:56, Jon Masters wrote:
> On 11/11/20 12:43 AM, Ben Widawsky wrote:
> 
> > +		case CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX:
> > +			dev_dbg(&cxlm->pdev->dev,
> > +				   "found UNSUPPORTED Secondary Mailbox capability\n");
> 
> Per spec, the secondary mailbox is intended for use by platform firmware, so
> Linux should never be using it anyway. Maybe that message is slightly
> misleading?

Yeah, I think the message could be reworded, but it is dev_dbg, so I wasn't too
worried about the wording in the first place. I think it is a mistake in this
case for the spec to describe the intended purpose. If the expectation is for
platform firmware to use it, but there is no negotiation mechanism in place,
it's essentially useless.

> 
> Jon.
> 
> P.S. Related - I've severe doubts about the mailbox approach being proposed
> by CXL and have begun to push back through the spec org.

Any reason not to articulate that here? Now that the spec is public, I don't see
any reason not to disclose that publicly.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-11-17 14:49   ` Jonathan Cameron
@ 2020-12-04  7:22     ` Dan Williams
  2020-12-04  7:27       ` Dan Williams
  0 siblings, 1 reply; 73+ messages in thread
From: Dan Williams @ 2020-12-04  7:22 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Tue, Nov 17, 2020 at 6:50 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Tue, 10 Nov 2020 21:43:50 -0800
> Ben Widawsky <ben.widawsky@intel.com> wrote:
>
> > From: Dan Williams <dan.j.williams@intel.com>
> >
> > The CXL.mem protocol allows a device to act as a provider of "System
> > RAM" and/or "Persistent Memory" that is fully coherent as if the memory
> > was attached to the typical CPU memory controller.
> >
> > The memory range exported by the device may optionally be described by
> > the platform firmware memory map, or by infrastructure like LIBNVDIMM to
> > provision persistent memory capacity from one, or more, CXL.mem devices.
> >
> > A pre-requisite for Linux-managed memory-capacity provisioning is this
> > cxl_mem driver that can speak the "type-3 mailbox" protocol.
> >
> > For now just land the driver boiler-plate and fill it in with
> > functionality in subsequent commits.
> >
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
>
> I've tried to avoid repeats, so mostly this is me moaning about naming!
>
> Jonathan
>
> > ---
> >  drivers/cxl/Kconfig  | 20 +++++++++++
> >  drivers/cxl/Makefile |  2 ++
> >  drivers/cxl/mem.c    | 82 ++++++++++++++++++++++++++++++++++++++++++++
> >  drivers/cxl/pci.h    | 15 ++++++++
> >  4 files changed, 119 insertions(+)
> >  create mode 100644 drivers/cxl/mem.c
> >  create mode 100644 drivers/cxl/pci.h
> >
> > diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> > index dd724bd364df..15548f5c77ff 100644
> > --- a/drivers/cxl/Kconfig
> > +++ b/drivers/cxl/Kconfig
> > @@ -27,4 +27,24 @@ config CXL_ACPI
> >         resources described by the CEDT (CXL Early Discovery Table)
> >
> >         Say 'y' to enable CXL (Compute Express Link) drivers.
> > +
> > +config CXL_MEM
> > +        tristate "CXL.mem Device Support"
> > +        depends on PCI && CXL_BUS_PROVIDER != n
> > +        default m if CXL_BUS_PROVIDER
> > +        help
> > +          The CXL.mem protocol allows a device to act as a provider of
> > +          "System RAM" and/or "Persistent Memory" that is fully coherent
> > +          as if the memory was attached to the typical CPU memory
> > +          controller.
> > +
> > +          Say 'y/m' to enable a driver named "cxl_mem.ko" that will attach
> > +          to CXL.mem devices for configuration, provisioning, and health
> > +          monitoring, the so called "type-3 mailbox". Note, this driver
> > +          is required for dynamic provisioning of CXL.mem attached
> > +          memory, a pre-requisite for persistent memory support, but
> > +          devices that provide volatile memory may be fully described by
> > +          existing platform firmware memory enumeration.
> > +
> > +          If unsure say 'n'.
> >  endif
> > diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> > index d38cd34a2582..97fdffb00f2d 100644
> > --- a/drivers/cxl/Makefile
> > +++ b/drivers/cxl/Makefile
> > @@ -1,5 +1,7 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
> > +obj-$(CONFIG_CXL_MEM) += cxl_mem.o
> >
> >  ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
> >  cxl_acpi-y := acpi.o
> > +cxl_mem-y := mem.o
> > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > new file mode 100644
> > index 000000000000..aa7d881fa47b
> > --- /dev/null
> > +++ b/drivers/cxl/mem.c
> > @@ -0,0 +1,82 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > +#include <linux/module.h>
> > +#include <linux/pci.h>
> > +#include <linux/io.h>
> > +#include "acpi.h"
> > +#include "pci.h"
> > +
> > +struct cxl_mem {
> > +     void __iomem *regs;
> > +};
> > +
> > +static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> > +{
> > +     int pos;
> > +
> > +     pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DVSEC);
> > +     if (!pos)
> > +             return 0;
> > +
> > +     while (pos) {
> > +             u16 vendor, id;
> > +
> > +             pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, &vendor);
> > +             pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, &id);
> > +             if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> > +                     return pos;
> > +
> > +             pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
>
> This is good generic code and wouldn't cause much backport effort (even if needed
> to bring in a local copy), so perhaps make it a generic function and move to
> core PCI code?
>
> Mind you I guess that can happen the 'second' time someone wants to find a DVSEC.
>
> > +     }
> > +
> > +     return 0;
> > +}
> > +
> > +static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > +{
> > +     struct device *dev = &pdev->dev;
> > +     struct cxl_mem *cxlm;
> > +     int rc, regloc;
> > +
> > +     rc = cxl_bus_prepared(pdev);
> > +     if (rc != 0) {
> > +             dev_err(dev, "failed to acquire interface\n");
> > +             return rc;
> > +     }
> > +
> > +     regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
> > +     if (!regloc) {
> > +             dev_err(dev, "register location dvsec not found\n");
> > +             return -ENXIO;
> > +     }
> > +
> > +     cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> > +     if (!cxlm)
> > +             return -ENOMEM;
> > +
> > +     return 0;
> > +}
> > +
> > +static void cxl_mem_remove(struct pci_dev *pdev)
> > +{
> > +}
>
> I'd bring this in only when needed in later patch.
>
> > +
> > +static const struct pci_device_id cxl_mem_pci_tbl[] = {
> > +     /* PCI class code for CXL.mem Type-3 Devices */
> > +     { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> > +       PCI_CLASS_MEMORY_CXL, 0xffffff, 0 },
> > +     { /* terminate list */ },
> > +};
> > +MODULE_DEVICE_TABLE(pci, cxl_mem_pci_tbl);
> > +
> > +static struct pci_driver cxl_mem_driver = {
> > +     .name                   = KBUILD_MODNAME,
> > +     .id_table               = cxl_mem_pci_tbl,
> > +     .probe                  = cxl_mem_probe,
> > +     .remove                 = cxl_mem_remove,
> > +};
> > +
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_AUTHOR("Intel Corporation");
> > +module_pci_driver(cxl_mem_driver);
> > +MODULE_IMPORT_NS(CXL);
> > diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> > new file mode 100644
> > index 000000000000..beb03921e6da
> > --- /dev/null
> > +++ b/drivers/cxl/pci.h
> > @@ -0,0 +1,15 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > +#ifndef __CXL_PCI_H__
> > +#define __CXL_PCI_H__
> > +
> > +#define PCI_CLASS_MEMORY_CXL 0x050210
> > +
> > +#define PCI_EXT_CAP_ID_DVSEC 0x23
> > +#define PCI_DVSEC_VENDOR_CXL 0x1E98
>
> Hmm. The magic question of what to call a vendor ID that isn't a vendor
> ID but just a magic number that talks like a duck and quacks like a duck
> (for anyone wondering what I'm talking about, there is a nice bit of legal
> boilerplate on this in the CXL spec)
>
> This name is definitely not accurate however.
>
> PCI_UNIQUE_VALUE_CXL maybe?  It is used for other things than DVSEC (VDMs etc),
> though possibly this is the only software visible use.

Finally working my way back through this review to make the changes.
If 0x1E98 becomes visible to software somewhere else then this can
become something like the following:

#define PCI_DVSEC_VENDOR_CXL PCI_UNIQUE_VALUE_CXL

...or whatever the generic name is, but this field per the
specification is the DVSEC-vendor-id and calling it
PCI_UNIQUE_VALUE_CXL does not have any basis in the spec.

I will rename it though to:

PCI_DVSEC_VENDOR_ID_CXL

...since include/linux/pci_ids.h includes the _ID_ part.

>
>
> > +#define PCI_DVSEC_VENDOR_OFFSET      0x4
> > +#define PCI_DVSEC_ID_OFFSET  0x8
>
> Put a line break here perhaps and maybe a spec reference to where to find
> the various DVSEC IDs.

Ok.

>
> > +#define PCI_DVSEC_ID_CXL     0x0
>
> That's definitely a confusing name as well.

Yeah, should be PCI_DVSEC_DEVICE_ID_CXL

>
> PCI_DEVSEC_ID_CXL_DEVICE maybe?
>
>
> > +#define PCI_DVSEC_ID_CXL_REGLOC      0x8
> > +
> > +#endif /* __CXL_PCI_H__ */
>

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-12-04  7:22     ` Dan Williams
@ 2020-12-04  7:27       ` Dan Williams
  2020-12-04 17:39         ` Jonathan Cameron
  0 siblings, 1 reply; 73+ messages in thread
From: Dan Williams @ 2020-12-04  7:27 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Thu, Dec 3, 2020 at 11:22 PM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Tue, Nov 17, 2020 at 6:50 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Tue, 10 Nov 2020 21:43:50 -0800
> > Ben Widawsky <ben.widawsky@intel.com> wrote:
> >
> > > From: Dan Williams <dan.j.williams@intel.com>
> > >
> > > The CXL.mem protocol allows a device to act as a provider of "System
> > > RAM" and/or "Persistent Memory" that is fully coherent as if the memory
> > > was attached to the typical CPU memory controller.
> > >
> > > The memory range exported by the device may optionally be described by
> > > the platform firmware memory map, or by infrastructure like LIBNVDIMM to
> > > provision persistent memory capacity from one, or more, CXL.mem devices.
> > >
> > > A pre-requisite for Linux-managed memory-capacity provisioning is this
> > > cxl_mem driver that can speak the "type-3 mailbox" protocol.
> > >
> > > For now just land the driver boiler-plate and fill it in with
> > > functionality in subsequent commits.
> > >
> > > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> >
> > I've tried to avoid repeats, so mostly this is me moaning about naming!
> >
> > Jonathan
> >
> > > ---
> > >  drivers/cxl/Kconfig  | 20 +++++++++++
> > >  drivers/cxl/Makefile |  2 ++
> > >  drivers/cxl/mem.c    | 82 ++++++++++++++++++++++++++++++++++++++++++++
> > >  drivers/cxl/pci.h    | 15 ++++++++
> > >  4 files changed, 119 insertions(+)
> > >  create mode 100644 drivers/cxl/mem.c
> > >  create mode 100644 drivers/cxl/pci.h
> > >
> > > diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> > > index dd724bd364df..15548f5c77ff 100644
> > > --- a/drivers/cxl/Kconfig
> > > +++ b/drivers/cxl/Kconfig
> > > @@ -27,4 +27,24 @@ config CXL_ACPI
> > >         resources described by the CEDT (CXL Early Discovery Table)
> > >
> > >         Say 'y' to enable CXL (Compute Express Link) drivers.
> > > +
> > > +config CXL_MEM
> > > +        tristate "CXL.mem Device Support"
> > > +        depends on PCI && CXL_BUS_PROVIDER != n
> > > +        default m if CXL_BUS_PROVIDER
> > > +        help
> > > +          The CXL.mem protocol allows a device to act as a provider of
> > > +          "System RAM" and/or "Persistent Memory" that is fully coherent
> > > +          as if the memory was attached to the typical CPU memory
> > > +          controller.
> > > +
> > > +          Say 'y/m' to enable a driver named "cxl_mem.ko" that will attach
> > > +          to CXL.mem devices for configuration, provisioning, and health
> > > +          monitoring, the so called "type-3 mailbox". Note, this driver
> > > +          is required for dynamic provisioning of CXL.mem attached
> > > +          memory, a pre-requisite for persistent memory support, but
> > > +          devices that provide volatile memory may be fully described by
> > > +          existing platform firmware memory enumeration.
> > > +
> > > +          If unsure say 'n'.
> > >  endif
> > > diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> > > index d38cd34a2582..97fdffb00f2d 100644
> > > --- a/drivers/cxl/Makefile
> > > +++ b/drivers/cxl/Makefile
> > > @@ -1,5 +1,7 @@
> > >  # SPDX-License-Identifier: GPL-2.0
> > >  obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
> > > +obj-$(CONFIG_CXL_MEM) += cxl_mem.o
> > >
> > >  ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
> > >  cxl_acpi-y := acpi.o
> > > +cxl_mem-y := mem.o
> > > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > > new file mode 100644
> > > index 000000000000..aa7d881fa47b
> > > --- /dev/null
> > > +++ b/drivers/cxl/mem.c
> > > @@ -0,0 +1,82 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > > +#include <linux/module.h>
> > > +#include <linux/pci.h>
> > > +#include <linux/io.h>
> > > +#include "acpi.h"
> > > +#include "pci.h"
> > > +
> > > +struct cxl_mem {
> > > +     void __iomem *regs;
> > > +};
> > > +
> > > +static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> > > +{
> > > +     int pos;
> > > +
> > > +     pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DVSEC);
> > > +     if (!pos)
> > > +             return 0;
> > > +
> > > +     while (pos) {
> > > +             u16 vendor, id;
> > > +
> > > +             pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, &vendor);
> > > +             pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, &id);
> > > +             if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> > > +                     return pos;
> > > +
> > > +             pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_DVSEC);
> >
> > This is good generic code and wouldn't cause much backport effort (even if needed
> > to bring in a local copy), so perhaps make it a generic function and move to
> > core PCI code?
> >
> > Mind you I guess that can happen the 'second' time someone wants to find a DVSEC.
> >
> > > +     }
> > > +
> > > +     return 0;
> > > +}
> > > +
> > > +static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > > +{
> > > +     struct device *dev = &pdev->dev;
> > > +     struct cxl_mem *cxlm;
> > > +     int rc, regloc;
> > > +
> > > +     rc = cxl_bus_prepared(pdev);
> > > +     if (rc != 0) {
> > > +             dev_err(dev, "failed to acquire interface\n");
> > > +             return rc;
> > > +     }
> > > +
> > > +     regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
> > > +     if (!regloc) {
> > > +             dev_err(dev, "register location dvsec not found\n");
> > > +             return -ENXIO;
> > > +     }
> > > +
> > > +     cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> > > +     if (!cxlm)
> > > +             return -ENOMEM;
> > > +
> > > +     return 0;
> > > +}
> > > +
> > > +static void cxl_mem_remove(struct pci_dev *pdev)
> > > +{
> > > +}
> >
> > I'd bring this in only when needed in later patch.
> >
> > > +
> > > +static const struct pci_device_id cxl_mem_pci_tbl[] = {
> > > +     /* PCI class code for CXL.mem Type-3 Devices */
> > > +     { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> > > +       PCI_CLASS_MEMORY_CXL, 0xffffff, 0 },
> > > +     { /* terminate list */ },
> > > +};
> > > +MODULE_DEVICE_TABLE(pci, cxl_mem_pci_tbl);
> > > +
> > > +static struct pci_driver cxl_mem_driver = {
> > > +     .name                   = KBUILD_MODNAME,
> > > +     .id_table               = cxl_mem_pci_tbl,
> > > +     .probe                  = cxl_mem_probe,
> > > +     .remove                 = cxl_mem_remove,
> > > +};
> > > +
> > > +MODULE_LICENSE("GPL v2");
> > > +MODULE_AUTHOR("Intel Corporation");
> > > +module_pci_driver(cxl_mem_driver);
> > > +MODULE_IMPORT_NS(CXL);
> > > diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> > > new file mode 100644
> > > index 000000000000..beb03921e6da
> > > --- /dev/null
> > > +++ b/drivers/cxl/pci.h
> > > @@ -0,0 +1,15 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > > +#ifndef __CXL_PCI_H__
> > > +#define __CXL_PCI_H__
> > > +
> > > +#define PCI_CLASS_MEMORY_CXL 0x050210
> > > +
> > > +#define PCI_EXT_CAP_ID_DVSEC 0x23
> > > +#define PCI_DVSEC_VENDOR_CXL 0x1E98
> >
> > Hmm. The magic question of what to call a vendor ID that isn't a vendor
> > ID but just a magic number that talks like a duck and quacks like a duck
> > (for anyone wondering what I'm talking about, there is a nice bit of legal
> > boilerplate on this in the CXL spec)
> >
> > This name is definitely not accurate however.
> >
> > PCI_UNIQUE_VALUE_CXL maybe?  It is used for other things than DVSEC (VDMs etc),
> > though possibly this is the only software visible use.
>
> Finally working my way back through this review to make the changes.
> If 0x1E98 becomes visible to software somewhere else then this can
> become something like the following:
>
> #define PCI_DVSEC_VENDOR_CXL PCI_UNIQUE_VALUE_CXL
>
> ...or whatever the generic name is, but this field per the
> specification is the DVSEC-vendor-id and calling it
> PCI_UNIQUE_VALUE_CXL does not have any basis in the spec.
>
> I will rename it though to:
>
> PCI_DVSEC_VENDOR_ID_CXL
>
> ...since include/linux/pci_ids.h includes the _ID_ part.
>
> >
> >
> > > +#define PCI_DVSEC_VENDOR_OFFSET      0x4
> > > +#define PCI_DVSEC_ID_OFFSET  0x8
> >
> > Put a line break here perhaps and maybe a spec reference to where to find
> > the various DVSEC IDs.
>
> Ok.
>
> >
> > > +#define PCI_DVSEC_ID_CXL     0x0
> >
> > That's definitely a confusing name as well.
>
> Yeah, should be PCI_DVSEC_DEVICE_ID_CXL

Actually, no, the spec calls this the "DVSEC id" so PCI_DVSEC_ID_CXL
seems suitable to me. This is from:

Table 126. PCI Express DVSEC Register Settings for CXL Device

In the CXL 2.0 Specification.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities
  2020-11-26  6:05   ` Jon Masters
  2020-11-26 18:18     ` Ben Widawsky
@ 2020-12-04  7:35     ` Dan Williams
  1 sibling, 0 replies; 73+ messages in thread
From: Dan Williams @ 2020-12-04  7:35 UTC (permalink / raw)
  To: Jon Masters
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

On Wed, Nov 25, 2020 at 10:06 PM Jon Masters <jcm@jonmasters.org> wrote:
>
> On 11/11/20 12:43 AM, Ben Widawsky wrote:
>
> > +             case CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX:
> > +                     dev_dbg(&cxlm->pdev->dev,
> > +                                "found UNSUPPORTED Secondary Mailbox capability\n");
>
> Per spec, the secondary mailbox is intended for use by platform
> firmware, so Linux should never be using it anyway. Maybe that message
> is slightly misleading?
>
> Jon.
>
> P.S. Related - I've severe doubts about the mailbox approach being
> proposed by CXL and have begun to push back through the spec org.

The more Linux software voices the better. At the same time the spec
is released so we're into xkcd territory [1] of what the driver will
be expected to support for any future improvements.

[1]: https://xkcd.com/927/

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities
  2020-11-11  5:43 ` [RFC PATCH 5/9] cxl/mem: Find device capabilities Ben Widawsky
                     ` (2 preceding siblings ...)
  2020-11-26  6:05   ` Jon Masters
@ 2020-12-04  7:41   ` Dan Williams
  2020-12-07  6:12     ` Ben Widawsky
  3 siblings, 1 reply; 73+ messages in thread
From: Dan Williams @ 2020-12-04  7:41 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: linux-cxl, Linux Kernel Mailing List, Linux PCI, Linux ACPI,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On Tue, Nov 10, 2020 at 9:44 PM Ben Widawsky <ben.widawsky@intel.com> wrote:
>
> CXL devices contain an array of capabilities that describe the
> interactions software can interact with the device, or firmware running
> on the device. A CXL compliant device must implement the device status
> and the mailbox capability. A CXL compliant memory device must implement
> the memory device capability.
>
> Each of the capabilities can [will] provide an offset within the MMIO
> region for interacting with the CXL device.
>
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> ---
>  drivers/cxl/cxl.h | 89 +++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/cxl/mem.c | 58 +++++++++++++++++++++++++++---
>  2 files changed, 143 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/cxl/cxl.h
>
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> new file mode 100644
> index 000000000000..02858ae63d6d
> --- /dev/null
> +++ b/drivers/cxl/cxl.h
[..]
> +static inline u32 __cxl_raw_read_reg32(struct cxl_mem *cxlm, u32 reg)

Going through my reworks and the "raw" jumped out at me. My typical
interpretation of "raw" in respect to register access macros is the
difference between readl() and __raw_readl()  which means "don't do
bus endian swizzling, and don't do a memory clobber barrier". Any
heartburn to drop the "raw"?

...is it only me that reacts that way?

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
  2020-12-04  7:27       ` Dan Williams
@ 2020-12-04 17:39         ` Jonathan Cameron
  0 siblings, 0 replies; 73+ messages in thread
From: Jonathan Cameron @ 2020-12-04 17:39 UTC (permalink / raw)
  To: Dan Williams
  Cc: Ben Widawsky, linux-cxl, Linux Kernel Mailing List, Linux PCI,
	Linux ACPI, Ira Weiny, Vishal Verma, Kelley, Sean V,
	Bjorn Helgaas, Rafael J . Wysocki

...

> > > > +MODULE_IMPORT_NS(CXL);
> > > > diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> > > > new file mode 100644
> > > > index 000000000000..beb03921e6da
> > > > --- /dev/null
> > > > +++ b/drivers/cxl/pci.h
> > > > @@ -0,0 +1,15 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > > > +#ifndef __CXL_PCI_H__
> > > > +#define __CXL_PCI_H__
> > > > +
> > > > +#define PCI_CLASS_MEMORY_CXL 0x050210
> > > > +
> > > > +#define PCI_EXT_CAP_ID_DVSEC 0x23
> > > > +#define PCI_DVSEC_VENDOR_CXL 0x1E98  
> > >
> > > Hmm. The magic question of what to call a vendor ID that isn't a vendor
> > > ID but just a magic number that talks like a duck and quacks like a duck
> > > (for anyone wondering what I'm talking about, there is a nice bit of legal
> > > boilerplate on this in the CXL spec)
> > >
> > > This name is definitely not accurate however.
> > >
> > > PCI_UNIQUE_VALUE_CXL maybe?  It is used for other things than DVSEC (VDMs etc),
> > > though possibly this is the only software visible use.  
> >
> > Finally working my way back through this review to make the changes.
> > If 0x1E98 becomes visible to software somewhere else then this can
> > become something like the following:
> >
> > #define PCI_DVSEC_VENDOR_CXL PCI_UNIQUE_VALUE_CXL
> >
> > ...or whatever the generic name is, but this field per the
> > specification is the DVSEC-vendor-id and calling it
> > PCI_UNIQUE_VALUE_CXL does not have any basis in the spec.

There is a big statement about it as a footnote to 3.1.2 in CXL 2.0
"The Unique Value that is provided in this specification for use in ...
Designated Vendor Specific Extended Capabilities.."  And for extra
amusement in the "Notice Regarding PCI-SIG Unique Value" that forms
part of the click through
https://www.computeexpresslink.org/download-the-specification
(that's the only use of "PCI-SIG Unique Value" that Google finds
 but I know of one other similar statement)

However, I agree it's being used in DVSEC field only (from software
point of view) so fair enough to name it after where it is used
rather than what it is.

> >
> > I will rename it though to:
> >
> > PCI_DVSEC_VENDOR_ID_CXL
> >
> > ...since include/linux/pci_ids.h includes the _ID_ part.
> >  
> > >
> > >  
> > > > +#define PCI_DVSEC_VENDOR_OFFSET      0x4
> > > > +#define PCI_DVSEC_ID_OFFSET  0x8  
> > >
> > > Put a line break here perhaps and maybe a spec reference to where to find
> > > the various DVSEC IDs.  
> >
> > Ok.
> >  
> > >  
> > > > +#define PCI_DVSEC_ID_CXL     0x0  
> > >
> > > That's definitely a confusing name as well.  
> >
> > Yeah, should be PCI_DVSEC_DEVICE_ID_CXL  
> 
> Actually, no, the spec calls this the "DVSEC id" so PCI_DVSEC_ID_CXL
> seems suitable to me. This is from:
> 
> Table 126. PCI Express DVSEC Register Settings for CXL Device
> 
> In the CXL 2.0 Specification.

The DVSEC ID naming is straight from the PCI spec so that part is fine,
my issue is this is one of a whole bunch of CXL related DVSEC ID so it
needs a more specific name.

PCI_DVSEC_ID_CXL_DEVICE would work in line with table 124.

I'm not that bothered though.

Jonathan



^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities
  2020-12-04  7:41   ` Dan Williams
@ 2020-12-07  6:12     ` Ben Widawsky
  0 siblings, 0 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-12-07  6:12 UTC (permalink / raw)
  To: Dan Williams
  Cc: linux-cxl, Linux Kernel Mailing List, Linux PCI, Linux ACPI,
	Ira Weiny, Vishal Verma, Kelley, Sean V, Bjorn Helgaas,
	Rafael J . Wysocki

On 20-12-03 23:41:16, Dan Williams wrote:
> On Tue, Nov 10, 2020 at 9:44 PM Ben Widawsky <ben.widawsky@intel.com> wrote:
> >
> > CXL devices contain an array of capabilities that describe the
> > interactions software can interact with the device, or firmware running
> > on the device. A CXL compliant device must implement the device status
> > and the mailbox capability. A CXL compliant memory device must implement
> > the memory device capability.
> >
> > Each of the capabilities can [will] provide an offset within the MMIO
> > region for interacting with the CXL device.
> >
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > ---
> >  drivers/cxl/cxl.h | 89 +++++++++++++++++++++++++++++++++++++++++++++++
> >  drivers/cxl/mem.c | 58 +++++++++++++++++++++++++++---
> >  2 files changed, 143 insertions(+), 4 deletions(-)
> >  create mode 100644 drivers/cxl/cxl.h
> >
> > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> > new file mode 100644
> > index 000000000000..02858ae63d6d
> > --- /dev/null
> > +++ b/drivers/cxl/cxl.h
> [..]
> > +static inline u32 __cxl_raw_read_reg32(struct cxl_mem *cxlm, u32 reg)
> 
> Going through my reworks and the "raw" jumped out at me. My typical
> interpretation of "raw" in respect to register access macros is the
> difference between readl() and __raw_readl()  which means "don't do
> bus endian swizzling, and don't do a memory clobber barrier". Any
> heartburn to drop the "raw"?
> 
> ...is it only me that reacts that way?

I will drop "raw". Especially given that I intend to reuse the word in v2 for
something entirely different, it makes sense.

My idea of "raw" was that it's just unfettered access to the device's MMIO
space. No offsets, no checks. I'm not sure of a better adjective to describe
that, but if you have any in mind, I'd like to add it.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 0/9] CXL 2.0 Support
  2020-12-07  4:40       ` Chris Browy
@ 2020-12-09  0:48         ` Ben Widawsky
  0 siblings, 0 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-12-09  0:48 UTC (permalink / raw)
  To: Chris Browy
  Cc: bhelgaas, dan.j.williams, ira.weiny, linux-acpi, linux-cxl,
	linux-kernel, linux-pci, rafael.j.wysocki, sean.v.kelley,
	vishal.l.verma

On 20-12-06 23:40:47, Chris Browy wrote:
> Hi Ben,
> 
> 
> >On Dec 4, 2020, at 1:12 PM, Ben Widawsky <mailto:ben.widawsky@intel.com> wrote:
> >
> >Hi Chris.
> >
> >On 20-12-04 12:40:03, Chris Browy wrote:
> >
> >Hi Ben,
> >
> >Trying to bring up the environment using the latest developments as follows:
> >
> >1. Linux kernel baseline version is cloned using
> >     git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> >   Using master branch.  Merged the 9 CXL linux kernel patches manually and built kernel
> >
> >2. QEMU baseline version is cloned using
> >     git clone https://gitlab.com/bwidawsk/qemu.git
> >
> >3. UEFI baseline is cloned using
> >     git clone https://github.com/tianocore/edk2.git
> >   Using master and built
> >
> >4. Now can run qemu as follows:
> >     The qcow2 we use is based on Ubuntu 20.10 with updated with kernel from 1) above
> >
> >     QEMU command:
> >
> >     sudo qemu-system-x86_64 -nic \
> >     user,hostfwd=tcp::2222-:22,hostfwd=tcp::1234-:1234 -machine \
> >     type=pc-q35-4.0,hmat=on,accel=kvm -enable-kvm -cpu host -smp \
> >     6,cores=6,threads=1,sockets=1 -m 8G -boot order=d -k 'en-us' -vga virtio \
> >     -drive file=/home/chris/Downloads/AQCXL/ubuntu_20.qcow,format=qcow2 -drive \
> >     if=pflash,format=raw,readonly,file=/home/chris/OVMF_CODE.fd \
> >     -drive if=pflash,format=raw,file=/home/chris/OVMF_VARS.fd \
> >     -object memory-backend-file,id=cxl-mem1,share,mem-path=/tmp/cxl-test/cxl,size=512M \
> >     -device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52,uid=0,len-window-base=1,\
> >     window-base[0]=0x4c0000000,memdev[0]=cxl-mem1 \
> >     -device cxl-rp,id=rp0,bus=cxl.0,addr=0.0,chassis=0,slot=0  \
> >     -device cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M  2>&1 | tee -a \
> >     /home/chris/Downloads/AQCXL/log/qemu.log
> >
> >   The qemu options are derived from looking at the tests/qtests/cxl-test.c
> >   along with the -hmat=on which seemed to make sense.
> >
> >   The system boots and lspci -vvv shows the CXL device is enumerated.  But
> >   no DOE capability register for CDAT access though (see below).  Otherwise the
> >   DVSEC registers are present.
> >
> >DOE is not supported yet in either Linux or QEMU. For us, CDAT isn't a high
> >priority yet so it likely won't be done for a while. I'd really like to see DOE
> >support added by someone - not me - so that we can wire it up. Not sure what
> >that would look like in the QEMU side.
> >
> >
> >
> >   acpidump indicates the CXL0 and CXLM devices but no SRAT or HMAT tables are
> >   in the dump which is curious.
> >
> >I don't typically use HMAT, but I do have an SRAT in mine, so that's strange.
> >You should also have a CEDT.
> >
> Could you provide the QEMU command line?  I was not successful adding numa node for cxl-mem1
> and RAM.  Leaving out numa node for cxl-mem1 I can now see  SRAT table being created but that’s
> not exactly the point.
> 
> Are you using UEFI or legacy BIOS to boot?
> 
> Reproducing a known working environment is better for now and then deviate for trying new
> configurations.

I'm using UEFI. I haven't built my own in a while. The script we use to run QEMU
pulls whatever is here: https://www.archlinux.org/packages/extra/any/edk2-ovmf/download/

-machine q35,accel=kvm,nvdimm,cxl
-m 8192M,slots=4,maxmem=40964M
-smp 8,sockets=2,cores=2,threads=2
-enable-kvm
-display none
-nographic
-drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd
-debugcon file:uefi_debug.log
-global isa-debugcon.iobase=0x402
-drive file=root.img,format=raw,media=disk
-kernel ./mkosi.extra/boot/vmlinuz
-initrd mkosi.extra/boot/initramfs-5.10.0-rc2-BEN-00016-geb5b35e092af-dirty.img
-append selinux=0 audit=0 console=tty0 console=ttyS0 root=/dev/sda2 ignore_loglevel rw dyndbg="file drivers/cxl/mem.c +p"
-device e1000,netdev=net0,mac=52:54:00:12:34:56
-netdev user,id=net0,hostfwd=tcp::10022-:22
-object memory-backend-file,id=cxl-mem1,share,mem-path=cxl-type3,size=512M
-device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52,uid=0,len-window-base=1,window-base[0]=0x4c0000000,memdev[0]=cxl-mem1
-device cxl-rp,id=rp0,bus=cxl.0,addr=0.0,chassis=0,slot=0
-device cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M
-snapshot
-object memory-backend-ram,id=mem0,size=2048M
-numa node,nodeid=0,memdev=mem0,
-numa cpu,node-id=0,socket-id=0
-object memory-backend-ram,id=mem1,size=2048M
-numa node,nodeid=1,memdev=mem1,
-numa cpu,node-id=1,socket-id=1
-object memory-backend-ram,id=mem2,size=2048M
-numa node,nodeid=2,memdev=mem2,
-object memory-backend-ram,id=mem3,size=2048M
-numa node,nodeid=3,memdev=mem3,
-numa node,nodeid=4,
-object memory-backend-file,id=nvmem0,share,mem-path=nvdimm-0,size=16384M,align=1G
-device nvdimm,memdev=nvmem0,id=nv0,label-size=2M,node=4
-numa node,nodeid=5,
-object memory-backend-file,id=nvmem1,share,mem-path=nvdimm-1,size=16384M,align=1G
-device nvdimm,memdev=nvmem1,id=nv1,label-size=2M,node=5
-numa dist,src=0,dst=0,val=10
-numa dist,src=0,dst=1,val=21
-numa dist,src=0,dst=2,val=12
-numa dist,src=0,dst=3,val=21
-numa dist,src=0,dst=4,val=17
-numa dist,src=0,dst=5,val=28
-numa dist,src=1,dst=1,val=10
-numa dist,src=1,dst=2,val=21
-numa dist,src=1,dst=3,val=12
-numa dist,src=1,dst=4,val=28
-numa dist,src=1,dst=5,val=17
-numa dist,src=2,dst=2,val=10
-numa dist,src=2,dst=3,val=21
-numa dist,src=2,dst=4,val=28
-numa dist,src=2,dst=5,val=28
-numa dist,src=3,dst=3,val=10
-numa dist,src=3,dst=4,val=28
-numa dist,src=3,dst=5,val=28
-numa dist,src=4,dst=4,val=10
-numa dist,src=4,dst=5,val=28
-numa dist,src=5,dst=5,val=10


> 
> >
> >
> >35:00.0 Memory controller [0502]: Intel Corporation Device 0d93 (rev 01) (prog-if 10)
> >    Subsystem: Red Hat, Inc. Device 1100
> >    Physical Slot: 0
> >    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> >    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> >    Latency: 0
> >    Region 0: Memory at c0a00000 (64-bit, non-prefetchable) [size=64K]
> >    Region 2: Memory at c0a10000 (64-bit, non-prefetchable) [size=4K]
> >    Capabilities: [80] Express (v2) Endpoint, MSI 00
> >        DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
> >            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
> >        DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
> >            RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> >            MaxPayload 128 bytes, MaxReadReq 128 bytes
> >        DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
> >        LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns
> >            ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> >        LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> >            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> >        LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
> >            TrErr- Train- SlotClk- DLActive+ BWMgmt- ABWMgmt-
> >        DevCap2: Completion Timeout: Not Supported, TimeoutDis-, NROPrPrP-, LTR-
> >             10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt+, EETLPPrefix+, MaxEETLPPrefixes 4
> >               EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
> >             FRS-, TPHComp-, ExtTPHComp-
> >             AtomicOpsCap: 32bit- 64bit- 128bitCAS-
> >        DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
> >             AtomicOpsCtl: ReqEn-
> >        LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
> >             Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
> >             Compliance De-emphasis: -6dB
> >        LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
> >             EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
> >    Capabilities: [100 v1] Designated Vendor-Specific <?>
> >    Capabilities: [138 v1] Designated Vendor-Specific <?>
> >    Kernel driver in use: cxl_mem
> Can you check this in the QEMU cxl_component_register_init_common() in cxl-component-utils.c
> 
> 
> I used devmem2 to dump out CLX Component CLX.mem regsisters located at BAR + 0x1000. Header
> List:
>      04110000 CXL CAP
>      08010002 CXL RAS
>      0D820004 CXL Link
>      11010005 CXL HDM Decoder
>      00000000
> 
> I think the 1st entry is the CXL Cap Header List should be
> 0x03110001
> 
> 
> Capability_ID looks like it is set using ARRAY_FIELD_DP32
> 
>     /* CXL Capability Header Register */
>     ARRAY_FIELD_DP32(reg_state, CXL_CAPABILITY_HEADER, ID, 1);
>     ARRAY_FIELD_DP32(reg_state, CXL_CAPABILITY_HEADER, VERSION, 1);
>     ARRAY_FIELD_DP32(reg_state, CXL_CAPABILITY_HEADER, CACHE_MEM_VERSION, 1);
>     ARRAY_FIELD_DP32(reg_state, CXL_CAPABILITY_HEADER, ARRAY_SIZE, caps);
> 
> 
> But value reported for ID is ‘0’.
> 
> Since there are only RAS, LINK, and HDM headers found the Array_Size should be ‘3’
> according to the spec:
> 
> Array_Size: This defines the number of elements present in
> the CXL_Capability array, not including the
> CXL_Capability_Header element. Each element is 1 DWORD in
> size and is located contiguous with previous elements.
> 
> 
> ‘caps’ should one less that calculated in switch statement
> 
>  96 void cxl_component_register_init_common(uint32_t *reg_state, enum reg_type type)
>  97 {
>  98     int caps = 0;
>  99     switch (type) {
> 100     case CXL2_DOWNSTREAM_PORT:
> 101     case CXL2_DEVICE:
> 102         /* CAP, RAS, Link */
> 103         caps = 3;
> 104         break;
> 105     case CXL2_UPSTREAM_PORT:
> 106     case CXL2_TYPE3_DEVICE:
> 107     case CXL2_LOGICAL_DEVICE:
> 108         /* + HDM */
> 109         caps = 4;
> 110         break;
> 111     case CXL2_ROOT_PORT:
> 112         /* + Extended Security, + Snoop */
> 113         caps = 6;
> 114         break;
> 115     default:
> 116         abort();
> 117     }
> 
> 

You're correct. I've fixed it and pushed it to the v2 branch.

> >
> >Questions/Comments:
> >-------------------
> >1. Linux
> >  a. Is there a gitlab for the linux kernel patches for CXL?  This would
> >     facilitate review and code modifications.
> >
> >We're hopefully going to send out v2 in the next couple of days. I'll push the
> >repo somewhere as well.
> >
> That’s great!
> 
> >
> >
> >
> >2. UEFI (edk2 from tianocore)
> >  a. seems to only support CXL 1.1 which means only method #1 (Device
> >     option ROM) of Coherent Device Attribute Table_1.02 spec
> >     for CDAT handling is possible now.
> >
> >     Does device option ROM need to be added to QEMU CXL setup?
> >
> >     Can we add a CXL 1.1 emulated device?
> >
> >Patches welcome :-). I know of other people who want this, but I only care about
> >2.0+, so I have no intention to implement it.
> Can you summarize how the System Physical Address (SPA) gets assigned to the
> CXL pmem if not by the UEFI or CXL driver methods?

The PMEM address isn't currently assigned. It expects the driver to program the
HDMs. However, for testing I faked this a bit, grep for SET_PMEM_PADDR. I did
have a tool I used to verify the HDM programming, but it appears that's been
lost to the sands of time.


> 
> Is it some alternate method using host bridge window-base and then
> cxl_realize() in cxl_type3.c.
> 
> -device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52,uid=0,len-window-base=1, \
>  window-base[0]=0x4c0000000,memdev[0]=cxl-mem1 \
> 
> The QEMU command would inform a lot especially whether you
> create 2 backend memories with numa nodes to models
> RAM and PMEM?
> 
> Eventually the CXL driver would need to handle hot plug of
> CT3D and access CDAT from the CT3D via DOE Mailbox.
> 
> As Dan mentions about Coherent Device Attribute Table (CDAT) Specification r1.02
> requires CDAT to build the SRAT/HMAT statically and dynamically
>  - Figure 1 Pre-boot CDAT Extraction Method (for CXL devices)  (uses CDAT in option ROM)
>  - Figure 2 OS Runtime CDAT Extraction Method (for CXL devices  (uses DOE mailbox)
> 
> >
> >
> >
> >
> >  b. lspci doesn’t show the existence of the DOE extended capability register
> >     in the CXL CT3D (needed to support method #2).  Are there more patches?
> >
> >As above, it's not supported. I'm hoping someone else will do that work since I
> >don't care about it just yet.
> 
> We can get a start on some QEMU updates to support DOE mailbox access.
> 
> >
> >
> >
> >
> >3. Do you have example user programs to share or better yet the CXL 2.0
> >   Sec 14.3.6.1 Application Layer/ Transaction layer test for CXL.mem?
> >
> >I don't have, mostly because I haven't actually implemented a lot of the real
> >CXL support. My primary concern was having the Linux driver be able to enumerate
> >devices and communicate with the device via the mailbox interface. v2 will
> >contain support for userspace to do this, which I think is a step toward what
> >you're asking for.
> >
> Understood. Looking forward to v2 and linux branch!  Working from a known good
> reference environment will allow for more in depth code review.
> 
> 
> >
> >
> >4. What are the userspace system APIs for targeting CXL HDM address domain?
> >   Usually you can mmap a SPA if you know how to look it up.
> >
> >I think Dan answered this in the other thread…
> 
> Correct 
> 
> 
> Best Regards,
> Chris Browy
> 
> 
> 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 0/9] CXL 2.0 Support
       [not found]     ` <B4FDE6CB-DA00-4F58-AA9F-F04E678E076B@avery-design.com>
@ 2020-12-07  4:40       ` Chris Browy
  2020-12-09  0:48         ` Ben Widawsky
  0 siblings, 1 reply; 73+ messages in thread
From: Chris Browy @ 2020-12-07  4:40 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: bhelgaas, dan.j.williams, ira.weiny, linux-acpi, linux-cxl,
	linux-kernel, linux-pci, rafael.j.wysocki, sean.v.kelley,
	vishal.l.verma

Hi Ben,


>On Dec 4, 2020, at 1:12 PM, Ben Widawsky <mailto:ben.widawsky@intel.com> wrote:
>
>Hi Chris.
>
>On 20-12-04 12:40:03, Chris Browy wrote:
>
>Hi Ben,
>
>Trying to bring up the environment using the latest developments as follows:
>
>1. Linux kernel baseline version is cloned using
>     git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
>   Using master branch.  Merged the 9 CXL linux kernel patches manually and built kernel
>
>2. QEMU baseline version is cloned using
>     git clone https://gitlab.com/bwidawsk/qemu.git
>
>3. UEFI baseline is cloned using
>     git clone https://github.com/tianocore/edk2.git
>   Using master and built
>
>4. Now can run qemu as follows:
>     The qcow2 we use is based on Ubuntu 20.10 with updated with kernel from 1) above
>
>     QEMU command:
>
>     sudo qemu-system-x86_64 -nic \
>     user,hostfwd=tcp::2222-:22,hostfwd=tcp::1234-:1234 -machine \
>     type=pc-q35-4.0,hmat=on,accel=kvm -enable-kvm -cpu host -smp \
>     6,cores=6,threads=1,sockets=1 -m 8G -boot order=d -k 'en-us' -vga virtio \
>     -drive file=/home/chris/Downloads/AQCXL/ubuntu_20.qcow,format=qcow2 -drive \
>     if=pflash,format=raw,readonly,file=/home/chris/OVMF_CODE.fd \
>     -drive if=pflash,format=raw,file=/home/chris/OVMF_VARS.fd \
>     -object memory-backend-file,id=cxl-mem1,share,mem-path=/tmp/cxl-test/cxl,size=512M \
>     -device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52,uid=0,len-window-base=1,\
>     window-base[0]=0x4c0000000,memdev[0]=cxl-mem1 \
>     -device cxl-rp,id=rp0,bus=cxl.0,addr=0.0,chassis=0,slot=0  \
>     -device cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M  2>&1 | tee -a \
>     /home/chris/Downloads/AQCXL/log/qemu.log
>
>   The qemu options are derived from looking at the tests/qtests/cxl-test.c
>   along with the -hmat=on which seemed to make sense.
>
>   The system boots and lspci -vvv shows the CXL device is enumerated.  But
>   no DOE capability register for CDAT access though (see below).  Otherwise the
>   DVSEC registers are present.
>
>DOE is not supported yet in either Linux or QEMU. For us, CDAT isn't a high
>priority yet so it likely won't be done for a while. I'd really like to see DOE
>support added by someone - not me - so that we can wire it up. Not sure what
>that would look like in the QEMU side.
>
>
>
>   acpidump indicates the CXL0 and CXLM devices but no SRAT or HMAT tables are
>   in the dump which is curious.
>
>I don't typically use HMAT, but I do have an SRAT in mine, so that's strange.
>You should also have a CEDT.
>
Could you provide the QEMU command line?  I was not successful adding numa node for cxl-mem1
and RAM.  Leaving out numa node for cxl-mem1 I can now see  SRAT table being created but that’s
not exactly the point.

Are you using UEFI or legacy BIOS to boot?

Reproducing a known working environment is better for now and then deviate for trying new
configurations.

>
>
>35:00.0 Memory controller [0502]: Intel Corporation Device 0d93 (rev 01) (prog-if 10)
>    Subsystem: Red Hat, Inc. Device 1100
>    Physical Slot: 0
>    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>    Latency: 0
>    Region 0: Memory at c0a00000 (64-bit, non-prefetchable) [size=64K]
>    Region 2: Memory at c0a10000 (64-bit, non-prefetchable) [size=4K]
>    Capabilities: [80] Express (v2) Endpoint, MSI 00
>        DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
>        DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
>            RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
>            MaxPayload 128 bytes, MaxReadReq 128 bytes
>        DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
>        LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns
>            ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
>        LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
>            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>        LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
>            TrErr- Train- SlotClk- DLActive+ BWMgmt- ABWMgmt-
>        DevCap2: Completion Timeout: Not Supported, TimeoutDis-, NROPrPrP-, LTR-
>             10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt+, EETLPPrefix+, MaxEETLPPrefixes 4
>               EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
>             FRS-, TPHComp-, ExtTPHComp-
>             AtomicOpsCap: 32bit- 64bit- 128bitCAS-
>        DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
>             AtomicOpsCtl: ReqEn-
>        LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
>             Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
>             Compliance De-emphasis: -6dB
>        LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
>             EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
>    Capabilities: [100 v1] Designated Vendor-Specific <?>
>    Capabilities: [138 v1] Designated Vendor-Specific <?>
>    Kernel driver in use: cxl_mem
Can you check this in the QEMU cxl_component_register_init_common() in cxl-component-utils.c


I used devmem2 to dump out CLX Component CLX.mem regsisters located at BAR + 0x1000. Header
List:
     04110000 CXL CAP
     08010002 CXL RAS
     0D820004 CXL Link
     11010005 CXL HDM Decoder
     00000000

I think the 1st entry is the CXL Cap Header List should be
0x03110001


Capability_ID looks like it is set using ARRAY_FIELD_DP32

    /* CXL Capability Header Register */
    ARRAY_FIELD_DP32(reg_state, CXL_CAPABILITY_HEADER, ID, 1);
    ARRAY_FIELD_DP32(reg_state, CXL_CAPABILITY_HEADER, VERSION, 1);
    ARRAY_FIELD_DP32(reg_state, CXL_CAPABILITY_HEADER, CACHE_MEM_VERSION, 1);
    ARRAY_FIELD_DP32(reg_state, CXL_CAPABILITY_HEADER, ARRAY_SIZE, caps);


But value reported for ID is ‘0’.

Since there are only RAS, LINK, and HDM headers found the Array_Size should be ‘3’
according to the spec:

Array_Size: This defines the number of elements present in
the CXL_Capability array, not including the
CXL_Capability_Header element. Each element is 1 DWORD in
size and is located contiguous with previous elements.


‘caps’ should one less that calculated in switch statement

 96 void cxl_component_register_init_common(uint32_t *reg_state, enum reg_type type)
 97 {
 98     int caps = 0;
 99     switch (type) {
100     case CXL2_DOWNSTREAM_PORT:
101     case CXL2_DEVICE:
102         /* CAP, RAS, Link */
103         caps = 3;
104         break;
105     case CXL2_UPSTREAM_PORT:
106     case CXL2_TYPE3_DEVICE:
107     case CXL2_LOGICAL_DEVICE:
108         /* + HDM */
109         caps = 4;
110         break;
111     case CXL2_ROOT_PORT:
112         /* + Extended Security, + Snoop */
113         caps = 6;
114         break;
115     default:
116         abort();
117     }


>
>Questions/Comments:
>-------------------
>1. Linux
>  a. Is there a gitlab for the linux kernel patches for CXL?  This would
>     facilitate review and code modifications.
>
>We're hopefully going to send out v2 in the next couple of days. I'll push the
>repo somewhere as well.
>
That’s great!

>
>
>
>2. UEFI (edk2 from tianocore)
>  a. seems to only support CXL 1.1 which means only method #1 (Device
>     option ROM) of Coherent Device Attribute Table_1.02 spec
>     for CDAT handling is possible now.
>
>     Does device option ROM need to be added to QEMU CXL setup?
>
>     Can we add a CXL 1.1 emulated device?
>
>Patches welcome :-). I know of other people who want this, but I only care about
>2.0+, so I have no intention to implement it.
Can you summarize how the System Physical Address (SPA) gets assigned to the
CXL pmem if not by the UEFI or CXL driver methods?

Is it some alternate method using host bridge window-base and then
cxl_realize() in cxl_type3.c.

-device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52,uid=0,len-window-base=1, \
 window-base[0]=0x4c0000000,memdev[0]=cxl-mem1 \

The QEMU command would inform a lot especially whether you
create 2 backend memories with numa nodes to models
RAM and PMEM?

Eventually the CXL driver would need to handle hot plug of
CT3D and access CDAT from the CT3D via DOE Mailbox.

As Dan mentions about Coherent Device Attribute Table (CDAT) Specification r1.02
requires CDAT to build the SRAT/HMAT statically and dynamically
 - Figure 1 Pre-boot CDAT Extraction Method (for CXL devices)  (uses CDAT in option ROM)
 - Figure 2 OS Runtime CDAT Extraction Method (for CXL devices  (uses DOE mailbox)

>
>
>
>
>  b. lspci doesn’t show the existence of the DOE extended capability register
>     in the CXL CT3D (needed to support method #2).  Are there more patches?
>
>As above, it's not supported. I'm hoping someone else will do that work since I
>don't care about it just yet.

We can get a start on some QEMU updates to support DOE mailbox access.

>
>
>
>
>3. Do you have example user programs to share or better yet the CXL 2.0
>   Sec 14.3.6.1 Application Layer/ Transaction layer test for CXL.mem?
>
>I don't have, mostly because I haven't actually implemented a lot of the real
>CXL support. My primary concern was having the Linux driver be able to enumerate
>devices and communicate with the device via the mailbox interface. v2 will
>contain support for userspace to do this, which I think is a step toward what
>you're asking for.
>
Understood. Looking forward to v2 and linux branch!  Working from a known good
reference environment will allow for more in depth code review.


>
>
>4. What are the userspace system APIs for targeting CXL HDM address domain?
>   Usually you can mmap a SPA if you know how to look it up.
>
>I think Dan answered this in the other thread…

Correct 


Best Regards,
Chris Browy




^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 0/9] CXL 2.0 Support
  2020-12-04 19:26     ` Verma, Vishal L
@ 2020-12-04 19:45       ` Dan Williams
  0 siblings, 0 replies; 73+ messages in thread
From: Dan Williams @ 2020-12-04 19:45 UTC (permalink / raw)
  To: Verma, Vishal L
  Cc: Widawsky, Ben, cbrowy, Kelley, Sean V, Weiny, Ira, linux-cxl,
	linux-kernel, Wysocki, Rafael J, linux-pci, bhelgaas, linux-acpi

On Fri, Dec 4, 2020 at 11:26 AM Verma, Vishal L
<vishal.l.verma@intel.com> wrote:
>
> On Fri, 2020-12-04 at 10:12 -0800, Ben Widawsky wrote:
> > Hi Chris.
> >
> > On 20-12-04 12:40:03, Chris Browy wrote:
> [..]
> >
> > >    acpidump indicates the CXL0 and CXLM devices but no SRAT or HMAT tables are
> > >    in the dump which is curious.
> >
> > I don't typically use HMAT, but I do have an SRAT in mine, so that's strange.
> > You should also have a CEDT.
> >
> I suspect an SRAT is only added if you have distinct numa nodes. Adding
> a few '-numa node' bits to the qemu command line should be enough to
> make that happen.

For CXL-2.0-Type-3, BIOS is responsible for retrieving CDATs and
synthesizing SRAT/SLIT/HMAT tables for the CXL.mem that is mapped by
platform firmware. For CXL.mem that is mapped by the OS, there is no
requirement to publish updated ACPI tables. CXL.mem mapped by the OS
need only support native CXL memory enumeration and leave ACPI only
for static platform resources.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 0/9] CXL 2.0 Support
  2020-12-04 18:12   ` Ben Widawsky
@ 2020-12-04 19:26     ` Verma, Vishal L
  2020-12-04 19:45       ` Dan Williams
       [not found]     ` <B4FDE6CB-DA00-4F58-AA9F-F04E678E076B@avery-design.com>
  1 sibling, 1 reply; 73+ messages in thread
From: Verma, Vishal L @ 2020-12-04 19:26 UTC (permalink / raw)
  To: Widawsky, Ben, cbrowy
  Cc: Kelley, Sean V, Weiny, Ira, linux-cxl, linux-kernel, Williams,
	Dan J, Wysocki, Rafael J, linux-pci, bhelgaas, linux-acpi

On Fri, 2020-12-04 at 10:12 -0800, Ben Widawsky wrote:
> Hi Chris.
> 
> On 20-12-04 12:40:03, Chris Browy wrote:
[..]
> 
> >    acpidump indicates the CXL0 and CXLM devices but no SRAT or HMAT tables are
> >    in the dump which is curious.
> 
> I don't typically use HMAT, but I do have an SRAT in mine, so that's strange.
> You should also have a CEDT.
> 
I suspect an SRAT is only added if you have distinct numa nodes. Adding
a few '-numa node' bits to the qemu command line should be enough to
make that happen.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 0/9] CXL 2.0 Support
  2020-12-04 17:40 ` Chris Browy
@ 2020-12-04 18:12   ` Ben Widawsky
  2020-12-04 19:26     ` Verma, Vishal L
       [not found]     ` <B4FDE6CB-DA00-4F58-AA9F-F04E678E076B@avery-design.com>
  0 siblings, 2 replies; 73+ messages in thread
From: Ben Widawsky @ 2020-12-04 18:12 UTC (permalink / raw)
  To: Chris Browy
  Cc: bhelgaas, dan.j.williams, ira.weiny, linux-acpi, linux-cxl,
	linux-kernel, linux-pci, rafael.j.wysocki, sean.v.kelley,
	vishal.l.verma

Hi Chris.

On 20-12-04 12:40:03, Chris Browy wrote:
> Hi Ben,
> 
> Trying to bring up the environment using the latest developments as follows:
> 
> 1. Linux kernel baseline version is cloned using
>      git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
>    Using master branch.  Merged the 9 CXL linux kernel patches manually and built kernel
> 
> 2. QEMU baseline version is cloned using
>      git clone https://gitlab.com/bwidawsk/qemu.git
> 
> 3. UEFI baseline is cloned using
>      git clone https://github.com/tianocore/edk2.git
>    Using master and built
> 
> 4. Now can run qemu as follows:
>      The qcow2 we use is based on Ubuntu 20.10 with updated with kernel from 1) above
> 
>      QEMU command:
> 
>      sudo qemu-system-x86_64 -nic \
>      user,hostfwd=tcp::2222-:22,hostfwd=tcp::1234-:1234 -machine \
>      type=pc-q35-4.0,hmat=on,accel=kvm -enable-kvm -cpu host -smp \
>      6,cores=6,threads=1,sockets=1 -m 8G -boot order=d -k 'en-us' -vga virtio \
>      -drive file=/home/chris/Downloads/AQCXL/ubuntu_20.qcow,format=qcow2 -drive \
>      if=pflash,format=raw,readonly,file=/home/chris/OVMF_CODE.fd \
>      -drive if=pflash,format=raw,file=/home/chris/OVMF_VARS.fd \
>      -object memory-backend-file,id=cxl-mem1,share,mem-path=/tmp/cxl-test/cxl,size=512M \
>      -device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52,uid=0,len-window-base=1,\
>      window-base[0]=0x4c0000000,memdev[0]=cxl-mem1 \
>      -device cxl-rp,id=rp0,bus=cxl.0,addr=0.0,chassis=0,slot=0  \
>      -device cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M  2>&1 | tee -a \
>      /home/chris/Downloads/AQCXL/log/qemu.log
> 
>    The qemu options are derived from looking at the tests/qtests/cxl-test.c
>    along with the -hmat=on which seemed to make sense.
> 
>    The system boots and lspci -vvv shows the CXL device is enumerated.  But
>    no DOE capability register for CDAT access though (see below).  Otherwise the
>    DVSEC registers are present.

DOE is not supported yet in either Linux or QEMU. For us, CDAT isn't a high
priority yet so it likely won't be done for a while. I'd really like to see DOE
support added by someone - not me - so that we can wire it up. Not sure what
that would look like in the QEMU side.

> 
>    acpidump indicates the CXL0 and CXLM devices but no SRAT or HMAT tables are
>    in the dump which is curious.

I don't typically use HMAT, but I do have an SRAT in mine, so that's strange.
You should also have a CEDT.

> 
> 
> 35:00.0 Memory controller [0502]: Intel Corporation Device 0d93 (rev 01) (prog-if 10)
>     Subsystem: Red Hat, Inc. Device 1100
>     Physical Slot: 0
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Latency: 0
>     Region 0: Memory at c0a00000 (64-bit, non-prefetchable) [size=64K]
>     Region 2: Memory at c0a10000 (64-bit, non-prefetchable) [size=4K]
>     Capabilities: [80] Express (v2) Endpoint, MSI 00
>         DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>             ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
>         DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
>             RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
>             MaxPayload 128 bytes, MaxReadReq 128 bytes
>         DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
>         LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns
>             ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
>         LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
>             TrErr- Train- SlotClk- DLActive+ BWMgmt- ABWMgmt-
>         DevCap2: Completion Timeout: Not Supported, TimeoutDis-, NROPrPrP-, LTR-
>              10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt+, EETLPPrefix+, MaxEETLPPrefixes 4
>                EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
>              FRS-, TPHComp-, ExtTPHComp-
>              AtomicOpsCap: 32bit- 64bit- 128bitCAS-
>         DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
>              AtomicOpsCtl: ReqEn-
>         LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
>              Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
>              Compliance De-emphasis: -6dB
>         LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
>              EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
>     Capabilities: [100 v1] Designated Vendor-Specific <?>
>     Capabilities: [138 v1] Designated Vendor-Specific <?>
>     Kernel driver in use: cxl_mem
> 
> Questions/Comments:
> -------------------
> 1. Linux
>   a. Is there a gitlab for the linux kernel patches for CXL?  This would
>      facilitate review and code modifications.

We're hopefully going to send out v2 in the next couple of days. I'll push the
repo somewhere as well.

> 
> 2. UEFI (edk2 from tianocore)
>   a. seems to only support CXL 1.1 which means only method #1 (Device
>      option ROM) of Coherent Device Attribute Table_1.02 spec
>      for CDAT handling is possible now.
> 
>      Does device option ROM need to be added to QEMU CXL setup?
> 
>      Can we add a CXL 1.1 emulated device?

Patches welcome :-). I know of other people who want this, but I only care about
2.0+, so I have no intention to implement it.

> 
>   b. lspci doesn’t show the existence of the DOE extended capability register
>      in the CXL CT3D (needed to support method #2).  Are there more patches?

As above, it's not supported. I'm hoping someone else will do that work since I
don't care about it just yet.

> 
> 3. Do you have example user programs to share or better yet the CXL 2.0
>    Sec 14.3.6.1 Application Layer/ Transaction layer test for CXL.mem?
> 

I don't have, mostly because I haven't actually implemented a lot of the real
CXL support. My primary concern was having the Linux driver be able to enumerate
devices and communicate with the device via the mailbox interface. v2 will
contain support for userspace to do this, which I think is a step toward what
you're asking for.

> 4. What are the userspace system APIs for targeting CXL HDM address domain?
>    Usually you can mmap a SPA if you know how to look it up.

I think Dan answered this in the other thread...

> 
> 
> Best Regards,
> Chris Browy
> 
> 
> 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: [RFC PATCH 0/9] CXL 2.0 Support
       [not found] <FB00A034-7C6D-40B1-8452-318A3B052216@avery-design.com>
@ 2020-12-04 17:40 ` Chris Browy
  2020-12-04 18:12   ` Ben Widawsky
  0 siblings, 1 reply; 73+ messages in thread
From: Chris Browy @ 2020-12-04 17:40 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: bhelgaas, dan.j.williams, ira.weiny, linux-acpi, linux-cxl,
	linux-kernel, linux-pci, rafael.j.wysocki, sean.v.kelley,
	vishal.l.verma

Hi Ben,

Trying to bring up the environment using the latest developments as follows:

1. Linux kernel baseline version is cloned using
     git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
   Using master branch.  Merged the 9 CXL linux kernel patches manually and built kernel

2. QEMU baseline version is cloned using
     git clone https://gitlab.com/bwidawsk/qemu.git

3. UEFI baseline is cloned using
     git clone https://github.com/tianocore/edk2.git
   Using master and built

4. Now can run qemu as follows:
     The qcow2 we use is based on Ubuntu 20.10 with updated with kernel from 1) above

     QEMU command:

     sudo qemu-system-x86_64 -nic \
     user,hostfwd=tcp::2222-:22,hostfwd=tcp::1234-:1234 -machine \
     type=pc-q35-4.0,hmat=on,accel=kvm -enable-kvm -cpu host -smp \
     6,cores=6,threads=1,sockets=1 -m 8G -boot order=d -k 'en-us' -vga virtio \
     -drive file=/home/chris/Downloads/AQCXL/ubuntu_20.qcow,format=qcow2 -drive \
     if=pflash,format=raw,readonly,file=/home/chris/OVMF_CODE.fd \
     -drive if=pflash,format=raw,file=/home/chris/OVMF_VARS.fd \
     -object memory-backend-file,id=cxl-mem1,share,mem-path=/tmp/cxl-test/cxl,size=512M \
     -device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52,uid=0,len-window-base=1,\
     window-base[0]=0x4c0000000,memdev[0]=cxl-mem1 \
     -device cxl-rp,id=rp0,bus=cxl.0,addr=0.0,chassis=0,slot=0  \
     -device cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M  2>&1 | tee -a \
     /home/chris/Downloads/AQCXL/log/qemu.log

   The qemu options are derived from looking at the tests/qtests/cxl-test.c
   along with the -hmat=on which seemed to make sense.

   The system boots and lspci -vvv shows the CXL device is enumerated.  But
   no DOE capability register for CDAT access though (see below).  Otherwise the
   DVSEC registers are present.

   acpidump indicates the CXL0 and CXLM devices but no SRAT or HMAT tables are
   in the dump which is curious.


35:00.0 Memory controller [0502]: Intel Corporation Device 0d93 (rev 01) (prog-if 10)
    Subsystem: Red Hat, Inc. Device 1100
    Physical Slot: 0
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    Latency: 0
    Region 0: Memory at c0a00000 (64-bit, non-prefetchable) [size=64K]
    Region 2: Memory at c0a10000 (64-bit, non-prefetchable) [size=4K]
    Capabilities: [80] Express (v2) Endpoint, MSI 00
        DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
        DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
            RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
            MaxPayload 128 bytes, MaxReadReq 128 bytes
        DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
        LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns
            ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
        LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
        LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
            TrErr- Train- SlotClk- DLActive+ BWMgmt- ABWMgmt-
        DevCap2: Completion Timeout: Not Supported, TimeoutDis-, NROPrPrP-, LTR-
             10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt+, EETLPPrefix+, MaxEETLPPrefixes 4
               EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
             FRS-, TPHComp-, ExtTPHComp-
             AtomicOpsCap: 32bit- 64bit- 128bitCAS-
        DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
             AtomicOpsCtl: ReqEn-
        LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
             Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
             Compliance De-emphasis: -6dB
        LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
             EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
    Capabilities: [100 v1] Designated Vendor-Specific <?>
    Capabilities: [138 v1] Designated Vendor-Specific <?>
    Kernel driver in use: cxl_mem

Questions/Comments:
-------------------
1. Linux
  a. Is there a gitlab for the linux kernel patches for CXL?  This would
     facilitate review and code modifications.

2. UEFI (edk2 from tianocore)
  a. seems to only support CXL 1.1 which means only method #1 (Device
     option ROM) of Coherent Device Attribute Table_1.02 spec
     for CDAT handling is possible now.

     Does device option ROM need to be added to QEMU CXL setup?

     Can we add a CXL 1.1 emulated device?

  b. lspci doesn’t show the existence of the DOE extended capability register
     in the CXL CT3D (needed to support method #2).  Are there more patches?

3. Do you have example user programs to share or better yet the CXL 2.0
   Sec 14.3.6.1 Application Layer/ Transaction layer test for CXL.mem?

4. What are the userspace system APIs for targeting CXL HDM address domain?
   Usually you can mmap a SPA if you know how to look it up.


Best Regards,
Chris Browy




^ permalink raw reply	[flat|nested] 73+ messages in thread

end of thread, other threads:[~2020-12-09  0:48 UTC | newest]

Thread overview: 73+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-11  5:43 [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
2020-11-11  5:43 ` [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect Ben Widawsky
2020-11-11  6:17   ` Randy Dunlap
2020-11-11  7:10   ` Christoph Hellwig
2020-11-11  7:30     ` Verma, Vishal L
2020-11-11  7:34       ` hch
2020-11-11  7:36         ` Verma, Vishal L
2020-11-11 23:03   ` Bjorn Helgaas
2020-11-16 17:59   ` Jonathan Cameron
2020-11-16 18:23     ` Verma, Vishal L
2020-11-17 14:32   ` Rafael J. Wysocki
2020-11-17 21:45     ` Dan Williams
2020-11-18 11:14       ` Rafael J. Wysocki
2020-11-11  5:43 ` [RFC PATCH 2/9] cxl/acpi: add OSC support Ben Widawsky
2020-11-16 17:59   ` Jonathan Cameron
2020-11-16 23:25     ` Dan Williams
2020-11-18 12:25       ` Rafael J. Wysocki
2020-11-18 17:58         ` Dan Williams
2020-11-11  5:43 ` [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox Ben Widawsky
2020-11-11  6:17   ` Randy Dunlap
2020-11-11  7:12   ` Christoph Hellwig
2020-11-11 17:17     ` Dan Williams
2020-11-11 18:27       ` Dan Williams
2020-11-11 21:41       ` Randy Dunlap
2020-11-11 22:40         ` Dan Williams
2020-11-16 16:56       ` Christoph Hellwig
2020-11-13 18:17   ` Bjorn Helgaas
2020-11-14  1:08     ` Ben Widawsky
2020-11-15  0:23       ` Dan Williams
2020-11-17 14:49   ` Jonathan Cameron
2020-12-04  7:22     ` Dan Williams
2020-12-04  7:27       ` Dan Williams
2020-12-04 17:39         ` Jonathan Cameron
2020-11-11  5:43 ` [RFC PATCH 4/9] cxl/mem: Map memory device registers Ben Widawsky
2020-11-13 18:17   ` Bjorn Helgaas
2020-11-14  1:12     ` Ben Widawsky
2020-11-16 23:19       ` Dan Williams
2020-11-17  0:23         ` Bjorn Helgaas
2020-11-23 19:20           ` Ben Widawsky
2020-11-23 19:32             ` Dan Williams
2020-11-23 19:58               ` Ben Widawsky
2020-11-17 15:00   ` Jonathan Cameron
2020-11-11  5:43 ` [RFC PATCH 5/9] cxl/mem: Find device capabilities Ben Widawsky
2020-11-13 18:26   ` Bjorn Helgaas
2020-11-14  1:36     ` Ben Widawsky
2020-11-17 15:15   ` Jonathan Cameron
2020-11-24  0:17     ` Ben Widawsky
2020-11-26  6:05   ` Jon Masters
2020-11-26 18:18     ` Ben Widawsky
2020-12-04  7:35     ` Dan Williams
2020-12-04  7:41   ` Dan Williams
2020-12-07  6:12     ` Ben Widawsky
2020-11-11  5:43 ` [RFC PATCH 6/9] cxl/mem: Initialize the mailbox interface Ben Widawsky
2020-11-17 15:22   ` Jonathan Cameron
2020-11-11  5:43 ` [RFC PATCH 7/9] cxl/mem: Implement polled mode mailbox Ben Widawsky
2020-11-13 23:14   ` Bjorn Helgaas
2020-11-17 15:31   ` Jonathan Cameron
2020-11-17 16:34     ` Ben Widawsky
2020-11-17 18:06       ` Jonathan Cameron
2020-11-17 18:38         ` Dan Williams
2020-11-11  5:43 ` [RFC PATCH 8/9] cxl/mem: Register CXL memX devices Ben Widawsky
2020-11-17 15:56   ` Jonathan Cameron
2020-11-20  2:16     ` Dan Williams
2020-11-20 15:20       ` Jonathan Cameron
2020-11-11  5:43 ` [RFC PATCH 9/9] MAINTAINERS: Add maintainers of the CXL driver Ben Widawsky
2020-11-11 22:06 ` [RFC PATCH 0/9] CXL 2.0 Support Ben Widawsky
2020-11-11 22:43 ` Bjorn Helgaas
     [not found] <FB00A034-7C6D-40B1-8452-318A3B052216@avery-design.com>
2020-12-04 17:40 ` Chris Browy
2020-12-04 18:12   ` Ben Widawsky
2020-12-04 19:26     ` Verma, Vishal L
2020-12-04 19:45       ` Dan Williams
     [not found]     ` <B4FDE6CB-DA00-4F58-AA9F-F04E678E076B@avery-design.com>
2020-12-07  4:40       ` Chris Browy
2020-12-09  0:48         ` Ben Widawsky

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).