diff mbox series

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

Message ID 20210419165451.2176200-3-Jonathan.Cameron@huawei.com
State New
Headers show
Series PCI Data Object Exchange support + CXL CDAT | expand

Commit Message

Jonathan Cameron April 19, 2021, 4:54 p.m. UTC 
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(-)

Comments

Ira Weiny May 6, 2021, 9:59 p.m. UTC | #1 
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
Jonathan Cameron May 7, 2021, 9:36 a.m. UTC | #2 
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);
> +}
> +
Bjorn Helgaas May 7, 2021, 11:10 p.m. UTC | #3 
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."
Jonathan Cameron May 11, 2021, 4:50 p.m. UTC | #4 
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
Jonathan Cameron May 12, 2021, 12:44 p.m. UTC | #5 
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
Dan Williams May 13, 2021, 9:20 p.m. UTC | #6 
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.
Jonathan Cameron May 14, 2021, 8:47 a.m. UTC | #7 
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
Lorenzo Pieralisi May 14, 2021, 11:15 a.m. UTC | #8 
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
Jonathan Cameron May 14, 2021, 12:39 p.m. UTC | #9 
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
Dan Williams May 14, 2021, 6:37 p.m. UTC | #10 
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.
Jonathan Cameron May 17, 2021, 8:40 a.m. UTC | #11 
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
Greg Kroah-Hartman May 17, 2021, 8:51 a.m. UTC | #12 
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
Dan Williams May 17, 2021, 5:21 p.m. UTC | #13 
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.
Jonathan Cameron May 18, 2021, 10:04 a.m. UTC | #14 
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
Dan Williams May 19, 2021, 2:18 p.m. UTC | #15 
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.
Jonathan Cameron May 19, 2021, 3:11 p.m. UTC | #16 
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
Dan Williams May 19, 2021, 3:29 p.m. UTC | #17 
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.
Jonathan Cameron May 19, 2021, 4:20 p.m. UTC | #18 
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.
Jonathan Cameron May 19, 2021, 4:33 p.m. UTC | #19 
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.  
>
Dan Williams May 19, 2021, 4:53 p.m. UTC | #20 
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.
Jonathan Cameron May 19, 2021, 5 p.m. UTC | #21 
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
Dan Williams May 19, 2021, 7:20 p.m. UTC | #22 
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.
Jonathan Cameron May 19, 2021, 8:18 p.m. UTC | #23 
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
Dan Williams May 19, 2021, 11:51 p.m. UTC | #24 
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.
Dan Williams May 20, 2021, 12:16 a.m. UTC | #25 
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.
Jonathan Cameron May 20, 2021, 8:22 a.m. UTC | #26 
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 mbox series

Patch

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 */