On Thu, 14 Jan 2021 11:04:25 -0800
Ben Widawsky [off-list ref] wrote:

On 21-01-14 18:32:17, Jonathan Cameron wrote:

quoted

On Thu, 14 Jan 2021 10:13:40 -0800
Ben Widawsky [off-list ref] wrote:
  

quoted

On 21-01-14 18:02:11, Jonathan Cameron wrote:  

quoted

On Mon, 11 Jan 2021 14:51:19 -0800
Ben Widawsky [off-list ref] wrote:
    

quoted

The Command Effects Log (CEL) is specified in the CXL 2.0 specification.
The CEL is one of two types of logs, the other being vendor specific.
They are distinguished in hardware/spec via UUID. The CEL is immediately
useful for 2 things:
1. Determine which optional commands are supported by the CXL device.
2. Enumerate any vendor specific commands

The CEL can be used by the driver to determine which commands are
available in the hardware (though it isn't, yet). That set of commands
might itself be a subset of commands which are available to be used via
CXL_MEM_SEND_COMMAND IOCTL.

Prior to this, all commands that the driver exposed were explicitly
enabled. After this, only those commands that are found in the CEL are
enabled.

Signed-off-by: Ben Widawsky <redacted>    

This patch made me wonder if the model for the command in quite right.
I think it would end up simpler with a pair of payload pointers for send
and receive (that can be equal when it makes sense).

A few other things inline.

Jonathan    

I'll address the others separately, but could you elaborate on this? I'm not
sure I follow your meaning.  

Further down in the review..
"
The fact that you end up bypassing the payload transfer stuff in mbox_cmd
rather suggests it's not a particularly good model.  + it keeps confusing
me.

While the hardware uses a single region for the payload, there is nothing
saying the code has to work that way.   Why not have separate payload_in and
payload_out pointers?  Occasionally you might set them to the same buffer, but
elsewhere you could avoid the direct memcpy()s you are doing around the
send_cmd(). 

"

Jonathan

  

Ah I was confused if that was a separate statement.

Can you specify the function prototype you're hoping for (or modification to the
structure)?

I really like the lowest level function to simply model the hardware. I get to
write the 8 steps out and clearly implement them.

I personally don't think it's so awkward, but again, give me something more
specific and I'll consider it.

Looking at the case in this patch as an example

Something like (completely untested)...
Note only real change here is having an extra pointer in mbox_cmd so we can 
have in and out buffers provided.  Doesn't change the flow at all means we can
use the internal memcpy_from_io memcpy_to_io in more cases.
Zero copy is still fine if we are in a case where it makes sense.

struct mbox_cmd {
	u16 opcode;
//separate in and out pointers.
	void *payload_in;
	void *payload_out;
	size_t size_in;
	size_t size_out;
	u16 return_code;
};

static int cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm,
				 struct mbox_cmd *mbox_cmd)
{
	u64 cmd_reg, status_reg;
	size_t out_len;
	int rc;

	lockdep_assert_held(&cxlm->mbox.mutex);

	/*
	 * Here are the steps from 8.2.8.4 of the CXL 2.0 spec.
	 *   1. Caller reads MB Control Register to verify doorbell is clear
	 *   2. Caller writes Command Register
	 *   3. Caller writes Command Payload Registers if input payload is non-empty
	 *   4. Caller writes MB Control Register to set doorbell
	 *   5. Caller either polls for doorbell to be clear or waits for interrupt if configured
	 *   6. Caller reads MB Status Register to fetch Return code
	 *   7. If command successful, Caller reads Command Register to get Payload Length
	 *   8. If output payload is non-empty, host reads Command Payload Registers
	 */

	/* #1 */
	WARN_ON(cxl_doorbell_busy(cxlm));

	cmd_reg = CXL_SET_FIELD(mbox_cmd->opcode, CXLDEV_MB_CMD_COMMAND_OPCODE);
	if (mbox_cmd->size_in) {
		cmd_reg |= CXL_SET_FIELD(mbox_cmd->size_in,
					 CXLDEV_MB_CMD_PAYLOAD_LENGTH);
		//leave this here for your userspace zero copy path...
		if (mbox_cmd->payload_in)
			memcpy_toio(cxl_payload_regs(cxlm), mbox_cmd->payload_in,
				    mbox_cmd->size_in);
	}

	/* #2, #3 */
	cxl_write_mbox_reg64(cxlm, CXLDEV_MB_CMD_OFFSET, cmd_reg);

	/* #4 */
+	dev_dbg(&cxlm->pdev->dev, "Sending command\n");
	cxl_write_mbox_reg32(cxlm, CXLDEV_MB_CTRL_OFFSET,
			     CXLDEV_MB_CTRL_DOORBELL);

	/* #5 */
	rc = cxl_mem_wait_for_doorbell(cxlm);
	if (rc == -ETIMEDOUT) {
		cxl_mem_mbox_timeout(cxlm, mbox_cmd);
		return rc;
	}

	/* #6 */
	status_reg = cxl_read_mbox_reg64(cxlm, CXLDEV_MB_STATUS_OFFSET);
	mbox_cmd->return_code =
		CXL_GET_FIELD(status_reg, CXLDEV_MB_STATUS_RET_CODE);

	if (mbox_cmd->return_code != 0) {
		dev_dbg(&cxlm->pdev->dev, "Mailbox operation had an error\n");
		return 0;
	}

	/* #7 */
	cmd_reg = cxl_read_mbox_reg64(cxlm, CXLDEV_MB_CMD_OFFSET);
	out_len = CXL_GET_FIELD(cmd_reg, CXLDEV_MB_CMD_PAYLOAD_LENGTH);
	
	/* #8 */
	if (out_len && mbox_cmd->payload_out)
		memcpy_fromio(mbox_cmd->payload_out, cxl_payload_regs(cxlm),
			      min(mbox_cmd->size_out, out_len));

//move this down here - because they the output buffer might theory not
//bit big enough.
	mbox_cmd->size_out = out_len;

	return 0;
}



....


static int cxl_xfer_log(struct cxl_mem *cxlm, uuid_t *uuid, u32 size,
			u8 *out)
{
	u32 remaining = size;
	u32 offset = 0;

	while (remaining) {
		u32 xfer_size = min_t(u32, remaining, cxlm->mbox.payload_size);
		struct mbox_cmd mbox_cmd;
		int rc;
		struct cxl_mbox_get_log log = {
			.uuid = *uuid,
			.offset = cpu_to_le32(offset),
			.length = cpu_to_le32(xfer_size),
		};

		mbox_cmd = (struct mbox_cmd) {
			.opcode = CXL_MBOX_OP_GET_LOG,
			.payload_in = &log,
			.size_in = sizeof(log),
			.payload_out = out,
			.size_out = min(xfer_size, remaining),
		};

		rc = cxl_mem_mbox_send_cmd(cxlm, &mbox_cmd);
		if (rc)
			return rc;

		WARN_ON(mbox_cmd.size_out != xfer_size);

		out += xfer_size;
		remaining -= xfer_size;
		offset += xfer_size;
	}

	return 0;
}