* [PATCH V11 0/8] CXL: Read CDAT and DSMAS data
@ 2022-06-10 20:22 ira.weiny
2022-06-10 20:22 ` [PATCH V11 1/8] PCI: Add vendor ID for the PCI SIG ira.weiny
` (7 more replies)
0 siblings, 8 replies; 44+ messages in thread
From: ira.weiny @ 2022-06-10 20:22 UTC (permalink / raw)
To: Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Alison Schofield, Vishal Verma, Dave Jiang,
Ben Widawsky, linux-kernel, linux-cxl, linux-pci
From: Ira Weiny <ira.weiny@intel.com>
Changes from V10:[7]
Address Ben Widawsky's comments
Protect against potentially malicious devices.
Fix ownership issue of cdat_mb
CXL drivers need various data which are provided through generic DOE mailboxes
as defined in the PCIe 6.0 spec.[1]
One such data is the Coherent Device Atribute Table (CDAT). CDAT data provides
coherent information about the various devices in the system. It was developed
because systems no longer have a priori knowledge of all coherent devices
within a system. CDAT describes the coherent characteristics of the
components on the CXL bus separate from system configurations. The OS can
then, for example, use this information to form correct interleave sets.
To begin reading the CDAT the OS must have support to access the DOE mailboxes
provided by the CXL devices.
Because DOE is not specific to DOE but is provided within the PCI spec, the
series adds PCI DOE capability library functions. These functions allow for
the iteration of the DOE capabilities on a device as well as creating
pci_doe_mb structures which can control the operation of the DOE state machine.
For now the iteration of and storage of the DOE mailboxes is done on memdev
objects within the CXL stack. When this is needed in more generic code this
can be lifted later.
This work was tested using qemu.
[0] https://lore.kernel.org/linux-cxl/20211105235056.3711389-1-ira.weiny@intel.com/
[1] https://pcisig.com/specifications
[2] https://lore.kernel.org/qemu-devel/20210202005948.241655-1-ben.widawsky@intel.com/
[3] https://lore.kernel.org/linux-cxl/20220201071952.900068-1-ira.weiny@intel.com/
[4] https://lore.kernel.org/linux-cxl/20220330235920.2800929-1-ira.weiny@intel.com/
[5] https://lore.kernel.org/linux-cxl/20220414203237.2198665-1-ira.weiny@intel.com/
[6] https://lore.kernel.org/linux-cxl/20220531152632.1397976-1-ira.weiny@intel.com/
[7] https://lore.kernel.org/linux-cxl/20220605005049.2155874-1-ira.weiny@intel.com/
Previous changes
================
Changes from V9:[6]
Address feedback from
Lukas Wunner, Davidlohr Bueso, Jonathan Cameron,
Alison Schofield, and Ben Widawsky
Details in each individual patch.
Changes from V8:[5]
For this version I've punted a bit to get it out and drop the auxiliary
bus functionality. I like where Jonathan is going with the port driver
idea. I think eventually the irq/mailbox creation will need to be more
generic in a PCI port driver. I've modeled this version on such an
architecture but used the CXL port for the time being.
From Dan
Drop the auxiliary bus/device
From Jonathan
Cleanups
From Bjorn
Clean up commit messages
move pci-doe.c to doe.c
Clean up PCI spec references
Ensure all messages use pci_*()
Add offset to error messages to distinguish mailboxes
use hex for DOE offsets
Print 4 nibbles for Vendor ID and 2 for type.
s/irq/IRQ in comments
Fix long lines
Fix typos
Changes from V7:[4]
Avoid code bloat by making pci-doe.c conditional on CONFIG_PCI_DOE
which is auto selected by the CXL_PCI config option.
Minor code clean ups
Fix bug in pci_doe_supports_prot()
Rebase to cxl-pending
Changes from V6:[3]
The big change is the removal of the auxiliary bus code from the PCI
layer. The auxiliary bus usage is now in the CXL layer. The PCI layer
provides helpers for subsystems to utilize DOE mailboxes by creating a
pci_doe_mb object which controls a state machine for that mailbox
capability. The CXL layer wraps this object in an auxiliary device and
driver which can then be used to determine if the kernel is controlling
the capability or it is available to be used by user space. Reads from
user space via lspci are allowed. Writes are allowed but flagged via a
tainting the kernel.
Feedback from Bjorn, Jonathan, and Dan
Details in each patch
Changes from V5:[0]
Rework the patch set to split PCI vs CXL changes
Also make each change a bit more stand alone for easier review
Add cxl_cdat structure
Put CDAT related data structures in cdat.h
Clarify some device lifetimes with comments
Incorporate feedback from Jonathan, Bjorn and Dan
The bigest change is placing the DOE scanning code into the
pci_doe driver (part of the PCI codre).
Validate the CDAT when it is read rather than before DSMAS
parsing
Do not report DSMAS failure as an error, report a warning and
keep going.
Retry reading the table 1 time.
Update commit messages and this cover letter
Ira Weiny (6):
PCI: Replace magic constant for PCI Sig Vendor ID
cxl/pci: Create PCI DOE mailbox's for memory devices
cxl/port: Read CDAT table
cxl/port: Introduce cxl_cdat_valid()
cxl/port: Retry reading CDAT on failure
cxl/port: Parse out DSMAS data from CDAT table
Jonathan Cameron (2):
PCI: Add vendor ID for the PCI SIG
PCI: Create PCI library functions in support of DOE mailboxes.
drivers/cxl/Kconfig | 1 +
drivers/cxl/cdat.h | 125 ++++++
drivers/cxl/core/pci.c | 302 +++++++++++++++
drivers/cxl/cxl.h | 5 +
drivers/cxl/cxlmem.h | 10 +
drivers/cxl/cxlpci.h | 2 +
drivers/cxl/mem.c | 1 +
drivers/cxl/pci.c | 114 ++++++
drivers/cxl/port.c | 51 +++
drivers/pci/Kconfig | 3 +
drivers/pci/Makefile | 1 +
drivers/pci/doe.c | 693 ++++++++++++++++++++++++++++++++++
drivers/pci/probe.c | 2 +-
include/linux/pci-doe.h | 65 ++++
include/linux/pci_ids.h | 1 +
include/uapi/linux/pci_regs.h | 29 +-
16 files changed, 1403 insertions(+), 2 deletions(-)
create mode 100644 drivers/cxl/cdat.h
create mode 100644 drivers/pci/doe.c
create mode 100644 include/linux/pci-doe.h
--
2.35.1
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH V11 1/8] PCI: Add vendor ID for the PCI SIG
2022-06-10 20:22 [PATCH V11 0/8] CXL: Read CDAT and DSMAS data ira.weiny
@ 2022-06-10 20:22 ` ira.weiny
2022-06-10 20:22 ` [PATCH V11 2/8] PCI: Replace magic constant for PCI Sig Vendor ID ira.weiny
` (6 subsequent siblings)
7 siblings, 0 replies; 44+ messages in thread
From: ira.weiny @ 2022-06-10 20:22 UTC (permalink / raw)
To: Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Davidlohr Bueso, Alison Schofield, Vishal Verma, Ira Weiny,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This ID is used in DOE headers to identify protocols that are defined
within the PCI Express Base Specification, PCIe r6.0, sec 6.30.1.1 table
6-32.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
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 0178823ce8c2..8af3b86206b1 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -151,6 +151,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.35.1
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH V11 2/8] PCI: Replace magic constant for PCI Sig Vendor ID
2022-06-10 20:22 [PATCH V11 0/8] CXL: Read CDAT and DSMAS data ira.weiny
2022-06-10 20:22 ` [PATCH V11 1/8] PCI: Add vendor ID for the PCI SIG ira.weiny
@ 2022-06-10 20:22 ` ira.weiny
2022-06-10 20:22 ` [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes ira.weiny
` (5 subsequent siblings)
7 siblings, 0 replies; 44+ messages in thread
From: ira.weiny @ 2022-06-10 20:22 UTC (permalink / raw)
To: Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Davidlohr Bueso, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
From: Ira Weiny <ira.weiny@intel.com>
Replace the magic value in pci_bus_crs_vendor_id() with
PCI_VENDOR_ID_PCI_SIG.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
Changes from V6
Simplify commit message
---
drivers/pci/probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 17a969942d37..6280e780a48c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2312,7 +2312,7 @@ EXPORT_SYMBOL(pci_alloc_dev);
static bool pci_bus_crs_vendor_id(u32 l)
{
- return (l & 0xffff) == 0x0001;
+ return (l & 0xffff) == PCI_VENDOR_ID_PCI_SIG;
}
static bool pci_bus_wait_crs(struct pci_bus *bus, int devfn, u32 *l,
--
2.35.1
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-10 20:22 [PATCH V11 0/8] CXL: Read CDAT and DSMAS data ira.weiny
2022-06-10 20:22 ` [PATCH V11 1/8] PCI: Add vendor ID for the PCI SIG ira.weiny
2022-06-10 20:22 ` [PATCH V11 2/8] PCI: Replace magic constant for PCI Sig Vendor ID ira.weiny
@ 2022-06-10 20:22 ` ira.weiny
2022-06-14 3:53 ` Li, Ming
` (2 more replies)
2022-06-10 20:22 ` [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices ira.weiny
` (4 subsequent siblings)
7 siblings, 3 replies; 44+ messages in thread
From: ira.weiny @ 2022-06-10 20:22 UTC (permalink / raw)
To: Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Alison Schofield, Vishal Verma, Dave Jiang,
Ben Widawsky, linux-kernel, linux-cxl, linux-pci
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Introduced in a PCI r6.0, sec 6.30, DOE provides a config space based
mailbox with standard protocol discovery. Each mailbox is accessed
through a DOE Extended Capability.
Each DOE mailbox must support the DOE discovery protocol in addition to
any number of additional protocols.
Define core PCI functionality to manage a single PCI DOE mailbox at a
defined config space offset. Functionality includes iterating,
creating, query of supported protocol, task submission, and destruction
of the mailboxes.
If interrupts are desired, the interrupt number can be queried and
passed to the create function. Passing a negative value disables
interrupts for that mailbox. It is the callers responsibility to ensure
enough interrupt vectors are allocated.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Co-developed-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
Changes from V9
Lukas Wunner
Update comments
Move private doe structures and defines from pci-doe.h to doe.c
check Data Obj Ready prior to last ack
Davidlohr
make task_lock a spinlock
Lukas/Jonathan
Remove special case of error in irq handler
Fix potential race with the scheduling of a task when one is ending.
The current task can't be retired until the state
machine is idle. Otherwise a new task work item may run
and the state machine would be out of sync.
Changes from V8
Remove Bjorn's ack
Expose a function to find the irq number for a mailbox based on
offset. This is the code Jonathan proposed for finding the irq
number here:
https://lore.kernel.org/linux-cxl/20220503153449.4088-2-Jonathan.Cameron@huawei.com/
This removes funky bool parameter to create.
Move pci_set_master() within the pci_doe_enable_irq()
Per Bjorn
Clean up commit messages
move pci-doe.c to doe.c
Clean up PCI spec references
Ensure all messages use pci_*()
Add offset to error messages to distinguish mailboxes
use hex for DOE offsets
Print 4 nibbles for Vendor ID and 2 for type.
s/irq/IRQ in comments
Fix long lines
Fix typos
Changes from V7
Add a Kconfig for this functionality
Fix bug in pci_doe_supports_prot()
Rebased on cxl-pending
Changes from V6
Clean up signed off by lines
Make this functionality all PCI library functions
Clean up header files
s/pci_doe_irq/pci_doe_irq_handler
Use pci_{request,free}_irq
Remove irq_name (maintained by pci_request_irq)
Fix checks to use an irq
Consistently use u16 for cap_offset
Cleanup kdocs and comments
Create a helper retire_cur_task() to handle locking of the
current task pointer.
Remove devm_ calls from PCI layer.
The devm_ calls do not allow for the pci_doe_mb objects
to be tied to an auxiliary device. Leave it to the
caller to use devm_ if desired.
From Dan Williams
s/cb/end_task/; Pass pci_doe_task to end_task
Clarify exchange/task/request/response.
Merge pci_doe_task and pci_doe_exchange into
pci_doe_task which represents a single
request/response task for the state machine to
process.
Simplify submitting work to the mailbox
Replace pci_doe_exchange_sync() with
pci_doe_submit_task() Consumers of the mailbox
are now responsible for setting up callbacks
within a task object and submitting them to the
mailbox to be processed.
Remove WARN_ON when task != NULL and be sure to abort that task.
Convert abort/dead to atomic flags
s/state_lock/task_lock to better define what the lock is
protecting
Remove all the auxiliary bus code from the PCI layer
The PCI layer provides helpers to use the DOE
Mailboxes. Each subsystem can then use the
helpers as they see fit. The CXL layer in this
series uses aux devices to manage the new
pci_doe_mb objects.
From Bjorn
Clarify the fact that DOE mailboxes are capabilities of
the device.
Code clean ups
Cleanup Makefile
Update references to PCI SIG spec v6.0
Move this attribution here:
This code is based on Jonathan's V4 series here:
https://lore.kernel.org/linux-cxl/20210524133938.2815206-1-Jonathan.Cameron@huawei.com/
Changes from V5
From Bjorn
s/pci_WARN/pci_warn
Add timeout period to print
Trim to 80 chars
Use Tabs for DOE define spacing
Use %#x for clarity
From Jonathan
Addresses concerns about the order of unwinding stuff
s/doe/doe_dev in pci_doe_exhcnage_sync
Correct kernel Doc comment
Move pci_doe_task_complete() down in the file.
Rework pci_doe_irq()
process STATUS_ERROR first
Return IRQ_NONE if the irq is not processed
Use PCI_DOE_STATUS_INT_STATUS explicitly to
clear the irq
Clean up goto label s/err_free_irqs/err_free_irq
use devm_kzalloc for doe struct
clean up error paths in pci_doe_probe
s/pci_doe_drv/pci_doe
remove include mutex.h
remove device name and define, move it in the next patch which uses it
use devm_kasprintf() for irq_name
use devm_request_irq()
remove pci_doe_unregister()
[get/put]_device() were unneeded and with the use of
devm_* this function can be removed completely.
refactor pci_doe_register and s/pci_doe_register/pci_doe_reg_irq
make this function just a registration of the irq and
move pci_doe_abort() into pci_doe_probe()
use devm_* to allocate the protocol array
Changes from Jonathan's V4
Move the DOE MB code into the DOE auxiliary driver
Remove Task List in favor of a wait queue
Changes from Ben
remove CXL references
propagate rc from pci functions on error
---
drivers/pci/Kconfig | 3 +
drivers/pci/Makefile | 1 +
drivers/pci/doe.c | 693 ++++++++++++++++++++++++++++++++++
include/linux/pci-doe.h | 65 ++++
include/uapi/linux/pci_regs.h | 29 +-
5 files changed, 790 insertions(+), 1 deletion(-)
create mode 100644 drivers/pci/doe.c
create mode 100644 include/linux/pci-doe.h
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 133c73207782..b2f2e588a817 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -121,6 +121,9 @@ config XEN_PCIDEV_FRONTEND
config PCI_ATS
bool
+config PCI_DOE
+ bool
+
config PCI_ECAM
bool
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 0da6b1ebc694..2680e4c92f0a 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_PCI_ECAM) += ecam.o
obj-$(CONFIG_PCI_P2PDMA) += p2pdma.o
obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
obj-$(CONFIG_VGA_ARB) += vgaarb.o
+obj-$(CONFIG_PCI_DOE) += doe.o
# Endpoint library must be initialized before its users
obj-$(CONFIG_PCI_ENDPOINT) += endpoint/
diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c
new file mode 100644
index 000000000000..4619c3e547f2
--- /dev/null
+++ b/drivers/pci/doe.c
@@ -0,0 +1,693 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Data Object Exchange
+ * PCIe r6.0, sec 6.30 DOE
+ *
+ * Copyright (C) 2021 Huawei
+ * Jonathan Cameron <Jonathan.Cameron@huawei.com>
+ *
+ * Copyright (C) 2022 Intel Corporation
+ * Ira Weiny <ira.weiny@intel.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/jiffies.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.30.2 Operation, PCI Spec r6.0 */
+#define PCI_DOE_TIMEOUT HZ
+
+enum pci_doe_state {
+ DOE_IDLE,
+ DOE_WAIT_RESP,
+ DOE_WAIT_ABORT,
+ DOE_WAIT_ABORT_ON_ERR,
+};
+
+#define PCI_DOE_FLAG_ABORT 0
+#define PCI_DOE_FLAG_DEAD 1
+
+/**
+ * struct pci_doe_mb - State for a single DOE mailbox
+ *
+ * This state is used to manage a single DOE mailbox capability. All fields
+ * should be considered opaque to the consumers and the structure passed into
+ * the helpers below after being created by devm_pci_doe_create()
+ *
+ * @pdev: PCI device this mailbox belongs to
+ * @abort_c: Completion used for initial abort handling
+ * @irq: Interrupt used for signaling DOE ready or abort
+ * @prots: Array of protocols supported on this DOE
+ * @num_prots: Size of @prots array
+ * @cap_offset: Capability offset
+ * @wq: Wait queue to wait on if a query is in progress
+ * @cur_task: Current task the state machine is working on
+ * @task_lock: Protect cur_task
+ * @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
+ * @flags: Bit array of PCI_DOE_FLAG_* flags
+ *
+ * Note: @prots can't be allocated with struct size because the number of
+ * protocols is not known until after this structure is in use. However, the
+ * single discovery protocol is always required to query for the number of
+ * protocols.
+ */
+struct pci_doe_mb {
+ struct pci_dev *pdev;
+ struct completion abort_c;
+ int irq;
+ struct pci_doe_protocol *prots;
+ int num_prots;
+ u16 cap_offset;
+
+ wait_queue_head_t wq;
+ struct pci_doe_task *cur_task;
+ spinlock_t task_lock;
+ struct delayed_work statemachine;
+ enum pci_doe_state state;
+ unsigned long timeout_jiffies;
+ unsigned int busy_retries;
+ unsigned long flags;
+};
+
+static irqreturn_t pci_doe_irq_handler(int irq, void *data)
+{
+ struct pci_doe_mb *doe_mb = data;
+ struct pci_dev *pdev = doe_mb->pdev;
+ int offset = doe_mb->cap_offset;
+ u32 val;
+
+ pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
+ if (FIELD_GET(PCI_DOE_STATUS_INT_STATUS, val)) {
+ pci_write_config_dword(pdev, offset + PCI_DOE_STATUS,
+ PCI_DOE_STATUS_INT_STATUS);
+ mod_delayed_work(system_wq, &doe_mb->statemachine, 0);
+ return IRQ_HANDLED;
+ }
+
+ return IRQ_NONE;
+}
+
+/*
+ * Only called when safe to directly access the DOE from
+ * doe_statemachine_work(). Outside access is not protected. Users who
+ * perform such access are left with the pieces.
+ */
+static void pci_doe_abort_start(struct pci_doe_mb *doe_mb)
+{
+ struct pci_dev *pdev = doe_mb->pdev;
+ int offset = doe_mb->cap_offset;
+ u32 val;
+
+ val = PCI_DOE_CTRL_ABORT;
+ if (doe_mb->irq >= 0)
+ val |= PCI_DOE_CTRL_INT_EN;
+ pci_write_config_dword(pdev, offset + PCI_DOE_CTRL, val);
+
+ doe_mb->timeout_jiffies = jiffies + HZ;
+ schedule_delayed_work(&doe_mb->statemachine, HZ);
+}
+
+static int pci_doe_send_req(struct pci_doe_mb *doe_mb,
+ struct pci_doe_task *task)
+{
+ struct pci_dev *pdev = doe_mb->pdev;
+ int offset = doe_mb->cap_offset;
+ 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, offset + 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, task->prot.vid) |
+ FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, task->prot.type);
+ pci_write_config_dword(pdev, offset + PCI_DOE_WRITE, val);
+ /* Length is 2 DW of header + length of payload in DW */
+ pci_write_config_dword(pdev, offset + PCI_DOE_WRITE,
+ FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH,
+ 2 + task->request_pl_sz /
+ sizeof(u32)));
+ for (i = 0; i < task->request_pl_sz / sizeof(u32); i++)
+ pci_write_config_dword(pdev, offset + PCI_DOE_WRITE,
+ task->request_pl[i]);
+
+ val = PCI_DOE_CTRL_GO;
+ if (doe_mb->irq >= 0)
+ val |= PCI_DOE_CTRL_INT_EN;
+
+ pci_write_config_dword(pdev, offset + PCI_DOE_CTRL, val);
+ /* Request is sent - now wait for poll or IRQ */
+ return 0;
+}
+
+static bool pci_doe_data_obj_ready(struct pci_doe_mb *doe_mb)
+{
+ struct pci_dev *pdev = doe_mb->pdev;
+ int offset = doe_mb->cap_offset;
+ u32 val;
+
+ pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
+ if (FIELD_GET(PCI_DOE_STATUS_DATA_OBJECT_READY, val))
+ return true;
+ return false;
+}
+
+static int pci_doe_recv_resp(struct pci_doe_mb *doe_mb, struct pci_doe_task *task)
+{
+ struct pci_dev *pdev = doe_mb->pdev;
+ int offset = doe_mb->cap_offset;
+ size_t length, payload_length;
+ u32 val;
+ int i;
+
+ /* Read the first dword to get the protocol */
+ pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
+ if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != task->prot.vid) ||
+ (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != task->prot.type)) {
+ pci_err(pdev,
+ "DOE [%x] expected [VID, Protocol] = [%04x, %02x], got [%04x, %02x]\n",
+ doe_mb->cap_offset,
+ task->prot.vid, task->prot.type,
+ 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, offset + PCI_DOE_READ, 0);
+ /* Read the second dword to get the length */
+ pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
+ pci_write_config_dword(pdev, offset + PCI_DOE_READ, 0);
+
+ length = FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH, val);
+ if (length > SZ_1M || length < 2)
+ return -EIO;
+
+ /* First 2 dwords have already been read */
+ length -= 2;
+ payload_length = min(length, task->response_pl_sz / sizeof(u32));
+ /* Read the rest of the response payload */
+ for (i = 0; i < payload_length; i++) {
+ pci_read_config_dword(pdev, offset + PCI_DOE_READ,
+ &task->response_pl[i]);
+ /* Prior to the last ack, ensure Data Object Ready */
+ if (i == (payload_length-1) && !pci_doe_data_obj_ready(doe_mb))
+ return -EIO;
+ pci_write_config_dword(pdev, offset + PCI_DOE_READ, 0);
+ }
+
+ /* Flush excess length */
+ for (; i < length; i++) {
+ pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
+ pci_write_config_dword(pdev, offset + PCI_DOE_READ, 0);
+ }
+
+ /* Final error check to pick up on any since Data Object Ready */
+ pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
+ if (FIELD_GET(PCI_DOE_STATUS_ERROR, val))
+ return -EIO;
+
+ return min(length, task->response_pl_sz / sizeof(u32)) * sizeof(u32);
+}
+
+static void signal_task_complete(struct pci_doe_task *task, int rv)
+{
+ task->rv = rv;
+ task->complete(task);
+}
+
+static void retire_cur_task(struct pci_doe_mb *doe_mb)
+{
+ spin_lock(&doe_mb->task_lock);
+ doe_mb->cur_task = NULL;
+ spin_unlock(&doe_mb->task_lock);
+ wake_up_interruptible(&doe_mb->wq);
+}
+
+static void doe_statemachine_work(struct work_struct *work)
+{
+ struct delayed_work *w = to_delayed_work(work);
+ struct pci_doe_mb *doe_mb = container_of(w, struct pci_doe_mb,
+ statemachine);
+ struct pci_dev *pdev = doe_mb->pdev;
+ int offset = doe_mb->cap_offset;
+ enum pci_doe_state prev_state;
+ struct pci_doe_task *task;
+ u32 val;
+ int rc;
+
+ spin_lock(&doe_mb->task_lock);
+ task = doe_mb->cur_task;
+ spin_unlock(&doe_mb->task_lock);
+
+ if (test_and_clear_bit(PCI_DOE_FLAG_ABORT, &doe_mb->flags)) {
+ /*
+ * Currently only used during init - care needed if
+ * pci_doe_abort() is generally exposed as it would impact
+ * queries in flight.
+ */
+ if (task)
+ pci_err(pdev, "DOE [%x] Aborting with active task!\n",
+ doe_mb->cap_offset);
+ doe_mb->state = DOE_WAIT_ABORT;
+ pci_doe_abort_start(doe_mb);
+ return;
+ }
+
+ switch (doe_mb->state) {
+ case DOE_IDLE:
+ if (task == NULL)
+ return;
+
+ rc = pci_doe_send_req(doe_mb, task);
+
+ /*
+ * 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_mb->busy_retries++;
+ if (doe_mb->busy_retries == PCI_DOE_BUSY_MAX_RETRIES) {
+ /* Long enough, fail this request */
+ pci_warn(pdev,
+ "DOE [%x] busy for too long (> 1 sec)\n",
+ doe_mb->cap_offset);
+ doe_mb->busy_retries = 0;
+ goto err_busy;
+ }
+ schedule_delayed_work(w, HZ / PCI_DOE_BUSY_MAX_RETRIES);
+ return;
+ }
+ if (rc)
+ goto err_abort;
+ doe_mb->busy_retries = 0;
+
+ doe_mb->state = DOE_WAIT_RESP;
+ doe_mb->timeout_jiffies = jiffies + HZ;
+ /* Now poll or wait for IRQ with timeout */
+ if (doe_mb->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, offset + 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_mb->timeout_jiffies)) {
+ rc = -ETIMEDOUT;
+ goto err_abort;
+ }
+ schedule_delayed_work(w, PCI_DOE_POLL_INTERVAL);
+ return;
+ }
+
+ rc = pci_doe_recv_resp(doe_mb, task);
+ if (rc < 0)
+ goto err_abort;
+
+ doe_mb->state = DOE_IDLE;
+
+ retire_cur_task(doe_mb);
+ /* Set the return value to the length of received payload */
+ signal_task_complete(task, rc);
+
+ return;
+
+ case DOE_WAIT_ABORT:
+ case DOE_WAIT_ABORT_ON_ERR:
+ prev_state = doe_mb->state;
+
+ pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
+
+ if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) &&
+ !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) {
+ doe_mb->state = DOE_IDLE;
+ /* Back to normal state - carry on */
+ retire_cur_task(doe_mb);
+ } else if (time_after(jiffies, doe_mb->timeout_jiffies)) {
+ /* Task has timed out and is dead - abort */
+ pci_err(pdev, "DOE [%x] ABORT timed out\n",
+ doe_mb->cap_offset);
+ set_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags);
+ retire_cur_task(doe_mb);
+ }
+
+ /*
+ * For deliberately triggered abort, someone is
+ * waiting.
+ */
+ if (prev_state == DOE_WAIT_ABORT) {
+ if (task)
+ signal_task_complete(task, -EFAULT);
+ complete(&doe_mb->abort_c);
+ }
+
+ return;
+ }
+
+err_abort:
+ doe_mb->state = DOE_WAIT_ABORT_ON_ERR;
+ pci_doe_abort_start(doe_mb);
+err_busy:
+ signal_task_complete(task, rc);
+ if (doe_mb->state == DOE_IDLE)
+ retire_cur_task(doe_mb);
+}
+
+static void pci_doe_task_complete(struct pci_doe_task *task)
+{
+ complete(task->private);
+}
+
+static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
+ u8 *protocol)
+{
+ u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
+ *index);
+ u32 response_pl;
+ DECLARE_COMPLETION_ONSTACK(c);
+ struct pci_doe_task task = {
+ .prot.vid = PCI_VENDOR_ID_PCI_SIG,
+ .prot.type = PCI_DOE_PROTOCOL_DISCOVERY,
+ .request_pl = &request_pl,
+ .request_pl_sz = sizeof(request_pl),
+ .response_pl = &response_pl,
+ .response_pl_sz = sizeof(response_pl),
+ .complete = pci_doe_task_complete,
+ .private = &c,
+ };
+ int ret;
+
+ ret = pci_doe_submit_task(doe_mb, &task);
+ if (ret < 0)
+ return ret;
+
+ wait_for_completion(&c);
+
+ if (task.rv != 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_mb *doe_mb)
+{
+ u8 index = 0;
+ int num_prots;
+ int rc;
+
+ /* Discovery protocol must always be supported and must report itself */
+ num_prots = 1;
+
+ doe_mb->prots = kcalloc(num_prots, sizeof(*doe_mb->prots), GFP_KERNEL);
+ if (!doe_mb->prots)
+ return -ENOMEM;
+
+ /*
+ * NOTE: doe_mb_prots is freed by pci_doe_free_mb() automatically on
+ * error if pci_doe_cache_protocols() fails past this point.
+ */
+ do {
+ struct pci_doe_protocol *prot;
+
+ prot = &doe_mb->prots[num_prots - 1];
+ rc = pci_doe_discovery(doe_mb, &index, &prot->vid, &prot->type);
+ if (rc)
+ return rc;
+
+ if (index) {
+ struct pci_doe_protocol *prot_new;
+
+ num_prots++;
+ prot_new = krealloc(doe_mb->prots,
+ sizeof(*doe_mb->prots) * num_prots,
+ GFP_KERNEL);
+ if (!prot_new)
+ return -ENOMEM;
+
+ doe_mb->prots = prot_new;
+ }
+ } while (index);
+
+ doe_mb->num_prots = num_prots;
+ return 0;
+}
+
+static int pci_doe_abort(struct pci_doe_mb *doe_mb)
+{
+ reinit_completion(&doe_mb->abort_c);
+ set_bit(PCI_DOE_FLAG_ABORT, &doe_mb->flags);
+ schedule_delayed_work(&doe_mb->statemachine, 0);
+ wait_for_completion(&doe_mb->abort_c);
+
+ if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags))
+ return -EIO;
+
+ return 0;
+}
+
+static int pci_doe_enable_irq(struct pci_doe_mb *doe_mb, unsigned int irq)
+{
+ struct pci_dev *pdev = doe_mb->pdev;
+ int offset = doe_mb->cap_offset;
+ int rc;
+
+ /*
+ * Enabling bus mastering is required for MSI/MSIx. It is safe to call
+ * this multiple times and thus is called here to ensure that mastering
+ * is enabled even if the driver has done so.
+ */
+ pci_set_master(pdev);
+ rc = pci_request_irq(pdev, irq, pci_doe_irq_handler, NULL, doe_mb,
+ "DOE[%d:%s]", irq, pci_name(pdev));
+ if (rc)
+ return rc;
+
+ doe_mb->irq = irq;
+ pci_write_config_dword(pdev, offset + PCI_DOE_CTRL,
+ PCI_DOE_CTRL_INT_EN);
+ return 0;
+}
+
+static void pci_doe_free_mb(struct pci_doe_mb *doe_mb)
+{
+ if (doe_mb->irq >= 0)
+ pci_free_irq(doe_mb->pdev, doe_mb->irq, doe_mb);
+ kfree(doe_mb->prots);
+ kfree(doe_mb);
+}
+
+/**
+ * pci_doe_get_irq_num() - Return the irq number for the mailbox at offset
+ *
+ * @pdev: The PCI device
+ * @offset: Offset of the DOE mailbox
+ *
+ * Returns: irq number on success
+ * -errno if irqs are not supported on this mailbox
+ */
+int pci_doe_get_irq_num(struct pci_dev *pdev, int offset)
+{
+ u32 val;
+
+ pci_read_config_dword(pdev, offset + PCI_DOE_CAP, &val);
+ if (!FIELD_GET(PCI_DOE_CAP_INT, val))
+ return -EOPNOTSUPP;
+
+ return FIELD_GET(PCI_DOE_CAP_IRQ, val);
+}
+EXPORT_SYMBOL_GPL(pci_doe_get_irq_num);
+
+/**
+ * pci_doe_create_mb() - Create a DOE mailbox object
+ *
+ * @pdev: PCI device to create the DOE mailbox for
+ * @cap_offset: Offset of the DOE mailbox
+ * @irq: irq number to use; a negative value means don't use interrupts
+ *
+ * Create a single mailbox object to manage the mailbox protocol at the
+ * cap_offset specified.
+ *
+ * Caller should allocate PCI IRQ vectors before setting use_irq.
+ *
+ * RETURNS: created mailbox object on success
+ * ERR_PTR(-errno) on failure
+ */
+struct pci_doe_mb *pci_doe_create_mb(struct pci_dev *pdev, u16 cap_offset,
+ int irq)
+{
+ struct pci_doe_mb *doe_mb;
+ int rc;
+
+ doe_mb = kzalloc(sizeof(*doe_mb), GFP_KERNEL);
+ if (!doe_mb)
+ return ERR_PTR(-ENOMEM);
+
+ doe_mb->pdev = pdev;
+ init_completion(&doe_mb->abort_c);
+ doe_mb->irq = -1;
+ doe_mb->cap_offset = cap_offset;
+
+ init_waitqueue_head(&doe_mb->wq);
+ spin_lock_init(&doe_mb->task_lock);
+ INIT_DELAYED_WORK(&doe_mb->statemachine, doe_statemachine_work);
+ doe_mb->state = DOE_IDLE;
+
+ if (irq >= 0) {
+ rc = pci_doe_enable_irq(doe_mb, irq);
+ if (rc)
+ pci_err(pdev,
+ "DOE [%x] enable requested IRQ (%d) failed : %d\n",
+ doe_mb->cap_offset, irq, rc);
+ }
+
+ /* Reset the mailbox by issuing an abort */
+ rc = pci_doe_abort(doe_mb);
+ if (rc) {
+ pci_err(pdev, "DOE [%x] failed to reset : %d\n",
+ doe_mb->cap_offset, rc);
+ pci_doe_free_mb(doe_mb);
+ return ERR_PTR(rc);
+ }
+
+ rc = pci_doe_cache_protocols(doe_mb);
+ if (rc) {
+ pci_err(pdev, "DOE [%x] failed to cache protocols : %d\n",
+ doe_mb->cap_offset, rc);
+ pci_doe_free_mb(doe_mb);
+ return ERR_PTR(rc);
+ }
+
+ return doe_mb;
+}
+EXPORT_SYMBOL_GPL(pci_doe_create_mb);
+
+/**
+ * pci_doe_supports_prot() - Return if the DOE instance supports the given
+ * protocol
+ * @doe_mb: DOE mailbox capability to query
+ * @vid: Protocol Vendor ID
+ * @type: Protocol type
+ *
+ * RETURNS: True if the DOE mailbox supports the protocol specified
+ */
+bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type)
+{
+ int i;
+
+ /* The discovery protocol must always be supported */
+ if (vid == PCI_VENDOR_ID_PCI_SIG && type == PCI_DOE_PROTOCOL_DISCOVERY)
+ return true;
+
+ for (i = 0; i < doe_mb->num_prots; i++)
+ if ((doe_mb->prots[i].vid == vid) &&
+ (doe_mb->prots[i].type == type))
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(pci_doe_supports_prot);
+
+/**
+ * pci_doe_submit_task() - Submit a task to be processed by the state machine
+ *
+ * @doe_mb: DOE mailbox capability to submit to
+ * @task: task to be queued
+ *
+ * Submit a DOE task (request/response) to the DOE mailbox to be processed.
+ * Returns upon queueing the task object. If the queue is full this function
+ * will sleep until there is room in the queue.
+ *
+ * task->complete will be called when the state machine is done processing this
+ * task.
+ *
+ * Excess data will be discarded.
+ *
+ * RETURNS: 0 when task has been successful queued, -ERRNO on error
+ */
+int pci_doe_submit_task(struct pci_doe_mb *doe_mb, struct pci_doe_task *task)
+{
+ if (!pci_doe_supports_prot(doe_mb, task->prot.vid, task->prot.type))
+ return -EINVAL;
+
+ /* DOE requests must be a whole number of DW */
+ if (task->request_pl_sz % sizeof(u32))
+ return -EINVAL;
+
+again:
+ spin_lock(&doe_mb->task_lock);
+ if (doe_mb->cur_task) {
+ spin_unlock(&doe_mb->task_lock);
+ wait_event_interruptible(doe_mb->wq, doe_mb->cur_task == NULL);
+ goto again;
+ }
+
+ if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags)) {
+ spin_unlock(&doe_mb->task_lock);
+ return -EIO;
+ }
+ doe_mb->cur_task = task;
+ spin_unlock(&doe_mb->task_lock);
+ schedule_delayed_work(&doe_mb->statemachine, 0);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pci_doe_submit_task);
+
+/**
+ * pci_doe_destroy_mb() - Destroy a DOE mailbox object created with
+ * pci_doe_create_mb()
+ *
+ * @doe_mb: DOE mailbox capability structure to destroy
+ *
+ * The mailbox becomes invalid and should not be used after this call.
+ */
+void pci_doe_destroy_mb(struct pci_doe_mb *doe_mb)
+{
+ /* abort any work in progress */
+ pci_doe_abort(doe_mb);
+
+ /* halt the state machine */
+ cancel_delayed_work_sync(&doe_mb->statemachine);
+
+ pci_doe_free_mb(doe_mb);
+}
+EXPORT_SYMBOL_GPL(pci_doe_destroy_mb);
diff --git a/include/linux/pci-doe.h b/include/linux/pci-doe.h
new file mode 100644
index 000000000000..4623881d0e3e
--- /dev/null
+++ b/include/linux/pci-doe.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Data Object Exchange
+ * PCIe r6.0, sec 6.30 DOE
+ *
+ * Copyright (C) 2021 Huawei
+ * Jonathan Cameron <Jonathan.Cameron@huawei.com>
+ *
+ * Copyright (C) 2022 Intel Corporation
+ * Ira Weiny <ira.weiny@intel.com>
+ */
+
+#ifndef LINUX_PCI_DOE_H
+#define LINUX_PCI_DOE_H
+
+#include <linux/completion.h>
+
+struct pci_doe_protocol {
+ u16 vid;
+ u8 type;
+};
+
+/**
+ * struct pci_doe_task - represents a single query/response
+ *
+ * @prot: DOE Protocol
+ * @request_pl: The request payload
+ * @request_pl_sz: Size of the request payload
+ * @response_pl: The response payload
+ * @response_pl_sz: Size of the response payload
+ * @rv: Return value. Length of received response or error
+ * @complete: Called when task is complete
+ * @private: Private data for the consumer
+ */
+struct pci_doe_task {
+ struct pci_doe_protocol prot;
+ u32 *request_pl;
+ size_t request_pl_sz;
+ u32 *response_pl;
+ size_t response_pl_sz;
+ int rv;
+ void (*complete)(struct pci_doe_task *task);
+ void *private;
+};
+
+/**
+ * pci_doe_for_each_off - Iterate each DOE capability
+ * @pdev: struct pci_dev to iterate
+ * @off: u16 of config space offset of each mailbox capability found
+ */
+#define pci_doe_for_each_off(pdev, off) \
+ for (off = pci_find_next_ext_capability(pdev, off, \
+ PCI_EXT_CAP_ID_DOE); \
+ off > 0; \
+ off = pci_find_next_ext_capability(pdev, off, \
+ PCI_EXT_CAP_ID_DOE))
+
+int pci_doe_get_irq_num(struct pci_dev *pdev, int offset);
+struct pci_doe_mb *pci_doe_create_mb(struct pci_dev *pdev, u16 cap_offset,
+ int irq);
+void pci_doe_destroy_mb(struct pci_doe_mb *doe_mb);
+bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type);
+int pci_doe_submit_task(struct pci_doe_mb *doe_mb, struct pci_doe_task *task);
+
+#endif
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index bee1a9ed6e66..4e96b45ee36d 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -736,7 +736,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
@@ -1102,4 +1103,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.35.1
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices
2022-06-10 20:22 [PATCH V11 0/8] CXL: Read CDAT and DSMAS data ira.weiny
` (2 preceding siblings ...)
2022-06-10 20:22 ` [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes ira.weiny
@ 2022-06-10 20:22 ` ira.weiny
2022-06-17 20:40 ` [PATCH v11 " Davidlohr Bueso
` (2 more replies)
2022-06-10 20:22 ` [PATCH V11 5/8] cxl/port: Read CDAT table ira.weiny
` (3 subsequent siblings)
7 siblings, 3 replies; 44+ messages in thread
From: ira.weiny @ 2022-06-10 20:22 UTC (permalink / raw)
To: Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Ben Widawsky, Alison Schofield, Vishal Verma,
Dave Jiang, linux-kernel, linux-cxl, linux-pci
From: Ira Weiny <ira.weiny@intel.com>
DOE mailbox objects will be needed for various mailbox communications
with each memory device.
Iterate each DOE mailbox capability and create PCI DOE mailbox objects
as found.
It is not anticipated that this is the final resting place for the
iteration of the DOE devices. The support of ports may drive this code
into the pcie side. In this imagined architecture the CXL port driver
would then query into the PCI device for the DOE mailbox array.
For now this is good enough for the endpoints and the split is similar
to the envisioned architecture where getting the mailbox array is
separated from the various protocol needs. For example, it is not
anticipated that the CDAT code will need to move because it is only
needed by the cxl_ports.
Likewise irq's are separated out in a similar design pattern to the
PCIe port driver. But a much simpler irq enabling flag is used and only
DOE interrupts are supported.
Reviewed-by: Ben Widawsky <bwidawsk@kernel.org>
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
Changes from V9:
Bug fix: ensure DOE mailboxes are iterated before memdev add
Ben Widawsky
Set use_irq to false and just return on error.
Don't return a value from devm_cxl_pci_create_doe()
Skip allocating doe_mb array if there are no mailboxes
Skip requesting irqs if none found.
Ben/Jonathan Cameron
s/num_irqs/max_irqs
Changes from V8:
Move PCI_DOE selection to CXL_BUS to support future patches
which move queries into the port code.
Remove Auxiliary device arch
Squash the functionality of the auxiliary driver into this
patch.
Split out the irq handling a bit.
Changes from V7:
Minor code clean ups
Rebased on cxl-pending
Changes from V6:
Move all the auxiliary device stuff to the CXL layer
Changes from V5:
Split the CXL specific stuff off from the PCI DOE create
auxiliary device code.
---
drivers/cxl/Kconfig | 1 +
drivers/cxl/cxlmem.h | 6 +++
drivers/cxl/pci.c | 114 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 121 insertions(+)
diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index f64e3984689f..7adaaf80b302 100644
--- a/drivers/cxl/Kconfig
+++ b/drivers/cxl/Kconfig
@@ -2,6 +2,7 @@
menuconfig CXL_BUS
tristate "CXL (Compute Express Link) Devices Support"
depends on PCI
+ select PCI_DOE
help
CXL is a bus that is electrically compatible with PCI Express, but
layers three protocols on that signalling (CXL.io, CXL.cache, and
diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
index 60d10ee1e7fc..4d2764b865ab 100644
--- a/drivers/cxl/cxlmem.h
+++ b/drivers/cxl/cxlmem.h
@@ -191,6 +191,8 @@ struct cxl_endpoint_dvsec_info {
* @component_reg_phys: register base of component registers
* @info: Cached DVSEC information about the device.
* @serial: PCIe Device Serial Number
+ * @doe_mbs: PCI DOE mailbox array
+ * @num_mbs: Number of DOE mailboxes
* @mbox_send: @dev specific transport for transmitting mailbox commands
*
* See section 8.2.9.5.2 Capacity Configuration and Label Storage for
@@ -224,6 +226,10 @@ struct cxl_dev_state {
resource_size_t component_reg_phys;
u64 serial;
+ bool doe_use_irq;
+ struct pci_doe_mb **doe_mbs;
+ int num_mbs;
+
int (*mbox_send)(struct cxl_dev_state *cxlds, struct cxl_mbox_cmd *cmd);
};
diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
index 5a0ae46d4989..72c7b535f5df 100644
--- a/drivers/cxl/pci.c
+++ b/drivers/cxl/pci.c
@@ -8,6 +8,7 @@
#include <linux/mutex.h>
#include <linux/list.h>
#include <linux/pci.h>
+#include <linux/pci-doe.h>
#include <linux/io.h>
#include "cxlmem.h"
#include "cxlpci.h"
@@ -386,6 +387,116 @@ static int cxl_setup_regs(struct pci_dev *pdev, enum cxl_regloc_type type,
return rc;
}
+static void cxl_pci_free_irq_vectors(void *data)
+{
+ pci_free_irq_vectors(data);
+}
+
+static void cxl_doe_destroy_mb(void *ds)
+{
+ struct cxl_dev_state *cxlds = ds;
+ int i;
+
+ for (i = 0; i < cxlds->num_mbs; i++) {
+ if (cxlds->doe_mbs[i])
+ pci_doe_destroy_mb(cxlds->doe_mbs[i]);
+ }
+}
+
+static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
+{
+ struct device *dev = cxlds->dev;
+ struct pci_dev *pdev = to_pci_dev(dev);
+ int max_irqs = 0;
+ int off = 0;
+ int rc;
+
+ /* Account for all the DOE vectors needed */
+ pci_doe_for_each_off(pdev, off) {
+ int irq = pci_doe_get_irq_num(pdev, off);
+
+ if (irq < 0)
+ continue;
+ max_irqs = max(max_irqs, irq + 1);
+ }
+
+ if (!max_irqs)
+ return;
+
+ cxlds->doe_use_irq = false;
+
+ /*
+ * Allocate enough vectors for the DOE's
+ */
+ rc = pci_alloc_irq_vectors(pdev, max_irqs, max_irqs, PCI_IRQ_MSI |
+ PCI_IRQ_MSIX);
+ if (rc != max_irqs) {
+ pci_err(pdev, "Not enough interrupts; use polling\n");
+ /* Some got allocated; clean them up */
+ if (rc > 0)
+ cxl_pci_free_irq_vectors(pdev);
+ return;
+ }
+
+ rc = devm_add_action_or_reset(dev, cxl_pci_free_irq_vectors, pdev);
+ if (rc)
+ return;
+
+ cxlds->doe_use_irq = true;
+}
+
+/**
+ * devm_cxl_pci_create_doe - Scan and set up DOE mailboxes
+ *
+ * @cxlds: The CXL device state
+ */
+static void devm_cxl_pci_create_doe(struct cxl_dev_state *cxlds)
+{
+ struct device *dev = cxlds->dev;
+ struct pci_dev *pdev = to_pci_dev(dev);
+ u16 off = 0;
+ int num_mbs = 0;
+ int rc;
+
+ pci_doe_for_each_off(pdev, off)
+ num_mbs++;
+
+ if (!num_mbs) {
+ pci_dbg(pdev, "0 DOE mailbox's found\n");
+ return;
+ }
+
+ cxlds->doe_mbs = devm_kcalloc(dev, num_mbs, sizeof(*cxlds->doe_mbs),
+ GFP_KERNEL);
+ if (!cxlds->doe_mbs)
+ return;
+
+ pci_doe_for_each_off(pdev, off) {
+ struct pci_doe_mb *doe_mb;
+ int irq = -1;
+
+ if (cxlds->doe_use_irq)
+ irq = pci_doe_get_irq_num(pdev, off);
+
+ doe_mb = pci_doe_create_mb(pdev, off, irq);
+ if (IS_ERR(doe_mb)) {
+ pci_err(pdev,
+ "Failed to create MB object for MB @ %x\n",
+ off);
+ doe_mb = NULL;
+ }
+
+ cxlds->doe_mbs[cxlds->num_mbs] = doe_mb;
+ cxlds->num_mbs++;
+ }
+
+ rc = devm_add_action_or_reset(dev, cxl_doe_destroy_mb, cxlds);
+ if (rc)
+ return;
+
+ pci_info(pdev, "Configured %d DOE mailbox's\n", cxlds->num_mbs);
+}
+
static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct cxl_register_map map;
@@ -434,6 +545,9 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
cxlds->component_reg_phys = cxl_regmap_to_base(pdev, &map);
+ cxl_alloc_irq_vectors(cxlds);
+ devm_cxl_pci_create_doe(cxlds);
+
rc = cxl_pci_setup_mailbox(cxlds);
if (rc)
return rc;
--
2.35.1
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH V11 5/8] cxl/port: Read CDAT table
2022-06-10 20:22 [PATCH V11 0/8] CXL: Read CDAT and DSMAS data ira.weiny
` (3 preceding siblings ...)
2022-06-10 20:22 ` [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices ira.weiny
@ 2022-06-10 20:22 ` ira.weiny
2022-06-18 0:43 ` Dan Williams
2022-06-10 20:22 ` [PATCH V11 6/8] cxl/port: Introduce cxl_cdat_valid() ira.weiny
` (2 subsequent siblings)
7 siblings, 1 reply; 44+ messages in thread
From: ira.weiny @ 2022-06-10 20:22 UTC (permalink / raw)
To: Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Alison Schofield, Vishal Verma, Dave Jiang,
Ben Widawsky, linux-kernel, linux-cxl, linux-pci
From: Ira Weiny <ira.weiny@intel.com>
The OS will need CDAT data from CXL devices to properly set up
interleave sets. Currently this is supported through a DOE mailbox
which supports CDAT.
Search the DOE mailboxes available, query CDAT data, and cache the data
for later parsing.
Provide a sysfs binary attribute to allow dumping of the CDAT.
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.
This does not support table updates at runtime. It will always provide
whatever was there when first cached. Handling of table updates can be
implemented later.
Finally create a complete list of CDAT defines within cdat.h for code
wishing to decode the CDAT table.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Co-developed-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
Changes from V10:
Ben Widawsky
Failure to find CDAT should be a debug message not error
Remove reference to cdat_mb from the port object
Dropped [PATCH V10 5/9] cxl/port: Find a DOE mailbox which supports
CDAT
Iterate the mailboxes for the CDAT one each time.
Define CXL_DOE_TABLE_ACCESS_LAST_ENTRY and add comment about
it's use.
Changes from V9:
Add debugging output
Jonathan Cameron
Move read_cdat to port probe by using dev_groups for the
sysfs attributes. This avoids issues with using devm
before the driver is loaded while making sure the CDAT
binary is available.
Changes from V8:
Fix length print format
Incorporate feedback from Jonathan
Move all this to cxl_port which can help support switches when
the time comes.
Changes from V6:
Fix issue with devm use
Move cached cdat data to cxl_dev_state
Use new pci_doe_submit_task()
Ensure the aux driver is locked while processing tasks
Rebased on cxl-pending
Changes from V5:
Add proper guards around cdat.h
Split out finding the CDAT DOE mailbox
Use cxl_cdat to group CDAT data together
Adjust to use auxiliary_find_device() to find the DOE device
which supplies the CDAT protocol.
Rebased to latest
Remove dev_dbg(length)
Remove unneeded DOE Table access defines
Move CXL_DOE_PROTOCOL_TABLE_ACCESS define into this patch where
it is used
Changes from V4:
Split this into it's own patch
Rearchitect this such that the memdev driver calls into the DOE
driver via the cxl_mem state object. This allows CDAT data to
come from any type of cxl_mem object not just PCI DOE.
Rebase on new struct cxl_dev_state
---
drivers/cxl/cdat.h | 100 ++++++++++++++++++++++++
drivers/cxl/core/pci.c | 172 +++++++++++++++++++++++++++++++++++++++++
drivers/cxl/cxl.h | 3 +
drivers/cxl/cxlpci.h | 1 +
drivers/cxl/port.c | 51 ++++++++++++
5 files changed, 327 insertions(+)
create mode 100644 drivers/cxl/cdat.h
diff --git a/drivers/cxl/cdat.h b/drivers/cxl/cdat.h
new file mode 100644
index 000000000000..c6a48ab326bf
--- /dev/null
+++ b/drivers/cxl/cdat.h
@@ -0,0 +1,100 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __CXL_CDAT_H__
+#define __CXL_CDAT_H__
+
+/*
+ * 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
+#define CXL_DOE_TABLE_ACCESS_LAST_ENTRY 0xffff
+
+/*
+ * 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 4
+#define CDAT_HEADER_LENGTH_BYTES (CDAT_HEADER_LENGTH_DW * sizeof(u32))
+#define CDAT_HEADER_DW0_LENGTH 0xffffffff
+#define CDAT_HEADER_DW1_REVISION 0x000000ff
+#define CDAT_HEADER_DW1_CHECKSUM 0x0000ff00
+/* CDAT_HEADER_DW2_RESERVED */
+#define CDAT_HEADER_DW3_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])
+#define CDAT_DSMAS_NON_VOLATILE(flags) ((flags & 0x04) >> 2)
+
+/* 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)
+
+#define CXL_DOE_PROTOCOL_TABLE_ACCESS 2
+
+/**
+ * struct cxl_cdat - CXL CDAT data
+ *
+ * @table: cache of CDAT table
+ * @length: length of cached CDAT table
+ */
+struct cxl_cdat {
+ void *table;
+ size_t length;
+};
+
+#endif /* !__CXL_CDAT_H__ */
diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
index c4c99ff7b55e..84dc82f7dff0 100644
--- a/drivers/cxl/core/pci.c
+++ b/drivers/cxl/core/pci.c
@@ -4,10 +4,12 @@
#include <linux/device.h>
#include <linux/delay.h>
#include <linux/pci.h>
+#include <linux/pci-doe.h>
#include <cxlpci.h>
#include <cxlmem.h>
#include <cxl.h>
#include "core.h"
+#include "cdat.h"
/**
* DOC: cxl core pci
@@ -458,3 +460,173 @@ int cxl_hdm_decode_init(struct cxl_dev_state *cxlds, struct cxl_hdm *cxlhdm)
return 0;
}
EXPORT_SYMBOL_NS_GPL(cxl_hdm_decode_init, CXL);
+
+static struct pci_doe_mb *find_cdat_mb(struct device *uport)
+{
+ struct cxl_memdev *cxlmd;
+ struct cxl_dev_state *cxlds;
+ int i;
+
+ if (!is_cxl_memdev(uport))
+ return NULL;
+
+ cxlmd = to_cxl_memdev(uport);
+ cxlds = cxlmd->cxlds;
+
+ for (i = 0; i < cxlds->num_mbs; i++) {
+ struct pci_doe_mb *cur = cxlds->doe_mbs[i];
+
+ if (pci_doe_supports_prot(cur, PCI_DVSEC_VENDOR_ID_CXL,
+ CXL_DOE_PROTOCOL_TABLE_ACCESS))
+ return cur;
+ }
+
+ return NULL;
+}
+
+#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 void cxl_doe_task_complete(struct pci_doe_task *task)
+{
+ complete(task->private);
+}
+
+static int cxl_cdat_get_length(struct device *dev,
+ struct pci_doe_mb *cdat_mb,
+ size_t *length)
+{
+ u32 cdat_request_pl = CDAT_DOE_REQ(0);
+ u32 cdat_response_pl[32];
+ DECLARE_COMPLETION_ONSTACK(c);
+ struct pci_doe_task task = {
+ .prot.vid = PCI_DVSEC_VENDOR_ID_CXL,
+ .prot.type = 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),
+ .complete = cxl_doe_task_complete,
+ .private = &c,
+ };
+ int rc = 0;
+
+ rc = pci_doe_submit_task(cdat_mb, &task);
+ if (rc < 0) {
+ dev_err(dev, "DOE submit failed: %d", rc);
+ return rc;
+ }
+ wait_for_completion(&c);
+
+ if (task.rv < 1)
+ return -EIO;
+
+ *length = cdat_response_pl[1];
+ dev_dbg(dev, "CDAT length %zu\n", *length);
+
+ return rc;
+}
+
+static int cxl_cdat_read_table(struct device *dev,
+ struct pci_doe_mb *cdat_mb,
+ struct cxl_cdat *cdat)
+{
+ size_t length = cdat->length;
+ u32 *data = cdat->table;
+ int entry_handle = 0;
+ int rc = 0;
+
+ do {
+ u32 cdat_request_pl = CDAT_DOE_REQ(entry_handle);
+ u32 cdat_response_pl[32];
+ DECLARE_COMPLETION_ONSTACK(c);
+ struct pci_doe_task task = {
+ .prot.vid = PCI_DVSEC_VENDOR_ID_CXL,
+ .prot.type = 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),
+ .complete = cxl_doe_task_complete,
+ .private = &c,
+ };
+ size_t entry_dw;
+ u32 *entry;
+
+ rc = pci_doe_submit_task(cdat_mb, &task);
+ if (rc < 0) {
+ dev_err(dev, "DOE submit failed: %d", rc);
+ return rc;
+ }
+ wait_for_completion(&c);
+
+ /* Get the CXL table access header entry handle */
+ entry_handle = FIELD_GET(CXL_DOE_TABLE_ACCESS_ENTRY_HANDLE,
+ cdat_response_pl[0]);
+ entry = cdat_response_pl + 1;
+ entry_dw = task.rv / sizeof(u32);
+ /* Skip Header */
+ entry_dw -= 1;
+ entry_dw = min(length / 4, entry_dw);
+ memcpy(data, entry, entry_dw * sizeof(u32));
+ length -= entry_dw * sizeof(u32);
+ data += entry_dw;
+
+ } while (entry_handle != CXL_DOE_TABLE_ACCESS_LAST_ENTRY);
+
+ return rc;
+}
+
+/**
+ * read_cdat_data - Read the CDAT data on this port
+ * @port: Port to read data from
+ *
+ * This call will sleep waiting for responses from the DOE mailbox.
+ */
+void read_cdat_data(struct cxl_port *port)
+{
+ static struct pci_doe_mb *cdat_mb;
+ struct device *dev = &port->dev;
+ struct device *uport = port->uport;
+ size_t cdat_length;
+ int ret;
+
+ /*
+ * Ensure a reference on the underlying uport device which has the
+ * mailboxes in it
+ */
+ get_device(uport);
+
+ cdat_mb = find_cdat_mb(uport);
+ if (!cdat_mb) {
+ dev_dbg(dev, "No CDAT mailbox\n");
+ goto out;
+ }
+
+ if (cxl_cdat_get_length(dev, cdat_mb, &cdat_length)) {
+ dev_dbg(dev, "No CDAT length\n");
+ goto out;
+ }
+
+ port->cdat.table = devm_kzalloc(dev, cdat_length, GFP_KERNEL);
+ if (!port->cdat.table)
+ goto out;
+
+ port->cdat.length = cdat_length;
+ ret = cxl_cdat_read_table(dev, cdat_mb, &port->cdat);
+ if (ret) {
+ /* Don't leave table data allocated on error */
+ devm_kfree(dev, port->cdat.table);
+ port->cdat.table = NULL;
+ port->cdat.length = 0;
+ dev_err(dev, "CDAT data read error\n");
+ }
+
+out:
+ put_device(uport);
+}
+EXPORT_SYMBOL_NS_GPL(read_cdat_data, CXL);
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index 140dc3278cde..f0f5c24789bc 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -8,6 +8,7 @@
#include <linux/bitfield.h>
#include <linux/bitops.h>
#include <linux/io.h>
+#include "cdat.h"
/**
* DOC: cxl objects
@@ -267,6 +268,7 @@ struct cxl_nvdimm {
* @component_reg_phys: component register capability base address (optional)
* @dead: last ep has been removed, force port re-creation
* @depth: How deep this port is relative to the root. depth 0 is the root.
+ * @cdat: Cached CDAT data
*/
struct cxl_port {
struct device dev;
@@ -278,6 +280,7 @@ struct cxl_port {
resource_size_t component_reg_phys;
bool dead;
unsigned int depth;
+ struct cxl_cdat cdat;
};
/**
diff --git a/drivers/cxl/cxlpci.h b/drivers/cxl/cxlpci.h
index fce1c11729c2..eec597dbe763 100644
--- a/drivers/cxl/cxlpci.h
+++ b/drivers/cxl/cxlpci.h
@@ -74,4 +74,5 @@ static inline resource_size_t cxl_regmap_to_base(struct pci_dev *pdev,
int devm_cxl_port_enumerate_dports(struct cxl_port *port);
struct cxl_dev_state;
int cxl_hdm_decode_init(struct cxl_dev_state *cxlds, struct cxl_hdm *cxlhdm);
+void read_cdat_data(struct cxl_port *port);
#endif /* __CXL_PCI_H__ */
diff --git a/drivers/cxl/port.c b/drivers/cxl/port.c
index 3cf308f114c4..7881ce66a5de 100644
--- a/drivers/cxl/port.c
+++ b/drivers/cxl/port.c
@@ -49,6 +49,9 @@ static int cxl_port_probe(struct device *dev)
if (IS_ERR(cxlhdm))
return PTR_ERR(cxlhdm);
+ /* Cache the data early to ensure is_visible() works */
+ read_cdat_data(port);
+
if (is_cxl_endpoint(port)) {
struct cxl_memdev *cxlmd = to_cxl_memdev(port->uport);
struct cxl_dev_state *cxlds = cxlmd->cxlds;
@@ -78,10 +81,58 @@ static int cxl_port_probe(struct device *dev)
return 0;
}
+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_port *port = to_cxl_port(dev);
+
+ if (!port->cdat.table)
+ return 0;
+
+ return memory_read_from_buffer(buf, count, &offset,
+ port->cdat.table,
+ port->cdat.length);
+}
+
+static BIN_ATTR_RO(cdat, 0);
+
+static umode_t cxl_port_bin_attr_is_visible(struct kobject *kobj,
+ struct bin_attribute *attr, int i)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct cxl_port *port = to_cxl_port(dev);
+
+ if ((attr == &bin_attr_cdat) && port->cdat.table)
+ return 0400;
+
+ return 0;
+}
+
+static struct bin_attribute *cxl_cdat_bin_attributes[] = {
+ &bin_attr_cdat,
+ NULL,
+};
+
+static struct attribute_group cxl_cdat_attribute_group = {
+ .name = "CDAT",
+ .bin_attrs = cxl_cdat_bin_attributes,
+ .is_bin_visible = cxl_port_bin_attr_is_visible,
+};
+
+static const struct attribute_group *cxl_port_attribute_groups[] = {
+ &cxl_cdat_attribute_group,
+ NULL,
+};
+
static struct cxl_driver cxl_port_driver = {
.name = "cxl_port",
.probe = cxl_port_probe,
.id = CXL_DEVICE_PORT,
+ .drv = {
+ .dev_groups = cxl_port_attribute_groups,
+ },
};
module_cxl_driver(cxl_port_driver);
--
2.35.1
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH V11 6/8] cxl/port: Introduce cxl_cdat_valid()
2022-06-10 20:22 [PATCH V11 0/8] CXL: Read CDAT and DSMAS data ira.weiny
` (4 preceding siblings ...)
2022-06-10 20:22 ` [PATCH V11 5/8] cxl/port: Read CDAT table ira.weiny
@ 2022-06-10 20:22 ` ira.weiny
2022-06-10 20:22 ` [PATCH V11 7/8] cxl/port: Retry reading CDAT on failure ira.weiny
2022-06-10 20:22 ` [PATCH V11 8/8] cxl/port: Parse out DSMAS data from CDAT table ira.weiny
7 siblings, 0 replies; 44+ messages in thread
From: ira.weiny @ 2022-06-10 20:22 UTC (permalink / raw)
To: Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Alison Schofield, Vishal Verma, Dave Jiang,
Ben Widawsky, linux-kernel, linux-cxl, linux-pci
From: Ira Weiny <ira.weiny@intel.com>
The CDAT data is protected by a checksum and should be the proper
length.
Introduce cxl_cdat_valid() to validate the data. While at it check and
store the sequence number.
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
Changes from V8
Move code to cxl/core/pci.c
Changes from V6
Change name to cxl_cdat_valid() as this validates all the CDAT
data not just the header
Add error and debug prints
Changes from V5
New patch, split out
Update cdat_hdr_valid()
Remove revision and cs field parsing
There is no point in these
Add seq check and debug print.
---
drivers/cxl/cdat.h | 2 ++
drivers/cxl/core/pci.c | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/drivers/cxl/cdat.h b/drivers/cxl/cdat.h
index c6a48ab326bf..39eb561081f2 100644
--- a/drivers/cxl/cdat.h
+++ b/drivers/cxl/cdat.h
@@ -91,10 +91,12 @@
*
* @table: cache of CDAT table
* @length: length of cached CDAT table
+ * @seq: Last read Sequence number of the CDAT table
*/
struct cxl_cdat {
void *table;
size_t length;
+ u32 seq;
};
#endif /* !__CXL_CDAT_H__ */
diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
index 84dc82f7dff0..cb70287e2984 100644
--- a/drivers/cxl/core/pci.c
+++ b/drivers/cxl/core/pci.c
@@ -531,6 +531,40 @@ static int cxl_cdat_get_length(struct device *dev,
return rc;
}
+static bool cxl_cdat_valid(struct device *dev, struct cxl_cdat *cdat)
+{
+ u32 *table = cdat->table;
+ u8 *data8 = cdat->table;
+ u32 length, seq;
+ u8 check;
+ int i;
+
+ length = FIELD_GET(CDAT_HEADER_DW0_LENGTH, table[0]);
+ if ((length < CDAT_HEADER_LENGTH_BYTES) || (length > cdat->length)) {
+ dev_err(dev, "CDAT Invalid length %u (%zu-%zu)\n", length,
+ CDAT_HEADER_LENGTH_BYTES, cdat->length);
+ return false;
+ }
+
+ for (check = 0, i = 0; i < length; i++)
+ check += data8[i];
+
+ dev_dbg(dev, "CDAT length %u CS %u\n", length, check);
+ if (check != 0) {
+ dev_err(dev, "CDAT Invalid checksum %u\n", check);
+ return false;
+ }
+
+ seq = FIELD_GET(CDAT_HEADER_DW3_SEQUENCE, table[3]);
+ /* Store the sequence for now. */
+ if (cdat->seq != seq) {
+ dev_info(dev, "CDAT seq change %x -> %x\n", cdat->seq, seq);
+ cdat->seq = seq;
+ }
+
+ return true;
+}
+
static int cxl_cdat_read_table(struct device *dev,
struct pci_doe_mb *cdat_mb,
struct cxl_cdat *cdat)
@@ -578,6 +612,8 @@ static int cxl_cdat_read_table(struct device *dev,
} while (entry_handle != CXL_DOE_TABLE_ACCESS_LAST_ENTRY);
+ if (!rc && !cxl_cdat_valid(dev, cdat))
+ return -EIO;
return rc;
}
--
2.35.1
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH V11 7/8] cxl/port: Retry reading CDAT on failure
2022-06-10 20:22 [PATCH V11 0/8] CXL: Read CDAT and DSMAS data ira.weiny
` (5 preceding siblings ...)
2022-06-10 20:22 ` [PATCH V11 6/8] cxl/port: Introduce cxl_cdat_valid() ira.weiny
@ 2022-06-10 20:22 ` ira.weiny
2022-06-28 3:32 ` Alison Schofield
2022-06-10 20:22 ` [PATCH V11 8/8] cxl/port: Parse out DSMAS data from CDAT table ira.weiny
7 siblings, 1 reply; 44+ messages in thread
From: ira.weiny @ 2022-06-10 20:22 UTC (permalink / raw)
To: Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Ben Widawsky, Alison Schofield, Vishal Verma,
Dave Jiang, linux-kernel, linux-cxl, linux-pci
From: Ira Weiny <ira.weiny@intel.com>
The CDAT read may fail for a number of reasons but mainly it is possible
to get different parts of a valid state. The checksum in the CDAT table
protects against this.
Now that the cdat data is validated, issue a retry if the CDAT read
fails. For now 5 retries are implemented.
Reviewed-by: Ben Widawsky <bwidawsk@kernel.org>
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
Changes from V10
Pick up review tag and fix commit message
Changes from V9
Alison Schofield/Davidlohr Bueso
Print debug on each iteration and error only after failure
Changes from V8
Move code to cxl/core/pci.c
Changes from V6
Move to pci.c
Fix retries count
Change to 5 retries
Changes from V5:
New patch -- easy to push off or drop.
---
drivers/cxl/core/pci.c | 40 +++++++++++++++++++++++++++++++---------
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
index cb70287e2984..fd02bc7c0d97 100644
--- a/drivers/cxl/core/pci.c
+++ b/drivers/cxl/core/pci.c
@@ -617,19 +617,13 @@ static int cxl_cdat_read_table(struct device *dev,
return rc;
}
-/**
- * read_cdat_data - Read the CDAT data on this port
- * @port: Port to read data from
- *
- * This call will sleep waiting for responses from the DOE mailbox.
- */
-void read_cdat_data(struct cxl_port *port)
+static int __read_cdat_data(struct cxl_port *port)
{
static struct pci_doe_mb *cdat_mb;
struct device *dev = &port->dev;
struct device *uport = port->uport;
size_t cdat_length;
- int ret;
+ int ret = 0;
/*
* Ensure a reference on the underlying uport device which has the
@@ -640,17 +634,21 @@ void read_cdat_data(struct cxl_port *port)
cdat_mb = find_cdat_mb(uport);
if (!cdat_mb) {
dev_dbg(dev, "No CDAT mailbox\n");
+ ret = -EIO;
goto out;
}
if (cxl_cdat_get_length(dev, cdat_mb, &cdat_length)) {
dev_dbg(dev, "No CDAT length\n");
+ ret = -EIO;
goto out;
}
port->cdat.table = devm_kzalloc(dev, cdat_length, GFP_KERNEL);
- if (!port->cdat.table)
+ if (!port->cdat.table) {
+ ret = -ENOMEM;
goto out;
+ }
port->cdat.length = cdat_length;
ret = cxl_cdat_read_table(dev, cdat_mb, &port->cdat);
@@ -664,5 +662,29 @@ void read_cdat_data(struct cxl_port *port)
out:
put_device(uport);
+ return ret;
+}
+
+/**
+ * read_cdat_data - Read the CDAT data on this port
+ * @port: Port to read data from
+ *
+ * This call will sleep waiting for responses from the DOE mailbox.
+ */
+void read_cdat_data(struct cxl_port *port)
+{
+ int retries = 5;
+ int rc;
+
+ while (retries--) {
+ rc = __read_cdat_data(port);
+ if (!rc)
+ return;
+ dev_dbg(&port->dev,
+ "CDAT data read error rc=%d (retries %d)\n",
+ rc, retries);
+ }
+ dev_err(&port->dev, "CDAT data read failed after %d retries\n",
+ retries);
}
EXPORT_SYMBOL_NS_GPL(read_cdat_data, CXL);
--
2.35.1
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH V11 8/8] cxl/port: Parse out DSMAS data from CDAT table
2022-06-10 20:22 [PATCH V11 0/8] CXL: Read CDAT and DSMAS data ira.weiny
` (6 preceding siblings ...)
2022-06-10 20:22 ` [PATCH V11 7/8] cxl/port: Retry reading CDAT on failure ira.weiny
@ 2022-06-10 20:22 ` ira.weiny
7 siblings, 0 replies; 44+ messages in thread
From: ira.weiny @ 2022-06-10 20:22 UTC (permalink / raw)
To: Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Alison Schofield, Vishal Verma, Dave Jiang,
Ben Widawsky, linux-kernel, linux-cxl, linux-pci
From: Ira Weiny <ira.weiny@intel.com>
CXL Ports with memory devices attached need the information from the
Device Scoped Memory Affinity Structure (DSMAS). This information is
contained within the CDAT table buffer which is cached in the port
device.
If CDAT data is available, parse and cache DSMAS data from the table.
Store this data in unmarshaled struct dsmas data structures for ease of
use later. Ensure DSMAS headers are not malicious or ill formed so as
to cause buffer overflow errors.
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
Changes from V10
From Ben Widawsky
Check data lengths to protect against malicious devices
Changes from V8
Adjust to the cdat data being in cxl_port
Changes from V7
Rebased on cxl-pending
Changes from V6
Move to port.c
It is not an error if no DSMAS data is found
Changes from V5
Fix up sparse warnings
Split out cdat_hdr_valid()
Update cdat_hdr_valid()
Remove revision and cs field parsing
There is no point in these
Add seq check and debug print.
From Jonathan
Add spaces around '+' and '/'
use devm_krealloc() for dmas_ary
---
drivers/cxl/cdat.h | 23 ++++++++++++++
drivers/cxl/core/pci.c | 72 ++++++++++++++++++++++++++++++++++++++++++
drivers/cxl/cxl.h | 2 ++
drivers/cxl/cxlmem.h | 4 +++
drivers/cxl/cxlpci.h | 1 +
drivers/cxl/mem.c | 1 +
6 files changed, 103 insertions(+)
diff --git a/drivers/cxl/cdat.h b/drivers/cxl/cdat.h
index 39eb561081f2..ca1f55762416 100644
--- a/drivers/cxl/cdat.h
+++ b/drivers/cxl/cdat.h
@@ -51,6 +51,7 @@
#define CDAT_DSMAS_DPA_OFFSET(entry) ((u64)((entry)[3]) << 32 | (entry)[2])
#define CDAT_DSMAS_DPA_LEN(entry) ((u64)((entry)[5]) << 32 | (entry)[4])
#define CDAT_DSMAS_NON_VOLATILE(flags) ((flags & 0x04) >> 2)
+#define CDAT_DSMAS_ENTRY_SIZE (6 * sizeof(u32))
/* Device Scoped Latency and Bandwidth Information Structure */
#define CDAT_DSLBIS_DW1_HANDLE 0x000000ff
@@ -60,22 +61,26 @@
#define CDAT_DSLBIS_DW4_ENTRY_0 0x0000ffff
#define CDAT_DSLBIS_DW4_ENTRY_1 0xffff0000
#define CDAT_DSLBIS_DW5_ENTRY_2 0x0000ffff
+#define CDAT_DSLBIS_ENTRY_SIZE (6 * sizeof(u32))
/* 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
+#define CDAT_DSMSCIS_ENTRY_SIZE (5 * sizeof(u32))
/* Device Scoped Initiator Structure */
#define CDAT_DSIS_DW1_FLAGS 0x000000ff
#define CDAT_DSIS_DW1_HANDLE 0x0000ff00
+#define CDAT_DSIS_ENTRY_SIZE (2 * sizeof(u32))
/* 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])
+#define CDAT_DSEMTS_ENTRY_SIZE (6 * sizeof(u32))
/* Switch Scoped Latency and Bandwidth Information Structure */
#define CDAT_SSLBIS_DW1_DATA_TYPE 0x000000ff
@@ -83,9 +88,27 @@
#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)
+#define CDAT_SSLBIS_HEADER_SIZE (6 * sizeof(u32))
#define CXL_DOE_PROTOCOL_TABLE_ACCESS 2
+/**
+ * struct cxl_dsmas - host unmarshaled version of DSMAS data
+ *
+ * As defined in the Coherent Device Attribute Table (CDAT) specification this
+ * represents a single DSMAS entry in that table.
+ *
+ * @dpa_base: The lowest Device Physical Address associated with this DSMAD
+ * @length: Length in bytes of this DSMAD
+ * @non_volatile: If set, the memory region represents Non-Volatile memory
+ */
+struct cxl_dsmas {
+ u64 dpa_base;
+ u64 length;
+ /* Flags */
+ u8 non_volatile:1;
+};
+
/**
* struct cxl_cdat - CXL CDAT data
*
diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
index fd02bc7c0d97..68b1a7c5359e 100644
--- a/drivers/cxl/core/pci.c
+++ b/drivers/cxl/core/pci.c
@@ -688,3 +688,75 @@ void read_cdat_data(struct cxl_port *port)
retries);
}
EXPORT_SYMBOL_NS_GPL(read_cdat_data, CXL);
+
+void parse_dsmas(struct cxl_memdev *cxlmd, struct cxl_port *port)
+{
+ struct device *dev = &port->dev;
+ struct cxl_dsmas *dsmas_ary = NULL;
+ u32 *data = port->cdat.table;
+ int bytes_left = port->cdat.length;
+ int nr_dsmas = 0;
+
+ if (!data) {
+ dev_info(dev, "No CDAT data available for DSMAS\n");
+ return;
+ }
+
+ /* Skip header */
+ data += CDAT_HEADER_LENGTH_DW;
+ bytes_left -= CDAT_HEADER_LENGTH_BYTES;
+
+ while (bytes_left > 0) {
+ u32 *cur_rec = data;
+ u8 type = FIELD_GET(CDAT_STRUCTURE_DW0_TYPE, cur_rec[0]);
+ u16 length = FIELD_GET(CDAT_STRUCTURE_DW0_LENGTH, cur_rec[0]);
+
+ if (type == CDAT_STRUCTURE_DW0_TYPE_DSMAS) {
+ struct cxl_dsmas *new_ary;
+ u8 flags;
+
+ /* Protect against malicious devices */
+ if (bytes_left < CDAT_DSMAS_ENTRY_SIZE ||
+ length != CDAT_DSMAS_ENTRY_SIZE) {
+ dev_err(dev, "Invalid DSMAS data detected\n");
+ return;
+ }
+
+ new_ary = devm_krealloc(dev, dsmas_ary,
+ sizeof(*dsmas_ary) * (nr_dsmas + 1),
+ GFP_KERNEL);
+ if (!new_ary) {
+ dev_err(dev,
+ "Failed to allocate memory for DSMAS data (nr_dsmas %d)\n",
+ nr_dsmas);
+ return;
+ }
+ dsmas_ary = new_ary;
+
+ flags = FIELD_GET(CDAT_DSMAS_DW1_FLAGS, cur_rec[1]);
+
+ dsmas_ary[nr_dsmas].dpa_base = CDAT_DSMAS_DPA_OFFSET(cur_rec);
+ dsmas_ary[nr_dsmas].length = CDAT_DSMAS_DPA_LEN(cur_rec);
+ dsmas_ary[nr_dsmas].non_volatile = CDAT_DSMAS_NON_VOLATILE(flags);
+
+ dev_dbg(dev, "DSMAS %d: %llx:%llx %s\n",
+ nr_dsmas,
+ dsmas_ary[nr_dsmas].dpa_base,
+ dsmas_ary[nr_dsmas].dpa_base +
+ dsmas_ary[nr_dsmas].length,
+ (dsmas_ary[nr_dsmas].non_volatile ?
+ "Persistent" : "Volatile")
+ );
+
+ nr_dsmas++;
+ }
+
+ data += (length / sizeof(u32));
+ bytes_left -= length;
+ }
+
+ dev_dbg(dev, "Found %d DSMAS entries\n", nr_dsmas);
+ cxlmd->dsmas_ary = dsmas_ary;
+ cxlmd->nr_dsmas = nr_dsmas;
+}
+EXPORT_SYMBOL_NS_GPL(parse_dsmas, CXL);
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index f0f5c24789bc..bc9237466f33 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -10,6 +10,8 @@
#include <linux/io.h>
#include "cdat.h"
+#include "cdat.h"
+
/**
* DOC: cxl objects
*
diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
index 4d2764b865ab..ce5b00f3ebcb 100644
--- a/drivers/cxl/cxlmem.h
+++ b/drivers/cxl/cxlmem.h
@@ -36,6 +36,8 @@
* @cxlds: The device state backing this device
* @detach_work: active memdev lost a port in its ancestry
* @id: id number of this memdev instance.
+ * @dsmas_ary: Array of DSMAS entries as parsed from the CDAT table
+ * @nr_dsmas: Number of entries in dsmas_ary
*/
struct cxl_memdev {
struct device dev;
@@ -43,6 +45,8 @@ struct cxl_memdev {
struct cxl_dev_state *cxlds;
struct work_struct detach_work;
int id;
+ struct cxl_dsmas *dsmas_ary;
+ int nr_dsmas;
};
static inline struct cxl_memdev *to_cxl_memdev(struct device *dev)
diff --git a/drivers/cxl/cxlpci.h b/drivers/cxl/cxlpci.h
index eec597dbe763..3e68804d8935 100644
--- a/drivers/cxl/cxlpci.h
+++ b/drivers/cxl/cxlpci.h
@@ -75,4 +75,5 @@ int devm_cxl_port_enumerate_dports(struct cxl_port *port);
struct cxl_dev_state;
int cxl_hdm_decode_init(struct cxl_dev_state *cxlds, struct cxl_hdm *cxlhdm);
void read_cdat_data(struct cxl_port *port);
+void parse_dsmas(struct cxl_memdev *cxlmd, struct cxl_port *port);
#endif /* __CXL_PCI_H__ */
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index c310f1fd3db0..a8768df4ae38 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -35,6 +35,7 @@ static int create_endpoint(struct cxl_memdev *cxlmd,
if (IS_ERR(endpoint))
return PTR_ERR(endpoint);
+ parse_dsmas(cxlmd, endpoint);
dev_dbg(&cxlmd->dev, "add: %s\n", dev_name(&endpoint->dev));
if (!endpoint->dev.driver) {
--
2.35.1
^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-10 20:22 ` [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes ira.weiny
@ 2022-06-14 3:53 ` Li, Ming
2022-06-15 4:18 ` Ira Weiny
2022-06-17 22:40 ` Bjorn Helgaas
2022-06-17 22:56 ` Dan Williams
2 siblings, 1 reply; 44+ messages in thread
From: Li, Ming @ 2022-06-14 3:53 UTC (permalink / raw)
To: ira.weiny, Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Alison Schofield, Vishal Verma, Dave Jiang, Ben Widawsky,
linux-kernel, linux-cxl, linux-pci
On 6/11/2022 4:22 AM, ira.weiny@intel.com wrote:
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> Introduced in a PCI r6.0, sec 6.30, DOE provides a config space based
> mailbox with standard protocol discovery. Each mailbox is accessed
> through a DOE Extended Capability.
>
> Each DOE mailbox must support the DOE discovery protocol in addition to
> any number of additional protocols.
>
> Define core PCI functionality to manage a single PCI DOE mailbox at a
> defined config space offset. Functionality includes iterating,
> creating, query of supported protocol, task submission, and destruction
> of the mailboxes.
>
> If interrupts are desired, the interrupt number can be queried and
> passed to the create function. Passing a negative value disables
> interrupts for that mailbox. It is the callers responsibility to ensure
> enough interrupt vectors are allocated.
>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Co-developed-by: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> ---
> Changes from V9
> Lukas Wunner
> Update comments
> Move private doe structures and defines from pci-doe.h to doe.c
> check Data Obj Ready prior to last ack
> Davidlohr
> make task_lock a spinlock
> Lukas/Jonathan
> Remove special case of error in irq handler
> Fix potential race with the scheduling of a task when one is ending.
> The current task can't be retired until the state
> machine is idle. Otherwise a new task work item may run
> and the state machine would be out of sync.
>
> Changes from V8
> Remove Bjorn's ack
> Expose a function to find the irq number for a mailbox based on
> offset. This is the code Jonathan proposed for finding the irq
> number here:
> https://lore.kernel.org/linux-cxl/20220503153449.4088-2-Jonathan.Cameron@huawei.com/
> This removes funky bool parameter to create.
> Move pci_set_master() within the pci_doe_enable_irq()
> Per Bjorn
> Clean up commit messages
> move pci-doe.c to doe.c
> Clean up PCI spec references
> Ensure all messages use pci_*()
> Add offset to error messages to distinguish mailboxes
> use hex for DOE offsets
> Print 4 nibbles for Vendor ID and 2 for type.
> s/irq/IRQ in comments
> Fix long lines
> Fix typos
>
> Changes from V7
> Add a Kconfig for this functionality
> Fix bug in pci_doe_supports_prot()
> Rebased on cxl-pending
>
> Changes from V6
> Clean up signed off by lines
> Make this functionality all PCI library functions
> Clean up header files
> s/pci_doe_irq/pci_doe_irq_handler
> Use pci_{request,free}_irq
> Remove irq_name (maintained by pci_request_irq)
> Fix checks to use an irq
> Consistently use u16 for cap_offset
> Cleanup kdocs and comments
> Create a helper retire_cur_task() to handle locking of the
> current task pointer.
> Remove devm_ calls from PCI layer.
> The devm_ calls do not allow for the pci_doe_mb objects
> to be tied to an auxiliary device. Leave it to the
> caller to use devm_ if desired.
> From Dan Williams
> s/cb/end_task/; Pass pci_doe_task to end_task
> Clarify exchange/task/request/response.
> Merge pci_doe_task and pci_doe_exchange into
> pci_doe_task which represents a single
> request/response task for the state machine to
> process.
> Simplify submitting work to the mailbox
> Replace pci_doe_exchange_sync() with
> pci_doe_submit_task() Consumers of the mailbox
> are now responsible for setting up callbacks
> within a task object and submitting them to the
> mailbox to be processed.
> Remove WARN_ON when task != NULL and be sure to abort that task.
> Convert abort/dead to atomic flags
> s/state_lock/task_lock to better define what the lock is
> protecting
> Remove all the auxiliary bus code from the PCI layer
> The PCI layer provides helpers to use the DOE
> Mailboxes. Each subsystem can then use the
> helpers as they see fit. The CXL layer in this
> series uses aux devices to manage the new
> pci_doe_mb objects.
>
> From Bjorn
> Clarify the fact that DOE mailboxes are capabilities of
> the device.
> Code clean ups
> Cleanup Makefile
> Update references to PCI SIG spec v6.0
> Move this attribution here:
> This code is based on Jonathan's V4 series here:
> https://lore.kernel.org/linux-cxl/20210524133938.2815206-1-Jonathan.Cameron@huawei.com/
>
> Changes from V5
> From Bjorn
> s/pci_WARN/pci_warn
> Add timeout period to print
> Trim to 80 chars
> Use Tabs for DOE define spacing
> Use %#x for clarity
> From Jonathan
> Addresses concerns about the order of unwinding stuff
> s/doe/doe_dev in pci_doe_exhcnage_sync
> Correct kernel Doc comment
> Move pci_doe_task_complete() down in the file.
> Rework pci_doe_irq()
> process STATUS_ERROR first
> Return IRQ_NONE if the irq is not processed
> Use PCI_DOE_STATUS_INT_STATUS explicitly to
> clear the irq
> Clean up goto label s/err_free_irqs/err_free_irq
> use devm_kzalloc for doe struct
> clean up error paths in pci_doe_probe
> s/pci_doe_drv/pci_doe
> remove include mutex.h
> remove device name and define, move it in the next patch which uses it
> use devm_kasprintf() for irq_name
> use devm_request_irq()
> remove pci_doe_unregister()
> [get/put]_device() were unneeded and with the use of
> devm_* this function can be removed completely.
> refactor pci_doe_register and s/pci_doe_register/pci_doe_reg_irq
> make this function just a registration of the irq and
> move pci_doe_abort() into pci_doe_probe()
> use devm_* to allocate the protocol array
>
> Changes from Jonathan's V4
> Move the DOE MB code into the DOE auxiliary driver
> Remove Task List in favor of a wait queue
>
> Changes from Ben
> remove CXL references
> propagate rc from pci functions on error
> ---
> drivers/pci/Kconfig | 3 +
> drivers/pci/Makefile | 1 +
> drivers/pci/doe.c | 693 ++++++++++++++++++++++++++++++++++
> include/linux/pci-doe.h | 65 ++++
> include/uapi/linux/pci_regs.h | 29 +-
> 5 files changed, 790 insertions(+), 1 deletion(-)
> create mode 100644 drivers/pci/doe.c
> create mode 100644 include/linux/pci-doe.h
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 133c73207782..b2f2e588a817 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -121,6 +121,9 @@ config XEN_PCIDEV_FRONTEND
> config PCI_ATS
> bool
>
> +config PCI_DOE
> + bool
> +
> config PCI_ECAM
> bool
>
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index 0da6b1ebc694..2680e4c92f0a 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_PCI_ECAM) += ecam.o
> obj-$(CONFIG_PCI_P2PDMA) += p2pdma.o
> obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
> obj-$(CONFIG_VGA_ARB) += vgaarb.o
> +obj-$(CONFIG_PCI_DOE) += doe.o
>
> # Endpoint library must be initialized before its users
> obj-$(CONFIG_PCI_ENDPOINT) += endpoint/
> diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c
> new file mode 100644
> index 000000000000..4619c3e547f2
> --- /dev/null
> +++ b/drivers/pci/doe.c
> @@ -0,0 +1,693 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Data Object Exchange
> + * PCIe r6.0, sec 6.30 DOE
> + *
> + * Copyright (C) 2021 Huawei
> + * Jonathan Cameron <Jonathan.Cameron@huawei.com>
> + *
> + * Copyright (C) 2022 Intel Corporation
> + * Ira Weiny <ira.weiny@intel.com>
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/delay.h>
> +#include <linux/jiffies.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.30.2 Operation, PCI Spec r6.0 */
> +#define PCI_DOE_TIMEOUT HZ
> +
> +enum pci_doe_state {
> + DOE_IDLE,
> + DOE_WAIT_RESP,
> + DOE_WAIT_ABORT,
> + DOE_WAIT_ABORT_ON_ERR,
> +};
> +
> +#define PCI_DOE_FLAG_ABORT 0
> +#define PCI_DOE_FLAG_DEAD 1
> +
> +/**
> + * struct pci_doe_mb - State for a single DOE mailbox
> + *
> + * This state is used to manage a single DOE mailbox capability. All fields
> + * should be considered opaque to the consumers and the structure passed into
> + * the helpers below after being created by devm_pci_doe_create()
> + *
> + * @pdev: PCI device this mailbox belongs to
> + * @abort_c: Completion used for initial abort handling
> + * @irq: Interrupt used for signaling DOE ready or abort
> + * @prots: Array of protocols supported on this DOE
> + * @num_prots: Size of @prots array
> + * @cap_offset: Capability offset
> + * @wq: Wait queue to wait on if a query is in progress
> + * @cur_task: Current task the state machine is working on
> + * @task_lock: Protect cur_task
> + * @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
> + * @flags: Bit array of PCI_DOE_FLAG_* flags
> + *
> + * Note: @prots can't be allocated with struct size because the number of
> + * protocols is not known until after this structure is in use. However, the
> + * single discovery protocol is always required to query for the number of
> + * protocols.
> + */
> +struct pci_doe_mb {
> + struct pci_dev *pdev;
> + struct completion abort_c;
> + int irq;
> + struct pci_doe_protocol *prots;
> + int num_prots;
> + u16 cap_offset;
> +
> + wait_queue_head_t wq;
> + struct pci_doe_task *cur_task;
> + spinlock_t task_lock;
> + struct delayed_work statemachine;
> + enum pci_doe_state state;
> + unsigned long timeout_jiffies;
> + unsigned int busy_retries;
> + unsigned long flags;
> +};
> +
> +static irqreturn_t pci_doe_irq_handler(int irq, void *data)
> +{
> + struct pci_doe_mb *doe_mb = data;
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + u32 val;
> +
> + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> + if (FIELD_GET(PCI_DOE_STATUS_INT_STATUS, val)) {
> + pci_write_config_dword(pdev, offset + PCI_DOE_STATUS,
> + PCI_DOE_STATUS_INT_STATUS);
> + mod_delayed_work(system_wq, &doe_mb->statemachine, 0);
> + return IRQ_HANDLED;
> + }
> +
> + return IRQ_NONE;
> +}
> +
> +/*
> + * Only called when safe to directly access the DOE from
> + * doe_statemachine_work(). Outside access is not protected. Users who
> + * perform such access are left with the pieces.
> + */
> +static void pci_doe_abort_start(struct pci_doe_mb *doe_mb)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + u32 val;
> +
> + val = PCI_DOE_CTRL_ABORT;
> + if (doe_mb->irq >= 0)
> + val |= PCI_DOE_CTRL_INT_EN;
> + pci_write_config_dword(pdev, offset + PCI_DOE_CTRL, val);
> +
> + doe_mb->timeout_jiffies = jiffies + HZ;
> + schedule_delayed_work(&doe_mb->statemachine, HZ);
> +}
> +
> +static int pci_doe_send_req(struct pci_doe_mb *doe_mb,
> + struct pci_doe_task *task)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + 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, offset + 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, task->prot.vid) |
> + FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, task->prot.type);
> + pci_write_config_dword(pdev, offset + PCI_DOE_WRITE, val);
> + /* Length is 2 DW of header + length of payload in DW */
> + pci_write_config_dword(pdev, offset + PCI_DOE_WRITE,
> + FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH,
> + 2 + task->request_pl_sz /
> + sizeof(u32)));
> + for (i = 0; i < task->request_pl_sz / sizeof(u32); i++)
> + pci_write_config_dword(pdev, offset + PCI_DOE_WRITE,
> + task->request_pl[i]);
> +
> + val = PCI_DOE_CTRL_GO;
> + if (doe_mb->irq >= 0)
> + val |= PCI_DOE_CTRL_INT_EN;
> +
> + pci_write_config_dword(pdev, offset + PCI_DOE_CTRL, val);
> + /* Request is sent - now wait for poll or IRQ */
> + return 0;
> +}
> +
> +static bool pci_doe_data_obj_ready(struct pci_doe_mb *doe_mb)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + u32 val;
> +
> + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> + if (FIELD_GET(PCI_DOE_STATUS_DATA_OBJECT_READY, val))
> + return true;
> + return false;
> +}
> +
> +static int pci_doe_recv_resp(struct pci_doe_mb *doe_mb, struct pci_doe_task *task)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + size_t length, payload_length;
> + u32 val;
> + int i;
> +
> + /* Read the first dword to get the protocol */
> + pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
> + if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != task->prot.vid) ||
> + (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != task->prot.type)) {
> + pci_err(pdev,
> + "DOE [%x] expected [VID, Protocol] = [%04x, %02x], got [%04x, %02x]\n",
> + doe_mb->cap_offset,
> + task->prot.vid, task->prot.type,
> + 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, offset + PCI_DOE_READ, 0);
> + /* Read the second dword to get the length */
> + pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
> + pci_write_config_dword(pdev, offset + PCI_DOE_READ, 0);
> +
> + length = FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH, val);
> + if (length > SZ_1M || length < 2)
> + return -EIO;
> +
> + /* First 2 dwords have already been read */
> + length -= 2;
> + payload_length = min(length, task->response_pl_sz / sizeof(u32));
> + /* Read the rest of the response payload */
> + for (i = 0; i < payload_length; i++) {
> + pci_read_config_dword(pdev, offset + PCI_DOE_READ,
> + &task->response_pl[i]);
> + /* Prior to the last ack, ensure Data Object Ready */
> + if (i == (payload_length-1) && !pci_doe_data_obj_ready(doe_mb))
> + return -EIO;
> + pci_write_config_dword(pdev, offset + PCI_DOE_READ, 0);
> + }
> +
> + /* Flush excess length */
> + for (; i < length; i++) {
> + pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
> + pci_write_config_dword(pdev, offset + PCI_DOE_READ, 0);
> + }
> +
> + /* Final error check to pick up on any since Data Object Ready */
> + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> + if (FIELD_GET(PCI_DOE_STATUS_ERROR, val))
> + return -EIO;
> +
> + return min(length, task->response_pl_sz / sizeof(u32)) * sizeof(u32);
> +}
> +
> +static void signal_task_complete(struct pci_doe_task *task, int rv)
> +{
> + task->rv = rv;
> + task->complete(task);
> +}
> +
> +static void retire_cur_task(struct pci_doe_mb *doe_mb)
> +{
> + spin_lock(&doe_mb->task_lock);
> + doe_mb->cur_task = NULL;
> + spin_unlock(&doe_mb->task_lock);
> + wake_up_interruptible(&doe_mb->wq);
> +}
> +
> +static void doe_statemachine_work(struct work_struct *work)
> +{
> + struct delayed_work *w = to_delayed_work(work);
> + struct pci_doe_mb *doe_mb = container_of(w, struct pci_doe_mb,
> + statemachine);
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + enum pci_doe_state prev_state;
> + struct pci_doe_task *task;
> + u32 val;
> + int rc;
> +
> + spin_lock(&doe_mb->task_lock);
> + task = doe_mb->cur_task;
> + spin_unlock(&doe_mb->task_lock);
> +
> + if (test_and_clear_bit(PCI_DOE_FLAG_ABORT, &doe_mb->flags)) {
> + /*
> + * Currently only used during init - care needed if
> + * pci_doe_abort() is generally exposed as it would impact
> + * queries in flight.
> + */
> + if (task)
> + pci_err(pdev, "DOE [%x] Aborting with active task!\n",
> + doe_mb->cap_offset);
> + doe_mb->state = DOE_WAIT_ABORT;
> + pci_doe_abort_start(doe_mb);
> + return;
> + }
> +
> + switch (doe_mb->state) {
> + case DOE_IDLE:
> + if (task == NULL)
> + return;
> +
> + rc = pci_doe_send_req(doe_mb, task);
> +
> + /*
> + * 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_mb->busy_retries++;
> + if (doe_mb->busy_retries == PCI_DOE_BUSY_MAX_RETRIES) {
> + /* Long enough, fail this request */
> + pci_warn(pdev,
> + "DOE [%x] busy for too long (> 1 sec)\n",
> + doe_mb->cap_offset);
> + doe_mb->busy_retries = 0;
> + goto err_busy;
> + }
> + schedule_delayed_work(w, HZ / PCI_DOE_BUSY_MAX_RETRIES);
> + return;
> + }
> + if (rc)
> + goto err_abort;
> + doe_mb->busy_retries = 0;
> +
> + doe_mb->state = DOE_WAIT_RESP;
> + doe_mb->timeout_jiffies = jiffies + HZ;
> + /* Now poll or wait for IRQ with timeout */
> + if (doe_mb->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, offset + 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_mb->timeout_jiffies)) {
> + rc = -ETIMEDOUT;
> + goto err_abort;
> + }
> + schedule_delayed_work(w, PCI_DOE_POLL_INTERVAL);
> + return;
> + }
> +
> + rc = pci_doe_recv_resp(doe_mb, task);
> + if (rc < 0)
> + goto err_abort;
> +
> + doe_mb->state = DOE_IDLE;
> +
> + retire_cur_task(doe_mb);
> + /* Set the return value to the length of received payload */
> + signal_task_complete(task, rc);
> +
> + return;
> +
> + case DOE_WAIT_ABORT:
> + case DOE_WAIT_ABORT_ON_ERR:
> + prev_state = doe_mb->state;
> +
> + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> +
> + if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) &&
> + !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) {
> + doe_mb->state = DOE_IDLE;
> + /* Back to normal state - carry on */
> + retire_cur_task(doe_mb);
> + } else if (time_after(jiffies, doe_mb->timeout_jiffies)) {
> + /* Task has timed out and is dead - abort */
> + pci_err(pdev, "DOE [%x] ABORT timed out\n",
> + doe_mb->cap_offset);
> + set_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags);
> + retire_cur_task(doe_mb);
> + }
> +
> + /*
> + * For deliberately triggered abort, someone is
> + * waiting.
> + */
> + if (prev_state == DOE_WAIT_ABORT) {
> + if (task)
> + signal_task_complete(task, -EFAULT);
> + complete(&doe_mb->abort_c);
> + }
> +
> + return;
> + }
> +
> +err_abort:
> + doe_mb->state = DOE_WAIT_ABORT_ON_ERR;
> + pci_doe_abort_start(doe_mb);
> +err_busy:
> + signal_task_complete(task, rc);
> + if (doe_mb->state == DOE_IDLE)
> + retire_cur_task(doe_mb);
> +}
> +
> +static void pci_doe_task_complete(struct pci_doe_task *task)
> +{
> + complete(task->private);
> +}
> +
> +static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
> + u8 *protocol)
> +{
> + u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
> + *index);
> + u32 response_pl;
> + DECLARE_COMPLETION_ONSTACK(c);
> + struct pci_doe_task task = {
> + .prot.vid = PCI_VENDOR_ID_PCI_SIG,
> + .prot.type = PCI_DOE_PROTOCOL_DISCOVERY,
> + .request_pl = &request_pl,
> + .request_pl_sz = sizeof(request_pl),
> + .response_pl = &response_pl,
> + .response_pl_sz = sizeof(response_pl),
> + .complete = pci_doe_task_complete,
> + .private = &c,
> + };
> + int ret;
> +
> + ret = pci_doe_submit_task(doe_mb, &task);
> + if (ret < 0)
> + return ret;
> +
> + wait_for_completion(&c);
> +
> + if (task.rv != 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_mb *doe_mb)
> +{
> + u8 index = 0;
> + int num_prots;
> + int rc;
> +
> + /* Discovery protocol must always be supported and must report itself */
> + num_prots = 1;
> +
> + doe_mb->prots = kcalloc(num_prots, sizeof(*doe_mb->prots), GFP_KERNEL);
> + if (!doe_mb->prots)
> + return -ENOMEM;
> +
> + /*
> + * NOTE: doe_mb_prots is freed by pci_doe_free_mb() automatically on
> + * error if pci_doe_cache_protocols() fails past this point.
> + */
> + do {
> + struct pci_doe_protocol *prot;
> +
> + prot = &doe_mb->prots[num_prots - 1];
> + rc = pci_doe_discovery(doe_mb, &index, &prot->vid, &prot->type);
> + if (rc)
> + return rc;
> +
> + if (index) {
> + struct pci_doe_protocol *prot_new;
> +
> + num_prots++;
> + prot_new = krealloc(doe_mb->prots,
> + sizeof(*doe_mb->prots) * num_prots,
> + GFP_KERNEL);
> + if (!prot_new)
> + return -ENOMEM;
> +
> + doe_mb->prots = prot_new;
> + }
> + } while (index);
> +
> + doe_mb->num_prots = num_prots;
> + return 0;
> +}
> +
> +static int pci_doe_abort(struct pci_doe_mb *doe_mb)
> +{
> + reinit_completion(&doe_mb->abort_c);
> + set_bit(PCI_DOE_FLAG_ABORT, &doe_mb->flags);
> + schedule_delayed_work(&doe_mb->statemachine, 0);
> + wait_for_completion(&doe_mb->abort_c);
> +
> + if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags))
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static int pci_doe_enable_irq(struct pci_doe_mb *doe_mb, unsigned int irq)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + int rc;
> +
> + /*
> + * Enabling bus mastering is required for MSI/MSIx. It is safe to call
> + * this multiple times and thus is called here to ensure that mastering
> + * is enabled even if the driver has done so.
> + */
> + pci_set_master(pdev);
> + rc = pci_request_irq(pdev, irq, pci_doe_irq_handler, NULL, doe_mb,
> + "DOE[%d:%s]", irq, pci_name(pdev));
> + if (rc)
> + return rc;
> +
> + doe_mb->irq = irq;
> + pci_write_config_dword(pdev, offset + PCI_DOE_CTRL,
> + PCI_DOE_CTRL_INT_EN);
> + return 0;
> +}
> +
> +static void pci_doe_free_mb(struct pci_doe_mb *doe_mb)
> +{
> + if (doe_mb->irq >= 0)
> + pci_free_irq(doe_mb->pdev, doe_mb->irq, doe_mb);
> + kfree(doe_mb->prots);
> + kfree(doe_mb);
> +}
> +
> +/**
> + * pci_doe_get_irq_num() - Return the irq number for the mailbox at offset
> + *
> + * @pdev: The PCI device
> + * @offset: Offset of the DOE mailbox
> + *
> + * Returns: irq number on success
> + * -errno if irqs are not supported on this mailbox
> + */
> +int pci_doe_get_irq_num(struct pci_dev *pdev, int offset)
> +{
> + u32 val;
> +
> + pci_read_config_dword(pdev, offset + PCI_DOE_CAP, &val);
> + if (!FIELD_GET(PCI_DOE_CAP_INT, val))
> + return -EOPNOTSUPP;
> +
> + return FIELD_GET(PCI_DOE_CAP_IRQ, val);
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_get_irq_num);
> +
> +/**
> + * pci_doe_create_mb() - Create a DOE mailbox object
> + *
> + * @pdev: PCI device to create the DOE mailbox for
> + * @cap_offset: Offset of the DOE mailbox
> + * @irq: irq number to use; a negative value means don't use interrupts
> + *
> + * Create a single mailbox object to manage the mailbox protocol at the
> + * cap_offset specified.
> + *
> + * Caller should allocate PCI IRQ vectors before setting use_irq.
> + *
> + * RETURNS: created mailbox object on success
> + * ERR_PTR(-errno) on failure
> + */
> +struct pci_doe_mb *pci_doe_create_mb(struct pci_dev *pdev, u16 cap_offset,
> + int irq)
> +{
> + struct pci_doe_mb *doe_mb;
> + int rc;
> +
> + doe_mb = kzalloc(sizeof(*doe_mb), GFP_KERNEL);
> + if (!doe_mb)
> + return ERR_PTR(-ENOMEM);
> +
> + doe_mb->pdev = pdev;
> + init_completion(&doe_mb->abort_c);
> + doe_mb->irq = -1;
> + doe_mb->cap_offset = cap_offset;
> +
> + init_waitqueue_head(&doe_mb->wq);
> + spin_lock_init(&doe_mb->task_lock);
> + INIT_DELAYED_WORK(&doe_mb->statemachine, doe_statemachine_work);
> + doe_mb->state = DOE_IDLE;
> +
> + if (irq >= 0) {
> + rc = pci_doe_enable_irq(doe_mb, irq);
> + if (rc)
> + pci_err(pdev,
> + "DOE [%x] enable requested IRQ (%d) failed : %d\n",
> + doe_mb->cap_offset, irq, rc);
> + }
> +
> + /* Reset the mailbox by issuing an abort */
> + rc = pci_doe_abort(doe_mb);
> + if (rc) {
> + pci_err(pdev, "DOE [%x] failed to reset : %d\n",
> + doe_mb->cap_offset, rc);
> + pci_doe_free_mb(doe_mb);
> + return ERR_PTR(rc);
> + }
> +
> + rc = pci_doe_cache_protocols(doe_mb);
> + if (rc) {
> + pci_err(pdev, "DOE [%x] failed to cache protocols : %d\n",
> + doe_mb->cap_offset, rc);
> + pci_doe_free_mb(doe_mb);
> + return ERR_PTR(rc);
> + }
> +
> + return doe_mb;
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_create_mb);
> +
> +/**
> + * pci_doe_supports_prot() - Return if the DOE instance supports the given
> + * protocol
> + * @doe_mb: DOE mailbox capability to query
> + * @vid: Protocol Vendor ID
> + * @type: Protocol type
> + *
> + * RETURNS: True if the DOE mailbox supports the protocol specified
> + */
> +bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type)
> +{
> + int i;
> +
> + /* The discovery protocol must always be supported */
> + if (vid == PCI_VENDOR_ID_PCI_SIG && type == PCI_DOE_PROTOCOL_DISCOVERY)
> + return true;
> +
> + for (i = 0; i < doe_mb->num_prots; i++)
> + if ((doe_mb->prots[i].vid == vid) &&
> + (doe_mb->prots[i].type == type))
> + return true;
> +
> + return false;
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_supports_prot);
> +
> +/**
> + * pci_doe_submit_task() - Submit a task to be processed by the state machine
> + *
> + * @doe_mb: DOE mailbox capability to submit to
> + * @task: task to be queued
> + *
> + * Submit a DOE task (request/response) to the DOE mailbox to be processed.
> + * Returns upon queueing the task object. If the queue is full this function
> + * will sleep until there is room in the queue.
> + *
> + * task->complete will be called when the state machine is done processing this
> + * task.
> + *
> + * Excess data will be discarded.
> + *
> + * RETURNS: 0 when task has been successful queued, -ERRNO on error
> + */
> +int pci_doe_submit_task(struct pci_doe_mb *doe_mb, struct pci_doe_task *task)
> +{
> + if (!pci_doe_supports_prot(doe_mb, task->prot.vid, task->prot.type))
> + return -EINVAL;
> +
> + /* DOE requests must be a whole number of DW */
> + if (task->request_pl_sz % sizeof(u32))
> + return -EINVAL;
> +
> +again:
> + spin_lock(&doe_mb->task_lock);
> + if (doe_mb->cur_task) {
> + spin_unlock(&doe_mb->task_lock);
> + wait_event_interruptible(doe_mb->wq, doe_mb->cur_task == NULL);
Hi,
do we need to check the returned value of wait_event_interruptible() here? if the returned value is -ERESTARTSYS, I think we should not try it again, just return.
> + goto again;
> + }
> +
> + if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags)) {
> + spin_unlock(&doe_mb->task_lock);
> + return -EIO;
> + }
> + doe_mb->cur_task = task;
> + spin_unlock(&doe_mb->task_lock);
> + schedule_delayed_work(&doe_mb->statemachine, 0);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_submit_task);
> +
> +/**
> + * pci_doe_destroy_mb() - Destroy a DOE mailbox object created with
> + * pci_doe_create_mb()
> + *
> + * @doe_mb: DOE mailbox capability structure to destroy
> + *
> + * The mailbox becomes invalid and should not be used after this call.
> + */
> +void pci_doe_destroy_mb(struct pci_doe_mb *doe_mb)
> +{
> + /* abort any work in progress */
> + pci_doe_abort(doe_mb);
> +
> + /* halt the state machine */
> + cancel_delayed_work_sync(&doe_mb->statemachine);
> +
> + pci_doe_free_mb(doe_mb);
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_destroy_mb);
> diff --git a/include/linux/pci-doe.h b/include/linux/pci-doe.h
> new file mode 100644
> index 000000000000..4623881d0e3e
> --- /dev/null
> +++ b/include/linux/pci-doe.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Data Object Exchange
> + * PCIe r6.0, sec 6.30 DOE
> + *
> + * Copyright (C) 2021 Huawei
> + * Jonathan Cameron <Jonathan.Cameron@huawei.com>
> + *
> + * Copyright (C) 2022 Intel Corporation
> + * Ira Weiny <ira.weiny@intel.com>
> + */
> +
> +#ifndef LINUX_PCI_DOE_H
> +#define LINUX_PCI_DOE_H
> +
> +#include <linux/completion.h>
> +
> +struct pci_doe_protocol {
> + u16 vid;
> + u8 type;
> +};
> +
> +/**
> + * struct pci_doe_task - represents a single query/response
> + *
> + * @prot: DOE Protocol
> + * @request_pl: The request payload
> + * @request_pl_sz: Size of the request payload
> + * @response_pl: The response payload
> + * @response_pl_sz: Size of the response payload
> + * @rv: Return value. Length of received response or error
> + * @complete: Called when task is complete
> + * @private: Private data for the consumer
> + */
> +struct pci_doe_task {
> + struct pci_doe_protocol prot;
> + u32 *request_pl;
> + size_t request_pl_sz;
> + u32 *response_pl;
> + size_t response_pl_sz;
> + int rv;
> + void (*complete)(struct pci_doe_task *task);
> + void *private;
> +};
> +
> +/**
> + * pci_doe_for_each_off - Iterate each DOE capability
> + * @pdev: struct pci_dev to iterate
> + * @off: u16 of config space offset of each mailbox capability found
> + */
> +#define pci_doe_for_each_off(pdev, off) \
> + for (off = pci_find_next_ext_capability(pdev, off, \
> + PCI_EXT_CAP_ID_DOE); \
> + off > 0; \
> + off = pci_find_next_ext_capability(pdev, off, \
> + PCI_EXT_CAP_ID_DOE))
> +
> +int pci_doe_get_irq_num(struct pci_dev *pdev, int offset);
> +struct pci_doe_mb *pci_doe_create_mb(struct pci_dev *pdev, u16 cap_offset,
> + int irq);
> +void pci_doe_destroy_mb(struct pci_doe_mb *doe_mb);
> +bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type);
> +int pci_doe_submit_task(struct pci_doe_mb *doe_mb, struct pci_doe_task *task);
> +
> +#endif
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index bee1a9ed6e66..4e96b45ee36d 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -736,7 +736,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
> @@ -1102,4 +1103,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 */
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-14 3:53 ` Li, Ming
@ 2022-06-15 4:18 ` Ira Weiny
0 siblings, 0 replies; 44+ messages in thread
From: Ira Weiny @ 2022-06-15 4:18 UTC (permalink / raw)
To: Li, Ming
Cc: Dan Williams, Bjorn Helgaas, Jonathan Cameron, Alison Schofield,
Vishal Verma, Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl,
linux-pci
On Tue, Jun 14, 2022 at 11:53:29AM +0800, Li, Ming wrote:
>
>
> On 6/11/2022 4:22 AM, ira.weiny@intel.com wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
[snip]
> > +
> > +/**
> > + * pci_doe_submit_task() - Submit a task to be processed by the state machine
> > + *
> > + * @doe_mb: DOE mailbox capability to submit to
> > + * @task: task to be queued
> > + *
> > + * Submit a DOE task (request/response) to the DOE mailbox to be processed.
> > + * Returns upon queueing the task object. If the queue is full this function
> > + * will sleep until there is room in the queue.
> > + *
> > + * task->complete will be called when the state machine is done processing this
> > + * task.
> > + *
> > + * Excess data will be discarded.
> > + *
> > + * RETURNS: 0 when task has been successful queued, -ERRNO on error
> > + */
> > +int pci_doe_submit_task(struct pci_doe_mb *doe_mb, struct pci_doe_task *task)
> > +{
> > + if (!pci_doe_supports_prot(doe_mb, task->prot.vid, task->prot.type))
> > + return -EINVAL;
> > +
> > + /* DOE requests must be a whole number of DW */
> > + if (task->request_pl_sz % sizeof(u32))
> > + return -EINVAL;
> > +
> > +again:
> > + spin_lock(&doe_mb->task_lock);
> > + if (doe_mb->cur_task) {
> > + spin_unlock(&doe_mb->task_lock);
> > + wait_event_interruptible(doe_mb->wq, doe_mb->cur_task == NULL);
> Hi,
> do we need to check the returned value of wait_event_interruptible() here? if the returned value is -ERESTARTSYS, I think we should not try it again, just return.
>
I'm not 100% sure it is necessary. However, I don't think there is a point in
trying to continue if a system thread is interrupted. So yea I think this is
a good idea.
Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices
2022-06-10 20:22 ` [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices ira.weiny
@ 2022-06-17 20:40 ` Davidlohr Bueso
2022-06-17 20:51 ` Davidlohr Bueso
2022-06-21 18:24 ` Ira Weiny
2022-06-17 23:44 ` [PATCH V11 " Dan Williams
2022-06-21 20:37 ` Bjorn Helgaas
2 siblings, 2 replies; 44+ messages in thread
From: Davidlohr Bueso @ 2022-06-17 20:40 UTC (permalink / raw)
To: ira.weiny
Cc: Dan Williams, Bjorn Helgaas, Jonathan Cameron, Ben Widawsky,
Alison Schofield, Vishal Verma, Dave Jiang, linux-kernel,
linux-cxl, linux-pci, a.manzanares
On Fri, 10 Jun 2022, ira.weiny@intel.com wrote:
>+++ b/drivers/cxl/cxlmem.h
>@@ -191,6 +191,8 @@ struct cxl_endpoint_dvsec_info {
> * @component_reg_phys: register base of component registers
> * @info: Cached DVSEC information about the device.
> * @serial: PCIe Device Serial Number
Missing doc:
@doe_use_irq: Use interrupt vectors for DOEs over polling.
However introducing such flags is not pretty, and this is only used by
devm_cxl_pci_create_doe(). Do we really need it? See below.
>+ * @doe_mbs: PCI DOE mailbox array
>+ * @num_mbs: Number of DOE mailboxes
> * @mbox_send: @dev specific transport for transmitting mailbox commands
> *
> * See section 8.2.9.5.2 Capacity Configuration and Label Storage for
>@@ -224,6 +226,10 @@ struct cxl_dev_state {
> resource_size_t component_reg_phys;
> u64 serial;
>
>+ bool doe_use_irq;
>+ struct pci_doe_mb **doe_mbs;
>+ int num_mbs;
>+
> int (*mbox_send)(struct cxl_dev_state *cxlds, struct cxl_mbox_cmd *cmd);
> };
>
>diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
>index 5a0ae46d4989..72c7b535f5df 100644
>--- a/drivers/cxl/pci.c
>+++ b/drivers/cxl/pci.c
>@@ -8,6 +8,7 @@
> #include <linux/mutex.h>
> #include <linux/list.h>
> #include <linux/pci.h>
>+#include <linux/pci-doe.h>
> #include <linux/io.h>
> #include "cxlmem.h"
> #include "cxlpci.h"
>@@ -386,6 +387,116 @@ static int cxl_setup_regs(struct pci_dev *pdev, enum cxl_regloc_type type,
> return rc;
> }
>
>+static void cxl_pci_free_irq_vectors(void *data)
>+{
>+ pci_free_irq_vectors(data);
>+}
>+
>+static void cxl_doe_destroy_mb(void *ds)
>+{
>+ struct cxl_dev_state *cxlds = ds;
>+ int i;
>+
>+ for (i = 0; i < cxlds->num_mbs; i++) {
>+ if (cxlds->doe_mbs[i])
>+ pci_doe_destroy_mb(cxlds->doe_mbs[i]);
>+ }
>+}
>+
>+static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
>+{
>+ struct device *dev = cxlds->dev;
>+ struct pci_dev *pdev = to_pci_dev(dev);
>+ int max_irqs = 0;
>+ int off = 0;
>+ int rc;
>+
>+ /* Account for all the DOE vectors needed */
>+ pci_doe_for_each_off(pdev, off) {
>+ int irq = pci_doe_get_irq_num(pdev, off);
>+
>+ if (irq < 0)
>+ continue;
>+ max_irqs = max(max_irqs, irq + 1);
>+ }
>+
>+ if (!max_irqs)
>+ return;
>+
>+ cxlds->doe_use_irq = false;
Is this unnecessary, it should already be 0 per the devm_kzalloc().
>+
>+ /*
>+ * Allocate enough vectors for the DOE's
>+ */
>+ rc = pci_alloc_irq_vectors(pdev, max_irqs, max_irqs, PCI_IRQ_MSI |
>+ PCI_IRQ_MSIX);
>+ if (rc != max_irqs) {
>+ pci_err(pdev, "Not enough interrupts; use polling\n");
>+ /* Some got allocated; clean them up */
>+ if (rc > 0)
>+ cxl_pci_free_irq_vectors(pdev);
>+ return;
>+ }
>+
>+ rc = devm_add_action_or_reset(dev, cxl_pci_free_irq_vectors, pdev);
>+ if (rc)
>+ return;
>+
>+ cxlds->doe_use_irq = true;
>+}
>+
>+/**
>+ * devm_cxl_pci_create_doe - Scan and set up DOE mailboxes
>+ *
>+ * @cxlds: The CXL device state
>+ */
>+static void devm_cxl_pci_create_doe(struct cxl_dev_state *cxlds)
>+{
>+ struct device *dev = cxlds->dev;
>+ struct pci_dev *pdev = to_pci_dev(dev);
>+ u16 off = 0;
>+ int num_mbs = 0;
>+ int rc;
>+
>+ pci_doe_for_each_off(pdev, off)
>+ num_mbs++;
>+
>+ if (!num_mbs) {
>+ pci_dbg(pdev, "0 DOE mailbox's found\n");
>+ return;
>+ }
>+
>+ cxlds->doe_mbs = devm_kcalloc(dev, num_mbs, sizeof(*cxlds->doe_mbs),
>+ GFP_KERNEL);
>+ if (!cxlds->doe_mbs)
>+ return;
>+
>+ pci_doe_for_each_off(pdev, off) {
>+ struct pci_doe_mb *doe_mb;
>+ int irq = -1;
>+
>+ if (cxlds->doe_use_irq)
>+ irq = pci_doe_get_irq_num(pdev, off);
>+
>+ doe_mb = pci_doe_create_mb(pdev, off, irq);
>+ if (IS_ERR(doe_mb)) {
>+ pci_err(pdev,
>+ "Failed to create MB object for MB @ %x\n",
>+ off);
>+ doe_mb = NULL;
>+ }
>+
>+ cxlds->doe_mbs[cxlds->num_mbs] = doe_mb;
>+ cxlds->num_mbs++;
>+ }
>+
>+ rc = devm_add_action_or_reset(dev, cxl_doe_destroy_mb, cxlds);
>+ if (rc)
>+ return;
>+
>+ pci_info(pdev, "Configured %d DOE mailbox's\n", cxlds->num_mbs);
>+}
>+
> static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> {
> struct cxl_register_map map;
>@@ -434,6 +545,9 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>
> cxlds->component_reg_phys = cxl_regmap_to_base(pdev, &map);
>
>+ cxl_alloc_irq_vectors(cxlds);
>+ devm_cxl_pci_create_doe(cxlds);
Should cxl_alloc_irq_vectors() just be called directly from devm_cxl_pci_create_doe()
instead? Also if devm_cxl_pci_create_doe() fails (say ENOMEM), why do we
bother continuing the cxl_pci probing?
Thanks,
Davidlohr
------
diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
index ce5b00f3ebcb..44098c785a8b 100644
--- a/drivers/cxl/cxlmem.h
+++ b/drivers/cxl/cxlmem.h
@@ -230,7 +230,6 @@ struct cxl_dev_state {
resource_size_t component_reg_phys;
u64 serial;
- bool doe_use_irq;
struct pci_doe_mb **doe_mbs;
int num_mbs;
diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
index 72c7b535f5df..47c3741f7768 100644
--- a/drivers/cxl/pci.c
+++ b/drivers/cxl/pci.c
@@ -403,7 +403,7 @@ static void cxl_doe_destroy_mb(void *ds)
}
}
-static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
+static int cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
{
struct device *dev = cxlds->dev;
struct pci_dev *pdev = to_pci_dev(dev);
@@ -421,9 +421,7 @@ static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
}
if (!max_irqs)
- return;
-
- cxlds->doe_use_irq = false;
+ return -ENOMEM;
/*
* Allocate enough vectors for the DOE's
@@ -435,14 +433,10 @@ static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
/* Some got allocated; clean them up */
if (rc > 0)
cxl_pci_free_irq_vectors(pdev);
- return;
+ return -ENOMEM;
}
- rc = devm_add_action_or_reset(dev, cxl_pci_free_irq_vectors, pdev);
- if (rc)
- return;
-
- cxlds->doe_use_irq = true;
+ return devm_add_action_or_reset(dev, cxl_pci_free_irq_vectors, pdev);
}
/**
@@ -457,6 +451,10 @@ static void devm_cxl_pci_create_doe(struct cxl_dev_state *cxlds)
u16 off = 0;
int num_mbs = 0;
int rc;
+ bool doe_use_irq = false;
+
+ if (cxl_alloc_irq_vectors(cxlds))
+ doe_use_irq = true;
pci_doe_for_each_off(pdev, off)
num_mbs++;
@@ -475,7 +473,7 @@ static void devm_cxl_pci_create_doe(struct cxl_dev_state *cxlds)
struct pci_doe_mb *doe_mb;
int irq = -1;
- if (cxlds->doe_use_irq)
+ if (doe_use_irq)
irq = pci_doe_get_irq_num(pdev, off);
doe_mb = pci_doe_create_mb(pdev, off, irq);
@@ -545,7 +543,6 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
cxlds->component_reg_phys = cxl_regmap_to_base(pdev, &map);
- cxl_alloc_irq_vectors(cxlds);
devm_cxl_pci_create_doe(cxlds);
rc = cxl_pci_setup_mailbox(cxlds);
^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH v11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices
2022-06-17 20:40 ` [PATCH v11 " Davidlohr Bueso
@ 2022-06-17 20:51 ` Davidlohr Bueso
2022-06-21 18:24 ` Ira Weiny
1 sibling, 0 replies; 44+ messages in thread
From: Davidlohr Bueso @ 2022-06-17 20:51 UTC (permalink / raw)
To: ira.weiny
Cc: Dan Williams, Bjorn Helgaas, Jonathan Cameron, Ben Widawsky,
Alison Schofield, Vishal Verma, Dave Jiang, linux-kernel,
linux-cxl, linux-pci, a.manzanares
On Fri, 17 Jun 2022, Davidlohr Bueso wrote:
>@@ -457,6 +451,10 @@ static void devm_cxl_pci_create_doe(struct cxl_dev_state *cxlds)
> u16 off = 0;
> int num_mbs = 0;
> int rc;
>+ bool doe_use_irq = false;
>+
>+ if (cxl_alloc_irq_vectors(cxlds))
if (!cxl_alloc_irq_vectors()), that is.
>+ doe_use_irq = true;
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-10 20:22 ` [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes ira.weiny
2022-06-14 3:53 ` Li, Ming
@ 2022-06-17 22:40 ` Bjorn Helgaas
2022-06-18 16:39 ` Bjorn Helgaas
` (2 more replies)
2022-06-17 22:56 ` Dan Williams
2 siblings, 3 replies; 44+ messages in thread
From: Bjorn Helgaas @ 2022-06-17 22:40 UTC (permalink / raw)
To: ira.weiny
Cc: Dan Williams, Bjorn Helgaas, Jonathan Cameron, Alison Schofield,
Vishal Verma, Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl,
linux-pci
On Fri, Jun 10, 2022 at 01:22:54PM -0700, ira.weiny@intel.com wrote:
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> Introduced in a PCI r6.0, sec 6.30, DOE provides a config space based
> mailbox with standard protocol discovery. Each mailbox is accessed
> through a DOE Extended Capability.
> +/* Timeout of 1 second from 6.30.2 Operation, PCI Spec r6.0 */
s/PCI/PCIe/ (up in commit log, too, I guess :))
Not that there will ever be a conventional PCI r6.0 spec, but there
was a PCI r3.0 well as a PCIe r3.0, so might as well keep them
straight.
> +struct pci_doe_mb {
> + struct pci_dev *pdev;
Trivial, but I would put cap_offset here next to pdev because the
(pdev, cap_offset) tuple is basically the identifier for the DOE
instance.
> + struct completion abort_c;
> + int irq;
> + struct pci_doe_protocol *prots;
> + int num_prots;
> + u16 cap_offset;
> +static void pci_doe_abort_start(struct pci_doe_mb *doe_mb)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + u32 val;
> +
> + val = PCI_DOE_CTRL_ABORT;
> + if (doe_mb->irq >= 0)
Is zero a valid IRQ? In general, I don't think it is, but maybe this
is a special case. Or maybe this is actually the "Interrupt Message
Number" mentioned in sec 6.30.3? If so maybe something other than
"irq" would be a better name here.
Possibly relevant: a85a6c86c25b ("driver core: platform: Clarify that
IRQ 0 is invalid")
> + pci_err(pdev,
> + "DOE [%x] expected [VID, Protocol] = [%04x, %02x], got [%04x, %02x]\n",
Wouldn't make a big difference, but could consider something like this
for enforced consistency:
#define dev_fmt(fmt) "DOE: " fmt
> + case DOE_WAIT_ABORT:
> + case DOE_WAIT_ABORT_ON_ERR:
> + prev_state = doe_mb->state;
> +
> + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> +
> + if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) &&
> + !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) {
> + doe_mb->state = DOE_IDLE;
> + /* Back to normal state - carry on */
> + retire_cur_task(doe_mb);
> + } else if (time_after(jiffies, doe_mb->timeout_jiffies)) {
> + /* Task has timed out and is dead - abort */
> + pci_err(pdev, "DOE [%x] ABORT timed out\n",
> + doe_mb->cap_offset);
> + set_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags);
> + retire_cur_task(doe_mb);
> + }
> +
> + /*
> + * For deliberately triggered abort, someone is
> + * waiting.
> + */
> + if (prev_state == DOE_WAIT_ABORT) {
> + if (task)
> + signal_task_complete(task, -EFAULT);
> + complete(&doe_mb->abort_c);
> + }
> +
> + return;
> + }
The "return" in each case is perfectly correct, but it feels a little
more conventional to make them "break" and return once here after the
switch to make it clear that the only way to get to the labels is via
an error path "goto".
> +err_abort:
> + doe_mb->state = DOE_WAIT_ABORT_ON_ERR;
> + pci_doe_abort_start(doe_mb);
> +err_busy:
> + signal_task_complete(task, rc);
> + if (doe_mb->state == DOE_IDLE)
> + retire_cur_task(doe_mb);
> +}
> + * Enabling bus mastering is required for MSI/MSIx. It is safe to call
s/MSIx/MSI-X/ (typical spelling in spec)
> + * this multiple times and thus is called here to ensure that mastering
> + * is enabled even if the driver has done so.
> + */
> + pci_set_master(pdev);
> + rc = pci_request_irq(pdev, irq, pci_doe_irq_handler, NULL, doe_mb,
> + "DOE[%d:%s]", irq, pci_name(pdev));
I assume the "DOE[%d:%s]" part appears in /proc/interrupts? Is it
redundant to include "irq", since /proc/interrupts already prints it,
or is there somewhere else where "irq" is useful?
How does the user associate this IRQ in /proc/interrupts with a
specific DOE capability? Should we include the cap_offset along with
the pci_name()?
> + * pci_doe_get_irq_num() - Return the irq number for the mailbox at offset
> + *
> + * @pdev: The PCI device
> + * @offset: Offset of the DOE mailbox
> + *
> + * Returns: irq number on success
> + * -errno if irqs are not supported on this mailbox
I normally capitalize IRQ/IRQs in comments. There are probably others
throughout the file. I notice some are already capitalized but not all.
> + */
> +int pci_doe_get_irq_num(struct pci_dev *pdev, int offset)
> +{
> + u32 val;
> +
> + pci_read_config_dword(pdev, offset + PCI_DOE_CAP, &val);
> + if (!FIELD_GET(PCI_DOE_CAP_INT, val))
> + return -EOPNOTSUPP;
> +
> + return FIELD_GET(PCI_DOE_CAP_IRQ, val);
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_get_irq_num);
Confusing function name (and comment) since PCI_DOE_CAP_IRQ is an
Interrupt Message Number that has nothing to do with Linux IRQ
numbers.
I see we already have PCI_EXP_FLAGS_IRQ, PCI_ERR_ROOT_AER_IRQ,
PCI_EXP_DPC_IRQ, so I guess you're in good company.
At least maybe update the comment to say "Interrupt Message Number"
instead of "irq".
> + * pci_doe_supports_prot() - Return if the DOE instance supports the given
> + * protocol
> + * @doe_mb: DOE mailbox capability to query
> + * @vid: Protocol Vendor ID
> + * @type: Protocol type
> + *
> + * RETURNS: True if the DOE mailbox supports the protocol specified
Is the typical use that the caller has a few specific protocols it
cares about? There's no case where a caller might want to enumerate
them all? I guess they're all in prots[], but that's supposed to be
opaque to users.
> + */
> +bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type)
> +{
> + int i;
> +
> + /* The discovery protocol must always be supported */
> + if (vid == PCI_VENDOR_ID_PCI_SIG && type == PCI_DOE_PROTOCOL_DISCOVERY)
> + return true;
> +
> + for (i = 0; i < doe_mb->num_prots; i++)
> + if ((doe_mb->prots[i].vid == vid) &&
> + (doe_mb->prots[i].type == type))
> + return true;
> +
> + return false;
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_supports_prot);
> + * struct pci_doe_task - represents a single query/response
> + *
> + * @prot: DOE Protocol
> + * @request_pl: The request payload
> + * @request_pl_sz: Size of the request payload
Size is in dwords, not bytes, I guess?
> + * @response_pl: The response payload
> + * @response_pl_sz: Size of the response payload
> + * @rv: Return value. Length of received response or error
> + * @complete: Called when task is complete
> + * @private: Private data for the consumer
> + */
> +struct pci_doe_task {
> + struct pci_doe_protocol prot;
> + u32 *request_pl;
> + size_t request_pl_sz;
> + u32 *response_pl;
> + size_t response_pl_sz;
> + int rv;
> + void (*complete)(struct pci_doe_task *task);
> + void *private;
> +};
^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-10 20:22 ` [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes ira.weiny
2022-06-14 3:53 ` Li, Ming
2022-06-17 22:40 ` Bjorn Helgaas
@ 2022-06-17 22:56 ` Dan Williams
2022-06-20 10:23 ` Jonathan Cameron
` (2 more replies)
2 siblings, 3 replies; 44+ messages in thread
From: Dan Williams @ 2022-06-17 22:56 UTC (permalink / raw)
To: ira.weiny, Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Alison Schofield, Vishal Verma, Dave Jiang,
Ben Widawsky, linux-kernel, linux-cxl, linux-pci
ira.weiny@ wrote:
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> Introduced in a PCI r6.0, sec 6.30, DOE provides a config space based
> mailbox with standard protocol discovery. Each mailbox is accessed
> through a DOE Extended Capability.
>
> Each DOE mailbox must support the DOE discovery protocol in addition to
> any number of additional protocols.
>
> Define core PCI functionality to manage a single PCI DOE mailbox at a
> defined config space offset. Functionality includes iterating,
> creating, query of supported protocol, task submission, and destruction
> of the mailboxes.
>
> If interrupts are desired, the interrupt number can be queried and
> passed to the create function. Passing a negative value disables
> interrupts for that mailbox. It is the callers responsibility to ensure
s/callers/caller's/
> enough interrupt vectors are allocated.
>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Co-developed-by: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> ---
> Changes from V9
> Lukas Wunner
> Update comments
> Move private doe structures and defines from pci-doe.h to doe.c
> check Data Obj Ready prior to last ack
> Davidlohr
> make task_lock a spinlock
> Lukas/Jonathan
> Remove special case of error in irq handler
> Fix potential race with the scheduling of a task when one is ending.
> The current task can't be retired until the state
> machine is idle. Otherwise a new task work item may run
> and the state machine would be out of sync.
>
> Changes from V8
> Remove Bjorn's ack
> Expose a function to find the irq number for a mailbox based on
> offset. This is the code Jonathan proposed for finding the irq
> number here:
> https://lore.kernel.org/linux-cxl/20220503153449.4088-2-Jonathan.Cameron@huawei.com/
> This removes funky bool parameter to create.
> Move pci_set_master() within the pci_doe_enable_irq()
> Per Bjorn
> Clean up commit messages
> move pci-doe.c to doe.c
> Clean up PCI spec references
> Ensure all messages use pci_*()
> Add offset to error messages to distinguish mailboxes
> use hex for DOE offsets
> Print 4 nibbles for Vendor ID and 2 for type.
> s/irq/IRQ in comments
> Fix long lines
> Fix typos
>
> Changes from V7
> Add a Kconfig for this functionality
> Fix bug in pci_doe_supports_prot()
> Rebased on cxl-pending
>
> Changes from V6
> Clean up signed off by lines
> Make this functionality all PCI library functions
> Clean up header files
> s/pci_doe_irq/pci_doe_irq_handler
> Use pci_{request,free}_irq
> Remove irq_name (maintained by pci_request_irq)
> Fix checks to use an irq
> Consistently use u16 for cap_offset
> Cleanup kdocs and comments
> Create a helper retire_cur_task() to handle locking of the
> current task pointer.
> Remove devm_ calls from PCI layer.
> The devm_ calls do not allow for the pci_doe_mb objects
> to be tied to an auxiliary device. Leave it to the
> caller to use devm_ if desired.
> From Dan Williams
> s/cb/end_task/; Pass pci_doe_task to end_task
> Clarify exchange/task/request/response.
> Merge pci_doe_task and pci_doe_exchange into
> pci_doe_task which represents a single
> request/response task for the state machine to
> process.
> Simplify submitting work to the mailbox
> Replace pci_doe_exchange_sync() with
> pci_doe_submit_task() Consumers of the mailbox
> are now responsible for setting up callbacks
> within a task object and submitting them to the
> mailbox to be processed.
> Remove WARN_ON when task != NULL and be sure to abort that task.
> Convert abort/dead to atomic flags
> s/state_lock/task_lock to better define what the lock is
> protecting
> Remove all the auxiliary bus code from the PCI layer
> The PCI layer provides helpers to use the DOE
> Mailboxes. Each subsystem can then use the
> helpers as they see fit. The CXL layer in this
> series uses aux devices to manage the new
> pci_doe_mb objects.
>
> From Bjorn
> Clarify the fact that DOE mailboxes are capabilities of
> the device.
> Code clean ups
> Cleanup Makefile
> Update references to PCI SIG spec v6.0
> Move this attribution here:
> This code is based on Jonathan's V4 series here:
> https://lore.kernel.org/linux-cxl/20210524133938.2815206-1-Jonathan.Cameron@huawei.com/
>
> Changes from V5
> From Bjorn
> s/pci_WARN/pci_warn
> Add timeout period to print
> Trim to 80 chars
> Use Tabs for DOE define spacing
> Use %#x for clarity
> From Jonathan
> Addresses concerns about the order of unwinding stuff
> s/doe/doe_dev in pci_doe_exhcnage_sync
> Correct kernel Doc comment
> Move pci_doe_task_complete() down in the file.
> Rework pci_doe_irq()
> process STATUS_ERROR first
> Return IRQ_NONE if the irq is not processed
> Use PCI_DOE_STATUS_INT_STATUS explicitly to
> clear the irq
> Clean up goto label s/err_free_irqs/err_free_irq
> use devm_kzalloc for doe struct
> clean up error paths in pci_doe_probe
> s/pci_doe_drv/pci_doe
> remove include mutex.h
> remove device name and define, move it in the next patch which uses it
> use devm_kasprintf() for irq_name
> use devm_request_irq()
> remove pci_doe_unregister()
> [get/put]_device() were unneeded and with the use of
> devm_* this function can be removed completely.
> refactor pci_doe_register and s/pci_doe_register/pci_doe_reg_irq
> make this function just a registration of the irq and
> move pci_doe_abort() into pci_doe_probe()
> use devm_* to allocate the protocol array
>
> Changes from Jonathan's V4
> Move the DOE MB code into the DOE auxiliary driver
> Remove Task List in favor of a wait queue
>
> Changes from Ben
> remove CXL references
> propagate rc from pci functions on error
> ---
> drivers/pci/Kconfig | 3 +
> drivers/pci/Makefile | 1 +
> drivers/pci/doe.c | 693 ++++++++++++++++++++++++++++++++++
> include/linux/pci-doe.h | 65 ++++
> include/uapi/linux/pci_regs.h | 29 +-
> 5 files changed, 790 insertions(+), 1 deletion(-)
> create mode 100644 drivers/pci/doe.c
> create mode 100644 include/linux/pci-doe.h
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 133c73207782..b2f2e588a817 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -121,6 +121,9 @@ config XEN_PCIDEV_FRONTEND
> config PCI_ATS
> bool
>
> +config PCI_DOE
> + bool
> +
> config PCI_ECAM
> bool
>
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index 0da6b1ebc694..2680e4c92f0a 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_PCI_ECAM) += ecam.o
> obj-$(CONFIG_PCI_P2PDMA) += p2pdma.o
> obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
> obj-$(CONFIG_VGA_ARB) += vgaarb.o
> +obj-$(CONFIG_PCI_DOE) += doe.o
>
> # Endpoint library must be initialized before its users
> obj-$(CONFIG_PCI_ENDPOINT) += endpoint/
> diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c
> new file mode 100644
> index 000000000000..4619c3e547f2
> --- /dev/null
> +++ b/drivers/pci/doe.c
> @@ -0,0 +1,693 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Data Object Exchange
> + * PCIe r6.0, sec 6.30 DOE
> + *
> + * Copyright (C) 2021 Huawei
> + * Jonathan Cameron <Jonathan.Cameron@huawei.com>
> + *
> + * Copyright (C) 2022 Intel Corporation
> + * Ira Weiny <ira.weiny@intel.com>
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/delay.h>
> +#include <linux/jiffies.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.30.2 Operation, PCI Spec r6.0 */
> +#define PCI_DOE_TIMEOUT HZ
> +
> +enum pci_doe_state {
> + DOE_IDLE,
> + DOE_WAIT_RESP,
> + DOE_WAIT_ABORT,
> + DOE_WAIT_ABORT_ON_ERR,
> +};
> +
> +#define PCI_DOE_FLAG_ABORT 0
> +#define PCI_DOE_FLAG_DEAD 1
Warning, I tend to review data structures first, so some of the
questions below might have answers in the code, but I have hard time
jumping to the implementation if the data structure is not clear.
> +
> +/**
> + * struct pci_doe_mb - State for a single DOE mailbox
> + *
> + * This state is used to manage a single DOE mailbox capability. All fields
> + * should be considered opaque to the consumers and the structure passed into
> + * the helpers below after being created by devm_pci_doe_create()
Hmm, why devm_ and not pcim_ like pcim_enable_device()?
> + *
> + * @pdev: PCI device this mailbox belongs to
> + * @abort_c: Completion used for initial abort handling
What does initial abort handling mean? If it's just a single point in
time use couldn't that be handled with an on-stack completion?
> + * @irq: Interrupt used for signaling DOE ready or abort
> + * @prots: Array of protocols supported on this DOE
> + * @num_prots: Size of @prots array
> + * @cap_offset: Capability offset
> + * @wq: Wait queue to wait on if a query is in progress
> + * @cur_task: Current task the state machine is working on
> + * @task_lock: Protect cur_task
Protect what about cur_task? Assigning and clearing a pointer is atomic.
> + * @statemachine: Work item for the DOE state machine
Why does the pci_doe_mb have a work item? I would expect a work item per
task. Then this gets a waitqueue for free to wait for task completion.
Otherwise I suspect this introduces complexity in the DOE implementation
to simulate per-task-work that a workqueue per DOE and a work item per
task gets you for free, and for recalling hardware context from one
firing of the state machine to the next. Just run the task work all
in-line in one context.
> + * @state: Current state of this DOE
> + * @timeout_jiffies: 1 second after GO set
> + * @busy_retries: Count of retry attempts
Why is this tracked in the mailbox object itself?
> + * @flags: Bit array of PCI_DOE_FLAG_* flags
> + *
> + * Note: @prots can't be allocated with struct size because the number of
> + * protocols is not known until after this structure is in use. However, the
> + * single discovery protocol is always required to query for the number of
> + * protocols.
Sounds like maybe this wants to be an xarray indexed by the device's
reported index.
> + */
> +struct pci_doe_mb {
> + struct pci_dev *pdev;
> + struct completion abort_c;
> + int irq;
> + struct pci_doe_protocol *prots;
> + int num_prots;
> + u16 cap_offset;
> +
> + wait_queue_head_t wq;
> + struct pci_doe_task *cur_task;
> + spinlock_t task_lock;
> + struct delayed_work statemachine;
> + enum pci_doe_state state;
> + unsigned long timeout_jiffies;
> + unsigned int busy_retries;
> + unsigned long flags;
> +};
> +
> +static irqreturn_t pci_doe_irq_handler(int irq, void *data)
> +{
> + struct pci_doe_mb *doe_mb = data;
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + u32 val;
> +
> + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> + if (FIELD_GET(PCI_DOE_STATUS_INT_STATUS, val)) {
> + pci_write_config_dword(pdev, offset + PCI_DOE_STATUS,
> + PCI_DOE_STATUS_INT_STATUS);
> + mod_delayed_work(system_wq, &doe_mb->statemachine, 0);
Wait, no, not system_wq. I expected this wants a dedicated / ordered queue
per doe and this likely wants a queue that can sleep while processing a
task and just not support overlapping tasks.
In that model the irq is just waking up any tasks in execution that are
awaiting a polling timeout. The irq handler does:
wake_up(&doe_mb->wait);
...and then task that is executing in the queue continues what it was
doing.
> + return IRQ_HANDLED;
> + }
> +
> + return IRQ_NONE;
> +}
> +
> +/*
> + * Only called when safe to directly access the DOE from
> + * doe_statemachine_work(). Outside access is not protected. Users who
> + * perform such access are left with the pieces.
What pieces, where? I expect the abort implementation would be something
like:
set_bit(ABORT_PENDING) <== blocks new task submissions until clear
flush_workqueue() <== make sure all in-flight tasks see the abort
do_doe_abort(...) <== do the abort
clear_bit(ABORT_PENDING) <== optionally restart the tasks that were
cancelled, or just expect them to be resubmitted.
> + */
> +static void pci_doe_abort_start(struct pci_doe_mb *doe_mb)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + u32 val;
> +
> + val = PCI_DOE_CTRL_ABORT;
> + if (doe_mb->irq >= 0)
> + val |= PCI_DOE_CTRL_INT_EN;
> + pci_write_config_dword(pdev, offset + PCI_DOE_CTRL, val);
> +
> + doe_mb->timeout_jiffies = jiffies + HZ;
> + schedule_delayed_work(&doe_mb->statemachine, HZ);
> +}
> +
> +static int pci_doe_send_req(struct pci_doe_mb *doe_mb,
> + struct pci_doe_task *task)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + 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, offset + 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, task->prot.vid) |
> + FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, task->prot.type);
> + pci_write_config_dword(pdev, offset + PCI_DOE_WRITE, val);
> + /* Length is 2 DW of header + length of payload in DW */
> + pci_write_config_dword(pdev, offset + PCI_DOE_WRITE,
> + FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH,
> + 2 + task->request_pl_sz /
> + sizeof(u32)));
> + for (i = 0; i < task->request_pl_sz / sizeof(u32); i++)
> + pci_write_config_dword(pdev, offset + PCI_DOE_WRITE,
> + task->request_pl[i]);
> +
> + val = PCI_DOE_CTRL_GO;
> + if (doe_mb->irq >= 0)
> + val |= PCI_DOE_CTRL_INT_EN;
> +
> + pci_write_config_dword(pdev, offset + PCI_DOE_CTRL, val);
> + /* Request is sent - now wait for poll or IRQ */
> + return 0;
> +}
> +
> +static bool pci_doe_data_obj_ready(struct pci_doe_mb *doe_mb)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + u32 val;
> +
> + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> + if (FIELD_GET(PCI_DOE_STATUS_DATA_OBJECT_READY, val))
> + return true;
> + return false;
> +}
> +
> +static int pci_doe_recv_resp(struct pci_doe_mb *doe_mb, struct pci_doe_task *task)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + size_t length, payload_length;
> + u32 val;
> + int i;
> +
> + /* Read the first dword to get the protocol */
> + pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
> + if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != task->prot.vid) ||
> + (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != task->prot.type)) {
> + pci_err(pdev,
> + "DOE [%x] expected [VID, Protocol] = [%04x, %02x], got [%04x, %02x]\n",
> + doe_mb->cap_offset,
> + task->prot.vid, task->prot.type,
> + 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, offset + PCI_DOE_READ, 0);
> + /* Read the second dword to get the length */
> + pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
> + pci_write_config_dword(pdev, offset + PCI_DOE_READ, 0);
> +
> + length = FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH, val);
> + if (length > SZ_1M || length < 2)
> + return -EIO;
> +
> + /* First 2 dwords have already been read */
> + length -= 2;
> + payload_length = min(length, task->response_pl_sz / sizeof(u32));
> + /* Read the rest of the response payload */
> + for (i = 0; i < payload_length; i++) {
> + pci_read_config_dword(pdev, offset + PCI_DOE_READ,
> + &task->response_pl[i]);
> + /* Prior to the last ack, ensure Data Object Ready */
> + if (i == (payload_length-1) && !pci_doe_data_obj_ready(doe_mb))
> + return -EIO;
> + pci_write_config_dword(pdev, offset + PCI_DOE_READ, 0);
> + }
> +
> + /* Flush excess length */
> + for (; i < length; i++) {
> + pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
> + pci_write_config_dword(pdev, offset + PCI_DOE_READ, 0);
> + }
> +
> + /* Final error check to pick up on any since Data Object Ready */
> + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> + if (FIELD_GET(PCI_DOE_STATUS_ERROR, val))
> + return -EIO;
> +
> + return min(length, task->response_pl_sz / sizeof(u32)) * sizeof(u32);
> +}
> +
> +static void signal_task_complete(struct pci_doe_task *task, int rv)
> +{
> + task->rv = rv;
> + task->complete(task);
> +}
> +
> +static void retire_cur_task(struct pci_doe_mb *doe_mb)
> +{
> + spin_lock(&doe_mb->task_lock);
> + doe_mb->cur_task = NULL;
> + spin_unlock(&doe_mb->task_lock);
What is the lock protecting here? Assigning a pointer is atomic, I think
this question is moot with a work-item per-task model as retiring the
task is just a typical work completion.
> + wake_up_interruptible(&doe_mb->wq);
> +}
> +
> +static void doe_statemachine_work(struct work_struct *work)
> +{
> + struct delayed_work *w = to_delayed_work(work);
> + struct pci_doe_mb *doe_mb = container_of(w, struct pci_doe_mb,
> + statemachine);
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + enum pci_doe_state prev_state;
> + struct pci_doe_task *task;
> + u32 val;
> + int rc;
> +
> + spin_lock(&doe_mb->task_lock);
> + task = doe_mb->cur_task;
> + spin_unlock(&doe_mb->task_lock);
> +
> + if (test_and_clear_bit(PCI_DOE_FLAG_ABORT, &doe_mb->flags)) {
> + /*
> + * Currently only used during init - care needed if
> + * pci_doe_abort() is generally exposed as it would impact
> + * queries in flight.
> + */
> + if (task)
> + pci_err(pdev, "DOE [%x] Aborting with active task!\n",
> + doe_mb->cap_offset);
> + doe_mb->state = DOE_WAIT_ABORT;
> + pci_doe_abort_start(doe_mb);
> + return;
> + }
> +
> + switch (doe_mb->state) {
> + case DOE_IDLE:
> + if (task == NULL)
> + return;
> +
> + rc = pci_doe_send_req(doe_mb, task);
> +
> + /*
> + * 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_mb->busy_retries++;
> + if (doe_mb->busy_retries == PCI_DOE_BUSY_MAX_RETRIES) {
> + /* Long enough, fail this request */
> + pci_warn(pdev,
> + "DOE [%x] busy for too long (> 1 sec)\n",
> + doe_mb->cap_offset);
> + doe_mb->busy_retries = 0;
> + goto err_busy;
> + }
> + schedule_delayed_work(w, HZ / PCI_DOE_BUSY_MAX_RETRIES);
> + return;
> + }
> + if (rc)
> + goto err_abort;
> + doe_mb->busy_retries = 0;
> +
> + doe_mb->state = DOE_WAIT_RESP;
> + doe_mb->timeout_jiffies = jiffies + HZ;
> + /* Now poll or wait for IRQ with timeout */
> + if (doe_mb->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, offset + 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_mb->timeout_jiffies)) {
> + rc = -ETIMEDOUT;
> + goto err_abort;
> + }
> + schedule_delayed_work(w, PCI_DOE_POLL_INTERVAL);
> + return;
> + }
> +
> + rc = pci_doe_recv_resp(doe_mb, task);
> + if (rc < 0)
> + goto err_abort;
> +
> + doe_mb->state = DOE_IDLE;
> +
> + retire_cur_task(doe_mb);
> + /* Set the return value to the length of received payload */
> + signal_task_complete(task, rc);
> +
> + return;
> +
> + case DOE_WAIT_ABORT:
> + case DOE_WAIT_ABORT_ON_ERR:
> + prev_state = doe_mb->state;
> +
> + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> +
> + if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) &&
> + !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) {
> + doe_mb->state = DOE_IDLE;
> + /* Back to normal state - carry on */
> + retire_cur_task(doe_mb);
> + } else if (time_after(jiffies, doe_mb->timeout_jiffies)) {
> + /* Task has timed out and is dead - abort */
> + pci_err(pdev, "DOE [%x] ABORT timed out\n",
> + doe_mb->cap_offset);
> + set_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags);
> + retire_cur_task(doe_mb);
> + }
> +
> + /*
> + * For deliberately triggered abort, someone is
> + * waiting.
> + */
> + if (prev_state == DOE_WAIT_ABORT) {
> + if (task)
> + signal_task_complete(task, -EFAULT);
> + complete(&doe_mb->abort_c);
> + }
> +
> + return;
> + }
> +
> +err_abort:
> + doe_mb->state = DOE_WAIT_ABORT_ON_ERR;
> + pci_doe_abort_start(doe_mb);
> +err_busy:
> + signal_task_complete(task, rc);
> + if (doe_mb->state == DOE_IDLE)
> + retire_cur_task(doe_mb);
> +}
> +
> +static void pci_doe_task_complete(struct pci_doe_task *task)
> +{
> + complete(task->private);
> +}
> +
> +static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
> + u8 *protocol)
> +{
> + u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
> + *index);
> + u32 response_pl;
> + DECLARE_COMPLETION_ONSTACK(c);
> + struct pci_doe_task task = {
> + .prot.vid = PCI_VENDOR_ID_PCI_SIG,
> + .prot.type = PCI_DOE_PROTOCOL_DISCOVERY,
> + .request_pl = &request_pl,
> + .request_pl_sz = sizeof(request_pl),
> + .response_pl = &response_pl,
> + .response_pl_sz = sizeof(response_pl),
> + .complete = pci_doe_task_complete,
> + .private = &c,
> + };
> + int ret;
> +
> + ret = pci_doe_submit_task(doe_mb, &task);
> + if (ret < 0)
> + return ret;
> +
> + wait_for_completion(&c);
Another place where the need for a completion can be replaced with
flush_work(). The only thing flush_work() does not offer is the option
to have an interruptible wait, but for in-kernel DOE cycles
uninterruptible is ok.
> +
> + if (task.rv != 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_mb *doe_mb)
> +{
> + u8 index = 0;
> + int num_prots;
> + int rc;
> +
> + /* Discovery protocol must always be supported and must report itself */
> + num_prots = 1;
> +
> + doe_mb->prots = kcalloc(num_prots, sizeof(*doe_mb->prots), GFP_KERNEL);
> + if (!doe_mb->prots)
> + return -ENOMEM;
> +
> + /*
> + * NOTE: doe_mb_prots is freed by pci_doe_free_mb() automatically on
> + * error if pci_doe_cache_protocols() fails past this point.
> + */
> + do {
> + struct pci_doe_protocol *prot;
> +
> + prot = &doe_mb->prots[num_prots - 1];
> + rc = pci_doe_discovery(doe_mb, &index, &prot->vid, &prot->type);
> + if (rc)
> + return rc;
> +
> + if (index) {
> + struct pci_doe_protocol *prot_new;
> +
> + num_prots++;
> + prot_new = krealloc(doe_mb->prots,
> + sizeof(*doe_mb->prots) * num_prots,
> + GFP_KERNEL);
An xarray saves the need for krealloc(), and probably even the need for
a separate 'struct pci_doe_protocol' allocation since that data fits
into an unsigned long that the xarray is already allocating for you
internally.
So something like:
struct pci_doe_protocol {
union {
unsigned long val;
struct {
u16 vid;
u8 type;
};
};
} prot;
pci_doe_discovery(doe_mb, &index, &prot.vid, &prot.type);
xa_insert(&doe_mb->prots, (unsigned long) index, (void *) prot.val, GFP_KERNEL);
...and then to retrieve:
void *ent = xa_load(&doe_mb->prots, index);
struct pci_doe_protocol prot = { .val = (unsigned long) ent };
...wrapped up nicely with helpers to hide all the casting.
> + if (!prot_new)
> + return -ENOMEM;
> +
> + doe_mb->prots = prot_new;
> + }
> + } while (index);
> +
> + doe_mb->num_prots = num_prots;
> + return 0;
> +}
> +
> +static int pci_doe_abort(struct pci_doe_mb *doe_mb)
> +{
> + reinit_completion(&doe_mb->abort_c);
> + set_bit(PCI_DOE_FLAG_ABORT, &doe_mb->flags);
> + schedule_delayed_work(&doe_mb->statemachine, 0);
> + wait_for_completion(&doe_mb->abort_c);
> +
> + if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags))
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static int pci_doe_enable_irq(struct pci_doe_mb *doe_mb, unsigned int irq)
> +{
> + struct pci_dev *pdev = doe_mb->pdev;
> + int offset = doe_mb->cap_offset;
> + int rc;
> +
> + /*
> + * Enabling bus mastering is required for MSI/MSIx. It is safe to call
> + * this multiple times and thus is called here to ensure that mastering
> + * is enabled even if the driver has done so.
> + */
It is required for MSI/MSIx to work, yes, but if the caller that created
the doe object has not set it yet that's its prerogative.
> + pci_set_master(pdev);
> + rc = pci_request_irq(pdev, irq, pci_doe_irq_handler, NULL, doe_mb,
> + "DOE[%d:%s]", irq, pci_name(pdev));
If the DOE object creation is use devm_ then this wants to be
devm_request_irq(), although I now notice that devm_pci_doe_create()
only existed in the code comments, not the implementation.
Is there any need for the unmanaged version of this API?
> + if (rc)
> + return rc;
> +
> + doe_mb->irq = irq;
> + pci_write_config_dword(pdev, offset + PCI_DOE_CTRL,
> + PCI_DOE_CTRL_INT_EN);
> + return 0;
> +}
> +
> +static void pci_doe_free_mb(struct pci_doe_mb *doe_mb)
> +{
> + if (doe_mb->irq >= 0)
> + pci_free_irq(doe_mb->pdev, doe_mb->irq, doe_mb);
> + kfree(doe_mb->prots);
> + kfree(doe_mb);
> +}
> +
> +/**
> + * pci_doe_get_irq_num() - Return the irq number for the mailbox at offset
> + *
> + * @pdev: The PCI device
> + * @offset: Offset of the DOE mailbox
> + *
> + * Returns: irq number on success
> + * -errno if irqs are not supported on this mailbox
> + */
> +int pci_doe_get_irq_num(struct pci_dev *pdev, int offset)
> +{
> + u32 val;
> +
> + pci_read_config_dword(pdev, offset + PCI_DOE_CAP, &val);
> + if (!FIELD_GET(PCI_DOE_CAP_INT, val))
> + return -EOPNOTSUPP;
I think ENXIO would be more appropriate than this networking errno.
> +
> + return FIELD_GET(PCI_DOE_CAP_IRQ, val);
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_get_irq_num);
> +
> +/**
> + * pci_doe_create_mb() - Create a DOE mailbox object
> + *
> + * @pdev: PCI device to create the DOE mailbox for
> + * @cap_offset: Offset of the DOE mailbox
> + * @irq: irq number to use; a negative value means don't use interrupts
> + *
> + * Create a single mailbox object to manage the mailbox protocol at the
> + * cap_offset specified.
> + *
> + * Caller should allocate PCI IRQ vectors before setting use_irq.
> + *
> + * RETURNS: created mailbox object on success
> + * ERR_PTR(-errno) on failure
> + */
> +struct pci_doe_mb *pci_doe_create_mb(struct pci_dev *pdev, u16 cap_offset,
> + int irq)
> +{
> + struct pci_doe_mb *doe_mb;
> + int rc;
> +
> + doe_mb = kzalloc(sizeof(*doe_mb), GFP_KERNEL);
> + if (!doe_mb)
> + return ERR_PTR(-ENOMEM);
> +
> + doe_mb->pdev = pdev;
> + init_completion(&doe_mb->abort_c);
> + doe_mb->irq = -1;
> + doe_mb->cap_offset = cap_offset;
> +
> + init_waitqueue_head(&doe_mb->wq);
> + spin_lock_init(&doe_mb->task_lock);
> + INIT_DELAYED_WORK(&doe_mb->statemachine, doe_statemachine_work);
> + doe_mb->state = DOE_IDLE;
> +
> + if (irq >= 0) {
> + rc = pci_doe_enable_irq(doe_mb, irq);
> + if (rc)
> + pci_err(pdev,
> + "DOE [%x] enable requested IRQ (%d) failed : %d\n",
> + doe_mb->cap_offset, irq, rc);
> + }
> +
> + /* Reset the mailbox by issuing an abort */
> + rc = pci_doe_abort(doe_mb);
> + if (rc) {
> + pci_err(pdev, "DOE [%x] failed to reset : %d\n",
> + doe_mb->cap_offset, rc);
> + pci_doe_free_mb(doe_mb);
> + return ERR_PTR(rc);
> + }
> +
> + rc = pci_doe_cache_protocols(doe_mb);
> + if (rc) {
> + pci_err(pdev, "DOE [%x] failed to cache protocols : %d\n",
> + doe_mb->cap_offset, rc);
> + pci_doe_free_mb(doe_mb);
> + return ERR_PTR(rc);
> + }
> +
> + return doe_mb;
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_create_mb);
> +
> +/**
> + * pci_doe_supports_prot() - Return if the DOE instance supports the given
> + * protocol
> + * @doe_mb: DOE mailbox capability to query
> + * @vid: Protocol Vendor ID
> + * @type: Protocol type
> + *
> + * RETURNS: True if the DOE mailbox supports the protocol specified
> + */
> +bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type)
> +{
> + int i;
> +
> + /* The discovery protocol must always be supported */
> + if (vid == PCI_VENDOR_ID_PCI_SIG && type == PCI_DOE_PROTOCOL_DISCOVERY)
> + return true;
> +
> + for (i = 0; i < doe_mb->num_prots; i++)
> + if ((doe_mb->prots[i].vid == vid) &&
> + (doe_mb->prots[i].type == type))
> + return true;
This becomes an xa_for_each() loop and I don't think you even need
->num_prots after this conversion.
> +
> + return false;
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_supports_prot);
> +
> +/**
> + * pci_doe_submit_task() - Submit a task to be processed by the state machine
> + *
> + * @doe_mb: DOE mailbox capability to submit to
> + * @task: task to be queued
> + *
> + * Submit a DOE task (request/response) to the DOE mailbox to be processed.
> + * Returns upon queueing the task object. If the queue is full this function
> + * will sleep until there is room in the queue.
> + *
> + * task->complete will be called when the state machine is done processing this
> + * task.
> + *
> + * Excess data will be discarded.
> + *
> + * RETURNS: 0 when task has been successful queued, -ERRNO on error
> + */
> +int pci_doe_submit_task(struct pci_doe_mb *doe_mb, struct pci_doe_task *task)
> +{
> + if (!pci_doe_supports_prot(doe_mb, task->prot.vid, task->prot.type))
> + return -EINVAL;
> +
> + /* DOE requests must be a whole number of DW */
> + if (task->request_pl_sz % sizeof(u32))
> + return -EINVAL;
> +
> +again:
> + spin_lock(&doe_mb->task_lock);
> + if (doe_mb->cur_task) {
> + spin_unlock(&doe_mb->task_lock);
> + wait_event_interruptible(doe_mb->wq, doe_mb->cur_task == NULL);
> + goto again;
> + }
This looks like it will scramble the order of competing submissions.
With a work-item per task there may be a race to who call queue_work()
first, but there will not follow-on races like the ones here for this
"goto again" case.
> + if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags)) {
> + spin_unlock(&doe_mb->task_lock);
> + return -EIO;
> + }
> + doe_mb->cur_task = task;
> + spin_unlock(&doe_mb->task_lock);
> + schedule_delayed_work(&doe_mb->statemachine, 0);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_submit_task);
> +
> +/**
> + * pci_doe_destroy_mb() - Destroy a DOE mailbox object created with
> + * pci_doe_create_mb()
> + *
> + * @doe_mb: DOE mailbox capability structure to destroy
> + *
> + * The mailbox becomes invalid and should not be used after this call.
> + */
> +void pci_doe_destroy_mb(struct pci_doe_mb *doe_mb)
> +{
> + /* abort any work in progress */
> + pci_doe_abort(doe_mb);
> +
> + /* halt the state machine */
> + cancel_delayed_work_sync(&doe_mb->statemachine);
> +
> + pci_doe_free_mb(doe_mb);
Where do racing submitters get told that the DOE is closed for business?
> +}
> +EXPORT_SYMBOL_GPL(pci_doe_destroy_mb);
> diff --git a/include/linux/pci-doe.h b/include/linux/pci-doe.h
> new file mode 100644
> index 000000000000..4623881d0e3e
> --- /dev/null
> +++ b/include/linux/pci-doe.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Data Object Exchange
> + * PCIe r6.0, sec 6.30 DOE
> + *
> + * Copyright (C) 2021 Huawei
> + * Jonathan Cameron <Jonathan.Cameron@huawei.com>
> + *
> + * Copyright (C) 2022 Intel Corporation
> + * Ira Weiny <ira.weiny@intel.com>
> + */
> +
> +#ifndef LINUX_PCI_DOE_H
> +#define LINUX_PCI_DOE_H
> +
> +#include <linux/completion.h>
> +
> +struct pci_doe_protocol {
> + u16 vid;
> + u8 type;
> +};
> +
> +/**
> + * struct pci_doe_task - represents a single query/response
> + *
> + * @prot: DOE Protocol
> + * @request_pl: The request payload
> + * @request_pl_sz: Size of the request payload
> + * @response_pl: The response payload
> + * @response_pl_sz: Size of the response payload
> + * @rv: Return value. Length of received response or error
> + * @complete: Called when task is complete
> + * @private: Private data for the consumer
> + */
> +struct pci_doe_task {
> + struct pci_doe_protocol prot;
> + u32 *request_pl;
> + size_t request_pl_sz;
> + u32 *response_pl;
> + size_t response_pl_sz;
> + int rv;
> + void (*complete)(struct pci_doe_task *task);
> + void *private;
> +};
> +
> +/**
> + * pci_doe_for_each_off - Iterate each DOE capability
> + * @pdev: struct pci_dev to iterate
> + * @off: u16 of config space offset of each mailbox capability found
> + */
> +#define pci_doe_for_each_off(pdev, off) \
> + for (off = pci_find_next_ext_capability(pdev, off, \
> + PCI_EXT_CAP_ID_DOE); \
> + off > 0; \
> + off = pci_find_next_ext_capability(pdev, off, \
> + PCI_EXT_CAP_ID_DOE))
New for loop macros should also be added to .clang-format.
> +
> +int pci_doe_get_irq_num(struct pci_dev *pdev, int offset);
> +struct pci_doe_mb *pci_doe_create_mb(struct pci_dev *pdev, u16 cap_offset,
> + int irq);
> +void pci_doe_destroy_mb(struct pci_doe_mb *doe_mb);
> +bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type);
> +int pci_doe_submit_task(struct pci_doe_mb *doe_mb, struct pci_doe_task *task);
> +
> +#endif
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index bee1a9ed6e66..4e96b45ee36d 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -736,7 +736,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
> @@ -1102,4 +1103,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.35.1
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices
2022-06-10 20:22 ` [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices ira.weiny
2022-06-17 20:40 ` [PATCH v11 " Davidlohr Bueso
@ 2022-06-17 23:44 ` Dan Williams
2022-06-21 18:29 ` Ira Weiny
2022-06-21 20:37 ` Bjorn Helgaas
2 siblings, 1 reply; 44+ messages in thread
From: Dan Williams @ 2022-06-17 23:44 UTC (permalink / raw)
To: ira.weiny, Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Ben Widawsky, Alison Schofield, Vishal Verma,
Dave Jiang, linux-kernel, linux-cxl, linux-pci
ira.weiny@ wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> DOE mailbox objects will be needed for various mailbox communications
> with each memory device.
>
> Iterate each DOE mailbox capability and create PCI DOE mailbox objects
> as found.
>
> It is not anticipated that this is the final resting place for the
> iteration of the DOE devices. The support of ports may drive this code
> into the pcie side. In this imagined architecture the CXL port driver
> would then query into the PCI device for the DOE mailbox array.
>
> For now this is good enough for the endpoints and the split is similar
> to the envisioned architecture where getting the mailbox array is
> separated from the various protocol needs. For example, it is not
> anticipated that the CDAT code will need to move because it is only
> needed by the cxl_ports.
>
> Likewise irq's are separated out in a similar design pattern to the
> PCIe port driver. But a much simpler irq enabling flag is used and only
> DOE interrupts are supported.
>
> Reviewed-by: Ben Widawsky <bwidawsk@kernel.org>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> ---
> Changes from V9:
> Bug fix: ensure DOE mailboxes are iterated before memdev add
> Ben Widawsky
> Set use_irq to false and just return on error.
> Don't return a value from devm_cxl_pci_create_doe()
> Skip allocating doe_mb array if there are no mailboxes
> Skip requesting irqs if none found.
> Ben/Jonathan Cameron
> s/num_irqs/max_irqs
>
> Changes from V8:
> Move PCI_DOE selection to CXL_BUS to support future patches
> which move queries into the port code.
> Remove Auxiliary device arch
> Squash the functionality of the auxiliary driver into this
> patch.
> Split out the irq handling a bit.
>
> Changes from V7:
> Minor code clean ups
> Rebased on cxl-pending
>
> Changes from V6:
> Move all the auxiliary device stuff to the CXL layer
>
> Changes from V5:
> Split the CXL specific stuff off from the PCI DOE create
> auxiliary device code.
> ---
> drivers/cxl/Kconfig | 1 +
> drivers/cxl/cxlmem.h | 6 +++
> drivers/cxl/pci.c | 114 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 121 insertions(+)
>
> diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> index f64e3984689f..7adaaf80b302 100644
> --- a/drivers/cxl/Kconfig
> +++ b/drivers/cxl/Kconfig
> @@ -2,6 +2,7 @@
> menuconfig CXL_BUS
> tristate "CXL (Compute Express Link) Devices Support"
> depends on PCI
> + select PCI_DOE
> help
> CXL is a bus that is electrically compatible with PCI Express, but
> layers three protocols on that signalling (CXL.io, CXL.cache, and
> diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
> index 60d10ee1e7fc..4d2764b865ab 100644
> --- a/drivers/cxl/cxlmem.h
> +++ b/drivers/cxl/cxlmem.h
> @@ -191,6 +191,8 @@ struct cxl_endpoint_dvsec_info {
> * @component_reg_phys: register base of component registers
> * @info: Cached DVSEC information about the device.
> * @serial: PCIe Device Serial Number
> + * @doe_mbs: PCI DOE mailbox array
> + * @num_mbs: Number of DOE mailboxes
> * @mbox_send: @dev specific transport for transmitting mailbox commands
> *
> * See section 8.2.9.5.2 Capacity Configuration and Label Storage for
> @@ -224,6 +226,10 @@ struct cxl_dev_state {
> resource_size_t component_reg_phys;
> u64 serial;
>
> + bool doe_use_irq;
Don't pass temporary state through a long lived data structure. Just
pass flag by reference between the functions that want to coordinate
this.
> + struct pci_doe_mb **doe_mbs;
> + int num_mbs;
> +
> int (*mbox_send)(struct cxl_dev_state *cxlds, struct cxl_mbox_cmd *cmd);
> };
>
> diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
> index 5a0ae46d4989..72c7b535f5df 100644
> --- a/drivers/cxl/pci.c
> +++ b/drivers/cxl/pci.c
> @@ -8,6 +8,7 @@
> #include <linux/mutex.h>
> #include <linux/list.h>
> #include <linux/pci.h>
> +#include <linux/pci-doe.h>
> #include <linux/io.h>
> #include "cxlmem.h"
> #include "cxlpci.h"
> @@ -386,6 +387,116 @@ static int cxl_setup_regs(struct pci_dev *pdev, enum cxl_regloc_type type,
> return rc;
> }
>
> +static void cxl_pci_free_irq_vectors(void *data)
> +{
> + pci_free_irq_vectors(data);
> +}
> +
> +static void cxl_doe_destroy_mb(void *ds)
> +{
> + struct cxl_dev_state *cxlds = ds;
> + int i;
> +
> + for (i = 0; i < cxlds->num_mbs; i++) {
> + if (cxlds->doe_mbs[i])
> + pci_doe_destroy_mb(cxlds->doe_mbs[i]);
> + }
> +}
> +
> +static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
> +{
> + struct device *dev = cxlds->dev;
> + struct pci_dev *pdev = to_pci_dev(dev);
> + int max_irqs = 0;
> + int off = 0;
> + int rc;
> +
> + /* Account for all the DOE vectors needed */
> + pci_doe_for_each_off(pdev, off) {
> + int irq = pci_doe_get_irq_num(pdev, off);
> +
> + if (irq < 0)
> + continue;
> + max_irqs = max(max_irqs, irq + 1);
This seems to assume that different DOEs will get independent vectors.
The driver needs to be prepared for DOE instances, Event notifications,
and mailbox commands to share a single MSI vector in the worst case.
Lets focus on polled mode DOE, or explicitly only support interrupt
based operation when no vector sharing is detected.
> + }
> +
> + if (!max_irqs)
> + return;
> +
> + cxlds->doe_use_irq = false;
> +
> + /*
> + * Allocate enough vectors for the DOE's
> + */
> + rc = pci_alloc_irq_vectors(pdev, max_irqs, max_irqs, PCI_IRQ_MSI |
> + PCI_IRQ_MSIX);
> + if (rc != max_irqs) {
> + pci_err(pdev, "Not enough interrupts; use polling\n");
> + /* Some got allocated; clean them up */
> + if (rc > 0)
> + cxl_pci_free_irq_vectors(pdev);
> + return;
> + }
> +
> + rc = devm_add_action_or_reset(dev, cxl_pci_free_irq_vectors, pdev);
> + if (rc)
> + return;
> +
> + cxlds->doe_use_irq = true;
> +}
> +
> +/**
> + * devm_cxl_pci_create_doe - Scan and set up DOE mailboxes
> + *
> + * @cxlds: The CXL device state
> + */
> +static void devm_cxl_pci_create_doe(struct cxl_dev_state *cxlds)
> +{
> + struct device *dev = cxlds->dev;
> + struct pci_dev *pdev = to_pci_dev(dev);
> + u16 off = 0;
> + int num_mbs = 0;
> + int rc;
> +
> + pci_doe_for_each_off(pdev, off)
> + num_mbs++;
> +
> + if (!num_mbs) {
> + pci_dbg(pdev, "0 DOE mailbox's found\n");
> + return;
> + }
> +
> + cxlds->doe_mbs = devm_kcalloc(dev, num_mbs, sizeof(*cxlds->doe_mbs),
> + GFP_KERNEL);
> + if (!cxlds->doe_mbs)
> + return;
> +
> + pci_doe_for_each_off(pdev, off) {
> + struct pci_doe_mb *doe_mb;
> + int irq = -1;
> +
> + if (cxlds->doe_use_irq)
> + irq = pci_doe_get_irq_num(pdev, off);
> +
> + doe_mb = pci_doe_create_mb(pdev, off, irq);
> + if (IS_ERR(doe_mb)) {
> + pci_err(pdev,
> + "Failed to create MB object for MB @ %x\n",
> + off);
> + doe_mb = NULL;
> + }
> +
> + cxlds->doe_mbs[cxlds->num_mbs] = doe_mb;
> + cxlds->num_mbs++;
> + }
> +
> + rc = devm_add_action_or_reset(dev, cxl_doe_destroy_mb, cxlds);
> + if (rc)
> + return;
> +
> + pci_info(pdev, "Configured %d DOE mailbox's\n", cxlds->num_mbs);
> +}
> +
> static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> {
> struct cxl_register_map map;
> @@ -434,6 +545,9 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>
> cxlds->component_reg_phys = cxl_regmap_to_base(pdev, &map);
>
> + cxl_alloc_irq_vectors(cxlds);
> + devm_cxl_pci_create_doe(cxlds);
> +
> rc = cxl_pci_setup_mailbox(cxlds);
> if (rc)
> return rc;
> --
> 2.35.1
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: [PATCH V11 5/8] cxl/port: Read CDAT table
2022-06-10 20:22 ` [PATCH V11 5/8] cxl/port: Read CDAT table ira.weiny
@ 2022-06-18 0:43 ` Dan Williams
2022-06-21 19:10 ` Dan Williams
2022-06-21 21:14 ` Ira Weiny
0 siblings, 2 replies; 44+ messages in thread
From: Dan Williams @ 2022-06-18 0:43 UTC (permalink / raw)
To: ira.weiny, Dan Williams, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Alison Schofield, Vishal Verma, Dave Jiang,
Ben Widawsky, linux-kernel, linux-cxl, linux-pci
ira.weiny@ wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> The OS will need CDAT data from CXL devices to properly set up
> interleave sets. Currently this is supported through a DOE mailbox
> which supports CDAT.
>
> Search the DOE mailboxes available, query CDAT data, and cache the data
> for later parsing.
>
> Provide a sysfs binary attribute to allow dumping of the CDAT.
>
> 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.
>
> This does not support table updates at runtime. It will always provide
> whatever was there when first cached. Handling of table updates can be
> implemented later.
>
> Finally create a complete list of CDAT defines within cdat.h for code
> wishing to decode the CDAT table.
>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Co-developed-by: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> ---
> Changes from V10:
> Ben Widawsky
> Failure to find CDAT should be a debug message not error
> Remove reference to cdat_mb from the port object
> Dropped [PATCH V10 5/9] cxl/port: Find a DOE mailbox which supports
> CDAT
> Iterate the mailboxes for the CDAT one each time.
> Define CXL_DOE_TABLE_ACCESS_LAST_ENTRY and add comment about
> it's use.
>
> Changes from V9:
> Add debugging output
> Jonathan Cameron
> Move read_cdat to port probe by using dev_groups for the
> sysfs attributes. This avoids issues with using devm
> before the driver is loaded while making sure the CDAT
> binary is available.
>
> Changes from V8:
> Fix length print format
> Incorporate feedback from Jonathan
> Move all this to cxl_port which can help support switches when
> the time comes.
>
> Changes from V6:
> Fix issue with devm use
> Move cached cdat data to cxl_dev_state
> Use new pci_doe_submit_task()
> Ensure the aux driver is locked while processing tasks
> Rebased on cxl-pending
>
> Changes from V5:
> Add proper guards around cdat.h
> Split out finding the CDAT DOE mailbox
> Use cxl_cdat to group CDAT data together
> Adjust to use auxiliary_find_device() to find the DOE device
> which supplies the CDAT protocol.
> Rebased to latest
> Remove dev_dbg(length)
> Remove unneeded DOE Table access defines
> Move CXL_DOE_PROTOCOL_TABLE_ACCESS define into this patch where
> it is used
>
> Changes from V4:
> Split this into it's own patch
> Rearchitect this such that the memdev driver calls into the DOE
> driver via the cxl_mem state object. This allows CDAT data to
> come from any type of cxl_mem object not just PCI DOE.
> Rebase on new struct cxl_dev_state
> ---
> drivers/cxl/cdat.h | 100 ++++++++++++++++++++++++
> drivers/cxl/core/pci.c | 172 +++++++++++++++++++++++++++++++++++++++++
> drivers/cxl/cxl.h | 3 +
> drivers/cxl/cxlpci.h | 1 +
> drivers/cxl/port.c | 51 ++++++++++++
> 5 files changed, 327 insertions(+)
> create mode 100644 drivers/cxl/cdat.h
>
> diff --git a/drivers/cxl/cdat.h b/drivers/cxl/cdat.h
> new file mode 100644
> index 000000000000..c6a48ab326bf
> --- /dev/null
> +++ b/drivers/cxl/cdat.h
> @@ -0,0 +1,100 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __CXL_CDAT_H__
> +#define __CXL_CDAT_H__
> +
> +/*
> + * 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
> +#define CXL_DOE_TABLE_ACCESS_LAST_ENTRY 0xffff
> +
> +/*
> + * 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 4
> +#define CDAT_HEADER_LENGTH_BYTES (CDAT_HEADER_LENGTH_DW * sizeof(u32))
> +#define CDAT_HEADER_DW0_LENGTH 0xffffffff
> +#define CDAT_HEADER_DW1_REVISION 0x000000ff
> +#define CDAT_HEADER_DW1_CHECKSUM 0x0000ff00
> +/* CDAT_HEADER_DW2_RESERVED */
> +#define CDAT_HEADER_DW3_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])
> +#define CDAT_DSMAS_NON_VOLATILE(flags) ((flags & 0x04) >> 2)
> +
> +/* 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)
> +
> +#define CXL_DOE_PROTOCOL_TABLE_ACCESS 2
> +
> +/**
> + * struct cxl_cdat - CXL CDAT data
> + *
> + * @table: cache of CDAT table
> + * @length: length of cached CDAT table
> + */
> +struct cxl_cdat {
> + void *table;
> + size_t length;
> +};
> +
> +#endif /* !__CXL_CDAT_H__ */
> diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
> index c4c99ff7b55e..84dc82f7dff0 100644
> --- a/drivers/cxl/core/pci.c
> +++ b/drivers/cxl/core/pci.c
> @@ -4,10 +4,12 @@
> #include <linux/device.h>
> #include <linux/delay.h>
> #include <linux/pci.h>
> +#include <linux/pci-doe.h>
> #include <cxlpci.h>
> #include <cxlmem.h>
> #include <cxl.h>
> #include "core.h"
> +#include "cdat.h"
>
> /**
> * DOC: cxl core pci
> @@ -458,3 +460,173 @@ int cxl_hdm_decode_init(struct cxl_dev_state *cxlds, struct cxl_hdm *cxlhdm)
> return 0;
> }
> EXPORT_SYMBOL_NS_GPL(cxl_hdm_decode_init, CXL);
> +
> +static struct pci_doe_mb *find_cdat_mb(struct device *uport)
> +{
> + struct cxl_memdev *cxlmd;
> + struct cxl_dev_state *cxlds;
> + int i;
> +
> + if (!is_cxl_memdev(uport))
> + return NULL;
> +
> + cxlmd = to_cxl_memdev(uport);
> + cxlds = cxlmd->cxlds;
This feels stuck between 2 worlds. Either cxl_port_probe() needs to do
the enumeration, or the attribute needs to move to be memdev relative.
Given that CXL switches are going to also have CDAT data, then the
former path needs to happen. Yes, cxl_pci still needs to do the vector
allocation, but it does not need to do the PCI DOE probing.
> +
> + for (i = 0; i < cxlds->num_mbs; i++) {
> + struct pci_doe_mb *cur = cxlds->doe_mbs[i];
> +
> + if (pci_doe_supports_prot(cur, PCI_DVSEC_VENDOR_ID_CXL,
> + CXL_DOE_PROTOCOL_TABLE_ACCESS))
> + return cur;
> + }
> +
> + return NULL;
> +}
> +
> +#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 void cxl_doe_task_complete(struct pci_doe_task *task)
> +{
> + complete(task->private);
> +}
> +
> +static int cxl_cdat_get_length(struct device *dev,
> + struct pci_doe_mb *cdat_mb,
> + size_t *length)
> +{
> + u32 cdat_request_pl = CDAT_DOE_REQ(0);
> + u32 cdat_response_pl[32];
> + DECLARE_COMPLETION_ONSTACK(c);
> + struct pci_doe_task task = {
> + .prot.vid = PCI_DVSEC_VENDOR_ID_CXL,
> + .prot.type = 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),
> + .complete = cxl_doe_task_complete,
> + .private = &c,
> + };
> + int rc = 0;
> +
> + rc = pci_doe_submit_task(cdat_mb, &task);
> + if (rc < 0) {
> + dev_err(dev, "DOE submit failed: %d", rc);
> + return rc;
> + }
> + wait_for_completion(&c);
> +
> + if (task.rv < 1)
> + return -EIO;
> +
> + *length = cdat_response_pl[1];
> + dev_dbg(dev, "CDAT length %zu\n", *length);
> +
> + return rc;
> +}
> +
> +static int cxl_cdat_read_table(struct device *dev,
> + struct pci_doe_mb *cdat_mb,
> + struct cxl_cdat *cdat)
> +{
> + size_t length = cdat->length;
> + u32 *data = cdat->table;
> + int entry_handle = 0;
> + int rc = 0;
> +
> + do {
> + u32 cdat_request_pl = CDAT_DOE_REQ(entry_handle);
> + u32 cdat_response_pl[32];
> + DECLARE_COMPLETION_ONSTACK(c);
> + struct pci_doe_task task = {
> + .prot.vid = PCI_DVSEC_VENDOR_ID_CXL,
> + .prot.type = 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),
> + .complete = cxl_doe_task_complete,
> + .private = &c,
> + };
> + size_t entry_dw;
> + u32 *entry;
> +
> + rc = pci_doe_submit_task(cdat_mb, &task);
> + if (rc < 0) {
> + dev_err(dev, "DOE submit failed: %d", rc);
> + return rc;
> + }
> + wait_for_completion(&c);
> +
> + /* Get the CXL table access header entry handle */
> + entry_handle = FIELD_GET(CXL_DOE_TABLE_ACCESS_ENTRY_HANDLE,
> + cdat_response_pl[0]);
> + entry = cdat_response_pl + 1;
> + entry_dw = task.rv / sizeof(u32);
> + /* Skip Header */
> + entry_dw -= 1;
> + entry_dw = min(length / 4, entry_dw);
> + memcpy(data, entry, entry_dw * sizeof(u32));
> + length -= entry_dw * sizeof(u32);
> + data += entry_dw;
> +
> + } while (entry_handle != CXL_DOE_TABLE_ACCESS_LAST_ENTRY);
> +
> + return rc;
> +}
> +
> +/**
> + * read_cdat_data - Read the CDAT data on this port
> + * @port: Port to read data from
> + *
> + * This call will sleep waiting for responses from the DOE mailbox.
> + */
> +void read_cdat_data(struct cxl_port *port)
> +{
> + static struct pci_doe_mb *cdat_mb;
> + struct device *dev = &port->dev;
> + struct device *uport = port->uport;
> + size_t cdat_length;
> + int ret;
> +
> + /*
> + * Ensure a reference on the underlying uport device which has the
> + * mailboxes in it
> + */
> + get_device(uport);
I had written up a long description grumbling about "just in case"
acquistions of device references, but then I lost that draft.
So I'll do the shorter response, but give you more homework in the
process. How / Why is that get_device() needed? What are the guarantees that
ensure you that the last reference has not been dropped just before that
call? Hint: what context is this code running?
> +
> + cdat_mb = find_cdat_mb(uport);
> + if (!cdat_mb) {
> + dev_dbg(dev, "No CDAT mailbox\n");
> + goto out;
> + }
> +
> + if (cxl_cdat_get_length(dev, cdat_mb, &cdat_length)) {
> + dev_dbg(dev, "No CDAT length\n");
> + goto out;
> + }
> +
> + port->cdat.table = devm_kzalloc(dev, cdat_length, GFP_KERNEL);
> + if (!port->cdat.table)
> + goto out;
> +
> + port->cdat.length = cdat_length;
> + ret = cxl_cdat_read_table(dev, cdat_mb, &port->cdat);
> + if (ret) {
> + /* Don't leave table data allocated on error */
> + devm_kfree(dev, port->cdat.table);
> + port->cdat.table = NULL;
> + port->cdat.length = 0;
> + dev_err(dev, "CDAT data read error\n");
Rather than a chatty / ephemeral error message I think this wants some
indication in userspace, likely the 0-length CDAT binary attribute, so
that userspace can debug why the kernel is picking sub-optimal QTG ids
for newly provisioned CXL regions.
> + }
> +
> +out:
> + put_device(uport);
> +}
> +EXPORT_SYMBOL_NS_GPL(read_cdat_data, CXL);
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 140dc3278cde..f0f5c24789bc 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -8,6 +8,7 @@
> #include <linux/bitfield.h>
> #include <linux/bitops.h>
> #include <linux/io.h>
> +#include "cdat.h"
>
> /**
> * DOC: cxl objects
> @@ -267,6 +268,7 @@ struct cxl_nvdimm {
> * @component_reg_phys: component register capability base address (optional)
> * @dead: last ep has been removed, force port re-creation
> * @depth: How deep this port is relative to the root. depth 0 is the root.
> + * @cdat: Cached CDAT data
> */
> struct cxl_port {
> struct device dev;
> @@ -278,6 +280,7 @@ struct cxl_port {
> resource_size_t component_reg_phys;
> bool dead;
> unsigned int depth;
> + struct cxl_cdat cdat;
> };
>
> /**
> diff --git a/drivers/cxl/cxlpci.h b/drivers/cxl/cxlpci.h
> index fce1c11729c2..eec597dbe763 100644
> --- a/drivers/cxl/cxlpci.h
> +++ b/drivers/cxl/cxlpci.h
> @@ -74,4 +74,5 @@ static inline resource_size_t cxl_regmap_to_base(struct pci_dev *pdev,
> int devm_cxl_port_enumerate_dports(struct cxl_port *port);
> struct cxl_dev_state;
> int cxl_hdm_decode_init(struct cxl_dev_state *cxlds, struct cxl_hdm *cxlhdm);
> +void read_cdat_data(struct cxl_port *port);
> #endif /* __CXL_PCI_H__ */
> diff --git a/drivers/cxl/port.c b/drivers/cxl/port.c
> index 3cf308f114c4..7881ce66a5de 100644
> --- a/drivers/cxl/port.c
> +++ b/drivers/cxl/port.c
> @@ -49,6 +49,9 @@ static int cxl_port_probe(struct device *dev)
> if (IS_ERR(cxlhdm))
> return PTR_ERR(cxlhdm);
>
> + /* Cache the data early to ensure is_visible() works */
> + read_cdat_data(port);
> +
> if (is_cxl_endpoint(port)) {
> struct cxl_memdev *cxlmd = to_cxl_memdev(port->uport);
> struct cxl_dev_state *cxlds = cxlmd->cxlds;
> @@ -78,10 +81,58 @@ static int cxl_port_probe(struct device *dev)
> return 0;
> }
>
> +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_port *port = to_cxl_port(dev);
> +
> + if (!port->cdat.table)
> + return 0;
> +
> + return memory_read_from_buffer(buf, count, &offset,
> + port->cdat.table,
> + port->cdat.length);
> +}
> +
> +static BIN_ATTR_RO(cdat, 0);
This should be BIN_ATTR_ADMIN_RO(), see:
3022c6a1b4b7 driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}
> +
> +static umode_t cxl_port_bin_attr_is_visible(struct kobject *kobj,
> + struct bin_attribute *attr, int i)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct cxl_port *port = to_cxl_port(dev);
> +
> + if ((attr == &bin_attr_cdat) && port->cdat.table)
> + return 0400;
Per above change you only need to manage visibility and not permissions,
also per the comment about the error message in the CDAT table read case
I think it makes sense to show an empty attribute. Only if the device
does not claim to have a CDAT should the attribute not be visible.
> +
> + return 0;
> +}
> +
> +static struct bin_attribute *cxl_cdat_bin_attributes[] = {
> + &bin_attr_cdat,
> + NULL,
> +};
> +
> +static struct attribute_group cxl_cdat_attribute_group = {
> + .name = "CDAT",
> + .bin_attrs = cxl_cdat_bin_attributes,
> + .is_bin_visible = cxl_port_bin_attr_is_visible,
> +};
> +
> +static const struct attribute_group *cxl_port_attribute_groups[] = {
> + &cxl_cdat_attribute_group,
> + NULL,
> +};
> +
> static struct cxl_driver cxl_port_driver = {
> .name = "cxl_port",
> .probe = cxl_port_probe,
> .id = CXL_DEVICE_PORT,
> + .drv = {
> + .dev_groups = cxl_port_attribute_groups,
> + },
> };
>
> module_cxl_driver(cxl_port_driver);
> --
> 2.35.1
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-17 22:40 ` Bjorn Helgaas
@ 2022-06-18 16:39 ` Bjorn Helgaas
2022-06-22 16:46 ` Ira Weiny
2022-06-20 9:24 ` Jonathan Cameron
2022-06-22 16:38 ` Ira Weiny
2 siblings, 1 reply; 44+ messages in thread
From: Bjorn Helgaas @ 2022-06-18 16:39 UTC (permalink / raw)
To: ira.weiny
Cc: Dan Williams, Bjorn Helgaas, Jonathan Cameron, Alison Schofield,
Vishal Verma, Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl,
linux-pci
On Fri, Jun 17, 2022 at 05:40:19PM -0500, Bjorn Helgaas wrote:
> On Fri, Jun 10, 2022 at 01:22:54PM -0700, ira.weiny@intel.com wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > Introduced in a PCI r6.0, sec 6.30, DOE provides a config space based
> > mailbox with standard protocol discovery. Each mailbox is accessed
> > through a DOE Extended Capability.
> > + * pci_doe_get_irq_num() - Return the irq number for the mailbox at offset
> > + *
> > + * @pdev: The PCI device
> > + * @offset: Offset of the DOE mailbox
> > + *
> > + * Returns: irq number on success
> > + * -errno if irqs are not supported on this mailbox
> > + */
> > +int pci_doe_get_irq_num(struct pci_dev *pdev, int offset)
> > +{
> > + u32 val;
> > +
> > + pci_read_config_dword(pdev, offset + PCI_DOE_CAP, &val);
> > + if (!FIELD_GET(PCI_DOE_CAP_INT, val))
> > + return -EOPNOTSUPP;
> > +
> > + return FIELD_GET(PCI_DOE_CAP_IRQ, val);
> > +}
> > +EXPORT_SYMBOL_GPL(pci_doe_get_irq_num);
>
> Confusing function name (and comment) since PCI_DOE_CAP_IRQ is an
> Interrupt Message Number that has nothing to do with Linux IRQ
> numbers.
>
> I see we already have PCI_EXP_FLAGS_IRQ, PCI_ERR_ROOT_AER_IRQ,
> PCI_EXP_DPC_IRQ, so I guess you're in good company.
Should have been more clear about this: I think we should rename the
new one to be PCI_DOE_CAP_INT_MSG_NUM or similar, and rename the
function as well. It's too confusing to use "irq" for both Linux IRQs
and what the spec calls "Interupt Message Numbers".
Bjorn
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-17 22:40 ` Bjorn Helgaas
2022-06-18 16:39 ` Bjorn Helgaas
@ 2022-06-20 9:24 ` Jonathan Cameron
2022-06-22 23:06 ` Ira Weiny
2022-06-22 16:38 ` Ira Weiny
2 siblings, 1 reply; 44+ messages in thread
From: Jonathan Cameron @ 2022-06-20 9:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: ira.weiny, Dan Williams, Bjorn Helgaas, Alison Schofield,
Vishal Verma, Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl,
linux-pci
Hi Bjorn,
Thanks for reviewing! Up to Ira of course, but I agree with all your
comments - a few responses to questions follow.
>
> > + * pci_doe_supports_prot() - Return if the DOE instance supports the given
> > + * protocol
> > + * @doe_mb: DOE mailbox capability to query
> > + * @vid: Protocol Vendor ID
> > + * @type: Protocol type
> > + *
> > + * RETURNS: True if the DOE mailbox supports the protocol specified
>
> Is the typical use that the caller has a few specific protocols it
> cares about? There's no case where a caller might want to enumerate
> them all? I guess they're all in prots[], but that's supposed to be
> opaque to users.
Given each protocol needs specific handling in the driver, the only
usecase for a general enumeration would be debug I think. Maybe
it makes sense to provide that info to userspace somewhere, but
definitely feels like something for a follow up discussion.
>
> > + */
> > +bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type)
> > +{
> > + int i;
> > +
> > + /* The discovery protocol must always be supported */
> > + if (vid == PCI_VENDOR_ID_PCI_SIG && type == PCI_DOE_PROTOCOL_DISCOVERY)
> > + return true;
> > +
> > + for (i = 0; i < doe_mb->num_prots; i++)
> > + if ((doe_mb->prots[i].vid == vid) &&
> > + (doe_mb->prots[i].type == type))
> > + return true;
> > +
> > + return false;
> > +}
> > +EXPORT_SYMBOL_GPL(pci_doe_supports_prot);
>
> > + * struct pci_doe_task - represents a single query/response
> > + *
> > + * @prot: DOE Protocol
> > + * @request_pl: The request payload
> > + * @request_pl_sz: Size of the request payload
>
> Size is in dwords, not bytes, I guess?
It's in bytes (IIRC) - we divide it by. It's a bit of a mess,
but there are parts of SPDM over CMA where messages are not
full number of dwords. My thinking was that we 'might' move
the padding into the generic code if this becomes something
multiple protocols need. For now the RFC does the
padding at the CMA layer.
Let's avoid this being unclear in future by stating that it's
in bytes in the comment.
Jonathan
>
> > + * @response_pl: The response payload
> > + * @response_pl_sz: Size of the response payload
> > + * @rv: Return value. Length of received response or error
> > + * @complete: Called when task is complete
> > + * @private: Private data for the consumer
> > + */
> > +struct pci_doe_task {
> > + struct pci_doe_protocol prot;
> > + u32 *request_pl;
> > + size_t request_pl_sz;
> > + u32 *response_pl;
> > + size_t response_pl_sz;
> > + int rv;
> > + void (*complete)(struct pci_doe_task *task);
> > + void *private;
> > +};
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-17 22:56 ` Dan Williams
@ 2022-06-20 10:23 ` Jonathan Cameron
2022-06-22 22:57 ` Ira Weiny
2022-06-22 22:37 ` Ira Weiny
2022-06-22 22:45 ` Ira Weiny
2 siblings, 1 reply; 44+ messages in thread
From: Jonathan Cameron @ 2022-06-20 10:23 UTC (permalink / raw)
To: Dan Williams
Cc: ira.weiny, Bjorn Helgaas, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
On Fri, 17 Jun 2022 15:56:38 -0700
Dan Williams <dan.j.williams@intel.com> wrote:
> ira.weiny@ wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > Introduced in a PCI r6.0, sec 6.30, DOE provides a config space based
> > mailbox with standard protocol discovery. Each mailbox is accessed
> > through a DOE Extended Capability.
> >
> > Each DOE mailbox must support the DOE discovery protocol in addition to
> > any number of additional protocols.
> >
> > Define core PCI functionality to manage a single PCI DOE mailbox at a
> > defined config space offset. Functionality includes iterating,
> > creating, query of supported protocol, task submission, and destruction
> > of the mailboxes.
> >
> > If interrupts are desired, the interrupt number can be queried and
> > passed to the create function. Passing a negative value disables
> > interrupts for that mailbox. It is the callers responsibility to ensure
>
> s/callers/caller's/
>
> > enough interrupt vectors are allocated.
> >
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > Co-developed-by: Ira Weiny <ira.weiny@intel.com>
> > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> >
...
> > + * @task_lock: Protect cur_task
>
> Protect what about cur_task? Assigning and clearing a pointer is atomic.
>
> > + * @statemachine: Work item for the DOE state machine
>
> Why does the pci_doe_mb have a work item? I would expect a work item per
> task. Then this gets a waitqueue for free to wait for task completion.
> Otherwise I suspect this introduces complexity in the DOE implementation
> to simulate per-task-work that a workqueue per DOE and a work item per
> task gets you for free, and for recalling hardware context from one
> firing of the state machine to the next. Just run the task work all
> in-line in one context.
We went through a model that looked rather more like that. Maybe
I misunderstood your feedback at the time (way back around the first RFC)
where you suggested using timeouts via delayed workqueue and limiting
the access to the DOE to a single thread (explicitly by using a single
work item). See description of changes in v2.
https://lore.kernel.org/all/20210413160159.935663-3-Jonathan.Cameron@huawei.com/
This logic has been fundamentally the same since around v2.
...
> > +static irqreturn_t pci_doe_irq_handler(int irq, void *data)
> > +{
> > + struct pci_doe_mb *doe_mb = data;
> > + struct pci_dev *pdev = doe_mb->pdev;
> > + int offset = doe_mb->cap_offset;
> > + u32 val;
> > +
> > + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> > + if (FIELD_GET(PCI_DOE_STATUS_INT_STATUS, val)) {
> > + pci_write_config_dword(pdev, offset + PCI_DOE_STATUS,
> > + PCI_DOE_STATUS_INT_STATUS);
> > + mod_delayed_work(system_wq, &doe_mb->statemachine, 0);
>
> Wait, no, not system_wq. I expected this wants a dedicated / ordered queue
> per doe and this likely wants a queue that can sleep while processing a
> task and just not support overlapping tasks.
>
> In that model the irq is just waking up any tasks in execution that are
> awaiting a polling timeout. The irq handler does:
>
> wake_up(&doe_mb->wait);
>
> ...and then task that is executing in the queue continues what it was
> doing.
Sure that should work.
>
> > + return IRQ_HANDLED;
> > + }
> > +
> > + return IRQ_NONE;
> > +}
> > +
> > +/*
> > + * Only called when safe to directly access the DOE from
> > + * doe_statemachine_work(). Outside access is not protected. Users who
> > + * perform such access are left with the pieces.
>
> What pieces, where? I expect the abort implementation would be something
> like:
>
> set_bit(ABORT_PENDING) <== blocks new task submissions until clear
> flush_workqueue() <== make sure all in-flight tasks see the abort
> do_doe_abort(...) <== do the abort
> clear_bit(ABORT_PENDING) <== optionally restart the tasks that were
> cancelled, or just expect them to be resubmitted.
I think this is an artifact of trying to act on suggestion to only access
the DOE from a single thread. Without that complexity something like you
suggest should work.
Fundamentally should still only be called from within the state machine
though (as that's the only place it makes sense) and will need to
interrupt work in flight (waiting for interrupt / polling for timeout etc).
> > +static int pci_doe_abort(struct pci_doe_mb *doe_mb)
> > +{
> > + reinit_completion(&doe_mb->abort_c);
> > + set_bit(PCI_DOE_FLAG_ABORT, &doe_mb->flags);
> > + schedule_delayed_work(&doe_mb->statemachine, 0);
> > + wait_for_completion(&doe_mb->abort_c);
> > +
> > + if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags))
> > + return -EIO;
> > +
> > + return 0;
> > +}
> > +
> > +static int pci_doe_enable_irq(struct pci_doe_mb *doe_mb, unsigned int irq)
> > +{
> > + struct pci_dev *pdev = doe_mb->pdev;
> > + int offset = doe_mb->cap_offset;
> > + int rc;
> > +
> > + /*
> > + * Enabling bus mastering is required for MSI/MSIx. It is safe to call
> > + * this multiple times and thus is called here to ensure that mastering
> > + * is enabled even if the driver has done so.
> > + */
>
> It is required for MSI/MSIx to work, yes, but if the caller that created
> the doe object has not set it yet that's its prerogative.
We went around this in one of the earlier threads, and I think consensus
was that it made sense to have this in core code.
>
> > + pci_set_master(pdev);
> > + rc = pci_request_irq(pdev, irq, pci_doe_irq_handler, NULL, doe_mb,
> > + "DOE[%d:%s]", irq, pci_name(pdev));
>
> If the DOE object creation is use devm_ then this wants to be
> devm_request_irq(), although I now notice that devm_pci_doe_create()
> only existed in the code comments, not the implementation.
>
> Is there any need for the unmanaged version of this API?
>
> > + if (rc)
> > + return rc;
> > +
> > + doe_mb->irq = irq;
> > + pci_write_config_dword(pdev, offset + PCI_DOE_CTRL,
> > + PCI_DOE_CTRL_INT_EN);
> > + return 0;
> > +}
> > +
Thanks,
Jonathan
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices
2022-06-17 20:40 ` [PATCH v11 " Davidlohr Bueso
2022-06-17 20:51 ` Davidlohr Bueso
@ 2022-06-21 18:24 ` Ira Weiny
1 sibling, 0 replies; 44+ messages in thread
From: Ira Weiny @ 2022-06-21 18:24 UTC (permalink / raw)
To: Davidlohr Bueso
Cc: Dan Williams, Bjorn Helgaas, Jonathan Cameron, Ben Widawsky,
Alison Schofield, Vishal Verma, Dave Jiang, linux-kernel,
linux-cxl, linux-pci, a.manzanares
On Fri, Jun 17, 2022 at 01:40:46PM -0700, Davidlohr Bueso wrote:
> On Fri, 10 Jun 2022, ira.weiny@intel.com wrote:
> > +++ b/drivers/cxl/cxlmem.h
> > @@ -191,6 +191,8 @@ struct cxl_endpoint_dvsec_info {
> > * @component_reg_phys: register base of component registers
> > * @info: Cached DVSEC information about the device.
> > * @serial: PCIe Device Serial Number
>
> Missing doc:
>
> @doe_use_irq: Use interrupt vectors for DOEs over polling.
>
> However introducing such flags is not pretty, and this is only used by
> devm_cxl_pci_create_doe(). Do we really need it? See below.
Yes Dan had the same feedback to get rid of the member.
[snip]
> > +
> > static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > {
> > struct cxl_register_map map;
> > @@ -434,6 +545,9 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> >
> > cxlds->component_reg_phys = cxl_regmap_to_base(pdev, &map);
> >
> > + cxl_alloc_irq_vectors(cxlds);
> > + devm_cxl_pci_create_doe(cxlds);
>
> Should cxl_alloc_irq_vectors() just be called directly from devm_cxl_pci_create_doe()
> instead?
I was anticipating having to merge cxl_alloc_irq_vectors() with other code
which is supporting irq's for other things later on. So I kept the 2 separate.
This is also why the use irq flag was in the device state. The irq vector call
could have specified to use other types of irq's. But those can be passed
directly as Dan suggested.
> Also if devm_cxl_pci_create_doe() fails (say ENOMEM), why do we
> bother continuing the cxl_pci probing?
Because the DOE is only required for CDAT data which is optional at this point.
Thanks for the suggested diff below. But I'm going to go with Dan's suggestion
to use a flag which is set and passed between the functions.
Thanks for the review!
Ira
>
> Thanks,
> Davidlohr
>
> ------
> diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
> index ce5b00f3ebcb..44098c785a8b 100644
> --- a/drivers/cxl/cxlmem.h
> +++ b/drivers/cxl/cxlmem.h
> @@ -230,7 +230,6 @@ struct cxl_dev_state {
> resource_size_t component_reg_phys;
> u64 serial;
>
> - bool doe_use_irq;
> struct pci_doe_mb **doe_mbs;
> int num_mbs;
>
> diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
> index 72c7b535f5df..47c3741f7768 100644
> --- a/drivers/cxl/pci.c
> +++ b/drivers/cxl/pci.c
> @@ -403,7 +403,7 @@ static void cxl_doe_destroy_mb(void *ds)
> }
> }
>
> -static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
> +static int cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
> {
> struct device *dev = cxlds->dev;
> struct pci_dev *pdev = to_pci_dev(dev);
> @@ -421,9 +421,7 @@ static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
> }
>
> if (!max_irqs)
> - return;
> -
> - cxlds->doe_use_irq = false;
> + return -ENOMEM;
>
> /*
> * Allocate enough vectors for the DOE's
> @@ -435,14 +433,10 @@ static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
> /* Some got allocated; clean them up */
> if (rc > 0)
> cxl_pci_free_irq_vectors(pdev);
> - return;
> + return -ENOMEM;
> }
>
> - rc = devm_add_action_or_reset(dev, cxl_pci_free_irq_vectors, pdev);
> - if (rc)
> - return;
> -
> - cxlds->doe_use_irq = true;
> + return devm_add_action_or_reset(dev, cxl_pci_free_irq_vectors, pdev);
> }
>
> /**
> @@ -457,6 +451,10 @@ static void devm_cxl_pci_create_doe(struct cxl_dev_state *cxlds)
> u16 off = 0;
> int num_mbs = 0;
> int rc;
> + bool doe_use_irq = false;
> +
> + if (cxl_alloc_irq_vectors(cxlds))
> + doe_use_irq = true;
>
> pci_doe_for_each_off(pdev, off)
> num_mbs++;
> @@ -475,7 +473,7 @@ static void devm_cxl_pci_create_doe(struct cxl_dev_state *cxlds)
> struct pci_doe_mb *doe_mb;
> int irq = -1;
>
> - if (cxlds->doe_use_irq)
> + if (doe_use_irq)
> irq = pci_doe_get_irq_num(pdev, off);
>
> doe_mb = pci_doe_create_mb(pdev, off, irq);
> @@ -545,7 +543,6 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>
> cxlds->component_reg_phys = cxl_regmap_to_base(pdev, &map);
>
> - cxl_alloc_irq_vectors(cxlds);
> devm_cxl_pci_create_doe(cxlds);
>
> rc = cxl_pci_setup_mailbox(cxlds);
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices
2022-06-17 23:44 ` [PATCH V11 " Dan Williams
@ 2022-06-21 18:29 ` Ira Weiny
2022-06-22 23:18 ` Ira Weiny
0 siblings, 1 reply; 44+ messages in thread
From: Ira Weiny @ 2022-06-21 18:29 UTC (permalink / raw)
To: Dan Williams
Cc: Bjorn Helgaas, Jonathan Cameron, Ben Widawsky, Alison Schofield,
Vishal Verma, Dave Jiang, linux-kernel, linux-cxl, linux-pci
On Fri, Jun 17, 2022 at 04:44:27PM -0700, Dan Williams wrote:
> ira.weiny@ wrote:
[snip]
> > diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
> > index 60d10ee1e7fc..4d2764b865ab 100644
> > --- a/drivers/cxl/cxlmem.h
> > +++ b/drivers/cxl/cxlmem.h
> > @@ -191,6 +191,8 @@ struct cxl_endpoint_dvsec_info {
> > * @component_reg_phys: register base of component registers
> > * @info: Cached DVSEC information about the device.
> > * @serial: PCIe Device Serial Number
> > + * @doe_mbs: PCI DOE mailbox array
> > + * @num_mbs: Number of DOE mailboxes
> > * @mbox_send: @dev specific transport for transmitting mailbox commands
> > *
> > * See section 8.2.9.5.2 Capacity Configuration and Label Storage for
> > @@ -224,6 +226,10 @@ struct cxl_dev_state {
> > resource_size_t component_reg_phys;
> > u64 serial;
> >
> > + bool doe_use_irq;
>
> Don't pass temporary state through a long lived data structure. Just
> pass flag by reference between the functions that want to coordinate
> this.
Done.
[snip]
> > +
> > +static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
> > +{
> > + struct device *dev = cxlds->dev;
> > + struct pci_dev *pdev = to_pci_dev(dev);
> > + int max_irqs = 0;
> > + int off = 0;
> > + int rc;
> > +
> > + /* Account for all the DOE vectors needed */
> > + pci_doe_for_each_off(pdev, off) {
> > + int irq = pci_doe_get_irq_num(pdev, off);
> > +
> > + if (irq < 0)
> > + continue;
> > + max_irqs = max(max_irqs, irq + 1);
>
> This seems to assume that different DOEs will get independent vectors.
> The driver needs to be prepared for DOE instances, Event notifications,
> and mailbox commands to share a single MSI vector in the worst case.
> Lets focus on polled mode DOE, or explicitly only support interrupt
> based operation when no vector sharing is detected.
>
Ok I see now. I was under the impression they had to be unique.
Do you think it is sufficient to check in this loop for duplicates and bail if
any are shared?
Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: [PATCH V11 5/8] cxl/port: Read CDAT table
2022-06-18 0:43 ` Dan Williams
@ 2022-06-21 19:10 ` Dan Williams
2022-06-21 19:34 ` Lukas Wunner
2022-06-21 21:14 ` Ira Weiny
1 sibling, 1 reply; 44+ messages in thread
From: Dan Williams @ 2022-06-21 19:10 UTC (permalink / raw)
To: Dan Williams, ira.weiny, Bjorn Helgaas, Jonathan Cameron
Cc: Ira Weiny, Alison Schofield, Vishal Verma, Dave Jiang,
Ben Widawsky, linux-kernel, linux-cxl, linux-pci
Dan Williams wrote:
> ira.weiny@ wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
[..]
> > diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
> > index c4c99ff7b55e..84dc82f7dff0 100644
> > --- a/drivers/cxl/core/pci.c
> > +++ b/drivers/cxl/core/pci.c
> > @@ -4,10 +4,12 @@
> > #include <linux/device.h>
> > #include <linux/delay.h>
> > #include <linux/pci.h>
> > +#include <linux/pci-doe.h>
> > #include <cxlpci.h>
> > #include <cxlmem.h>
> > #include <cxl.h>
> > #include "core.h"
> > +#include "cdat.h"
> >
> > /**
> > * DOC: cxl core pci
> > @@ -458,3 +460,173 @@ int cxl_hdm_decode_init(struct cxl_dev_state *cxlds, struct cxl_hdm *cxlhdm)
> > return 0;
> > }
> > EXPORT_SYMBOL_NS_GPL(cxl_hdm_decode_init, CXL);
> > +
> > +static struct pci_doe_mb *find_cdat_mb(struct device *uport)
> > +{
> > + struct cxl_memdev *cxlmd;
> > + struct cxl_dev_state *cxlds;
> > + int i;
> > +
> > + if (!is_cxl_memdev(uport))
> > + return NULL;
> > +
> > + cxlmd = to_cxl_memdev(uport);
> > + cxlds = cxlmd->cxlds;
>
> This feels stuck between 2 worlds. Either cxl_port_probe() needs to do
> the enumeration, or the attribute needs to move to be memdev relative.
> Given that CXL switches are going to also have CDAT data, then the
> former path needs to happen. Yes, cxl_pci still needs to do the vector
> allocation, but it does not need to do the PCI DOE probing.
It is really the interrupt setup that makes this an awkward fit all
around. The PCI core knows how to handle capabilities with interrupts,
but only for PCIe port services. DOE is both a PCIe port service *and*
and "endpoint service" like VPD (pci_vpd_init()). The more I think about
this the closer I get to the recommendation from Lukas which is that
DOE is more like pci_vpd_init() than pci_aer_init(), or a custom
enabling per driver.
If the DOE enumeration moves to a sub-function of
pci_init_capabilities() then the cxl_pci and/or cxl_port drivers just
look those up and use them. The DOE instances would remain in polled
mode unless and until a PCI driver added interrupt support late. In
other words, DOE can follow the VPD init model as long as interrupts are
not involved, and if interrupts are desired it requires late allocation
of IRQ vectors.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 5/8] cxl/port: Read CDAT table
2022-06-21 19:10 ` Dan Williams
@ 2022-06-21 19:34 ` Lukas Wunner
2022-06-21 19:41 ` Dan Williams
0 siblings, 1 reply; 44+ messages in thread
From: Lukas Wunner @ 2022-06-21 19:34 UTC (permalink / raw)
To: Dan Williams
Cc: ira.weiny, Bjorn Helgaas, Jonathan Cameron, Alison Schofield,
Vishal Verma, Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl,
linux-pci
On Tue, Jun 21, 2022 at 12:10:03PM -0700, Dan Williams wrote:
> It is really the interrupt setup that makes this an awkward fit all
> around. The PCI core knows how to handle capabilities with interrupts,
> but only for PCIe port services. DOE is both a PCIe port service *and*
> and "endpoint service" like VPD (pci_vpd_init()). The more I think about
> this the closer I get to the recommendation from Lukas which is that
> DOE is more like pci_vpd_init() than pci_aer_init(), or a custom
> enabling per driver.
>
> If the DOE enumeration moves to a sub-function of
> pci_init_capabilities() then the cxl_pci and/or cxl_port drivers just
> look those up and use them. The DOE instances would remain in polled
> mode unless and until a PCI driver added interrupt support late. In
> other words, DOE can follow the VPD init model as long as interrupts are
> not involved, and if interrupts are desired it requires late allocation
> of IRQ vectors.
Thomas Gleixner has been working on dynamic allocation of MSI-X vectors.
We should probably just build on that and let the PCI core allocate
vectors for DOE mailboxes independently from drivers.
To conserve vectors, I'd delay allocation for a DOE mailbox until
it is first used. There may be mailboxes that are never used.
DOE requires MSI-X or MSI. We could probably leave MSI unsupported
until a device with broken MSI-X support shows up. I envision that
with MSI, the onus is on the driver to allocate vectors for mailboxes
it intends to use and it would then have to "donate" those vectors
to the PCI core via a library function.
As for portdrv, that's a driver but Bjorn has expressed a desire
for a long time to move its functionality into the PCI core.
It shouldn't be allowed to unbind portdrv via sysfs and thus break
DPC etc, as is currently possible.
The question with regards to this series is, do we get *something*
merged and perfect it over time once it's in the tree, or do we
keep iterating on the mailing list. I deliberately only provided
a single, comprehensive review and then stayed mum because I feel
bad for Ira having to keep reacting to more and more feedback
despite being at v11 already (or v12? I've lost count).
Particularly because I suspect (I might be mistaken) that Ira's
natural habitat is actually CXL not PCI, so it might be a burden for him.
I'd be fine to implement suggestions I've made myself after Ira's
series lands. No need for him to keep iterating ad infinitum.
Thanks,
Lukas
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 5/8] cxl/port: Read CDAT table
2022-06-21 19:34 ` Lukas Wunner
@ 2022-06-21 19:41 ` Dan Williams
2022-06-21 20:38 ` Ira Weiny
0 siblings, 1 reply; 44+ messages in thread
From: Dan Williams @ 2022-06-21 19:41 UTC (permalink / raw)
To: Lukas Wunner, Dan Williams
Cc: ira.weiny, Bjorn Helgaas, Jonathan Cameron, Alison Schofield,
Vishal Verma, Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl,
linux-pci
Lukas Wunner wrote:
> On Tue, Jun 21, 2022 at 12:10:03PM -0700, Dan Williams wrote:
> > It is really the interrupt setup that makes this an awkward fit all
> > around. The PCI core knows how to handle capabilities with interrupts,
> > but only for PCIe port services. DOE is both a PCIe port service *and*
> > and "endpoint service" like VPD (pci_vpd_init()). The more I think about
> > this the closer I get to the recommendation from Lukas which is that
> > DOE is more like pci_vpd_init() than pci_aer_init(), or a custom
> > enabling per driver.
> >
> > If the DOE enumeration moves to a sub-function of
> > pci_init_capabilities() then the cxl_pci and/or cxl_port drivers just
> > look those up and use them. The DOE instances would remain in polled
> > mode unless and until a PCI driver added interrupt support late. In
> > other words, DOE can follow the VPD init model as long as interrupts are
> > not involved, and if interrupts are desired it requires late allocation
> > of IRQ vectors.
>
> Thomas Gleixner has been working on dynamic allocation of MSI-X vectors.
> We should probably just build on that and let the PCI core allocate
> vectors for DOE mailboxes independently from drivers.
>
> To conserve vectors, I'd delay allocation for a DOE mailbox until
> it is first used. There may be mailboxes that are never used.
>
> DOE requires MSI-X or MSI. We could probably leave MSI unsupported
> until a device with broken MSI-X support shows up. I envision that
> with MSI, the onus is on the driver to allocate vectors for mailboxes
> it intends to use and it would then have to "donate" those vectors
> to the PCI core via a library function.
>
> As for portdrv, that's a driver but Bjorn has expressed a desire
> for a long time to move its functionality into the PCI core.
> It shouldn't be allowed to unbind portdrv via sysfs and thus break
> DPC etc, as is currently possible.
>
> The question with regards to this series is, do we get *something*
> merged and perfect it over time once it's in the tree, or do we
> keep iterating on the mailing list. I deliberately only provided
> a single, comprehensive review and then stayed mum because I feel
> bad for Ira having to keep reacting to more and more feedback
> despite being at v11 already (or v12? I've lost count).
> Particularly because I suspect (I might be mistaken) that Ira's
> natural habitat is actually CXL not PCI, so it might be a burden for him.
> I'd be fine to implement suggestions I've made myself after Ira's
> series lands. No need for him to keep iterating ad infinitum.
Yeah, sounds good. If the dynamic IRQ allocation support is on its way
then lets leave interrupt support out of the current DOE series and just
focus on getting polled mode going with the enumeration coming from the
PCI core. That seems the shortest path to get something landed and
enables incremental improvement. Then the messiness of DOE interrupt
allocation and pcie_port_drv reworks can be saved for PCI core folks.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices
2022-06-10 20:22 ` [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices ira.weiny
2022-06-17 20:40 ` [PATCH v11 " Davidlohr Bueso
2022-06-17 23:44 ` [PATCH V11 " Dan Williams
@ 2022-06-21 20:37 ` Bjorn Helgaas
2 siblings, 0 replies; 44+ messages in thread
From: Bjorn Helgaas @ 2022-06-21 20:37 UTC (permalink / raw)
To: ira.weiny
Cc: Dan Williams, Bjorn Helgaas, Jonathan Cameron, Ben Widawsky,
Alison Schofield, Vishal Verma, Dave Jiang, linux-kernel,
linux-cxl, linux-pci
In subject, I assume you mean the plural "mailboxes", not the
possessive "mailbox's".
On Fri, Jun 10, 2022 at 01:22:55PM -0700, ira.weiny@intel.com wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> DOE mailbox objects will be needed for various mailbox communications
> with each memory device.
>
> Iterate each DOE mailbox capability and create PCI DOE mailbox objects
> as found.
>
> It is not anticipated that this is the final resting place for the
> iteration of the DOE devices. The support of ports may drive this code
> into the pcie side. In this imagined architecture the CXL port driver
s/pcie/PCIe/ to match other usage below.
> would then query into the PCI device for the DOE mailbox array.
>
> For now this is good enough for the endpoints and the split is similar
> to the envisioned architecture where getting the mailbox array is
> separated from the various protocol needs. For example, it is not
> anticipated that the CDAT code will need to move because it is only
> needed by the cxl_ports.
>
> Likewise irq's are separated out in a similar design pattern to the
> PCIe port driver. But a much simpler irq enabling flag is used and only
> DOE interrupts are supported.
I don't know what the convention is or will be for drivers/cxl. In
drivers/pci, we favor "IRQ" over "irq" in English text to go along
with PCI, DOE, CDAT, etc.
Also makes "IRQs" intelligible where "irq's" looks a little funny
because the usage isn't possessive and "irqs" isn't obviously a word
or an acronym.
Bjorn
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 5/8] cxl/port: Read CDAT table
2022-06-21 19:41 ` Dan Williams
@ 2022-06-21 20:38 ` Ira Weiny
0 siblings, 0 replies; 44+ messages in thread
From: Ira Weiny @ 2022-06-21 20:38 UTC (permalink / raw)
To: Dan Williams
Cc: Lukas Wunner, Bjorn Helgaas, Jonathan Cameron, Alison Schofield,
Vishal Verma, Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl,
linux-pci
On Tue, Jun 21, 2022 at 12:41:35PM -0700, Dan Williams wrote:
> Lukas Wunner wrote:
> > On Tue, Jun 21, 2022 at 12:10:03PM -0700, Dan Williams wrote:
> > > It is really the interrupt setup that makes this an awkward fit all
> > > around. The PCI core knows how to handle capabilities with interrupts,
> > > but only for PCIe port services. DOE is both a PCIe port service *and*
> > > and "endpoint service" like VPD (pci_vpd_init()). The more I think about
> > > this the closer I get to the recommendation from Lukas which is that
> > > DOE is more like pci_vpd_init() than pci_aer_init(), or a custom
> > > enabling per driver.
> > >
> > > If the DOE enumeration moves to a sub-function of
> > > pci_init_capabilities() then the cxl_pci and/or cxl_port drivers just
> > > look those up and use them. The DOE instances would remain in polled
> > > mode unless and until a PCI driver added interrupt support late. In
> > > other words, DOE can follow the VPD init model as long as interrupts are
> > > not involved, and if interrupts are desired it requires late allocation
> > > of IRQ vectors.
> >
> > Thomas Gleixner has been working on dynamic allocation of MSI-X vectors.
> > We should probably just build on that and let the PCI core allocate
> > vectors for DOE mailboxes independently from drivers.
> >
> > To conserve vectors, I'd delay allocation for a DOE mailbox until
> > it is first used. There may be mailboxes that are never used.
> >
> > DOE requires MSI-X or MSI. We could probably leave MSI unsupported
> > until a device with broken MSI-X support shows up. I envision that
> > with MSI, the onus is on the driver to allocate vectors for mailboxes
> > it intends to use and it would then have to "donate" those vectors
> > to the PCI core via a library function.
> >
> > As for portdrv, that's a driver but Bjorn has expressed a desire
> > for a long time to move its functionality into the PCI core.
> > It shouldn't be allowed to unbind portdrv via sysfs and thus break
> > DPC etc, as is currently possible.
> >
> > The question with regards to this series is, do we get *something*
> > merged and perfect it over time once it's in the tree, or do we
> > keep iterating on the mailing list.
That is what I was going for by allocating the vectors in the CXL driver where
they happen to be used right now. But I mentioned in the commit message that I
don't think that is where they should live long term.
> > I deliberately only provided
> > a single, comprehensive review and then stayed mum because I feel
> > bad for Ira having to keep reacting to more and more feedback
> > despite being at v11 already (or v12? I've lost count).
> > Particularly because I suspect (I might be mistaken) that Ira's
> > natural habitat is actually CXL not PCI, so it might be a burden for him.
I'm always willing to learn more (PCI) but yes CXL is my focus. I've never
modified the PCI layers so I am out of my element there.
> > I'd be fine to implement suggestions I've made myself after Ira's
> > series lands. No need for him to keep iterating ad infinitum.
>
> Yeah, sounds good. If the dynamic IRQ allocation support is on its way
> then lets leave interrupt support out of the current DOE series and just
> focus on getting polled mode going with the enumeration coming from the
> PCI core.
I've taken some time to look at the dynamic allocation stuff but I've not
internalized it nor figured out how to integrate it into the PCI/CXL layers.
> That seems the shortest path to get something landed and
> enables incremental improvement. Then the messiness of DOE interrupt
> allocation and pcie_port_drv reworks can be saved for PCI core folks.
Yes I think getting rid of the IRQ stuff for this round would help. There has
been a lot of discussion around it and I'm still not fully happy with it where
it stands. So I'll split it out for now. If someone wants to pick it up that
would be great or I can work on a more central place.
Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 5/8] cxl/port: Read CDAT table
2022-06-18 0:43 ` Dan Williams
2022-06-21 19:10 ` Dan Williams
@ 2022-06-21 21:14 ` Ira Weiny
2022-06-21 21:48 ` Dan Williams
1 sibling, 1 reply; 44+ messages in thread
From: Ira Weiny @ 2022-06-21 21:14 UTC (permalink / raw)
To: Dan Williams
Cc: Bjorn Helgaas, Jonathan Cameron, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
On Fri, Jun 17, 2022 at 05:43:34PM -0700, Dan Williams wrote:
> ira.weiny@ wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
[snip]
> > +
> > +/**
> > + * read_cdat_data - Read the CDAT data on this port
> > + * @port: Port to read data from
> > + *
> > + * This call will sleep waiting for responses from the DOE mailbox.
> > + */
> > +void read_cdat_data(struct cxl_port *port)
> > +{
> > + static struct pci_doe_mb *cdat_mb;
> > + struct device *dev = &port->dev;
> > + struct device *uport = port->uport;
> > + size_t cdat_length;
> > + int ret;
> > +
> > + /*
> > + * Ensure a reference on the underlying uport device which has the
> > + * mailboxes in it
> > + */
> > + get_device(uport);
>
> I had written up a long description grumbling about "just in case"
> acquistions of device references, but then I lost that draft.
>
> So I'll do the shorter response, but give you more homework in the
> process. How / Why is that get_device() needed? What are the guarantees that
> ensure you that the last reference has not been dropped just before that
> call? Hint: what context is this code running?
I'll check it out. I suspect there is some reference on uport already taken
such that if port is valid uport must be valid.
>
> > +
> > + cdat_mb = find_cdat_mb(uport);
> > + if (!cdat_mb) {
> > + dev_dbg(dev, "No CDAT mailbox\n");
> > + goto out;
> > + }
> > +
> > + if (cxl_cdat_get_length(dev, cdat_mb, &cdat_length)) {
> > + dev_dbg(dev, "No CDAT length\n");
> > + goto out;
> > + }
> > +
> > + port->cdat.table = devm_kzalloc(dev, cdat_length, GFP_KERNEL);
> > + if (!port->cdat.table)
> > + goto out;
> > +
> > + port->cdat.length = cdat_length;
> > + ret = cxl_cdat_read_table(dev, cdat_mb, &port->cdat);
> > + if (ret) {
> > + /* Don't leave table data allocated on error */
> > + devm_kfree(dev, port->cdat.table);
> > + port->cdat.table = NULL;
> > + port->cdat.length = 0;
> > + dev_err(dev, "CDAT data read error\n");
>
> Rather than a chatty / ephemeral error message I think this wants some
> indication in userspace, likely the 0-length CDAT binary attribute, so
> that userspace can debug why the kernel is picking sub-optimal QTG ids
> for newly provisioned CXL regions.
I thought we agreed that 0-length or CDAT query failure would result in no
sysfs entry?
This message was to alert that a CDAT query was attempted but the read failed
vs finding no mailbox with CDAT capabilities for example.
[snip]
> >
> > +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_port *port = to_cxl_port(dev);
> > +
> > + if (!port->cdat.table)
> > + return 0;
> > +
> > + return memory_read_from_buffer(buf, count, &offset,
> > + port->cdat.table,
> > + port->cdat.length);
> > +}
> > +
> > +static BIN_ATTR_RO(cdat, 0);
>
> This should be BIN_ATTR_ADMIN_RO(), see:
>
> 3022c6a1b4b7 driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}
Are you suggesting I add BIN_ATTR_ADMIN_* macros?
>
> > +
> > +static umode_t cxl_port_bin_attr_is_visible(struct kobject *kobj,
> > + struct bin_attribute *attr, int i)
> > +{
> > + struct device *dev = kobj_to_dev(kobj);
> > + struct cxl_port *port = to_cxl_port(dev);
> > +
> > + if ((attr == &bin_attr_cdat) && port->cdat.table)
> > + return 0400;
>
> Per above change you only need to manage visibility and not permissions,
But the permissions indicate visibility (In the kdoc for struct
attribute_group).
* ... Must
* return 0 if a binary attribute is not visible. The returned
* value will replace static permissions defined in
* struct bin_attribute.
And the value returned overrides the mode.
fs/sysfs/group.c:
create_files()
82 if (grp->is_bin_visible) {
83 mode = grp->is_bin_visible(kobj, *bin_attr, i);
84 if (!mode)
85 continue;
86 }
87
88 WARN(mode & ~(SYSFS_PREALLOC | 0664),
89 "Attribute %s: Invalid permissions 0%o\n",
90 (*bin_attr)->attr.name, mode);
91
92 mode &= SYSFS_PREALLOC | 0664;
So I'm willing to add the macro but I'm not sure it is going to change anything
in this case. I think to make those _ADMIN_ macros work with is_visible()
create_files() needs to be changed. :-/ I'm not sure if the addition of
DEVICE_ATTR_ADMIN_{RO,RW} intended for is_visible() to be able to override the
mode?
> also per the comment about the error message in the CDAT table read case
> I think it makes sense to show an empty attribute. Only if the device
> does not claim to have a CDAT should the attribute not be visible.
Ok I can do that.
Thanks for the review,
Ira
>
> > +
> > + return 0;
> > +}
> > +
> > +static struct bin_attribute *cxl_cdat_bin_attributes[] = {
> > + &bin_attr_cdat,
> > + NULL,
> > +};
> > +
> > +static struct attribute_group cxl_cdat_attribute_group = {
> > + .name = "CDAT",
> > + .bin_attrs = cxl_cdat_bin_attributes,
> > + .is_bin_visible = cxl_port_bin_attr_is_visible,
> > +};
> > +
> > +static const struct attribute_group *cxl_port_attribute_groups[] = {
> > + &cxl_cdat_attribute_group,
> > + NULL,
> > +};
> > +
> > static struct cxl_driver cxl_port_driver = {
> > .name = "cxl_port",
> > .probe = cxl_port_probe,
> > .id = CXL_DEVICE_PORT,
> > + .drv = {
> > + .dev_groups = cxl_port_attribute_groups,
> > + },
> > };
> >
> > module_cxl_driver(cxl_port_driver);
> > --
> > 2.35.1
> >
>
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 5/8] cxl/port: Read CDAT table
2022-06-21 21:14 ` Ira Weiny
@ 2022-06-21 21:48 ` Dan Williams
2022-06-28 3:24 ` Ira Weiny
0 siblings, 1 reply; 44+ messages in thread
From: Dan Williams @ 2022-06-21 21:48 UTC (permalink / raw)
To: Ira Weiny, Dan Williams
Cc: Bjorn Helgaas, Jonathan Cameron, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
Ira Weiny wrote:
> On Fri, Jun 17, 2022 at 05:43:34PM -0700, Dan Williams wrote:
> > ira.weiny@ wrote:
> > > From: Ira Weiny <ira.weiny@intel.com>
> > >
>
> [snip]
>
> > > +
> > > +/**
> > > + * read_cdat_data - Read the CDAT data on this port
> > > + * @port: Port to read data from
> > > + *
> > > + * This call will sleep waiting for responses from the DOE mailbox.
> > > + */
> > > +void read_cdat_data(struct cxl_port *port)
> > > +{
> > > + static struct pci_doe_mb *cdat_mb;
> > > + struct device *dev = &port->dev;
> > > + struct device *uport = port->uport;
> > > + size_t cdat_length;
> > > + int ret;
> > > +
> > > + /*
> > > + * Ensure a reference on the underlying uport device which has the
> > > + * mailboxes in it
> > > + */
> > > + get_device(uport);
> >
> > I had written up a long description grumbling about "just in case"
> > acquistions of device references, but then I lost that draft.
> >
> > So I'll do the shorter response, but give you more homework in the
> > process. How / Why is that get_device() needed? What are the guarantees that
> > ensure you that the last reference has not been dropped just before that
> > call? Hint: what context is this code running?
>
> I'll check it out. I suspect there is some reference on uport already taken
> such that if port is valid uport must be valid.
Right, this routine is called from cxl_port_probe() which holds the
device_lock() and prevents the port from being unregistered before it
has gone through device_release_driver(). The port was registered by the
driver for @uport i.e. cxl_mem. That driver is guaranteed to unregister
the port before it is unregistered itself.
As long as you know that the code path is within the lifespan of
cxl_port_probe() and cxl_port_remove() you are guaranteed to not need to
manage reference counts on the associated cxl_memdev.
>
> >
> > > +
> > > + cdat_mb = find_cdat_mb(uport);
> > > + if (!cdat_mb) {
> > > + dev_dbg(dev, "No CDAT mailbox\n");
> > > + goto out;
> > > + }
> > > +
> > > + if (cxl_cdat_get_length(dev, cdat_mb, &cdat_length)) {
> > > + dev_dbg(dev, "No CDAT length\n");
> > > + goto out;
> > > + }
> > > +
> > > + port->cdat.table = devm_kzalloc(dev, cdat_length, GFP_KERNEL);
> > > + if (!port->cdat.table)
> > > + goto out;
> > > +
> > > + port->cdat.length = cdat_length;
> > > + ret = cxl_cdat_read_table(dev, cdat_mb, &port->cdat);
> > > + if (ret) {
> > > + /* Don't leave table data allocated on error */
> > > + devm_kfree(dev, port->cdat.table);
> > > + port->cdat.table = NULL;
> > > + port->cdat.length = 0;
> > > + dev_err(dev, "CDAT data read error\n");
> >
> > Rather than a chatty / ephemeral error message I think this wants some
> > indication in userspace, likely the 0-length CDAT binary attribute, so
> > that userspace can debug why the kernel is picking sub-optimal QTG ids
> > for newly provisioned CXL regions.
>
> I thought we agreed that 0-length or CDAT query failure would result in no
> sysfs entry?
Oh, I forgot about that, but some new rationale below...
>
> This message was to alert that a CDAT query was attempted but the read failed
> vs finding no mailbox with CDAT capabilities for example.
...right, but that's an error message buried in the kernel log. I was
hoping for something where tooling can query and say "oh, by the way,
the driver tried and failed to get CDAT from this device that claimed to
support CDAT, remedy that situation if you are seeing unexpected
performance / behavior".
>
> [snip]
>
> > >
> > > +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_port *port = to_cxl_port(dev);
> > > +
> > > + if (!port->cdat.table)
> > > + return 0;
> > > +
> > > + return memory_read_from_buffer(buf, count, &offset,
> > > + port->cdat.table,
> > > + port->cdat.length);
> > > +}
> > > +
> > > +static BIN_ATTR_RO(cdat, 0);
> >
> > This should be BIN_ATTR_ADMIN_RO(), see:
> >
> > 3022c6a1b4b7 driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}
>
> Are you suggesting I add BIN_ATTR_ADMIN_* macros?
Yes.
>
> >
> > > +
> > > +static umode_t cxl_port_bin_attr_is_visible(struct kobject *kobj,
> > > + struct bin_attribute *attr, int i)
> > > +{
> > > + struct device *dev = kobj_to_dev(kobj);
> > > + struct cxl_port *port = to_cxl_port(dev);
> > > +
> > > + if ((attr == &bin_attr_cdat) && port->cdat.table)
> > > + return 0400;
> >
> > Per above change you only need to manage visibility and not permissions,
>
> But the permissions indicate visibility (In the kdoc for struct
> attribute_group).
>
>
> * ... Must
> * return 0 if a binary attribute is not visible. The returned
> * value will replace static permissions defined in
> * struct bin_attribute.
>
> And the value returned overrides the mode.
>
> fs/sysfs/group.c:
>
> create_files()
>
> 82 if (grp->is_bin_visible) {
> 83 mode = grp->is_bin_visible(kobj, *bin_attr, i);
> 84 if (!mode)
> 85 continue;
> 86 }
> 87
> 88 WARN(mode & ~(SYSFS_PREALLOC | 0664),
> 89 "Attribute %s: Invalid permissions 0%o\n",
> 90 (*bin_attr)->attr.name, mode);
> 91
> 92 mode &= SYSFS_PREALLOC | 0664;
>
>
> So I'm willing to add the macro but I'm not sure it is going to change anything
> in this case.
The change I was expecting is that with BIN_ATTR_ADMIN_RO() this
implementation changes from:
if ((attr == &bin_attr_cdat) && port->cdat.table)
return 0400;
...to:
if ((attr == &bin_attr_cdat) && port->cdat.table)
return attr->mode;
...i.e. this routine only modifies visibility, you do not also need it
to enforce the root-read-only permission change since that's already
statically defined at attribute creation time.
> I think to make those _ADMIN_ macros work with is_visible()
> create_files() needs to be changed. :-/ I'm not sure if the addition of
> DEVICE_ATTR_ADMIN_{RO,RW} intended for is_visible() to be able to override the
> mode?
The intent was that one only needs to look in one place to read the
permission, and is_visible() is (mostly*) only left to change the mode to
0.
* changes from read-only to/from writable would still need is_visble()
to manipulate permissions, but you get the idea.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-17 22:40 ` Bjorn Helgaas
2022-06-18 16:39 ` Bjorn Helgaas
2022-06-20 9:24 ` Jonathan Cameron
@ 2022-06-22 16:38 ` Ira Weiny
2 siblings, 0 replies; 44+ messages in thread
From: Ira Weiny @ 2022-06-22 16:38 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Dan Williams, Bjorn Helgaas, Jonathan Cameron, Alison Schofield,
Vishal Verma, Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl,
linux-pci
On Fri, Jun 17, 2022 at 05:40:19PM -0500, Bjorn Helgaas wrote:
> On Fri, Jun 10, 2022 at 01:22:54PM -0700, ira.weiny@intel.com wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > Introduced in a PCI r6.0, sec 6.30, DOE provides a config space based
> > mailbox with standard protocol discovery. Each mailbox is accessed
> > through a DOE Extended Capability.
>
> > +/* Timeout of 1 second from 6.30.2 Operation, PCI Spec r6.0 */
>
> s/PCI/PCIe/ (up in commit log, too, I guess :))
>
> Not that there will ever be a conventional PCI r6.0 spec, but there
> was a PCI r3.0 well as a PCIe r3.0, so might as well keep them
> straight.
Done.
>
> > +struct pci_doe_mb {
> > + struct pci_dev *pdev;
>
> Trivial, but I would put cap_offset here next to pdev because the
> (pdev, cap_offset) tuple is basically the identifier for the DOE
> instance.
Done.
>
> > + struct completion abort_c;
> > + int irq;
> > + struct pci_doe_protocol *prots;
> > + int num_prots;
> > + u16 cap_offset;
>
> > +static void pci_doe_abort_start(struct pci_doe_mb *doe_mb)
> > +{
> > + struct pci_dev *pdev = doe_mb->pdev;
> > + int offset = doe_mb->cap_offset;
> > + u32 val;
> > +
> > + val = PCI_DOE_CTRL_ABORT;
> > + if (doe_mb->irq >= 0)
>
> Is zero a valid IRQ? In general, I don't think it is, but maybe this
> is a special case. Or maybe this is actually the "Interrupt Message
> Number" mentioned in sec 6.30.3? If so maybe something other than
> "irq" would be a better name here.
Yes I think irq is a bad name. I think 0 is valid here because this is the
Interrupt Message Number" from the DOE Capabilities Register (7.9.24.2).
At least with Qemu 0 is returned for the 1st mailbox. I'm not sure if that is
valid or not but I think it is.
But reading that in detail I think there is even more complexity than Jonathan
or I realized with regard to MSI vs MSI-X.
I'm going to leave the irq support in this layer (changing 'irq' to
'irq_msg_num'?) but I think the callers will need to resolve what support they
enable.
>
> Possibly relevant: a85a6c86c25b ("driver core: platform: Clarify that
> IRQ 0 is invalid")
>
> > + pci_err(pdev,
> > + "DOE [%x] expected [VID, Protocol] = [%04x, %02x], got [%04x, %02x]\n",
>
> Wouldn't make a big difference, but could consider something like this
> for enforced consistency:
>
> #define dev_fmt(fmt) "DOE: " fmt
Good idea.
>
> > + case DOE_WAIT_ABORT:
> > + case DOE_WAIT_ABORT_ON_ERR:
> > + prev_state = doe_mb->state;
> > +
> > + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> > +
> > + if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) &&
> > + !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) {
> > + doe_mb->state = DOE_IDLE;
> > + /* Back to normal state - carry on */
> > + retire_cur_task(doe_mb);
> > + } else if (time_after(jiffies, doe_mb->timeout_jiffies)) {
> > + /* Task has timed out and is dead - abort */
> > + pci_err(pdev, "DOE [%x] ABORT timed out\n",
> > + doe_mb->cap_offset);
> > + set_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags);
> > + retire_cur_task(doe_mb);
> > + }
> > +
> > + /*
> > + * For deliberately triggered abort, someone is
> > + * waiting.
> > + */
> > + if (prev_state == DOE_WAIT_ABORT) {
> > + if (task)
> > + signal_task_complete(task, -EFAULT);
> > + complete(&doe_mb->abort_c);
> > + }
> > +
> > + return;
> > + }
>
> The "return" in each case is perfectly correct, but it feels a little
> more conventional to make them "break" and return once here after the
> switch to make it clear that the only way to get to the labels is via
> an error path "goto".
Done.
>
> > +err_abort:
> > + doe_mb->state = DOE_WAIT_ABORT_ON_ERR;
> > + pci_doe_abort_start(doe_mb);
> > +err_busy:
> > + signal_task_complete(task, rc);
> > + if (doe_mb->state == DOE_IDLE)
> > + retire_cur_task(doe_mb);
> > +}
>
> > + * Enabling bus mastering is required for MSI/MSIx. It is safe to call
>
> s/MSIx/MSI-X/ (typical spelling in spec)
>
> > + * this multiple times and thus is called here to ensure that mastering
> > + * is enabled even if the driver has done so.
> > + */
> > + pci_set_master(pdev);
> > + rc = pci_request_irq(pdev, irq, pci_doe_irq_handler, NULL, doe_mb,
> > + "DOE[%d:%s]", irq, pci_name(pdev));
>
> I assume the "DOE[%d:%s]" part appears in /proc/interrupts?
Yes
> Is it
> redundant to include "irq", since /proc/interrupts already prints it,
> or is there somewhere else where "irq" is useful?
As you pointed out irq is the wrong name here. This is just the message
number.
>
> How does the user associate this IRQ in /proc/interrupts with a
> specific DOE capability? Should we include the cap_offset along with
> the pci_name()?
Good idea, cap_offset is much more useful. In my testing the irq's were all
unique but as Dan pointed out I did not realize that the message number could
be shared.
>
> > + * pci_doe_get_irq_num() - Return the irq number for the mailbox at offset
> > + *
> > + * @pdev: The PCI device
> > + * @offset: Offset of the DOE mailbox
> > + *
> > + * Returns: irq number on success
> > + * -errno if irqs are not supported on this mailbox
>
> I normally capitalize IRQ/IRQs in comments. There are probably others
> throughout the file. I notice some are already capitalized but not all.
Done.
>
> > + */
> > +int pci_doe_get_irq_num(struct pci_dev *pdev, int offset)
> > +{
> > + u32 val;
> > +
> > + pci_read_config_dword(pdev, offset + PCI_DOE_CAP, &val);
> > + if (!FIELD_GET(PCI_DOE_CAP_INT, val))
> > + return -EOPNOTSUPP;
> > +
> > + return FIELD_GET(PCI_DOE_CAP_IRQ, val);
> > +}
> > +EXPORT_SYMBOL_GPL(pci_doe_get_irq_num);
>
> Confusing function name (and comment) since PCI_DOE_CAP_IRQ is an
> Interrupt Message Number that has nothing to do with Linux IRQ
> numbers.
Agreed. Changed to pci_doe_get_irq_msg_num(); With corresponding fixups to
the kdoc.
>
> I see we already have PCI_EXP_FLAGS_IRQ, PCI_ERR_ROOT_AER_IRQ,
> PCI_EXP_DPC_IRQ, so I guess you're in good company.
>
> At least maybe update the comment to say "Interrupt Message Number"
> instead of "irq".
Yea I did that too.
>
> > + * pci_doe_supports_prot() - Return if the DOE instance supports the given
> > + * protocol
> > + * @doe_mb: DOE mailbox capability to query
> > + * @vid: Protocol Vendor ID
> > + * @type: Protocol type
> > + *
> > + * RETURNS: True if the DOE mailbox supports the protocol specified
>
> Is the typical use that the caller has a few specific protocols it
> cares about?
That is how CXL needs it right now yes.
> There's no case where a caller might want to enumerate
> them all?
Not at this time.
> I guess they're all in prots[], but that's supposed to be
> opaque to users.
Agreed. Something else would be needed in that use case.
>
> > + */
> > +bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type)
> > +{
> > + int i;
> > +
> > + /* The discovery protocol must always be supported */
> > + if (vid == PCI_VENDOR_ID_PCI_SIG && type == PCI_DOE_PROTOCOL_DISCOVERY)
> > + return true;
> > +
> > + for (i = 0; i < doe_mb->num_prots; i++)
> > + if ((doe_mb->prots[i].vid == vid) &&
> > + (doe_mb->prots[i].type == type))
> > + return true;
> > +
> > + return false;
> > +}
> > +EXPORT_SYMBOL_GPL(pci_doe_supports_prot);
>
> > + * struct pci_doe_task - represents a single query/response
> > + *
> > + * @prot: DOE Protocol
> > + * @request_pl: The request payload
> > + * @request_pl_sz: Size of the request payload
>
> Size is in dwords, not bytes, I guess?
No. Those are in bytes and the DOE layer takes care of the DW conversion.
I'll update the kdoc to make that clear.
Thanks again for the review,
Ira
>
> > + * @response_pl: The response payload
> > + * @response_pl_sz: Size of the response payload
> > + * @rv: Return value. Length of received response or error
> > + * @complete: Called when task is complete
> > + * @private: Private data for the consumer
> > + */
> > +struct pci_doe_task {
> > + struct pci_doe_protocol prot;
> > + u32 *request_pl;
> > + size_t request_pl_sz;
> > + u32 *response_pl;
> > + size_t response_pl_sz;
> > + int rv;
> > + void (*complete)(struct pci_doe_task *task);
> > + void *private;
> > +};
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-18 16:39 ` Bjorn Helgaas
@ 2022-06-22 16:46 ` Ira Weiny
0 siblings, 0 replies; 44+ messages in thread
From: Ira Weiny @ 2022-06-22 16:46 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Dan Williams, Bjorn Helgaas, Jonathan Cameron, Alison Schofield,
Vishal Verma, Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl,
linux-pci
On Sat, Jun 18, 2022 at 11:39:27AM -0500, Bjorn Helgaas wrote:
> On Fri, Jun 17, 2022 at 05:40:19PM -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 10, 2022 at 01:22:54PM -0700, ira.weiny@intel.com wrote:
> > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > >
> > > Introduced in a PCI r6.0, sec 6.30, DOE provides a config space based
> > > mailbox with standard protocol discovery. Each mailbox is accessed
> > > through a DOE Extended Capability.
>
> > > + * pci_doe_get_irq_num() - Return the irq number for the mailbox at offset
> > > + *
> > > + * @pdev: The PCI device
> > > + * @offset: Offset of the DOE mailbox
> > > + *
> > > + * Returns: irq number on success
> > > + * -errno if irqs are not supported on this mailbox
> > > + */
> > > +int pci_doe_get_irq_num(struct pci_dev *pdev, int offset)
> > > +{
> > > + u32 val;
> > > +
> > > + pci_read_config_dword(pdev, offset + PCI_DOE_CAP, &val);
> > > + if (!FIELD_GET(PCI_DOE_CAP_INT, val))
> > > + return -EOPNOTSUPP;
> > > +
> > > + return FIELD_GET(PCI_DOE_CAP_IRQ, val);
> > > +}
> > > +EXPORT_SYMBOL_GPL(pci_doe_get_irq_num);
> >
> > Confusing function name (and comment) since PCI_DOE_CAP_IRQ is an
> > Interrupt Message Number that has nothing to do with Linux IRQ
> > numbers.
> >
> > I see we already have PCI_EXP_FLAGS_IRQ, PCI_ERR_ROOT_AER_IRQ,
> > PCI_EXP_DPC_IRQ, so I guess you're in good company.
>
> Should have been more clear about this: I think we should rename the
> new one to be PCI_DOE_CAP_INT_MSG_NUM or similar, and rename the
> function as well. It's too confusing to use "irq" for both Linux IRQs
> and what the spec calls "Interupt Message Numbers".
Oh... ok I was thinking of using int_msg_num in the function and variable
names. I was just not sure about 'int'. But if you like it then I do too!
:-D
I'll update the code as well as that macro.
Thanks again!
Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-17 22:56 ` Dan Williams
2022-06-20 10:23 ` Jonathan Cameron
@ 2022-06-22 22:37 ` Ira Weiny
2022-06-22 22:45 ` Ira Weiny
2 siblings, 0 replies; 44+ messages in thread
From: Ira Weiny @ 2022-06-22 22:37 UTC (permalink / raw)
To: Dan Williams
Cc: Bjorn Helgaas, Jonathan Cameron, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
On Fri, Jun 17, 2022 at 03:56:38PM -0700, Dan Williams wrote:
> ira.weiny@ wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > Introduced in a PCI r6.0, sec 6.30, DOE provides a config space based
> > mailbox with standard protocol discovery. Each mailbox is accessed
> > through a DOE Extended Capability.
> >
> > Each DOE mailbox must support the DOE discovery protocol in addition to
> > any number of additional protocols.
> >
> > Define core PCI functionality to manage a single PCI DOE mailbox at a
> > defined config space offset. Functionality includes iterating,
> > creating, query of supported protocol, task submission, and destruction
> > of the mailboxes.
> >
> > If interrupts are desired, the interrupt number can be queried and
> > passed to the create function. Passing a negative value disables
> > interrupts for that mailbox. It is the callers responsibility to ensure
>
> s/callers/caller's/
Done.
[snip]
> > +
> > +enum pci_doe_state {
> > + DOE_IDLE,
> > + DOE_WAIT_RESP,
> > + DOE_WAIT_ABORT,
> > + DOE_WAIT_ABORT_ON_ERR,
> > +};
> > +
> > +#define PCI_DOE_FLAG_ABORT 0
> > +#define PCI_DOE_FLAG_DEAD 1
>
> Warning, I tend to review data structures first, so some of the
> questions below might have answers in the code, but I have hard time
> jumping to the implementation if the data structure is not clear.
These are just flags for the state machine.
>
> > +
> > +/**
> > + * struct pci_doe_mb - State for a single DOE mailbox
> > + *
> > + * This state is used to manage a single DOE mailbox capability. All fields
> > + * should be considered opaque to the consumers and the structure passed into
> > + * the helpers below after being created by devm_pci_doe_create()
>
> Hmm, why devm_ and not pcim_ like pcim_enable_device()?
Because I did not know there were pcim_* calls. But also because that comment
is wrong. :-( That was left over from a previous version.
With this version we had agreed to not use device managed calls in this layer
and depend on callers to do that if they wanted.
Since I'm spinning another version I think pcim_create_doe_mb() and dropping
pci_doe_destroy_mb() from the API is a good idea.
>
> > + *
> > + * @pdev: PCI device this mailbox belongs to
> > + * @abort_c: Completion used for initial abort handling
>
> What does initial abort handling mean? If it's just a single point in
> time use couldn't that be handled with an on-stack completion?
I think this is going to get reworked with the new dedicated workqueue. So I'm
not going to address it directly.
>
> > + * @irq: Interrupt used for signaling DOE ready or abort
> > + * @prots: Array of protocols supported on this DOE
> > + * @num_prots: Size of @prots array
> > + * @cap_offset: Capability offset
> > + * @wq: Wait queue to wait on if a query is in progress
> > + * @cur_task: Current task the state machine is working on
> > + * @task_lock: Protect cur_task
>
> Protect what about cur_task? Assigning and clearing a pointer is atomic.
As I explained before this is protecting the entrance to the state machine from
potentially multiple writer threads. See pci_doe_submit_task() for details...
However, again I think this is going to change with the new workqueue. So I'm
not going to try and address this directly.
>
> > + * @statemachine: Work item for the DOE state machine
>
> Why does the pci_doe_mb have a work item? I would expect a work item per
> task. Then this gets a waitqueue for free to wait for task completion.
> Otherwise I suspect this introduces complexity in the DOE implementation
> to simulate per-task-work that a workqueue per DOE and a work item per
> task gets you for free, and for recalling hardware context from one
> firing of the state machine to the next. Just run the task work all
> in-line in one context.
Yep. Sorry about not following the advise you gave to Jonathan before. I
should have checked with you.
j
>
> > + * @state: Current state of this DOE
> > + * @timeout_jiffies: 1 second after GO set
> > + * @busy_retries: Count of retry attempts
>
> Why is this tracked in the mailbox object itself?
Because this object doubles as the work item.
>
> > + * @flags: Bit array of PCI_DOE_FLAG_* flags
> > + *
> > + * Note: @prots can't be allocated with struct size because the number of
> > + * protocols is not known until after this structure is in use. However, the
> > + * single discovery protocol is always required to query for the number of
> > + * protocols.
>
> Sounds like maybe this wants to be an xarray indexed by the device's
> reported index.
Could be.
>
> > + */
> > +struct pci_doe_mb {
> > + struct pci_dev *pdev;
> > + struct completion abort_c;
> > + int irq;
> > + struct pci_doe_protocol *prots;
> > + int num_prots;
> > + u16 cap_offset;
> > +
> > + wait_queue_head_t wq;
> > + struct pci_doe_task *cur_task;
> > + spinlock_t task_lock;
> > + struct delayed_work statemachine;
> > + enum pci_doe_state state;
> > + unsigned long timeout_jiffies;
> > + unsigned int busy_retries;
> > + unsigned long flags;
> > +};
> > +
> > +static irqreturn_t pci_doe_irq_handler(int irq, void *data)
> > +{
> > + struct pci_doe_mb *doe_mb = data;
> > + struct pci_dev *pdev = doe_mb->pdev;
> > + int offset = doe_mb->cap_offset;
> > + u32 val;
> > +
> > + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> > + if (FIELD_GET(PCI_DOE_STATUS_INT_STATUS, val)) {
> > + pci_write_config_dword(pdev, offset + PCI_DOE_STATUS,
> > + PCI_DOE_STATUS_INT_STATUS);
> > + mod_delayed_work(system_wq, &doe_mb->statemachine, 0);
>
> Wait, no, not system_wq. I expected this wants a dedicated / ordered queue
> per doe and this likely wants a queue that can sleep while processing a
> task and just not support overlapping tasks.
>
> In that model the irq is just waking up any tasks in execution that are
> awaiting a polling timeout. The irq handler does:
>
> wake_up(&doe_mb->wait);
>
> ...and then task that is executing in the queue continues what it was
> doing.
Ok I've looked back and I think there was a lot of confusion here regarding the
use of a workqueue and the number of outstanding work items.
Very early on Jonathan had a queue of tasks. IIRC you suggested to get rid of
that complexity and just process a single task at a time because we never
expected the queue depth to be very deep (probably only 1 work item at a time
anyway).
I think that is how things got where they were.
After reading through this email I think you are correct. So I'm not going to
address any of this logic here because I think it will change quite a bit.
>
> > + return IRQ_HANDLED;
> > + }
> > +
> > + return IRQ_NONE;
> > +}
> > +
> > +/*
> > + * Only called when safe to directly access the DOE from
> > + * doe_statemachine_work(). Outside access is not protected. Users who
> > + * perform such access are left with the pieces.
>
> What pieces, where?
Ok again this comment is slightly out of date. This call is no longer part of
the 'user' API with the exception of destroying the mailbox whilst the state
machine is running.
I'll delete this comment.
> I expect the abort implementation would be something
> like:
See pci_doe_abort()
>
> set_bit(ABORT_PENDING) <== blocks new task submissions until clear
Yes
> flush_workqueue() <== make sure all in-flight tasks see the abort
Effectively yes. schedule_delayed_work() kicks the single work item which can
be in the state machine.
> do_doe_abort(...) <== do the abort
The state machine does this depending on where it is.
> clear_bit(ABORT_PENDING) <== optionally restart the tasks that were
> cancelled, or just expect them to be resubmitted.
This depends on where the item was in the state machine. It may have already
gotten a response in which case it would be complete or the submit task call
will start returning errors.
Again this path was only called when the mailbox was being destroyed so
resubmission was not possible anyway.
[snip]
> > +
> > +static void signal_task_complete(struct pci_doe_task *task, int rv)
> > +{
> > + task->rv = rv;
> > + task->complete(task);
> > +}
> > +
> > +static void retire_cur_task(struct pci_doe_mb *doe_mb)
> > +{
> > + spin_lock(&doe_mb->task_lock);
> > + doe_mb->cur_task = NULL;
> > + spin_unlock(&doe_mb->task_lock);
>
> What is the lock protecting here? Assigning a pointer is atomic, I think
> this question is moot with a work-item per-task model as retiring the
> task is just a typical work completion.
Yes moot.
[snip]
> > +
> > +static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
> > + u8 *protocol)
> > +{
> > + u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
> > + *index);
> > + u32 response_pl;
> > + DECLARE_COMPLETION_ONSTACK(c);
> > + struct pci_doe_task task = {
> > + .prot.vid = PCI_VENDOR_ID_PCI_SIG,
> > + .prot.type = PCI_DOE_PROTOCOL_DISCOVERY,
> > + .request_pl = &request_pl,
> > + .request_pl_sz = sizeof(request_pl),
> > + .response_pl = &response_pl,
> > + .response_pl_sz = sizeof(response_pl),
> > + .complete = pci_doe_task_complete,
> > + .private = &c,
> > + };
> > + int ret;
> > +
> > + ret = pci_doe_submit_task(doe_mb, &task);
> > + if (ret < 0)
> > + return ret;
> > +
> > + wait_for_completion(&c);
>
> Another place where the need for a completion can be replaced with
> flush_work().
No not here. While this call is internal it is actually acting like an
external caller. This specific wait is for that response to get back.
This pattern was specifically asked for by you. Previously Jonathan had a
synchronous call which took care of this but you said let all callers just
handle it themselves. So all callers submit a task and if they want to wait
for the response they have to do so themselves.
> The only thing flush_work() does not offer is the option
> to have an interruptible wait, but for in-kernel DOE cycles
> uninterruptible is ok.
>
> > +
> > + if (task.rv != 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_mb *doe_mb)
> > +{
> > + u8 index = 0;
> > + int num_prots;
> > + int rc;
> > +
> > + /* Discovery protocol must always be supported and must report itself */
> > + num_prots = 1;
> > +
> > + doe_mb->prots = kcalloc(num_prots, sizeof(*doe_mb->prots), GFP_KERNEL);
> > + if (!doe_mb->prots)
> > + return -ENOMEM;
> > +
> > + /*
> > + * NOTE: doe_mb_prots is freed by pci_doe_free_mb() automatically on
> > + * error if pci_doe_cache_protocols() fails past this point.
> > + */
> > + do {
> > + struct pci_doe_protocol *prot;
> > +
> > + prot = &doe_mb->prots[num_prots - 1];
> > + rc = pci_doe_discovery(doe_mb, &index, &prot->vid, &prot->type);
> > + if (rc)
> > + return rc;
> > +
> > + if (index) {
> > + struct pci_doe_protocol *prot_new;
> > +
> > + num_prots++;
> > + prot_new = krealloc(doe_mb->prots,
> > + sizeof(*doe_mb->prots) * num_prots,
> > + GFP_KERNEL);
>
> An xarray saves the need for krealloc(), and probably even the need for
> a separate 'struct pci_doe_protocol' allocation since that data fits
> into an unsigned long that the xarray is already allocating for you
> internally.
:-/
>
> So something like:
>
> struct pci_doe_protocol {
> union {
> unsigned long val;
> struct {
> u16 vid;
> u8 type;
> };
> };
> } prot;
>
> pci_doe_discovery(doe_mb, &index, &prot.vid, &prot.type);
>
> xa_insert(&doe_mb->prots, (unsigned long) index, (void *) prot.val, GFP_KERNEL);
>
> ...and then to retrieve:
>
> void *ent = xa_load(&doe_mb->prots, index);
> struct pci_doe_protocol prot = { .val = (unsigned long) ent };
>
> ...wrapped up nicely with helpers to hide all the casting.
Interesting idea.
>
>
> > + if (!prot_new)
> > + return -ENOMEM;
> > +
> > + doe_mb->prots = prot_new;
> > + }
> > + } while (index);
> > +
> > + doe_mb->num_prots = num_prots;
> > + return 0;
> > +}
> > +
> > +static int pci_doe_abort(struct pci_doe_mb *doe_mb)
> > +{
> > + reinit_completion(&doe_mb->abort_c);
> > + set_bit(PCI_DOE_FLAG_ABORT, &doe_mb->flags);
> > + schedule_delayed_work(&doe_mb->statemachine, 0);
> > + wait_for_completion(&doe_mb->abort_c);
> > +
> > + if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags))
> > + return -EIO;
> > +
> > + return 0;
> > +}
> > +
> > +static int pci_doe_enable_irq(struct pci_doe_mb *doe_mb, unsigned int irq)
> > +{
> > + struct pci_dev *pdev = doe_mb->pdev;
> > + int offset = doe_mb->cap_offset;
> > + int rc;
> > +
> > + /*
> > + * Enabling bus mastering is required for MSI/MSIx. It is safe to call
> > + * this multiple times and thus is called here to ensure that mastering
> > + * is enabled even if the driver has done so.
> > + */
>
> It is required for MSI/MSIx to work, yes, but if the caller that created
> the doe object has not set it yet that's its prerogative.
>
> > + pci_set_master(pdev);
> > + rc = pci_request_irq(pdev, irq, pci_doe_irq_handler, NULL, doe_mb,
> > + "DOE[%d:%s]", irq, pci_name(pdev));
>
> If the DOE object creation is use devm_ then this wants to be
> devm_request_irq(), although I now notice that devm_pci_doe_create()
> only existed in the code comments, not the implementation.
yea... Sorry.
>
> Is there any need for the unmanaged version of this API?
Only that we had agreed to create it unmanaged before because of some auxiliary
bus oddities which made it easier to use an unmanaged API. Now that that is
gone I'm changing it to pcim_*.
[snip]
> > +
> > +/**
> > + * pci_doe_get_irq_num() - Return the irq number for the mailbox at offset
> > + *
> > + * @pdev: The PCI device
> > + * @offset: Offset of the DOE mailbox
> > + *
> > + * Returns: irq number on success
> > + * -errno if irqs are not supported on this mailbox
> > + */
> > +int pci_doe_get_irq_num(struct pci_dev *pdev, int offset)
> > +{
> > + u32 val;
> > +
> > + pci_read_config_dword(pdev, offset + PCI_DOE_CAP, &val);
> > + if (!FIELD_GET(PCI_DOE_CAP_INT, val))
> > + return -EOPNOTSUPP;
>
> I think ENXIO would be more appropriate than this networking errno.
Done.
[snip]
> > +/**
> > + * pci_doe_supports_prot() - Return if the DOE instance supports the given
> > + * protocol
> > + * @doe_mb: DOE mailbox capability to query
> > + * @vid: Protocol Vendor ID
> > + * @type: Protocol type
> > + *
> > + * RETURNS: True if the DOE mailbox supports the protocol specified
> > + */
> > +bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type)
> > +{
> > + int i;
> > +
> > + /* The discovery protocol must always be supported */
> > + if (vid == PCI_VENDOR_ID_PCI_SIG && type == PCI_DOE_PROTOCOL_DISCOVERY)
> > + return true;
> > +
> > + for (i = 0; i < doe_mb->num_prots; i++)
> > + if ((doe_mb->prots[i].vid == vid) &&
> > + (doe_mb->prots[i].type == type))
> > + return true;
>
> This becomes an xa_for_each() loop and I don't think you even need
> ->num_prots after this conversion.
Probably not. I don't even think we need a loop if I understand xarray
correctly. If the vid/type tuple is the long index then looking up that in the
xarray would return NULL or the value. But I'm not super familiar with xarray
yet. So I reserve the right to use xa_for_each(). :-D
[snip]
> > +int pci_doe_submit_task(struct pci_doe_mb *doe_mb, struct pci_doe_task *task)
> > +{
> > + if (!pci_doe_supports_prot(doe_mb, task->prot.vid, task->prot.type))
> > + return -EINVAL;
> > +
> > + /* DOE requests must be a whole number of DW */
> > + if (task->request_pl_sz % sizeof(u32))
> > + return -EINVAL;
> > +
> > +again:
> > + spin_lock(&doe_mb->task_lock);
> > + if (doe_mb->cur_task) {
> > + spin_unlock(&doe_mb->task_lock);
> > + wait_event_interruptible(doe_mb->wq, doe_mb->cur_task == NULL);
> > + goto again;
> > + }
>
> This looks like it will scramble the order of competing submissions.
> With a work-item per task there may be a race to who call queue_work()
> first, but there will not follow-on races like the ones here for this
> "goto again" case.
Agreed. and this is all changing.
However, there was no guarantee about submission order in the API nor am I
going to add any. If a users needs some order they should ensure they are
submitting from a single thread or other synchronization mechanisms in the
callers.
[snip]
> > +void pci_doe_destroy_mb(struct pci_doe_mb *doe_mb)
> > +{
> > + /* abort any work in progress */
> > + pci_doe_abort(doe_mb);
> > +
> > + /* halt the state machine */
> > + cancel_delayed_work_sync(&doe_mb->statemachine);
> > +
> > + pci_doe_free_mb(doe_mb);
>
> Where do racing submitters get told that the DOE is closed for business?
All their submit tasks would return -ERESTARTSYS. If a task was in the
state machine it will return it's completion.
[snip]
> > +
> > +/**
> > + * pci_doe_for_each_off - Iterate each DOE capability
> > + * @pdev: struct pci_dev to iterate
> > + * @off: u16 of config space offset of each mailbox capability found
> > + */
> > +#define pci_doe_for_each_off(pdev, off) \
> > + for (off = pci_find_next_ext_capability(pdev, off, \
> > + PCI_EXT_CAP_ID_DOE); \
> > + off > 0; \
> > + off = pci_find_next_ext_capability(pdev, off, \
> > + PCI_EXT_CAP_ID_DOE))
>
> New for loop macros should also be added to .clang-format.
Done.
Thanks for the review,
Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-17 22:56 ` Dan Williams
2022-06-20 10:23 ` Jonathan Cameron
2022-06-22 22:37 ` Ira Weiny
@ 2022-06-22 22:45 ` Ira Weiny
2022-06-22 22:57 ` Dan Williams
2 siblings, 1 reply; 44+ messages in thread
From: Ira Weiny @ 2022-06-22 22:45 UTC (permalink / raw)
To: Dan Williams
Cc: Bjorn Helgaas, Jonathan Cameron, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
On Fri, Jun 17, 2022 at 03:56:38PM -0700, Dan Williams wrote:
> ira.weiny@ wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > Introduced in a PCI r6.0, sec 6.30, DOE provides a config space based
> > mailbox with standard protocol discovery. Each mailbox is accessed
> > through a DOE Extended Capability.
> >
> > Each DOE mailbox must support the DOE discovery protocol in addition to
> > any number of additional protocols.
> >
> > Define core PCI functionality to manage a single PCI DOE mailbox at a
> > defined config space offset. Functionality includes iterating,
> > creating, query of supported protocol, task submission, and destruction
> > of the mailboxes.
> >
> > If interrupts are desired, the interrupt number can be queried and
> > passed to the create function. Passing a negative value disables
> > interrupts for that mailbox. It is the callers responsibility to ensure
>
> s/callers/caller's/
Done.
[snip]
> > +
> > +enum pci_doe_state {
> > + DOE_IDLE,
> > + DOE_WAIT_RESP,
> > + DOE_WAIT_ABORT,
> > + DOE_WAIT_ABORT_ON_ERR,
> > +};
> > +
> > +#define PCI_DOE_FLAG_ABORT 0
> > +#define PCI_DOE_FLAG_DEAD 1
>
> Warning, I tend to review data structures first, so some of the
> questions below might have answers in the code, but I have hard time
> jumping to the implementation if the data structure is not clear.
These are just flags for the state machine.
>
> > +
> > +/**
> > + * struct pci_doe_mb - State for a single DOE mailbox
> > + *
> > + * This state is used to manage a single DOE mailbox capability. All fields
> > + * should be considered opaque to the consumers and the structure passed into
> > + * the helpers below after being created by devm_pci_doe_create()
>
> Hmm, why devm_ and not pcim_ like pcim_enable_device()?
Because I did not know there were pcim_* calls. But also because that comment
is wrong. :-( That was left over from a previous version.
With this version we had agreed to not use device managed calls in this layer
and depend on callers to do that if they wanted.
Since I'm spinning another version I think pcim_create_doe_mb() and dropping
pci_doe_destroy_mb() from the API is a good idea.
>
> > + *
> > + * @pdev: PCI device this mailbox belongs to
> > + * @abort_c: Completion used for initial abort handling
>
> What does initial abort handling mean? If it's just a single point in
> time use couldn't that be handled with an on-stack completion?
I think this is going to get reworked with the new dedicated workqueue. So I'm
not going to address it directly.
>
> > + * @irq: Interrupt used for signaling DOE ready or abort
> > + * @prots: Array of protocols supported on this DOE
> > + * @num_prots: Size of @prots array
> > + * @cap_offset: Capability offset
> > + * @wq: Wait queue to wait on if a query is in progress
> > + * @cur_task: Current task the state machine is working on
> > + * @task_lock: Protect cur_task
>
> Protect what about cur_task? Assigning and clearing a pointer is atomic.
As I explained before this is protecting the entrance to the state machine from
potentially multiple writer threads. See pci_doe_submit_task() for details...
However, again I think this is going to change with the new workqueue. So I'm
not going to try and address this directly.
>
> > + * @statemachine: Work item for the DOE state machine
>
> Why does the pci_doe_mb have a work item? I would expect a work item per
> task. Then this gets a waitqueue for free to wait for task completion.
> Otherwise I suspect this introduces complexity in the DOE implementation
> to simulate per-task-work that a workqueue per DOE and a work item per
> task gets you for free, and for recalling hardware context from one
> firing of the state machine to the next. Just run the task work all
> in-line in one context.
Yep. Sorry about not following the advise you gave to Jonathan before. I
should have checked with you.
j
>
> > + * @state: Current state of this DOE
> > + * @timeout_jiffies: 1 second after GO set
> > + * @busy_retries: Count of retry attempts
>
> Why is this tracked in the mailbox object itself?
Because this object doubles as the work item.
>
> > + * @flags: Bit array of PCI_DOE_FLAG_* flags
> > + *
> > + * Note: @prots can't be allocated with struct size because the number of
> > + * protocols is not known until after this structure is in use. However, the
> > + * single discovery protocol is always required to query for the number of
> > + * protocols.
>
> Sounds like maybe this wants to be an xarray indexed by the device's
> reported index.
Could be.
>
> > + */
> > +struct pci_doe_mb {
> > + struct pci_dev *pdev;
> > + struct completion abort_c;
> > + int irq;
> > + struct pci_doe_protocol *prots;
> > + int num_prots;
> > + u16 cap_offset;
> > +
> > + wait_queue_head_t wq;
> > + struct pci_doe_task *cur_task;
> > + spinlock_t task_lock;
> > + struct delayed_work statemachine;
> > + enum pci_doe_state state;
> > + unsigned long timeout_jiffies;
> > + unsigned int busy_retries;
> > + unsigned long flags;
> > +};
> > +
> > +static irqreturn_t pci_doe_irq_handler(int irq, void *data)
> > +{
> > + struct pci_doe_mb *doe_mb = data;
> > + struct pci_dev *pdev = doe_mb->pdev;
> > + int offset = doe_mb->cap_offset;
> > + u32 val;
> > +
> > + pci_read_config_dword(pdev, offset + PCI_DOE_STATUS, &val);
> > + if (FIELD_GET(PCI_DOE_STATUS_INT_STATUS, val)) {
> > + pci_write_config_dword(pdev, offset + PCI_DOE_STATUS,
> > + PCI_DOE_STATUS_INT_STATUS);
> > + mod_delayed_work(system_wq, &doe_mb->statemachine, 0);
>
> Wait, no, not system_wq. I expected this wants a dedicated / ordered queue
> per doe and this likely wants a queue that can sleep while processing a
> task and just not support overlapping tasks.
>
> In that model the irq is just waking up any tasks in execution that are
> awaiting a polling timeout. The irq handler does:
>
> wake_up(&doe_mb->wait);
>
> ...and then task that is executing in the queue continues what it was
> doing.
Ok I've looked back and I think there was a lot of confusion here regarding the
use of a workqueue and the number of outstanding work items.
Very early on Jonathan had a queue of tasks. IIRC you suggested to get rid of
that complexity and just process a single task at a time because we never
expected the queue depth to be very deep (probably only 1 work item at a time
anyway).
I think that is how things got where they were.
After reading through this email I think you are correct. So I'm not going to
address any of this logic here because I think it will change quite a bit.
>
> > + return IRQ_HANDLED;
> > + }
> > +
> > + return IRQ_NONE;
> > +}
> > +
> > +/*
> > + * Only called when safe to directly access the DOE from
> > + * doe_statemachine_work(). Outside access is not protected. Users who
> > + * perform such access are left with the pieces.
>
> What pieces, where?
Ok again this comment is slightly out of date. This call is no longer part of
the 'user' API with the exception of destroying the mailbox whilst the state
machine is running.
I'll delete this comment.
> I expect the abort implementation would be something
> like:
See pci_doe_abort()
>
> set_bit(ABORT_PENDING) <== blocks new task submissions until clear
Yes
> flush_workqueue() <== make sure all in-flight tasks see the abort
Effectively yes. schedule_delayed_work() kicks the single work item which can
be in the state machine.
> do_doe_abort(...) <== do the abort
The state machine does this depending on where it is.
> clear_bit(ABORT_PENDING) <== optionally restart the tasks that were
> cancelled, or just expect them to be resubmitted.
This depends on where the item was in the state machine. It may have already
gotten a response in which case it would be complete or the submit task call
will start returning errors.
Again this path was only called when the mailbox was being destroyed so
resubmission was not possible anyway.
[snip]
> > +
> > +static void signal_task_complete(struct pci_doe_task *task, int rv)
> > +{
> > + task->rv = rv;
> > + task->complete(task);
> > +}
> > +
> > +static void retire_cur_task(struct pci_doe_mb *doe_mb)
> > +{
> > + spin_lock(&doe_mb->task_lock);
> > + doe_mb->cur_task = NULL;
> > + spin_unlock(&doe_mb->task_lock);
>
> What is the lock protecting here? Assigning a pointer is atomic, I think
> this question is moot with a work-item per-task model as retiring the
> task is just a typical work completion.
Yes moot.
[snip]
> > +
> > +static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
> > + u8 *protocol)
> > +{
> > + u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
> > + *index);
> > + u32 response_pl;
> > + DECLARE_COMPLETION_ONSTACK(c);
> > + struct pci_doe_task task = {
> > + .prot.vid = PCI_VENDOR_ID_PCI_SIG,
> > + .prot.type = PCI_DOE_PROTOCOL_DISCOVERY,
> > + .request_pl = &request_pl,
> > + .request_pl_sz = sizeof(request_pl),
> > + .response_pl = &response_pl,
> > + .response_pl_sz = sizeof(response_pl),
> > + .complete = pci_doe_task_complete,
> > + .private = &c,
> > + };
> > + int ret;
> > +
> > + ret = pci_doe_submit_task(doe_mb, &task);
> > + if (ret < 0)
> > + return ret;
> > +
> > + wait_for_completion(&c);
>
> Another place where the need for a completion can be replaced with
> flush_work().
No not here. While this call is internal it is actually acting like an
external caller. This specific wait is for that response to get back.
This pattern was specifically asked for by you. Previously Jonathan had a
synchronous call which took care of this but you said let all callers just
handle it themselves. So all callers submit a task and if they want to wait
for the response they have to do so themselves.
> The only thing flush_work() does not offer is the option
> to have an interruptible wait, but for in-kernel DOE cycles
> uninterruptible is ok.
>
> > +
> > + if (task.rv != 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_mb *doe_mb)
> > +{
> > + u8 index = 0;
> > + int num_prots;
> > + int rc;
> > +
> > + /* Discovery protocol must always be supported and must report itself */
> > + num_prots = 1;
> > +
> > + doe_mb->prots = kcalloc(num_prots, sizeof(*doe_mb->prots), GFP_KERNEL);
> > + if (!doe_mb->prots)
> > + return -ENOMEM;
> > +
> > + /*
> > + * NOTE: doe_mb_prots is freed by pci_doe_free_mb() automatically on
> > + * error if pci_doe_cache_protocols() fails past this point.
> > + */
> > + do {
> > + struct pci_doe_protocol *prot;
> > +
> > + prot = &doe_mb->prots[num_prots - 1];
> > + rc = pci_doe_discovery(doe_mb, &index, &prot->vid, &prot->type);
> > + if (rc)
> > + return rc;
> > +
> > + if (index) {
> > + struct pci_doe_protocol *prot_new;
> > +
> > + num_prots++;
> > + prot_new = krealloc(doe_mb->prots,
> > + sizeof(*doe_mb->prots) * num_prots,
> > + GFP_KERNEL);
>
> An xarray saves the need for krealloc(), and probably even the need for
> a separate 'struct pci_doe_protocol' allocation since that data fits
> into an unsigned long that the xarray is already allocating for you
> internally.
:-/
>
> So something like:
>
> struct pci_doe_protocol {
> union {
> unsigned long val;
> struct {
> u16 vid;
> u8 type;
> };
> };
> } prot;
>
> pci_doe_discovery(doe_mb, &index, &prot.vid, &prot.type);
>
> xa_insert(&doe_mb->prots, (unsigned long) index, (void *) prot.val, GFP_KERNEL);
>
> ...and then to retrieve:
>
> void *ent = xa_load(&doe_mb->prots, index);
> struct pci_doe_protocol prot = { .val = (unsigned long) ent };
>
> ...wrapped up nicely with helpers to hide all the casting.
Interesting idea.
>
>
> > + if (!prot_new)
> > + return -ENOMEM;
> > +
> > + doe_mb->prots = prot_new;
> > + }
> > + } while (index);
> > +
> > + doe_mb->num_prots = num_prots;
> > + return 0;
> > +}
> > +
> > +static int pci_doe_abort(struct pci_doe_mb *doe_mb)
> > +{
> > + reinit_completion(&doe_mb->abort_c);
> > + set_bit(PCI_DOE_FLAG_ABORT, &doe_mb->flags);
> > + schedule_delayed_work(&doe_mb->statemachine, 0);
> > + wait_for_completion(&doe_mb->abort_c);
> > +
> > + if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags))
> > + return -EIO;
> > +
> > + return 0;
> > +}
> > +
> > +static int pci_doe_enable_irq(struct pci_doe_mb *doe_mb, unsigned int irq)
> > +{
> > + struct pci_dev *pdev = doe_mb->pdev;
> > + int offset = doe_mb->cap_offset;
> > + int rc;
> > +
> > + /*
> > + * Enabling bus mastering is required for MSI/MSIx. It is safe to call
> > + * this multiple times and thus is called here to ensure that mastering
> > + * is enabled even if the driver has done so.
> > + */
>
> It is required for MSI/MSIx to work, yes, but if the caller that created
> the doe object has not set it yet that's its prerogative.
>
> > + pci_set_master(pdev);
> > + rc = pci_request_irq(pdev, irq, pci_doe_irq_handler, NULL, doe_mb,
> > + "DOE[%d:%s]", irq, pci_name(pdev));
>
> If the DOE object creation is use devm_ then this wants to be
> devm_request_irq(), although I now notice that devm_pci_doe_create()
> only existed in the code comments, not the implementation.
yea... Sorry.
>
> Is there any need for the unmanaged version of this API?
Only that we had agreed to create it unmanaged before because of some auxiliary
bus oddities which made it easier to use an unmanaged API. Now that that is
gone I'm changing it to pcim_*.
[snip]
> > +
> > +/**
> > + * pci_doe_get_irq_num() - Return the irq number for the mailbox at offset
> > + *
> > + * @pdev: The PCI device
> > + * @offset: Offset of the DOE mailbox
> > + *
> > + * Returns: irq number on success
> > + * -errno if irqs are not supported on this mailbox
> > + */
> > +int pci_doe_get_irq_num(struct pci_dev *pdev, int offset)
> > +{
> > + u32 val;
> > +
> > + pci_read_config_dword(pdev, offset + PCI_DOE_CAP, &val);
> > + if (!FIELD_GET(PCI_DOE_CAP_INT, val))
> > + return -EOPNOTSUPP;
>
> I think ENXIO would be more appropriate than this networking errno.
Done.
[snip]
> > +/**
> > + * pci_doe_supports_prot() - Return if the DOE instance supports the given
> > + * protocol
> > + * @doe_mb: DOE mailbox capability to query
> > + * @vid: Protocol Vendor ID
> > + * @type: Protocol type
> > + *
> > + * RETURNS: True if the DOE mailbox supports the protocol specified
> > + */
> > +bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type)
> > +{
> > + int i;
> > +
> > + /* The discovery protocol must always be supported */
> > + if (vid == PCI_VENDOR_ID_PCI_SIG && type == PCI_DOE_PROTOCOL_DISCOVERY)
> > + return true;
> > +
> > + for (i = 0; i < doe_mb->num_prots; i++)
> > + if ((doe_mb->prots[i].vid == vid) &&
> > + (doe_mb->prots[i].type == type))
> > + return true;
>
> This becomes an xa_for_each() loop and I don't think you even need
> ->num_prots after this conversion.
Probably not. I don't even think we need a loop if I understand xarray
correctly. If the vid/type tuple is the long index then looking up that in the
xarray would return NULL or the value. But I'm not super familiar with xarray
yet. So I reserve the right to use xa_for_each(). :-D
[snip]
> > +int pci_doe_submit_task(struct pci_doe_mb *doe_mb, struct pci_doe_task *task)
> > +{
> > + if (!pci_doe_supports_prot(doe_mb, task->prot.vid, task->prot.type))
> > + return -EINVAL;
> > +
> > + /* DOE requests must be a whole number of DW */
> > + if (task->request_pl_sz % sizeof(u32))
> > + return -EINVAL;
> > +
> > +again:
> > + spin_lock(&doe_mb->task_lock);
> > + if (doe_mb->cur_task) {
> > + spin_unlock(&doe_mb->task_lock);
> > + wait_event_interruptible(doe_mb->wq, doe_mb->cur_task == NULL);
> > + goto again;
> > + }
>
> This looks like it will scramble the order of competing submissions.
> With a work-item per task there may be a race to who call queue_work()
> first, but there will not follow-on races like the ones here for this
> "goto again" case.
Agreed. and this is all changing.
However, there was no guarantee about submission order in the API nor am I
going to add any. If a users needs some order they should ensure they are
submitting from a single thread or other synchronization mechanisms in the
callers.
[snip]
> > +void pci_doe_destroy_mb(struct pci_doe_mb *doe_mb)
> > +{
> > + /* abort any work in progress */
> > + pci_doe_abort(doe_mb);
> > +
> > + /* halt the state machine */
> > + cancel_delayed_work_sync(&doe_mb->statemachine);
> > +
> > + pci_doe_free_mb(doe_mb);
>
> Where do racing submitters get told that the DOE is closed for business?
All their submit tasks would return -ERESTARTSYS. If a task was in the
state machine it will return it's completion.
[snip]
> > +
> > +/**
> > + * pci_doe_for_each_off - Iterate each DOE capability
> > + * @pdev: struct pci_dev to iterate
> > + * @off: u16 of config space offset of each mailbox capability found
> > + */
> > +#define pci_doe_for_each_off(pdev, off) \
> > + for (off = pci_find_next_ext_capability(pdev, off, \
> > + PCI_EXT_CAP_ID_DOE); \
> > + off > 0; \
> > + off = pci_find_next_ext_capability(pdev, off, \
> > + PCI_EXT_CAP_ID_DOE))
>
> New for loop macros should also be added to .clang-format.
Done.
Thanks for the review,
Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-22 22:45 ` Ira Weiny
@ 2022-06-22 22:57 ` Dan Williams
2022-06-23 0:25 ` Ira Weiny
0 siblings, 1 reply; 44+ messages in thread
From: Dan Williams @ 2022-06-22 22:57 UTC (permalink / raw)
To: Ira Weiny, Dan Williams
Cc: Bjorn Helgaas, Jonathan Cameron, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
Ira Weiny wrote:
> On Fri, Jun 17, 2022 at 03:56:38PM -0700, Dan Williams wrote:
[..]
> > > +static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
> > > + u8 *protocol)
> > > +{
> > > + u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
> > > + *index);
> > > + u32 response_pl;
> > > + DECLARE_COMPLETION_ONSTACK(c);
> > > + struct pci_doe_task task = {
> > > + .prot.vid = PCI_VENDOR_ID_PCI_SIG,
> > > + .prot.type = PCI_DOE_PROTOCOL_DISCOVERY,
> > > + .request_pl = &request_pl,
> > > + .request_pl_sz = sizeof(request_pl),
> > > + .response_pl = &response_pl,
> > > + .response_pl_sz = sizeof(response_pl),
> > > + .complete = pci_doe_task_complete,
> > > + .private = &c,
> > > + };
> > > + int ret;
> > > +
> > > + ret = pci_doe_submit_task(doe_mb, &task);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + wait_for_completion(&c);
> >
> > Another place where the need for a completion can be replaced with
> > flush_work().
>
> No not here. While this call is internal it is actually acting like an
> external caller. This specific wait is for that response to get back.
>
> This pattern was specifically asked for by you. Previously Jonathan had a
> synchronous call which took care of this but you said let all callers just
> handle it themselves. So all callers submit a task and if they want to wait
> for the response they have to do so themselves.
Ah, true I remember that. The nice thing about a doing your own
wait_for_completion() like this is that you can make it
wait_for_completion_interruptible() to give up on the DOE if it gets
stalled. However, if you have a work item per-task and you're willing to
do an uninterruptible sleep, then flush_work(&task->work) is identical.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-20 10:23 ` Jonathan Cameron
@ 2022-06-22 22:57 ` Ira Weiny
2022-06-23 18:03 ` Dan Williams
0 siblings, 1 reply; 44+ messages in thread
From: Ira Weiny @ 2022-06-22 22:57 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Dan Williams, Bjorn Helgaas, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
On Mon, Jun 20, 2022 at 11:23:28AM +0100, Jonathan Cameron wrote:
> On Fri, 17 Jun 2022 15:56:38 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
>
[snip]
> > > +static int pci_doe_enable_irq(struct pci_doe_mb *doe_mb, unsigned int irq)
> > > +{
> > > + struct pci_dev *pdev = doe_mb->pdev;
> > > + int offset = doe_mb->cap_offset;
> > > + int rc;
> > > +
> > > + /*
> > > + * Enabling bus mastering is required for MSI/MSIx. It is safe to call
> > > + * this multiple times and thus is called here to ensure that mastering
> > > + * is enabled even if the driver has done so.
> > > + */
> >
> > It is required for MSI/MSIx to work, yes, but if the caller that created
> > the doe object has not set it yet that's its prerogative.
>
> We went around this in one of the earlier threads, and I think consensus
> was that it made sense to have this in core code.
Yes we did. This is where Bjorn asked for this to be done I thought.
I verified that pci_set_master() is fine to call more than one time. If the
caller asks for irq support I think it is fine to do this here to ensure that
support is enabled.
Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-20 9:24 ` Jonathan Cameron
@ 2022-06-22 23:06 ` Ira Weiny
0 siblings, 0 replies; 44+ messages in thread
From: Ira Weiny @ 2022-06-22 23:06 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Bjorn Helgaas, Dan Williams, Bjorn Helgaas, Alison Schofield,
Vishal Verma, Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl,
linux-pci
On Mon, Jun 20, 2022 at 10:24:49AM +0100, Jonathan Cameron wrote:
>
> Hi Bjorn,
>
> Thanks for reviewing! Up to Ira of course, but I agree with all your
> comments
Me too! :-D
> - a few responses to questions follow.
>
>
> >
> > > + * pci_doe_supports_prot() - Return if the DOE instance supports the given
> > > + * protocol
> > > + * @doe_mb: DOE mailbox capability to query
> > > + * @vid: Protocol Vendor ID
> > > + * @type: Protocol type
> > > + *
> > > + * RETURNS: True if the DOE mailbox supports the protocol specified
> >
> > Is the typical use that the caller has a few specific protocols it
> > cares about? There's no case where a caller might want to enumerate
> > them all? I guess they're all in prots[], but that's supposed to be
> > opaque to users.
>
> Given each protocol needs specific handling in the driver, the only
> usecase for a general enumeration would be debug I think. Maybe
> it makes sense to provide that info to userspace somewhere, but
> definitely feels like something for a follow up discussion.
Yep, CXL just needs to find out which mailbox has CDAT on it.
> >
> > > + */
> > > +bool pci_doe_supports_prot(struct pci_doe_mb *doe_mb, u16 vid, u8 type)
> > > +{
> > > + int i;
> > > +
> > > + /* The discovery protocol must always be supported */
> > > + if (vid == PCI_VENDOR_ID_PCI_SIG && type == PCI_DOE_PROTOCOL_DISCOVERY)
> > > + return true;
> > > +
> > > + for (i = 0; i < doe_mb->num_prots; i++)
> > > + if ((doe_mb->prots[i].vid == vid) &&
> > > + (doe_mb->prots[i].type == type))
> > > + return true;
> > > +
> > > + return false;
> > > +}
> > > +EXPORT_SYMBOL_GPL(pci_doe_supports_prot);
> >
> > > + * struct pci_doe_task - represents a single query/response
> > > + *
> > > + * @prot: DOE Protocol
> > > + * @request_pl: The request payload
> > > + * @request_pl_sz: Size of the request payload
> >
> > Size is in dwords, not bytes, I guess?
>
> It's in bytes (IIRC) - we divide it by. It's a bit of a mess,
> but there are parts of SPDM over CMA where messages are not
> full number of dwords. My thinking was that we 'might' move
> the padding into the generic code if this becomes something
> multiple protocols need. For now the RFC does the
> padding at the CMA layer.
I think at this layer the DOE protocol specifies all message sizes are in
multiples of DW's. So I think this layer should enforce that. Other protocols
will need to pad if they need to based on their need.
> Let's avoid this being unclear in future by stating that it's
> in bytes in the comment.
Already done!
Thanks Jonathan!
Ira
>
> Jonathan
>
> >
> > > + * @response_pl: The response payload
> > > + * @response_pl_sz: Size of the response payload
> > > + * @rv: Return value. Length of received response or error
> > > + * @complete: Called when task is complete
> > > + * @private: Private data for the consumer
> > > + */
> > > +struct pci_doe_task {
> > > + struct pci_doe_protocol prot;
> > > + u32 *request_pl;
> > > + size_t request_pl_sz;
> > > + u32 *response_pl;
> > > + size_t response_pl_sz;
> > > + int rv;
> > > + void (*complete)(struct pci_doe_task *task);
> > > + void *private;
> > > +};
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices
2022-06-21 18:29 ` Ira Weiny
@ 2022-06-22 23:18 ` Ira Weiny
0 siblings, 0 replies; 44+ messages in thread
From: Ira Weiny @ 2022-06-22 23:18 UTC (permalink / raw)
To: Dan Williams
Cc: Bjorn Helgaas, Jonathan Cameron, Ben Widawsky, Alison Schofield,
Vishal Verma, Dave Jiang, linux-kernel, linux-cxl, linux-pci
On Tue, Jun 21, 2022 at 11:29:35AM -0700, Ira wrote:
> On Fri, Jun 17, 2022 at 04:44:27PM -0700, Dan Williams wrote:
> > ira.weiny@ wrote:
>
> [snip]
>
> > > diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
> > > index 60d10ee1e7fc..4d2764b865ab 100644
> > > --- a/drivers/cxl/cxlmem.h
> > > +++ b/drivers/cxl/cxlmem.h
> > > @@ -191,6 +191,8 @@ struct cxl_endpoint_dvsec_info {
> > > * @component_reg_phys: register base of component registers
> > > * @info: Cached DVSEC information about the device.
> > > * @serial: PCIe Device Serial Number
> > > + * @doe_mbs: PCI DOE mailbox array
> > > + * @num_mbs: Number of DOE mailboxes
> > > * @mbox_send: @dev specific transport for transmitting mailbox commands
> > > *
> > > * See section 8.2.9.5.2 Capacity Configuration and Label Storage for
> > > @@ -224,6 +226,10 @@ struct cxl_dev_state {
> > > resource_size_t component_reg_phys;
> > > u64 serial;
> > >
> > > + bool doe_use_irq;
> >
> > Don't pass temporary state through a long lived data structure. Just
> > pass flag by reference between the functions that want to coordinate
> > this.
>
> Done.
>
> [snip]
>
> > > +
> > > +static void cxl_alloc_irq_vectors(struct cxl_dev_state *cxlds)
> > > +{
> > > + struct device *dev = cxlds->dev;
> > > + struct pci_dev *pdev = to_pci_dev(dev);
> > > + int max_irqs = 0;
> > > + int off = 0;
> > > + int rc;
> > > +
> > > + /* Account for all the DOE vectors needed */
> > > + pci_doe_for_each_off(pdev, off) {
> > > + int irq = pci_doe_get_irq_num(pdev, off);
> > > +
> > > + if (irq < 0)
> > > + continue;
> > > + max_irqs = max(max_irqs, irq + 1);
> >
> > This seems to assume that different DOEs will get independent vectors.
> > The driver needs to be prepared for DOE instances, Event notifications,
> > and mailbox commands to share a single MSI vector in the worst case.
> > Lets focus on polled mode DOE, or explicitly only support interrupt
> > based operation when no vector sharing is detected.
> >
>
> Ok I see now. I was under the impression they had to be unique.
>
> Do you think it is sufficient to check in this loop for duplicates and bail if
> any are shared?
I'm still removing the irq code from the CXL layer but I had to look a bit
deeper at this for my own knowledge.
I don't think shared interrupt numbers is a problem because the
pci_request_irq() used within pci_doe_create_mb() specifies IRQF_SHARED.
drivers/pci/irq.c:
int pci_request_irq(struct pci_dev *dev, unsigned int nr, irq_handler_t handler,
irq_handler_t thread_fn, void *dev_id, const char *fmt, ...)
{
...
unsigned long irqflags = IRQF_SHARED;
...
So I think this would work even with share vectors, right?
Regardless, setting up the CXL/PCI IRQs is a bit of a mess. So I'm still going
to remove the IRQ code in the CXL layer. But I think it is safe to leave the
IRQ code in the pci/doe.c layer for others to use.
Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-22 22:57 ` Dan Williams
@ 2022-06-23 0:25 ` Ira Weiny
2022-06-23 10:24 ` Jonathan Cameron
2022-06-23 18:07 ` Dan Williams
0 siblings, 2 replies; 44+ messages in thread
From: Ira Weiny @ 2022-06-23 0:25 UTC (permalink / raw)
To: Dan Williams
Cc: Bjorn Helgaas, Jonathan Cameron, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
On Wed, Jun 22, 2022 at 03:57:34PM -0700, Dan Williams wrote:
> Ira Weiny wrote:
> > On Fri, Jun 17, 2022 at 03:56:38PM -0700, Dan Williams wrote:
> [..]
> > > > +static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
> > > > + u8 *protocol)
> > > > +{
> > > > + u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
> > > > + *index);
> > > > + u32 response_pl;
> > > > + DECLARE_COMPLETION_ONSTACK(c);
> > > > + struct pci_doe_task task = {
> > > > + .prot.vid = PCI_VENDOR_ID_PCI_SIG,
> > > > + .prot.type = PCI_DOE_PROTOCOL_DISCOVERY,
> > > > + .request_pl = &request_pl,
> > > > + .request_pl_sz = sizeof(request_pl),
> > > > + .response_pl = &response_pl,
> > > > + .response_pl_sz = sizeof(response_pl),
> > > > + .complete = pci_doe_task_complete,
> > > > + .private = &c,
> > > > + };
> > > > + int ret;
> > > > +
> > > > + ret = pci_doe_submit_task(doe_mb, &task);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + wait_for_completion(&c);
> > >
> > > Another place where the need for a completion can be replaced with
> > > flush_work().
> >
> > No not here. While this call is internal it is actually acting like an
> > external caller. This specific wait is for that response to get back.
> >
> > This pattern was specifically asked for by you. Previously Jonathan had a
> > synchronous call which took care of this but you said let all callers just
> > handle it themselves. So all callers submit a task and if they want to wait
> > for the response they have to do so themselves.
>
> Ah, true I remember that. The nice thing about a doing your own
> wait_for_completion() like this is that you can make it
> wait_for_completion_interruptible() to give up on the DOE if it gets
> stalled. However, if you have a work item per-task and you're willing to
> do an uninterruptible sleep, then flush_work(&task->work) is identical.
So when you mentioned a work item per task I really jumped on that idea. But I
realize now that it is a bit more complicated than that.
Currently a work item is actually one step of the state machine. The state
machine queues the next step of work as a new work item.
I'm going to have to change the state machine quite a bit. I still agree with
the one work item per task but it is going to take a bit of work to get the
state machine to operate within that single task.
I don't like what might result if I layer a work queue on top of using the
system work queue for the individual steps of the state machine. So stay
tuned.
Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-23 0:25 ` Ira Weiny
@ 2022-06-23 10:24 ` Jonathan Cameron
2022-06-23 18:14 ` Dan Williams
2022-06-23 18:07 ` Dan Williams
1 sibling, 1 reply; 44+ messages in thread
From: Jonathan Cameron @ 2022-06-23 10:24 UTC (permalink / raw)
To: Ira Weiny
Cc: Dan Williams, Bjorn Helgaas, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
On Wed, 22 Jun 2022 17:25:02 -0700
Ira Weiny <ira.weiny@intel.com> wrote:
> On Wed, Jun 22, 2022 at 03:57:34PM -0700, Dan Williams wrote:
> > Ira Weiny wrote:
> > > On Fri, Jun 17, 2022 at 03:56:38PM -0700, Dan Williams wrote:
> > [..]
> > > > > +static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
> > > > > + u8 *protocol)
> > > > > +{
> > > > > + u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
> > > > > + *index);
> > > > > + u32 response_pl;
> > > > > + DECLARE_COMPLETION_ONSTACK(c);
> > > > > + struct pci_doe_task task = {
> > > > > + .prot.vid = PCI_VENDOR_ID_PCI_SIG,
> > > > > + .prot.type = PCI_DOE_PROTOCOL_DISCOVERY,
> > > > > + .request_pl = &request_pl,
> > > > > + .request_pl_sz = sizeof(request_pl),
> > > > > + .response_pl = &response_pl,
> > > > > + .response_pl_sz = sizeof(response_pl),
> > > > > + .complete = pci_doe_task_complete,
> > > > > + .private = &c,
> > > > > + };
> > > > > + int ret;
> > > > > +
> > > > > + ret = pci_doe_submit_task(doe_mb, &task);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + wait_for_completion(&c);
> > > >
> > > > Another place where the need for a completion can be replaced with
> > > > flush_work().
> > >
> > > No not here. While this call is internal it is actually acting like an
> > > external caller. This specific wait is for that response to get back.
> > >
> > > This pattern was specifically asked for by you. Previously Jonathan had a
> > > synchronous call which took care of this but you said let all callers just
> > > handle it themselves. So all callers submit a task and if they want to wait
> > > for the response they have to do so themselves.
> >
> > Ah, true I remember that. The nice thing about a doing your own
> > wait_for_completion() like this is that you can make it
> > wait_for_completion_interruptible() to give up on the DOE if it gets
> > stalled. However, if you have a work item per-task and you're willing to
> > do an uninterruptible sleep, then flush_work(&task->work) is identical.
>
> So when you mentioned a work item per task I really jumped on that idea. But I
> realize now that it is a bit more complicated than that.
>
> Currently a work item is actually one step of the state machine. The state
> machine queues the next step of work as a new work item.
>
> I'm going to have to change the state machine quite a bit. I still agree with
> the one work item per task but it is going to take a bit of work to get the
> state machine to operate within that single task.
>
> I don't like what might result if I layer a work queue on top of using the
> system work queue for the individual steps of the state machine. So stay
> tuned.
Yup. I went through that (between RFC v1 and RFC v2) and it wasn't pretty
- maybe it's worth a revisit though.
To throw another view point in the mix. Note that I want a solution and
in my view DOE is slow and never on a fast path + I don't see it being
high churn code so needs to be fairly maintainable but not super simple
or architecturally clean (at the level of state machines / work queues etc
- interfaces need to be clean!)
If we go back to RFC v1, which IIRC was basically queue on a mutex, and
consider it in the light of where we've ended up. I wussed out on arguing much
about this at the time because consensus + moving forward was more
important to me than the chosen architecture.
Taking a slightly black and white view of requirements. I don't think
we loose anything by using this list...
1. Synchronous (if anyone needs async at level of caller, they can spin
a thread up). Async is the corner case, not the common one.
2. Small number (< 3 I'm guessing) of protocols per instance.
3. Very rare there is significant contention. Fairness doesn't matter.
Normally the only reason we'd get contention is userspace triggering
access to multiple protocols at a time - probably via sysfs or other slow
method.
4. Per protocol ordering can be maintained by the protocol, not the DOE layer.
5. DOE is basically a bus over which we are talking to different devices
- think of it like I2C but rather than address we have protocol IDs.
That last analogy brings us back to how I think almost all slow buses are
handled.
At level of a bus, a lock is used for mutual exclusion (often also protecting
bus controller register state etc). No workqueues or similar complexity
- Underlying hardware typically doing DMA of result into a provided buffer
with only one transaction in flight at that layer at anyone time.
Note there is more complex handling for high perf cases, but in many cases
its not really used.
We have a bus lock that can ensure exclusion over sequences if necessary
(there's one in SPI).
If a given driver needs to ensure exclusion for RMW or similar sequences
of operations it takes a driver specific mutex and holds it across these
sequences of slow operations, which usually sleep, include interrupts and all
sorts of fun. Normally there is a completion in there somewhere to
get from the 'done' interrupt on the bus controller back to the
i2c_smbus_bus_read() etc that is waiting on the result.
This model works, is super simple and layered.
In case of no contention (perhaps 99% of time), it immediately runs the
DOE/bus access in the thread that made the read/write request.
So no overhead of going to a workqueue.
Implementation is one linear function, no state machine needed.
Anyhow, to refer back to my initial comment. I'm not that fussed on how
we do this but it's a blocker on other work so quick solution is more
important to me than perfect one.
Jonathan
>
> Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-22 22:57 ` Ira Weiny
@ 2022-06-23 18:03 ` Dan Williams
0 siblings, 0 replies; 44+ messages in thread
From: Dan Williams @ 2022-06-23 18:03 UTC (permalink / raw)
To: Ira Weiny, Jonathan Cameron
Cc: Dan Williams, Bjorn Helgaas, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
Ira Weiny wrote:
> On Mon, Jun 20, 2022 at 11:23:28AM +0100, Jonathan Cameron wrote:
> > On Fri, 17 Jun 2022 15:56:38 -0700
> > Dan Williams <dan.j.williams@intel.com> wrote:
> >
>
> [snip]
>
> > > > +static int pci_doe_enable_irq(struct pci_doe_mb *doe_mb, unsigned int irq)
> > > > +{
> > > > + struct pci_dev *pdev = doe_mb->pdev;
> > > > + int offset = doe_mb->cap_offset;
> > > > + int rc;
> > > > +
> > > > + /*
> > > > + * Enabling bus mastering is required for MSI/MSIx. It is safe to call
> > > > + * this multiple times and thus is called here to ensure that mastering
> > > > + * is enabled even if the driver has done so.
> > > > + */
> > >
> > > It is required for MSI/MSIx to work, yes, but if the caller that created
> > > the doe object has not set it yet that's its prerogative.
> >
> > We went around this in one of the earlier threads, and I think consensus
> > was that it made sense to have this in core code.
>
> Yes we did. This is where Bjorn asked for this to be done I thought.
>
> I verified that pci_set_master() is fine to call more than one time. If the
> caller asks for irq support I think it is fine to do this here to ensure that
> support is enabled.
Its moot now that irq support is being pushed out to a follow-on
change, but I think its unfortunate that this makes it difficult to
audit when and where a device will be enabled to send cycles. If at all
possible I think it makes sense to keep this the responsibility of the
driver for the pci_dev. Similar to how pcie_port_device_register() does
this on behalf of the services it registers rather than each service
doing this itself.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-23 0:25 ` Ira Weiny
2022-06-23 10:24 ` Jonathan Cameron
@ 2022-06-23 18:07 ` Dan Williams
1 sibling, 0 replies; 44+ messages in thread
From: Dan Williams @ 2022-06-23 18:07 UTC (permalink / raw)
To: Ira Weiny, Dan Williams
Cc: Bjorn Helgaas, Jonathan Cameron, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
Ira Weiny wrote:
> On Wed, Jun 22, 2022 at 03:57:34PM -0700, Dan Williams wrote:
> > Ira Weiny wrote:
> > > On Fri, Jun 17, 2022 at 03:56:38PM -0700, Dan Williams wrote:
> > [..]
> > > > > +static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
> > > > > + u8 *protocol)
> > > > > +{
> > > > > + u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
> > > > > + *index);
> > > > > + u32 response_pl;
> > > > > + DECLARE_COMPLETION_ONSTACK(c);
> > > > > + struct pci_doe_task task = {
> > > > > + .prot.vid = PCI_VENDOR_ID_PCI_SIG,
> > > > > + .prot.type = PCI_DOE_PROTOCOL_DISCOVERY,
> > > > > + .request_pl = &request_pl,
> > > > > + .request_pl_sz = sizeof(request_pl),
> > > > > + .response_pl = &response_pl,
> > > > > + .response_pl_sz = sizeof(response_pl),
> > > > > + .complete = pci_doe_task_complete,
> > > > > + .private = &c,
> > > > > + };
> > > > > + int ret;
> > > > > +
> > > > > + ret = pci_doe_submit_task(doe_mb, &task);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + wait_for_completion(&c);
> > > >
> > > > Another place where the need for a completion can be replaced with
> > > > flush_work().
> > >
> > > No not here. While this call is internal it is actually acting like an
> > > external caller. This specific wait is for that response to get back.
> > >
> > > This pattern was specifically asked for by you. Previously Jonathan had a
> > > synchronous call which took care of this but you said let all callers just
> > > handle it themselves. So all callers submit a task and if they want to wait
> > > for the response they have to do so themselves.
> >
> > Ah, true I remember that. The nice thing about a doing your own
> > wait_for_completion() like this is that you can make it
> > wait_for_completion_interruptible() to give up on the DOE if it gets
> > stalled. However, if you have a work item per-task and you're willing to
> > do an uninterruptible sleep, then flush_work(&task->work) is identical.
>
> So when you mentioned a work item per task I really jumped on that idea. But I
> realize now that it is a bit more complicated than that.
>
> Currently a work item is actually one step of the state machine. The state
> machine queues the next step of work as a new work item.
>
> I'm going to have to change the state machine quite a bit. I still agree with
> the one work item per task but it is going to take a bit of work to get the
> state machine to operate within that single task.
>
> I don't like what might result if I layer a work queue on top of using the
> system work queue for the individual steps of the state machine. So stay
> tuned.
In the end only one workqueue should exist either a task queue (my first
preference) or a device-state queue (if the task queue turns out not to
fit), but neither of those use cases should be glomming onto the
unbounded system_wq. Keep it simple with a dedicated ordered queue.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes.
2022-06-23 10:24 ` Jonathan Cameron
@ 2022-06-23 18:14 ` Dan Williams
0 siblings, 0 replies; 44+ messages in thread
From: Dan Williams @ 2022-06-23 18:14 UTC (permalink / raw)
To: Jonathan Cameron, Ira Weiny
Cc: Dan Williams, Bjorn Helgaas, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
Jonathan Cameron wrote:
> On Wed, 22 Jun 2022 17:25:02 -0700
> Ira Weiny <ira.weiny@intel.com> wrote:
>
> > On Wed, Jun 22, 2022 at 03:57:34PM -0700, Dan Williams wrote:
> > > Ira Weiny wrote:
> > > > On Fri, Jun 17, 2022 at 03:56:38PM -0700, Dan Williams wrote:
> > > [..]
> > > > > > +static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
> > > > > > + u8 *protocol)
> > > > > > +{
> > > > > > + u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
> > > > > > + *index);
> > > > > > + u32 response_pl;
> > > > > > + DECLARE_COMPLETION_ONSTACK(c);
> > > > > > + struct pci_doe_task task = {
> > > > > > + .prot.vid = PCI_VENDOR_ID_PCI_SIG,
> > > > > > + .prot.type = PCI_DOE_PROTOCOL_DISCOVERY,
> > > > > > + .request_pl = &request_pl,
> > > > > > + .request_pl_sz = sizeof(request_pl),
> > > > > > + .response_pl = &response_pl,
> > > > > > + .response_pl_sz = sizeof(response_pl),
> > > > > > + .complete = pci_doe_task_complete,
> > > > > > + .private = &c,
> > > > > > + };
> > > > > > + int ret;
> > > > > > +
> > > > > > + ret = pci_doe_submit_task(doe_mb, &task);
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + wait_for_completion(&c);
> > > > >
> > > > > Another place where the need for a completion can be replaced with
> > > > > flush_work().
> > > >
> > > > No not here. While this call is internal it is actually acting like an
> > > > external caller. This specific wait is for that response to get back.
> > > >
> > > > This pattern was specifically asked for by you. Previously Jonathan had a
> > > > synchronous call which took care of this but you said let all callers just
> > > > handle it themselves. So all callers submit a task and if they want to wait
> > > > for the response they have to do so themselves.
> > >
> > > Ah, true I remember that. The nice thing about a doing your own
> > > wait_for_completion() like this is that you can make it
> > > wait_for_completion_interruptible() to give up on the DOE if it gets
> > > stalled. However, if you have a work item per-task and you're willing to
> > > do an uninterruptible sleep, then flush_work(&task->work) is identical.
> >
> > So when you mentioned a work item per task I really jumped on that idea. But I
> > realize now that it is a bit more complicated than that.
> >
> > Currently a work item is actually one step of the state machine. The state
> > machine queues the next step of work as a new work item.
> >
> > I'm going to have to change the state machine quite a bit. I still agree with
> > the one work item per task but it is going to take a bit of work to get the
> > state machine to operate within that single task.
> >
> > I don't like what might result if I layer a work queue on top of using the
> > system work queue for the individual steps of the state machine. So stay
> > tuned.
>
> Yup. I went through that (between RFC v1 and RFC v2) and it wasn't pretty
> - maybe it's worth a revisit though.
>
> To throw another view point in the mix. Note that I want a solution and
> in my view DOE is slow and never on a fast path + I don't see it being
> high churn code so needs to be fairly maintainable but not super simple
> or architecturally clean (at the level of state machines / work queues etc
> - interfaces need to be clean!)
>
> If we go back to RFC v1, which IIRC was basically queue on a mutex, and
> consider it in the light of where we've ended up. I wussed out on arguing much
> about this at the time because consensus + moving forward was more
> important to me than the chosen architecture.
>
> Taking a slightly black and white view of requirements. I don't think
> we loose anything by using this list...
>
> 1. Synchronous (if anyone needs async at level of caller, they can spin
> a thread up). Async is the corner case, not the common one.
> 2. Small number (< 3 I'm guessing) of protocols per instance.
> 3. Very rare there is significant contention. Fairness doesn't matter.
> Normally the only reason we'd get contention is userspace triggering
> access to multiple protocols at a time - probably via sysfs or other slow
> method.
> 4. Per protocol ordering can be maintained by the protocol, not the DOE layer.
> 5. DOE is basically a bus over which we are talking to different devices
> - think of it like I2C but rather than address we have protocol IDs.
>
> That last analogy brings us back to how I think almost all slow buses are
> handled.
>
> At level of a bus, a lock is used for mutual exclusion (often also protecting
> bus controller register state etc). No workqueues or similar complexity
> - Underlying hardware typically doing DMA of result into a provided buffer
> with only one transaction in flight at that layer at anyone time.
> Note there is more complex handling for high perf cases, but in many cases
> its not really used.
>
> We have a bus lock that can ensure exclusion over sequences if necessary
> (there's one in SPI).
>
> If a given driver needs to ensure exclusion for RMW or similar sequences
> of operations it takes a driver specific mutex and holds it across these
> sequences of slow operations, which usually sleep, include interrupts and all
> sorts of fun. Normally there is a completion in there somewhere to
> get from the 'done' interrupt on the bus controller back to the
> i2c_smbus_bus_read() etc that is waiting on the result.
>
> This model works, is super simple and layered.
>
> In case of no contention (perhaps 99% of time), it immediately runs the
> DOE/bus access in the thread that made the read/write request.
> So no overhead of going to a workqueue.
>
> Implementation is one linear function, no state machine needed.
Agree on this principle, once you have one linear function then it does not
matter if that function is under a mutex() or is run in an ordered
workqueue.
If the one linear function with a mutex ends up needing to invent its
own waitqueues and event completion notifications then maybe its better
to just use a workqueue than reinvent those wheels, but if push comes to
shove that's just a nice to have if we get to the one linear function
implementation.
> Anyhow, to refer back to my initial comment. I'm not that fussed on how
> we do this but it's a blocker on other work so quick solution is more
> important to me than perfect one.
Agree.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 5/8] cxl/port: Read CDAT table
2022-06-21 21:48 ` Dan Williams
@ 2022-06-28 3:24 ` Ira Weiny
0 siblings, 0 replies; 44+ messages in thread
From: Ira Weiny @ 2022-06-28 3:24 UTC (permalink / raw)
To: Dan Williams
Cc: Bjorn Helgaas, Jonathan Cameron, Alison Schofield, Vishal Verma,
Dave Jiang, Ben Widawsky, linux-kernel, linux-cxl, linux-pci
On Tue, Jun 21, 2022 at 02:48:11PM -0700, Dan Williams wrote:
> Ira Weiny wrote:
> > On Fri, Jun 17, 2022 at 05:43:34PM -0700, Dan Williams wrote:
> > > ira.weiny@ wrote:
> > > > From: Ira Weiny <ira.weiny@intel.com>
> > > >
> > >
[snip]
> > > Rather than a chatty / ephemeral error message I think this wants some
> > > indication in userspace, likely the 0-length CDAT binary attribute, so
> > > that userspace can debug why the kernel is picking sub-optimal QTG ids
> > > for newly provisioned CXL regions.
> >
> > I thought we agreed that 0-length or CDAT query failure would result in no
> > sysfs entry?
>
> Oh, I forgot about that, but some new rationale below...
>
> >
> > This message was to alert that a CDAT query was attempted but the read failed
> > vs finding no mailbox with CDAT capabilities for example.
>
> ...right, but that's an error message buried in the kernel log. I was
> hoping for something where tooling can query and say "oh, by the way,
> the driver tried and failed to get CDAT from this device that claimed to
> support CDAT, remedy that situation if you are seeing unexpected
> performance / behavior".
>
Ok I've added a flag which indicates if the device supported CDAT or not. If
so the sysfs will be visible but the data may be 0 length. Which means there
was some error in reading it.
> >
> > [snip]
> >
> > > >
> > > > +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_port *port = to_cxl_port(dev);
> > > > +
> > > > + if (!port->cdat.table)
> > > > + return 0;
> > > > +
> > > > + return memory_read_from_buffer(buf, count, &offset,
> > > > + port->cdat.table,
> > > > + port->cdat.length);
> > > > +}
> > > > +
> > > > +static BIN_ATTR_RO(cdat, 0);
> > >
> > > This should be BIN_ATTR_ADMIN_RO(), see:
> > >
> > > 3022c6a1b4b7 driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}
> >
> > Are you suggesting I add BIN_ATTR_ADMIN_* macros?
>
> Yes.
Done.
>
> >
> > >
> > > > +
> > > > +static umode_t cxl_port_bin_attr_is_visible(struct kobject *kobj,
> > > > + struct bin_attribute *attr, int i)
> > > > +{
> > > > + struct device *dev = kobj_to_dev(kobj);
> > > > + struct cxl_port *port = to_cxl_port(dev);
> > > > +
> > > > + if ((attr == &bin_attr_cdat) && port->cdat.table)
> > > > + return 0400;
> > >
> > > Per above change you only need to manage visibility and not permissions,
> >
> > But the permissions indicate visibility (In the kdoc for struct
> > attribute_group).
> >
> >
> > * ... Must
> > * return 0 if a binary attribute is not visible. The returned
> > * value will replace static permissions defined in
> > * struct bin_attribute.
> >
> > And the value returned overrides the mode.
> >
> > fs/sysfs/group.c:
> >
> > create_files()
> >
> > 82 if (grp->is_bin_visible) {
> > 83 mode = grp->is_bin_visible(kobj, *bin_attr, i);
> > 84 if (!mode)
> > 85 continue;
> > 86 }
> > 87
> > 88 WARN(mode & ~(SYSFS_PREALLOC | 0664),
> > 89 "Attribute %s: Invalid permissions 0%o\n",
> > 90 (*bin_attr)->attr.name, mode);
> > 91
> > 92 mode &= SYSFS_PREALLOC | 0664;
> >
> >
> > So I'm willing to add the macro but I'm not sure it is going to change anything
> > in this case.
>
> The change I was expecting is that with BIN_ATTR_ADMIN_RO() this
> implementation changes from:
>
> if ((attr == &bin_attr_cdat) && port->cdat.table)
> return 0400;
>
> ...to:
>
> if ((attr == &bin_attr_cdat) && port->cdat.table)
> return attr->mode;
>
> ...i.e. this routine only modifies visibility, you do not also need it
> to enforce the root-read-only permission change since that's already
> statically defined at attribute creation time.
Ok.
>
> > I think to make those _ADMIN_ macros work with is_visible()
> > create_files() needs to be changed. :-/ I'm not sure if the addition of
> > DEVICE_ATTR_ADMIN_{RO,RW} intended for is_visible() to be able to override the
> > mode?
>
> The intent was that one only needs to look in one place to read the
> permission, and is_visible() is (mostly*) only left to change the mode to
> 0.
>
> * changes from read-only to/from writable would still need is_visble()
> to manipulate permissions, but you get the idea.
Yep, done.
Ira
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH V11 7/8] cxl/port: Retry reading CDAT on failure
2022-06-10 20:22 ` [PATCH V11 7/8] cxl/port: Retry reading CDAT on failure ira.weiny
@ 2022-06-28 3:32 ` Alison Schofield
0 siblings, 0 replies; 44+ messages in thread
From: Alison Schofield @ 2022-06-28 3:32 UTC (permalink / raw)
To: Weiny, Ira
Cc: Williams, Dan J, Bjorn Helgaas, Jonathan Cameron, Ben Widawsky,
Verma, Vishal L, Jiang, Dave, linux-kernel, linux-cxl, linux-pci
On Fri, Jun 10, 2022 at 01:22:58PM -0700, Ira Weiny wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> The CDAT read may fail for a number of reasons but mainly it is possible
> to get different parts of a valid state. The checksum in the CDAT table
> protects against this.
>
> Now that the cdat data is validated, issue a retry if the CDAT read
> fails. For now 5 retries are implemented.
>
> Reviewed-by: Ben Widawsky <bwidawsk@kernel.org>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
> ---
> Changes from V10
> Pick up review tag and fix commit message
>
> Changes from V9
> Alison Schofield/Davidlohr Bueso
> Print debug on each iteration and error only after failure
>
> Changes from V8
> Move code to cxl/core/pci.c
>
> Changes from V6
> Move to pci.c
> Fix retries count
> Change to 5 retries
>
> Changes from V5:
> New patch -- easy to push off or drop.
> ---
> drivers/cxl/core/pci.c | 40 +++++++++++++++++++++++++++++++---------
> 1 file changed, 31 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
> index cb70287e2984..fd02bc7c0d97 100644
> --- a/drivers/cxl/core/pci.c
> +++ b/drivers/cxl/core/pci.c
> @@ -617,19 +617,13 @@ static int cxl_cdat_read_table(struct device *dev,
> return rc;
> }
>
> -/**
> - * read_cdat_data - Read the CDAT data on this port
> - * @port: Port to read data from
> - *
> - * This call will sleep waiting for responses from the DOE mailbox.
> - */
> -void read_cdat_data(struct cxl_port *port)
> +static int __read_cdat_data(struct cxl_port *port)
> {
> static struct pci_doe_mb *cdat_mb;
> struct device *dev = &port->dev;
> struct device *uport = port->uport;
> size_t cdat_length;
> - int ret;
> + int ret = 0;
>
> /*
> * Ensure a reference on the underlying uport device which has the
> @@ -640,17 +634,21 @@ void read_cdat_data(struct cxl_port *port)
> cdat_mb = find_cdat_mb(uport);
> if (!cdat_mb) {
> dev_dbg(dev, "No CDAT mailbox\n");
> + ret = -EIO;
> goto out;
> }
>
> if (cxl_cdat_get_length(dev, cdat_mb, &cdat_length)) {
> dev_dbg(dev, "No CDAT length\n");
> + ret = -EIO;
> goto out;
> }
>
> port->cdat.table = devm_kzalloc(dev, cdat_length, GFP_KERNEL);
> - if (!port->cdat.table)
> + if (!port->cdat.table) {
> + ret = -ENOMEM;
> goto out;
> + }
>
> port->cdat.length = cdat_length;
> ret = cxl_cdat_read_table(dev, cdat_mb, &port->cdat);
> @@ -664,5 +662,29 @@ void read_cdat_data(struct cxl_port *port)
>
> out:
> put_device(uport);
> + return ret;
> +}
> +
> +/**
> + * read_cdat_data - Read the CDAT data on this port
> + * @port: Port to read data from
> + *
> + * This call will sleep waiting for responses from the DOE mailbox.
> + */
> +void read_cdat_data(struct cxl_port *port)
> +{
> + int retries = 5;
> + int rc;
> +
> + while (retries--) {
> + rc = __read_cdat_data(port);
> + if (!rc)
> + return;
> + dev_dbg(&port->dev,
> + "CDAT data read error rc=%d (retries %d)\n",
> + rc, retries);
> + }
> + dev_err(&port->dev, "CDAT data read failed after %d retries\n",
> + retries);
> }
> EXPORT_SYMBOL_NS_GPL(read_cdat_data, CXL);
> --
> 2.35.1
>
^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2022-06-28 3:33 UTC | newest]
Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-10 20:22 [PATCH V11 0/8] CXL: Read CDAT and DSMAS data ira.weiny
2022-06-10 20:22 ` [PATCH V11 1/8] PCI: Add vendor ID for the PCI SIG ira.weiny
2022-06-10 20:22 ` [PATCH V11 2/8] PCI: Replace magic constant for PCI Sig Vendor ID ira.weiny
2022-06-10 20:22 ` [PATCH V11 3/8] PCI: Create PCI library functions in support of DOE mailboxes ira.weiny
2022-06-14 3:53 ` Li, Ming
2022-06-15 4:18 ` Ira Weiny
2022-06-17 22:40 ` Bjorn Helgaas
2022-06-18 16:39 ` Bjorn Helgaas
2022-06-22 16:46 ` Ira Weiny
2022-06-20 9:24 ` Jonathan Cameron
2022-06-22 23:06 ` Ira Weiny
2022-06-22 16:38 ` Ira Weiny
2022-06-17 22:56 ` Dan Williams
2022-06-20 10:23 ` Jonathan Cameron
2022-06-22 22:57 ` Ira Weiny
2022-06-23 18:03 ` Dan Williams
2022-06-22 22:37 ` Ira Weiny
2022-06-22 22:45 ` Ira Weiny
2022-06-22 22:57 ` Dan Williams
2022-06-23 0:25 ` Ira Weiny
2022-06-23 10:24 ` Jonathan Cameron
2022-06-23 18:14 ` Dan Williams
2022-06-23 18:07 ` Dan Williams
2022-06-10 20:22 ` [PATCH V11 4/8] cxl/pci: Create PCI DOE mailbox's for memory devices ira.weiny
2022-06-17 20:40 ` [PATCH v11 " Davidlohr Bueso
2022-06-17 20:51 ` Davidlohr Bueso
2022-06-21 18:24 ` Ira Weiny
2022-06-17 23:44 ` [PATCH V11 " Dan Williams
2022-06-21 18:29 ` Ira Weiny
2022-06-22 23:18 ` Ira Weiny
2022-06-21 20:37 ` Bjorn Helgaas
2022-06-10 20:22 ` [PATCH V11 5/8] cxl/port: Read CDAT table ira.weiny
2022-06-18 0:43 ` Dan Williams
2022-06-21 19:10 ` Dan Williams
2022-06-21 19:34 ` Lukas Wunner
2022-06-21 19:41 ` Dan Williams
2022-06-21 20:38 ` Ira Weiny
2022-06-21 21:14 ` Ira Weiny
2022-06-21 21:48 ` Dan Williams
2022-06-28 3:24 ` Ira Weiny
2022-06-10 20:22 ` [PATCH V11 6/8] cxl/port: Introduce cxl_cdat_valid() ira.weiny
2022-06-10 20:22 ` [PATCH V11 7/8] cxl/port: Retry reading CDAT on failure ira.weiny
2022-06-28 3:32 ` Alison Schofield
2022-06-10 20:22 ` [PATCH V11 8/8] cxl/port: Parse out DSMAS data from CDAT table ira.weiny
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).