| Message ID | 20210419165451.2176200-3-Jonathan.Cameron@huawei.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | PCI Data Object Exchange support + CXL CDAT | expand |
On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote: > + > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex) > +{ > + struct pci_dev *pdev = doe->pdev; > + u32 val; > + int i; > + > + /* > + * Check the DOE busy bit is not set. If it is set, this could indicate > + * someone other than Linux (e.g. firmware) is using the mailbox. Note > + * it is expected that firmware and OS will negotiate access rights via > + * an, as yet to be defined method. > + */ > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); > + if (FIELD_GET(PCI_DOE_STATUS_BUSY, val)) > + return -EBUSY; In discussion with Dan we believe that user space could also be issuing commands and would potentially cause us to be locked out. We agree that firmware should be out of the way here and if it is blocking the OS there is not much we can do about it. However, if user space is using the mailbox we need to synchronize with them via pci_cfg_access_[try]lock(). This should avoid this EBUSY condition. [snip] > + > +static int pci_doe_recv_resp(struct pci_doe *doe, struct pci_doe_exchange *ex) > +{ > + struct pci_dev *pdev = doe->pdev; > + size_t length; > + u32 val; > + int i; > + > + /* Read the first two dwords to get the length and protocol */ > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val); > + if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != ex->vid) || > + (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != ex->protocol)) { > + pci_err(pdev, > + "Expected [VID, Protocol] = [%x, %x], got [%x, %x]\n", > + ex->vid, ex->protocol, > + FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val), > + FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val)); > + return -EIO; > + } > + > + pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0); I'm quite unfamiliar with the spec here: but it seems like this needs to be done before the above if statement indicate we got the value? [snip] > + > +static void doe_statemachine_work(struct work_struct *work) > +{ > + struct delayed_work *w = to_delayed_work(work); > + struct pci_doe *doe = container_of(w, struct pci_doe, statemachine); > + struct pci_dev *pdev = doe->pdev; > + struct pci_doe_task *task; > + bool abort; > + u32 val; > + int rc; > + > + mutex_lock(&doe->tasks_lock); > + task = list_first_entry_or_null(&doe->tasks, struct pci_doe_task, h); > + abort = doe->abort; > + doe->abort = false; > + mutex_unlock(&doe->tasks_lock); > + > + if (abort) { > + /* > + * Currently only used during init - care needed if we want to > + * generally expose pci_doe_abort() as it would impact queries > + * in flight. > + */ > + WARN_ON(task); > + doe->state = DOE_WAIT_ABORT; > + pci_doe_abort_start(doe); > + return; > + } > + > + switch (doe->state) { > + case DOE_IDLE: > + if (task == NULL) > + return; > + > + /* Nothing currently in flight so queue a task */ > + rc = pci_doe_send_req(doe, task->ex); > + /* > + * The specification does not provide any guidance on how long > + * some other entity could keep the DOE busy, so try for 1 > + * second then fail. Busy handling is best effort only, because > + * there is no way of avoiding racing against another user of > + * the DOE. > + */ > + if (rc == -EBUSY) { > + doe->busy_retries++; > + if (doe->busy_retries == PCI_DOE_BUSY_MAX_RETRIES) { > + /* Long enough, fail this request */ > + doe->busy_retries = 0; > + goto err_busy; With the addition of pci_cfg_access_[try]lock(): Should we have some sort of WARN_ON() here to indicate that the system is behaving badly? [snip] > + case DOE_WAIT_ABORT: > + case DOE_WAIT_ABORT_ON_ERR: > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); > + > + if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) && > + !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) { > + /* Back to normal state - carry on */ > + mutex_lock(&doe->tasks_lock); > + if (!list_empty(&doe->tasks)) > + schedule_delayed_work(w, 0); > + mutex_unlock(&doe->tasks_lock); > + > + /* > + * For deliberately triggered abort, someone is > + * waiting. > + */ > + if (doe->state == DOE_WAIT_ABORT) > + complete(&doe->abort_c); > + doe->state = DOE_IDLE; > + > + return; > + } > + if (time_after(jiffies, doe->timeout_jiffies)) { > + struct pci_doe_task *t, *n; > + > + /* We are dead - abort all queued tasks */ > + pci_err(pdev, "DOE ABORT timed out\n"); > + mutex_lock(&doe->tasks_lock); > + doe->dead = true; > + list_for_each_entry_safe(t, n, &doe->tasks, h) { > + t->rv = -EIO; > + t->cb(t->private); > + list_del(&t->h); > + } > + > + mutex_unlock(&doe->tasks_lock); > + if (doe->state == DOE_WAIT_ABORT) > + complete(&doe->abort_c); > + } > + return; > + } > + > +err_abort: > + pci_doe_abort_start(doe); > + doe->state = DOE_WAIT_ABORT_ON_ERR; Should this be before pci_doe_abort_start() to ensure that state is set when the statemachine runs? [snip] > + > +/** > + * struct pci_doe - State to support use of DOE mailbox > + * @cap: Config space offset to base of DOE capability. > + * @pdev: PCI device that hosts this DOE. > + * @abort_c: Completion used for initial abort handling. > + * @irq: Interrupt used for signaling DOE ready or abort. > + * @prots: Cache of identifiers for protocols supported. > + * @num_prots: Size of prots cache. > + * @h: Used for DOE instance lifetime management. > + * @wq: Workqueue used to handle state machine and polling / timeouts. > + * @tasks: List of task in flight + pending. > + * @tasks_lock: Protect the tasks list. This protects more than just the task list. It appears to protect abort and dead as well. I'm not sure if it is worth mentioning but... > + * @statemachine: Work item for the DOE state machine. > + * @state: Current state of this DOE. > + * @timeout_jiffies: 1 second after GO set. > + * @busy_retries: Count of retry attempts. > + * @abort: Request a manual abort (e.g. on init). > + * @dead: Used to mark a DOE for which an ABORT has timed out. Further messages > + * will immediately be aborted with error. > + */ > +struct pci_doe { > + int cap; > + struct pci_dev *pdev; > + struct completion abort_c; > + int irq; > + struct pci_doe_prot *prots; > + int num_prots; > + struct list_head h; > + > + struct workqueue_struct *wq; > + struct list_head tasks; > + struct mutex tasks_lock; > + struct delayed_work statemachine; > + enum pci_doe_state state; > + unsigned long timeout_jiffies; > + unsigned int busy_retries; > + unsigned int abort:1; > + unsigned int dead:1; > +}; [snip] Ira
On Tue, 20 Apr 2021 00:54:49 +0800 Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > Introduced in a PCI ECN [1], DOE provides a config space > based mailbox with standard protocol discovery. Each mailbox > is accessed through a DOE Extended Capability. > > A device may have 1 or more DOE mailboxes, each of which is allowed > to support any number of protocols (some DOE protocol > specifications apply additional restrictions). A given protocol > may be supported on more than one DOE mailbox on a given function. > > If a driver wishes to access any number of DOE instances / protocols > it makes a single call to pcie_doe_register_all() which will find > available DOEs, create the required infrastructure and cache the > protocols they support. pcie_doe_find() can then retrieve a > pointer to an appropriate DOE instance. > > A synchronous interface is provided in pcie_doe_exchange_sync() to > perform a single query / response exchange. > > Testing conducted against QEMU using: > > https://lore.kernel.org/qemu-devel/1612900760-7361-1-git-send-email-cbrowy@avery-design.com/ > + fix for interrupt flag mentioned in that thread and a whole load > of hacks to exercise error paths etc. > > [1] https://members.pcisig.com/wg/PCI-SIG/document/14143 > Data Object Exchange (DOE) - Approved 12 March 2020 > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > --- ... > +static int pci_doe_recv_resp(struct pci_doe *doe, struct pci_doe_exchange *ex) > +{ > + struct pci_dev *pdev = doe->pdev; > + size_t length; > + u32 val; > + int i; > + > + /* Read the first two dwords to get the length and protocol */ > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val); > + if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != ex->vid) || > + (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != ex->protocol)) { > + pci_err(pdev, > + "Expected [VID, Protocol] = [%x, %x], got [%x, %x]\n", > + ex->vid, ex->protocol, > + FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val), > + FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val)); > + return -EIO; > + } > + > + pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0); > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val); > + pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0); > + > + length = FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH, val); > + if (length > SZ_1M) > + return -EIO; > + > + /* Read the rest of the response payload */ > + for (i = 0; i < min(length, ex->response_pl_sz / sizeof(u32)); i++) { Note for anyone testing these that there is a bug here which leads to a buffer underflow triggered reset with the latest QEMU patches (I've not figured out yet why this didn't trigger a problem with the earlier QEMU patch versions). This needs to take into account that length includes the two header DW, but the response_pl_sz does not. > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, > + &ex->response_pl[i]); > + pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0); > + } > + > + /* Flush excess length */ > + for (; i < length; i++) { > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val); > + pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0); > + } > + /* Final error check to pick up on any since Data Object Ready */ > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); > + if (FIELD_GET(PCI_DOE_STATUS_ERROR, val)) > + return -EIO; > + > + return min(length, ex->response_pl_sz / sizeof(u32)) * sizeof(u32); > +} > +
s/doe/DOE/ in subject. On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote: > Introduced in a PCI ECN [1], DOE provides a config space > based mailbox with standard protocol discovery. Each mailbox > is accessed through a DOE Extended Capability. > > A device may have 1 or more DOE mailboxes, each of which is allowed > to support any number of protocols (some DOE protocol > specifications apply additional restrictions). A given protocol > may be supported on more than one DOE mailbox on a given function. > > If a driver wishes to access any number of DOE instances / protocols > it makes a single call to pcie_doe_register_all() which will find > available DOEs, create the required infrastructure and cache the > protocols they support. pcie_doe_find() can then retrieve a > pointer to an appropriate DOE instance. > > A synchronous interface is provided in pcie_doe_exchange_sync() to > perform a single query / response exchange. Re-wrap above (and commit logs of other patches) to fill 75 columns. s/pcie_doe_register_all/pci_doe_register_all/ s/pcie_doe_find/pci_doe_find/ s/pcie_doe_exchange_sync/pci_doe_exchange_sync/ > +config PCI_DOE > + bool > + help > + This enables library support for the PCI Data Object Exchange > + capability. DOE provides a simple mailbox in PCI config space that is > + used by a number of different protocols. > + DOE is defined in the Data Object Exchange ECN to PCI 5.0. "ECN to the PCIe r5.0 spec." "PCI 5.0" sounds like a conventional PCI spec. > + * pci_doe_exchange_sync() - Send a request, then wait for and receive response. > + * @doe: DOE mailbox state structure. > + * @ex: Description of the buffers and Vendor ID + type used in this > + * request/response pair, s/,/./ (Or omit the periods altogether on these function and parameter one-liners, as most of drivers/pci does. Most of these descriptions aren't sentences anyway, I think it's fine that they're unterminated.) > +static void pci_doe_init(struct pci_doe *doe, struct pci_dev *pdev, int doe_offset) Indent to fit in 80 columns like the rest of drivers/pci/. > +static int pci_doe_register(struct pci_doe *doe) > +{ > + struct pci_dev *pdev = doe->pdev; > + bool poll = !pci_dev_msi_enabled(pdev); > + int rc, irq; > + u32 val; > + > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_CAP, &val); > + > + if (!poll && FIELD_GET(PCI_DOE_CAP_INT, val)) { > + irq = pci_irq_vector(pdev, FIELD_GET(PCI_DOE_CAP_IRQ, val)); > + if (irq < 0) > + return irq; > + > + rc = request_irq(irq, pci_doe_irq, 0, "DOE", doe); I expect there may be many devices with DOE. Do you want some device identification here? E.g., on my system I see things like this in /proc/interrupts: dmar0 nvme0q0 snd_hda_intel:card0 ahci[0000:00:17.0] > +++ b/include/linux/pci-doe.h > @@ -0,0 +1,85 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Data Object Exchange was added to the PCI spec as an ECN to 5.0. "... was added as an ECN to the PCIe r5.0 spec."
On Thu, 6 May 2021 14:59:34 -0700 Ira Weiny <ira.weiny@intel.com> wrote: > On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote: > > + > > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex) > > +{ > > + struct pci_dev *pdev = doe->pdev; > > + u32 val; > > + int i; > > + > > + /* > > + * Check the DOE busy bit is not set. If it is set, this could indicate > > + * someone other than Linux (e.g. firmware) is using the mailbox. Note > > + * it is expected that firmware and OS will negotiate access rights via > > + * an, as yet to be defined method. > > + */ > > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); > > + if (FIELD_GET(PCI_DOE_STATUS_BUSY, val)) > > + return -EBUSY; > > In discussion with Dan we believe that user space could also be issuing > commands and would potentially cause us to be locked out. > > We agree that firmware should be out of the way here and if it is blocking > the OS there is not much we can do about it. > > However, if user space is using the mailbox we need to synchronize with them > via pci_cfg_access_[try]lock(). This should avoid this EBUSY condition. Hi Ira, thanks for taking a look. So the question here is whether we can ever safely work with a userspace that is accessing the DOE. I think the answer is no we can't. We'd have no way of knowing that userspace left the DOE in a clean state without resetting every time we want to use it (which can take 1 second) or doing significant sanity checking (can we tell if something is in flight?). Note that if userspace and kernel were talking different protocols nothing sensible could be done to prevent them receiving each other's answers (unless you can rely on userspace holding the lock until it is done - which you can't as who trusts userspace?) You could do something horrible like back off after peeking at the protocol to see if it might be yours, but even that only works assuming the two are trying to talk different protocols (talking the same protocol isn't allowed but no way to enforce that using just pci_cfg_access_lock()). I can't see a way to tell that the DOE might not have responded to an earlier request. DOE busy indicates the write mailbox register cannot receive data at the moment. If it's set then there is a message in flight, but if it is not set there might still be a message in flight. Busy only indicates if the write mailbox register can sink a request which doesn't in general tell us anything about the underlying state. So if userspace sent a request then quit. Kernel driver would have no way of knowing if the next response was due to the request it sent or some earlier one (other than matching IDs) Note you aren't allowed to have multiple requests for a single protocol in flight at the same time. With just a lock you would have no way of preventing this. So we are back to every request the kernel sent having to be proceeded by an abort and potentially a 1 second delay whilst some chunk of the device firmware reboots. This came up in dicussion when Dan proposed the patch [PATCH] PCI: Allow drivers to claim exclusive access to config regions https://lore.kernel.org/linux-pci/161663543465.1867664.5674061943008380442.stgit@dwillia2-desk3.amr.corp.intel.com/ Summarizing outcome of that thread. 1) Reads of DOE registers are always safe, so we shouldn't stop lspci and similar accessing config space. 2) You are on your own if any userspace writes to pci config space. There are loads of ways it can break the system so it doesn't make much sense to protect against one more. If there is a reason to provide a userspace interface to a DOE for a device with a driver attached, then I would agree with Dan's suggestion to use a proper driver for it. Dan briefly mentioned that temporary blocking might be needed. I'm guessing that was to try and let userspace safely use the DOE. The driver would work fine ignoring busy entirely and would perhaps be less confusing as a result. We reset the DOE at startup anyway and that would clear existing busy. Any future times busy is set would have no impact on the flow. > > [snip] > > > + > > +static int pci_doe_recv_resp(struct pci_doe *doe, struct pci_doe_exchange *ex) > > +{ > > + struct pci_dev *pdev = doe->pdev; > > + size_t length; > > + u32 val; > > + int i; > > + > > + /* Read the first two dwords to get the length and protocol */ > > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val); > > + if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != ex->vid) || > > + (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != ex->protocol)) { > > + pci_err(pdev, > > + "Expected [VID, Protocol] = [%x, %x], got [%x, %x]\n", > > + ex->vid, ex->protocol, > > + FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val), > > + FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val)); > > + return -EIO; > > + } > > + > > + pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0); > > I'm quite unfamiliar with the spec here: but it seems like this needs to be > done before the above if statement indicate we got the value? Perhaps it's the comment that caused confusion here. It covered the next few lines as well. You need to read the first DW to get protocol (and write it to be able to read the next one back) The second dw is then need to get to the length which follows this. I'll split the comment into two parts so that it's clearer what it is referring to. On any error here, we end up calling a abort anyway so state on error paths of the DOE doesn't matter. > > [snip] > > > + > > +static void doe_statemachine_work(struct work_struct *work) > > +{ > > + struct delayed_work *w = to_delayed_work(work); > > + struct pci_doe *doe = container_of(w, struct pci_doe, statemachine); > > + struct pci_dev *pdev = doe->pdev; > > + struct pci_doe_task *task; > > + bool abort; > > + u32 val; > > + int rc; > > + > > + mutex_lock(&doe->tasks_lock); > > + task = list_first_entry_or_null(&doe->tasks, struct pci_doe_task, h); > > + abort = doe->abort; > > + doe->abort = false; > > + mutex_unlock(&doe->tasks_lock); > > + > > + if (abort) { > > + /* > > + * Currently only used during init - care needed if we want to > > + * generally expose pci_doe_abort() as it would impact queries > > + * in flight. > > + */ > > + WARN_ON(task); > > + doe->state = DOE_WAIT_ABORT; > > + pci_doe_abort_start(doe); > > + return; > > + } > > + > > + switch (doe->state) { > > + case DOE_IDLE: > > + if (task == NULL) > > + return; > > + > > + /* Nothing currently in flight so queue a task */ > > + rc = pci_doe_send_req(doe, task->ex); > > + /* > > + * The specification does not provide any guidance on how long > > + * some other entity could keep the DOE busy, so try for 1 > > + * second then fail. Busy handling is best effort only, because > > + * there is no way of avoiding racing against another user of > > + * the DOE. > > + */ > > + if (rc == -EBUSY) { > > + doe->busy_retries++; > > + if (doe->busy_retries == PCI_DOE_BUSY_MAX_RETRIES) { > > + /* Long enough, fail this request */ > > + doe->busy_retries = 0; > > + goto err_busy; > > With the addition of pci_cfg_access_[try]lock(): > > Should we have some sort of WARN_ON() here to indicate that the system is > behaving badly? Makes sense. I'll add a pci_WARN() here > > [snip] > > > + case DOE_WAIT_ABORT: > > + case DOE_WAIT_ABORT_ON_ERR: > > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); > > + > > + if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) && > > + !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) { > > + /* Back to normal state - carry on */ > > + mutex_lock(&doe->tasks_lock); > > + if (!list_empty(&doe->tasks)) > > + schedule_delayed_work(w, 0); > > + mutex_unlock(&doe->tasks_lock); > > + > > + /* > > + * For deliberately triggered abort, someone is > > + * waiting. > > + */ > > + if (doe->state == DOE_WAIT_ABORT) > > + complete(&doe->abort_c); > > + doe->state = DOE_IDLE; > > + > > + return; > > + } > > + if (time_after(jiffies, doe->timeout_jiffies)) { > > + struct pci_doe_task *t, *n; > > + > > + /* We are dead - abort all queued tasks */ > > + pci_err(pdev, "DOE ABORT timed out\n"); > > + mutex_lock(&doe->tasks_lock); > > + doe->dead = true; > > + list_for_each_entry_safe(t, n, &doe->tasks, h) { > > + t->rv = -EIO; > > + t->cb(t->private); > > + list_del(&t->h); > > + } > > + > > + mutex_unlock(&doe->tasks_lock); > > + if (doe->state == DOE_WAIT_ABORT) > > + complete(&doe->abort_c); > > + } > > + return; > > + } > > + > > +err_abort: > > + pci_doe_abort_start(doe); > > + doe->state = DOE_WAIT_ABORT_ON_ERR; > > Should this be before pci_doe_abort_start() to ensure that state is set when > the statemachine runs? Don't think it's a bug (single work item) but it's definitely clearer the other way around. > > [snip] > > > + > > +/** > > + * struct pci_doe - State to support use of DOE mailbox > > + * @cap: Config space offset to base of DOE capability. > > + * @pdev: PCI device that hosts this DOE. > > + * @abort_c: Completion used for initial abort handling. > > + * @irq: Interrupt used for signaling DOE ready or abort. > > + * @prots: Cache of identifiers for protocols supported. > > + * @num_prots: Size of prots cache. > > + * @h: Used for DOE instance lifetime management. > > + * @wq: Workqueue used to handle state machine and polling / timeouts. > > + * @tasks: List of task in flight + pending. > > + * @tasks_lock: Protect the tasks list. > > This protects more than just the task list. It appears to protect abort and > dead as well. I'm not sure if it is worth mentioning but... Added 'abort state' to that comment. > > > + * @statemachine: Work item for the DOE state machine. > > + * @state: Current state of this DOE. > > + * @timeout_jiffies: 1 second after GO set. > > + * @busy_retries: Count of retry attempts. > > + * @abort: Request a manual abort (e.g. on init). > > + * @dead: Used to mark a DOE for which an ABORT has timed out. Further messages > > + * will immediately be aborted with error. > > + */ > > +struct pci_doe { > > + int cap; > > + struct pci_dev *pdev; > > + struct completion abort_c; > > + int irq; > > + struct pci_doe_prot *prots; > > + int num_prots; > > + struct list_head h; > > + > > + struct workqueue_struct *wq; > > + struct list_head tasks; > > + struct mutex tasks_lock; > > + struct delayed_work statemachine; > > + enum pci_doe_state state; > > + unsigned long timeout_jiffies; > > + unsigned int busy_retries; > > + unsigned int abort:1; > > + unsigned int dead:1; > > +}; > > [snip] > > Ira > Thanks! Jonathan
On Fri, 7 May 2021 18:10:13 -0500 Bjorn Helgaas <helgaas@kernel.org> wrote: Thanks. All updates as per your comments. > > +static int pci_doe_register(struct pci_doe *doe) > > +{ > > + struct pci_dev *pdev = doe->pdev; > > + bool poll = !pci_dev_msi_enabled(pdev); > > + int rc, irq; > > + u32 val; > > + > > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_CAP, &val); > > + > > + if (!poll && FIELD_GET(PCI_DOE_CAP_INT, val)) { > > + irq = pci_irq_vector(pdev, FIELD_GET(PCI_DOE_CAP_IRQ, val)); > > + if (irq < 0) > > + return irq; > > + > > + rc = request_irq(irq, pci_doe_irq, 0, "DOE", doe); > > I expect there may be many devices with DOE. Do you want some > device identification here? E.g., on my system I see things like this > in /proc/interrupts: > > dmar0 > nvme0q0 > snd_hda_intel:card0 > ahci[0000:00:17.0] Good point. For this I've currently gone with DOE[0000:00:81.0]_160 DOE[0000:00:81.0]_190 etc as a single function can have multiple DOE instances and the easiest way to distinguish them is the offset at which the capability is found in config space of the device. I'm open to other suggestions. Jonathan
On Tue, May 11, 2021 at 9:52 AM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > > On Thu, 6 May 2021 14:59:34 -0700 > Ira Weiny <ira.weiny@intel.com> wrote: > > > On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote: > > > + > > > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex) > > > +{ > > > + struct pci_dev *pdev = doe->pdev; > > > + u32 val; > > > + int i; > > > + > > > + /* > > > + * Check the DOE busy bit is not set. If it is set, this could indicate > > > + * someone other than Linux (e.g. firmware) is using the mailbox. Note > > > + * it is expected that firmware and OS will negotiate access rights via > > > + * an, as yet to be defined method. > > > + */ > > > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); > > > + if (FIELD_GET(PCI_DOE_STATUS_BUSY, val)) > > > + return -EBUSY; > > > > In discussion with Dan we believe that user space could also be issuing > > commands and would potentially cause us to be locked out. > > > > We agree that firmware should be out of the way here and if it is blocking > > the OS there is not much we can do about it. > > > > However, if user space is using the mailbox we need to synchronize with them > > via pci_cfg_access_[try]lock(). This should avoid this EBUSY condition. > > Hi Ira, thanks for taking a look. > > So the question here is whether we can ever safely work with a > userspace that is accessing the DOE. I think the answer is no we can't. > > We'd have no way of knowing that userspace left the DOE in a clean state > without resetting every time we want to use it (which can take 1 second) > or doing significant sanity checking (can we tell if something is > in flight?). Note that if userspace and kernel were talking different > protocols nothing sensible could be done to prevent them receiving each > other's answers (unless you can rely on userspace holding the lock until > it is done - which you can't as who trusts userspace?) There is no ability for userpsace to lock out the kernel, only kernel locking out userspace. > You could do > something horrible like back off after peeking at the protocol to see > if it might be yours, but even that only works assuming the two are > trying to talk different protocols (talking the same protocol isn't allowed > but no way to enforce that using just pci_cfg_access_lock()). Wait why isn't pci_cfg_access_lock() sufficient? The userspace DOE transfer is halted, the kernel validates the state of DOE, does it's work and releases the lock. > I can't see a way to tell that the DOE might not have responded to an > earlier request. DOE busy indicates the write mailbox register cannot > receive data at the moment. If it's set then there is a message in > flight, but if it is not set there might still be a message in flight. > Busy only indicates if the write mailbox register can sink a request > which doesn't in general tell us anything about the underlying state. > > So if userspace sent a request then quit. Kernel driver would have > no way of knowing if the next response was due to the request it sent > or some earlier one (other than matching IDs) Note you aren't allowed > to have multiple requests for a single protocol in flight at the same > time. With just a lock you would have no way of preventing this. > > So we are back to every request the kernel sent having to be proceeded > by an abort and potentially a 1 second delay whilst some chunk of the > device firmware reboots. > > This came up in dicussion when Dan proposed the patch > [PATCH] PCI: Allow drivers to claim exclusive access to config regions > https://lore.kernel.org/linux-pci/161663543465.1867664.5674061943008380442.stgit@dwillia2-desk3.amr.corp.intel.com/ > Summarizing outcome of that thread. > > 1) Reads of DOE registers are always safe, so we shouldn't stop lspci > and similar accessing config space. > 2) You are on your own if any userspace writes to pci config space. > There are loads of ways it can break the system so it doesn't make much > sense to protect against one more. I'm not quite as enthusiastic about Greg's assertion that "we're already broken why not allow more breakage" as he was also the one supportive of /dev/mem restrictions in the face of obvious collisions. I'll circle back and say as much to Greg. My mistake was not realizing the write dependency in the protocol, so the pushback was warranted that the kernel does not need to block out all access. Given that /dev/mem is optionally disabled for userspace access outside of kernel-lockdown scenarios, I think it is reasonable to have the kernel disable config writes to a register block and the request of a driver. Consider that userspace can certainly trash the system by writing to the BAR registers, for example, but a non-malicious userspace has no reason to do that. Unfortunately DOE has some utility for a non-malicious userspace to access so there is a rationale to figure out a cooperation scheme. > > If there is a reason to provide a userspace interface to a DOE for a > device with a driver attached, then I would agree with Dan's suggestion > to use a proper driver for it. > > Dan briefly mentioned that temporary blocking might be needed. I'm guessing > that was to try and let userspace safely use the DOE. > > The driver would work fine ignoring busy entirely and would perhaps be > less confusing as a result. We reset the DOE at startup anyway and that > would clear existing busy. Any future times busy is set would have no > impact on the flow. If it simplifies the kernel implementation to assume single kernel-initiator then I think that's more than enough reason to block out userspace, and/or provide userspace a method to get into the kernel's queue for service.
On Thu, 13 May 2021 14:20:38 -0700 Dan Williams <dan.j.williams@intel.com> wrote: > On Tue, May 11, 2021 at 9:52 AM Jonathan Cameron > <Jonathan.Cameron@huawei.com> wrote: > > > > On Thu, 6 May 2021 14:59:34 -0700 > > Ira Weiny <ira.weiny@intel.com> wrote: > > > > > On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote: > > > > + > > > > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex) > > > > +{ > > > > + struct pci_dev *pdev = doe->pdev; > > > > + u32 val; > > > > + int i; > > > > + > > > > + /* > > > > + * Check the DOE busy bit is not set. If it is set, this could indicate > > > > + * someone other than Linux (e.g. firmware) is using the mailbox. Note > > > > + * it is expected that firmware and OS will negotiate access rights via > > > > + * an, as yet to be defined method. > > > > + */ > > > > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); > > > > + if (FIELD_GET(PCI_DOE_STATUS_BUSY, val)) > > > > + return -EBUSY; > > > > > > In discussion with Dan we believe that user space could also be issuing > > > commands and would potentially cause us to be locked out. > > > > > > We agree that firmware should be out of the way here and if it is blocking > > > the OS there is not much we can do about it. > > > > > > However, if user space is using the mailbox we need to synchronize with them > > > via pci_cfg_access_[try]lock(). This should avoid this EBUSY condition. > > > > Hi Ira, thanks for taking a look. > > > > So the question here is whether we can ever safely work with a > > userspace that is accessing the DOE. I think the answer is no we can't. > > > > We'd have no way of knowing that userspace left the DOE in a clean state > > without resetting every time we want to use it (which can take 1 second) > > or doing significant sanity checking (can we tell if something is > > in flight?). Note that if userspace and kernel were talking different > > protocols nothing sensible could be done to prevent them receiving each > > other's answers (unless you can rely on userspace holding the lock until > > it is done - which you can't as who trusts userspace?) > > There is no ability for userpsace to lock out the kernel, only kernel > locking out userspace. Hi Dan, Got it. Writing userspace to code with arbitrary kernel breakage of exchanges userspace initialized is going to be nasty. > > > You could do > > something horrible like back off after peeking at the protocol to see > > if it might be yours, but even that only works assuming the two are > > trying to talk different protocols (talking the same protocol isn't allowed > > but no way to enforce that using just pci_cfg_access_lock()). > > Wait why isn't pci_cfg_access_lock() sufficient? The userspace DOE > transfer is halted, the kernel validates the state of DOE, does it's > work and releases the lock. It's that 'validate the state of the DOE' which is the problem. I 'think' the only way to do that is to issue an abort every time and I'm really not liking the fact that adds a potential 1 second sleep to every DOE access from the kernel. There is no other way of knowing there is no exchange already in flight that might come back and bite you even after you think you have a clean state + I think you might be able to construct cases where even inspecting the data isn't enough to tell. If we are safe with today's protocols, there is no guarantee we will be in future. If the DOE design had incorporated such a flag or counter of exchanges in flight, then this might have been a workable approach. > > > I can't see a way to tell that the DOE might not have responded to an > > earlier request. DOE busy indicates the write mailbox register cannot > > receive data at the moment. If it's set then there is a message in > > flight, but if it is not set there might still be a message in flight. > > Busy only indicates if the write mailbox register can sink a request > > which doesn't in general tell us anything about the underlying state. > > > > So if userspace sent a request then quit. Kernel driver would have > > no way of knowing if the next response was due to the request it sent > > or some earlier one (other than matching IDs) Note you aren't allowed > > to have multiple requests for a single protocol in flight at the same > > time. With just a lock you would have no way of preventing this. > > > > So we are back to every request the kernel sent having to be proceeded > > by an abort and potentially a 1 second delay whilst some chunk of the > > device firmware reboots. > > > > This came up in dicussion when Dan proposed the patch > > [PATCH] PCI: Allow drivers to claim exclusive access to config regions > > https://lore.kernel.org/linux-pci/161663543465.1867664.5674061943008380442.stgit@dwillia2-desk3.amr.corp.intel.com/ > > Summarizing outcome of that thread. > > > > 1) Reads of DOE registers are always safe, so we shouldn't stop lspci > > and similar accessing config space. > > 2) You are on your own if any userspace writes to pci config space. > > There are loads of ways it can break the system so it doesn't make much > > sense to protect against one more. > > I'm not quite as enthusiastic about Greg's assertion that "we're > already broken why not allow more breakage" as he was also the one > supportive of /dev/mem restrictions in the face of obvious collisions. > I'll circle back and say as much to Greg. My mistake was not realizing > the write dependency in the protocol, so the pushback was warranted > that the kernel does not need to block out all access. > > Given that /dev/mem is optionally disabled for userspace access > outside of kernel-lockdown scenarios, I think it is reasonable to have > the kernel disable config writes to a register block and the request > of a driver. > > Consider that userspace can certainly trash the system by writing to > the BAR registers, for example, but a non-malicious userspace has no > reason to do that. Unfortunately DOE has some utility for a > non-malicious userspace to access so there is a rationale to figure > out a cooperation scheme. I agree with a cooperation scheme, but I think that should take the form of a proper interface rather than a one sided lock out. It may well make sense to tighten access to PCI config space anyway but I think that's a discussion that should be separate from this feature. > > > > > If there is a reason to provide a userspace interface to a DOE for a > > device with a driver attached, then I would agree with Dan's suggestion > > to use a proper driver for it. > > > > Dan briefly mentioned that temporary blocking might be needed. I'm guessing > > that was to try and let userspace safely use the DOE. > > > > The driver would work fine ignoring busy entirely and would perhaps be > > less confusing as a result. We reset the DOE at startup anyway and that > > would clear existing busy. Any future times busy is set would have no > > impact on the flow. > > If it simplifies the kernel implementation to assume single > kernel-initiator then I think that's more than enough reason to block > out userspace, and/or provide userspace a method to get into the > kernel's queue for service. This last suggestion makes sense to me. Let's provide a 'right' way to access the DOE from user space. I like the idea if it being possible to run CXL compliance tests from userspace whilst the driver is loaded. Bjorn, given this would be a generic PCI thing, any preference for what this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar to those for the BAR based CXL mailboxes? Thanks, Jonathan
On Fri, May 14, 2021 at 09:47:55AM +0100, Jonathan Cameron wrote: > On Thu, 13 May 2021 14:20:38 -0700 > Dan Williams <dan.j.williams@intel.com> wrote: > > > On Tue, May 11, 2021 at 9:52 AM Jonathan Cameron > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > On Thu, 6 May 2021 14:59:34 -0700 > > > Ira Weiny <ira.weiny@intel.com> wrote: > > > > > > > On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote: > > > > > + > > > > > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex) > > > > > +{ > > > > > + struct pci_dev *pdev = doe->pdev; > > > > > + u32 val; > > > > > + int i; > > > > > + > > > > > + /* > > > > > + * Check the DOE busy bit is not set. If it is set, this could indicate > > > > > + * someone other than Linux (e.g. firmware) is using the mailbox. Note > > > > > + * it is expected that firmware and OS will negotiate access rights via > > > > > + * an, as yet to be defined method. > > > > > + */ > > > > > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); > > > > > + if (FIELD_GET(PCI_DOE_STATUS_BUSY, val)) > > > > > + return -EBUSY; > > > > > > > > In discussion with Dan we believe that user space could also be issuing > > > > commands and would potentially cause us to be locked out. > > > > > > > > We agree that firmware should be out of the way here and if it is blocking > > > > the OS there is not much we can do about it. > > > > > > > > However, if user space is using the mailbox we need to synchronize with them > > > > via pci_cfg_access_[try]lock(). This should avoid this EBUSY condition. > > > > > > Hi Ira, thanks for taking a look. > > > > > > So the question here is whether we can ever safely work with a > > > userspace that is accessing the DOE. I think the answer is no we can't. > > > > > > We'd have no way of knowing that userspace left the DOE in a clean state > > > without resetting every time we want to use it (which can take 1 second) > > > or doing significant sanity checking (can we tell if something is > > > in flight?). Note that if userspace and kernel were talking different > > > protocols nothing sensible could be done to prevent them receiving each > > > other's answers (unless you can rely on userspace holding the lock until > > > it is done - which you can't as who trusts userspace?) > > > > There is no ability for userpsace to lock out the kernel, only kernel > > locking out userspace. > > Hi Dan, > > Got it. Writing userspace to code with arbitrary kernel > breakage of exchanges userspace initialized is going to be nasty. > > > > > > You could do > > > something horrible like back off after peeking at the protocol to see > > > if it might be yours, but even that only works assuming the two are > > > trying to talk different protocols (talking the same protocol isn't allowed > > > but no way to enforce that using just pci_cfg_access_lock()). > > > > Wait why isn't pci_cfg_access_lock() sufficient? The userspace DOE > > transfer is halted, the kernel validates the state of DOE, does it's > > work and releases the lock. > > It's that 'validate the state of the DOE' which is the problem. I 'think' > the only way to do that is to issue an abort every time and I'm really > not liking the fact that adds a potential 1 second sleep to every > DOE access from the kernel. IIUC an abort would mean game over for *every* transaction in flight, not sure that's the best way of preventing userspace from mingling but as you mentioned I don't think there is a way around it with the current protocol. I don't see how a lock would solve this issue either - how would it ? Basically you have to stop userspace from issuing requests for the duration of a request/response (per-protocol) session, right ? Lorenzo
On Fri, 14 May 2021 12:15:38 +0100 Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: > On Fri, May 14, 2021 at 09:47:55AM +0100, Jonathan Cameron wrote: > > On Thu, 13 May 2021 14:20:38 -0700 > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > On Tue, May 11, 2021 at 9:52 AM Jonathan Cameron > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > On Thu, 6 May 2021 14:59:34 -0700 > > > > Ira Weiny <ira.weiny@intel.com> wrote: > > > > > > > > > On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote: > > > > > > + > > > > > > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex) > > > > > > +{ > > > > > > + struct pci_dev *pdev = doe->pdev; > > > > > > + u32 val; > > > > > > + int i; > > > > > > + > > > > > > + /* > > > > > > + * Check the DOE busy bit is not set. If it is set, this could indicate > > > > > > + * someone other than Linux (e.g. firmware) is using the mailbox. Note > > > > > > + * it is expected that firmware and OS will negotiate access rights via > > > > > > + * an, as yet to be defined method. > > > > > > + */ > > > > > > + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); > > > > > > + if (FIELD_GET(PCI_DOE_STATUS_BUSY, val)) > > > > > > + return -EBUSY; > > > > > > > > > > In discussion with Dan we believe that user space could also be issuing > > > > > commands and would potentially cause us to be locked out. > > > > > > > > > > We agree that firmware should be out of the way here and if it is blocking > > > > > the OS there is not much we can do about it. > > > > > > > > > > However, if user space is using the mailbox we need to synchronize with them > > > > > via pci_cfg_access_[try]lock(). This should avoid this EBUSY condition. > > > > > > > > Hi Ira, thanks for taking a look. > > > > > > > > So the question here is whether we can ever safely work with a > > > > userspace that is accessing the DOE. I think the answer is no we can't. > > > > > > > > We'd have no way of knowing that userspace left the DOE in a clean state > > > > without resetting every time we want to use it (which can take 1 second) > > > > or doing significant sanity checking (can we tell if something is > > > > in flight?). Note that if userspace and kernel were talking different > > > > protocols nothing sensible could be done to prevent them receiving each > > > > other's answers (unless you can rely on userspace holding the lock until > > > > it is done - which you can't as who trusts userspace?) > > > > > > There is no ability for userpsace to lock out the kernel, only kernel > > > locking out userspace. > > > > Hi Dan, > > > > Got it. Writing userspace to code with arbitrary kernel > > breakage of exchanges userspace initialized is going to be nasty. > > > > > > > > > You could do > > > > something horrible like back off after peeking at the protocol to see > > > > if it might be yours, but even that only works assuming the two are > > > > trying to talk different protocols (talking the same protocol isn't allowed > > > > but no way to enforce that using just pci_cfg_access_lock()). > > > > > > Wait why isn't pci_cfg_access_lock() sufficient? The userspace DOE > > > transfer is halted, the kernel validates the state of DOE, does it's > > > work and releases the lock. > > > > It's that 'validate the state of the DOE' which is the problem. I 'think' > > the only way to do that is to issue an abort every time and I'm really > > not liking the fact that adds a potential 1 second sleep to every > > DOE access from the kernel. > > IIUC an abort would mean game over for *every* transaction in flight, > not sure that's the best way of preventing userspace from mingling > but as you mentioned I don't think there is a way around it with the > current protocol. > > I don't see how a lock would solve this issue either - how would it ? It would only work if symmetric (can be locked by userspace or kernel space) and userspace was well behaved. > > Basically you have to stop userspace from issuing requests for the > duration of a request/response (per-protocol) session, right ? Yes, but also stop the kernel from issuing requests for the duration of a userspace request/response. Imagine userspace issues a request for a particular part of CDAT then kernel issues it's own request for a different part of CDAT. Unless we can ensure the userspace request / response pair is done, then there is no way for the kernel to verify that the response it gets is to the request it made. You could do some protocol specific validation but that is horrible and you might need to read a bunch of additional records to do it (checksum). As currently implemented, I'm not allowing concurrent exchanges from different protocols because it is very fiddly to do (handling the busy flag) and I'm not convinced there is a real usecase. Whilst in theory you can have lots of protocols on one DOE, the protocols defined so far have had a bunch or restrictions that mean at most you can currently collocate 2 protocols only. If it turns out to be necessary at some future time, then we can look at adding it. I think the right way to do this is to put a proper interface in place to expose the functionality to userspace via a path where mediation can be easily handled. Jonathan > > Lorenzo
On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: [..] > > If it simplifies the kernel implementation to assume single > > kernel-initiator then I think that's more than enough reason to block > > out userspace, and/or provide userspace a method to get into the > > kernel's queue for service. > > This last suggestion makes sense to me. Let's provide a 'right' way > to access the DOE from user space. I like the idea if it being possible > to run CXL compliance tests from userspace whilst the driver is loaded. Ah, and I like your observation that once the kernel provides a "right" way to access DOE then userspace direct-access of DOE is indeed a "you get to keep the pieces" event like any other unwanted userspace config-write. > Bjorn, given this would be a generic PCI thing, any preference for what > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > to those for the BAR based CXL mailboxes? (warning, anti-ioctl bias incoming...) Hmm, DOE has an enumeration capability, could the DOE driver use a scheme to have a sysfs bin_attr per discovered object type? This would make it simliar to the pci-vpd sysfs interface. Then the kernel could cache objects like CDAT that don't change outside of some invalidation event.
On Fri, 14 May 2021 11:37:12 -0700 Dan Williams <dan.j.williams@intel.com> wrote: > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > <Jonathan.Cameron@huawei.com> wrote: > [..] > > > If it simplifies the kernel implementation to assume single > > > kernel-initiator then I think that's more than enough reason to block > > > out userspace, and/or provide userspace a method to get into the > > > kernel's queue for service. > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > to access the DOE from user space. I like the idea if it being possible > > to run CXL compliance tests from userspace whilst the driver is loaded. > > Ah, and I like your observation that once the kernel provides a > "right" way to access DOE then userspace direct-access of DOE is > indeed a "you get to keep the pieces" event like any other unwanted > userspace config-write. > > > Bjorn, given this would be a generic PCI thing, any preference for what > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > to those for the BAR based CXL mailboxes? > > (warning, anti-ioctl bias incoming...) I feel very similar about ioctls - my immediate thought was to shove this in debugfs, but that feels the wrong choice if we are trying to persuade people to use it instead of writing code that directly accesses the config space. > > Hmm, DOE has an enumeration capability, could the DOE driver use a > scheme to have a sysfs bin_attr per discovered object type? This would > make it simliar to the pci-vpd sysfs interface. We can discover the protocols, but anything beyond that is protocol specific. I don't think there is a enough info available by any standards defined method. Also part of the reason to allow a safe userspace interface would be to provide a generic interface for vendor protocols and things like CXL compliance tests where we will almost certainly never provide a more specific kernel interface. Whilst sysfs would work for CDAT, some protocols are challenge response rather than simple read back and that really doesn't fit well for sysfs model. If we get other protocols that are simple data read back, then I would advocate giving them a simple sysfs interface much like proposed for CDAT as it will always be simpler to use + self describing. On a lesser note it might be helpful to provide sysfs attrs for what protocols are supported. The alternative is to let userspace run the discovery protocol. Perhaps we can do this as a later phase. > > Then the kernel could cache objects like CDAT that don't change > outside of some invalidation event. It's been a while since I last saw any conversation on sysfs bin_attrs but mostly I thought the feeling was pretty strongly against them for anything but a few niche usecases. Feels to me like it would break most of the usual rules in a way vpd does not (IIRC VPD is supposed to be a simple in the sense that if you write a value to a writable part, you will read back the same value). +CC Greg who is a fount of knowledge in this area (and regularly + correctly screams at the ways I try to abuse sysfs :) Note I don't think Dan was suggesting implementing response / request directly, but I think that is all we could do given DOE protocols can be vendor specific and the standard discovery protocol doesn't let us know the fine grained support (what commands within a given protocol). Jonathan
On Mon, May 17, 2021 at 09:40:45AM +0100, Jonathan Cameron wrote: > On Fri, 14 May 2021 11:37:12 -0700 > Dan Williams <dan.j.williams@intel.com> wrote: > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > <Jonathan.Cameron@huawei.com> wrote: > > [..] > > > > If it simplifies the kernel implementation to assume single > > > > kernel-initiator then I think that's more than enough reason to block > > > > out userspace, and/or provide userspace a method to get into the > > > > kernel's queue for service. > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > to access the DOE from user space. I like the idea if it being possible > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > Ah, and I like your observation that once the kernel provides a > > "right" way to access DOE then userspace direct-access of DOE is > > indeed a "you get to keep the pieces" event like any other unwanted > > userspace config-write. > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > to those for the BAR based CXL mailboxes? > > > > (warning, anti-ioctl bias incoming...) > > I feel very similar about ioctls - my immediate thought was to shove this in > debugfs, but that feels the wrong choice if we are trying to persuade people > to use it instead of writing code that directly accesses the config space. > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > scheme to have a sysfs bin_attr per discovered object type? This would > > make it simliar to the pci-vpd sysfs interface. > > We can discover the protocols, but anything beyond that is protocol > specific. I don't think there is a enough info available by any standards > defined method. Also part of the reason to allow a safe userspace interface > would be to provide a generic interface for vendor protocols and things like > CXL compliance tests where we will almost certainly never provide a more > specific kernel interface. > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > than simple read back and that really doesn't fit well for sysfs model. > If we get other protocols that are simple data read back, then I would > advocate giving them a simple sysfs interface much like proposed for CDAT > as it will always be simpler to use + self describing. > > On a lesser note it might be helpful to provide sysfs attrs for > what protocols are supported. The alternative is to let userspace run > the discovery protocol. Perhaps we can do this as a later phase. > > > > > Then the kernel could cache objects like CDAT that don't change > > outside of some invalidation event. > > It's been a while since I last saw any conversation on sysfs bin_attrs > but mostly I thought the feeling was pretty strongly against them for anything > but a few niche usecases. > > Feels to me like it would break most of the usual rules in a way vpd does > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > to a writable part, you will read back the same value). > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > suggesting implementing response / request directly, but I think that is > all we could do given DOE protocols can be vendor specific and the standard > discovery protocol doesn't let us know the fine grained support (what commands > within a given protocol). sysfs binary files are ONLY for pass-through things that go to/from userspace/hardware without the kernel touching them at all. Like raw PCI config descriptors. challenge/response type stuff, really does still fit the ioctl model, so that is a viable solution if needed. thanks, greg k-h
On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > > On Fri, 14 May 2021 11:37:12 -0700 > Dan Williams <dan.j.williams@intel.com> wrote: > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > <Jonathan.Cameron@huawei.com> wrote: > > [..] > > > > If it simplifies the kernel implementation to assume single > > > > kernel-initiator then I think that's more than enough reason to block > > > > out userspace, and/or provide userspace a method to get into the > > > > kernel's queue for service. > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > to access the DOE from user space. I like the idea if it being possible > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > Ah, and I like your observation that once the kernel provides a > > "right" way to access DOE then userspace direct-access of DOE is > > indeed a "you get to keep the pieces" event like any other unwanted > > userspace config-write. > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > to those for the BAR based CXL mailboxes? > > > > (warning, anti-ioctl bias incoming...) > > I feel very similar about ioctls - my immediate thought was to shove this in > debugfs, but that feels the wrong choice if we are trying to persuade people > to use it instead of writing code that directly accesses the config space. > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > scheme to have a sysfs bin_attr per discovered object type? This would > > make it simliar to the pci-vpd sysfs interface. > > We can discover the protocols, but anything beyond that is protocol > specific. I don't think there is a enough info available by any standards > defined method. Also part of the reason to allow a safe userspace interface > would be to provide a generic interface for vendor protocols and things like > CXL compliance tests where we will almost certainly never provide a more > specific kernel interface. > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > than simple read back and that really doesn't fit well for sysfs model. > If we get other protocols that are simple data read back, then I would > advocate giving them a simple sysfs interface much like proposed for CDAT > as it will always be simpler to use + self describing. > > On a lesser note it might be helpful to provide sysfs attrs for > what protocols are supported. The alternative is to let userspace run > the discovery protocol. Perhaps we can do this as a later phase. > > > > > Then the kernel could cache objects like CDAT that don't change > > outside of some invalidation event. > > It's been a while since I last saw any conversation on sysfs bin_attrs > but mostly I thought the feeling was pretty strongly against them for anything > but a few niche usecases. > > Feels to me like it would break most of the usual rules in a way vpd does > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > to a writable part, you will read back the same value). > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > suggesting implementing response / request directly, but I think that is > all we could do given DOE protocols can be vendor specific and the standard > discovery protocol doesn't let us know the fine grained support (what commands > within a given protocol). I'm not all that interested in supporting vendor defined DOE shenanigans. There's more than enough published DOE protocols that the kernel could limit its support to the known set. This is similar to how ACPI DSMs are not generically supported, but when they appear in a published specification the kernel may then grow the support. The supported protocols could be limited to: CDAT, PCIe IDE, CXL Compliance, etc... Vendor specific DOE is in the same class as unfettered /dev/mem access, first you need to disable the kernel's integrity and confidentiality protections, and then you can do whatever you want. If a vendor wants a DOE protocol supported in the "trusted" set they can simply publish the specification and send the proper support patches.
On Mon, 17 May 2021 10:21:14 -0700 Dan Williams <dan.j.williams@intel.com> wrote: > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron > <Jonathan.Cameron@huawei.com> wrote: > > > > On Fri, 14 May 2021 11:37:12 -0700 > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > > <Jonathan.Cameron@huawei.com> wrote: > > > [..] > > > > > If it simplifies the kernel implementation to assume single > > > > > kernel-initiator then I think that's more than enough reason to block > > > > > out userspace, and/or provide userspace a method to get into the > > > > > kernel's queue for service. > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > > to access the DOE from user space. I like the idea if it being possible > > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > > > Ah, and I like your observation that once the kernel provides a > > > "right" way to access DOE then userspace direct-access of DOE is > > > indeed a "you get to keep the pieces" event like any other unwanted > > > userspace config-write. > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > > to those for the BAR based CXL mailboxes? > > > > > > (warning, anti-ioctl bias incoming...) > > > > I feel very similar about ioctls - my immediate thought was to shove this in > > debugfs, but that feels the wrong choice if we are trying to persuade people > > to use it instead of writing code that directly accesses the config space. > > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > > scheme to have a sysfs bin_attr per discovered object type? This would > > > make it simliar to the pci-vpd sysfs interface. > > > > We can discover the protocols, but anything beyond that is protocol > > specific. I don't think there is a enough info available by any standards > > defined method. Also part of the reason to allow a safe userspace interface > > would be to provide a generic interface for vendor protocols and things like > > CXL compliance tests where we will almost certainly never provide a more > > specific kernel interface. > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > > than simple read back and that really doesn't fit well for sysfs model. > > If we get other protocols that are simple data read back, then I would > > advocate giving them a simple sysfs interface much like proposed for CDAT > > as it will always be simpler to use + self describing. > > > > On a lesser note it might be helpful to provide sysfs attrs for > > what protocols are supported. The alternative is to let userspace run > > the discovery protocol. Perhaps we can do this as a later phase. > > > > > > > > Then the kernel could cache objects like CDAT that don't change > > > outside of some invalidation event. > > > > It's been a while since I last saw any conversation on sysfs bin_attrs > > but mostly I thought the feeling was pretty strongly against them for anything > > but a few niche usecases. > > > > Feels to me like it would break most of the usual rules in a way vpd does > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > > to a writable part, you will read back the same value). > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > > suggesting implementing response / request directly, but I think that is > > all we could do given DOE protocols can be vendor specific and the standard > > discovery protocol doesn't let us know the fine grained support (what commands > > within a given protocol). > > I'm not all that interested in supporting vendor defined DOE > shenanigans. There's more than enough published DOE protocols that the > kernel could limit its support to the known set. This is similar to > how ACPI DSMs are not generically supported, but when they appear in a > published specification the kernel may then grow the support. The > supported protocols could be limited to: CDAT, PCIe IDE, CXL > Compliance, etc... > > Vendor specific DOE is in the same class as unfettered /dev/mem > access, first you need to disable the kernel's integrity and > confidentiality protections, and then you can do whatever you want. If > a vendor wants a DOE protocol supported in the "trusted" set they can > simply publish the specification and send the proper support patches. Fair enough, though the interface should be root only, so a vendor shooting themselves in the foot this way would be no different to using pcitools to access the device directly (we are just providing safety from concurrency point of view). Anyway, I can see two options for how to do this. 1) Per protocol interface. Would not be generic, as these work in entirely different ways (some are simple read back of tables, some require complex cycles of operations in the right order with data flowing in both directions) 2) White list those protocols we are going to let through a generic interface Not including CXL compliance for instance as that has nasty side effects! If we want to enable userspace DOE access, I prefer option 2. Note that I wasn't that keen on a userspace interface in the first place as in my view these should all be handled in kernel. Ultimately we should have case 1 if userspace access make sense. However, if we do this we shouldn't pretend we are providing userspace access to the DOE at all. We are providing interfaces to things that just happen to be implemented using DOE under the hood. I have a prototype of a trivial ioctl based interface. I'll send it out as an RFC later this week. Might add a white list, depending on where this discussion goes. Jonathan
On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > > On Mon, 17 May 2021 10:21:14 -0700 > Dan Williams <dan.j.williams@intel.com> wrote: > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > On Fri, 14 May 2021 11:37:12 -0700 > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > [..] > > > > > > If it simplifies the kernel implementation to assume single > > > > > > kernel-initiator then I think that's more than enough reason to block > > > > > > out userspace, and/or provide userspace a method to get into the > > > > > > kernel's queue for service. > > > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > > > to access the DOE from user space. I like the idea if it being possible > > > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > > > > > Ah, and I like your observation that once the kernel provides a > > > > "right" way to access DOE then userspace direct-access of DOE is > > > > indeed a "you get to keep the pieces" event like any other unwanted > > > > userspace config-write. > > > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > > > to those for the BAR based CXL mailboxes? > > > > > > > > (warning, anti-ioctl bias incoming...) > > > > > > I feel very similar about ioctls - my immediate thought was to shove this in > > > debugfs, but that feels the wrong choice if we are trying to persuade people > > > to use it instead of writing code that directly accesses the config space. > > > > > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > > > scheme to have a sysfs bin_attr per discovered object type? This would > > > > make it simliar to the pci-vpd sysfs interface. > > > > > > We can discover the protocols, but anything beyond that is protocol > > > specific. I don't think there is a enough info available by any standards > > > defined method. Also part of the reason to allow a safe userspace interface > > > would be to provide a generic interface for vendor protocols and things like > > > CXL compliance tests where we will almost certainly never provide a more > > > specific kernel interface. > > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > > > than simple read back and that really doesn't fit well for sysfs model. > > > If we get other protocols that are simple data read back, then I would > > > advocate giving them a simple sysfs interface much like proposed for CDAT > > > as it will always be simpler to use + self describing. > > > > > > On a lesser note it might be helpful to provide sysfs attrs for > > > what protocols are supported. The alternative is to let userspace run > > > the discovery protocol. Perhaps we can do this as a later phase. > > > > > > > > > > > Then the kernel could cache objects like CDAT that don't change > > > > outside of some invalidation event. > > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs > > > but mostly I thought the feeling was pretty strongly against them for anything > > > but a few niche usecases. > > > > > > Feels to me like it would break most of the usual rules in a way vpd does > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > > > to a writable part, you will read back the same value). > > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > > > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > > > suggesting implementing response / request directly, but I think that is > > > all we could do given DOE protocols can be vendor specific and the standard > > > discovery protocol doesn't let us know the fine grained support (what commands > > > within a given protocol). > > > > I'm not all that interested in supporting vendor defined DOE > > shenanigans. There's more than enough published DOE protocols that the > > kernel could limit its support to the known set. This is similar to > > how ACPI DSMs are not generically supported, but when they appear in a > > published specification the kernel may then grow the support. The > > supported protocols could be limited to: CDAT, PCIe IDE, CXL > > Compliance, etc... > > > > Vendor specific DOE is in the same class as unfettered /dev/mem > > access, first you need to disable the kernel's integrity and > > confidentiality protections, and then you can do whatever you want. If > > a vendor wants a DOE protocol supported in the "trusted" set they can > > simply publish the specification and send the proper support patches. > > Fair enough, though the interface should be root only, so a vendor shooting > themselves in the foot this way would be no different to using pcitools > to access the device directly (we are just providing safety from concurrency > point of view). > > Anyway, I can see two options for how to do this. > > 1) Per protocol interface. Would not be generic, as these work in entirely > different ways (some are simple read back of tables, some require complex > cycles of operations in the right order with data flowing in both directions) > 2) White list those protocols we are going to let through a generic interface > Not including CXL compliance for instance as that has nasty side effects! > > If we want to enable userspace DOE access, I prefer option 2. > > Note that I wasn't that keen on a userspace interface in the first place as > in my view these should all be handled in kernel. > Ultimately we should have case 1 if userspace access make sense. > However, if we do this we shouldn't pretend we are providing userspace > access to the DOE at all. We are providing interfaces to things that just > happen to be implemented using DOE under the hood. > > I have a prototype of a trivial ioctl based interface. I'll send it out > as an RFC later this week. Might add a white list, depending on where > this discussion goes. > I'd say let's do this in typical Linux fashion and not solve future problems before they need to be solved. I.e. start small and build incrementally. To me that looks like a sysfs interface to convey a cached copy of a CDAT with an internal interface for a driver to trigger invalidations and re-reads on the next access. This would assume that userspace may have left the DOE in an indeterminate state and an abort cycle may be needed. A 1 second delay for the rare case where a collision is detected seems reasonable for just CDAT retrieval.
On Wed, 19 May 2021 07:18:28 -0700 Dan Williams <dan.j.williams@intel.com> wrote: > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron > <Jonathan.Cameron@huawei.com> wrote: > > > > On Mon, 17 May 2021 10:21:14 -0700 > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > On Fri, 14 May 2021 11:37:12 -0700 > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > [..] > > > > > > > If it simplifies the kernel implementation to assume single > > > > > > > kernel-initiator then I think that's more than enough reason to block > > > > > > > out userspace, and/or provide userspace a method to get into the > > > > > > > kernel's queue for service. > > > > > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > > > > to access the DOE from user space. I like the idea if it being possible > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > > > > > > > Ah, and I like your observation that once the kernel provides a > > > > > "right" way to access DOE then userspace direct-access of DOE is > > > > > indeed a "you get to keep the pieces" event like any other unwanted > > > > > userspace config-write. > > > > > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > > > > to those for the BAR based CXL mailboxes? > > > > > > > > > > (warning, anti-ioctl bias incoming...) > > > > > > > > I feel very similar about ioctls - my immediate thought was to shove this in > > > > debugfs, but that feels the wrong choice if we are trying to persuade people > > > > to use it instead of writing code that directly accesses the config space. > > > > > > > > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > > > > scheme to have a sysfs bin_attr per discovered object type? This would > > > > > make it simliar to the pci-vpd sysfs interface. > > > > > > > > We can discover the protocols, but anything beyond that is protocol > > > > specific. I don't think there is a enough info available by any standards > > > > defined method. Also part of the reason to allow a safe userspace interface > > > > would be to provide a generic interface for vendor protocols and things like > > > > CXL compliance tests where we will almost certainly never provide a more > > > > specific kernel interface. > > > > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > > > > than simple read back and that really doesn't fit well for sysfs model. > > > > If we get other protocols that are simple data read back, then I would > > > > advocate giving them a simple sysfs interface much like proposed for CDAT > > > > as it will always be simpler to use + self describing. > > > > > > > > On a lesser note it might be helpful to provide sysfs attrs for > > > > what protocols are supported. The alternative is to let userspace run > > > > the discovery protocol. Perhaps we can do this as a later phase. > > > > > > > > > > > > > > Then the kernel could cache objects like CDAT that don't change > > > > > outside of some invalidation event. > > > > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs > > > > but mostly I thought the feeling was pretty strongly against them for anything > > > > but a few niche usecases. > > > > > > > > Feels to me like it would break most of the usual rules in a way vpd does > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > > > > to a writable part, you will read back the same value). > > > > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > > > > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > > > > suggesting implementing response / request directly, but I think that is > > > > all we could do given DOE protocols can be vendor specific and the standard > > > > discovery protocol doesn't let us know the fine grained support (what commands > > > > within a given protocol). > > > > > > I'm not all that interested in supporting vendor defined DOE > > > shenanigans. There's more than enough published DOE protocols that the > > > kernel could limit its support to the known set. This is similar to > > > how ACPI DSMs are not generically supported, but when they appear in a > > > published specification the kernel may then grow the support. The > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL > > > Compliance, etc... > > > > > > Vendor specific DOE is in the same class as unfettered /dev/mem > > > access, first you need to disable the kernel's integrity and > > > confidentiality protections, and then you can do whatever you want. If > > > a vendor wants a DOE protocol supported in the "trusted" set they can > > > simply publish the specification and send the proper support patches. > > > > Fair enough, though the interface should be root only, so a vendor shooting > > themselves in the foot this way would be no different to using pcitools > > to access the device directly (we are just providing safety from concurrency > > point of view). > > > > Anyway, I can see two options for how to do this. > > > > 1) Per protocol interface. Would not be generic, as these work in entirely > > different ways (some are simple read back of tables, some require complex > > cycles of operations in the right order with data flowing in both directions) > > 2) White list those protocols we are going to let through a generic interface > > Not including CXL compliance for instance as that has nasty side effects! > > > > If we want to enable userspace DOE access, I prefer option 2. > > > > Note that I wasn't that keen on a userspace interface in the first place as > > in my view these should all be handled in kernel. > > Ultimately we should have case 1 if userspace access make sense. > > However, if we do this we shouldn't pretend we are providing userspace > > access to the DOE at all. We are providing interfaces to things that just > > happen to be implemented using DOE under the hood. > > > > I have a prototype of a trivial ioctl based interface. I'll send it out > > as an RFC later this week. Might add a white list, depending on where > > this discussion goes. > > > > I'd say let's do this in typical Linux fashion and not solve future > problems before they need to be solved. I.e. start small and build > incrementally. To me that looks like a sysfs interface to convey a > cached copy of a CDAT with an internal interface for a driver to > trigger invalidations and re-reads on the next access. This would > assume that userspace may have left the DOE in an indeterminate state > and an abort cycle may be needed. A 1 second delay for the rare case > where a collision is detected seems reasonable for just CDAT > retrieval. The problem is you can not detect a collision. Hence it's a reset every time you use the DOE from in the kernel. Personally I think that this is fixing a problem that doesn't exist. Userspace should not access the DOE when a driver is loaded in exactly the same way it shouldn't be writing to anywhere else in config space under normal circumstances. I really don't see this as special. If we think it is special then we should provide a safe interface. Given it's nearly done, I might send out the ioctl proposal and we can can just decide to leave it unmerged for now, pending real usecases being established. Jonathan
On Wed, May 19, 2021 at 8:14 AM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > > On Wed, 19 May 2021 07:18:28 -0700 > Dan Williams <dan.j.williams@intel.com> wrote: > > > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > On Mon, 17 May 2021 10:21:14 -0700 > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > > On Fri, 14 May 2021 11:37:12 -0700 > > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > [..] > > > > > > > > If it simplifies the kernel implementation to assume single > > > > > > > > kernel-initiator then I think that's more than enough reason to block > > > > > > > > out userspace, and/or provide userspace a method to get into the > > > > > > > > kernel's queue for service. > > > > > > > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > > > > > to access the DOE from user space. I like the idea if it being possible > > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > > > > > > > > > Ah, and I like your observation that once the kernel provides a > > > > > > "right" way to access DOE then userspace direct-access of DOE is > > > > > > indeed a "you get to keep the pieces" event like any other unwanted > > > > > > userspace config-write. > > > > > > > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > > > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > > > > > to those for the BAR based CXL mailboxes? > > > > > > > > > > > > (warning, anti-ioctl bias incoming...) > > > > > > > > > > I feel very similar about ioctls - my immediate thought was to shove this in > > > > > debugfs, but that feels the wrong choice if we are trying to persuade people > > > > > to use it instead of writing code that directly accesses the config space. > > > > > > > > > > > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > > > > > scheme to have a sysfs bin_attr per discovered object type? This would > > > > > > make it simliar to the pci-vpd sysfs interface. > > > > > > > > > > We can discover the protocols, but anything beyond that is protocol > > > > > specific. I don't think there is a enough info available by any standards > > > > > defined method. Also part of the reason to allow a safe userspace interface > > > > > would be to provide a generic interface for vendor protocols and things like > > > > > CXL compliance tests where we will almost certainly never provide a more > > > > > specific kernel interface. > > > > > > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > > > > > than simple read back and that really doesn't fit well for sysfs model. > > > > > If we get other protocols that are simple data read back, then I would > > > > > advocate giving them a simple sysfs interface much like proposed for CDAT > > > > > as it will always be simpler to use + self describing. > > > > > > > > > > On a lesser note it might be helpful to provide sysfs attrs for > > > > > what protocols are supported. The alternative is to let userspace run > > > > > the discovery protocol. Perhaps we can do this as a later phase. > > > > > > > > > > > > > > > > > Then the kernel could cache objects like CDAT that don't change > > > > > > outside of some invalidation event. > > > > > > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs > > > > > but mostly I thought the feeling was pretty strongly against them for anything > > > > > but a few niche usecases. > > > > > > > > > > Feels to me like it would break most of the usual rules in a way vpd does > > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > > > > > to a writable part, you will read back the same value). > > > > > > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > > > > > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > > > > > suggesting implementing response / request directly, but I think that is > > > > > all we could do given DOE protocols can be vendor specific and the standard > > > > > discovery protocol doesn't let us know the fine grained support (what commands > > > > > within a given protocol). > > > > > > > > I'm not all that interested in supporting vendor defined DOE > > > > shenanigans. There's more than enough published DOE protocols that the > > > > kernel could limit its support to the known set. This is similar to > > > > how ACPI DSMs are not generically supported, but when they appear in a > > > > published specification the kernel may then grow the support. The > > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL > > > > Compliance, etc... > > > > > > > > Vendor specific DOE is in the same class as unfettered /dev/mem > > > > access, first you need to disable the kernel's integrity and > > > > confidentiality protections, and then you can do whatever you want. If > > > > a vendor wants a DOE protocol supported in the "trusted" set they can > > > > simply publish the specification and send the proper support patches. > > > > > > Fair enough, though the interface should be root only, so a vendor shooting > > > themselves in the foot this way would be no different to using pcitools > > > to access the device directly (we are just providing safety from concurrency > > > point of view). > > > > > > Anyway, I can see two options for how to do this. > > > > > > 1) Per protocol interface. Would not be generic, as these work in entirely > > > different ways (some are simple read back of tables, some require complex > > > cycles of operations in the right order with data flowing in both directions) > > > 2) White list those protocols we are going to let through a generic interface > > > Not including CXL compliance for instance as that has nasty side effects! > > > > > > If we want to enable userspace DOE access, I prefer option 2. > > > > > > Note that I wasn't that keen on a userspace interface in the first place as > > > in my view these should all be handled in kernel. > > > Ultimately we should have case 1 if userspace access make sense. > > > However, if we do this we shouldn't pretend we are providing userspace > > > access to the DOE at all. We are providing interfaces to things that just > > > happen to be implemented using DOE under the hood. > > > > > > I have a prototype of a trivial ioctl based interface. I'll send it out > > > as an RFC later this week. Might add a white list, depending on where > > > this discussion goes. > > > > > > > I'd say let's do this in typical Linux fashion and not solve future > > problems before they need to be solved. I.e. start small and build > > incrementally. To me that looks like a sysfs interface to convey a > > cached copy of a CDAT with an internal interface for a driver to > > trigger invalidations and re-reads on the next access. This would > > assume that userspace may have left the DOE in an indeterminate state > > and an abort cycle may be needed. A 1 second delay for the rare case > > where a collision is detected seems reasonable for just CDAT > > retrieval. > > The problem is you can not detect a collision. This discussion started because Ira questioned the handling of the busy status. If the DOE is busy and the kernel did not make it busy then there was a collision, no? > Hence it's a reset every > time you use the DOE from in the kernel. I would expect: pci_cfg_access_lock() if (busy) reset(); do_doe_operation(); pci_cfg_access_unlock(); > Personally I think that this > is fixing a problem that doesn't exist. Again this is all stemming from the driver handling "busy" especially with the knowledged that it did not busy it itself. > Userspace should not access > the DOE when a driver is loaded in exactly the same way it shouldn't > be writing to anywhere else in config space under normal circumstances. DOE has data that is similar to what can be retrieved via config read, it just so happens that reading that data triggers writes. DOE is in a different class than other configuration writes in terms of the userspace motivation to access it. > I really don't see this as special. If we think it is special then > we should provide a safe interface. > > Given it's nearly done, I might send out the ioctl proposal and > we can can just decide to leave it unmerged for now, pending real > usecases being established. Fair enough.
On Wed, 19 May 2021 08:29:58 -0700 Dan Williams <dan.j.williams@intel.com> wrote: > On Wed, May 19, 2021 at 8:14 AM Jonathan Cameron > <Jonathan.Cameron@huawei.com> wrote: > > > > On Wed, 19 May 2021 07:18:28 -0700 > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > On Mon, 17 May 2021 10:21:14 -0700 > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > > > > On Fri, 14 May 2021 11:37:12 -0700 > > > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > [..] > > > > > > > > > If it simplifies the kernel implementation to assume single > > > > > > > > > kernel-initiator then I think that's more than enough reason to block > > > > > > > > > out userspace, and/or provide userspace a method to get into the > > > > > > > > > kernel's queue for service. > > > > > > > > > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > > > > > > to access the DOE from user space. I like the idea if it being possible > > > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > > > > > > > > > > > Ah, and I like your observation that once the kernel provides a > > > > > > > "right" way to access DOE then userspace direct-access of DOE is > > > > > > > indeed a "you get to keep the pieces" event like any other unwanted > > > > > > > userspace config-write. > > > > > > > > > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > > > > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > > > > > > to those for the BAR based CXL mailboxes? > > > > > > > > > > > > > > (warning, anti-ioctl bias incoming...) > > > > > > > > > > > > I feel very similar about ioctls - my immediate thought was to shove this in > > > > > > debugfs, but that feels the wrong choice if we are trying to persuade people > > > > > > to use it instead of writing code that directly accesses the config space. > > > > > > > > > > > > > > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > > > > > > scheme to have a sysfs bin_attr per discovered object type? This would > > > > > > > make it simliar to the pci-vpd sysfs interface. > > > > > > > > > > > > We can discover the protocols, but anything beyond that is protocol > > > > > > specific. I don't think there is a enough info available by any standards > > > > > > defined method. Also part of the reason to allow a safe userspace interface > > > > > > would be to provide a generic interface for vendor protocols and things like > > > > > > CXL compliance tests where we will almost certainly never provide a more > > > > > > specific kernel interface. > > > > > > > > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > > > > > > than simple read back and that really doesn't fit well for sysfs model. > > > > > > If we get other protocols that are simple data read back, then I would > > > > > > advocate giving them a simple sysfs interface much like proposed for CDAT > > > > > > as it will always be simpler to use + self describing. > > > > > > > > > > > > On a lesser note it might be helpful to provide sysfs attrs for > > > > > > what protocols are supported. The alternative is to let userspace run > > > > > > the discovery protocol. Perhaps we can do this as a later phase. > > > > > > > > > > > > > > > > > > > > Then the kernel could cache objects like CDAT that don't change > > > > > > > outside of some invalidation event. > > > > > > > > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs > > > > > > but mostly I thought the feeling was pretty strongly against them for anything > > > > > > but a few niche usecases. > > > > > > > > > > > > Feels to me like it would break most of the usual rules in a way vpd does > > > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > > > > > > to a writable part, you will read back the same value). > > > > > > > > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > > > > > > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > > > > > > suggesting implementing response / request directly, but I think that is > > > > > > all we could do given DOE protocols can be vendor specific and the standard > > > > > > discovery protocol doesn't let us know the fine grained support (what commands > > > > > > within a given protocol). > > > > > > > > > > I'm not all that interested in supporting vendor defined DOE > > > > > shenanigans. There's more than enough published DOE protocols that the > > > > > kernel could limit its support to the known set. This is similar to > > > > > how ACPI DSMs are not generically supported, but when they appear in a > > > > > published specification the kernel may then grow the support. The > > > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL > > > > > Compliance, etc... > > > > > > > > > > Vendor specific DOE is in the same class as unfettered /dev/mem > > > > > access, first you need to disable the kernel's integrity and > > > > > confidentiality protections, and then you can do whatever you want. If > > > > > a vendor wants a DOE protocol supported in the "trusted" set they can > > > > > simply publish the specification and send the proper support patches. > > > > > > > > Fair enough, though the interface should be root only, so a vendor shooting > > > > themselves in the foot this way would be no different to using pcitools > > > > to access the device directly (we are just providing safety from concurrency > > > > point of view). > > > > > > > > Anyway, I can see two options for how to do this. > > > > > > > > 1) Per protocol interface. Would not be generic, as these work in entirely > > > > different ways (some are simple read back of tables, some require complex > > > > cycles of operations in the right order with data flowing in both directions) > > > > 2) White list those protocols we are going to let through a generic interface > > > > Not including CXL compliance for instance as that has nasty side effects! > > > > > > > > If we want to enable userspace DOE access, I prefer option 2. > > > > > > > > Note that I wasn't that keen on a userspace interface in the first place as > > > > in my view these should all be handled in kernel. > > > > Ultimately we should have case 1 if userspace access make sense. > > > > However, if we do this we shouldn't pretend we are providing userspace > > > > access to the DOE at all. We are providing interfaces to things that just > > > > happen to be implemented using DOE under the hood. > > > > > > > > I have a prototype of a trivial ioctl based interface. I'll send it out > > > > as an RFC later this week. Might add a white list, depending on where > > > > this discussion goes. > > > > > > > > > > I'd say let's do this in typical Linux fashion and not solve future > > > problems before they need to be solved. I.e. start small and build > > > incrementally. To me that looks like a sysfs interface to convey a > > > cached copy of a CDAT with an internal interface for a driver to > > > trigger invalidations and re-reads on the next access. This would > > > assume that userspace may have left the DOE in an indeterminate state > > > and an abort cycle may be needed. A 1 second delay for the rare case > > > where a collision is detected seems reasonable for just CDAT > > > retrieval. > > > > The problem is you can not detect a collision. > > This discussion started because Ira questioned the handling of the > busy status. If the DOE is busy and the kernel did not make it busy > then there was a collision, no? True, but not complete. Not having busy set does not mean there wasn't a collision. Busy is an indication that the EP can't recieve a new request (no space in buffer or similar), not that there is a response still to be sent back. We have no way to tell if there is a response going to come back in the future. There is no 'exchange in flight' flag. > > > Hence it's a reset every > > time you use the DOE from in the kernel. > > I would expect: > > pci_cfg_access_lock() > if (busy) > reset(); No, it would need to be unconditional, or you might get a response to a previously issued request mid way through your operation, and you can't in general tell that it wasn't the response to your request. For example you might get the wrong part of CDAT. You'd need to read the whole of CDAT to then verify the checksum to detect this had happened. > do_doe_operation(); > pci_cfg_access_unlock(); > > > Personally I think that this > > is fixing a problem that doesn't exist. > > Again this is all stemming from the driver handling "busy" especially > with the knowledged that it did not busy it itself. As above, busy doesn't do what it's name might suggest. It doesn't mean there is a request / response pair in flight. > > > Userspace should not access > > the DOE when a driver is loaded in exactly the same way it shouldn't > > be writing to anywhere else in config space under normal circumstances. > > DOE has data that is similar to what can be retrieved via config read, > it just so happens that reading that data triggers writes. DOE is in a > different class than other configuration writes in terms of the > userspace motivation to access it. For CDAT yes, for other protocols, (e.g. IDE, CXL compliance) definitely not. Using the protocols is as destructive as a write to config space. > > > I really don't see this as special. If we think it is special then > > we should provide a safe interface. > > > > > > Given it's nearly done, I might send out the ioctl proposal and > > we can can just decide to leave it unmerged for now, pending real > > usecases being established. > > Fair enough.
On Wed, 19 May 2021 17:20:52 +0100 Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote: > On Wed, 19 May 2021 08:29:58 -0700 > Dan Williams <dan.j.williams@intel.com> wrote: > > > On Wed, May 19, 2021 at 8:14 AM Jonathan Cameron > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > On Wed, 19 May 2021 07:18:28 -0700 > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > > On Mon, 17 May 2021 10:21:14 -0700 > > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron > > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > > > > > > On Fri, 14 May 2021 11:37:12 -0700 > > > > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > > > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > [..] > > > > > > > > > > If it simplifies the kernel implementation to assume single > > > > > > > > > > kernel-initiator then I think that's more than enough reason to block > > > > > > > > > > out userspace, and/or provide userspace a method to get into the > > > > > > > > > > kernel's queue for service. > > > > > > > > > > > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > > > > > > > to access the DOE from user space. I like the idea if it being possible > > > > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > > > > > > > > > > > > > Ah, and I like your observation that once the kernel provides a > > > > > > > > "right" way to access DOE then userspace direct-access of DOE is > > > > > > > > indeed a "you get to keep the pieces" event like any other unwanted > > > > > > > > userspace config-write. > > > > > > > > > > > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > > > > > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > > > > > > > to those for the BAR based CXL mailboxes? > > > > > > > > > > > > > > > > (warning, anti-ioctl bias incoming...) > > > > > > > > > > > > > > I feel very similar about ioctls - my immediate thought was to shove this in > > > > > > > debugfs, but that feels the wrong choice if we are trying to persuade people > > > > > > > to use it instead of writing code that directly accesses the config space. > > > > > > > > > > > > > > > > > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > > > > > > > scheme to have a sysfs bin_attr per discovered object type? This would > > > > > > > > make it simliar to the pci-vpd sysfs interface. > > > > > > > > > > > > > > We can discover the protocols, but anything beyond that is protocol > > > > > > > specific. I don't think there is a enough info available by any standards > > > > > > > defined method. Also part of the reason to allow a safe userspace interface > > > > > > > would be to provide a generic interface for vendor protocols and things like > > > > > > > CXL compliance tests where we will almost certainly never provide a more > > > > > > > specific kernel interface. > > > > > > > > > > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > > > > > > > than simple read back and that really doesn't fit well for sysfs model. > > > > > > > If we get other protocols that are simple data read back, then I would > > > > > > > advocate giving them a simple sysfs interface much like proposed for CDAT > > > > > > > as it will always be simpler to use + self describing. > > > > > > > > > > > > > > On a lesser note it might be helpful to provide sysfs attrs for > > > > > > > what protocols are supported. The alternative is to let userspace run > > > > > > > the discovery protocol. Perhaps we can do this as a later phase. > > > > > > > > > > > > > > > > > > > > > > > Then the kernel could cache objects like CDAT that don't change > > > > > > > > outside of some invalidation event. > > > > > > > > > > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs > > > > > > > but mostly I thought the feeling was pretty strongly against them for anything > > > > > > > but a few niche usecases. > > > > > > > > > > > > > > Feels to me like it would break most of the usual rules in a way vpd does > > > > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > > > > > > > to a writable part, you will read back the same value). > > > > > > > > > > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > > > > > > > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > > > > > > > suggesting implementing response / request directly, but I think that is > > > > > > > all we could do given DOE protocols can be vendor specific and the standard > > > > > > > discovery protocol doesn't let us know the fine grained support (what commands > > > > > > > within a given protocol). > > > > > > > > > > > > I'm not all that interested in supporting vendor defined DOE > > > > > > shenanigans. There's more than enough published DOE protocols that the > > > > > > kernel could limit its support to the known set. This is similar to > > > > > > how ACPI DSMs are not generically supported, but when they appear in a > > > > > > published specification the kernel may then grow the support. The > > > > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL > > > > > > Compliance, etc... > > > > > > > > > > > > Vendor specific DOE is in the same class as unfettered /dev/mem > > > > > > access, first you need to disable the kernel's integrity and > > > > > > confidentiality protections, and then you can do whatever you want. If > > > > > > a vendor wants a DOE protocol supported in the "trusted" set they can > > > > > > simply publish the specification and send the proper support patches. > > > > > > > > > > Fair enough, though the interface should be root only, so a vendor shooting > > > > > themselves in the foot this way would be no different to using pcitools > > > > > to access the device directly (we are just providing safety from concurrency > > > > > point of view). > > > > > > > > > > Anyway, I can see two options for how to do this. > > > > > > > > > > 1) Per protocol interface. Would not be generic, as these work in entirely > > > > > different ways (some are simple read back of tables, some require complex > > > > > cycles of operations in the right order with data flowing in both directions) > > > > > 2) White list those protocols we are going to let through a generic interface > > > > > Not including CXL compliance for instance as that has nasty side effects! > > > > > > > > > > If we want to enable userspace DOE access, I prefer option 2. > > > > > > > > > > Note that I wasn't that keen on a userspace interface in the first place as > > > > > in my view these should all be handled in kernel. > > > > > Ultimately we should have case 1 if userspace access make sense. > > > > > However, if we do this we shouldn't pretend we are providing userspace > > > > > access to the DOE at all. We are providing interfaces to things that just > > > > > happen to be implemented using DOE under the hood. > > > > > > > > > > I have a prototype of a trivial ioctl based interface. I'll send it out > > > > > as an RFC later this week. Might add a white list, depending on where > > > > > this discussion goes. > > > > > > > > > > > > > I'd say let's do this in typical Linux fashion and not solve future > > > > problems before they need to be solved. I.e. start small and build > > > > incrementally. To me that looks like a sysfs interface to convey a > > > > cached copy of a CDAT with an internal interface for a driver to > > > > trigger invalidations and re-reads on the next access. This would > > > > assume that userspace may have left the DOE in an indeterminate state > > > > and an abort cycle may be needed. A 1 second delay for the rare case > > > > where a collision is detected seems reasonable for just CDAT > > > > retrieval. > > > > > > The problem is you can not detect a collision. > > > > This discussion started because Ira questioned the handling of the > > busy status. If the DOE is busy and the kernel did not make it busy > > then there was a collision, no? > > True, but not complete. Not having busy set does not mean there > wasn't a collision. Busy is an indication that the EP can't recieve > a new request (no space in buffer or similar), not that there is a response > still to be sent back. We have no way to tell if there is a response > going to come back in the future. There is no 'exchange in flight' flag. Perhaps useful to add a quote from the DOE ECN here. This is in an implementation note on Page 6. "The DOE Busy bit can be used to indicate that the DOE responder is temporarily unable to accept a data object. It is necessary for a DOE requester to ensure that individual data object transfers are completed, and that a request/response contract is completed, for example using a mutex mechanism to block other conflicting traffic for cases where such conflicts are possible." Given you must not issue a second request to a given protocol until the response is received (unless you issue an abort) you can't safely do anything if we assume userspace might be using the DOE directly other than by issuing an abort every time. I had previously missed that a DOE busy clear can cause an interrupt but that would only avoid us polling for busy (probably not worth the handling code). It doesn't help us with this problem. > > > > > > Hence it's a reset every > > > time you use the DOE from in the kernel. > > > > I would expect: > > > > pci_cfg_access_lock() > > if (busy) > > reset(); > > No, it would need to be unconditional, or you might get a response > to a previously issued request mid way through your operation, and you > can't in general tell that it wasn't the response to your request. > For example you might get the wrong part of CDAT. You'd need to read > the whole of CDAT to then verify the checksum to detect this had happened. > > > do_doe_operation(); > > pci_cfg_access_unlock(); > > > > > Personally I think that this > > > is fixing a problem that doesn't exist. > > > > Again this is all stemming from the driver handling "busy" especially > > with the knowledged that it did not busy it itself. > > As above, busy doesn't do what it's name might suggest. It doesn't > mean there is a request / response pair in flight. > > > > > > Userspace should not access > > > the DOE when a driver is loaded in exactly the same way it shouldn't > > > be writing to anywhere else in config space under normal circumstances. > > > > DOE has data that is similar to what can be retrieved via config read, > > it just so happens that reading that data triggers writes. DOE is in a > > different class than other configuration writes in terms of the > > userspace motivation to access it. > > For CDAT yes, for other protocols, (e.g. IDE, CXL compliance) definitely not. > Using the protocols is as destructive as a write to config space. > > > > > > I really don't see this as special. If we think it is special then > > > we should provide a safe interface. > > > > > > > > > > Given it's nearly done, I might send out the ioctl proposal and > > > we can can just decide to leave it unmerged for now, pending real > > > usecases being established. > > > > Fair enough. >
On Wed, May 19, 2021 at 9:35 AM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > > On Wed, 19 May 2021 17:20:52 +0100 > Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote: > > > On Wed, 19 May 2021 08:29:58 -0700 > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > On Wed, May 19, 2021 at 8:14 AM Jonathan Cameron > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > On Wed, 19 May 2021 07:18:28 -0700 > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > > > > On Mon, 17 May 2021 10:21:14 -0700 > > > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > > > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron > > > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > > > > > > > > On Fri, 14 May 2021 11:37:12 -0700 > > > > > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > > > > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > > > > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > [..] > > > > > > > > > > > If it simplifies the kernel implementation to assume single > > > > > > > > > > > kernel-initiator then I think that's more than enough reason to block > > > > > > > > > > > out userspace, and/or provide userspace a method to get into the > > > > > > > > > > > kernel's queue for service. > > > > > > > > > > > > > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > > > > > > > > to access the DOE from user space. I like the idea if it being possible > > > > > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > > > > > > > > > > > > > > > Ah, and I like your observation that once the kernel provides a > > > > > > > > > "right" way to access DOE then userspace direct-access of DOE is > > > > > > > > > indeed a "you get to keep the pieces" event like any other unwanted > > > > > > > > > userspace config-write. > > > > > > > > > > > > > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > > > > > > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > > > > > > > > to those for the BAR based CXL mailboxes? > > > > > > > > > > > > > > > > > > (warning, anti-ioctl bias incoming...) > > > > > > > > > > > > > > > > I feel very similar about ioctls - my immediate thought was to shove this in > > > > > > > > debugfs, but that feels the wrong choice if we are trying to persuade people > > > > > > > > to use it instead of writing code that directly accesses the config space. > > > > > > > > > > > > > > > > > > > > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > > > > > > > > scheme to have a sysfs bin_attr per discovered object type? This would > > > > > > > > > make it simliar to the pci-vpd sysfs interface. > > > > > > > > > > > > > > > > We can discover the protocols, but anything beyond that is protocol > > > > > > > > specific. I don't think there is a enough info available by any standards > > > > > > > > defined method. Also part of the reason to allow a safe userspace interface > > > > > > > > would be to provide a generic interface for vendor protocols and things like > > > > > > > > CXL compliance tests where we will almost certainly never provide a more > > > > > > > > specific kernel interface. > > > > > > > > > > > > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > > > > > > > > than simple read back and that really doesn't fit well for sysfs model. > > > > > > > > If we get other protocols that are simple data read back, then I would > > > > > > > > advocate giving them a simple sysfs interface much like proposed for CDAT > > > > > > > > as it will always be simpler to use + self describing. > > > > > > > > > > > > > > > > On a lesser note it might be helpful to provide sysfs attrs for > > > > > > > > what protocols are supported. The alternative is to let userspace run > > > > > > > > the discovery protocol. Perhaps we can do this as a later phase. > > > > > > > > > > > > > > > > > > > > > > > > > > Then the kernel could cache objects like CDAT that don't change > > > > > > > > > outside of some invalidation event. > > > > > > > > > > > > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs > > > > > > > > but mostly I thought the feeling was pretty strongly against them for anything > > > > > > > > but a few niche usecases. > > > > > > > > > > > > > > > > Feels to me like it would break most of the usual rules in a way vpd does > > > > > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > > > > > > > > to a writable part, you will read back the same value). > > > > > > > > > > > > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > > > > > > > > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > > > > > > > > suggesting implementing response / request directly, but I think that is > > > > > > > > all we could do given DOE protocols can be vendor specific and the standard > > > > > > > > discovery protocol doesn't let us know the fine grained support (what commands > > > > > > > > within a given protocol). > > > > > > > > > > > > > > I'm not all that interested in supporting vendor defined DOE > > > > > > > shenanigans. There's more than enough published DOE protocols that the > > > > > > > kernel could limit its support to the known set. This is similar to > > > > > > > how ACPI DSMs are not generically supported, but when they appear in a > > > > > > > published specification the kernel may then grow the support. The > > > > > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL > > > > > > > Compliance, etc... > > > > > > > > > > > > > > Vendor specific DOE is in the same class as unfettered /dev/mem > > > > > > > access, first you need to disable the kernel's integrity and > > > > > > > confidentiality protections, and then you can do whatever you want. If > > > > > > > a vendor wants a DOE protocol supported in the "trusted" set they can > > > > > > > simply publish the specification and send the proper support patches. > > > > > > > > > > > > Fair enough, though the interface should be root only, so a vendor shooting > > > > > > themselves in the foot this way would be no different to using pcitools > > > > > > to access the device directly (we are just providing safety from concurrency > > > > > > point of view). > > > > > > > > > > > > Anyway, I can see two options for how to do this. > > > > > > > > > > > > 1) Per protocol interface. Would not be generic, as these work in entirely > > > > > > different ways (some are simple read back of tables, some require complex > > > > > > cycles of operations in the right order with data flowing in both directions) > > > > > > 2) White list those protocols we are going to let through a generic interface > > > > > > Not including CXL compliance for instance as that has nasty side effects! > > > > > > > > > > > > If we want to enable userspace DOE access, I prefer option 2. > > > > > > > > > > > > Note that I wasn't that keen on a userspace interface in the first place as > > > > > > in my view these should all be handled in kernel. > > > > > > Ultimately we should have case 1 if userspace access make sense. > > > > > > However, if we do this we shouldn't pretend we are providing userspace > > > > > > access to the DOE at all. We are providing interfaces to things that just > > > > > > happen to be implemented using DOE under the hood. > > > > > > > > > > > > I have a prototype of a trivial ioctl based interface. I'll send it out > > > > > > as an RFC later this week. Might add a white list, depending on where > > > > > > this discussion goes. > > > > > > > > > > > > > > > > I'd say let's do this in typical Linux fashion and not solve future > > > > > problems before they need to be solved. I.e. start small and build > > > > > incrementally. To me that looks like a sysfs interface to convey a > > > > > cached copy of a CDAT with an internal interface for a driver to > > > > > trigger invalidations and re-reads on the next access. This would > > > > > assume that userspace may have left the DOE in an indeterminate state > > > > > and an abort cycle may be needed. A 1 second delay for the rare case > > > > > where a collision is detected seems reasonable for just CDAT > > > > > retrieval. > > > > > > > > The problem is you can not detect a collision. > > > > > > This discussion started because Ira questioned the handling of the > > > busy status. If the DOE is busy and the kernel did not make it busy > > > then there was a collision, no? > > > > True, but not complete. Not having busy set does not mean there > > wasn't a collision. Busy is an indication that the EP can't recieve > > a new request (no space in buffer or similar), not that there is a response > > still to be sent back. We have no way to tell if there is a response > > going to come back in the future. There is no 'exchange in flight' flag. > > Perhaps useful to add a quote from the DOE ECN here. > This is in an implementation note on Page 6. > > "The DOE Busy bit can be used to indicate that the DOE responder is > temporarily unable to accept a data object. It is necessary for a > DOE requester to ensure that individual data object transfers are > completed, and that a request/response contract is completed, for > example using a mutex mechanism to block other conflicting traffic > for cases where such conflicts are possible." I read that as the specification mandating my proposal to disallow multi-initiator access. My only mistake was making the exclusion apply to reads and not limiting it to the minimum of config write exclusion.
On Wed, 19 May 2021 09:53:33 -0700 Dan Williams <dan.j.williams@intel.com> wrote: > On Wed, May 19, 2021 at 9:35 AM Jonathan Cameron > <Jonathan.Cameron@huawei.com> wrote: > > > > On Wed, 19 May 2021 17:20:52 +0100 > > Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote: > > > > > On Wed, 19 May 2021 08:29:58 -0700 > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > On Wed, May 19, 2021 at 8:14 AM Jonathan Cameron > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > > On Wed, 19 May 2021 07:18:28 -0700 > > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > > > On Tue, May 18, 2021 at 3:06 AM Jonathan Cameron > > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > > > > > > On Mon, 17 May 2021 10:21:14 -0700 > > > > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > > > > > > > On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron > > > > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > > > > > > > > > > On Fri, 14 May 2021 11:37:12 -0700 > > > > > > > > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > > > > > > > > > > > > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > > > > > > > > > <Jonathan.Cameron@huawei.com> wrote: > > > > > > > > > > [..] > > > > > > > > > > > > If it simplifies the kernel implementation to assume single > > > > > > > > > > > > kernel-initiator then I think that's more than enough reason to block > > > > > > > > > > > > out userspace, and/or provide userspace a method to get into the > > > > > > > > > > > > kernel's queue for service. > > > > > > > > > > > > > > > > > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > > > > > > > > > to access the DOE from user space. I like the idea if it being possible > > > > > > > > > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > > > > > > > > > > > > > > > > > Ah, and I like your observation that once the kernel provides a > > > > > > > > > > "right" way to access DOE then userspace direct-access of DOE is > > > > > > > > > > indeed a "you get to keep the pieces" event like any other unwanted > > > > > > > > > > userspace config-write. > > > > > > > > > > > > > > > > > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > > > > > > > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > > > > > > > > > to those for the BAR based CXL mailboxes? > > > > > > > > > > > > > > > > > > > > (warning, anti-ioctl bias incoming...) > > > > > > > > > > > > > > > > > > I feel very similar about ioctls - my immediate thought was to shove this in > > > > > > > > > debugfs, but that feels the wrong choice if we are trying to persuade people > > > > > > > > > to use it instead of writing code that directly accesses the config space. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > > > > > > > > > scheme to have a sysfs bin_attr per discovered object type? This would > > > > > > > > > > make it simliar to the pci-vpd sysfs interface. > > > > > > > > > > > > > > > > > > We can discover the protocols, but anything beyond that is protocol > > > > > > > > > specific. I don't think there is a enough info available by any standards > > > > > > > > > defined method. Also part of the reason to allow a safe userspace interface > > > > > > > > > would be to provide a generic interface for vendor protocols and things like > > > > > > > > > CXL compliance tests where we will almost certainly never provide a more > > > > > > > > > specific kernel interface. > > > > > > > > > > > > > > > > > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > > > > > > > > > than simple read back and that really doesn't fit well for sysfs model. > > > > > > > > > If we get other protocols that are simple data read back, then I would > > > > > > > > > advocate giving them a simple sysfs interface much like proposed for CDAT > > > > > > > > > as it will always be simpler to use + self describing. > > > > > > > > > > > > > > > > > > On a lesser note it might be helpful to provide sysfs attrs for > > > > > > > > > what protocols are supported. The alternative is to let userspace run > > > > > > > > > the discovery protocol. Perhaps we can do this as a later phase. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then the kernel could cache objects like CDAT that don't change > > > > > > > > > > outside of some invalidation event. > > > > > > > > > > > > > > > > > > It's been a while since I last saw any conversation on sysfs bin_attrs > > > > > > > > > but mostly I thought the feeling was pretty strongly against them for anything > > > > > > > > > but a few niche usecases. > > > > > > > > > > > > > > > > > > Feels to me like it would break most of the usual rules in a way vpd does > > > > > > > > > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > > > > > > > > > to a writable part, you will read back the same value). > > > > > > > > > > > > > > > > > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > > > > > > > > > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > > > > > > > > > suggesting implementing response / request directly, but I think that is > > > > > > > > > all we could do given DOE protocols can be vendor specific and the standard > > > > > > > > > discovery protocol doesn't let us know the fine grained support (what commands > > > > > > > > > within a given protocol). > > > > > > > > > > > > > > > > I'm not all that interested in supporting vendor defined DOE > > > > > > > > shenanigans. There's more than enough published DOE protocols that the > > > > > > > > kernel could limit its support to the known set. This is similar to > > > > > > > > how ACPI DSMs are not generically supported, but when they appear in a > > > > > > > > published specification the kernel may then grow the support. The > > > > > > > > supported protocols could be limited to: CDAT, PCIe IDE, CXL > > > > > > > > Compliance, etc... > > > > > > > > > > > > > > > > Vendor specific DOE is in the same class as unfettered /dev/mem > > > > > > > > access, first you need to disable the kernel's integrity and > > > > > > > > confidentiality protections, and then you can do whatever you want. If > > > > > > > > a vendor wants a DOE protocol supported in the "trusted" set they can > > > > > > > > simply publish the specification and send the proper support patches. > > > > > > > > > > > > > > Fair enough, though the interface should be root only, so a vendor shooting > > > > > > > themselves in the foot this way would be no different to using pcitools > > > > > > > to access the device directly (we are just providing safety from concurrency > > > > > > > point of view). > > > > > > > > > > > > > > Anyway, I can see two options for how to do this. > > > > > > > > > > > > > > 1) Per protocol interface. Would not be generic, as these work in entirely > > > > > > > different ways (some are simple read back of tables, some require complex > > > > > > > cycles of operations in the right order with data flowing in both directions) > > > > > > > 2) White list those protocols we are going to let through a generic interface > > > > > > > Not including CXL compliance for instance as that has nasty side effects! > > > > > > > > > > > > > > If we want to enable userspace DOE access, I prefer option 2. > > > > > > > > > > > > > > Note that I wasn't that keen on a userspace interface in the first place as > > > > > > > in my view these should all be handled in kernel. > > > > > > > Ultimately we should have case 1 if userspace access make sense. > > > > > > > However, if we do this we shouldn't pretend we are providing userspace > > > > > > > access to the DOE at all. We are providing interfaces to things that just > > > > > > > happen to be implemented using DOE under the hood. > > > > > > > > > > > > > > I have a prototype of a trivial ioctl based interface. I'll send it out > > > > > > > as an RFC later this week. Might add a white list, depending on where > > > > > > > this discussion goes. > > > > > > > > > > > > > > > > > > > I'd say let's do this in typical Linux fashion and not solve future > > > > > > problems before they need to be solved. I.e. start small and build > > > > > > incrementally. To me that looks like a sysfs interface to convey a > > > > > > cached copy of a CDAT with an internal interface for a driver to > > > > > > trigger invalidations and re-reads on the next access. This would > > > > > > assume that userspace may have left the DOE in an indeterminate state > > > > > > and an abort cycle may be needed. A 1 second delay for the rare case > > > > > > where a collision is detected seems reasonable for just CDAT > > > > > > retrieval. > > > > > > > > > > The problem is you can not detect a collision. > > > > > > > > This discussion started because Ira questioned the handling of the > > > > busy status. If the DOE is busy and the kernel did not make it busy > > > > then there was a collision, no? > > > > > > True, but not complete. Not having busy set does not mean there > > > wasn't a collision. Busy is an indication that the EP can't recieve > > > a new request (no space in buffer or similar), not that there is a response > > > still to be sent back. We have no way to tell if there is a response > > > going to come back in the future. There is no 'exchange in flight' flag. > > > > Perhaps useful to add a quote from the DOE ECN here. > > This is in an implementation note on Page 6. > > > > "The DOE Busy bit can be used to indicate that the DOE responder is > > temporarily unable to accept a data object. It is necessary for a > > DOE requester to ensure that individual data object transfers are > > completed, and that a request/response contract is completed, for > > example using a mutex mechanism to block other conflicting traffic > > for cases where such conflicts are possible." > > I read that as the specification mandating my proposal to disallow > multi-initiator access. My only mistake was making the exclusion apply > to reads and not limiting it to the minimum of config write exclusion. Key thing is even that isn't enough. The mutex isn't about stopping temporary access, it's about ensuring "request/response contract is completed". So you would need userspace to be able to take a lock to stop the kernel from using the DOE whilst it completes it's request/response pair and userspace to guarantee it doesn't do anything stupid. Easiest way to do that is provide proper interfaces that allows the kernel to fully mediate the access + don't support direct userspace access for normal operation. (treat it the same as an other config space write) Jonathan
On Wed, May 19, 2021 at 10:03 AM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: [..] > > > "The DOE Busy bit can be used to indicate that the DOE responder is > > > temporarily unable to accept a data object. It is necessary for a > > > DOE requester to ensure that individual data object transfers are > > > completed, and that a request/response contract is completed, for > > > example using a mutex mechanism to block other conflicting traffic > > > for cases where such conflicts are possible." > > > > I read that as the specification mandating my proposal to disallow > > multi-initiator access. My only mistake was making the exclusion apply > > to reads and not limiting it to the minimum of config write exclusion. > > Key thing is even that isn't enough. The mutex isn't about stopping > temporary access, it's about ensuring "request/response contract is completed". > So you would need userspace to be able to take a lock to stop the kernel > from using the DOE whilst it completes it's request/response pair and > userspace to guarantee it doesn't do anything stupid. A userspace lockout of the kernel is not needed if userspace is outright forbidden from corrupting the kernel's state machine. I.e. kernel enforced full disable of user initiated config-write to DOE registers, not the ephemeral pci_cfg_access_lock() proposal. > Easiest way to do that is provide proper interfaces that allows the > kernel to fully mediate the access + don't support direct userspace access > for normal operation. (treat it the same as an other config space write) Again, it's the parenthetical at issue. I struggle to see this as just another errant / unwanted config-write when there is legitimate reason for userspace to expect that touching the DOE is not destructive to device operation as opposed to writes to other critical registers. Where the kernel's legitimate-access and userspace's legitimate-access to a resource collide, the kernel provides a mediation interface that precludes conflicts. Otherwise, I don't understand why the kernel is going through the trouble of /dev/mem and pci-mmap restrictions if it is not supposed to be concerned about userspace corrupting driver state.
On Wed, 19 May 2021 12:20:17 -0700 Dan Williams <dan.j.williams@intel.com> wrote: > On Wed, May 19, 2021 at 10:03 AM Jonathan Cameron > <Jonathan.Cameron@huawei.com> wrote: > [..] > > > > "The DOE Busy bit can be used to indicate that the DOE responder is > > > > temporarily unable to accept a data object. It is necessary for a > > > > DOE requester to ensure that individual data object transfers are > > > > completed, and that a request/response contract is completed, for > > > > example using a mutex mechanism to block other conflicting traffic > > > > for cases where such conflicts are possible." > > > > > > I read that as the specification mandating my proposal to disallow > > > multi-initiator access. My only mistake was making the exclusion apply > > > to reads and not limiting it to the minimum of config write exclusion. > > > > Key thing is even that isn't enough. The mutex isn't about stopping > > temporary access, it's about ensuring "request/response contract is completed". > > So you would need userspace to be able to take a lock to stop the kernel > > from using the DOE whilst it completes it's request/response pair and > > userspace to guarantee it doesn't do anything stupid. > > A userspace lockout of the kernel is not needed if userspace is > outright forbidden from corrupting the kernel's state machine. I.e. > kernel enforced full disable of user initiated config-write to DOE > registers, not the ephemeral pci_cfg_access_lock() proposal. That would work but I thought was ruled out as an approach. @Bjorn would this be acceptable? > > > Easiest way to do that is provide proper interfaces that allows the > > kernel to fully mediate the access + don't support direct userspace access > > for normal operation. (treat it the same as an other config space write) > > Again, it's the parenthetical at issue. I struggle to see this as just > another errant / unwanted config-write when there is legitimate reason > for userspace to expect that touching the DOE is not destructive to > device operation as opposed to writes to other critical registers. True for specific protocols (CDAT). I'm fairly sure, with IDE you can take down the link encryption to the device, potentially (worst case?) resulting a memory access failure and a machine reboot or corruption of persistent memory. > Where the kernel's legitimate-access and userspace's legitimate-access > to a resource collide, the kernel provides a mediation interface that > precludes conflicts. Otherwise, I don't understand why the kernel is > going through the trouble of /dev/mem and pci-mmap restrictions if it > is not supposed to be concerned about userspace corrupting driver > state. The short answer is that lock requirement, in the above note, rules out safe direct userspace use of the DOE (unless we can tell the kernel is not going to ever use it). Mediation must be done. Even if we safely protect the kernel side via aborts, userspace transactions can be interrupted in a fashion that is invisible to userspace (beyond maybe a timeout if the userspace code is hardened against this). So there is no legitimate use that is not fully mediated by the kernel. So ioctl or defined per protocol interfaces are the way forwards. Perhaps that's putting it rather strongly :) Jonathan
On Wed, May 19, 2021 at 1:20 PM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > > On Wed, 19 May 2021 12:20:17 -0700 > Dan Williams <dan.j.williams@intel.com> wrote: > > > On Wed, May 19, 2021 at 10:03 AM Jonathan Cameron > > <Jonathan.Cameron@huawei.com> wrote: > > [..] > > > > > "The DOE Busy bit can be used to indicate that the DOE responder is > > > > > temporarily unable to accept a data object. It is necessary for a > > > > > DOE requester to ensure that individual data object transfers are > > > > > completed, and that a request/response contract is completed, for > > > > > example using a mutex mechanism to block other conflicting traffic > > > > > for cases where such conflicts are possible." > > > > > > > > I read that as the specification mandating my proposal to disallow > > > > multi-initiator access. My only mistake was making the exclusion apply > > > > to reads and not limiting it to the minimum of config write exclusion. > > > > > > Key thing is even that isn't enough. The mutex isn't about stopping > > > temporary access, it's about ensuring "request/response contract is completed". > > > So you would need userspace to be able to take a lock to stop the kernel > > > from using the DOE whilst it completes it's request/response pair and > > > userspace to guarantee it doesn't do anything stupid. > > > > A userspace lockout of the kernel is not needed if userspace is > > outright forbidden from corrupting the kernel's state machine. I.e. > > kernel enforced full disable of user initiated config-write to DOE > > registers, not the ephemeral pci_cfg_access_lock() proposal. > > That would work but I thought was ruled out as an approach. > @Bjorn would this be acceptable? > It sounded like Bjorn needed more convincing: "I don't know how hard we should work to protect against that." ...and I'm advocating that yes, DOE config-writes are in a different class than other critical register writes, and that class is analogous to what Linux does for driver managed MMIO exclusion. > > > > > Easiest way to do that is provide proper interfaces that allows the > > > kernel to fully mediate the access + don't support direct userspace access > > > for normal operation. (treat it the same as an other config space write) > > > > Again, it's the parenthetical at issue. I struggle to see this as just > > another errant / unwanted config-write when there is legitimate reason > > for userspace to expect that touching the DOE is not destructive to > > device operation as opposed to writes to other critical registers. > > True for specific protocols (CDAT). I'm fairly sure, with IDE you can take down > the link encryption to the device, potentially (worst case?) resulting a memory > access failure and a machine reboot or corruption of persistent memory. No, that does not sound right. My reading of the PCI IDE spec highlights a few exclusions that apply here: 1/ A DOE instance that implements the CMA/SPDM protocol will support "no other data object protocol(s)". 2/ An SPDM session once established arranges for "requests that are received through a different secure [SPDM] session must be discarded by the Responder, and must not result in a response" > > > Where the kernel's legitimate-access and userspace's legitimate-access > > to a resource collide, the kernel provides a mediation interface that > > precludes conflicts. Otherwise, I don't understand why the kernel is > > going through the trouble of /dev/mem and pci-mmap restrictions if it > > is not supposed to be concerned about userspace corrupting driver > > state. > > The short answer is that lock requirement, in the above note, rules > out safe direct userspace use of the DOE (unless we can tell the kernel > is not going to ever use it). Linux has the mitigation for that situation defined already. It's the mechanism for /dev/mem and pci-mmap exclusion: disable the driver to enable unfettered userspace access (modulo kernel-lockdown is disabled). > Mediation must be done. Even if we safely > protect the kernel side via aborts, userspace transactions can be > interrupted in a fashion that is invisible to userspace (beyond maybe > a timeout if the userspace code is hardened against this). Right, ephemeral per-transaction lockout is more complicated to handle than coarse lockout bounded to driver attach lifetime. > So there is no > legitimate use that is not fully mediated by the kernel. So ioctl > or defined per protocol interfaces are the way forwards. Agree, and Linux has historically tried to wrap specific protocols around capabilities like this rather than defining raw passthroughs. I.e. I'm equating DOE enabling policy to ACPI DSM enabling policy. So per-protocol enabling is my expectation regardless of sysfs or ioctl. In fact. for SPDM and IDE key establishment that is probably neither ioctl nor sysfs, but instead a cooperation with the Linux keys api. > Perhaps that's putting it rather strongly :) No major disagreement on the big picture... just quibbling with details at this point.
On Wed, May 19, 2021 at 4:51 PM Dan Williams <dan.j.williams@intel.com> wrote: [..] > > The short answer is that lock requirement, in the above note, rules > > out safe direct userspace use of the DOE (unless we can tell the kernel > > is not going to ever use it). > > Linux has the mitigation for that situation defined already. It's the > mechanism for /dev/mem and pci-mmap exclusion: disable the driver to > enable unfettered userspace access (modulo kernel-lockdown is > disabled). > Note that when I say "driver" here, it need not necessarily be the cxl_pci driver for the memory expander. For example, DOE functionality could be handled by an aux-bus device+driver where that can be unloaded without taking down the rest of the CXL driver.
On Wed, 19 May 2021 16:51:36 -0700 Dan Williams <dan.j.williams@intel.com> wrote: > On Wed, May 19, 2021 at 1:20 PM Jonathan Cameron > <Jonathan.Cameron@huawei.com> wrote: > > > > On Wed, 19 May 2021 12:20:17 -0700 > > Dan Williams <dan.j.williams@intel.com> wrote: > > > > > On Wed, May 19, 2021 at 10:03 AM Jonathan Cameron > > > <Jonathan.Cameron@huawei.com> wrote: > > > [..] > > > > > > "The DOE Busy bit can be used to indicate that the DOE responder is > > > > > > temporarily unable to accept a data object. It is necessary for a > > > > > > DOE requester to ensure that individual data object transfers are > > > > > > completed, and that a request/response contract is completed, for > > > > > > example using a mutex mechanism to block other conflicting traffic > > > > > > for cases where such conflicts are possible." > > > > > > > > > > I read that as the specification mandating my proposal to disallow > > > > > multi-initiator access. My only mistake was making the exclusion apply > > > > > to reads and not limiting it to the minimum of config write exclusion. > > > > > > > > Key thing is even that isn't enough. The mutex isn't about stopping > > > > temporary access, it's about ensuring "request/response contract is completed". > > > > So you would need userspace to be able to take a lock to stop the kernel > > > > from using the DOE whilst it completes it's request/response pair and > > > > userspace to guarantee it doesn't do anything stupid. > > > > > > A userspace lockout of the kernel is not needed if userspace is > > > outright forbidden from corrupting the kernel's state machine. I.e. > > > kernel enforced full disable of user initiated config-write to DOE > > > registers, not the ephemeral pci_cfg_access_lock() proposal. > > > > That would work but I thought was ruled out as an approach. > > @Bjorn would this be acceptable? > > > > It sounded like Bjorn needed more convincing: > > "I don't know how hard we should work to protect against that." > > ...and I'm advocating that yes, DOE config-writes are in a different > class than other critical register writes, and that class is analogous > to what Linux does for driver managed MMIO exclusion. I'm not convinced they are special, though I can see an argument for write protecting a bunch of registers in config space, including them, with some form of disable for those debug type cases that Bjorn referred to. > > > > > > > > Easiest way to do that is provide proper interfaces that allows the > > > > kernel to fully mediate the access + don't support direct userspace access > > > > for normal operation. (treat it the same as an other config space write) > > > > > > Again, it's the parenthetical at issue. I struggle to see this as just > > > another errant / unwanted config-write when there is legitimate reason > > > for userspace to expect that touching the DOE is not destructive to > > > device operation as opposed to writes to other critical registers. > > > > True for specific protocols (CDAT). I'm fairly sure, with IDE you can take down > > the link encryption to the device, potentially (worst case?) resulting a memory > > access failure and a machine reboot or corruption of persistent memory. > > No, that does not sound right. My reading of the PCI IDE spec > highlights a few exclusions that apply here: > > 1/ A DOE instance that implements the CMA/SPDM protocol will support > "no other data object protocol(s)". > > 2/ An SPDM session once established arranges for "requests that are > received through a different secure [SPDM] session must be discarded > by the Responder, and must not result in a response" Fair enough. I've not looked at that one in a while and clearly need to give it another read. CXL compliance though can definitely cause things to be exciting for the host. > > > > > > Where the kernel's legitimate-access and userspace's legitimate-access > > > to a resource collide, the kernel provides a mediation interface that > > > precludes conflicts. Otherwise, I don't understand why the kernel is > > > going through the trouble of /dev/mem and pci-mmap restrictions if it > > > is not supposed to be concerned about userspace corrupting driver > > > state. > > > > The short answer is that lock requirement, in the above note, rules > > out safe direct userspace use of the DOE (unless we can tell the kernel > > is not going to ever use it). > > Linux has the mitigation for that situation defined already. It's the > mechanism for /dev/mem and pci-mmap exclusion: disable the driver to > enable unfettered userspace access (modulo kernel-lockdown is > disabled). > > > Mediation must be done. Even if we safely > > protect the kernel side via aborts, userspace transactions can be > > interrupted in a fashion that is invisible to userspace (beyond maybe > > a timeout if the userspace code is hardened against this). > > Right, ephemeral per-transaction lockout is more complicated to handle > than coarse lockout bounded to driver attach lifetime. > > > So there is no > > legitimate use that is not fully mediated by the kernel. So ioctl > > or defined per protocol interfaces are the way forwards. > > Agree, and Linux has historically tried to wrap specific protocols > around capabilities like this rather than defining raw passthroughs. > I.e. I'm equating DOE enabling policy to ACPI DSM enabling policy. So > per-protocol enabling is my expectation regardless of sysfs or ioctl. > In fact. for SPDM and IDE key establishment that is probably neither > ioctl nor sysfs, but instead a cooperation with the Linux keys api. Agreed. On that basis I'll do a very limited polish of the generic ioctl approach simply as an enabling tool and put some warnings on the patch that we don't currently intend it to be merged etc. Great - that lets be me lazy with testing lifetime management which is always irritating to do ;) > > > Perhaps that's putting it rather strongly :) > > No major disagreement on the big picture... just quibbling with > details at this point.
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 0c473d75e625..6dd48a1ad2a4 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -190,6 +190,14 @@ config PCI_HYPERV The PCI device frontend driver allows the kernel to import arbitrary PCI devices from a PCI backend to support PCI driver domains. +config PCI_DOE + bool + help + This enables library support for the PCI Data Object Exchange + capability. DOE provides a simple mailbox in PCI config space that is + used by a number of different protocols. + DOE is defined in the Data Object Exchange ECN to PCI 5.0. + choice prompt "PCI Express hierarchy optimization setting" default PCIE_BUS_DEFAULT diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index d62c4ac4ae1b..1b61c1a1c232 100644 --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_PCI_STUB) += pci-stub.o obj-$(CONFIG_PCI_PF_STUB) += pci-pf-stub.o obj-$(CONFIG_PCI_ECAM) += ecam.o obj-$(CONFIG_PCI_P2PDMA) += p2pdma.o +obj-$(CONFIG_PCI_DOE) += doe.o obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o # Endpoint library must be initialized before its users diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c new file mode 100644 index 000000000000..fce16c78ff45 --- /dev/null +++ b/drivers/pci/doe.c @@ -0,0 +1,601 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Data Object Exchange ECN + * https://members.pcisig.com/wg/PCI-SIG/document/14143 + * + * Copyright (C) 2021 Huawei + * Jonathan Cameron <Jonathan.Cameron@huawei.com> + */ + +#include <linux/bitfield.h> +#include <linux/delay.h> +#include <linux/jiffies.h> +#include <linux/list.h> +#include <linux/mutex.h> +#include <linux/pci.h> +#include <linux/pci-doe.h> +#include <linux/workqueue.h> + +#define PCI_DOE_PROTOCOL_DISCOVERY 0 + +#define PCI_DOE_BUSY_MAX_RETRIES 16 +#define PCI_DOE_POLL_INTERVAL (HZ / 128) + +/* Timeout of 1 second from 6.xx.1 (Operation), ECN - Data Object Exchange */ +#define PCI_DOE_TIMEOUT HZ + +static irqreturn_t pci_doe_irq(int irq, void *data) +{ + struct pci_doe *doe = data; + struct pci_dev *pdev = doe->pdev; + u32 val; + + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); + if (FIELD_GET(PCI_DOE_STATUS_INT_STATUS, val)) { + pci_write_config_dword(pdev, doe->cap + PCI_DOE_STATUS, val); + mod_delayed_work(system_wq, &doe->statemachine, 0); + return IRQ_HANDLED; + } + /* Leave the error case to be handled outside IRQ */ + if (FIELD_GET(PCI_DOE_STATUS_ERROR, val)) { + mod_delayed_work(system_wq, &doe->statemachine, 0); + return IRQ_HANDLED; + } + + return IRQ_NONE; +} + +/* + * Only call when safe to directly access the DOE, either because no tasks yet + * queued, or called from doe_statemachine_work() which has exclusive access to + * the DOE config space. + */ +static void pci_doe_abort_start(struct pci_doe *doe) +{ + struct pci_dev *pdev = doe->pdev; + + pci_write_config_dword(pdev, doe->cap + PCI_DOE_CTRL, + PCI_DOE_CTRL_ABORT); + + doe->timeout_jiffies = jiffies + HZ; + schedule_delayed_work(&doe->statemachine, HZ); +} + +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex) +{ + struct pci_dev *pdev = doe->pdev; + u32 val; + int i; + + /* + * Check the DOE busy bit is not set. If it is set, this could indicate + * someone other than Linux (e.g. firmware) is using the mailbox. Note + * it is expected that firmware and OS will negotiate access rights via + * an, as yet to be defined method. + */ + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); + if (FIELD_GET(PCI_DOE_STATUS_BUSY, val)) + return -EBUSY; + + if (FIELD_GET(PCI_DOE_STATUS_ERROR, val)) + return -EIO; + + /* Write DOE Header */ + val = FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_1_VID, ex->vid) | + FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, ex->protocol); + pci_write_config_dword(pdev, doe->cap + PCI_DOE_WRITE, val); + /* Length is 2 DW of header + length of payload in DW */ + pci_write_config_dword(pdev, doe->cap + PCI_DOE_WRITE, + FIELD_PREP(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH, + 2 + ex->request_pl_sz / sizeof(u32))); + for (i = 0; i < ex->request_pl_sz / sizeof(u32); i++) + pci_write_config_dword(pdev, doe->cap + PCI_DOE_WRITE, + ex->request_pl[i]); + + pci_write_config_dword(pdev, doe->cap + PCI_DOE_CTRL, PCI_DOE_CTRL_GO); + /* Request is sent - now wait for poll or IRQ */ + return 0; +} + +static int pci_doe_recv_resp(struct pci_doe *doe, struct pci_doe_exchange *ex) +{ + struct pci_dev *pdev = doe->pdev; + size_t length; + u32 val; + int i; + + /* Read the first two dwords to get the length and protocol */ + pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val); + if ((FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val) != ex->vid) || + (FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val) != ex->protocol)) { + pci_err(pdev, + "Expected [VID, Protocol] = [%x, %x], got [%x, %x]\n", + ex->vid, ex->protocol, + FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_VID, val), + FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_1_TYPE, val)); + return -EIO; + } + + pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0); + pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val); + pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0); + + length = FIELD_GET(PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH, val); + if (length > SZ_1M) + return -EIO; + + /* Read the rest of the response payload */ + for (i = 0; i < min(length, ex->response_pl_sz / sizeof(u32)); i++) { + pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, + &ex->response_pl[i]); + pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0); + } + + /* Flush excess length */ + for (; i < length; i++) { + pci_read_config_dword(pdev, doe->cap + PCI_DOE_READ, &val); + pci_write_config_dword(pdev, doe->cap + PCI_DOE_READ, 0); + } + /* Final error check to pick up on any since Data Object Ready */ + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); + if (FIELD_GET(PCI_DOE_STATUS_ERROR, val)) + return -EIO; + + return min(length, ex->response_pl_sz / sizeof(u32)) * sizeof(u32); +} + +static void pci_doe_task_complete(void *private) +{ + complete(private); +} + +/** + * struct pci_doe_task - description of a query / response task. + * @h: Head to add it to the list of outstanding tasks. + * @ex: The details of the task to be done. + * @rv: Return value. Length of received response or error. + * @cb: Callback for completion of task. + * @private: Private data passed to callback on completion. + */ +struct pci_doe_task { + struct list_head h; + struct pci_doe_exchange *ex; + int rv; + void (*cb)(void *private); + void *private; +}; + +/** + * pci_doe_exchange_sync() - Send a request, then wait for and receive response. + * @doe: DOE mailbox state structure. + * @ex: Description of the buffers and Vendor ID + type used in this + * request/response pair, + * + * Excess data will be discarded. + * + * RETURNS: payload in bytes on success, < 0 on error. + */ +int pci_doe_exchange_sync(struct pci_doe *doe, struct pci_doe_exchange *ex) +{ + struct pci_doe_task task; + DECLARE_COMPLETION_ONSTACK(c); + int only_task; + + /* DOE requests must be a whole number of DW */ + if (ex->request_pl_sz % sizeof(u32)) + return -EINVAL; + + task.ex = ex; + task.cb = pci_doe_task_complete; + task.private = &c; + + mutex_lock(&doe->tasks_lock); + if (doe->dead) { + mutex_unlock(&doe->tasks_lock); + return -EIO; + } + only_task = list_empty(&doe->tasks); + list_add_tail(&task.h, &doe->tasks); + if (only_task) + schedule_delayed_work(&doe->statemachine, 0); + mutex_unlock(&doe->tasks_lock); + wait_for_completion(&c); + + return task.rv; +} +EXPORT_SYMBOL_GPL(pci_doe_exchange_sync); + +static void doe_statemachine_work(struct work_struct *work) +{ + struct delayed_work *w = to_delayed_work(work); + struct pci_doe *doe = container_of(w, struct pci_doe, statemachine); + struct pci_dev *pdev = doe->pdev; + struct pci_doe_task *task; + bool abort; + u32 val; + int rc; + + mutex_lock(&doe->tasks_lock); + task = list_first_entry_or_null(&doe->tasks, struct pci_doe_task, h); + abort = doe->abort; + doe->abort = false; + mutex_unlock(&doe->tasks_lock); + + if (abort) { + /* + * Currently only used during init - care needed if we want to + * generally expose pci_doe_abort() as it would impact queries + * in flight. + */ + WARN_ON(task); + doe->state = DOE_WAIT_ABORT; + pci_doe_abort_start(doe); + return; + } + + switch (doe->state) { + case DOE_IDLE: + if (task == NULL) + return; + + /* Nothing currently in flight so queue a task */ + rc = pci_doe_send_req(doe, task->ex); + /* + * The specification does not provide any guidance on how long + * some other entity could keep the DOE busy, so try for 1 + * second then fail. Busy handling is best effort only, because + * there is no way of avoiding racing against another user of + * the DOE. + */ + if (rc == -EBUSY) { + doe->busy_retries++; + if (doe->busy_retries == PCI_DOE_BUSY_MAX_RETRIES) { + /* Long enough, fail this request */ + doe->busy_retries = 0; + goto err_busy; + } + schedule_delayed_work(w, HZ / PCI_DOE_BUSY_MAX_RETRIES); + return; + } + if (rc) + goto err_abort; + doe->busy_retries = 0; + + doe->state = DOE_WAIT_RESP; + doe->timeout_jiffies = jiffies + HZ; + /* Now poll or wait for IRQ with timeout */ + if (doe->irq > 0) + schedule_delayed_work(w, PCI_DOE_TIMEOUT); + else + schedule_delayed_work(w, PCI_DOE_POLL_INTERVAL); + return; + + case DOE_WAIT_RESP: + /* Not possible to get here with NULL task */ + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); + if (FIELD_GET(PCI_DOE_STATUS_ERROR, val)) { + rc = -EIO; + goto err_abort; + } + + if (!FIELD_GET(PCI_DOE_STATUS_DATA_OBJECT_READY, val)) { + /* If not yet at timeout reschedule otherwise abort */ + if (time_after(jiffies, doe->timeout_jiffies)) { + rc = -ETIMEDOUT; + goto err_abort; + } + schedule_delayed_work(w, PCI_DOE_POLL_INTERVAL); + return; + } + + rc = pci_doe_recv_resp(doe, task->ex); + if (rc < 0) + goto err_abort; + + doe->state = DOE_IDLE; + + mutex_lock(&doe->tasks_lock); + list_del(&task->h); + if (!list_empty(&doe->tasks)) + schedule_delayed_work(w, 0); + mutex_unlock(&doe->tasks_lock); + + /* Set the return value to the length of received payload */ + task->rv = rc; + task->cb(task->private); + return; + + case DOE_WAIT_ABORT: + case DOE_WAIT_ABORT_ON_ERR: + pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val); + + if (!FIELD_GET(PCI_DOE_STATUS_ERROR, val) && + !FIELD_GET(PCI_DOE_STATUS_BUSY, val)) { + /* Back to normal state - carry on */ + mutex_lock(&doe->tasks_lock); + if (!list_empty(&doe->tasks)) + schedule_delayed_work(w, 0); + mutex_unlock(&doe->tasks_lock); + + /* + * For deliberately triggered abort, someone is + * waiting. + */ + if (doe->state == DOE_WAIT_ABORT) + complete(&doe->abort_c); + doe->state = DOE_IDLE; + + return; + } + if (time_after(jiffies, doe->timeout_jiffies)) { + struct pci_doe_task *t, *n; + + /* We are dead - abort all queued tasks */ + pci_err(pdev, "DOE ABORT timed out\n"); + mutex_lock(&doe->tasks_lock); + doe->dead = true; + list_for_each_entry_safe(t, n, &doe->tasks, h) { + t->rv = -EIO; + t->cb(t->private); + list_del(&t->h); + } + + mutex_unlock(&doe->tasks_lock); + if (doe->state == DOE_WAIT_ABORT) + complete(&doe->abort_c); + } + return; + } + +err_abort: + pci_doe_abort_start(doe); + doe->state = DOE_WAIT_ABORT_ON_ERR; +err_busy: + mutex_lock(&doe->tasks_lock); + list_del(&task->h); + mutex_unlock(&doe->tasks_lock); + + task->rv = rc; + task->cb(task->private); + /* + * If we got here via err_busy, and the queue isn't empty then we need + * to go again. + */ + if (doe->state == DOE_IDLE) { + mutex_lock(&doe->tasks_lock); + if (!list_empty(&doe->tasks)) + schedule_delayed_work(w, 0); + mutex_unlock(&doe->tasks_lock); + } +} + +static int pci_doe_discovery(struct pci_doe *doe, u8 *index, u16 *vid, + u8 *protocol) +{ + u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX, *index); + u32 response_pl; + struct pci_doe_exchange ex = { + .vid = PCI_VENDOR_ID_PCI_SIG, + .protocol = PCI_DOE_PROTOCOL_DISCOVERY, + .request_pl = &request_pl, + .request_pl_sz = sizeof(request_pl), + .response_pl = &response_pl, + .response_pl_sz = sizeof(response_pl), + }; + int ret; + + ret = pci_doe_exchange_sync(doe, &ex); + if (ret < 0) + return ret; + + if (ret != sizeof(response_pl)) + return -EIO; + + *vid = FIELD_GET(PCI_DOE_DATA_OBJECT_DISC_RSP_3_VID, response_pl); + *protocol = FIELD_GET(PCI_DOE_DATA_OBJECT_DISC_RSP_3_PROTOCOL, response_pl); + *index = FIELD_GET(PCI_DOE_DATA_OBJECT_DISC_RSP_3_NEXT_INDEX, response_pl); + + return 0; +} + +static int pci_doe_cache_protocols(struct pci_doe *doe) +{ + u8 index = 0; + int rc; + + /* Discovery protocol must always be supported and must report itself */ + doe->num_prots = 1; + doe->prots = kzalloc(sizeof(*doe->prots) * doe->num_prots, GFP_KERNEL); + if (doe->prots == NULL) + return -ENOMEM; + + do { + struct pci_doe_prot *prot, *prot_new; + + prot = &doe->prots[doe->num_prots - 1]; + rc = pci_doe_discovery(doe, &index, &prot->vid, &prot->type); + if (rc) + goto err_free_prots; + + if (index) { + prot_new = krealloc(doe->prots, + sizeof(*doe->prots) * doe->num_prots, + GFP_KERNEL); + if (prot_new == NULL) { + rc = -ENOMEM; + goto err_free_prots; + } + doe->prots = prot_new; + doe->num_prots++; + } + } while (index); + + return 0; + +err_free_prots: + kfree(doe->prots); + return rc; +} + +static void pci_doe_init(struct pci_doe *doe, struct pci_dev *pdev, int doe_offset) +{ + mutex_init(&doe->tasks_lock); + init_completion(&doe->abort_c); + doe->cap = doe_offset; + doe->pdev = pdev; + INIT_LIST_HEAD(&doe->tasks); + INIT_DELAYED_WORK(&doe->statemachine, doe_statemachine_work); +} + +static int pci_doe_abort(struct pci_doe *doe) +{ + reinit_completion(&doe->abort_c); + mutex_lock(&doe->tasks_lock); + doe->abort = true; + mutex_unlock(&doe->tasks_lock); + schedule_delayed_work(&doe->statemachine, 0); + wait_for_completion(&doe->abort_c); + + if (doe->dead) + return -EIO; + + return 0; +} + +static int pci_doe_register(struct pci_doe *doe) +{ + struct pci_dev *pdev = doe->pdev; + bool poll = !pci_dev_msi_enabled(pdev); + int rc, irq; + u32 val; + + pci_read_config_dword(pdev, doe->cap + PCI_DOE_CAP, &val); + + if (!poll && FIELD_GET(PCI_DOE_CAP_INT, val)) { + irq = pci_irq_vector(pdev, FIELD_GET(PCI_DOE_CAP_IRQ, val)); + if (irq < 0) + return irq; + + rc = request_irq(irq, pci_doe_irq, 0, "DOE", doe); + if (rc) + return rc; + + doe->irq = irq; + pci_write_config_dword(pdev, doe->cap + PCI_DOE_CTRL, + FIELD_PREP(PCI_DOE_CTRL_INT_EN, 1)); + } + + /* Reset the mailbox by issuing an abort */ + rc = pci_doe_abort(doe); + if (rc) + goto err_free_irqs; + + return 0; + +err_free_irqs: + if (doe->irq > 0) + free_irq(doe->irq, doe); + + return rc; +} + +static void pci_doe_unregister(struct pci_doe *doe) +{ + if (doe->irq > 0) + free_irq(doe->irq, doe); +} + +void pci_doe_unregister_all(struct pci_dev *pdev) +{ + struct pci_doe *doe, *next; + + list_for_each_entry_safe(doe, next, &pdev->doe_list, h) { + /* First halt the state machine */ + cancel_delayed_work_sync(&doe->statemachine); + kfree(doe->prots); + pci_doe_unregister(doe); + kfree(doe); + } +} +EXPORT_SYMBOL_GPL(pci_doe_unregister_all); + +/** + * pci_doe_register_all() - Find and register all DOE mailboxes. + * @pdev: PCI device whose DOE mailboxes we are finding. + * + * Will locate any DOE mailboxes present on the device and cache the protocols + * so that pci_doe_find() can be used to retrieve a suitable DOE instance. + * + * DOE mailboxes are available until pci_doe_unregister_all() is called. + * + * RETURNS: 0 on success, < 0 on error. + */ +int pci_doe_register_all(struct pci_dev *pdev) +{ + struct pci_doe *doe; + int pos = 0; + int rc; + + INIT_LIST_HEAD(&pdev->doe_list); + + /* Walk the DOE extended capabilities and add to per pci_dev list */ + while (true) { + pos = pci_find_next_ext_capability(pdev, pos, + PCI_EXT_CAP_ID_DOE); + if (!pos) + return 0; + + doe = kzalloc(sizeof(*doe), GFP_KERNEL); + if (!doe) { + rc = -ENOMEM; + goto err_free_does; + } + + pci_doe_init(doe, pdev, pos); + rc = pci_doe_register(doe); + if (rc) { + kfree(doe); + goto err_free_does; + } + + rc = pci_doe_cache_protocols(doe); + if (rc) { + pci_doe_unregister(doe); + kfree(doe); + goto err_free_does; + } + + list_add(&doe->h, &pdev->doe_list); + } + +err_free_does: + pci_doe_unregister_all(pdev); + + return rc; +} +EXPORT_SYMBOL_GPL(pci_doe_register_all); + +/** + * pci_doe_find() - Find the first DOE instance that supports a given protocol. + * @pdev: Device on which to find the DOE instance. + * @vid: Vendor ID. + * @type: Specific protocol for this vendor. + * + * RETURNS: Pointer to DOE instance on success, NULL on no suitable instance + * available. + */ +struct pci_doe *pci_doe_find(struct pci_dev *pdev, u16 vid, u8 type) +{ + struct pci_doe *doe; + int i; + + list_for_each_entry(doe, &pdev->doe_list, h) { + for (i = 0; i < doe->num_prots; i++) + if ((doe->prots[i].vid == vid) && + (doe->prots[i].type == type)) + return doe; + } + + return NULL; +} +EXPORT_SYMBOL_GPL(pci_doe_find); diff --git a/include/linux/pci-doe.h b/include/linux/pci-doe.h new file mode 100644 index 000000000000..0307ed17d3ab --- /dev/null +++ b/include/linux/pci-doe.h @@ -0,0 +1,85 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Data Object Exchange was added to the PCI spec as an ECN to 5.0. + * + * Copyright (C) 2021 Huawei + * Jonathan Cameron <Jonathan.Cameron@huawei.com> + */ + +#include <linux/completion.h> +#include <linux/list.h> +#include <linux/mutex.h> + +#ifndef LINUX_PCI_DOE_H +#define LINUX_PCI_DOE_H + +struct pci_doe_prot { + u16 vid; + u8 type; +}; + +struct workqueue_struct; + +enum pci_doe_state { + DOE_IDLE, + DOE_WAIT_RESP, + DOE_WAIT_ABORT, + DOE_WAIT_ABORT_ON_ERR, +}; + +struct pci_doe_exchange { + u16 vid; + u8 protocol; + u32 *request_pl; + size_t request_pl_sz; + u32 *response_pl; + size_t response_pl_sz; +}; + +/** + * struct pci_doe - State to support use of DOE mailbox + * @cap: Config space offset to base of DOE capability. + * @pdev: PCI device that hosts this DOE. + * @abort_c: Completion used for initial abort handling. + * @irq: Interrupt used for signaling DOE ready or abort. + * @prots: Cache of identifiers for protocols supported. + * @num_prots: Size of prots cache. + * @h: Used for DOE instance lifetime management. + * @wq: Workqueue used to handle state machine and polling / timeouts. + * @tasks: List of task in flight + pending. + * @tasks_lock: Protect the tasks list. + * @statemachine: Work item for the DOE state machine. + * @state: Current state of this DOE. + * @timeout_jiffies: 1 second after GO set. + * @busy_retries: Count of retry attempts. + * @abort: Request a manual abort (e.g. on init). + * @dead: Used to mark a DOE for which an ABORT has timed out. Further messages + * will immediately be aborted with error. + */ +struct pci_doe { + int cap; + struct pci_dev *pdev; + struct completion abort_c; + int irq; + struct pci_doe_prot *prots; + int num_prots; + struct list_head h; + + struct workqueue_struct *wq; + struct list_head tasks; + struct mutex tasks_lock; + struct delayed_work statemachine; + enum pci_doe_state state; + unsigned long timeout_jiffies; + unsigned int busy_retries; + unsigned int abort:1; + unsigned int dead:1; +}; + +int pci_doe_register_all(struct pci_dev *pdev); +void pci_doe_unregister_all(struct pci_dev *pdev); +struct pci_doe *pci_doe_find(struct pci_dev *pdev, u16 vid, u8 type); + +int pci_doe_exchange_sync(struct pci_doe *doe, struct pci_doe_exchange *ex); + +#endif diff --git a/include/linux/pci.h b/include/linux/pci.h index 86c799c97b77..ac7a18826096 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -332,6 +332,9 @@ struct pci_dev { #ifdef CONFIG_PCIEPORTBUS struct rcec_ea *rcec_ea; /* RCEC cached endpoint association */ struct pci_dev *rcec; /* Associated RCEC device */ +#endif +#ifdef CONFIG_PCI_DOE + struct list_head doe_list; /* Data Object Exchange mailboxes */ #endif u8 pcie_cap; /* PCIe capability offset */ u8 msi_cap; /* MSI capability offset */ diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h index e709ae8235e7..b97df1d8bd19 100644 --- a/include/uapi/linux/pci_regs.h +++ b/include/uapi/linux/pci_regs.h @@ -730,7 +730,8 @@ #define PCI_EXT_CAP_ID_DVSEC 0x23 /* Designated Vendor-Specific */ #define PCI_EXT_CAP_ID_DLF 0x25 /* Data Link Feature */ #define PCI_EXT_CAP_ID_PL_16GT 0x26 /* Physical Layer 16.0 GT/s */ -#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PL_16GT +#define PCI_EXT_CAP_ID_DOE 0x2E /* Data Object Exchange */ +#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_DOE #define PCI_EXT_CAP_DSN_SIZEOF 12 #define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40 @@ -1092,4 +1093,30 @@ #define PCI_PL_16GT_LE_CTRL_USP_TX_PRESET_MASK 0x000000F0 #define PCI_PL_16GT_LE_CTRL_USP_TX_PRESET_SHIFT 4 +/* Data Object Exchange */ +#define PCI_DOE_CAP 0x04 /* DOE Capabilities Register */ +#define PCI_DOE_CAP_INT 0x00000001 /* Interrupt Support */ +#define PCI_DOE_CAP_IRQ 0x00000ffe /* Interrupt Message Number */ +#define PCI_DOE_CTRL 0x08 /* DOE Control Register */ +#define PCI_DOE_CTRL_ABORT 0x00000001 /* DOE Abort */ +#define PCI_DOE_CTRL_INT_EN 0x00000002 /* DOE Interrupt Enable */ +#define PCI_DOE_CTRL_GO 0x80000000 /* DOE Go */ +#define PCI_DOE_STATUS 0x0c /* DOE Status Register */ +#define PCI_DOE_STATUS_BUSY 0x00000001 /* DOE Busy */ +#define PCI_DOE_STATUS_INT_STATUS 0x00000002 /* DOE Interrupt Status */ +#define PCI_DOE_STATUS_ERROR 0x00000004 /* DOE Error */ +#define PCI_DOE_STATUS_DATA_OBJECT_READY 0x80000000 /* Data Object Ready */ +#define PCI_DOE_WRITE 0x10 /* DOE Write Data Mailbox Register */ +#define PCI_DOE_READ 0x14 /* DOE Read Data Mailbox Register */ + +/* DOE Data Object - note not actually registers */ +#define PCI_DOE_DATA_OBJECT_HEADER_1_VID 0x0000ffff +#define PCI_DOE_DATA_OBJECT_HEADER_1_TYPE 0x00ff0000 +#define PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH 0x0003ffff + +#define PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX 0x000000ff +#define PCI_DOE_DATA_OBJECT_DISC_RSP_3_VID 0x0000ffff +#define PCI_DOE_DATA_OBJECT_DISC_RSP_3_PROTOCOL 0x00ff0000 +#define PCI_DOE_DATA_OBJECT_DISC_RSP_3_NEXT_INDEX 0xff000000 + #endif /* LINUX_PCI_REGS_H */
Introduced in a PCI ECN [1], DOE provides a config space based mailbox with standard protocol discovery. Each mailbox is accessed through a DOE Extended Capability. A device may have 1 or more DOE mailboxes, each of which is allowed to support any number of protocols (some DOE protocol specifications apply additional restrictions). A given protocol may be supported on more than one DOE mailbox on a given function. If a driver wishes to access any number of DOE instances / protocols it makes a single call to pcie_doe_register_all() which will find available DOEs, create the required infrastructure and cache the protocols they support. pcie_doe_find() can then retrieve a pointer to an appropriate DOE instance. A synchronous interface is provided in pcie_doe_exchange_sync() to perform a single query / response exchange. Testing conducted against QEMU using: https://lore.kernel.org/qemu-devel/1612900760-7361-1-git-send-email-cbrowy@avery-design.com/ + fix for interrupt flag mentioned in that thread and a whole load of hacks to exercise error paths etc. [1] https://members.pcisig.com/wg/PCI-SIG/document/14143 Data Object Exchange (DOE) - Approved 12 March 2020 Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> --- Thanks to Bjorn Helgaas for reviewing v2. Changes since v2: * Move files and rename so as not to make them PCIe specific. * Rename pretty much everything from pcie* to pci*. * Editorial changes in patch description. * Rename pcie_doe_sync() to pci_doe_exchange_sync() to add a verb. Note that I'm not happy with this naming, but have not come up with anything better. Suggestions welcome! * Various white space, punctuation and similar changes as suggested by Bjorn. * Consistent reporting of return values in kernel-doc. * Use bitfields for Boolean elements of struct pci_doe. * Change some labels so we don't have both a local variable and label abort. * Add missing EXPORT_SYMBOL_GPL(pci_doe_exchange_sync) to allow use from modules. * Consistenty use sizeof(u32) for DW size. Thanks to Dan Williams for reviewing v1. Note code has changed a lot, so I may well have missed stuff in this log Changes since v1: Major stuff: * Rework the registration of DOE. DOE instances are added to a list in the struct pci_dev. A single call to pcie_doe_register_all() finds all DOEs present on a device and caches which protocols they support. The lifetime of these can then all be managed alongside the struct pci_dev avoiding need for reference counting etc whilst allowing a driver not to care if different protocols are using the same DOE instance, or different ones. The driver issues a call to pcie_doe_find() to get a pointer to the first appropriate DOE. Note, a side effect of minimizing impact of this on struct pci_dev is that we can't build DOE support as a module. * Instead of serializing on a mutex, move to a more complex state machine based scheme in which the DOE config space registers are only accessed from a single delayed work item. The state machine uses two states for normal operation, IDLE and WAITING. Two states also exist for ABORT to indicate if it was called in response to error, or at startup. Interrupts result in mod_delayed_work() to force an immediate check on the status register. Message queuing is implemented with a list of tasks and kicking the state machine work item as needed. * Decide, inside the core DOE code, whether to poll based on if the MSI/MSIX interrupts are enabled and the DOE instance advertises an interrupt. * Define a struct pcie_doe_exchange to encapsulate header info with payloads etc. Specific fields used for VID and protocol + lengths so the DOE header can be constructed inside the DOE functions rather than relying on callers to do that. * Don't hide away devm_ stuff in calls that don't make it obvious. Minor stuff: * pcie_doe_init() and pcie_doe_register separation to cover the bits that can fail in register() and the bits that can't in init() * Many typos * Rename cap_offset field to cap * Use new PCI_VENDOR_ID_PCI_SIG define to avoid open coding the value * Add defines for timeouts etc. * Missing EXPORT_SYMBOL_GPL() added to allow DOE access from modules. drivers/pci/Kconfig | 8 + drivers/pci/Makefile | 1 + drivers/pci/doe.c | 601 ++++++++++++++++++++++++++++++++++ include/linux/pci-doe.h | 85 +++++ include/linux/pci.h | 3 + include/uapi/linux/pci_regs.h | 29 +- 6 files changed, 726 insertions(+), 1 deletion(-) -- 2.27.0