[RFC PATCH v3 0/4] PCI Data Object Exchange support + CXL CDAT

[RFC PATCH v3 0/4] PCI Data Object Exchange support + CXL CDAT

[Jonathan Cameron]

Change logs in individual patches.
V3 incorporates changes from Bjorn's review and minor related items.

There are several options for how to implement the DOE support in the
kernel.  This cover letter will try to assess the main decision to be
made in this series.

sync vs single threaded workqueue vs delayed work
=================================================

The DOE works via single input and output registers + some control
flags. Protocols are of the query/response type with a short standard
header in both followed by protocol specific data. A given DOE
instance can support multiple protocols, though individual protocol
specifications often limit what combinations are allowed.

Constraints on DOE queue handling.
1. Only a single query/response can be in flight at a time (*)
2. Need to handle timeouts on interrupt, or polling otherwise.

* Not strictly true. The DOE ECN allows for interleaving of multiple
  query/response pairs as long as only one is in flight for a given
  protocol at any given time.  However, the DOE may use the BUSY status bit
  to require software to not write a new request to the device.
  As there is no defined way of knowing when the BUSY bit is no longer
  set other than polling, such an operating mode cannot sensibly be
  used in conjunction with interrupts (which indicate response
  ready or error).  Given the current usecases of DOE and restrictions
  protocols specifications place on what other protocols they can share
  a DOE instance with, it seems unlikely that this level of interleaving
  is worth the complexity it would add.

Let us term a query/response sequence an exchange.

Approaches investigated:
1. Serialize using a mutex. This either makes exchange operations
   synchronous or requires a per caller thread. This was the approach in
   RFC v1. Long sleeps are possible as the protocol allows the response
   generation to take up to 1 second.
2. Use a single threaded workqueue to serialize exchanges.
   Each exchange uses a separate work_struct. Long sleeps can
   occur within the work items.  Note that one of the original stated reasons
   for the introduction of single threaded workqueues was to cater for work
   items which can sleep for a long time. This approach is naturally
   asynchronous, but a trivial wrapper can be used to provide a convenient
   synchronous calling API (I have code doing this, works fine but not posted
   as doesn't avoid long sleeps and discussion around v1 suggested we
   should do avoid them).
3. Use a single delayed work item to implement a state machine. Queuing is
   handled via a list to which query/response pairs are added.  Any delayed
   action or timeout is handled via schedule_delayed_work() with interrupts
   using mod_delayed_work() to immediately advance the state machine.
   There is no reason to use a dedicated work queue, as here serialization
   is handled using the exchange list. The proposal in this patch set.

Note I was unable to find any sensible way to combine 2 and 3, that is
to use both a delayed work approach to avoid timeouts in work items and
a single threaded workqueue to handle ordering + synchronization.
Either such an approach would have ended up with one work item just being
responsible for scheduling items on a different work queue, or it
requires the ability to insert work items at the front of single threaded
work queue (to ensure the next step of the state machine for the current
exchange runs before a step of the next exchange).

Relative complexity
-------------------

1. (mutex) Very simple.
2. (single thread workqueue) Fairly simple.
3. (delayed work) Most complex (particularly around abort handling).

Fairness
--------

Fairness considered to be work done in order of submission.
1. Potentially unfair given simple lock being used to serialize.
2. Fair as first come first served.
3. Fair as manual list implementation of first come first served.

Sync vs Async
-------------

Whilst it's not clear there will actually be any async usecases, lets
consider how this works.
1. (mutex) Caller implements - either long sleeps in sync, or long sleeps in
   a thread to which sync operation off loaded.
2. (single thread workqueue) Async is natural state, with sync implemented as
   wrapper around async. Effectively same as spinning off to a thread in 1.
3. (delayed work) Async is natural state, with sync implemented as wrapper
   around async.

Decision comes down to trading off complexity against advantages of naturally
async operation that avoids sleeping inside a work item / thread / caller.

Cover letter from v1:
https://lore.kernel.org/linux-pci/20210310180306.1588376-1-Jonathan.Cameron@huawei.com/

Series first introduces generic support for DOE mailboxes as defined
in the ECN to the PCI 5.0 specification available from the PCI SIG [0]

A user is then introduced in the form of the table access protocol defined
in the CXL 2.0 specification [1] used to access the
Coherent Device Attribute Table (CDAT) defined in [2]

Various open questions in the individual patches.

All testing conducted against QEMU emulation of a CXL type 3 device
in conjunction with DOE mailbox patches [3, 4]

[0] https://pcisig.com/specifications
[1] https://www.computeexpresslink.org/download-the-specification
[2] https://uefi.org/node/4093
[3] https://lore.kernel.org/qemu-devel/20210202005948.241655-1-ben.widawsky@intel.com/
[4] https://lore.kernel.org/qemu-devel/1612900760-7361-1-git-send-email-cbrowy@avery-design.com/

Jonathan Cameron (4):
  PCI: Add vendor ID for the PCI SIG
  PCI/doe: Add Data Object Exchange support
  cxl/mem: Add CDAT table reading from DOE
  cxl/mem: Add a debug parser for CDAT commands

 drivers/cxl/Kconfig           |   1 +
 drivers/cxl/cdat.h            |  78 +++++
 drivers/cxl/cxl.h             |  13 +
 drivers/cxl/mem.c             | 279 ++++++++++++++++
 drivers/pci/Kconfig           |   8 +
 drivers/pci/Makefile          |   1 +
 drivers/pci/doe.c             | 601 ++++++++++++++++++++++++++++++++++
 include/linux/pci-doe.h       |  85 +++++
 include/linux/pci.h           |   3 +
 include/linux/pci_ids.h       |   1 +
 include/uapi/linux/pci_regs.h |  29 +-
 11 files changed, 1098 insertions(+), 1 deletion(-)
 create mode 100644 drivers/cxl/cdat.h
 create mode 100644 drivers/pci/doe.c
 create mode 100644 include/linux/pci-doe.h

-- 
2.27.0

[RFC PATCH v3 1/4] PCI: Add vendor ID for the PCI SIG

[Jonathan Cameron]

This ID is used in DOE headers to identify protocols that are defined
within the PCI Express Base Specification.

Specified in Table 7-x2 of the Data Object Exchange ECN
(approved 12 March 2020) available from
https://members.pcisig.com/wg/PCI-SIG/document/14143

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
v3: Add a reference to the patch description.

 include/linux/pci_ids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index a76ccb697bef..2c0459c23331 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -149,6 +149,7 @@
 #define PCI_CLASS_OTHERS		0xff
 
 /* Vendors and devices.  Sort key: vendor first, device next. */
+#define PCI_VENDOR_ID_PCI_SIG		0x0001
 
 #define PCI_VENDOR_ID_LOONGSON		0x0014
 
-- 
2.27.0

[RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

Introduced in a PCI ECN [1], DOE provides a config space
based mailbox with standard protocol discovery.  Each mailbox
is accessed through a DOE Extended Capability.

A device may have 1 or more DOE mailboxes, each of which is allowed
to support any number of protocols (some DOE protocol
specifications apply additional restrictions).  A given protocol
may be supported on more than one DOE mailbox on a given function.

If a driver wishes to access any number of DOE instances / protocols
it makes a single call to pcie_doe_register_all() which will find
available DOEs, create the required infrastructure and cache the
protocols they support.  pcie_doe_find() can then retrieve a
pointer to an appropriate DOE instance.

A synchronous interface is provided in pcie_doe_exchange_sync() to
perform a single query / response exchange.

Testing conducted against QEMU using:

https://lore.kernel.org/qemu-devel/1612900760-7361-1-git-send-email-cbrowy@avery-design.com/
+ fix for interrupt flag mentioned in that thread and a whole load
of hacks to exercise error paths etc.

[1] https://members.pcisig.com/wg/PCI-SIG/document/14143
    Data Object Exchange (DOE) - Approved 12 March 2020

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---

Thanks to Bjorn Helgaas for reviewing v2.

Changes since v2:
* Move files and rename so as not to make them PCIe specific.
* Rename pretty much everything from pcie* to pci*.
* Editorial changes in patch description.
* Rename pcie_doe_sync() to pci_doe_exchange_sync() to add a verb.
  Note that I'm not happy with this naming, but have not come up
  with anything better. Suggestions welcome!
* Various white space, punctuation and similar changes as suggested
  by Bjorn.
* Consistent reporting of return values in kernel-doc.
* Use bitfields for Boolean elements of struct pci_doe.
* Change some labels so we don't have both a local variable and label
  abort.
* Add missing EXPORT_SYMBOL_GPL(pci_doe_exchange_sync) to allow use
  from modules.
* Consistenty use sizeof(u32) for DW size.

Thanks to Dan Williams for reviewing v1.
Note code has changed a lot, so I may well have missed stuff in this
log

Changes since v1:
Major stuff:
* Rework the registration of DOE. DOE instances are added to a list in
  the struct pci_dev. A single call to pcie_doe_register_all() finds
  all DOEs present on a device and caches which protocols they support.
  The lifetime of these can then all be managed alongside the
  struct pci_dev avoiding need for reference counting etc whilst allowing
  a driver not to care if different protocols are using the same DOE
  instance, or different ones. The driver issues a call to
  pcie_doe_find() to get a pointer to the first appropriate DOE.
  Note, a side effect of minimizing impact of this on struct pci_dev
  is that we can't build DOE support as a module.
* Instead of serializing on a mutex, move to a more complex state machine
  based scheme in which the DOE config space registers are only
  accessed from a single delayed work item. The state machine uses
  two states for normal operation, IDLE and WAITING. Two states also
  exist for ABORT to indicate if it was called in response to error,
  or at startup. Interrupts result in mod_delayed_work()
  to force an immediate check on the status register.
  Message queuing is implemented with a list of tasks and kicking
  the state machine work item as needed.
* Decide, inside the core DOE code, whether to poll based
  on if the MSI/MSIX interrupts are enabled and the DOE
  instance advertises an interrupt.
* Define a struct pcie_doe_exchange to encapsulate header info
  with payloads etc. Specific fields used for VID and protocol +
  lengths so the DOE header can be constructed inside the DOE
  functions rather than relying on callers to do that.
* Don't hide away devm_ stuff in calls that don't make it obvious.

Minor stuff:
* pcie_doe_init() and pcie_doe_register separation to cover the
  bits that can fail in register() and the bits that can't in init()
* Many typos
* Rename cap_offset field to cap
* Use new PCI_VENDOR_ID_PCI_SIG define to avoid open coding the
  value
* Add defines for timeouts etc.
* Missing EXPORT_SYMBOL_GPL() added to allow DOE access from
  modules.

 drivers/pci/Kconfig           |   8 +
 drivers/pci/Makefile          |   1 +
 drivers/pci/doe.c             | 601 ++++++++++++++++++++++++++++++++++
 include/linux/pci-doe.h       |  85 +++++
 include/linux/pci.h           |   3 +
 include/uapi/linux/pci_regs.h |  29 +-
 6 files changed, 726 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 0c473d75e625..6dd48a1ad2a4 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -190,6 +190,14 @@ config PCI_HYPERV
 	  The PCI device frontend driver allows the kernel to import arbitrary
 	  PCI devices from a PCI backend to support PCI driver domains.
 
+config PCI_DOE
+	bool
+	help
+	  This enables library support for the PCI Data Object Exchange
+	  capability. DOE provides a simple mailbox in PCI config space that is
+	  used by a number of different protocols.
+	  DOE is defined in the Data Object Exchange ECN to PCI 5.0.
+
 choice
 	prompt "PCI Express hierarchy optimization setting"
 	default PCIE_BUS_DEFAULT
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index d62c4ac4ae1b..1b61c1a1c232 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PCI_STUB)		+= pci-stub.o
 obj-$(CONFIG_PCI_PF_STUB)	+= pci-pf-stub.o
 obj-$(CONFIG_PCI_ECAM)		+= ecam.o
 obj-$(CONFIG_PCI_P2PDMA)	+= p2pdma.o
+obj-$(CONFIG_PCI_DOE)		+= doe.o
 obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
 
 # Endpoint library must be initialized before its users
diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c
new file mode 100644
index 000000000000..fce16c78ff45
--- /dev/null
+++ b/drivers/pci/doe.c
@@ -0,0 +1,601 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Data Object Exchange ECN
+ * https://members.pcisig.com/wg/PCI-SIG/document/14143
+ *
+ * Copyright (C) 2021 Huawei
+ *     Jonathan Cameron <Jonathan.Cameron@huawei.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/jiffies.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
+#include <linux/pci.h>
+#include <linux/pci-doe.h>
+#include <linux/workqueue.h>
+
+#define PCI_DOE_PROTOCOL_DISCOVERY 0
+
+#define PCI_DOE_BUSY_MAX_RETRIES 16
+#define PCI_DOE_POLL_INTERVAL (HZ / 128)
+
+/* Timeout of 1 second from 6.xx.1 (Operation), ECN - Data Object Exchange */
+#define PCI_DOE_TIMEOUT HZ
+
+static irqreturn_t pci_doe_irq(int irq, void *data)
+{
+	struct pci_doe *doe = data;
+	struct pci_dev *pdev = doe->pdev;
+	u32 val;
+
+	pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
+	if (FIELD_GET(PCI_DOE_STATUS_INT_STATUS, val)) {
+		pci_write_config_dword(pdev, doe->cap + PCI_DOE_STATUS, val);
+		mod_delayed_work(system_wq, &doe->statemachine, 0);
+		return IRQ_HANDLED;
+	}
+	/* Leave the error case to be handled outside IRQ */
+	if (FIELD_GET(PCI_DOE_STATUS_ERROR, val)) {
+		mod_delayed_work(system_wq, &doe->statemachine, 0);
+		return IRQ_HANDLED;
+	}
+
+	return IRQ_NONE;
+}
+
+/*
+ * Only call when safe to directly access the DOE, either because no tasks yet
+ * queued, or called from doe_statemachine_work() which has exclusive access to
+ * the DOE config space.
+ */
+static void pci_doe_abort_start(struct pci_doe *doe)
+{
+	struct pci_dev *pdev = doe->pdev;
+
+	pci_write_config_dword(pdev, doe->cap + PCI_DOE_CTRL,
+			       PCI_DOE_CTRL_ABORT);
+
+	doe->timeout_jiffies = jiffies + HZ;
+	schedule_delayed_work(&doe->statemachine, HZ);
+}
+
+static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex)
+{
+	struct pci_dev *pdev = doe->pdev;
+	u32 val;
+	int i;
+
+	/*
+	 * Check the DOE busy bit is not set. If it is set, this could indicate
+	 * someone other than Linux (e.g. firmware) is using the mailbox. Note
+	 * it is expected that firmware and OS will negotiate access rights via
+	 * an, as yet to be defined method.
+	 */
+	pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
+	if (FIELD_GET(PCI_DOE_STATUS_BUSY, val))
+		return -EBUSY;
+
+	if (FIELD_GET(PCI_DOE_STATUS_ERROR, val))
+		return -EIO;
+
+	/* Write DOE Header */
+	val = FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_1_VID, ex->vid) |
+		FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, ex->protocol);
+	pci_write_config_dword(pdev, doe->cap + PCI_DOE_WRITE, val);
+	/* Length is 2 DW of header + length of payload in DW */
+	pci_write_config_dword(pdev, doe->cap + PCI_DOE_WRITE,
+			       FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH,
+					  2 + ex->request_pl_sz / sizeof(u32)));
+	for (i = 0; i < ex->request_pl_sz / sizeof(u32); i++)
+		pci_write_config_dword(pdev, doe->cap + PCI_DOE_WRITE,
+				       ex->request_pl[i]);
+
+	pci_write_config_dword(pdev, doe->cap + PCI_DOE_CTRL, PCI_DOE_CTRL_GO);
+	/* Request is sent - now wait for poll or IRQ */
+	return 0;
+}
+
+static int pci_doe_recv_resp(struct pci_doe *doe, struct pci_doe_exchange *ex)
+{
+	struct pci_dev *pdev = doe->pdev;
+	size_t length;
+	u32 val;
+	int i;
+
+	/* Read the first two dwords to get the length and protocol */
+	pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val);
+	if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != ex->vid) ||
+	    (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != ex->protocol)) {
+		pci_err(pdev,
+			"Expected [VID, Protocol] = [%x, %x], got [%x, %x]\n",
+			ex->vid, ex->protocol,
+			FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val),
+			FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val));
+		return -EIO;
+	}
+
+	pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0);
+	pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val);
+	pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0);
+
+	length = FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH, val);
+	if (length > SZ_1M)
+		return -EIO;
+
+	/* Read the rest of the response payload */
+	for (i = 0; i < min(length, ex->response_pl_sz / sizeof(u32)); i++) {
+		pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ,
+				      &ex->response_pl[i]);
+		pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0);
+	}
+
+	/* Flush excess length */
+	for (; i < length; i++) {
+		pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val);
+		pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0);
+	}
+	/* Final error check to pick up on any since Data Object Ready */
+	pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
+	if (FIELD_GET(PCI_DOE_STATUS_ERROR, val))
+		return -EIO;
+
+	return min(length, ex->response_pl_sz / sizeof(u32)) * sizeof(u32);
+}
+
+static void pci_doe_task_complete(void *private)
+{
+	complete(private);
+}
+
+/**
+ * struct pci_doe_task - description of a query / response task.
+ * @h: Head to add it to the list of outstanding tasks.
+ * @ex: The details of the task to be done.
+ * @rv: Return value.  Length of received response or error.
+ * @cb: Callback for completion of task.
+ * @private: Private data passed to callback on completion.
+ */
+struct pci_doe_task {
+	struct list_head h;
+	struct pci_doe_exchange *ex;
+	int rv;
+	void (*cb)(void *private);
+	void *private;
+};
+
+/**
+ * pci_doe_exchange_sync() - Send a request, then wait for and receive response.
+ * @doe: DOE mailbox state structure.
+ * @ex: Description of the buffers and Vendor ID + type used in this
+ *      request/response pair,
+ *
+ * Excess data will be discarded.
+ *
+ * RETURNS: payload in bytes on success, < 0 on error.
+ */
+int pci_doe_exchange_sync(struct pci_doe *doe, struct pci_doe_exchange *ex)
+{
+	struct pci_doe_task task;
+	DECLARE_COMPLETION_ONSTACK(c);
+	int only_task;
+
+	/* DOE requests must be a whole number of DW */
+	if (ex->request_pl_sz % sizeof(u32))
+		return -EINVAL;
+
+	task.ex = ex;
+	task.cb = pci_doe_task_complete;
+	task.private = &c;
+
+	mutex_lock(&doe->tasks_lock);
+	if (doe->dead) {
+		mutex_unlock(&doe->tasks_lock);
+		return -EIO;
+	}
+	only_task = list_empty(&doe->tasks);
+	list_add_tail(&task.h, &doe->tasks);
+	if (only_task)
+		schedule_delayed_work(&doe->statemachine, 0);
+	mutex_unlock(&doe->tasks_lock);
+	wait_for_completion(&c);
+
+	return task.rv;
+}
+EXPORT_SYMBOL_GPL(pci_doe_exchange_sync);
+
+static void doe_statemachine_work(struct work_struct *work)
+{
+	struct delayed_work *w = to_delayed_work(work);
+	struct pci_doe *doe = container_of(w, struct pci_doe, statemachine);
+	struct pci_dev *pdev = doe->pdev;
+	struct pci_doe_task *task;
+	bool abort;
+	u32 val;
+	int rc;
+
+	mutex_lock(&doe->tasks_lock);
+	task = list_first_entry_or_null(&doe->tasks, struct pci_doe_task, h);
+	abort = doe->abort;
+	doe->abort = false;
+	mutex_unlock(&doe->tasks_lock);
+
+	if (abort) {
+		/*
+		 * Currently only used during init - care needed if we want to
+		 * generally expose pci_doe_abort() as it would impact queries
+		 * in flight.
+		 */
+		WARN_ON(task);
+		doe->state = DOE_WAIT_ABORT;
+		pci_doe_abort_start(doe);
+		return;
+	}
+
+	switch (doe->state) {
+	case DOE_IDLE:
+		if (task == NULL)
+			return;
+
+		/* Nothing currently in flight so queue a task */
+		rc = pci_doe_send_req(doe, task->ex);
+		/*
+		 * The specification does not provide any guidance on how long
+		 * some other entity could keep the DOE busy, so try for 1
+		 * second then fail. Busy handling is best effort only, because
+		 * there is no way of avoiding racing against another user of
+		 * the DOE.
+		 */
+		if (rc == -EBUSY) {
+			doe->busy_retries++;
+			if (doe->busy_retries == PCI_DOE_BUSY_MAX_RETRIES) {
+				/* Long enough, fail this request */
+				doe->busy_retries = 0;
+				goto err_busy;
+			}
+			schedule_delayed_work(w, HZ / PCI_DOE_BUSY_MAX_RETRIES);
+			return;
+		}
+		if (rc)
+			goto err_abort;
+		doe->busy_retries = 0;
+
+		doe->state = DOE_WAIT_RESP;
+		doe->timeout_jiffies = jiffies + HZ;
+		/* Now poll or wait for IRQ with timeout */
+		if (doe->irq > 0)
+			schedule_delayed_work(w, PCI_DOE_TIMEOUT);
+		else
+			schedule_delayed_work(w, PCI_DOE_POLL_INTERVAL);
+		return;
+
+	case DOE_WAIT_RESP:
+		/* Not possible to get here with NULL task */
+		pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
+		if (FIELD_GET(PCI_DOE_STATUS_ERROR, val)) {
+			rc = -EIO;
+			goto err_abort;
+		}
+
+		if (!FIELD_GET(PCI_DOE_STATUS_DATA_OBJECT_READY, val)) {
+			/* If not yet at timeout reschedule otherwise abort */
+			if (time_after(jiffies, doe->timeout_jiffies)) {
+				rc = -ETIMEDOUT;
+				goto err_abort;
+			}
+			schedule_delayed_work(w, PCI_DOE_POLL_INTERVAL);
+			return;
+		}
+
+		rc  = pci_doe_recv_resp(doe, task->ex);
+		if (rc < 0)
+			goto err_abort;
+
+		doe->state = DOE_IDLE;
+
+		mutex_lock(&doe->tasks_lock);
+		list_del(&task->h);
+		if (!list_empty(&doe->tasks))
+			schedule_delayed_work(w, 0);
+		mutex_unlock(&doe->tasks_lock);
+
+		/* Set the return value to the length of received payload */
+		task->rv = rc;
+		task->cb(task->private);
+		return;
+
+	case DOE_WAIT_ABORT:
+	case DOE_WAIT_ABORT_ON_ERR:
+		pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
+
+		if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) &&
+		    !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) {
+			/* Back to normal state - carry on */
+			mutex_lock(&doe->tasks_lock);
+			if (!list_empty(&doe->tasks))
+				schedule_delayed_work(w, 0);
+			mutex_unlock(&doe->tasks_lock);
+
+			/*
+			 * For deliberately triggered abort, someone is
+			 * waiting.
+			 */
+			if (doe->state == DOE_WAIT_ABORT)
+				complete(&doe->abort_c);
+			doe->state = DOE_IDLE;
+
+			return;
+		}
+		if (time_after(jiffies, doe->timeout_jiffies)) {
+			struct pci_doe_task *t, *n;
+
+			/* We are dead - abort all queued tasks */
+			pci_err(pdev, "DOE ABORT timed out\n");
+			mutex_lock(&doe->tasks_lock);
+			doe->dead = true;
+			list_for_each_entry_safe(t, n, &doe->tasks, h) {
+				t->rv = -EIO;
+				t->cb(t->private);
+				list_del(&t->h);
+			}
+
+			mutex_unlock(&doe->tasks_lock);
+			if (doe->state == DOE_WAIT_ABORT)
+				complete(&doe->abort_c);
+		}
+		return;
+	}
+
+err_abort:
+	pci_doe_abort_start(doe);
+	doe->state = DOE_WAIT_ABORT_ON_ERR;
+err_busy:
+	mutex_lock(&doe->tasks_lock);
+	list_del(&task->h);
+	mutex_unlock(&doe->tasks_lock);
+
+	task->rv = rc;
+	task->cb(task->private);
+	/*
+	 * If we got here via err_busy, and the queue isn't empty then we need
+	 * to go again.
+	 */
+	if (doe->state == DOE_IDLE) {
+		mutex_lock(&doe->tasks_lock);
+		if (!list_empty(&doe->tasks))
+			schedule_delayed_work(w, 0);
+		mutex_unlock(&doe->tasks_lock);
+	}
+}
+
+static int pci_doe_discovery(struct pci_doe *doe, u8 *index, u16 *vid,
+			     u8 *protocol)
+{
+	u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX, *index);
+	u32 response_pl;
+	struct pci_doe_exchange ex = {
+		.vid = PCI_VENDOR_ID_PCI_SIG,
+		.protocol = PCI_DOE_PROTOCOL_DISCOVERY,
+		.request_pl = &request_pl,
+		.request_pl_sz = sizeof(request_pl),
+		.response_pl = &response_pl,
+		.response_pl_sz = sizeof(response_pl),
+	};
+	int ret;
+
+	ret = pci_doe_exchange_sync(doe, &ex);
+	if (ret < 0)
+		return ret;
+
+	if (ret != sizeof(response_pl))
+		return -EIO;
+
+	*vid = FIELD_GET(PCI_DOE_DATA_OBJECT_DISC_RSP_3_VID, response_pl);
+	*protocol = FIELD_GET(PCI_DOE_DATA_OBJECT_DISC_RSP_3_PROTOCOL, response_pl);
+	*index = FIELD_GET(PCI_DOE_DATA_OBJECT_DISC_RSP_3_NEXT_INDEX, response_pl);
+
+	return 0;
+}
+
+static int pci_doe_cache_protocols(struct pci_doe *doe)
+{
+	u8 index = 0;
+	int rc;
+
+	/* Discovery protocol must always be supported and must report itself */
+	doe->num_prots = 1;
+	doe->prots = kzalloc(sizeof(*doe->prots) * doe->num_prots, GFP_KERNEL);
+	if (doe->prots == NULL)
+		return -ENOMEM;
+
+	do {
+		struct pci_doe_prot *prot, *prot_new;
+
+		prot = &doe->prots[doe->num_prots - 1];
+		rc = pci_doe_discovery(doe, &index, &prot->vid, &prot->type);
+		if (rc)
+			goto err_free_prots;
+
+		if (index) {
+			prot_new = krealloc(doe->prots,
+					    sizeof(*doe->prots) * doe->num_prots,
+					    GFP_KERNEL);
+			if (prot_new == NULL) {
+				rc = -ENOMEM;
+				goto err_free_prots;
+			}
+			doe->prots = prot_new;
+			doe->num_prots++;
+		}
+	} while (index);
+
+	return 0;
+
+err_free_prots:
+	kfree(doe->prots);
+	return rc;
+}
+
+static void pci_doe_init(struct pci_doe *doe, struct pci_dev *pdev, int doe_offset)
+{
+	mutex_init(&doe->tasks_lock);
+	init_completion(&doe->abort_c);
+	doe->cap = doe_offset;
+	doe->pdev = pdev;
+	INIT_LIST_HEAD(&doe->tasks);
+	INIT_DELAYED_WORK(&doe->statemachine, doe_statemachine_work);
+}
+
+static int pci_doe_abort(struct pci_doe *doe)
+{
+	reinit_completion(&doe->abort_c);
+	mutex_lock(&doe->tasks_lock);
+	doe->abort = true;
+	mutex_unlock(&doe->tasks_lock);
+	schedule_delayed_work(&doe->statemachine, 0);
+	wait_for_completion(&doe->abort_c);
+
+	if (doe->dead)
+		return -EIO;
+
+	return 0;
+}
+
+static int pci_doe_register(struct pci_doe *doe)
+{
+	struct pci_dev *pdev = doe->pdev;
+	bool poll = !pci_dev_msi_enabled(pdev);
+	int rc, irq;
+	u32 val;
+
+	pci_read_config_dword(pdev, doe->cap + PCI_DOE_CAP, &val);
+
+	if (!poll && FIELD_GET(PCI_DOE_CAP_INT, val)) {
+		irq = pci_irq_vector(pdev, FIELD_GET(PCI_DOE_CAP_IRQ, val));
+		if (irq < 0)
+			return irq;
+
+		rc = request_irq(irq, pci_doe_irq, 0, "DOE", doe);
+		if (rc)
+			return rc;
+
+		doe->irq = irq;
+		pci_write_config_dword(pdev, doe->cap + PCI_DOE_CTRL,
+				       FIELD_PREP(PCI_DOE_CTRL_INT_EN, 1));
+	}
+
+	/* Reset the mailbox by issuing an abort */
+	rc = pci_doe_abort(doe);
+	if (rc)
+		goto err_free_irqs;
+
+	return 0;
+
+err_free_irqs:
+	if (doe->irq > 0)
+		free_irq(doe->irq, doe);
+
+	return rc;
+}
+
+static void pci_doe_unregister(struct pci_doe *doe)
+{
+	if (doe->irq > 0)
+		free_irq(doe->irq, doe);
+}
+
+void pci_doe_unregister_all(struct pci_dev *pdev)
+{
+	struct pci_doe *doe, *next;
+
+	list_for_each_entry_safe(doe, next, &pdev->doe_list, h) {
+		/* First halt the state machine */
+		cancel_delayed_work_sync(&doe->statemachine);
+		kfree(doe->prots);
+		pci_doe_unregister(doe);
+		kfree(doe);
+	}
+}
+EXPORT_SYMBOL_GPL(pci_doe_unregister_all);
+
+/**
+ * pci_doe_register_all() - Find and register all DOE mailboxes.
+ * @pdev: PCI device whose DOE mailboxes we are finding.
+ *
+ * Will locate any DOE mailboxes present on the device and cache the protocols
+ * so that pci_doe_find() can be used to retrieve a suitable DOE instance.
+ *
+ * DOE mailboxes are available until pci_doe_unregister_all() is called.
+ *
+ * RETURNS: 0 on success, < 0 on error.
+ */
+int pci_doe_register_all(struct pci_dev *pdev)
+{
+	struct pci_doe *doe;
+	int pos = 0;
+	int rc;
+
+	INIT_LIST_HEAD(&pdev->doe_list);
+
+	/* Walk the DOE extended capabilities and add to per pci_dev list */
+	while (true) {
+		pos = pci_find_next_ext_capability(pdev, pos,
+						   PCI_EXT_CAP_ID_DOE);
+		if (!pos)
+			return 0;
+
+		doe = kzalloc(sizeof(*doe), GFP_KERNEL);
+		if (!doe) {
+			rc = -ENOMEM;
+			goto err_free_does;
+		}
+
+		pci_doe_init(doe, pdev, pos);
+		rc = pci_doe_register(doe);
+		if (rc) {
+			kfree(doe);
+			goto err_free_does;
+		}
+
+		rc = pci_doe_cache_protocols(doe);
+		if (rc) {
+			pci_doe_unregister(doe);
+			kfree(doe);
+			goto err_free_does;
+		}
+
+		list_add(&doe->h, &pdev->doe_list);
+	}
+
+err_free_does:
+	pci_doe_unregister_all(pdev);
+
+	return rc;
+}
+EXPORT_SYMBOL_GPL(pci_doe_register_all);
+
+/**
+ * pci_doe_find() - Find the first DOE instance that supports a given protocol.
+ * @pdev: Device on which to find the DOE instance.
+ * @vid: Vendor ID.
+ * @type: Specific protocol for this vendor.
+ *
+ * RETURNS: Pointer to DOE instance on success, NULL on no suitable instance
+ * available.
+ */
+struct pci_doe *pci_doe_find(struct pci_dev *pdev, u16 vid, u8 type)
+{
+	struct pci_doe *doe;
+	int i;
+
+	list_for_each_entry(doe, &pdev->doe_list, h) {
+		for (i = 0; i < doe->num_prots; i++)
+			if ((doe->prots[i].vid == vid) &&
+			    (doe->prots[i].type == type))
+				return doe;
+	}
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(pci_doe_find);
diff --git a/include/linux/pci-doe.h b/include/linux/pci-doe.h
new file mode 100644
index 000000000000..0307ed17d3ab
--- /dev/null
+++ b/include/linux/pci-doe.h
@@ -0,0 +1,85 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Data Object Exchange was added to the PCI spec as an ECN to 5.0.
+ *
+ * Copyright (C) 2021 Huawei
+ *     Jonathan Cameron <Jonathan.Cameron@huawei.com>
+ */
+
+#include <linux/completion.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
+
+#ifndef LINUX_PCI_DOE_H
+#define LINUX_PCI_DOE_H
+
+struct pci_doe_prot {
+	u16 vid;
+	u8 type;
+};
+
+struct workqueue_struct;
+
+enum pci_doe_state {
+	DOE_IDLE,
+	DOE_WAIT_RESP,
+	DOE_WAIT_ABORT,
+	DOE_WAIT_ABORT_ON_ERR,
+};
+
+struct pci_doe_exchange {
+	u16 vid;
+	u8 protocol;
+	u32 *request_pl;
+	size_t request_pl_sz;
+	u32 *response_pl;
+	size_t response_pl_sz;
+};
+
+/**
+ * struct pci_doe - State to support use of DOE mailbox
+ * @cap: Config space offset to base of DOE capability.
+ * @pdev: PCI device that hosts this DOE.
+ * @abort_c: Completion used for initial abort handling.
+ * @irq: Interrupt used for signaling DOE ready or abort.
+ * @prots: Cache of identifiers for protocols supported.
+ * @num_prots: Size of prots cache.
+ * @h: Used for DOE instance lifetime management.
+ * @wq: Workqueue used to handle state machine and polling / timeouts.
+ * @tasks: List of task in flight + pending.
+ * @tasks_lock: Protect the tasks list.
+ * @statemachine: Work item for the DOE state machine.
+ * @state: Current state of this DOE.
+ * @timeout_jiffies: 1 second after GO set.
+ * @busy_retries: Count of retry attempts.
+ * @abort: Request a manual abort (e.g. on init).
+ * @dead: Used to mark a DOE for which an ABORT has timed out. Further messages
+ *        will immediately be aborted with error.
+ */
+struct pci_doe {
+	int cap;
+	struct pci_dev *pdev;
+	struct completion abort_c;
+	int irq;
+	struct pci_doe_prot *prots;
+	int num_prots;
+	struct list_head h;
+
+	struct workqueue_struct *wq;
+	struct list_head tasks;
+	struct mutex tasks_lock;
+	struct delayed_work statemachine;
+	enum pci_doe_state state;
+	unsigned long timeout_jiffies;
+	unsigned int busy_retries;
+	unsigned int abort:1;
+	unsigned int dead:1;
+};
+
+int pci_doe_register_all(struct pci_dev *pdev);
+void pci_doe_unregister_all(struct pci_dev *pdev);
+struct pci_doe *pci_doe_find(struct pci_dev *pdev, u16 vid, u8 type);
+
+int pci_doe_exchange_sync(struct pci_doe *doe, struct pci_doe_exchange *ex);
+
+#endif
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 86c799c97b77..ac7a18826096 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -332,6 +332,9 @@ struct pci_dev {
 #ifdef CONFIG_PCIEPORTBUS
 	struct rcec_ea	*rcec_ea;	/* RCEC cached endpoint association */
 	struct pci_dev  *rcec;          /* Associated RCEC device */
+#endif
+#ifdef CONFIG_PCI_DOE
+	struct list_head doe_list;	/* Data Object Exchange mailboxes */
 #endif
 	u8		pcie_cap;	/* PCIe capability offset */
 	u8		msi_cap;	/* MSI capability offset */
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index e709ae8235e7..b97df1d8bd19 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -730,7 +730,8 @@
 #define PCI_EXT_CAP_ID_DVSEC	0x23	/* Designated Vendor-Specific */
 #define PCI_EXT_CAP_ID_DLF	0x25	/* Data Link Feature */
 #define PCI_EXT_CAP_ID_PL_16GT	0x26	/* Physical Layer 16.0 GT/s */
-#define PCI_EXT_CAP_ID_MAX	PCI_EXT_CAP_ID_PL_16GT
+#define PCI_EXT_CAP_ID_DOE	0x2E	/* Data Object Exchange */
+#define PCI_EXT_CAP_ID_MAX	PCI_EXT_CAP_ID_DOE
 
 #define PCI_EXT_CAP_DSN_SIZEOF	12
 #define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
@@ -1092,4 +1093,30 @@
 #define  PCI_PL_16GT_LE_CTRL_USP_TX_PRESET_MASK		0x000000F0
 #define  PCI_PL_16GT_LE_CTRL_USP_TX_PRESET_SHIFT	4
 
+/* Data Object Exchange */
+#define PCI_DOE_CAP		0x04	/* DOE Capabilities Register */
+#define  PCI_DOE_CAP_INT			0x00000001  /* Interrupt Support */
+#define  PCI_DOE_CAP_IRQ			0x00000ffe  /* Interrupt Message Number */
+#define PCI_DOE_CTRL		0x08	/* DOE Control Register */
+#define  PCI_DOE_CTRL_ABORT			0x00000001  /* DOE Abort */
+#define  PCI_DOE_CTRL_INT_EN			0x00000002  /* DOE Interrupt Enable */
+#define  PCI_DOE_CTRL_GO			0x80000000  /* DOE Go */
+#define PCI_DOE_STATUS		0x0c	/* DOE Status Register */
+#define  PCI_DOE_STATUS_BUSY			0x00000001  /* DOE Busy */
+#define  PCI_DOE_STATUS_INT_STATUS		0x00000002  /* DOE Interrupt Status */
+#define  PCI_DOE_STATUS_ERROR			0x00000004  /* DOE Error */
+#define  PCI_DOE_STATUS_DATA_OBJECT_READY	0x80000000  /* Data Object Ready */
+#define PCI_DOE_WRITE		0x10	/* DOE Write Data Mailbox Register */
+#define PCI_DOE_READ		0x14	/* DOE Read Data Mailbox Register */
+
+/* DOE Data Object - note not actually registers */
+#define PCI_DOE_DATA_OBJECT_HEADER_1_VID	0x0000ffff
+#define PCI_DOE_DATA_OBJECT_HEADER_1_TYPE	0x00ff0000
+#define PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH	0x0003ffff
+
+#define PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX	0x000000ff
+#define PCI_DOE_DATA_OBJECT_DISC_RSP_3_VID	0x0000ffff
+#define PCI_DOE_DATA_OBJECT_DISC_RSP_3_PROTOCOL	0x00ff0000
+#define PCI_DOE_DATA_OBJECT_DISC_RSP_3_NEXT_INDEX 0xff000000
+
 #endif /* LINUX_PCI_REGS_H */
-- 
2.27.0

[RFC PATCH v3 3/4] cxl/mem: Add CDAT table reading from DOE

[Jonathan Cameron]

This patch provides a sysfs binary attribute to
allow dumping of the whole table.

Binary dumping is modeled on /sys/firmware/ACPI/tables/

The ability to dump this table will be very useful for emulation of
real devices once they become available as QEMU CXL type 3 device
emulation will be able to load this file in.

Open questions:
* No support here for table updates via the binary attribute. You
  get whatever was there when it was first cached.. Worth including
  these from the start, or leave that complexity for later?  We could
  read directly from the DOE every time, but need to check we get
  a coherent table.  Let's figure this out once we are making 'real'
  use of the table.
* What is maximum size of the SSLBIS entry - I haven't quite managed
  to figure that out and this is the record with largest size.
  We could support dynamic allocation of the record size, but it
  would add complexity that seems unnecessary.
  It would not be compliant with the specification for a type 3 memory
  device to report this record anyway so I'm not that worried about this
  for now.  It will become relevant once we have support for reading
  CDAT from CXL switches.
* cdat.h is formatted in a similar style to pci_regs.h on basis that
  it may well be helpful to share this header with userspace tools.
* Move the generic parts of this out to driver/cxl/cdat.c or leave that
  until we have other CXL drivers wishing to use this?

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
Changes since v2:
* Naming changes to match those in the patch introducing DOE support.
* Consistent use of lowercase hexadecimal values.

Thanks to Dan Williams for review

Changes since v1:
* static creation of the binary attribute
* moved the debug print to separate patch to make it easy to drop
  later.
* select PCIE_DOE
* Changes due to interface changes in previous patch.

 drivers/cxl/Kconfig |   1 +
 drivers/cxl/cdat.h  |  78 +++++++++++++++++++
 drivers/cxl/cxl.h   |  13 ++++
 drivers/cxl/mem.c   | 177 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 269 insertions(+)

diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index 97dc4d751651..26cad9fa29f7 100644
--- a/drivers/cxl/Kconfig
+++ b/drivers/cxl/Kconfig
@@ -15,6 +15,7 @@ if CXL_BUS
 
 config CXL_MEM
 	tristate "CXL.mem: Memory Devices"
+	select PCI_DOE
 	help
 	  The CXL.mem protocol allows a device to act as a provider of
 	  "System RAM" and/or "Persistent Memory" that is fully coherent
diff --git a/drivers/cxl/cdat.h b/drivers/cxl/cdat.h
new file mode 100644
index 000000000000..da9c147cbdfa
--- /dev/null
+++ b/drivers/cxl/cdat.h
@@ -0,0 +1,78 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Coherent Device Attribute table (CDAT)
+ *
+ * Specification available from UEFI.org
+ *
+ * Whilst CDAT is defined as a single table, the access via DOE maiboxes is
+ * done one entry at a time, where the first entry is the header.
+ */
+
+#define CXL_DOE_TABLE_ACCESS_REQ_CODE		0x000000ff
+#define   CXL_DOE_TABLE_ACCESS_REQ_CODE_READ	0
+#define CXL_DOE_TABLE_ACCESS_TABLE_TYPE		0x0000ff00
+#define   CXL_DOE_TABLE_ACCESS_TABLE_TYPE_CDATA	0
+#define CXL_DOE_TABLE_ACCESS_ENTRY_HANDLE	0xffff0000
+
+/*
+ * CDAT entries are little endian and are read from PCI config space which
+ * is also little endian.
+ * As such, on a big endian system these will have been reversed.
+ * This prevents us from making easy use of packed structures.
+ * Style form pci_regs.h
+ */
+
+#define CDAT_HEADER_LENGTH_DW 3
+#define CDAT_HEADER_DW0_LENGTH		0xffffffff
+#define CDAT_HEADER_DW1_REVISION	0x000000ff
+#define CDAT_HEADER_DW1_CHECKSUM	0x0000ff00
+#define CDAT_HEADER_DW2_SEQUENCE	0xffffffff
+
+/* All structures have a common first DW */
+#define CDAT_STRUCTURE_DW0_TYPE		0x000000ff
+#define   CDAT_STRUCTURE_DW0_TYPE_DSMAS 0
+#define   CDAT_STRUCTURE_DW0_TYPE_DSLBIS 1
+#define   CDAT_STRUCTURE_DW0_TYPE_DSMSCIS 2
+#define   CDAT_STRUCTURE_DW0_TYPE_DSIS 3
+#define   CDAT_STRUCTURE_DW0_TYPE_DSEMTS 4
+#define   CDAT_STRUCTURE_DW0_TYPE_SSLBIS 5
+
+#define CDAT_STRUCTURE_DW0_LENGTH	0xffff0000
+
+/* Device Scoped Memory Affinity Structure */
+#define CDAT_DSMAS_DW1_DSMAD_HANDLE	0x000000ff
+#define CDAT_DSMAS_DW1_FLAGS		0x0000ff00
+#define CDAT_DSMAS_DPA_OFFSET(entry) ((u64)((entry)[3]) << 32 | (entry)[2])
+#define CDAT_DSMAS_DPA_LEN(entry) ((u64)((entry)[5]) << 32 | (entry)[4])
+
+/* Device Scoped Latency and Bandwidth Information Structure */
+#define CDAT_DSLBIS_DW1_HANDLE		0x000000ff
+#define CDAT_DSLBIS_DW1_FLAGS		0x0000ff00
+#define CDAT_DSLBIS_DW1_DATA_TYPE	0x00ff0000
+#define CDAT_DSLBIS_BASE_UNIT(entry) ((u64)((entry)[3]) << 32 | (entry)[2])
+#define CDAT_DSLBIS_DW4_ENTRY_0		0x0000ffff
+#define CDAT_DSLBIS_DW4_ENTRY_1		0xffff0000
+#define CDAT_DSLBIS_DW5_ENTRY_2		0x0000ffff
+
+/* Device Scoped Memory Side Cache Information Structure */
+#define CDAT_DSMSCIS_DW1_HANDLE		0x000000ff
+#define CDAT_DSMSCIS_MEMORY_SIDE_CACHE_SIZE(entry) \
+	((u64)((entry)[3]) << 32 | (entry)[2])
+#define CDAT_DSMSCIS_DW4_MEMORY_SIDE_CACHE_ATTRS 0xffffffff
+
+/* Device Scoped Initiator Structure */
+#define CDAT_DSIS_DW1_FLAGS		0x000000ff
+#define CDAT_DSIS_DW1_HANDLE		0x0000ff00
+
+/* Device Scoped EFI Memory Type Structure */
+#define CDAT_DSEMTS_DW1_HANDLE		0x000000ff
+#define CDAT_DSEMTS_DW1_EFI_MEMORY_TYPE_ATTR	0x0000ff00
+#define CDAT_DSEMTS_DPA_OFFSET(entry)	((u64)((entry)[3]) << 32 | (entry)[2])
+#define CDAT_DSEMTS_DPA_LENGTH(entry)	((u64)((entry)[5]) << 32 | (entry)[4])
+
+/* Switch Scoped Latency and Bandwidth Information Structure */
+#define CDAT_SSLBIS_DW1_DATA_TYPE	0x000000ff
+#define CDAT_SSLBIS_BASE_UNIT(entry)	((u64)((entry)[3]) << 32 | (entry)[2])
+#define CDAT_SSLBIS_ENTRY_PORT_X(entry, i) ((entry)[4 + (i) * 2] & 0x0000ffff)
+#define CDAT_SSLBIS_ENTRY_PORT_Y(entry, i) (((entry)[4 + (i) * 2] & 0xffff0000) >> 16)
+#define CDAT_SSLBIS_ENTRY_LAT_OR_BW(entry, i) ((entry)[4 + (i) * 2 + 1] & 0x0000ffff)
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index 6f14838c2d25..eba3f7e7d997 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -7,6 +7,7 @@
 #include <linux/bitfield.h>
 #include <linux/bitops.h>
 #include <linux/io.h>
+#include <linux/pci-doe.h>
 
 /* CXL 2.0 8.2.8.1 Device Capabilities Array Register */
 #define CXLDEV_CAP_ARRAY_OFFSET 0x0
@@ -57,10 +58,21 @@
 	(FIELD_GET(CXLMDEV_RESET_NEEDED_MASK, status) !=                       \
 	 CXLMDEV_RESET_NEEDED_NOT)
 
+#define CXL_DOE_PROTOCOL_COMPLIANCE 0
+#define CXL_DOE_PROTOCOL_TABLE_ACCESS 2
+
+/* Common to request and response */
+#define CXL_DOE_TABLE_ACCESS_3_CODE GENMASK(7, 0)
+#define   CXL_DOE_TABLE_ACCESS_3_CODE_READ 0
+#define CXL_DOE_TABLE_ACCESS_3_TYPE GENMASK(15, 8)
+#define   CXL_DOE_TABLE_ACCESS_3_TYPE_CDAT 0
+#define CXL_DOE_TABLE_ACCESS_3_ENTRY_HANDLE GENMASK(31, 16)
+
 struct cxl_memdev;
 /**
  * struct cxl_mem - A CXL memory device
  * @pdev: The PCI device associated with this CXL device.
+ * @table_doe: Data exchange object mailbox used to read tables.
  * @regs: IO mappings to the device's MMIO
  * @status_regs: CXL 2.0 8.2.8.3 Device Status Registers
  * @mbox_regs: CXL 2.0 8.2.8.4 Mailbox Registers
@@ -75,6 +87,7 @@ struct cxl_memdev;
  */
 struct cxl_mem {
 	struct pci_dev *pdev;
+	struct pci_doe *table_doe;
 	void __iomem *regs;
 	struct cxl_memdev *cxlmd;
 
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 244cb7d89678..32354d443f2e 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -12,6 +12,7 @@
 #include <linux/io-64-nonatomic-lo-hi.h>
 #include "pci.h"
 #include "cxl.h"
+#include "cdat.h"
 
 /**
  * DOC: cxl mem
@@ -99,6 +100,8 @@ struct mbox_cmd {
  * @ops_active: active user of @cxlm in ops handlers
  * @ops_dead: completion when all @cxlm ops users have exited
  * @id: id number of this memdev instance.
+ * @cdat_table: cache of CDAT table
+ * @cdat_length: length of cached CDAT table
  */
 struct cxl_memdev {
 	struct device dev;
@@ -107,6 +110,8 @@ struct cxl_memdev {
 	struct percpu_ref ops_active;
 	struct completion ops_dead;
 	int id;
+	void *cdat_table;
+	size_t cdat_length;
 };
 
 static int cxl_mem_major;
@@ -968,6 +973,85 @@ static int cxl_mem_setup_mailbox(struct cxl_mem *cxlm)
 	return 0;
 }
 
+#define CDAT_DOE_REQ(entry_handle)					\
+	(FIELD_PREP(CXL_DOE_TABLE_ACCESS_REQ_CODE,			\
+		    CXL_DOE_TABLE_ACCESS_REQ_CODE_READ) |		\
+	 FIELD_PREP(CXL_DOE_TABLE_ACCESS_TABLE_TYPE,			\
+		    CXL_DOE_TABLE_ACCESS_TABLE_TYPE_CDATA) |		\
+	 FIELD_PREP(CXL_DOE_TABLE_ACCESS_ENTRY_HANDLE, (entry_handle)))
+
+static ssize_t cdat_get_length(struct pci_doe *doe)
+{
+	u32 cdat_request_pl = CDAT_DOE_REQ(0);
+	u32 cdat_response_pl[32];
+	struct pci_doe_exchange ex = {
+		.vid = PCI_DVSEC_VENDOR_ID_CXL,
+		.protocol = CXL_DOE_PROTOCOL_TABLE_ACCESS,
+		.request_pl = &cdat_request_pl,
+		.request_pl_sz = sizeof(cdat_request_pl),
+		.response_pl = cdat_response_pl,
+		.response_pl_sz = sizeof(cdat_response_pl),
+	};
+
+	ssize_t rc;
+
+	rc = pci_doe_exchange_sync(doe, &ex);
+	if (rc < 0)
+		return rc;
+	if (rc < 1)
+		return -EIO;
+
+	return cdat_response_pl[1];
+}
+
+static int cdat_to_buffer(struct pci_doe *doe, u32 *buffer, size_t length)
+{
+	int entry_handle = 0;
+	int rc;
+
+	do {
+		u32 cdat_request_pl = CDAT_DOE_REQ(entry_handle);
+		u32 cdat_response_pl[32];
+		struct pci_doe_exchange ex = {
+			.vid = PCI_DVSEC_VENDOR_ID_CXL,
+			.protocol = CXL_DOE_PROTOCOL_TABLE_ACCESS,
+			.request_pl = &cdat_request_pl,
+			.request_pl_sz = sizeof(cdat_request_pl),
+			.response_pl = cdat_response_pl,
+			.response_pl_sz = sizeof(cdat_response_pl),
+		};
+		size_t entry_dw;
+		u32 *entry;
+
+		rc = pci_doe_exchange_sync(doe, &ex);
+		if (rc < 0)
+			return rc;
+
+		entry = cdat_response_pl + 1;
+		entry_dw = rc / sizeof(u32);
+		/* Skip Header */
+		entry_dw -= 1;
+		entry_dw = min(length / 4, entry_dw);
+		memcpy(buffer, entry, entry_dw * sizeof(u32));
+		length -= entry_dw * sizeof(u32);
+		buffer += entry_dw;
+		entry_handle = FIELD_GET(CXL_DOE_TABLE_ACCESS_ENTRY_HANDLE, cdat_response_pl[0]);
+
+	} while (entry_handle != 0xFFFF);
+
+	return 0;
+}
+
+static void cxl_mem_free_irq_vectors(void *data)
+{
+	pci_free_irq_vectors(data);
+}
+
+static void cxl_mem_doe_unregister_all(void *data)
+{
+	pci_doe_unregister_all(data);
+}
+
 static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo,
 				      u32 reg_hi)
 {
@@ -975,6 +1059,7 @@ static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo,
 	struct cxl_mem *cxlm;
 	void __iomem *regs;
 	u64 offset;
+	int irqs;
 	u8 bar;
 	int rc;
 
@@ -1013,6 +1098,44 @@ static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo,
 		return NULL;
 	}
 
+	/*
+	 * An implementation of a cxl type3 device may support an unknown
+	 * number of interrupts. Assume that number is not that large and
+	 * request them all.
+	 */
+	irqs = pci_msix_vec_count(pdev);
+	rc = pci_alloc_irq_vectors(pdev, irqs, irqs, PCI_IRQ_MSIX);
+	if (rc != irqs) {
+		/* No interrupt available - carry on */
+		dev_dbg(dev, "No interrupts available for DOE\n");
+	} else {
+		/*
+		 * Enabling bus mastering could be done within the DOE
+		 * initialization, but as it potentially has other impacts
+		 * keep it within the driver.
+		 */
+		pci_set_master(pdev);
+		rc = devm_add_action_or_reset(dev, cxl_mem_free_irq_vectors,
+					       pdev);
+		if (rc)
+			return NULL;
+	}
+
+	/*
+	 * Find a DOE mailbox that supports CDAT.
+	 * Supporting other DOE protocols will require more complexity.
+	 */
+	rc = pci_doe_register_all(pdev);
+	if (rc < 0)
+		return NULL;
+
+	rc = devm_add_action_or_reset(dev, cxl_mem_doe_unregister_all, pdev);
+	if (rc)
+		return NULL;
+
+	cxlm->table_doe = pci_doe_find(pdev, PCI_DVSEC_VENDOR_ID_CXL,
+				       CXL_DOE_PROTOCOL_TABLE_ACCESS);
+
 	dev_dbg(dev, "Mapped CXL Memory Device resource\n");
 	return cxlm;
 }
@@ -1103,6 +1226,31 @@ static ssize_t pmem_size_show(struct device *dev, struct device_attribute *attr,
 	return sprintf(buf, "%#llx\n", len);
 }
 
+static ssize_t CDAT_read(struct file *filp, struct kobject *kobj,
+			 struct bin_attribute *bin_attr, char *buf,
+			 loff_t offset, size_t count)
+{
+	struct device *dev = kobj_to_dev(kobj);
+	struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
+
+	return memory_read_from_buffer(buf, count, &offset, cxlmd->cdat_table,
+				       cxlmd->cdat_length);
+}
+
+static BIN_ATTR_RO(CDAT, 0);
+
+static umode_t cxl_memdev_bin_attr_is_visible(struct kobject *kobj,
+					      struct bin_attribute *attr, int i)
+{
+	struct device *dev = kobj_to_dev(kobj);
+	struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
+
+	if ((attr == &bin_attr_CDAT) && cxlmd->cdat_table)
+		return 0400;
+
+	return 0;
+}
+
 static struct device_attribute dev_attr_pmem_size =
 	__ATTR(size, 0444, pmem_size_show, NULL);
 
@@ -1112,6 +1260,11 @@ static struct attribute *cxl_memdev_attributes[] = {
 	NULL,
 };
 
+static struct bin_attribute *cxl_memdev_bin_attributes[] = {
+	&bin_attr_CDAT,
+	NULL,
+};
+
 static struct attribute *cxl_memdev_pmem_attributes[] = {
 	&dev_attr_pmem_size.attr,
 	NULL,
@@ -1124,6 +1277,8 @@ static struct attribute *cxl_memdev_ram_attributes[] = {
 
 static struct attribute_group cxl_memdev_attribute_group = {
 	.attrs = cxl_memdev_attributes,
+	.bin_attrs = cxl_memdev_bin_attributes,
+	.is_bin_visible = cxl_memdev_bin_attr_is_visible,
 };
 
 static struct attribute_group cxl_memdev_ram_attribute_group = {
@@ -1170,6 +1325,25 @@ static void cxlmdev_ops_active_release(struct percpu_ref *ref)
 	complete(&cxlmd->ops_dead);
 }
 
+static int cxl_cache_cdat_table(struct cxl_memdev *cxlmd)
+{
+	struct cxl_mem *cxlm = cxlmd->cxlm;
+	struct device *dev = &cxlmd->dev;
+	ssize_t cdat_length;
+
+	if (cxlm->table_doe == NULL)
+		return 0;
+
+	cdat_length = cdat_get_length(cxlm->table_doe);
+	if (cdat_length < 0)
+		return cdat_length;
+
+	cxlmd->cdat_length = cdat_length;
+	cxlmd->cdat_table = devm_kzalloc(dev->parent, cdat_length, GFP_KERNEL);
+
+	return cdat_to_buffer(cxlm->table_doe, cxlmd->cdat_table, cxlmd->cdat_length);
+}
+
 static int cxl_mem_add_memdev(struct cxl_mem *cxlm)
 {
 	struct pci_dev *pdev = cxlm->pdev;
@@ -1208,6 +1382,9 @@ static int cxl_mem_add_memdev(struct cxl_mem *cxlm)
 
 	cdev = &cxlmd->cdev;
 	cdev_init(cdev, &cxl_memdev_fops);
+	rc = cxl_cache_cdat_table(cxlmd);
+	if (rc)
+		goto err_add;
 
 	rc = cdev_device_add(cdev, dev);
 	if (rc)
-- 
2.27.0

[RFC PATCH v3 4/4] cxl/mem: Add a debug parser for CDAT commands

[Jonathan Cameron]

Logs a pretty printed version of the CDAT table entries at driver load.

I find this helpful for development, so including as an extra patch
that I would suggest is never merged.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 v3: renames to match changes in doe function naming.
 
 drivers/cxl/mem.c | 102 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 102 insertions(+)

diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 32354d443f2e..b357dba9048b 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -1042,6 +1042,104 @@ static int cdat_to_buffer(struct pci_doe *doe, u32 *buffer, size_t length)
 	return 0;
 }
 
+static int cdat_dump(struct pci_doe *doe)
+{
+	struct pci_dev *dev = doe->pdev;
+	int entry_handle = 0;
+	int rc;
+
+	if (doe == NULL)
+		return 0;
+
+	dev = doe->pdev;
+	do {
+		/* Table access is available */
+		u32 cdat_request_pl = CDAT_DOE_REQ(entry_handle);
+		u32 cdat_response_pl[32];
+		struct pci_doe_exchange ex = {
+			.vid = PCI_DVSEC_VENDOR_ID_CXL,
+			.protocol = CXL_DOE_PROTOCOL_TABLE_ACCESS,
+			.request_pl = &cdat_request_pl,
+			.request_pl_sz = sizeof(cdat_request_pl),
+			.response_pl = cdat_response_pl,
+			.response_pl_sz = sizeof(cdat_response_pl),
+		};
+		u32 *entry;
+
+		rc = pci_doe_exchange_sync(doe, &ex);
+		if (rc < 0)
+			return rc;
+
+		/* Skip past table response header */
+		entry = cdat_response_pl + 1;
+		if (entry_handle == 0) {
+			pci_info(dev,
+				 "CDAT Header (Length=%u, Revision=%u, Checksum=0x%x, Sequence=%u\n",
+				 entry[0],
+				 FIELD_GET(CDAT_HEADER_DW1_REVISION, entry[1]),
+				 FIELD_GET(CDAT_HEADER_DW1_CHECKSUM, entry[1]),
+				 entry[2]);
+		} else {
+			u8 entry_type = FIELD_GET(CDAT_STRUCTURE_DW0_TYPE, entry[0]);
+
+			switch (entry_type) {
+			case CDAT_STRUCTURE_DW0_TYPE_DSMAS:
+				pci_info(dev,
+					 "CDAT DSMAS (handle=%u flags=0x%x, dpa(0x%llx 0x%llx)\n",
+					 FIELD_GET(CDAT_DSMAS_DW1_DSMAD_HANDLE, entry[1]),
+					 FIELD_GET(CDAT_DSMAS_DW1_FLAGS, entry[1]),
+					 CDAT_DSMAS_DPA_OFFSET(entry),
+					 CDAT_DSMAS_DPA_LEN(entry));
+				break;
+			case CDAT_STRUCTURE_DW0_TYPE_DSLBIS:
+				pci_info(dev,
+					 "CDAT DSLBIS (handle=%u flags=0x%x, ent_base=0x%llx, entry[%u %u %u])\n",
+					 FIELD_GET(CDAT_DSLBIS_DW1_HANDLE, entry[1]),
+					 FIELD_GET(CDAT_DSLBIS_DW1_FLAGS, entry[1]),
+					 CDAT_DSLBIS_BASE_UNIT(entry),
+					 FIELD_GET(CDAT_DSLBIS_DW4_ENTRY_0, entry[4]),
+					 FIELD_GET(CDAT_DSLBIS_DW4_ENTRY_1, entry[4]),
+					 FIELD_GET(CDAT_DSLBIS_DW5_ENTRY_2, entry[5]));
+				break;
+			case CDAT_STRUCTURE_DW0_TYPE_DSMSCIS:
+				pci_info(dev,
+					 "CDAT DSMSCIS (handle=%u sc_size=0x%llx attrs=0x%x)\n",
+					 FIELD_GET(CDAT_DSMSCIS_DW1_HANDLE, entry[1]),
+					 CDAT_DSMSCIS_MEMORY_SIDE_CACHE_SIZE(entry),
+					 FIELD_GET(CDAT_DSMSCIS_DW4_MEMORY_SIDE_CACHE_ATTRS,
+						   entry[4]));
+				break;
+			case CDAT_STRUCTURE_DW0_TYPE_DSIS:
+				pci_info(dev,
+					 "CDAT DSIS (handle=%u flags=0x%x)\n",
+					 FIELD_GET(CDAT_DSIS_DW1_HANDLE, entry[1]),
+					 FIELD_GET(CDAT_DSIS_DW1_FLAGS, entry[1]));
+				break;
+			case CDAT_STRUCTURE_DW0_TYPE_DSEMTS:
+				pci_info(dev,
+					 "CDAT DSEMTS (handle=%u EFI=0x%x dpa(0x%llx 0x%llx)\n",
+					 FIELD_GET(CDAT_DSEMTS_DW1_HANDLE, entry[1]),
+					 FIELD_GET(CDAT_DSEMTS_DW1_EFI_MEMORY_TYPE_ATTR,
+						   entry[1]),
+					 CDAT_DSEMTS_DPA_OFFSET(entry),
+					 CDAT_DSEMTS_DPA_LENGTH(entry));
+				break;
+			case CDAT_STRUCTURE_DW0_TYPE_SSLBIS:
+				pci_info(dev,
+					 "CDAT SSLBIS (type%u ent_base=%llu...)\n",
+					 FIELD_GET(CDAT_SSLBIS_DW1_DATA_TYPE,
+						   entry[1]),
+					 CDAT_SSLBIS_BASE_UNIT(entry));
+				break;
+			}
+		}
+		entry_handle = FIELD_GET(CXL_DOE_TABLE_ACCESS_ENTRY_HANDLE,
+					 cdat_response_pl[0]);
+	} while (entry_handle != 0xFFFF);
+
+	return 0;
+}
+
 static void cxl_mem_free_irq_vectors(void *data)
 {
 	pci_free_irq_vectors(data);
@@ -1136,6 +1234,10 @@ static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo,
 	cxlm->table_doe = pci_doe_find(pdev, PCI_DVSEC_VENDOR_ID_CXL,
 				       CXL_DOE_PROTOCOL_TABLE_ACCESS);
 
+	rc = cdat_dump(cxlm->table_doe);
+	if (rc)
+		return NULL;
+
 	dev_dbg(dev, "Mapped CXL Memory Device resource\n");
 	return cxlm;
 }
-- 
2.27.0

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Ira Weiny]

On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote:
> +
> +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex)
> +{
> +	struct pci_dev *pdev = doe->pdev;
> +	u32 val;
> +	int i;
> +
> +	/*
> +	 * Check the DOE busy bit is not set. If it is set, this could indicate
> +	 * someone other than Linux (e.g. firmware) is using the mailbox. Note
> +	 * it is expected that firmware and OS will negotiate access rights via
> +	 * an, as yet to be defined method.
> +	 */
> +	pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
> +	if (FIELD_GET(PCI_DOE_STATUS_BUSY, val))
> +		return -EBUSY;

In discussion with Dan we believe that user space could also be issuing
commands and would potentially cause us to be locked out.

We agree that firmware should be out of the way here and if it is blocking
the OS there is not much we can do about it.

However, if user space is using the mailbox we need to synchronize with them
via pci_cfg_access_[try]lock().  This should avoid this EBUSY condition.

[snip]

> +
> +static int pci_doe_recv_resp(struct pci_doe *doe, struct pci_doe_exchange *ex)
> +{
> +	struct pci_dev *pdev = doe->pdev;
> +	size_t length;
> +	u32 val;
> +	int i;
> +
> +	/* Read the first two dwords to get the length and protocol */
> +	pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val);
> +	if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != ex->vid) ||
> +	    (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != ex->protocol)) {
> +		pci_err(pdev,
> +			"Expected [VID, Protocol] = [%x, %x], got [%x, %x]\n",
> +			ex->vid, ex->protocol,
> +			FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val),
> +			FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val));
> +		return -EIO;
> +	}
> +
> +	pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0);

I'm quite unfamiliar with the spec here: but it seems like this needs to be
done before the above if statement indicate we got the value?

[snip]

> +
> +static void doe_statemachine_work(struct work_struct *work)
> +{
> +	struct delayed_work *w = to_delayed_work(work);
> +	struct pci_doe *doe = container_of(w, struct pci_doe, statemachine);
> +	struct pci_dev *pdev = doe->pdev;
> +	struct pci_doe_task *task;
> +	bool abort;
> +	u32 val;
> +	int rc;
> +
> +	mutex_lock(&doe->tasks_lock);
> +	task = list_first_entry_or_null(&doe->tasks, struct pci_doe_task, h);
> +	abort = doe->abort;
> +	doe->abort = false;
> +	mutex_unlock(&doe->tasks_lock);
> +
> +	if (abort) {
> +		/*
> +		 * Currently only used during init - care needed if we want to
> +		 * generally expose pci_doe_abort() as it would impact queries
> +		 * in flight.
> +		 */
> +		WARN_ON(task);
> +		doe->state = DOE_WAIT_ABORT;
> +		pci_doe_abort_start(doe);
> +		return;
> +	}
> +
> +	switch (doe->state) {
> +	case DOE_IDLE:
> +		if (task == NULL)
> +			return;
> +
> +		/* Nothing currently in flight so queue a task */
> +		rc = pci_doe_send_req(doe, task->ex);
> +		/*
> +		 * The specification does not provide any guidance on how long
> +		 * some other entity could keep the DOE busy, so try for 1
> +		 * second then fail. Busy handling is best effort only, because
> +		 * there is no way of avoiding racing against another user of
> +		 * the DOE.
> +		 */
> +		if (rc == -EBUSY) {
> +			doe->busy_retries++;
> +			if (doe->busy_retries == PCI_DOE_BUSY_MAX_RETRIES) {
> +				/* Long enough, fail this request */
> +				doe->busy_retries = 0;
> +				goto err_busy;

With the addition of pci_cfg_access_[try]lock():

Should we have some sort of WARN_ON() here to indicate that the system is
behaving badly?

[snip]

> +	case DOE_WAIT_ABORT:
> +	case DOE_WAIT_ABORT_ON_ERR:
> +		pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
> +
> +		if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) &&
> +		    !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) {
> +			/* Back to normal state - carry on */
> +			mutex_lock(&doe->tasks_lock);
> +			if (!list_empty(&doe->tasks))
> +				schedule_delayed_work(w, 0);
> +			mutex_unlock(&doe->tasks_lock);
> +
> +			/*
> +			 * For deliberately triggered abort, someone is
> +			 * waiting.
> +			 */
> +			if (doe->state == DOE_WAIT_ABORT)
> +				complete(&doe->abort_c);
> +			doe->state = DOE_IDLE;
> +
> +			return;
> +		}
> +		if (time_after(jiffies, doe->timeout_jiffies)) {
> +			struct pci_doe_task *t, *n;
> +
> +			/* We are dead - abort all queued tasks */
> +			pci_err(pdev, "DOE ABORT timed out\n");
> +			mutex_lock(&doe->tasks_lock);
> +			doe->dead = true;
> +			list_for_each_entry_safe(t, n, &doe->tasks, h) {
> +				t->rv = -EIO;
> +				t->cb(t->private);
> +				list_del(&t->h);
> +			}
> +
> +			mutex_unlock(&doe->tasks_lock);
> +			if (doe->state == DOE_WAIT_ABORT)
> +				complete(&doe->abort_c);
> +		}
> +		return;
> +	}
> +
> +err_abort:
> +	pci_doe_abort_start(doe);
> +	doe->state = DOE_WAIT_ABORT_ON_ERR;

Should this be before pci_doe_abort_start() to ensure that state is set when
the statemachine runs?

[snip]

> +
> +/**
> + * struct pci_doe - State to support use of DOE mailbox
> + * @cap: Config space offset to base of DOE capability.
> + * @pdev: PCI device that hosts this DOE.
> + * @abort_c: Completion used for initial abort handling.
> + * @irq: Interrupt used for signaling DOE ready or abort.
> + * @prots: Cache of identifiers for protocols supported.
> + * @num_prots: Size of prots cache.
> + * @h: Used for DOE instance lifetime management.
> + * @wq: Workqueue used to handle state machine and polling / timeouts.
> + * @tasks: List of task in flight + pending.
> + * @tasks_lock: Protect the tasks list.

This protects more than just the task list.  It appears to protect abort and
dead as well.  I'm not sure if it is worth mentioning but...

> + * @statemachine: Work item for the DOE state machine.
> + * @state: Current state of this DOE.
> + * @timeout_jiffies: 1 second after GO set.
> + * @busy_retries: Count of retry attempts.
> + * @abort: Request a manual abort (e.g. on init).
> + * @dead: Used to mark a DOE for which an ABORT has timed out. Further messages
> + *        will immediately be aborted with error.
> + */
> +struct pci_doe {
> +	int cap;
> +	struct pci_dev *pdev;
> +	struct completion abort_c;
> +	int irq;
> +	struct pci_doe_prot *prots;
> +	int num_prots;
> +	struct list_head h;
> +
> +	struct workqueue_struct *wq;
> +	struct list_head tasks;
> +	struct mutex tasks_lock;
> +	struct delayed_work statemachine;
> +	enum pci_doe_state state;
> +	unsigned long timeout_jiffies;
> +	unsigned int busy_retries;
> +	unsigned int abort:1;
> +	unsigned int dead:1;
> +};

[snip]

Ira

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Tue, 20 Apr 2021 00:54:49 +0800
Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:

> Introduced in a PCI ECN [1], DOE provides a config space
> based mailbox with standard protocol discovery.  Each mailbox
> is accessed through a DOE Extended Capability.
> 
> A device may have 1 or more DOE mailboxes, each of which is allowed
> to support any number of protocols (some DOE protocol
> specifications apply additional restrictions).  A given protocol
> may be supported on more than one DOE mailbox on a given function.
> 
> If a driver wishes to access any number of DOE instances / protocols
> it makes a single call to pcie_doe_register_all() which will find
> available DOEs, create the required infrastructure and cache the
> protocols they support.  pcie_doe_find() can then retrieve a
> pointer to an appropriate DOE instance.
> 
> A synchronous interface is provided in pcie_doe_exchange_sync() to
> perform a single query / response exchange.
> 
> Testing conducted against QEMU using:
> 
> https://lore.kernel.org/qemu-devel/1612900760-7361-1-git-send-email-cbrowy@avery-design.com/
> + fix for interrupt flag mentioned in that thread and a whole load
> of hacks to exercise error paths etc.
> 
> [1] https://members.pcisig.com/wg/PCI-SIG/document/14143
>     Data Object Exchange (DOE) - Approved 12 March 2020
> 
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---

...

> +static int pci_doe_recv_resp(struct pci_doe *doe, struct pci_doe_exchange *ex)
> +{
> +	struct pci_dev *pdev = doe->pdev;
> +	size_t length;
> +	u32 val;
> +	int i;
> +
> +	/* Read the first two dwords to get the length and protocol */
> +	pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val);
> +	if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != ex->vid) ||
> +	    (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != ex->protocol)) {
> +		pci_err(pdev,
> +			"Expected [VID, Protocol] = [%x, %x], got [%x, %x]\n",
> +			ex->vid, ex->protocol,
> +			FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val),
> +			FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val));
> +		return -EIO;
> +	}
> +
> +	pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0);
> +	pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val);
> +	pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0);
> +
> +	length = FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH, val);
> +	if (length > SZ_1M)
> +		return -EIO;
> +
> +	/* Read the rest of the response payload */
> +	for (i = 0; i < min(length, ex->response_pl_sz / sizeof(u32)); i++) {

Note for anyone testing these that there is a bug here which leads to
a buffer underflow triggered reset with the latest QEMU patches
(I've not figured out yet why this didn't trigger a problem with the earlier
QEMU patch versions).

This needs to take into account that length includes the two header DW, but
the response_pl_sz does not.
 

> +		pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ,
> +				      &ex->response_pl[i]);
> +		pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0);
> +	}
> +
> +	/* Flush excess length */
> +	for (; i < length; i++) {
> +		pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val);
> +		pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0);
> +	}
> +	/* Final error check to pick up on any since Data Object Ready */
> +	pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
> +	if (FIELD_GET(PCI_DOE_STATUS_ERROR, val))
> +		return -EIO;
> +
> +	return min(length, ex->response_pl_sz / sizeof(u32)) * sizeof(u32);
> +}
> +

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Bjorn Helgaas]

s/doe/DOE/ in subject.

On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote:
> Introduced in a PCI ECN [1], DOE provides a config space
> based mailbox with standard protocol discovery.  Each mailbox
> is accessed through a DOE Extended Capability.
> 
> A device may have 1 or more DOE mailboxes, each of which is allowed
> to support any number of protocols (some DOE protocol
> specifications apply additional restrictions).  A given protocol
> may be supported on more than one DOE mailbox on a given function.
> 
> If a driver wishes to access any number of DOE instances / protocols
> it makes a single call to pcie_doe_register_all() which will find
> available DOEs, create the required infrastructure and cache the
> protocols they support.  pcie_doe_find() can then retrieve a
> pointer to an appropriate DOE instance.
> 
> A synchronous interface is provided in pcie_doe_exchange_sync() to
> perform a single query / response exchange.

Re-wrap above (and commit logs of other patches) to fill 75 columns.

s/pcie_doe_register_all/pci_doe_register_all/
s/pcie_doe_find/pci_doe_find/
s/pcie_doe_exchange_sync/pci_doe_exchange_sync/

> +config PCI_DOE
> +	bool
> +	help
> +	  This enables library support for the PCI Data Object Exchange
> +	  capability. DOE provides a simple mailbox in PCI config space that is
> +	  used by a number of different protocols.
> +	  DOE is defined in the Data Object Exchange ECN to PCI 5.0.

"ECN to the PCIe r5.0 spec."

"PCI 5.0" sounds like a conventional PCI spec.

> + * pci_doe_exchange_sync() - Send a request, then wait for and receive response.
> + * @doe: DOE mailbox state structure.
> + * @ex: Description of the buffers and Vendor ID + type used in this
> + *      request/response pair,

s/,/./

(Or omit the periods altogether on these function and parameter
one-liners, as most of drivers/pci does.  Most of these descriptions
aren't sentences anyway, I think it's fine that they're unterminated.)

> +static void pci_doe_init(struct pci_doe *doe, struct pci_dev *pdev, int doe_offset)

Indent to fit in 80 columns like the rest of drivers/pci/.

> +static int pci_doe_register(struct pci_doe *doe)
> +{
> +	struct pci_dev *pdev = doe->pdev;
> +	bool poll = !pci_dev_msi_enabled(pdev);
> +	int rc, irq;
> +	u32 val;
> +
> +	pci_read_config_dword(pdev, doe->cap + PCI_DOE_CAP, &val);
> +
> +	if (!poll && FIELD_GET(PCI_DOE_CAP_INT, val)) {
> +		irq = pci_irq_vector(pdev, FIELD_GET(PCI_DOE_CAP_IRQ, val));
> +		if (irq < 0)
> +			return irq;
> +
> +		rc = request_irq(irq, pci_doe_irq, 0, "DOE", doe);

I expect there may be many devices with DOE.  Do you want some
device identification here?  E.g., on my system I see things like this
in /proc/interrupts:

  dmar0
  nvme0q0
  snd_hda_intel:card0
  ahci[0000:00:17.0]

> +++ b/include/linux/pci-doe.h
> @@ -0,0 +1,85 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Data Object Exchange was added to the PCI spec as an ECN to 5.0.

"... was added as an ECN to the PCIe r5.0 spec."

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Thu, 6 May 2021 14:59:34 -0700
Ira Weiny <ira.weiny@intel.com> wrote:

> On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote:
> > +
> > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex)
> > +{
> > +	struct pci_dev *pdev = doe->pdev;
> > +	u32 val;
> > +	int i;
> > +
> > +	/*
> > +	 * Check the DOE busy bit is not set. If it is set, this could indicate
> > +	 * someone other than Linux (e.g. firmware) is using the mailbox. Note
> > +	 * it is expected that firmware and OS will negotiate access rights via
> > +	 * an, as yet to be defined method.
> > +	 */
> > +	pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
> > +	if (FIELD_GET(PCI_DOE_STATUS_BUSY, val))
> > +		return -EBUSY;  
> 
> In discussion with Dan we believe that user space could also be issuing
> commands and would potentially cause us to be locked out.
> 
> We agree that firmware should be out of the way here and if it is blocking
> the OS there is not much we can do about it.
> 
> However, if user space is using the mailbox we need to synchronize with them
> via pci_cfg_access_[try]lock().  This should avoid this EBUSY condition.

Hi Ira, thanks for taking a look.

So the question here is whether we can ever safely work with a
userspace that is accessing the DOE.  I think the answer is no we can't.

We'd have no way of knowing that userspace left the DOE in a clean state
without resetting every time we want to use it (which can take 1 second)
or doing significant sanity checking (can we tell if something is
in flight?).  Note that if userspace and kernel were talking different
protocols nothing sensible could be done to prevent them receiving each
other's answers (unless you can rely on userspace holding the lock until
it is done - which you can't as who trusts userspace?) You could do
something horrible like back off after peeking at the protocol to see
if it might be yours, but even that only works assuming the two are
trying to talk different protocols (talking the same protocol isn't allowed
but no way to enforce that using just pci_cfg_access_lock()).

I can't see a way to tell that the DOE might not have responded to an
earlier request.  DOE busy indicates the write mailbox register cannot
receive data at the moment.  If it's set then there is a message in
flight, but if it is not set there might still be a message in flight.
Busy only indicates if the write mailbox register can sink a request
which doesn't in general tell us anything about the underlying state.

So if userspace sent a request then quit.  Kernel driver would have
no way of knowing if the next response was due to the request it sent
or some earlier one (other than matching IDs)  Note you aren't allowed
to have multiple requests for a single protocol in flight at the same
time.  With just a lock you would have no way of preventing this.

So we are back to every request the kernel sent having to be proceeded
by an abort and potentially a 1 second delay whilst some chunk of the
device firmware reboots.

This came up in dicussion when Dan proposed the patch
[PATCH] PCI: Allow drivers to claim exclusive access to config regions
https://lore.kernel.org/linux-pci/161663543465.1867664.5674061943008380442.stgit@dwillia2-desk3.amr.corp.intel.com/
Summarizing outcome of that thread.

1) Reads of DOE registers are always safe, so we shouldn't stop lspci
and similar accessing config space.
2) You are on your own if any userspace writes to pci config space.
There are loads of ways it can break the system so it doesn't make much
sense to protect against one more.

If there is a reason to provide a userspace interface to a DOE for a
device with a driver attached, then I would agree with Dan's suggestion
to use a proper driver for it.

Dan briefly mentioned that temporary blocking might be needed. I'm guessing
that was to try and let userspace safely use the DOE.

The driver would work fine ignoring busy entirely and would perhaps be
less confusing as a result.  We reset the DOE at startup anyway and that
would clear existing busy.  Any future times busy is set would have no
impact on the flow.

> 
> [snip]
> 
> > +
> > +static int pci_doe_recv_resp(struct pci_doe *doe, struct pci_doe_exchange *ex)
> > +{
> > +	struct pci_dev *pdev = doe->pdev;
> > +	size_t length;
> > +	u32 val;
> > +	int i;
> > +
> > +	/* Read the first two dwords to get the length and protocol */
> > +	pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val);
> > +	if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != ex->vid) ||
> > +	    (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != ex->protocol)) {
> > +		pci_err(pdev,
> > +			"Expected [VID, Protocol] = [%x, %x], got [%x, %x]\n",
> > +			ex->vid, ex->protocol,
> > +			FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val),
> > +			FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val));
> > +		return -EIO;
> > +	}
> > +
> > +	pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0);  
> 
> I'm quite unfamiliar with the spec here: but it seems like this needs to be
> done before the above if statement indicate we got the value?

Perhaps it's the comment that caused confusion here. It covered
the next few lines as well. You need to read the first DW to get protocol
(and write it to be able to read the next one back)
The second dw is then need to get to the length which follows this.

I'll split the comment into two parts so that it's clearer what it is referring
to.

On any error here, we end up calling a abort anyway so state on error paths of
the DOE doesn't matter.

> 
> [snip]
> 
> > +
> > +static void doe_statemachine_work(struct work_struct *work)
> > +{
> > +	struct delayed_work *w = to_delayed_work(work);
> > +	struct pci_doe *doe = container_of(w, struct pci_doe, statemachine);
> > +	struct pci_dev *pdev = doe->pdev;
> > +	struct pci_doe_task *task;
> > +	bool abort;
> > +	u32 val;
> > +	int rc;
> > +
> > +	mutex_lock(&doe->tasks_lock);
> > +	task = list_first_entry_or_null(&doe->tasks, struct pci_doe_task, h);
> > +	abort = doe->abort;
> > +	doe->abort = false;
> > +	mutex_unlock(&doe->tasks_lock);
> > +
> > +	if (abort) {
> > +		/*
> > +		 * Currently only used during init - care needed if we want to
> > +		 * generally expose pci_doe_abort() as it would impact queries
> > +		 * in flight.
> > +		 */
> > +		WARN_ON(task);
> > +		doe->state = DOE_WAIT_ABORT;
> > +		pci_doe_abort_start(doe);
> > +		return;
> > +	}
> > +
> > +	switch (doe->state) {
> > +	case DOE_IDLE:
> > +		if (task == NULL)
> > +			return;
> > +
> > +		/* Nothing currently in flight so queue a task */
> > +		rc = pci_doe_send_req(doe, task->ex);
> > +		/*
> > +		 * The specification does not provide any guidance on how long
> > +		 * some other entity could keep the DOE busy, so try for 1
> > +		 * second then fail. Busy handling is best effort only, because
> > +		 * there is no way of avoiding racing against another user of
> > +		 * the DOE.
> > +		 */
> > +		if (rc == -EBUSY) {
> > +			doe->busy_retries++;
> > +			if (doe->busy_retries == PCI_DOE_BUSY_MAX_RETRIES) {
> > +				/* Long enough, fail this request */
> > +				doe->busy_retries = 0;
> > +				goto err_busy;  
> 
> With the addition of pci_cfg_access_[try]lock():
> 
> Should we have some sort of WARN_ON() here to indicate that the system is
> behaving badly?

Makes sense. I'll add a pci_WARN() here

> 
> [snip]
> 
> > +	case DOE_WAIT_ABORT:
> > +	case DOE_WAIT_ABORT_ON_ERR:
> > +		pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
> > +
> > +		if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) &&
> > +		    !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) {
> > +			/* Back to normal state - carry on */
> > +			mutex_lock(&doe->tasks_lock);
> > +			if (!list_empty(&doe->tasks))
> > +				schedule_delayed_work(w, 0);
> > +			mutex_unlock(&doe->tasks_lock);
> > +
> > +			/*
> > +			 * For deliberately triggered abort, someone is
> > +			 * waiting.
> > +			 */
> > +			if (doe->state == DOE_WAIT_ABORT)
> > +				complete(&doe->abort_c);
> > +			doe->state = DOE_IDLE;
> > +
> > +			return;
> > +		}
> > +		if (time_after(jiffies, doe->timeout_jiffies)) {
> > +			struct pci_doe_task *t, *n;
> > +
> > +			/* We are dead - abort all queued tasks */
> > +			pci_err(pdev, "DOE ABORT timed out\n");
> > +			mutex_lock(&doe->tasks_lock);
> > +			doe->dead = true;
> > +			list_for_each_entry_safe(t, n, &doe->tasks, h) {
> > +				t->rv = -EIO;
> > +				t->cb(t->private);
> > +				list_del(&t->h);
> > +			}
> > +
> > +			mutex_unlock(&doe->tasks_lock);
> > +			if (doe->state == DOE_WAIT_ABORT)
> > +				complete(&doe->abort_c);
> > +		}
> > +		return;
> > +	}
> > +
> > +err_abort:
> > +	pci_doe_abort_start(doe);
> > +	doe->state = DOE_WAIT_ABORT_ON_ERR;  
> 
> Should this be before pci_doe_abort_start() to ensure that state is set when
> the statemachine runs?

Don't think it's a bug (single work item) but it's definitely
clearer the other way around.

> 
> [snip]
> 
> > +
> > +/**
> > + * struct pci_doe - State to support use of DOE mailbox
> > + * @cap: Config space offset to base of DOE capability.
> > + * @pdev: PCI device that hosts this DOE.
> > + * @abort_c: Completion used for initial abort handling.
> > + * @irq: Interrupt used for signaling DOE ready or abort.
> > + * @prots: Cache of identifiers for protocols supported.
> > + * @num_prots: Size of prots cache.
> > + * @h: Used for DOE instance lifetime management.
> > + * @wq: Workqueue used to handle state machine and polling / timeouts.
> > + * @tasks: List of task in flight + pending.
> > + * @tasks_lock: Protect the tasks list.  
> 
> This protects more than just the task list.  It appears to protect abort and
> dead as well.  I'm not sure if it is worth mentioning but...

Added 'abort state' to that comment.

> 
> > + * @statemachine: Work item for the DOE state machine.
> > + * @state: Current state of this DOE.
> > + * @timeout_jiffies: 1 second after GO set.
> > + * @busy_retries: Count of retry attempts.
> > + * @abort: Request a manual abort (e.g. on init).
> > + * @dead: Used to mark a DOE for which an ABORT has timed out. Further messages
> > + *        will immediately be aborted with error.
> > + */
> > +struct pci_doe {
> > +	int cap;
> > +	struct pci_dev *pdev;
> > +	struct completion abort_c;
> > +	int irq;
> > +	struct pci_doe_prot *prots;
> > +	int num_prots;
> > +	struct list_head h;
> > +
> > +	struct workqueue_struct *wq;
> > +	struct list_head tasks;
> > +	struct mutex tasks_lock;
> > +	struct delayed_work statemachine;
> > +	enum pci_doe_state state;
> > +	unsigned long timeout_jiffies;
> > +	unsigned int busy_retries;
> > +	unsigned int abort:1;
> > +	unsigned int dead:1;
> > +};  
> 
> [snip]
> 
> Ira
> 
Thanks!

Jonathan

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Fri, 7 May 2021 18:10:13 -0500
Bjorn Helgaas <helgaas@kernel.org> wrote:

Thanks. All updates as per your comments.

> > +static int pci_doe_register(struct pci_doe *doe)
> > +{
> > +	struct pci_dev *pdev = doe->pdev;
> > +	bool poll = !pci_dev_msi_enabled(pdev);
> > +	int rc, irq;
> > +	u32 val;
> > +
> > +	pci_read_config_dword(pdev, doe->cap + PCI_DOE_CAP, &val);
> > +
> > +	if (!poll && FIELD_GET(PCI_DOE_CAP_INT, val)) {
> > +		irq = pci_irq_vector(pdev, FIELD_GET(PCI_DOE_CAP_IRQ, val));
> > +		if (irq < 0)
> > +			return irq;
> > +
> > +		rc = request_irq(irq, pci_doe_irq, 0, "DOE", doe);  
> 
> I expect there may be many devices with DOE.  Do you want some
> device identification here?  E.g., on my system I see things like this
> in /proc/interrupts:
> 
>   dmar0
>   nvme0q0
>   snd_hda_intel:card0
>   ahci[0000:00:17.0]

Good point.  For this I've currently gone with

DOE[0000:00:81.0]_160
DOE[0000:00:81.0]_190

etc as a single function can have multiple DOE instances
and the easiest way to distinguish them is the offset at
which the capability is found in config space of the device.

I'm open to other suggestions.

Jonathan

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Dan Williams]

On Tue, May 11, 2021 at 9:52 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Thu, 6 May 2021 14:59:34 -0700
> Ira Weiny <ira.weiny@intel.com> wrote:
>
> > On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote:
> > > +
> > > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex)
> > > +{
> > > +   struct pci_dev *pdev = doe->pdev;
> > > +   u32 val;
> > > +   int i;
> > > +
> > > +   /*
> > > +    * Check the DOE busy bit is not set. If it is set, this could indicate
> > > +    * someone other than Linux (e.g. firmware) is using the mailbox. Note
> > > +    * it is expected that firmware and OS will negotiate access rights via
> > > +    * an, as yet to be defined method.
> > > +    */
> > > +   pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
> > > +   if (FIELD_GET(PCI_DOE_STATUS_BUSY, val))
> > > +           return -EBUSY;
> >
> > In discussion with Dan we believe that user space could also be issuing
> > commands and would potentially cause us to be locked out.
> >
> > We agree that firmware should be out of the way here and if it is blocking
> > the OS there is not much we can do about it.
> >
> > However, if user space is using the mailbox we need to synchronize with them
> > via pci_cfg_access_[try]lock().  This should avoid this EBUSY condition.
>
> Hi Ira, thanks for taking a look.
>
> So the question here is whether we can ever safely work with a
> userspace that is accessing the DOE.  I think the answer is no we can't.
>
> We'd have no way of knowing that userspace left the DOE in a clean state
> without resetting every time we want to use it (which can take 1 second)
> or doing significant sanity checking (can we tell if something is
> in flight?).  Note that if userspace and kernel were talking different
> protocols nothing sensible could be done to prevent them receiving each
> other's answers (unless you can rely on userspace holding the lock until
> it is done - which you can't as who trusts userspace?)

There is no ability for userpsace to lock out the kernel, only kernel
locking out userspace.

> You could do
> something horrible like back off after peeking at the protocol to see
> if it might be yours, but even that only works assuming the two are
> trying to talk different protocols (talking the same protocol isn't allowed
> but no way to enforce that using just pci_cfg_access_lock()).

Wait why isn't pci_cfg_access_lock() sufficient? The userspace DOE
transfer is halted, the kernel validates the state of DOE, does it's
work and releases the lock.

> I can't see a way to tell that the DOE might not have responded to an
> earlier request.  DOE busy indicates the write mailbox register cannot
> receive data at the moment.  If it's set then there is a message in
> flight, but if it is not set there might still be a message in flight.
> Busy only indicates if the write mailbox register can sink a request
> which doesn't in general tell us anything about the underlying state.
>
> So if userspace sent a request then quit.  Kernel driver would have
> no way of knowing if the next response was due to the request it sent
> or some earlier one (other than matching IDs)  Note you aren't allowed
> to have multiple requests for a single protocol in flight at the same
> time.  With just a lock you would have no way of preventing this.
>
> So we are back to every request the kernel sent having to be proceeded
> by an abort and potentially a 1 second delay whilst some chunk of the
> device firmware reboots.
>
> This came up in dicussion when Dan proposed the patch
> [PATCH] PCI: Allow drivers to claim exclusive access to config regions
> https://lore.kernel.org/linux-pci/161663543465.1867664.5674061943008380442.stgit@dwillia2-desk3.amr.corp.intel.com/
> Summarizing outcome of that thread.
>
> 1) Reads of DOE registers are always safe, so we shouldn't stop lspci
> and similar accessing config space.
> 2) You are on your own if any userspace writes to pci config space.
> There are loads of ways it can break the system so it doesn't make much
> sense to protect against one more.

I'm not quite as enthusiastic about Greg's assertion that "we're
already broken why not allow more breakage" as he was also the one
supportive of /dev/mem restrictions in the face of obvious collisions.
I'll circle back and say as much to Greg. My mistake was not realizing
the write dependency in the protocol, so the pushback was warranted
that the kernel does not need to block out all access.

Given that /dev/mem is optionally disabled for userspace access
outside of kernel-lockdown scenarios, I think it is reasonable to have
the kernel disable config writes to a register block and the request
of a driver.

Consider that userspace can certainly trash the system by writing to
the BAR registers, for example, but a non-malicious userspace has no
reason to do that. Unfortunately DOE has some utility for a
non-malicious userspace to access so there is a rationale to figure
out a cooperation scheme.

>
> If there is a reason to provide a userspace interface to a DOE for a
> device with a driver attached, then I would agree with Dan's suggestion
> to use a proper driver for it.
>
> Dan briefly mentioned that temporary blocking might be needed. I'm guessing
> that was to try and let userspace safely use the DOE.
>
> The driver would work fine ignoring busy entirely and would perhaps be
> less confusing as a result.  We reset the DOE at startup anyway and that
> would clear existing busy.  Any future times busy is set would have no
> impact on the flow.

If it simplifies the kernel implementation to assume single
kernel-initiator then I think that's more than enough reason to block
out userspace, and/or provide userspace a method to get into the
kernel's queue for service.

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Thu, 13 May 2021 14:20:38 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> On Tue, May 11, 2021 at 9:52 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Thu, 6 May 2021 14:59:34 -0700
> > Ira Weiny <ira.weiny@intel.com> wrote:
> >  
> > > On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote:  
> > > > +
> > > > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex)
> > > > +{
> > > > +   struct pci_dev *pdev = doe->pdev;
> > > > +   u32 val;
> > > > +   int i;
> > > > +
> > > > +   /*
> > > > +    * Check the DOE busy bit is not set. If it is set, this could indicate
> > > > +    * someone other than Linux (e.g. firmware) is using the mailbox. Note
> > > > +    * it is expected that firmware and OS will negotiate access rights via
> > > > +    * an, as yet to be defined method.
> > > > +    */
> > > > +   pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
> > > > +   if (FIELD_GET(PCI_DOE_STATUS_BUSY, val))
> > > > +           return -EBUSY;  
> > >
> > > In discussion with Dan we believe that user space could also be issuing
> > > commands and would potentially cause us to be locked out.
> > >
> > > We agree that firmware should be out of the way here and if it is blocking
> > > the OS there is not much we can do about it.
> > >
> > > However, if user space is using the mailbox we need to synchronize with them
> > > via pci_cfg_access_[try]lock().  This should avoid this EBUSY condition.  
> >
> > Hi Ira, thanks for taking a look.
> >
> > So the question here is whether we can ever safely work with a
> > userspace that is accessing the DOE.  I think the answer is no we can't.
> >
> > We'd have no way of knowing that userspace left the DOE in a clean state
> > without resetting every time we want to use it (which can take 1 second)
> > or doing significant sanity checking (can we tell if something is
> > in flight?).  Note that if userspace and kernel were talking different
> > protocols nothing sensible could be done to prevent them receiving each
> > other's answers (unless you can rely on userspace holding the lock until
> > it is done - which you can't as who trusts userspace?)  
> 
> There is no ability for userpsace to lock out the kernel, only kernel
> locking out userspace.

Hi Dan,

Got it. Writing userspace to code with arbitrary kernel
breakage of exchanges userspace initialized is going to be nasty. 

> 
> > You could do
> > something horrible like back off after peeking at the protocol to see
> > if it might be yours, but even that only works assuming the two are
> > trying to talk different protocols (talking the same protocol isn't allowed
> > but no way to enforce that using just pci_cfg_access_lock()).  
> 
> Wait why isn't pci_cfg_access_lock() sufficient? The userspace DOE
> transfer is halted, the kernel validates the state of DOE, does it's
> work and releases the lock.

It's that 'validate the state of the DOE' which is the problem.  I 'think'
the only way to do that is to issue an abort every time and I'm really
not liking the fact that adds a potential 1 second sleep to every
DOE access from the kernel.  There is no other way of knowing there is
no exchange already in flight that might come back and bite you even
after you think you have a clean state + I think you might be able to
construct cases where even inspecting the data isn't enough to tell.
If we are safe with today's protocols, there is no guarantee we will be
in future. If the DOE design had incorporated such a flag or counter of
exchanges in flight, then this might have been a workable approach. 

> 
> > I can't see a way to tell that the DOE might not have responded to an
> > earlier request.  DOE busy indicates the write mailbox register cannot
> > receive data at the moment.  If it's set then there is a message in
> > flight, but if it is not set there might still be a message in flight.
> > Busy only indicates if the write mailbox register can sink a request
> > which doesn't in general tell us anything about the underlying state.
> >
> > So if userspace sent a request then quit.  Kernel driver would have
> > no way of knowing if the next response was due to the request it sent
> > or some earlier one (other than matching IDs)  Note you aren't allowed
> > to have multiple requests for a single protocol in flight at the same
> > time.  With just a lock you would have no way of preventing this.
> >
> > So we are back to every request the kernel sent having to be proceeded
> > by an abort and potentially a 1 second delay whilst some chunk of the
> > device firmware reboots.
> >
> > This came up in dicussion when Dan proposed the patch
> > [PATCH] PCI: Allow drivers to claim exclusive access to config regions
> > https://lore.kernel.org/linux-pci/161663543465.1867664.5674061943008380442.stgit@dwillia2-desk3.amr.corp.intel.com/
> > Summarizing outcome of that thread.
> >
> > 1) Reads of DOE registers are always safe, so we shouldn't stop lspci
> > and similar accessing config space.
> > 2) You are on your own if any userspace writes to pci config space.
> > There are loads of ways it can break the system so it doesn't make much
> > sense to protect against one more.  
> 
> I'm not quite as enthusiastic about Greg's assertion that "we're
> already broken why not allow more breakage" as he was also the one
> supportive of /dev/mem restrictions in the face of obvious collisions.
> I'll circle back and say as much to Greg. My mistake was not realizing
> the write dependency in the protocol, so the pushback was warranted
> that the kernel does not need to block out all access.
> 
> Given that /dev/mem is optionally disabled for userspace access
> outside of kernel-lockdown scenarios, I think it is reasonable to have
> the kernel disable config writes to a register block and the request
> of a driver.
> 
> Consider that userspace can certainly trash the system by writing to
> the BAR registers, for example, but a non-malicious userspace has no
> reason to do that. Unfortunately DOE has some utility for a
> non-malicious userspace to access so there is a rationale to figure
> out a cooperation scheme.

I agree with a cooperation scheme, but I think that should take the
form of a proper interface rather than a one sided lock out.
It may well make sense to tighten access to PCI config space anyway but
I think that's a discussion that should be separate from this feature.

> 
> >
> > If there is a reason to provide a userspace interface to a DOE for a
> > device with a driver attached, then I would agree with Dan's suggestion
> > to use a proper driver for it.
> >
> > Dan briefly mentioned that temporary blocking might be needed. I'm guessing
> > that was to try and let userspace safely use the DOE.
> >
> > The driver would work fine ignoring busy entirely and would perhaps be
> > less confusing as a result.  We reset the DOE at startup anyway and that
> > would clear existing busy.  Any future times busy is set would have no
> > impact on the flow.  
> 
> If it simplifies the kernel implementation to assume single
> kernel-initiator then I think that's more than enough reason to block
> out userspace, and/or provide userspace a method to get into the
> kernel's queue for service.

This last suggestion makes sense to me. Let's provide a 'right' way
to access the DOE from user space. I like the idea if it being possible
to run CXL compliance tests from userspace whilst the driver is loaded.

Bjorn, given this would be a generic PCI thing, any preference for what
this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
to those for the BAR based CXL mailboxes?

Thanks,

Jonathan

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Lorenzo Pieralisi]

On Fri, May 14, 2021 at 09:47:55AM +0100, Jonathan Cameron wrote:
> On Thu, 13 May 2021 14:20:38 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
> 
> > On Tue, May 11, 2021 at 9:52 AM Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > >
> > > On Thu, 6 May 2021 14:59:34 -0700
> > > Ira Weiny <ira.weiny@intel.com> wrote:
> > >  
> > > > On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote:  
> > > > > +
> > > > > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex)
> > > > > +{
> > > > > +   struct pci_dev *pdev = doe->pdev;
> > > > > +   u32 val;
> > > > > +   int i;
> > > > > +
> > > > > +   /*
> > > > > +    * Check the DOE busy bit is not set. If it is set, this could indicate
> > > > > +    * someone other than Linux (e.g. firmware) is using the mailbox. Note
> > > > > +    * it is expected that firmware and OS will negotiate access rights via
> > > > > +    * an, as yet to be defined method.
> > > > > +    */
> > > > > +   pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
> > > > > +   if (FIELD_GET(PCI_DOE_STATUS_BUSY, val))
> > > > > +           return -EBUSY;  
> > > >
> > > > In discussion with Dan we believe that user space could also be issuing
> > > > commands and would potentially cause us to be locked out.
> > > >
> > > > We agree that firmware should be out of the way here and if it is blocking
> > > > the OS there is not much we can do about it.
> > > >
> > > > However, if user space is using the mailbox we need to synchronize with them
> > > > via pci_cfg_access_[try]lock().  This should avoid this EBUSY condition.  
> > >
> > > Hi Ira, thanks for taking a look.
> > >
> > > So the question here is whether we can ever safely work with a
> > > userspace that is accessing the DOE.  I think the answer is no we can't.
> > >
> > > We'd have no way of knowing that userspace left the DOE in a clean state
> > > without resetting every time we want to use it (which can take 1 second)
> > > or doing significant sanity checking (can we tell if something is
> > > in flight?).  Note that if userspace and kernel were talking different
> > > protocols nothing sensible could be done to prevent them receiving each
> > > other's answers (unless you can rely on userspace holding the lock until
> > > it is done - which you can't as who trusts userspace?)  
> > 
> > There is no ability for userpsace to lock out the kernel, only kernel
> > locking out userspace.
> 
> Hi Dan,
> 
> Got it. Writing userspace to code with arbitrary kernel
> breakage of exchanges userspace initialized is going to be nasty. 
> 
> > 
> > > You could do
> > > something horrible like back off after peeking at the protocol to see
> > > if it might be yours, but even that only works assuming the two are
> > > trying to talk different protocols (talking the same protocol isn't allowed
> > > but no way to enforce that using just pci_cfg_access_lock()).  
> > 
> > Wait why isn't pci_cfg_access_lock() sufficient? The userspace DOE
> > transfer is halted, the kernel validates the state of DOE, does it's
> > work and releases the lock.
> 
> It's that 'validate the state of the DOE' which is the problem.  I 'think'
> the only way to do that is to issue an abort every time and I'm really
> not liking the fact that adds a potential 1 second sleep to every
> DOE access from the kernel.

IIUC an abort would mean game over for *every* transaction in flight,
not sure that's the best way of preventing userspace from mingling
but as you mentioned I don't think there is a way around it with the
current protocol.

I don't see how a lock would solve this issue either - how would it ?

Basically you have to stop userspace from issuing requests for the
duration of a request/response (per-protocol) session, right ?

Lorenzo

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Fri, 14 May 2021 12:15:38 +0100
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:

> On Fri, May 14, 2021 at 09:47:55AM +0100, Jonathan Cameron wrote:
> > On Thu, 13 May 2021 14:20:38 -0700
> > Dan Williams <dan.j.williams@intel.com> wrote:
> >   
> > > On Tue, May 11, 2021 at 9:52 AM Jonathan Cameron
> > > <Jonathan.Cameron@huawei.com> wrote:  
> > > >
> > > > On Thu, 6 May 2021 14:59:34 -0700
> > > > Ira Weiny <ira.weiny@intel.com> wrote:
> > > >    
> > > > > On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote:    
> > > > > > +
> > > > > > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex)
> > > > > > +{
> > > > > > +   struct pci_dev *pdev = doe->pdev;
> > > > > > +   u32 val;
> > > > > > +   int i;
> > > > > > +
> > > > > > +   /*
> > > > > > +    * Check the DOE busy bit is not set. If it is set, this could indicate
> > > > > > +    * someone other than Linux (e.g. firmware) is using the mailbox. Note
> > > > > > +    * it is expected that firmware and OS will negotiate access rights via
> > > > > > +    * an, as yet to be defined method.
> > > > > > +    */
> > > > > > +   pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
> > > > > > +   if (FIELD_GET(PCI_DOE_STATUS_BUSY, val))
> > > > > > +           return -EBUSY;    
> > > > >
> > > > > In discussion with Dan we believe that user space could also be issuing
> > > > > commands and would potentially cause us to be locked out.
> > > > >
> > > > > We agree that firmware should be out of the way here and if it is blocking
> > > > > the OS there is not much we can do about it.
> > > > >
> > > > > However, if user space is using the mailbox we need to synchronize with them
> > > > > via pci_cfg_access_[try]lock().  This should avoid this EBUSY condition.    
> > > >
> > > > Hi Ira, thanks for taking a look.
> > > >
> > > > So the question here is whether we can ever safely work with a
> > > > userspace that is accessing the DOE.  I think the answer is no we can't.
> > > >
> > > > We'd have no way of knowing that userspace left the DOE in a clean state
> > > > without resetting every time we want to use it (which can take 1 second)
> > > > or doing significant sanity checking (can we tell if something is
> > > > in flight?).  Note that if userspace and kernel were talking different
> > > > protocols nothing sensible could be done to prevent them receiving each
> > > > other's answers (unless you can rely on userspace holding the lock until
> > > > it is done - which you can't as who trusts userspace?)    
> > > 
> > > There is no ability for userpsace to lock out the kernel, only kernel
> > > locking out userspace.  
> > 
> > Hi Dan,
> > 
> > Got it. Writing userspace to code with arbitrary kernel
> > breakage of exchanges userspace initialized is going to be nasty. 
> >   
> > >   
> > > > You could do
> > > > something horrible like back off after peeking at the protocol to see
> > > > if it might be yours, but even that only works assuming the two are
> > > > trying to talk different protocols (talking the same protocol isn't allowed
> > > > but no way to enforce that using just pci_cfg_access_lock()).    
> > > 
> > > Wait why isn't pci_cfg_access_lock() sufficient? The userspace DOE
> > > transfer is halted, the kernel validates the state of DOE, does it's
> > > work and releases the lock.  
> > 
> > It's that 'validate the state of the DOE' which is the problem.  I 'think'
> > the only way to do that is to issue an abort every time and I'm really
> > not liking the fact that adds a potential 1 second sleep to every
> > DOE access from the kernel.  
> 
> IIUC an abort would mean game over for *every* transaction in flight,
> not sure that's the best way of preventing userspace from mingling
> but as you mentioned I don't think there is a way around it with the
> current protocol.
> 
> I don't see how a lock would solve this issue either - how would it ?

It would only work if symmetric (can be locked by userspace or kernel space)
and userspace was well behaved.

> 
> Basically you have to stop userspace from issuing requests for the
> duration of a request/response (per-protocol) session, right ?

Yes, but also stop the kernel from issuing requests for the duration of
a userspace request/response.  Imagine userspace issues a request for
a particular part of CDAT then kernel issues it's own request for a different
part of CDAT. Unless we can ensure the userspace request / response pair
is done, then there is no way for the kernel to verify that the response
it gets is to the request it made.  You could do some protocol specific
validation but that is horrible and you might need to read a bunch of
additional records to do it (checksum).

As currently implemented, I'm not allowing concurrent exchanges from
different protocols because it is very fiddly to do (handling the busy flag)
and I'm not convinced there is a real usecase.  Whilst in theory you can
have lots of protocols on one DOE, the protocols defined so far have had
a bunch or restrictions that mean at most you can currently collocate 2
protocols only.  If it turns out to be necessary at some future time, then
we can look at adding it.

I think the right way to do this is to put a proper interface in place
to expose the functionality to userspace via a path where mediation can
be easily handled.

Jonathan


> 
> Lorenzo

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Dan Williams]

On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
[..]
> > If it simplifies the kernel implementation to assume single
> > kernel-initiator then I think that's more than enough reason to block
> > out userspace, and/or provide userspace a method to get into the
> > kernel's queue for service.
>
> This last suggestion makes sense to me. Let's provide a 'right' way
> to access the DOE from user space. I like the idea if it being possible
> to run CXL compliance tests from userspace whilst the driver is loaded.

Ah, and I like your observation that once the kernel provides a
"right" way to access DOE then userspace direct-access of DOE is
indeed a "you get to keep the pieces" event like any other unwanted
userspace config-write.

> Bjorn, given this would be a generic PCI thing, any preference for what
> this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> to those for the BAR based CXL mailboxes?

(warning, anti-ioctl bias incoming...)

Hmm, DOE has an enumeration capability, could the DOE driver use a
scheme to have a sysfs bin_attr per discovered object type? This would
make it simliar to the pci-vpd sysfs interface.

Then the kernel could cache objects like CDAT that don't change
outside of some invalidation event.

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Fri, 14 May 2021 11:37:12 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> [..]
> > > If it simplifies the kernel implementation to assume single
> > > kernel-initiator then I think that's more than enough reason to block
> > > out userspace, and/or provide userspace a method to get into the
> > > kernel's queue for service.  
> >
> > This last suggestion makes sense to me. Let's provide a 'right' way
> > to access the DOE from user space. I like the idea if it being possible
> > to run CXL compliance tests from userspace whilst the driver is loaded.  
> 
> Ah, and I like your observation that once the kernel provides a
> "right" way to access DOE then userspace direct-access of DOE is
> indeed a "you get to keep the pieces" event like any other unwanted
> userspace config-write.
> 
> > Bjorn, given this would be a generic PCI thing, any preference for what
> > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > to those for the BAR based CXL mailboxes?  
> 
> (warning, anti-ioctl bias incoming...)

I feel very similar about ioctls - my immediate thought was to shove this in
debugfs, but that feels the wrong choice if we are trying to persuade people
to use it instead of writing code that directly accesses the config space.

> 
> Hmm, DOE has an enumeration capability, could the DOE driver use a
> scheme to have a sysfs bin_attr per discovered object type? This would
> make it simliar to the pci-vpd sysfs interface.

We can discover the protocols, but anything beyond that is protocol
specific.  I don't think there is a enough info available by any standards
defined method. Also part of the reason to allow a safe userspace interface
would be to provide a generic interface for vendor protocols and things like
CXL compliance tests where we will almost certainly never provide a more
specific kernel interface.

Whilst sysfs would work for CDAT, some protocols are challenge response rather
than simple read back and that really doesn't fit well for sysfs model.
If we get other protocols that are simple data read back, then I would
advocate giving them a simple sysfs interface much like proposed for CDAT
as it will always be simpler to use + self describing.

On a lesser note it might be helpful to provide sysfs attrs for
what protocols are supported.  The alternative is to let userspace run
the discovery protocol. Perhaps we can do this as a later phase.

> 
> Then the kernel could cache objects like CDAT that don't change
> outside of some invalidation event.

It's been a while since I last saw any conversation on sysfs bin_attrs
but mostly I thought the feeling was pretty strongly against them for anything
but a few niche usecases.

Feels to me like it would break most of the usual rules in a way vpd does
not (IIRC VPD is supposed to be a simple in the sense that if you write a value
to a writable part, you will read back the same value).

+CC Greg who is a fount of knowledge in this area (and regularly + correctly
screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
suggesting implementing response / request directly, but I think that is
all we could do given DOE protocols can be vendor specific and the standard
discovery protocol doesn't let us know the fine grained support (what commands
within a given protocol).

Jonathan

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Greg KH]

On Mon, May 17, 2021 at 09:40:45AM +0100, Jonathan Cameron wrote:
> On Fri, 14 May 2021 11:37:12 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
> 
> > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > [..]
> > > > If it simplifies the kernel implementation to assume single
> > > > kernel-initiator then I think that's more than enough reason to block
> > > > out userspace, and/or provide userspace a method to get into the
> > > > kernel's queue for service.  
> > >
> > > This last suggestion makes sense to me. Let's provide a 'right' way
> > > to access the DOE from user space. I like the idea if it being possible
> > > to run CXL compliance tests from userspace whilst the driver is loaded.  
> > 
> > Ah, and I like your observation that once the kernel provides a
> > "right" way to access DOE then userspace direct-access of DOE is
> > indeed a "you get to keep the pieces" event like any other unwanted
> > userspace config-write.
> > 
> > > Bjorn, given this would be a generic PCI thing, any preference for what
> > > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > > to those for the BAR based CXL mailboxes?  
> > 
> > (warning, anti-ioctl bias incoming...)
> 
> I feel very similar about ioctls - my immediate thought was to shove this in
> debugfs, but that feels the wrong choice if we are trying to persuade people
> to use it instead of writing code that directly accesses the config space.
> 
> > 
> > Hmm, DOE has an enumeration capability, could the DOE driver use a
> > scheme to have a sysfs bin_attr per discovered object type? This would
> > make it simliar to the pci-vpd sysfs interface.
> 
> We can discover the protocols, but anything beyond that is protocol
> specific.  I don't think there is a enough info available by any standards
> defined method. Also part of the reason to allow a safe userspace interface
> would be to provide a generic interface for vendor protocols and things like
> CXL compliance tests where we will almost certainly never provide a more
> specific kernel interface.
> 
> Whilst sysfs would work for CDAT, some protocols are challenge response rather
> than simple read back and that really doesn't fit well for sysfs model.
> If we get other protocols that are simple data read back, then I would
> advocate giving them a simple sysfs interface much like proposed for CDAT
> as it will always be simpler to use + self describing.
> 
> On a lesser note it might be helpful to provide sysfs attrs for
> what protocols are supported.  The alternative is to let userspace run
> the discovery protocol. Perhaps we can do this as a later phase.
> 
> > 
> > Then the kernel could cache objects like CDAT that don't change
> > outside of some invalidation event.
> 
> It's been a while since I last saw any conversation on sysfs bin_attrs
> but mostly I thought the feeling was pretty strongly against them for anything
> but a few niche usecases.
> 
> Feels to me like it would break most of the usual rules in a way vpd does
> not (IIRC VPD is supposed to be a simple in the sense that if you write a value
> to a writable part, you will read back the same value).
> 
> +CC Greg who is a fount of knowledge in this area (and regularly + correctly
> screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
> suggesting implementing response / request directly, but I think that is
> all we could do given DOE protocols can be vendor specific and the standard
> discovery protocol doesn't let us know the fine grained support (what commands
> within a given protocol).

sysfs binary files are ONLY for pass-through things that go to/from
userspace/hardware without the kernel touching them at all.  Like raw
PCI config descriptors.

challenge/response type stuff, really does still fit the ioctl model, so
that is a viable solution if needed.

thanks,

greg k-h

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Dan Williams]

On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Fri, 14 May 2021 11:37:12 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
>
> > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > [..]
> > > > If it simplifies the kernel implementation to assume single
> > > > kernel-initiator then I think that's more than enough reason to block
> > > > out userspace, and/or provide userspace a method to get into the
> > > > kernel's queue for service.
> > >
> > > This last suggestion makes sense to me. Let's provide a 'right' way
> > > to access the DOE from user space. I like the idea if it being possible
> > > to run CXL compliance tests from userspace whilst the driver is loaded.
> >
> > Ah, and I like your observation that once the kernel provides a
> > "right" way to access DOE then userspace direct-access of DOE is
> > indeed a "you get to keep the pieces" event like any other unwanted
> > userspace config-write.
> >
> > > Bjorn, given this would be a generic PCI thing, any preference for what
> > > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > > to those for the BAR based CXL mailboxes?
> >
> > (warning, anti-ioctl bias incoming...)
>
> I feel very similar about ioctls - my immediate thought was to shove this in
> debugfs, but that feels the wrong choice if we are trying to persuade people
> to use it instead of writing code that directly accesses the config space.
>
> >
> > Hmm, DOE has an enumeration capability, could the DOE driver use a
> > scheme to have a sysfs bin_attr per discovered object type? This would
> > make it simliar to the pci-vpd sysfs interface.
>
> We can discover the protocols, but anything beyond that is protocol
> specific.  I don't think there is a enough info available by any standards
> defined method. Also part of the reason to allow a safe userspace interface
> would be to provide a generic interface for vendor protocols and things like
> CXL compliance tests where we will almost certainly never provide a more
> specific kernel interface.
>
> Whilst sysfs would work for CDAT, some protocols are challenge response rather
> than simple read back and that really doesn't fit well for sysfs model.
> If we get other protocols that are simple data read back, then I would
> advocate giving them a simple sysfs interface much like proposed for CDAT
> as it will always be simpler to use + self describing.
>
> On a lesser note it might be helpful to provide sysfs attrs for
> what protocols are supported.  The alternative is to let userspace run
> the discovery protocol. Perhaps we can do this as a later phase.
>
> >
> > Then the kernel could cache objects like CDAT that don't change
> > outside of some invalidation event.
>
> It's been a while since I last saw any conversation on sysfs bin_attrs
> but mostly I thought the feeling was pretty strongly against them for anything
> but a few niche usecases.
>
> Feels to me like it would break most of the usual rules in a way vpd does
> not (IIRC VPD is supposed to be a simple in the sense that if you write a value
> to a writable part, you will read back the same value).
>
> +CC Greg who is a fount of knowledge in this area (and regularly + correctly
> screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
> suggesting implementing response / request directly, but I think that is
> all we could do given DOE protocols can be vendor specific and the standard
> discovery protocol doesn't let us know the fine grained support (what commands
> within a given protocol).

I'm not all that interested in supporting vendor defined DOE
shenanigans. There's more than enough published DOE protocols that the
kernel could limit its support to the known set. This is similar to
how ACPI DSMs are not generically supported, but when they appear in a
published specification the kernel may then grow the support. The
supported protocols could be limited to: CDAT, PCIe IDE, CXL
Compliance, etc...

Vendor specific DOE is in the same class as unfettered /dev/mem
access, first you need to disable the kernel's integrity and
confidentiality protections, and then you can do whatever you want. If
a vendor wants a DOE protocol supported in the "trusted" set they can
simply publish the specification and send the proper support patches.

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Mon, 17 May 2021 10:21:14 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Fri, 14 May 2021 11:37:12 -0700
> > Dan Williams <dan.j.williams@intel.com> wrote:
> >  
> > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> > > <Jonathan.Cameron@huawei.com> wrote:
> > > [..]  
> > > > > If it simplifies the kernel implementation to assume single
> > > > > kernel-initiator then I think that's more than enough reason to block
> > > > > out userspace, and/or provide userspace a method to get into the
> > > > > kernel's queue for service.  
> > > >
> > > > This last suggestion makes sense to me. Let's provide a 'right' way
> > > > to access the DOE from user space. I like the idea if it being possible
> > > > to run CXL compliance tests from userspace whilst the driver is loaded.  
> > >
> > > Ah, and I like your observation that once the kernel provides a
> > > "right" way to access DOE then userspace direct-access of DOE is
> > > indeed a "you get to keep the pieces" event like any other unwanted
> > > userspace config-write.
> > >  
> > > > Bjorn, given this would be a generic PCI thing, any preference for what
> > > > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > > > to those for the BAR based CXL mailboxes?  
> > >
> > > (warning, anti-ioctl bias incoming...)  
> >
> > I feel very similar about ioctls - my immediate thought was to shove this in
> > debugfs, but that feels the wrong choice if we are trying to persuade people
> > to use it instead of writing code that directly accesses the config space.
> >  
> > >
> > > Hmm, DOE has an enumeration capability, could the DOE driver use a
> > > scheme to have a sysfs bin_attr per discovered object type? This would
> > > make it simliar to the pci-vpd sysfs interface.  
> >
> > We can discover the protocols, but anything beyond that is protocol
> > specific.  I don't think there is a enough info available by any standards
> > defined method. Also part of the reason to allow a safe userspace interface
> > would be to provide a generic interface for vendor protocols and things like
> > CXL compliance tests where we will almost certainly never provide a more
> > specific kernel interface.
> >
> > Whilst sysfs would work for CDAT, some protocols are challenge response rather
> > than simple read back and that really doesn't fit well for sysfs model.
> > If we get other protocols that are simple data read back, then I would
> > advocate giving them a simple sysfs interface much like proposed for CDAT
> > as it will always be simpler to use + self describing.
> >
> > On a lesser note it might be helpful to provide sysfs attrs for
> > what protocols are supported.  The alternative is to let userspace run
> > the discovery protocol. Perhaps we can do this as a later phase.
> >  
> > >
> > > Then the kernel could cache objects like CDAT that don't change
> > > outside of some invalidation event.  
> >
> > It's been a while since I last saw any conversation on sysfs bin_attrs
> > but mostly I thought the feeling was pretty strongly against them for anything
> > but a few niche usecases.
> >
> > Feels to me like it would break most of the usual rules in a way vpd does
> > not (IIRC VPD is supposed to be a simple in the sense that if you write a value
> > to a writable part, you will read back the same value).
> >
> > +CC Greg who is a fount of knowledge in this area (and regularly + correctly
> > screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
> > suggesting implementing response / request directly, but I think that is
> > all we could do given DOE protocols can be vendor specific and the standard
> > discovery protocol doesn't let us know the fine grained support (what commands
> > within a given protocol).  
> 
> I'm not all that interested in supporting vendor defined DOE
> shenanigans. There's more than enough published DOE protocols that the
> kernel could limit its support to the known set. This is similar to
> how ACPI DSMs are not generically supported, but when they appear in a
> published specification the kernel may then grow the support. The
> supported protocols could be limited to: CDAT, PCIe IDE, CXL
> Compliance, etc...
> 
> Vendor specific DOE is in the same class as unfettered /dev/mem
> access, first you need to disable the kernel's integrity and
> confidentiality protections, and then you can do whatever you want. If
> a vendor wants a DOE protocol supported in the "trusted" set they can
> simply publish the specification and send the proper support patches.

Fair enough, though the interface should be root only, so a vendor shooting
themselves in the foot this way would be no different to using pcitools
to access the device directly (we are just providing safety from concurrency
point of view).

Anyway, I can see two options for how to do this.

1) Per protocol interface. Would not be generic, as these work in entirely
   different ways (some are simple read back of tables, some require complex
   cycles of operations in the right order with data flowing in both directions)
2) White list those protocols we are going to let through a generic interface
   Not including CXL compliance for instance as that has nasty side effects!

If we want to enable userspace DOE access, I prefer option 2.

Note that I wasn't that keen on a userspace interface in the first place as
in my view these should all be handled in kernel.
Ultimately we should have case 1 if userspace access make sense.
However, if we do this we shouldn't pretend we are providing userspace
access to the DOE at all.  We are providing interfaces to things that just
happen to be implemented using DOE under the hood.

I have a prototype of a trivial ioctl based interface. I'll send it out
as an RFC later this week.  Might add a white list, depending on where
this discussion goes.

Jonathan

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Dan Williams]

On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Mon, 17 May 2021 10:21:14 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
>
> > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > >
> > > On Fri, 14 May 2021 11:37:12 -0700
> > > Dan Williams <dan.j.williams@intel.com> wrote:
> > >
> > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > [..]
> > > > > > If it simplifies the kernel implementation to assume single
> > > > > > kernel-initiator then I think that's more than enough reason to block
> > > > > > out userspace, and/or provide userspace a method to get into the
> > > > > > kernel's queue for service.
> > > > >
> > > > > This last suggestion makes sense to me. Let's provide a 'right' way
> > > > > to access the DOE from user space. I like the idea if it being possible
> > > > > to run CXL compliance tests from userspace whilst the driver is loaded.
> > > >
> > > > Ah, and I like your observation that once the kernel provides a
> > > > "right" way to access DOE then userspace direct-access of DOE is
> > > > indeed a "you get to keep the pieces" event like any other unwanted
> > > > userspace config-write.
> > > >
> > > > > Bjorn, given this would be a generic PCI thing, any preference for what
> > > > > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > > > > to those for the BAR based CXL mailboxes?
> > > >
> > > > (warning, anti-ioctl bias incoming...)
> > >
> > > I feel very similar about ioctls - my immediate thought was to shove this in
> > > debugfs, but that feels the wrong choice if we are trying to persuade people
> > > to use it instead of writing code that directly accesses the config space.
> > >
> > > >
> > > > Hmm, DOE has an enumeration capability, could the DOE driver use a
> > > > scheme to have a sysfs bin_attr per discovered object type? This would
> > > > make it simliar to the pci-vpd sysfs interface.
> > >
> > > We can discover the protocols, but anything beyond that is protocol
> > > specific.  I don't think there is a enough info available by any standards
> > > defined method. Also part of the reason to allow a safe userspace interface
> > > would be to provide a generic interface for vendor protocols and things like
> > > CXL compliance tests where we will almost certainly never provide a more
> > > specific kernel interface.
> > >
> > > Whilst sysfs would work for CDAT, some protocols are challenge response rather
> > > than simple read back and that really doesn't fit well for sysfs model.
> > > If we get other protocols that are simple data read back, then I would
> > > advocate giving them a simple sysfs interface much like proposed for CDAT
> > > as it will always be simpler to use + self describing.
> > >
> > > On a lesser note it might be helpful to provide sysfs attrs for
> > > what protocols are supported.  The alternative is to let userspace run
> > > the discovery protocol. Perhaps we can do this as a later phase.
> > >
> > > >
> > > > Then the kernel could cache objects like CDAT that don't change
> > > > outside of some invalidation event.
> > >
> > > It's been a while since I last saw any conversation on sysfs bin_attrs
> > > but mostly I thought the feeling was pretty strongly against them for anything
> > > but a few niche usecases.
> > >
> > > Feels to me like it would break most of the usual rules in a way vpd does
> > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value
> > > to a writable part, you will read back the same value).
> > >
> > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly
> > > screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
> > > suggesting implementing response / request directly, but I think that is
> > > all we could do given DOE protocols can be vendor specific and the standard
> > > discovery protocol doesn't let us know the fine grained support (what commands
> > > within a given protocol).
> >
> > I'm not all that interested in supporting vendor defined DOE
> > shenanigans. There's more than enough published DOE protocols that the
> > kernel could limit its support to the known set. This is similar to
> > how ACPI DSMs are not generically supported, but when they appear in a
> > published specification the kernel may then grow the support. The
> > supported protocols could be limited to: CDAT, PCIe IDE, CXL
> > Compliance, etc...
> >
> > Vendor specific DOE is in the same class as unfettered /dev/mem
> > access, first you need to disable the kernel's integrity and
> > confidentiality protections, and then you can do whatever you want. If
> > a vendor wants a DOE protocol supported in the "trusted" set they can
> > simply publish the specification and send the proper support patches.
>
> Fair enough, though the interface should be root only, so a vendor shooting
> themselves in the foot this way would be no different to using pcitools
> to access the device directly (we are just providing safety from concurrency
> point of view).
>
> Anyway, I can see two options for how to do this.
>
> 1) Per protocol interface. Would not be generic, as these work in entirely
>    different ways (some are simple read back of tables, some require complex
>    cycles of operations in the right order with data flowing in both directions)
> 2) White list those protocols we are going to let through a generic interface
>    Not including CXL compliance for instance as that has nasty side effects!
>
> If we want to enable userspace DOE access, I prefer option 2.
>
> Note that I wasn't that keen on a userspace interface in the first place as
> in my view these should all be handled in kernel.
> Ultimately we should have case 1 if userspace access make sense.
> However, if we do this we shouldn't pretend we are providing userspace
> access to the DOE at all.  We are providing interfaces to things that just
> happen to be implemented using DOE under the hood.
>
> I have a prototype of a trivial ioctl based interface. I'll send it out
> as an RFC later this week.  Might add a white list, depending on where
> this discussion goes.
>

I'd say let's do this in typical Linux fashion and not solve future
problems before they need to be solved. I.e. start small and build
incrementally. To me that looks like a sysfs interface to convey a
cached copy of a CDAT with an internal interface for a driver to
trigger invalidations and re-reads on the next access. This would
assume that userspace may have left the DOE in an indeterminate state
and an abort cycle may be needed. A 1 second delay for the rare case
where a collision is detected seems reasonable for just CDAT
retrieval.

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Wed, 19 May 2021 07:18:28 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Mon, 17 May 2021 10:21:14 -0700
> > Dan Williams <dan.j.williams@intel.com> wrote:
> >  
> > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron
> > > <Jonathan.Cameron@huawei.com> wrote:  
> > > >
> > > > On Fri, 14 May 2021 11:37:12 -0700
> > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > >  
> > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > [..]  
> > > > > > > If it simplifies the kernel implementation to assume single
> > > > > > > kernel-initiator then I think that's more than enough reason to block
> > > > > > > out userspace, and/or provide userspace a method to get into the
> > > > > > > kernel's queue for service.  
> > > > > >
> > > > > > This last suggestion makes sense to me. Let's provide a 'right' way
> > > > > > to access the DOE from user space. I like the idea if it being possible
> > > > > > to run CXL compliance tests from userspace whilst the driver is loaded.  
> > > > >
> > > > > Ah, and I like your observation that once the kernel provides a
> > > > > "right" way to access DOE then userspace direct-access of DOE is
> > > > > indeed a "you get to keep the pieces" event like any other unwanted
> > > > > userspace config-write.
> > > > >  
> > > > > > Bjorn, given this would be a generic PCI thing, any preference for what
> > > > > > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > > > > > to those for the BAR based CXL mailboxes?  
> > > > >
> > > > > (warning, anti-ioctl bias incoming...)  
> > > >
> > > > I feel very similar about ioctls - my immediate thought was to shove this in
> > > > debugfs, but that feels the wrong choice if we are trying to persuade people
> > > > to use it instead of writing code that directly accesses the config space.
> > > >  
> > > > >
> > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a
> > > > > scheme to have a sysfs bin_attr per discovered object type? This would
> > > > > make it simliar to the pci-vpd sysfs interface.  
> > > >
> > > > We can discover the protocols, but anything beyond that is protocol
> > > > specific.  I don't think there is a enough info available by any standards
> > > > defined method. Also part of the reason to allow a safe userspace interface
> > > > would be to provide a generic interface for vendor protocols and things like
> > > > CXL compliance tests where we will almost certainly never provide a more
> > > > specific kernel interface.
> > > >
> > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather
> > > > than simple read back and that really doesn't fit well for sysfs model.
> > > > If we get other protocols that are simple data read back, then I would
> > > > advocate giving them a simple sysfs interface much like proposed for CDAT
> > > > as it will always be simpler to use + self describing.
> > > >
> > > > On a lesser note it might be helpful to provide sysfs attrs for
> > > > what protocols are supported.  The alternative is to let userspace run
> > > > the discovery protocol. Perhaps we can do this as a later phase.
> > > >  
> > > > >
> > > > > Then the kernel could cache objects like CDAT that don't change
> > > > > outside of some invalidation event.  
> > > >
> > > > It's been a while since I last saw any conversation on sysfs bin_attrs
> > > > but mostly I thought the feeling was pretty strongly against them for anything
> > > > but a few niche usecases.
> > > >
> > > > Feels to me like it would break most of the usual rules in a way vpd does
> > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value
> > > > to a writable part, you will read back the same value).
> > > >
> > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly
> > > > screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
> > > > suggesting implementing response / request directly, but I think that is
> > > > all we could do given DOE protocols can be vendor specific and the standard
> > > > discovery protocol doesn't let us know the fine grained support (what commands
> > > > within a given protocol).  
> > >
> > > I'm not all that interested in supporting vendor defined DOE
> > > shenanigans. There's more than enough published DOE protocols that the
> > > kernel could limit its support to the known set. This is similar to
> > > how ACPI DSMs are not generically supported, but when they appear in a
> > > published specification the kernel may then grow the support. The
> > > supported protocols could be limited to: CDAT, PCIe IDE, CXL
> > > Compliance, etc...
> > >
> > > Vendor specific DOE is in the same class as unfettered /dev/mem
> > > access, first you need to disable the kernel's integrity and
> > > confidentiality protections, and then you can do whatever you want. If
> > > a vendor wants a DOE protocol supported in the "trusted" set they can
> > > simply publish the specification and send the proper support patches.  
> >
> > Fair enough, though the interface should be root only, so a vendor shooting
> > themselves in the foot this way would be no different to using pcitools
> > to access the device directly (we are just providing safety from concurrency
> > point of view).
> >
> > Anyway, I can see two options for how to do this.
> >
> > 1) Per protocol interface. Would not be generic, as these work in entirely
> >    different ways (some are simple read back of tables, some require complex
> >    cycles of operations in the right order with data flowing in both directions)
> > 2) White list those protocols we are going to let through a generic interface
> >    Not including CXL compliance for instance as that has nasty side effects!
> >
> > If we want to enable userspace DOE access, I prefer option 2.
> >
> > Note that I wasn't that keen on a userspace interface in the first place as
> > in my view these should all be handled in kernel.
> > Ultimately we should have case 1 if userspace access make sense.
> > However, if we do this we shouldn't pretend we are providing userspace
> > access to the DOE at all.  We are providing interfaces to things that just
> > happen to be implemented using DOE under the hood.
> >
> > I have a prototype of a trivial ioctl based interface. I'll send it out
> > as an RFC later this week.  Might add a white list, depending on where
> > this discussion goes.
> >  
> 
> I'd say let's do this in typical Linux fashion and not solve future
> problems before they need to be solved. I.e. start small and build
> incrementally. To me that looks like a sysfs interface to convey a
> cached copy of a CDAT with an internal interface for a driver to
> trigger invalidations and re-reads on the next access. This would
> assume that userspace may have left the DOE in an indeterminate state
> and an abort cycle may be needed. A 1 second delay for the rare case
> where a collision is detected seems reasonable for just CDAT
> retrieval.

The problem is you can not detect a collision. Hence it's a reset every
time you use the DOE from in the kernel. Personally I think that this
is fixing a problem that doesn't exist. Userspace should not access
the DOE when a driver is loaded in exactly the same way it shouldn't
be writing to anywhere else in config space under normal circumstances.
I really don't see this as special. If we think it is special then
we should provide a safe interface.

Given it's nearly done, I might send out the ioctl proposal and
we can can just decide to leave it unmerged for now, pending real
usecases being established.

Jonathan

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Dan Williams]

On Wed, May 19, 2021 at 8:14 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Wed, 19 May 2021 07:18:28 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
>
> > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > >
> > > On Mon, 17 May 2021 10:21:14 -0700
> > > Dan Williams <dan.j.williams@intel.com> wrote:
> > >
> > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron
> > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > >
> > > > > On Fri, 14 May 2021 11:37:12 -0700
> > > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > > >
> > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > > [..]
> > > > > > > > If it simplifies the kernel implementation to assume single
> > > > > > > > kernel-initiator then I think that's more than enough reason to block
> > > > > > > > out userspace, and/or provide userspace a method to get into the
> > > > > > > > kernel's queue for service.
> > > > > > >
> > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way
> > > > > > > to access the DOE from user space. I like the idea if it being possible
> > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded.
> > > > > >
> > > > > > Ah, and I like your observation that once the kernel provides a
> > > > > > "right" way to access DOE then userspace direct-access of DOE is
> > > > > > indeed a "you get to keep the pieces" event like any other unwanted
> > > > > > userspace config-write.
> > > > > >
> > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what
> > > > > > > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > > > > > > to those for the BAR based CXL mailboxes?
> > > > > >
> > > > > > (warning, anti-ioctl bias incoming...)
> > > > >
> > > > > I feel very similar about ioctls - my immediate thought was to shove this in
> > > > > debugfs, but that feels the wrong choice if we are trying to persuade people
> > > > > to use it instead of writing code that directly accesses the config space.
> > > > >
> > > > > >
> > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a
> > > > > > scheme to have a sysfs bin_attr per discovered object type? This would
> > > > > > make it simliar to the pci-vpd sysfs interface.
> > > > >
> > > > > We can discover the protocols, but anything beyond that is protocol
> > > > > specific.  I don't think there is a enough info available by any standards
> > > > > defined method. Also part of the reason to allow a safe userspace interface
> > > > > would be to provide a generic interface for vendor protocols and things like
> > > > > CXL compliance tests where we will almost certainly never provide a more
> > > > > specific kernel interface.
> > > > >
> > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather
> > > > > than simple read back and that really doesn't fit well for sysfs model.
> > > > > If we get other protocols that are simple data read back, then I would
> > > > > advocate giving them a simple sysfs interface much like proposed for CDAT
> > > > > as it will always be simpler to use + self describing.
> > > > >
> > > > > On a lesser note it might be helpful to provide sysfs attrs for
> > > > > what protocols are supported.  The alternative is to let userspace run
> > > > > the discovery protocol. Perhaps we can do this as a later phase.
> > > > >
> > > > > >
> > > > > > Then the kernel could cache objects like CDAT that don't change
> > > > > > outside of some invalidation event.
> > > > >
> > > > > It's been a while since I last saw any conversation on sysfs bin_attrs
> > > > > but mostly I thought the feeling was pretty strongly against them for anything
> > > > > but a few niche usecases.
> > > > >
> > > > > Feels to me like it would break most of the usual rules in a way vpd does
> > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value
> > > > > to a writable part, you will read back the same value).
> > > > >
> > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly
> > > > > screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
> > > > > suggesting implementing response / request directly, but I think that is
> > > > > all we could do given DOE protocols can be vendor specific and the standard
> > > > > discovery protocol doesn't let us know the fine grained support (what commands
> > > > > within a given protocol).
> > > >
> > > > I'm not all that interested in supporting vendor defined DOE
> > > > shenanigans. There's more than enough published DOE protocols that the
> > > > kernel could limit its support to the known set. This is similar to
> > > > how ACPI DSMs are not generically supported, but when they appear in a
> > > > published specification the kernel may then grow the support. The
> > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL
> > > > Compliance, etc...
> > > >
> > > > Vendor specific DOE is in the same class as unfettered /dev/mem
> > > > access, first you need to disable the kernel's integrity and
> > > > confidentiality protections, and then you can do whatever you want. If
> > > > a vendor wants a DOE protocol supported in the "trusted" set they can
> > > > simply publish the specification and send the proper support patches.
> > >
> > > Fair enough, though the interface should be root only, so a vendor shooting
> > > themselves in the foot this way would be no different to using pcitools
> > > to access the device directly (we are just providing safety from concurrency
> > > point of view).
> > >
> > > Anyway, I can see two options for how to do this.
> > >
> > > 1) Per protocol interface. Would not be generic, as these work in entirely
> > >    different ways (some are simple read back of tables, some require complex
> > >    cycles of operations in the right order with data flowing in both directions)
> > > 2) White list those protocols we are going to let through a generic interface
> > >    Not including CXL compliance for instance as that has nasty side effects!
> > >
> > > If we want to enable userspace DOE access, I prefer option 2.
> > >
> > > Note that I wasn't that keen on a userspace interface in the first place as
> > > in my view these should all be handled in kernel.
> > > Ultimately we should have case 1 if userspace access make sense.
> > > However, if we do this we shouldn't pretend we are providing userspace
> > > access to the DOE at all.  We are providing interfaces to things that just
> > > happen to be implemented using DOE under the hood.
> > >
> > > I have a prototype of a trivial ioctl based interface. I'll send it out
> > > as an RFC later this week.  Might add a white list, depending on where
> > > this discussion goes.
> > >
> >
> > I'd say let's do this in typical Linux fashion and not solve future
> > problems before they need to be solved. I.e. start small and build
> > incrementally. To me that looks like a sysfs interface to convey a
> > cached copy of a CDAT with an internal interface for a driver to
> > trigger invalidations and re-reads on the next access. This would
> > assume that userspace may have left the DOE in an indeterminate state
> > and an abort cycle may be needed. A 1 second delay for the rare case
> > where a collision is detected seems reasonable for just CDAT
> > retrieval.
>
> The problem is you can not detect a collision.

This discussion started because Ira questioned the handling of the
busy status. If the DOE is busy and the kernel did not make it busy
then there was a collision, no?

> Hence it's a reset every
> time you use the DOE from in the kernel.

I would expect:

pci_cfg_access_lock()
if (busy)
    reset();
do_doe_operation();
pci_cfg_access_unlock();

> Personally I think that this
> is fixing a problem that doesn't exist.

Again this is all stemming from the driver handling "busy" especially
with the knowledged that it did not busy it itself.

> Userspace should not access
> the DOE when a driver is loaded in exactly the same way it shouldn't
> be writing to anywhere else in config space under normal circumstances.

DOE has data that is similar to what can be retrieved via config read,
it just so happens that reading that data triggers writes. DOE is in a
different class than other configuration writes in terms of the
userspace motivation to access it.

> I really don't see this as special. If we think it is special then
> we should provide a safe interface.


>
> Given it's nearly done, I might send out the ioctl proposal and
> we can can just decide to leave it unmerged for now, pending real
> usecases being established.

Fair enough.

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Wed, 19 May 2021 08:29:58 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> On Wed, May 19, 2021 at 8:14 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Wed, 19 May 2021 07:18:28 -0700
> > Dan Williams <dan.j.williams@intel.com> wrote:
> >  
> > > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron
> > > <Jonathan.Cameron@huawei.com> wrote:  
> > > >
> > > > On Mon, 17 May 2021 10:21:14 -0700
> > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > >  
> > > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron
> > > > > <Jonathan.Cameron@huawei.com> wrote:  
> > > > > >
> > > > > > On Fri, 14 May 2021 11:37:12 -0700
> > > > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > > > >  
> > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> > > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > > > [..]  
> > > > > > > > > If it simplifies the kernel implementation to assume single
> > > > > > > > > kernel-initiator then I think that's more than enough reason to block
> > > > > > > > > out userspace, and/or provide userspace a method to get into the
> > > > > > > > > kernel's queue for service.  
> > > > > > > >
> > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way
> > > > > > > > to access the DOE from user space. I like the idea if it being possible
> > > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded.  
> > > > > > >
> > > > > > > Ah, and I like your observation that once the kernel provides a
> > > > > > > "right" way to access DOE then userspace direct-access of DOE is
> > > > > > > indeed a "you get to keep the pieces" event like any other unwanted
> > > > > > > userspace config-write.
> > > > > > >  
> > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what
> > > > > > > > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > > > > > > > to those for the BAR based CXL mailboxes?  
> > > > > > >
> > > > > > > (warning, anti-ioctl bias incoming...)  
> > > > > >
> > > > > > I feel very similar about ioctls - my immediate thought was to shove this in
> > > > > > debugfs, but that feels the wrong choice if we are trying to persuade people
> > > > > > to use it instead of writing code that directly accesses the config space.
> > > > > >  
> > > > > > >
> > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a
> > > > > > > scheme to have a sysfs bin_attr per discovered object type? This would
> > > > > > > make it simliar to the pci-vpd sysfs interface.  
> > > > > >
> > > > > > We can discover the protocols, but anything beyond that is protocol
> > > > > > specific.  I don't think there is a enough info available by any standards
> > > > > > defined method. Also part of the reason to allow a safe userspace interface
> > > > > > would be to provide a generic interface for vendor protocols and things like
> > > > > > CXL compliance tests where we will almost certainly never provide a more
> > > > > > specific kernel interface.
> > > > > >
> > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather
> > > > > > than simple read back and that really doesn't fit well for sysfs model.
> > > > > > If we get other protocols that are simple data read back, then I would
> > > > > > advocate giving them a simple sysfs interface much like proposed for CDAT
> > > > > > as it will always be simpler to use + self describing.
> > > > > >
> > > > > > On a lesser note it might be helpful to provide sysfs attrs for
> > > > > > what protocols are supported.  The alternative is to let userspace run
> > > > > > the discovery protocol. Perhaps we can do this as a later phase.
> > > > > >  
> > > > > > >
> > > > > > > Then the kernel could cache objects like CDAT that don't change
> > > > > > > outside of some invalidation event.  
> > > > > >
> > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs
> > > > > > but mostly I thought the feeling was pretty strongly against them for anything
> > > > > > but a few niche usecases.
> > > > > >
> > > > > > Feels to me like it would break most of the usual rules in a way vpd does
> > > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value
> > > > > > to a writable part, you will read back the same value).
> > > > > >
> > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly
> > > > > > screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
> > > > > > suggesting implementing response / request directly, but I think that is
> > > > > > all we could do given DOE protocols can be vendor specific and the standard
> > > > > > discovery protocol doesn't let us know the fine grained support (what commands
> > > > > > within a given protocol).  
> > > > >
> > > > > I'm not all that interested in supporting vendor defined DOE
> > > > > shenanigans. There's more than enough published DOE protocols that the
> > > > > kernel could limit its support to the known set. This is similar to
> > > > > how ACPI DSMs are not generically supported, but when they appear in a
> > > > > published specification the kernel may then grow the support. The
> > > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL
> > > > > Compliance, etc...
> > > > >
> > > > > Vendor specific DOE is in the same class as unfettered /dev/mem
> > > > > access, first you need to disable the kernel's integrity and
> > > > > confidentiality protections, and then you can do whatever you want. If
> > > > > a vendor wants a DOE protocol supported in the "trusted" set they can
> > > > > simply publish the specification and send the proper support patches.  
> > > >
> > > > Fair enough, though the interface should be root only, so a vendor shooting
> > > > themselves in the foot this way would be no different to using pcitools
> > > > to access the device directly (we are just providing safety from concurrency
> > > > point of view).
> > > >
> > > > Anyway, I can see two options for how to do this.
> > > >
> > > > 1) Per protocol interface. Would not be generic, as these work in entirely
> > > >    different ways (some are simple read back of tables, some require complex
> > > >    cycles of operations in the right order with data flowing in both directions)
> > > > 2) White list those protocols we are going to let through a generic interface
> > > >    Not including CXL compliance for instance as that has nasty side effects!
> > > >
> > > > If we want to enable userspace DOE access, I prefer option 2.
> > > >
> > > > Note that I wasn't that keen on a userspace interface in the first place as
> > > > in my view these should all be handled in kernel.
> > > > Ultimately we should have case 1 if userspace access make sense.
> > > > However, if we do this we shouldn't pretend we are providing userspace
> > > > access to the DOE at all.  We are providing interfaces to things that just
> > > > happen to be implemented using DOE under the hood.
> > > >
> > > > I have a prototype of a trivial ioctl based interface. I'll send it out
> > > > as an RFC later this week.  Might add a white list, depending on where
> > > > this discussion goes.
> > > >  
> > >
> > > I'd say let's do this in typical Linux fashion and not solve future
> > > problems before they need to be solved. I.e. start small and build
> > > incrementally. To me that looks like a sysfs interface to convey a
> > > cached copy of a CDAT with an internal interface for a driver to
> > > trigger invalidations and re-reads on the next access. This would
> > > assume that userspace may have left the DOE in an indeterminate state
> > > and an abort cycle may be needed. A 1 second delay for the rare case
> > > where a collision is detected seems reasonable for just CDAT
> > > retrieval.  
> >
> > The problem is you can not detect a collision.  
> 
> This discussion started because Ira questioned the handling of the
> busy status. If the DOE is busy and the kernel did not make it busy
> then there was a collision, no?

True, but not complete. Not having busy set does not mean there
wasn't a collision. Busy is an indication that the EP can't recieve
a new request (no space in buffer or similar), not that there is a response
still to be sent back.  We have no way to tell if there is a response
going to come back in the future. There is no 'exchange in flight' flag.

> 
> > Hence it's a reset every
> > time you use the DOE from in the kernel.  
> 
> I would expect:
> 
> pci_cfg_access_lock()
> if (busy)
>     reset();

No, it would need to be unconditional, or you might get a response
to a previously issued request mid way through your operation, and you
can't in general tell that it wasn't the response to your request.
For example you might get the wrong part of CDAT. You'd need to read
the whole of CDAT to then verify the checksum to detect this had happened.

> do_doe_operation();
> pci_cfg_access_unlock();
> 
> > Personally I think that this
> > is fixing a problem that doesn't exist.  
> 
> Again this is all stemming from the driver handling "busy" especially
> with the knowledged that it did not busy it itself.

As above, busy doesn't do what it's name might suggest. It doesn't
mean there is a request / response pair in flight.

> 
> > Userspace should not access
> > the DOE when a driver is loaded in exactly the same way it shouldn't
> > be writing to anywhere else in config space under normal circumstances.  
> 
> DOE has data that is similar to what can be retrieved via config read,
> it just so happens that reading that data triggers writes. DOE is in a
> different class than other configuration writes in terms of the
> userspace motivation to access it.

For CDAT yes, for other protocols, (e.g. IDE, CXL compliance) definitely not.
Using the protocols is as destructive as a write to config space.

> 
> > I really don't see this as special. If we think it is special then
> > we should provide a safe interface.  
> 
> 
> >
> > Given it's nearly done, I might send out the ioctl proposal and
> > we can can just decide to leave it unmerged for now, pending real
> > usecases being established.  
> 
> Fair enough.

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Wed, 19 May 2021 17:20:52 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Wed, 19 May 2021 08:29:58 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
> 
> > On Wed, May 19, 2021 at 8:14 AM Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:  
> > >
> > > On Wed, 19 May 2021 07:18:28 -0700
> > > Dan Williams <dan.j.williams@intel.com> wrote:
> > >    
> > > > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron
> > > > <Jonathan.Cameron@huawei.com> wrote:    
> > > > >
> > > > > On Mon, 17 May 2021 10:21:14 -0700
> > > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > > >    
> > > > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron
> > > > > > <Jonathan.Cameron@huawei.com> wrote:    
> > > > > > >
> > > > > > > On Fri, 14 May 2021 11:37:12 -0700
> > > > > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > > > > >    
> > > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> > > > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > > > > [..]    
> > > > > > > > > > If it simplifies the kernel implementation to assume single
> > > > > > > > > > kernel-initiator then I think that's more than enough reason to block
> > > > > > > > > > out userspace, and/or provide userspace a method to get into the
> > > > > > > > > > kernel's queue for service.    
> > > > > > > > >
> > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way
> > > > > > > > > to access the DOE from user space. I like the idea if it being possible
> > > > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded.    
> > > > > > > >
> > > > > > > > Ah, and I like your observation that once the kernel provides a
> > > > > > > > "right" way to access DOE then userspace direct-access of DOE is
> > > > > > > > indeed a "you get to keep the pieces" event like any other unwanted
> > > > > > > > userspace config-write.
> > > > > > > >    
> > > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what
> > > > > > > > > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > > > > > > > > to those for the BAR based CXL mailboxes?    
> > > > > > > >
> > > > > > > > (warning, anti-ioctl bias incoming...)    
> > > > > > >
> > > > > > > I feel very similar about ioctls - my immediate thought was to shove this in
> > > > > > > debugfs, but that feels the wrong choice if we are trying to persuade people
> > > > > > > to use it instead of writing code that directly accesses the config space.
> > > > > > >    
> > > > > > > >
> > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a
> > > > > > > > scheme to have a sysfs bin_attr per discovered object type? This would
> > > > > > > > make it simliar to the pci-vpd sysfs interface.    
> > > > > > >
> > > > > > > We can discover the protocols, but anything beyond that is protocol
> > > > > > > specific.  I don't think there is a enough info available by any standards
> > > > > > > defined method. Also part of the reason to allow a safe userspace interface
> > > > > > > would be to provide a generic interface for vendor protocols and things like
> > > > > > > CXL compliance tests where we will almost certainly never provide a more
> > > > > > > specific kernel interface.
> > > > > > >
> > > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather
> > > > > > > than simple read back and that really doesn't fit well for sysfs model.
> > > > > > > If we get other protocols that are simple data read back, then I would
> > > > > > > advocate giving them a simple sysfs interface much like proposed for CDAT
> > > > > > > as it will always be simpler to use + self describing.
> > > > > > >
> > > > > > > On a lesser note it might be helpful to provide sysfs attrs for
> > > > > > > what protocols are supported.  The alternative is to let userspace run
> > > > > > > the discovery protocol. Perhaps we can do this as a later phase.
> > > > > > >    
> > > > > > > >
> > > > > > > > Then the kernel could cache objects like CDAT that don't change
> > > > > > > > outside of some invalidation event.    
> > > > > > >
> > > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs
> > > > > > > but mostly I thought the feeling was pretty strongly against them for anything
> > > > > > > but a few niche usecases.
> > > > > > >
> > > > > > > Feels to me like it would break most of the usual rules in a way vpd does
> > > > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value
> > > > > > > to a writable part, you will read back the same value).
> > > > > > >
> > > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly
> > > > > > > screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
> > > > > > > suggesting implementing response / request directly, but I think that is
> > > > > > > all we could do given DOE protocols can be vendor specific and the standard
> > > > > > > discovery protocol doesn't let us know the fine grained support (what commands
> > > > > > > within a given protocol).    
> > > > > >
> > > > > > I'm not all that interested in supporting vendor defined DOE
> > > > > > shenanigans. There's more than enough published DOE protocols that the
> > > > > > kernel could limit its support to the known set. This is similar to
> > > > > > how ACPI DSMs are not generically supported, but when they appear in a
> > > > > > published specification the kernel may then grow the support. The
> > > > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL
> > > > > > Compliance, etc...
> > > > > >
> > > > > > Vendor specific DOE is in the same class as unfettered /dev/mem
> > > > > > access, first you need to disable the kernel's integrity and
> > > > > > confidentiality protections, and then you can do whatever you want. If
> > > > > > a vendor wants a DOE protocol supported in the "trusted" set they can
> > > > > > simply publish the specification and send the proper support patches.    
> > > > >
> > > > > Fair enough, though the interface should be root only, so a vendor shooting
> > > > > themselves in the foot this way would be no different to using pcitools
> > > > > to access the device directly (we are just providing safety from concurrency
> > > > > point of view).
> > > > >
> > > > > Anyway, I can see two options for how to do this.
> > > > >
> > > > > 1) Per protocol interface. Would not be generic, as these work in entirely
> > > > >    different ways (some are simple read back of tables, some require complex
> > > > >    cycles of operations in the right order with data flowing in both directions)
> > > > > 2) White list those protocols we are going to let through a generic interface
> > > > >    Not including CXL compliance for instance as that has nasty side effects!
> > > > >
> > > > > If we want to enable userspace DOE access, I prefer option 2.
> > > > >
> > > > > Note that I wasn't that keen on a userspace interface in the first place as
> > > > > in my view these should all be handled in kernel.
> > > > > Ultimately we should have case 1 if userspace access make sense.
> > > > > However, if we do this we shouldn't pretend we are providing userspace
> > > > > access to the DOE at all.  We are providing interfaces to things that just
> > > > > happen to be implemented using DOE under the hood.
> > > > >
> > > > > I have a prototype of a trivial ioctl based interface. I'll send it out
> > > > > as an RFC later this week.  Might add a white list, depending on where
> > > > > this discussion goes.
> > > > >    
> > > >
> > > > I'd say let's do this in typical Linux fashion and not solve future
> > > > problems before they need to be solved. I.e. start small and build
> > > > incrementally. To me that looks like a sysfs interface to convey a
> > > > cached copy of a CDAT with an internal interface for a driver to
> > > > trigger invalidations and re-reads on the next access. This would
> > > > assume that userspace may have left the DOE in an indeterminate state
> > > > and an abort cycle may be needed. A 1 second delay for the rare case
> > > > where a collision is detected seems reasonable for just CDAT
> > > > retrieval.    
> > >
> > > The problem is you can not detect a collision.    
> > 
> > This discussion started because Ira questioned the handling of the
> > busy status. If the DOE is busy and the kernel did not make it busy
> > then there was a collision, no?  
> 
> True, but not complete. Not having busy set does not mean there
> wasn't a collision. Busy is an indication that the EP can't recieve
> a new request (no space in buffer or similar), not that there is a response
> still to be sent back.  We have no way to tell if there is a response
> going to come back in the future. There is no 'exchange in flight' flag.

Perhaps useful to add a quote from the DOE ECN here.
This is in an implementation note on Page 6.

"The DOE Busy bit can be used to indicate that the DOE responder is
 temporarily unable to accept a data object. It is necessary for a
 DOE requester to ensure that individual data object transfers are
 completed, and that a request/response contract is completed, for
 example using a mutex mechanism to block other conflicting traffic
 for cases where such conflicts are possible."

Given you must not issue a second request to a given protocol until
the response is received (unless you issue an abort) you can't safely
do anything if we assume userspace might be using the DOE directly
other than by issuing an abort every time.

I had previously missed that a DOE busy clear can cause an interrupt
but that would only avoid us polling for busy (probably not worth
the handling code). It doesn't help us with this problem.

> 
> >   
> > > Hence it's a reset every
> > > time you use the DOE from in the kernel.    
> > 
> > I would expect:
> > 
> > pci_cfg_access_lock()
> > if (busy)
> >     reset();  
> 
> No, it would need to be unconditional, or you might get a response
> to a previously issued request mid way through your operation, and you
> can't in general tell that it wasn't the response to your request.
> For example you might get the wrong part of CDAT. You'd need to read
> the whole of CDAT to then verify the checksum to detect this had happened.
> 
> > do_doe_operation();
> > pci_cfg_access_unlock();
> >   
> > > Personally I think that this
> > > is fixing a problem that doesn't exist.    
> > 
> > Again this is all stemming from the driver handling "busy" especially
> > with the knowledged that it did not busy it itself.  
> 
> As above, busy doesn't do what it's name might suggest. It doesn't
> mean there is a request / response pair in flight.
> 
> >   
> > > Userspace should not access
> > > the DOE when a driver is loaded in exactly the same way it shouldn't
> > > be writing to anywhere else in config space under normal circumstances.    
> > 
> > DOE has data that is similar to what can be retrieved via config read,
> > it just so happens that reading that data triggers writes. DOE is in a
> > different class than other configuration writes in terms of the
> > userspace motivation to access it.  
> 
> For CDAT yes, for other protocols, (e.g. IDE, CXL compliance) definitely not.
> Using the protocols is as destructive as a write to config space.
> 
> >   
> > > I really don't see this as special. If we think it is special then
> > > we should provide a safe interface.    
> > 
> >   
> > >
> > > Given it's nearly done, I might send out the ioctl proposal and
> > > we can can just decide to leave it unmerged for now, pending real
> > > usecases being established.    
> > 
> > Fair enough.  
> 

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Dan Williams]

On Wed, May 19, 2021 at 9:35 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Wed, 19 May 2021 17:20:52 +0100
> Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
>
> > On Wed, 19 May 2021 08:29:58 -0700
> > Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > > On Wed, May 19, 2021 at 8:14 AM Jonathan Cameron
> > > <Jonathan.Cameron@huawei.com> wrote:
> > > >
> > > > On Wed, 19 May 2021 07:18:28 -0700
> > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > >
> > > > > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron
> > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > >
> > > > > > On Mon, 17 May 2021 10:21:14 -0700
> > > > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > > > >
> > > > > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron
> > > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, 14 May 2021 11:37:12 -0700
> > > > > > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > > > > > >
> > > > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> > > > > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > > > > > [..]
> > > > > > > > > > > If it simplifies the kernel implementation to assume single
> > > > > > > > > > > kernel-initiator then I think that's more than enough reason to block
> > > > > > > > > > > out userspace, and/or provide userspace a method to get into the
> > > > > > > > > > > kernel's queue for service.
> > > > > > > > > >
> > > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way
> > > > > > > > > > to access the DOE from user space. I like the idea if it being possible
> > > > > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded.
> > > > > > > > >
> > > > > > > > > Ah, and I like your observation that once the kernel provides a
> > > > > > > > > "right" way to access DOE then userspace direct-access of DOE is
> > > > > > > > > indeed a "you get to keep the pieces" event like any other unwanted
> > > > > > > > > userspace config-write.
> > > > > > > > >
> > > > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what
> > > > > > > > > > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > > > > > > > > > to those for the BAR based CXL mailboxes?
> > > > > > > > >
> > > > > > > > > (warning, anti-ioctl bias incoming...)
> > > > > > > >
> > > > > > > > I feel very similar about ioctls - my immediate thought was to shove this in
> > > > > > > > debugfs, but that feels the wrong choice if we are trying to persuade people
> > > > > > > > to use it instead of writing code that directly accesses the config space.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a
> > > > > > > > > scheme to have a sysfs bin_attr per discovered object type? This would
> > > > > > > > > make it simliar to the pci-vpd sysfs interface.
> > > > > > > >
> > > > > > > > We can discover the protocols, but anything beyond that is protocol
> > > > > > > > specific.  I don't think there is a enough info available by any standards
> > > > > > > > defined method. Also part of the reason to allow a safe userspace interface
> > > > > > > > would be to provide a generic interface for vendor protocols and things like
> > > > > > > > CXL compliance tests where we will almost certainly never provide a more
> > > > > > > > specific kernel interface.
> > > > > > > >
> > > > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather
> > > > > > > > than simple read back and that really doesn't fit well for sysfs model.
> > > > > > > > If we get other protocols that are simple data read back, then I would
> > > > > > > > advocate giving them a simple sysfs interface much like proposed for CDAT
> > > > > > > > as it will always be simpler to use + self describing.
> > > > > > > >
> > > > > > > > On a lesser note it might be helpful to provide sysfs attrs for
> > > > > > > > what protocols are supported.  The alternative is to let userspace run
> > > > > > > > the discovery protocol. Perhaps we can do this as a later phase.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Then the kernel could cache objects like CDAT that don't change
> > > > > > > > > outside of some invalidation event.
> > > > > > > >
> > > > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs
> > > > > > > > but mostly I thought the feeling was pretty strongly against them for anything
> > > > > > > > but a few niche usecases.
> > > > > > > >
> > > > > > > > Feels to me like it would break most of the usual rules in a way vpd does
> > > > > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value
> > > > > > > > to a writable part, you will read back the same value).
> > > > > > > >
> > > > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly
> > > > > > > > screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
> > > > > > > > suggesting implementing response / request directly, but I think that is
> > > > > > > > all we could do given DOE protocols can be vendor specific and the standard
> > > > > > > > discovery protocol doesn't let us know the fine grained support (what commands
> > > > > > > > within a given protocol).
> > > > > > >
> > > > > > > I'm not all that interested in supporting vendor defined DOE
> > > > > > > shenanigans. There's more than enough published DOE protocols that the
> > > > > > > kernel could limit its support to the known set. This is similar to
> > > > > > > how ACPI DSMs are not generically supported, but when they appear in a
> > > > > > > published specification the kernel may then grow the support. The
> > > > > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL
> > > > > > > Compliance, etc...
> > > > > > >
> > > > > > > Vendor specific DOE is in the same class as unfettered /dev/mem
> > > > > > > access, first you need to disable the kernel's integrity and
> > > > > > > confidentiality protections, and then you can do whatever you want. If
> > > > > > > a vendor wants a DOE protocol supported in the "trusted" set they can
> > > > > > > simply publish the specification and send the proper support patches.
> > > > > >
> > > > > > Fair enough, though the interface should be root only, so a vendor shooting
> > > > > > themselves in the foot this way would be no different to using pcitools
> > > > > > to access the device directly (we are just providing safety from concurrency
> > > > > > point of view).
> > > > > >
> > > > > > Anyway, I can see two options for how to do this.
> > > > > >
> > > > > > 1) Per protocol interface. Would not be generic, as these work in entirely
> > > > > >    different ways (some are simple read back of tables, some require complex
> > > > > >    cycles of operations in the right order with data flowing in both directions)
> > > > > > 2) White list those protocols we are going to let through a generic interface
> > > > > >    Not including CXL compliance for instance as that has nasty side effects!
> > > > > >
> > > > > > If we want to enable userspace DOE access, I prefer option 2.
> > > > > >
> > > > > > Note that I wasn't that keen on a userspace interface in the first place as
> > > > > > in my view these should all be handled in kernel.
> > > > > > Ultimately we should have case 1 if userspace access make sense.
> > > > > > However, if we do this we shouldn't pretend we are providing userspace
> > > > > > access to the DOE at all.  We are providing interfaces to things that just
> > > > > > happen to be implemented using DOE under the hood.
> > > > > >
> > > > > > I have a prototype of a trivial ioctl based interface. I'll send it out
> > > > > > as an RFC later this week.  Might add a white list, depending on where
> > > > > > this discussion goes.
> > > > > >
> > > > >
> > > > > I'd say let's do this in typical Linux fashion and not solve future
> > > > > problems before they need to be solved. I.e. start small and build
> > > > > incrementally. To me that looks like a sysfs interface to convey a
> > > > > cached copy of a CDAT with an internal interface for a driver to
> > > > > trigger invalidations and re-reads on the next access. This would
> > > > > assume that userspace may have left the DOE in an indeterminate state
> > > > > and an abort cycle may be needed. A 1 second delay for the rare case
> > > > > where a collision is detected seems reasonable for just CDAT
> > > > > retrieval.
> > > >
> > > > The problem is you can not detect a collision.
> > >
> > > This discussion started because Ira questioned the handling of the
> > > busy status. If the DOE is busy and the kernel did not make it busy
> > > then there was a collision, no?
> >
> > True, but not complete. Not having busy set does not mean there
> > wasn't a collision. Busy is an indication that the EP can't recieve
> > a new request (no space in buffer or similar), not that there is a response
> > still to be sent back.  We have no way to tell if there is a response
> > going to come back in the future. There is no 'exchange in flight' flag.
>
> Perhaps useful to add a quote from the DOE ECN here.
> This is in an implementation note on Page 6.
>
> "The DOE Busy bit can be used to indicate that the DOE responder is
>  temporarily unable to accept a data object. It is necessary for a
>  DOE requester to ensure that individual data object transfers are
>  completed, and that a request/response contract is completed, for
>  example using a mutex mechanism to block other conflicting traffic
>  for cases where such conflicts are possible."

I read that as the specification mandating my proposal to disallow
multi-initiator access. My only mistake was making the exclusion apply
to reads and not limiting it to the minimum of config write exclusion.

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Wed, 19 May 2021 09:53:33 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> On Wed, May 19, 2021 at 9:35 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Wed, 19 May 2021 17:20:52 +0100
> > Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> >  
> > > On Wed, 19 May 2021 08:29:58 -0700
> > > Dan Williams <dan.j.williams@intel.com> wrote:
> > >  
> > > > On Wed, May 19, 2021 at 8:14 AM Jonathan Cameron
> > > > <Jonathan.Cameron@huawei.com> wrote:  
> > > > >
> > > > > On Wed, 19 May 2021 07:18:28 -0700
> > > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > > >  
> > > > > > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron
> > > > > > <Jonathan.Cameron@huawei.com> wrote:  
> > > > > > >
> > > > > > > On Mon, 17 May 2021 10:21:14 -0700
> > > > > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > > > > >  
> > > > > > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron
> > > > > > > > <Jonathan.Cameron@huawei.com> wrote:  
> > > > > > > > >
> > > > > > > > > On Fri, 14 May 2021 11:37:12 -0700
> > > > > > > > > Dan Williams <dan.j.williams@intel.com> wrote:
> > > > > > > > >  
> > > > > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
> > > > > > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > > > > > > [..]  
> > > > > > > > > > > > If it simplifies the kernel implementation to assume single
> > > > > > > > > > > > kernel-initiator then I think that's more than enough reason to block
> > > > > > > > > > > > out userspace, and/or provide userspace a method to get into the
> > > > > > > > > > > > kernel's queue for service.  
> > > > > > > > > > >
> > > > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way
> > > > > > > > > > > to access the DOE from user space. I like the idea if it being possible
> > > > > > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded.  
> > > > > > > > > >
> > > > > > > > > > Ah, and I like your observation that once the kernel provides a
> > > > > > > > > > "right" way to access DOE then userspace direct-access of DOE is
> > > > > > > > > > indeed a "you get to keep the pieces" event like any other unwanted
> > > > > > > > > > userspace config-write.
> > > > > > > > > >  
> > > > > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what
> > > > > > > > > > > this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> > > > > > > > > > > to those for the BAR based CXL mailboxes?  
> > > > > > > > > >
> > > > > > > > > > (warning, anti-ioctl bias incoming...)  
> > > > > > > > >
> > > > > > > > > I feel very similar about ioctls - my immediate thought was to shove this in
> > > > > > > > > debugfs, but that feels the wrong choice if we are trying to persuade people
> > > > > > > > > to use it instead of writing code that directly accesses the config space.
> > > > > > > > >  
> > > > > > > > > >
> > > > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a
> > > > > > > > > > scheme to have a sysfs bin_attr per discovered object type? This would
> > > > > > > > > > make it simliar to the pci-vpd sysfs interface.  
> > > > > > > > >
> > > > > > > > > We can discover the protocols, but anything beyond that is protocol
> > > > > > > > > specific.  I don't think there is a enough info available by any standards
> > > > > > > > > defined method. Also part of the reason to allow a safe userspace interface
> > > > > > > > > would be to provide a generic interface for vendor protocols and things like
> > > > > > > > > CXL compliance tests where we will almost certainly never provide a more
> > > > > > > > > specific kernel interface.
> > > > > > > > >
> > > > > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather
> > > > > > > > > than simple read back and that really doesn't fit well for sysfs model.
> > > > > > > > > If we get other protocols that are simple data read back, then I would
> > > > > > > > > advocate giving them a simple sysfs interface much like proposed for CDAT
> > > > > > > > > as it will always be simpler to use + self describing.
> > > > > > > > >
> > > > > > > > > On a lesser note it might be helpful to provide sysfs attrs for
> > > > > > > > > what protocols are supported.  The alternative is to let userspace run
> > > > > > > > > the discovery protocol. Perhaps we can do this as a later phase.
> > > > > > > > >  
> > > > > > > > > >
> > > > > > > > > > Then the kernel could cache objects like CDAT that don't change
> > > > > > > > > > outside of some invalidation event.  
> > > > > > > > >
> > > > > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs
> > > > > > > > > but mostly I thought the feeling was pretty strongly against them for anything
> > > > > > > > > but a few niche usecases.
> > > > > > > > >
> > > > > > > > > Feels to me like it would break most of the usual rules in a way vpd does
> > > > > > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value
> > > > > > > > > to a writable part, you will read back the same value).
> > > > > > > > >
> > > > > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly
> > > > > > > > > screams at the ways I try to abuse sysfs :)  Note I don't think Dan was
> > > > > > > > > suggesting implementing response / request directly, but I think that is
> > > > > > > > > all we could do given DOE protocols can be vendor specific and the standard
> > > > > > > > > discovery protocol doesn't let us know the fine grained support (what commands
> > > > > > > > > within a given protocol).  
> > > > > > > >
> > > > > > > > I'm not all that interested in supporting vendor defined DOE
> > > > > > > > shenanigans. There's more than enough published DOE protocols that the
> > > > > > > > kernel could limit its support to the known set. This is similar to
> > > > > > > > how ACPI DSMs are not generically supported, but when they appear in a
> > > > > > > > published specification the kernel may then grow the support. The
> > > > > > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL
> > > > > > > > Compliance, etc...
> > > > > > > >
> > > > > > > > Vendor specific DOE is in the same class as unfettered /dev/mem
> > > > > > > > access, first you need to disable the kernel's integrity and
> > > > > > > > confidentiality protections, and then you can do whatever you want. If
> > > > > > > > a vendor wants a DOE protocol supported in the "trusted" set they can
> > > > > > > > simply publish the specification and send the proper support patches.  
> > > > > > >
> > > > > > > Fair enough, though the interface should be root only, so a vendor shooting
> > > > > > > themselves in the foot this way would be no different to using pcitools
> > > > > > > to access the device directly (we are just providing safety from concurrency
> > > > > > > point of view).
> > > > > > >
> > > > > > > Anyway, I can see two options for how to do this.
> > > > > > >
> > > > > > > 1) Per protocol interface. Would not be generic, as these work in entirely
> > > > > > >    different ways (some are simple read back of tables, some require complex
> > > > > > >    cycles of operations in the right order with data flowing in both directions)
> > > > > > > 2) White list those protocols we are going to let through a generic interface
> > > > > > >    Not including CXL compliance for instance as that has nasty side effects!
> > > > > > >
> > > > > > > If we want to enable userspace DOE access, I prefer option 2.
> > > > > > >
> > > > > > > Note that I wasn't that keen on a userspace interface in the first place as
> > > > > > > in my view these should all be handled in kernel.
> > > > > > > Ultimately we should have case 1 if userspace access make sense.
> > > > > > > However, if we do this we shouldn't pretend we are providing userspace
> > > > > > > access to the DOE at all.  We are providing interfaces to things that just
> > > > > > > happen to be implemented using DOE under the hood.
> > > > > > >
> > > > > > > I have a prototype of a trivial ioctl based interface. I'll send it out
> > > > > > > as an RFC later this week.  Might add a white list, depending on where
> > > > > > > this discussion goes.
> > > > > > >  
> > > > > >
> > > > > > I'd say let's do this in typical Linux fashion and not solve future
> > > > > > problems before they need to be solved. I.e. start small and build
> > > > > > incrementally. To me that looks like a sysfs interface to convey a
> > > > > > cached copy of a CDAT with an internal interface for a driver to
> > > > > > trigger invalidations and re-reads on the next access. This would
> > > > > > assume that userspace may have left the DOE in an indeterminate state
> > > > > > and an abort cycle may be needed. A 1 second delay for the rare case
> > > > > > where a collision is detected seems reasonable for just CDAT
> > > > > > retrieval.  
> > > > >
> > > > > The problem is you can not detect a collision.  
> > > >
> > > > This discussion started because Ira questioned the handling of the
> > > > busy status. If the DOE is busy and the kernel did not make it busy
> > > > then there was a collision, no?  
> > >
> > > True, but not complete. Not having busy set does not mean there
> > > wasn't a collision. Busy is an indication that the EP can't recieve
> > > a new request (no space in buffer or similar), not that there is a response
> > > still to be sent back.  We have no way to tell if there is a response
> > > going to come back in the future. There is no 'exchange in flight' flag.  
> >
> > Perhaps useful to add a quote from the DOE ECN here.
> > This is in an implementation note on Page 6.
> >
> > "The DOE Busy bit can be used to indicate that the DOE responder is
> >  temporarily unable to accept a data object. It is necessary for a
> >  DOE requester to ensure that individual data object transfers are
> >  completed, and that a request/response contract is completed, for
> >  example using a mutex mechanism to block other conflicting traffic
> >  for cases where such conflicts are possible."  
> 
> I read that as the specification mandating my proposal to disallow
> multi-initiator access. My only mistake was making the exclusion apply
> to reads and not limiting it to the minimum of config write exclusion.

Key thing is even that isn't enough.   The mutex isn't about stopping
temporary access, it's about ensuring "request/response contract is completed".
So you would need userspace to be able to take a lock to stop the kernel
from using the DOE whilst it completes it's request/response pair and
userspace to guarantee it doesn't do anything stupid.

Easiest way to do that is provide proper interfaces that allows the
kernel to fully mediate the access + don't support direct userspace access
for normal operation. (treat it the same as an other config space write)

Jonathan

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Dan Williams]

On Wed, May 19, 2021 at 10:03 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
[..]
> > > "The DOE Busy bit can be used to indicate that the DOE responder is
> > >  temporarily unable to accept a data object. It is necessary for a
> > >  DOE requester to ensure that individual data object transfers are
> > >  completed, and that a request/response contract is completed, for
> > >  example using a mutex mechanism to block other conflicting traffic
> > >  for cases where such conflicts are possible."
> >
> > I read that as the specification mandating my proposal to disallow
> > multi-initiator access. My only mistake was making the exclusion apply
> > to reads and not limiting it to the minimum of config write exclusion.
>
> Key thing is even that isn't enough.   The mutex isn't about stopping
> temporary access, it's about ensuring "request/response contract is completed".
> So you would need userspace to be able to take a lock to stop the kernel
> from using the DOE whilst it completes it's request/response pair and
> userspace to guarantee it doesn't do anything stupid.

A userspace lockout of the kernel is not needed if userspace is
outright forbidden from corrupting the kernel's state machine. I.e.
kernel enforced full disable of user initiated config-write to DOE
registers, not the ephemeral pci_cfg_access_lock() proposal.

> Easiest way to do that is provide proper interfaces that allows the
> kernel to fully mediate the access + don't support direct userspace access
> for normal operation. (treat it the same as an other config space write)

Again, it's the parenthetical at issue. I struggle to see this as just
another errant / unwanted config-write when there is legitimate reason
for userspace to expect that touching the DOE is not destructive to
device operation as opposed to writes to other critical registers.
Where the kernel's legitimate-access and userspace's legitimate-access
to a resource collide, the kernel provides a mediation interface that
precludes conflicts. Otherwise, I don't understand why the kernel is
going through the trouble of /dev/mem and pci-mmap restrictions if it
is not supposed to be concerned about userspace corrupting driver
state.

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Wed, 19 May 2021 12:20:17 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> On Wed, May 19, 2021 at 10:03 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> [..]
> > > > "The DOE Busy bit can be used to indicate that the DOE responder is
> > > >  temporarily unable to accept a data object. It is necessary for a
> > > >  DOE requester to ensure that individual data object transfers are
> > > >  completed, and that a request/response contract is completed, for
> > > >  example using a mutex mechanism to block other conflicting traffic
> > > >  for cases where such conflicts are possible."  
> > >
> > > I read that as the specification mandating my proposal to disallow
> > > multi-initiator access. My only mistake was making the exclusion apply
> > > to reads and not limiting it to the minimum of config write exclusion.  
> >
> > Key thing is even that isn't enough.   The mutex isn't about stopping
> > temporary access, it's about ensuring "request/response contract is completed".
> > So you would need userspace to be able to take a lock to stop the kernel
> > from using the DOE whilst it completes it's request/response pair and
> > userspace to guarantee it doesn't do anything stupid.  
> 
> A userspace lockout of the kernel is not needed if userspace is
> outright forbidden from corrupting the kernel's state machine. I.e.
> kernel enforced full disable of user initiated config-write to DOE
> registers, not the ephemeral pci_cfg_access_lock() proposal.

That would work but I thought was ruled out as an approach.
@Bjorn would this be acceptable?

> 
> > Easiest way to do that is provide proper interfaces that allows the
> > kernel to fully mediate the access + don't support direct userspace access
> > for normal operation. (treat it the same as an other config space write)  
> 
> Again, it's the parenthetical at issue. I struggle to see this as just
> another errant / unwanted config-write when there is legitimate reason
> for userspace to expect that touching the DOE is not destructive to
> device operation as opposed to writes to other critical registers.

True for specific protocols (CDAT). I'm fairly sure, with IDE you can take down
the link encryption to the device, potentially (worst case?) resulting a memory
access failure and a machine reboot or corruption of persistent memory.

> Where the kernel's legitimate-access and userspace's legitimate-access
> to a resource collide, the kernel provides a mediation interface that
> precludes conflicts. Otherwise, I don't understand why the kernel is
> going through the trouble of /dev/mem and pci-mmap restrictions if it
> is not supposed to be concerned about userspace corrupting driver
> state.

The short answer is that lock requirement, in the above note, rules
out safe direct userspace use of the DOE (unless we can tell the kernel
is not going to ever use it).  Mediation must be done. Even if we safely
protect the kernel side via aborts, userspace transactions can be
interrupted in a fashion that is invisible to userspace (beyond maybe
a timeout if the userspace code is hardened against this). So there is no
legitimate use that is not fully mediated by the kernel. So ioctl
or defined per protocol interfaces are the way forwards.

Perhaps that's putting it rather strongly :)

Jonathan

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Dan Williams]

On Wed, May 19, 2021 at 1:20 PM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Wed, 19 May 2021 12:20:17 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
>
> > On Wed, May 19, 2021 at 10:03 AM Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > [..]
> > > > > "The DOE Busy bit can be used to indicate that the DOE responder is
> > > > >  temporarily unable to accept a data object. It is necessary for a
> > > > >  DOE requester to ensure that individual data object transfers are
> > > > >  completed, and that a request/response contract is completed, for
> > > > >  example using a mutex mechanism to block other conflicting traffic
> > > > >  for cases where such conflicts are possible."
> > > >
> > > > I read that as the specification mandating my proposal to disallow
> > > > multi-initiator access. My only mistake was making the exclusion apply
> > > > to reads and not limiting it to the minimum of config write exclusion.
> > >
> > > Key thing is even that isn't enough.   The mutex isn't about stopping
> > > temporary access, it's about ensuring "request/response contract is completed".
> > > So you would need userspace to be able to take a lock to stop the kernel
> > > from using the DOE whilst it completes it's request/response pair and
> > > userspace to guarantee it doesn't do anything stupid.
> >
> > A userspace lockout of the kernel is not needed if userspace is
> > outright forbidden from corrupting the kernel's state machine. I.e.
> > kernel enforced full disable of user initiated config-write to DOE
> > registers, not the ephemeral pci_cfg_access_lock() proposal.
>
> That would work but I thought was ruled out as an approach.
> @Bjorn would this be acceptable?
>

It sounded like Bjorn needed more convincing:

    "I don't know how hard we should work to protect against that."

...and I'm advocating that yes, DOE config-writes are in a different
class than other critical register writes, and that class is analogous
to what Linux does for driver managed MMIO exclusion.

> >
> > > Easiest way to do that is provide proper interfaces that allows the
> > > kernel to fully mediate the access + don't support direct userspace access
> > > for normal operation. (treat it the same as an other config space write)
> >
> > Again, it's the parenthetical at issue. I struggle to see this as just
> > another errant / unwanted config-write when there is legitimate reason
> > for userspace to expect that touching the DOE is not destructive to
> > device operation as opposed to writes to other critical registers.
>
> True for specific protocols (CDAT). I'm fairly sure, with IDE you can take down
> the link encryption to the device, potentially (worst case?) resulting a memory
> access failure and a machine reboot or corruption of persistent memory.

No, that does not sound right. My reading of the PCI IDE spec
highlights a few exclusions that apply here:

1/ A DOE instance that implements the CMA/SPDM protocol will support
"no other data object protocol(s)".

2/ An SPDM session once established arranges for "requests that are
received through a different secure [SPDM] session must be discarded
by the Responder, and must not result in a response"

>
> > Where the kernel's legitimate-access and userspace's legitimate-access
> > to a resource collide, the kernel provides a mediation interface that
> > precludes conflicts. Otherwise, I don't understand why the kernel is
> > going through the trouble of /dev/mem and pci-mmap restrictions if it
> > is not supposed to be concerned about userspace corrupting driver
> > state.
>
> The short answer is that lock requirement, in the above note, rules
> out safe direct userspace use of the DOE (unless we can tell the kernel
> is not going to ever use it).

Linux has the mitigation for that situation defined already. It's the
mechanism for /dev/mem and pci-mmap exclusion: disable the driver to
enable unfettered userspace access (modulo kernel-lockdown is
disabled).

> Mediation must be done. Even if we safely
> protect the kernel side via aborts, userspace transactions can be
> interrupted in a fashion that is invisible to userspace (beyond maybe
> a timeout if the userspace code is hardened against this).

Right, ephemeral per-transaction lockout is more complicated to handle
than coarse lockout bounded to driver attach lifetime.

> So there is no
> legitimate use that is not fully mediated by the kernel. So ioctl
> or defined per protocol interfaces are the way forwards.

Agree, and Linux has historically tried to wrap specific protocols
around capabilities like this rather than defining raw passthroughs.
I.e. I'm equating DOE enabling policy to ACPI DSM enabling policy. So
per-protocol enabling is my expectation regardless of sysfs or ioctl.
In fact. for SPDM and IDE key establishment that is probably neither
ioctl nor sysfs, but instead a cooperation with the Linux keys api.

> Perhaps that's putting it rather strongly :)

No major disagreement on the big picture... just quibbling with
details at this point.

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Dan Williams]

On Wed, May 19, 2021 at 4:51 PM Dan Williams <dan.j.williams@intel.com> wrote:
[..]
> > The short answer is that lock requirement, in the above note, rules
> > out safe direct userspace use of the DOE (unless we can tell the kernel
> > is not going to ever use it).
>
> Linux has the mitigation for that situation defined already. It's the
> mechanism for /dev/mem and pci-mmap exclusion: disable the driver to
> enable unfettered userspace access (modulo kernel-lockdown is
> disabled).
>

Note that when I say "driver" here, it need not necessarily be the
cxl_pci driver for the memory expander. For example, DOE functionality
could be handled by an aux-bus device+driver where that can be
unloaded without taking down the rest of the CXL driver.

Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Jonathan Cameron]

On Wed, 19 May 2021 16:51:36 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> On Wed, May 19, 2021 at 1:20 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Wed, 19 May 2021 12:20:17 -0700
> > Dan Williams <dan.j.williams@intel.com> wrote:
> >  
> > > On Wed, May 19, 2021 at 10:03 AM Jonathan Cameron
> > > <Jonathan.Cameron@huawei.com> wrote:
> > > [..]  
> > > > > > "The DOE Busy bit can be used to indicate that the DOE responder is
> > > > > >  temporarily unable to accept a data object. It is necessary for a
> > > > > >  DOE requester to ensure that individual data object transfers are
> > > > > >  completed, and that a request/response contract is completed, for
> > > > > >  example using a mutex mechanism to block other conflicting traffic
> > > > > >  for cases where such conflicts are possible."  
> > > > >
> > > > > I read that as the specification mandating my proposal to disallow
> > > > > multi-initiator access. My only mistake was making the exclusion apply
> > > > > to reads and not limiting it to the minimum of config write exclusion.  
> > > >
> > > > Key thing is even that isn't enough.   The mutex isn't about stopping
> > > > temporary access, it's about ensuring "request/response contract is completed".
> > > > So you would need userspace to be able to take a lock to stop the kernel
> > > > from using the DOE whilst it completes it's request/response pair and
> > > > userspace to guarantee it doesn't do anything stupid.  
> > >
> > > A userspace lockout of the kernel is not needed if userspace is
> > > outright forbidden from corrupting the kernel's state machine. I.e.
> > > kernel enforced full disable of user initiated config-write to DOE
> > > registers, not the ephemeral pci_cfg_access_lock() proposal.  
> >
> > That would work but I thought was ruled out as an approach.
> > @Bjorn would this be acceptable?
> >  
> 
> It sounded like Bjorn needed more convincing:
> 
>     "I don't know how hard we should work to protect against that."
> 
> ...and I'm advocating that yes, DOE config-writes are in a different
> class than other critical register writes, and that class is analogous
> to what Linux does for driver managed MMIO exclusion.

I'm not convinced they are special, though I can see an argument for write
protecting a bunch of registers in config space, including them, with
some form of disable for those debug type cases that Bjorn referred to.

> 
> > >  
> > > > Easiest way to do that is provide proper interfaces that allows the
> > > > kernel to fully mediate the access + don't support direct userspace access
> > > > for normal operation. (treat it the same as an other config space write)  
> > >
> > > Again, it's the parenthetical at issue. I struggle to see this as just
> > > another errant / unwanted config-write when there is legitimate reason
> > > for userspace to expect that touching the DOE is not destructive to
> > > device operation as opposed to writes to other critical registers.  
> >
> > True for specific protocols (CDAT). I'm fairly sure, with IDE you can take down
> > the link encryption to the device, potentially (worst case?) resulting a memory
> > access failure and a machine reboot or corruption of persistent memory.  
> 
> No, that does not sound right. My reading of the PCI IDE spec
> highlights a few exclusions that apply here:
> 
> 1/ A DOE instance that implements the CMA/SPDM protocol will support
> "no other data object protocol(s)".
> 
> 2/ An SPDM session once established arranges for "requests that are
> received through a different secure [SPDM] session must be discarded
> by the Responder, and must not result in a response"

Fair enough.  I've not looked at that one in a while and clearly
need to give it another read.
CXL compliance though can definitely cause things to be exciting
for the host.

> 
> >  
> > > Where the kernel's legitimate-access and userspace's legitimate-access
> > > to a resource collide, the kernel provides a mediation interface that
> > > precludes conflicts. Otherwise, I don't understand why the kernel is
> > > going through the trouble of /dev/mem and pci-mmap restrictions if it
> > > is not supposed to be concerned about userspace corrupting driver
> > > state.  
> >
> > The short answer is that lock requirement, in the above note, rules
> > out safe direct userspace use of the DOE (unless we can tell the kernel
> > is not going to ever use it).  
> 
> Linux has the mitigation for that situation defined already. It's the
> mechanism for /dev/mem and pci-mmap exclusion: disable the driver to
> enable unfettered userspace access (modulo kernel-lockdown is
> disabled).
> 
> > Mediation must be done. Even if we safely
> > protect the kernel side via aborts, userspace transactions can be
> > interrupted in a fashion that is invisible to userspace (beyond maybe
> > a timeout if the userspace code is hardened against this).  
> 
> Right, ephemeral per-transaction lockout is more complicated to handle
> than coarse lockout bounded to driver attach lifetime.
> 
> > So there is no
> > legitimate use that is not fully mediated by the kernel. So ioctl
> > or defined per protocol interfaces are the way forwards.  
> 
> Agree, and Linux has historically tried to wrap specific protocols
> around capabilities like this rather than defining raw passthroughs.
> I.e. I'm equating DOE enabling policy to ACPI DSM enabling policy. So
> per-protocol enabling is my expectation regardless of sysfs or ioctl.
> In fact. for SPDM and IDE key establishment that is probably neither
> ioctl nor sysfs, but instead a cooperation with the Linux keys api.

Agreed.  On that basis I'll do a very limited polish of the generic
ioctl approach simply as an enabling tool and put some warnings
on the patch that we don't currently intend it to be merged etc.

Great - that lets be me lazy with testing lifetime management which
is always irritating to do ;)

> 
> > Perhaps that's putting it rather strongly :)  
> 
> No major disagreement on the big picture... just quibbling with
> details at this point.